July 13, 2017
I recently started a new job in bank company as Senior UI Developer. When I first joined I was told that the the company itself was using cutting edge technologies and stuff like that. In a world like this, a Frontend Developer loves to work with such technologies, and so am I.
Once I started, I understood that everything was misunderstood. They actually use cutting edge technologies but the whole ecosystem around it is fucked up. There's a legacy thing, there's a half legacy thing and there's a cutting edge technology thing that is really bad used.
Although, the will of the team is to refactor the whole application smoothly and gracefully using the latest technologies and least, but not last, some technology that is well maintained and there's assurance that it will be supported for the next five years at least.
The library that was chosen at that time was made by a guy there, so when he left it wasn't maintained anymore. Bad choice.
The frontend has grown so fast and so big that now it has become really difficult to evaluate what to use inside an application. Five or seven years ago there was mainly jQuery and that was always the correct choice (yeah, let's also remember Dojo).
Nowadays there are lot of choices and which is good because it forces the concurrency and the evolution between vendors; from another point of view it's bad because the decision process is longer and harder.
I don't want to bother you people with libraries and frameworks we have around. I want to share how I take a decision.
I will now list which are the factors that, from my point of view, have to take in consideration when choosing a library/framework.
First of all the context is really important. I have worked in a company where they didn't want to have a Single Page application because they were running an existing e-commerce and they wanted to target the widest range of customers. Also, there was the SEO to take in consideration as they have competition and they run SEM campaigns on the different search engines.
I another job we were dealing with an internal application. A website running through a dedicated application installed in the client machines. In that case we had move leverage and a wider choice of libraries. In the the end, I arrived that there was the entire ReactJS ecosystem. Brilliant. That ecosystem was perfect because we wanted to have the ability to create/manipulate components through an external configuration and at the same time being able to have a Metadata computer engine that could be standalone.
The beauty was that were aiming to have something like Redux has: the library and the connector for ReactJS. We wanted to have the Metadata computer and metadata transmitter for React. Good times.
Now, here I have to take a big decision that will impact the internal development for the next five years.
Choice must be taken based on what you need. You don't use a library if it doesn't do what you really need, or it doesn't allow you to add custom functionality.
Every application and every company has different requirements. You must take them in consideration when you have to choose your library/framework. You can't choose it based on the hype of the moment, especially if you are working for an enterprise company, where stability and support are important. As I mentioned before, at the moment there's an internal library that is not supported by nobody, fixes are done internally. There's no improvement, it doesn't allow you to do much.
If you need SSR (Server side rendering), you could use AngularJS or ReactJS or VueJS or any other library or framework that gives you that.
If you need browser testing, you will definitely karma because is quite supported by the community.
That's really important. You want to use something that is widely used and where the community and the Open Source world is happy to work with. Redux has got a really big ecosystem where they created all sort of libraries on top it. In two years the type of libraries has grown a lot and now there are add-on for every kind of purpose.
Sometimes that's driven by the hype of the moment but you have to take in consideration that once people start playing with a tool, they understand if is manipulable or not. And if is, which is the extent.
Having a person that is fully committed to the implementation and fixing bugs is really reassuring. That's why libraries such as AngularJS and ReactJS became really popular in the past few years. They are backed up by giants so for sure they have money to pay their developers.
Sometimes another libraries are Open Source so the commitment of the people is limited to their free time because they don't earn anything from what they are doing. We now that the community is helpful but sometimes it's just difficult. Thankfully, if the library is successful, you will backers and sponsors somehow.
So, choose with calm and do not force your decision driven by the hype of the moment. Document yourself, make experiments and make sure that the library will give you want!