With the help of public repositories, the open source community, and social media, we see new technologies, trends, frameworks, libraries, and languages emerge and getting popular very quickly. Those newcomers are considered by a large amount of developers and designers the “future”, “best practices”, “the only solution”, “the cure of cancer”, etcetera without the analysis required for us to shift our projects into those new directions. We can see comments on blogs like this: “Great guys! I am for sure using this on my next project!”. Lets talk about JavaScript in particular which has countless libraries and frameworks that offer similar solutions, but those solutions die almost as soon as they become popular. (Almost everything on this article applies to CSS too. Also, I am not going to talk about the obvious lack of Progressive Enhancement on most Single Page applications).
JavaScript is without a doubt, the language with most improvements in the last 10 years since the term Ajax was coined by Jesse James Garrett in 2005, which is the foundation on how we develop rich internet applications today. JavaScript, considered a “toy language” in the past, now has a respectable amount of developers and it has been evolving rapidly. However, those advantages on JavaScript also brings problems: lifespan/support and redundancy of the tools we use to develop with JavaScript. I will discuss some of the problems front-end developers face today while developing using JavaScript.
Libraries/Frameworks Lifespan
JavaScript Frameworks and libraries usually get a lot of attention at their birth, but their lifespan is very short if we compare them with other popular frameworks and libraries in other languages. For example, PrototypeJS was the go to guy years ago, now a very small margin of developers consider working with Prototype. In fact, Sam Stephenson wrote a very good post where he addresses some of the issues with Prototype, and how it went from a recommended library to the one with the most critics. A good measure for the popularity is Google Trends, where we can see the popularity of those JavaScript libraries from 2007-2009 but rapidly fading away with the exception of jQuery, which still stays popular as it was years ago. In addition, you can see the amount of JavaScript frameworks available in TodoMVC and the majority of them will not be maintained and will likely die in near future. Just look at BatmanJS. The framework was created by Shopify in 2013, and by 2014, the framework was abandoned. So, even if the framework was built by a well-known company, it does not mean that you are safe building your product with it. Something similar happened with Angular 1.x version after the announcement of 2.0. I will discuss this later on this post.
Best Practices Change too Fast
Most popular languages have already a set of best practices. In JavaScript, we are still developing and discovering ways to develop applications efficiently. We went from inline-scripting to unobtrusive JavaScript, from placing the script on the head to placing at the bottom of the page to improve performance, etc. But, we are not there yet, not like other languages due to the environment JavaScript is meant to be execute: the browser. The browsers are updated constantly and they include new versions of JavaScript almost as soon as it is available, which leads to developers implementing and figuring out new practices and advices for good code. For instance, in the past it was considered a good practice to modify directly a built-in objects but now it is considered a bad practice and you should never modify because it can break your code somewhere, especially if you are using a JavaScript library.
Support and Backwards Compatibility
AngularJS is one of the most popular JavaScript frameworks. But, even with its popularity, recent announcements on incompatibility between versions 1.x and 2.0 has made a lot of developers to rethink how they want to build a product around a framework. The framework does not offer a way to upgrade to version 2.0. For example, would you like to build an app that only has support for 2 more years? Are you willing to rebuild the application again in AngularJS 2.0 in near future? Are your clients willing to pay twice for the same work (considering that version 1.x will be out of support in a couple of years max)? Do you want to wait months to start working on AngularJS 2.0? Those are the kind of questions developers should not have to make in order to develop an app. Frameworks should be always compatible with previous versions. At least they should warn the developer for several versions about a deprecated method that may be removed in future versions. Developers don’t use frameworks only to speed up their development, the frameworks take care of the headache of us instead of giving us one with new versions.
Tools Redundancy
This is where JavaScript development takes that cake. There are too many tools around front-end development. Even to write JavaScript is hard because everybody has “the solution” ( just look at the list of languages that compile to JavaScript.) It is impossible to keep track of all of them, and it looks like every single developer has a prefered tool and there is not a consensus on which one is better. Additionally, companies and teams have their prefered framework and tools. So, if you are looking for a job as a front-end developer, you may need knowledge in several MVC frameworks and tools in order to apply to different companies because one may require BackboneJS, while the other may need AngularJS. The following tweet from Stefan Baumgartner explains the stage of our tools right now.
“What’s bower?” “A package manager, install it with npm.” “What’s npm?” “A package manager, you can install it with brew” “What’s brew?” …
— Stefan Baumgartner (@ddprrt) November 5, 2014
If you really need one of the tools, you have to pick the one that goes with your personal style and projects. But, keep praying that it stays on development and it does not fall on the first point of this post. At the moment of this post, 37 repositories package managers for JavaScript where found in Github. A package manager is a tool where we should have a consensus on which one is the best and move forward with it.
In JavaScript, there is no clear winner when it comes to MV* frameworks. So, the effort of the community is spread across multiple frameworks that do exactly the same thing. This contrasts from other languages like Ruby where Ruby on Rails is the leader, C# where ASP.net MVC is the defacto standard, Python where Django is the king, etc.
For seasoned developers this may not be a problem. But what about the new developers? They are already overwhelmed having to learn proper HTML, CSS, JavaScript, and one of the popular back end languages. So, they don’t have a clear path of what to learn to become relevant and find a job because the market has decided that you need to learn and be an expert with some tools. However, the tools are not clear choice because they may choose the wrong tool to learn because it may be outdated as soon as they mastered it.
We Fall In Love too Fast.
A lot of front-end developers don’t have a very strong resistance to change like website users, which is a good thing. But, some developers just need a Todo list demo to get excited and crazy to built an app with the new framework or tool. Some don’t wait for a framework to get out of beta or reach version 1.0 in order to build something with it. We need to learn to wait and let the tools mature so we can take full advantage or have a better idea of the path they are going to take.
Conclusion
I am very much a fan of JavaScript and its capabilities. However, I am also on the side that because you can do it, does not mean you should. If we are going to build something that lasts, we need to start thinking of what is the best option for our projects. Some of those tools and frameworks may not be maintained long enough for us to dedicate our time and effort learning them and using them in our projects.
