The Javascript ecosystem

Introduction

This post was inspired by a long standing annoyance within me for the the Javascript ecosystem. Prompted by several incidents during my own learnings and client interactions, I was playing with several half baked ideas and then saw this.

No impetus like validation from someone you respect to get off your ass and get something you’ve been putting off done.

The problem

I’ve coded deeply in several languages and toyed with several others. Javascript has been especially annoying with the large number of frameworks each with several recommendations on usage. Couple that with super opinionated proponents of each one leads to a never ending process of decision making and analysis paralysis before one can get anything productive done.

To understand this, I have two frameworks I’m using. The first is the concept of boilerplates and the second is the idea of popularity.

Boilerplates

While we all like to claim that programming is a unique and a craft in itself, there are a lot of boring bits that we automate away. This is a good thing. Laziness is, after all, a virtue for a programmer. One way we’ve done this is by creating programs that can generate code for us. This ranges all the way from snippets (e.g. a keychord that inserts a python import guard) to frameworks (e.g. a command that generates most of the code for you and you just fill in the blanks). These things vary on various axes

• Size Snippets are usually quick way to insert a commonly used piece of code like a for loop header. Frameworks might generate several dozen lines of code
• Commitment If I use yasnippet on Emacs, I (and my team) can move away from it at a moments notice. If I use create-react-app, we have to follow its conventions and rules throughout the project. “Whatever a framework does for you, it also does to you”
• Configurability How much can you tweak a snippet? Contrast that with the number of command line arguments for a framework like create-react-app.
• Opinionatedness There’s only so much opinion you can have for a small snippet. With a larger framework, there are design decisions which might not sit well with all people. This is also proportional to how passionate people revile or defend tools.

Boilerplates are, on the overall, a solution and not a problem but like all those, they come with compromises. These allow people to

• Speed up their development cycle with common best practices.
• Avoid common (sometimes expensive) mistakes. e.g. using OpenZeppelin rather than writing your own contracts avoids several security problems that are important for custom tokens.
• Done right, a tool can generate just enough code to solve your problem without taking away any power. A reasonable example are parser generators like Ragel or Bison. You can work on the interesting parts and leave the boring bits to the computer

So, on the overall, I think tools like these are necessary as well as useful. It’s not right to think of them as “problems”.

Language community

Another thing that has a bearing on this whole is the size and nature of the users and developers of the language.

It’s highly unlikely that a toy language I designed in my own room on a dark night has people complaining about how the tooling for it is sub optimal. On the other hand, I’d bet good money that there’s an argument brewing right now about whether you should use Next.js or nwb or whatever else is popular right now on some forum on the internet.

There are two kinds of languages. The ones that no one uses and the ones that everyone complains about.

Large user bases expose a large number of itches. Itchy programmers with an editor and an internet connection will scratch out solutions and put them online. Most of them will be emotionally invested into their own solutions. The end result of this will be, unsurprisingly, a large number of incompatible tools to do the same or similar tasks. To summarize,

high popularity => lots of itches => lots of tools(scratchers)

This is far from an ideal situation and as far as I can see, there are three ways to prevent this.

1. One is to reduce the popularity. A smaller, narrower community (e.g. R is targeted towards statisticians , Haskell requires some amount of mathematical interest to truly enjoy etc.). Most developers wouldn’t want to do this since they want their tools to be popular.
2. The second is to build the language in a way that reduces itches. This is exemplified by modern languages like Go which solved the package management and formatting problems by including tools for these in the standard language toolchain. Contrast that with Python where package management was added later to the language and which resulted in a large number of tools that do similar tasks. To be fair, this was a language from a different time and Go, Rust etc. had the experience of Python, Javascript etc. to draw from.
3. A third way is to implement standards so that even if multiple tools exist, they can work nicely with each other and people can use what they want. This is easier said than done and in the real world, standards follow implementations rather than the other way round.

Javascript is a little special in this spectrum. For two reasons.

1. It was originally a small language used only for the occasional bells and whistles on websites. There were no “front end developers”. With the advent of NodeJs, they suddenly got a large number of developers in a single shot. Applications, Frameworks, Tools etc. all of them exploded. In short, *sudden* popularity.
2. There are (or atleast were) no options other than Javascript for front end development. You could just decide to use Perl instead of PHP for your application because you felt like it but you were forced to use Javascript.

Another relevant factor is that since the whole ecosystem wasn’t really “engineered” but sort of organically mushroomed due to several events, there were many holes in it. I think this triggered the Inferior is Better phenomenon which allowed people to participate and the popularity to increase at the cost of creating several (some non compatible) tools.

Analysis

All this being said, the question is whether this is a “bad thing”. I don’t think there’s an objective answer here. Some people like a polished smooth experience without any choice. Some people prefer a highly configurable, always tweakable environment that they can go on making their own.

A second point is whether it needs to be “fixed”? On the question of boilerplates, there’s no fixing that needs to be done. It’s a genuine solution for genuine problem and over the years has done much more good than harm. On the question of popularity, there are some fights than can be avoided easily by careful planning and engineering. A good example is rolling in common tools into the standard distribution of a language so that many of these problems are gone. In other words, it’s an ongoing evolution and while we might not reach the ideal solution, we’ll definitely get better. The poorer tools will fall away due to lack of popularity and the good ones will surface to the top and take over. Just like how git is more or less the “standard” version control tool now.

My final thought is that this is a human problem and not one that can be solved through technology. Decisions of which tool should be used depend on what the developers are comfortable with, whether there is legacy code in the system, how active the development of the tools under consideration are. As for Sidu’s original concern, there are always other tools which are better failing which it’s an itch that needs to be scratched. 😉

---

Take advantage of our experience with all of these frameworks and more if you want to quickly build out your own products within budget and without delays. We at Hamon embrace the philosophy of “strong opinions weakly held” when we help our clients build out their software. Drop us an email at contact@hamon.in. We’d be glad to help you out with your requirements.

Much thanks to @Swanand for reviewing a draft of this post and offering suggestions.