This is a guest post by Juho Vepsäläinen. He has been dealing with the web since the 90s and contributing to open source for over a decade. He is behind projects such as jster.net and SurviveJS.
When starting a front-end project, you usually have to make some technology choices unless they have been made for you already. The amount of choice we have these days can be almost overwhelming. New libraries and frameworks seem to come out each month. Technologies come and go out of vogue. This doesn't entirely make it easier.
There is no single right way to justify some technology choice. It depends on so many factors. Obviously it's safer to go with technology you already know well. But is it still relevant? Would newer technologies allow you to proceed faster even if they come with a learning curve?
On general level it's about libraries vs. frameworks. You can of course use them together so it's not an either-or proposition. Sometimes it may make sense to skip them altogether. This can be a valid approach especially when payload size is a limiting factor. JavaScript based banners are a good example of this. It's more of a special case, though, and often you may want to use at least some library to make your work easier. The split between libraries and frameworks provides a good starting point for further discussion.
The greatest benefit of picking a framework, such as Angular, is that it comes with opinions. There are less decisions to make. You will get a router to use, a way to deal with data, and of course, a way to render it. Frameworks enable high productivity out of the box if you know how to use them.
Inheriting opinions means that you might not agree with all of them. Sometimes you may have to code against the design of a framework. That is when it can begin to become hairy and even counterproductive. Rather than coding with the framework, you are coding against it.
Frameworks excel for prototyping. You can recruit people based on their knowledge of frameworks. This is visible on the job market. At the moment there's high demand for Angular developers at the moment due to this factor.
As Paul Lewis notes, frameworks come with a cost. Especially on mobile frameworks can be surprisingly heavy to use. They provide good developer ergonomics, but as Paul argues, this may have a cost for our users.
A library based approach comes with a different set of tradeoffs. In contrast to frameworks, you bring your own opinions and you may also change them. If you made a bad choice, you can revert it later. Instead of fighting against decisions that have been made for you, you simply change your mind and fix your error on a more fundamental level.
The freedom of choice can be great if there's a great amount of uncertainty in a project. If you value flexibility, a library based approach can work well. The downside is that you need to understand what libraries fit together and how. Frameworks deal with all that for you. Most importantly, frameworks come with conventions. When using libraries, you will most likely have to develop some conventions of your own.
This is the reason why each library based project tends to be like a snowflake. It is difficult to find two that are completely alike. Developing projects this way requires a different set of skills. You need to have a strong sense of architecture in order to be able to shape the project based on your requirements.
Given there are so many libraries out there, it is difficult to hire people that fit some predefined profile. Rather, you will need a different kind of strategy to attract people that are able to deal with them. This isn't necessarily a bad thing. It just means you need different recruitment tactics.
I believe there could be something between a pure framework and a library based approach. Obviously you can use certain libraries with popular frameworks to complement them. Sometimes you can even replace key portions of them entirely. That said, it may be beneficial to turn your own opinions about libraries into a framework of its own.
The idea is that once you begin to understand the type of projects you are doing better, you can begin to codify your observations into something that is possible to reuse across projects. This is something that can help particularly in the maintenance effort. Rather than having to maintain each project on its own, you bring fixes to something common and consume them across projects from there.
As no project remains static, maintenance is an important topic. Front-end development tends to move forward fast. This is something good to keep in mind. No matter how good your initial design is, it is most likely bound to change. Therefore I think it's valid to design change in mind.
Different approaches come with their own pros and cons. In a library based approach you can refactor your project a library at a time. Frameworks tend to require constant changes. Sometimes these changes may be somewhat large as a new major version of a framework comes out. Falling behind is not often a good option. This depends on the nature of the project, though.
To paraphrase Paul Lewis again, it is easy to optimize for developer ergomics while forgetting about our end users. Regardless of the approach, the user should come first. I believe it's possible to cater both. The idea is that good developer ergonomics allow us to spend more time thinking about the user. Perhaps there's some balance between the user and the developer needs.
As the web platform develops, less compromises need to be made. It is good to remember that many solutions have been designed the lowest common denominator in mind. When you design for legacy browsers, it will inevitably have an effect. If you don't need to support legacy browsers, you may be able to rely on modern web APIs instead of libraries or frameworks wrapping them. It's always valuable to understand what sort of functionality the platform provides even if you use it by a proxy.
The best we can do as front-end developers is to hang on. There are multiple ways to reach the same goal after all. I don't believe there's one definite approach. Rather, you have to customize your approach depending on your current situation and the needs of a project. Sometimes the best thing to do is to experiment with various approaches and pick the one that seems the most fitting.
Perhaps the main thing is that you should be prepared to change your mind. Nothing is ever static in software design. It can absolutely help to have structure in place. But it may make sense to design for change especially if you are in it for the long haul. No living piece of software remains the same after all.