Today I will bring a discussion about a hot topic at the moment. Actually, if you spend some time browsing blog posts and forums, it sounds more like a novel with heroes, villains, a complicated plot with probably not a very good ending, all this with a project deadline of course. Oh yes, I am talking about Javascript Frameworks!
Frameworks, Frameworks, Libraries, Libraries
I have been immersed in the topic for some time, done a lot of prototyping for a big project with +15 people, trying to found what would be the best way for us.
Angular, React, VueJs, Aurelia, Backbone, Ember, JavascriptMVC, and couple of others, all made part of the menu. Some were strongly opinionated, good maybe for teams with less know how or for LoB applications (Angular, Ember), others focused on performance with a learning curve and some decision making fatigue (React ecosystem), others yet with a great mix, but a smaller community (VueJS), all of them had strong and weak points, and I see them with specific use cases.
Know your problem
What I have learned is that before you even start considering a framework, you first need to acknowledge that problem you need to solve. If the thing you are doing is a static website, maybe you don’t need one. Or if you are building a super optimized website to run, lets say, on older smartphone or an old browser, or IE6 (ok if you actually need to support IE6 please change job), probably you should stick with other techniques (traditional server side, vanilla js, jquery mobile) due to the cpu hit you get from all the JS magic running, the impact on big javascript files on limited networks (yes I know everyone have CDNs these days, but you should see the payload of some of those things).
If your use case is the typical SPA application running on a modern browser, then a framework is a strong candidate, for the modularity and code scale it provides.
Javascript was not designed to scale
If we think a bit, the main reason why these frameworks showed up was exactly to bring organization to the mess that Javascript is. For example, Angular was created exactly to simplify and reduce the codebase of a Google product as you can see here the creator Miško Hevery talking about at ng conf back in 2014.
Javascript is a scripting language and was not built to support giant codebases.
That’s why we hear so often about the callback hell or giant spaghetti javascript files, because we are scripting our way into a large application.
Frameworks sure are a powerful tool but don’t solve the problem by themselves. This is a list of general things I learned on my journey and are agnostic to the framework you choose:
- First of all, guarantee that you and all the team know Javascript;
- Read and follow the documentation. Make sure everyone is on the same page (not literally of course, just make them read the damn docs);
- Follow the framework, don’t fight against it;
- Automate your testing. As soon as possible;
- Don’t forget the CSS. Lots of times underrated and can get a real mess. Use processors, css frameworks and well opinionated guidelines to help organize it. This is material to a blog post on its own;
- Security is as a top concern, remember you are running in the client, trust no one;
- Follow well known industry best practices. I consider important facade pattern, composition, separation of concerns and dependency inversion.
And for me, the best advice of all, avoid a large monolith. Instead try to decompose into smaller apps, each living in a separate page, this will allow you do break down and isolate your problem, and you will avoid a lot of problems associated to Large Scale Javascript.
As Justin Meyer, author JavaScriptMVC, said: “The secret to building large apps is never build large apps”.
May the SOLID be with you.