A lot of people are complaining now about how chaotic the state of JavaScript is, how the ecosystem expands, how there are different solutions to a problem, and how none of them seem to be a community standard. When it comes to UI frameworks, there are more than a dozen: Popular frameworks like React Angular, Vue. Js and Svelte, as well as Inferno, pReact, Riot, Polymer, Aurelia, Ember, Knockout, Mithril, Dojo, and more.

Packing tools? CSS framework? CSS – in – JS tool? Package manager? Testing frameworks? Many concepts flourish: SPA, SSR, Ant, microfront-end…

Fifteen years ago, the web was not as rigorous as today’s platforms. They come from a time in history when JavaScript was just a toy manipulating DOM nodes and making AJAX requests. If you know how to animate a checkerboard using Vanilla JS, you’re a cool kid. JQuery took off in 2006, simplifying the workflow so much that there was no need to make more demands on JavaScript.

This isn’t just a framework problem; JavaScript itself has a lot of problems. The lack of a type system is bad, type coercion is strange, and the existence of undefined and NULL is confusing. So much so that some developers decided to stop using NULL altogether, and the list goes on and on.

Douglas Crockford famously wrote JavaScript: The Good Parts, which is an important learning resource for many experienced JavaScript engineers. The book becomes part of the famous picture below, which shows a clear message: only a subset of the entire JavaScript is “good”.

But there is one thing that many people tend to forget.

JavaScript is 26 years old

In 1995 Brendan Eich from Netscape developed a Java-inspired language in just 10 days. It was named LiveScript, Mocha, and finally JavaScript.

The language was then embedded in the Netscape browser, and Microsoft designed its own JScript language (an implementation of the ECMA specification) for Internet Explorer, entering the browser market as Netscape’s first real competitor.

This was the beginning of Internet Explorer (affectionately known as IE, or Internet Eradicator), whose nightmare culminated in version 7, when we had to write IE specific code for the project. Firefox and Opera entered the infamous browser wars in 2007, and Chrome came out a year later.

Still, the Web is not waiting for the war to end. Many enhancements will be added to JavaScript, and the ECMA Committee has a mandate: don’t break the Web. To this day, no other language has lasted as long as JavaScript.

It took JavaScript nearly 10 years from its inception to become a powerful language, embedding client-server communication and providing a rich dynamic experience on the Web. This was the peak of jQuery and Dojo, which naturally attracted the SPA model with Backbone and Ember.

As technology evolves, there is a need for the Web to keep up, both functionally and aesthetically. JavaScript is essentially the dynamic client language of the Web, and so far has no competition. But it must accept its flaws and move towards more modern designs. Applications become heavier and more complex, and JavaScript is no longer a toy.

This led to the creation of JavaScript supersets called C offeeScript and TypeScript, the latter of which is now the market winner. Introducing types into JavaScript can significantly enhance maintainability and simplify collaboration. But it added a build step to the process that wasn’t part of the JavaScript toolkit at the time.

Here comes the big player, the one who will change everything: Node.js. NPM followed a few years later, finally addressing a common problem with every programming language: dependency management. This evolution represents a huge shift in Web client development.

As you can see, JavaScript has a huge background that you can’t get rid of or the Web will crash. The committee also had no choice but to keep most of the content, while adding new features to fill in the gaps. ECMAScript 2015 (ECMA 6.0) introduces class syntax to JavaScript, Then ECMAScript 2016 (ECMA 7.0) and ECMAScript 2017 (ECMA 8.0) added piomise, generators, async/await to JavaScript.

The legacy of JavaScript cannot be changed without incalculable consequences. There’s nothing we can do about it. JavaScript is destined to retain its old flaws.

The good news: Avoiding them is easy.

The pain of JavaScript being overrated

There’s a lot of talk on Twitter about weird coercion, floating point errors, undefined actually being two values (either the property doesn’t exist, or the property does exist but isn’t defined).

But it doesn’t stop there, and all of these shortcomings are notoriously bad. But as a beginner, how many of us have actually suffered from floating point conversions? Most problems affect only a small number of developers. Solve the coercion problem by adding another equal sign, using strict equations, and eliminating coercion altogether.

Developers really shouldn’t have to struggle with language flaws, but unfortunately, that’s just the way it is. However, as far as my work is concerned, I haven’t had a problem with the language itself, all it takes is to avoid the bad parts. JavaScript is fun and I’ll even say something that might offend purists: I have fun programming in JavaScript. First of all, I am a C language programmer. Compared to JavaScript, the language is simpler (not easier), but much less interactive. I also do a lot of PHP, and even today the language’s structure is not as elegant as JavaScript’s: passing callbacks, using promises, linking methods on arrays, all of which are big no-nos in traditional PHP.

But in JavaScript, with its integrated garbage collector, everything is made simple:

  • No need to manage IO buffers (read files, sockets, pipes…) , the string is automatically expanded as needed;
  • It is a single-threaded language with event loops, so knowledge of thread synchronization and communication is not required (unless you make a multi-process Node.js application);
  • Concurrent programming in JavaScript is much easier than in a multithreaded environment;
  • You don’t even need to know anything about stack allocation;
  • It is possible to link method calls (successive calls), although this is less common when dealing with arrays and more often used on objects.
  • The constructs JavaScript allows (links, callbacks, promises, and functional programming) make it easy to write elegant code.

All of these features are not necessarily unique to JavaScript, but they are fun to use. If you carefully apply the principles of programming style, such as SOLID principles or GoF design patterns, coupled with the functional programming paradigm and an understanding of JavaScript quirks, you pave the way for maintainability. I firmly believe that the single most important factor for developer happiness is still the convenience of working on an existing code base, because that’s something we deal with every day. Are we tired of it?

We have a lot of frameworks, and they all do more or less the same thing, though not differently. These choices paralyze many of us because at work we need time to evaluate how well a tool is performing. We have choices, like giving a baby multiple toys to play with. That’s how innovation drives it.

We don’t have to learn every framework and every tool involved. For the last four years, I’ve mostly used React, Angular, vue.js, and a little Svelte. I know enough Webpack and Babel to make my application work, and that’s enough.

It makes more sense to learn the principles and concepts of the tool than to use it.

JavaScript is not what it used to be

JavaScript is no longer a toy to be laughed at. It is providing rich interactions for every web site that are now commonplace.

Sure, JavaScript has its flaws, and it’s not going to get rid of them anytime soon. Fortunately, with a little care, it’s easy to avoid these problems.

Yes, there are lots of frameworks, and every now and then a new one comes along, and we’re told repeatedly to stay up to date. But how many major breakthroughs have taken place in the past decade?

A few examples: Angular (SPA), Babel (Transpiler), React (declarative SPA), Webpack (packaging), Svelte (statically generated site), and JAM Stack, React-Native/NativeScript (JS for building Native applications).

Most frameworks and libraries revolve around more or less the same idea, which of course takes time to master, but once learned, the knowledge can be used with other tools without needing to be relearned.

In the meantime, some people are still using jQuery and happy with it. The men did not seem exhausted from fatigue.

JavaScript is not what it used to be. It’s grown up, but it’s not mature yet.

By Anthony Cyrille

Translator: CUGGZ

Original text: javascript. Plainenglish. IO/javascript -…