Why don’t we use front-end frameworks at Locomotive?
In the web community, we’re often asked why we don’t use a front-end framework. At Locomotive the vast majority of our sites are built without front-end frameworks, but why?
A front-end framework is a toolbox with a certain structure, files and folders already organized, and a number of tools to facilitate front-end development — especially for managing components, transitions and routes. For example, some widely-used front-end frameworks (such as VueJS, ReactJS or Angular) are all different from each other, and adapt to the needs of all developers.
At Locomotive, our front-end boilerplate (empty project ready to be started) is like a “mini framework.” Since this tool was built internally for our small team’s specific needs, we adapted it to be the perfect fit for us. But of course, with our front-end developers mostly busy working on client projects, developing our boilerplate isn’t our priority. As a result it typically evolves quite slowly.
As things progressed, we realized our internal tools and front-end boilerplate were very powerful and met many of our needs.
A few projects with ReactJS and VueJS
Over the last 5 years, we had a few projects that really lent themselves to using front-end frameworks. In those days, ReactJS was all the rage, so when we understood that we needed to develop a web application, it made sense to use it.
To tell you more about our experiences with front-end frameworks, we used ReactJS for the Report.Cards web application, and mainly for our citizen solution Agora. Recently, we worked with VueJS (Nuxt) to develop the Fontshare.com site. These projects were seen more as “application-style,” with many components and variations, and a lot of data to manage. Another important aspect of this type of project is dynamic data change, front-end routes, API settings, etc… All these constraints make this type of framework an interesting technical choice.
We had to reappropriate a lot of concepts: how to handle views, components, CSS, routes and data management. And the development went super well, these projects’ technical needs fit with this type of framework. As things progressed, we realized our internal tools and front-end boilerplate were very powerful and met many of our needs.
When we see a design, our boilerplate allows us to know very quickly whether it’s possible and feasible to develop a certain feature within it, because we know our own tool like the back of our hand.
Work without a framework?
Our front-end boilerplate has evolved a lot in the past 6 years, according to our needs, habits and everyone’s desires.
You know, it’s kind of like that old pair of shoes you wear all the time, maybe they aren’t the newest, not the nicest, they wouldn’t fit anyone else… but you feel so good in them, like you could race around the world in them, so letting go feels complicated! Of course, we’re talking about technology, so we must always stay open to change. We’re the first to know we have limits. Yet when we see a design, our boilerplate allows us to know very quickly whether it’s possible and feasible to develop a certain feature within it. Sometimes we can tell as early in the process as the design or UX phase, because we know our own tool like the back of our hand.
So what does the future hold? In my opinion, we must continue to evolve our boilerplate to keep up with new developments in terms of performance and accessibility. But do we really need a large toolbox made to appeal to everyone, when we made our own that works for us, and that only has the tools we actually need? No doubt we don’t, but let’s keep in mind that technology depends on each project and its technical specifications, and technologies evolve so quickly that we have to stay on the lookout and open-minded about using a front-end framework.
Originally published at https://locomotive.ca on July 22, 2021.
