The [real] problem with JavaScript
On Monday I came across this post:
Despite the fact that the article feels like it was written by Kylo Ren after trying Lisp for the first time without any previous FP knowledge I think mister Drew makes a valid point: there’s a problem that needs to be solved.
Here I speak directly to mister Drew: in your post you attack some specific technologies and, by doing so, you also attack the people/organizations behind those projects. People that invested their most valuable asset -time- to create such tools, a lot of them for free. Believe me, if someone invested that amount of time creating a tool there is a use case for it and, as you may expect, this tool/framework/library is not suited for every problem you’ll face.
With that being said I think there’s someone else to blame for this “mess” mister Drew talks about. And that’s every developer who ever used a tool only because it was the new shiny thing or because everyone else was using it.
As professionals it’s our duty to determine which tool best solves the problem we’re working on. We shouldn’t just hop into the bandwagon of a framework because it’s hot right now, and I think this is just a small part of the real issue: a lot of developers are learning how to use a framework instead of how to use a language.
Does JavaScript and its community really suck?
JavaScript is a very powerful and flexible language, that’s its nature. If you don’t know what you’re doing stuff can get really messy but it doesn’t have to be that way.
In the last 5 years or so we’ve seen an exponential growth in the number of technologies available. We went from a handful of options (jQuery, ExtJS, Backbone) to, literally, thousands of new tools and frameworks, and it is really hard to keep up with this ever changing landscape of technologies we face every day.
As web development evolved though the years we started to build businesses right inside the front end, something that would’ve been inconceivable less than a decade ago, and the technologies available were just not powerful enough to build the kind of applications we were being ask for. So we started to port best practices, tooling and ideas from other communities and languages. We brought package managers and repositories, “compilers” (“transpilers”), static typing and so on.
This is AWESOME. See, I came from a background of compiled languages and it feels good to have all these goodies in the web development world. The best thing about it is that you don’t need to use any of those things. You can always open a terminal window, start vim and write html, js and css the good ol’ way.
But then hell broke loose.
Which framework should I use? Angular versus React. Gulp versus Grunt versus Broccoli versus Webpack. SASS, LESS or Stylus?
So a lot of developers decided to go with the flow and just adopt whatever everyone else was using. The magpie developer was born, forever stuck in that never ending pursuit for the shiniest, newest thing.
Don’t get me wrong, doing research about frameworks, comparing them and making a decision is by no means a bad thing. It’s just that we should be careful: there’s a thin line between researching and pursuing the pot of gold at the end of the rainbow.
Just because everyone else is using [framework name], doesn’t mean you should.
A new breed of programmer
I’ve been developing for 7 or 8 years now (including both back end and front end applications) and while I don’t consider that a lot of time things have certainly changed.
Back in my first year of programming I remember web development to be quite different from what we do now: it was a mere complement of your back end duties and it didn’t really matter if it looked good, it only had to work.
There was no online courses to become a “rockstar” web developer. If you wanted to become a developer you had to get a degree in Computer Science or something related. Sure, there was some “front end experts” that had vast html and css knowledge but that was basically it.
For some years that remained true and these front end “experts” never really had to handle complex situations with JavaScript. But then something changed and front end developers started to create complex applications leading to the age of the client side frameworks.
In this context more and more developers started to learn how to use a specific framework instead of how to use JavaScript. In some cases developers would think that jQuery and JavaScript were completely different technologies.
These “rockstars” are proficient in, lets say, Angular 1.x and its APIs but they lack of the understanding of how JavaScript works and how Angular could potentially do more harm than good in certain projects that you could easily build using a more lightweight alternative like Vue.js or even the good ol’ vanilla JavaScript.
Nowadays this problem is widely spread and a lot of developers are not learning the underlying language that powers their favorite framework or library. They’re adding build tools, libraries and all sorts of plugins for no reason and this results in bloated apps/sites and, a terrible developer and user experience. This is bad and, as a community, we should strive to change this.
So, instead of just criticizing the current state of things I want to propose something that hopefully will help developers to choose the proper frameworks and tools or, at least, will give them a quick reference about the experience other devs had when using the same technology stack to build similar products:
Let’s create a repository of categorized projects. These projects will have an associated technology stack complete with a description of the main challenges faced while building each project and recommendations in regards to the use of that particular stack to build similar projects.
I’ve been thinking about something like this for some time now (I even bought the shouldiuse.xyz domain name) so, to start, I’ve created a 16 question survey. Every response will be part of this crowd sourced knowledge database, I promise it wont take long and, by completing it, you’ll be giving back to the community. The survey includes some basic information about the project and the technologies used, and the main idea is to curate and expose this database though a searchable UI that will allow anyone to access it using a web browser.
By completing this survey you’ll be contributing to the creation of this knowledge database.
At the end of the day, a professional developer will analyze the pros and cons of using each candidate framework/library for a specific task and use whatever fits our team capabilities and the project requirements. I know it’s really hard to find this equilibrium but it’s better to invest some hours in the early stages of the project than figuring out, half way in, that we need to go back.
And for all of you folks in the Open Source community I can’t thank you enough for your countless contributions and efforts to make the JavaScript ecosystem a better place to create, share and collaborate.
Keep up the good work, we really appreciate it!
Disclaimer: I’m not a native English speaker, so feel free to point out grammatical and/or syntactical errors. Every respectful comment is deeply appreciated.
