What’s In The Future For JavaScript?
The predictions of a software developer who’s seen the language evolve for the past 17 years. What’s in our near future and what will happen 20 or more years from now?
JavaScript is everywhere these days, and I’m not just talking about front-end (browsers) vs back-end (Node and Deno), I’m talking mobile, desktop and even hybrid apps as well. This has led it to become one of the most wanted job skills of 2020 (at least according to StackOverflow’s developer survey).
But why is that? And what does it mean for the future of JavaScript? Is it going to be smooth sailing from here on out? Will we see the birth of a newer and better language that will topple its omnipresence? Let us explore the possibilities.
What makes JavaScript so popular?
Whether you love it or hate it, JavaScript is popular, that’s a fact, you can check TIOBE’s popularity index where you’ll find it in the Top10 languages, currently sitting in 7th place:
And it is the #1 most popular technology according to StackOverflow’s 2020 Developer survey:
These are not random numbers or biased polls, they’re analyzing our market and polling millions of developers worldwide, and everything is pointing towards JavaScript being one of the Top languages of 2020, why do you think that is?
Granted, that question can probably be answered in many different ways, depending mainly on what you consider important when it comes to picking a technology, but here is my take at it:
- A big community behind it: There are numerous jokes around the fact that there are probably more JavaScript frameworks out there than actually developers using them. Although it might be an exaggeration (notice how I said “might” here), it is born out of the fact that there are so many of us out there, trying to make the language our own, that the contributions are overwhelming. This is not a bad thing, this is proof of a community that is filled with life and constantly trying to evolve. One thing I really miss when I have to use other languages is the amount of support and help from the community you can get (in the form of tutorials, articles, SO questions and even tools and frameworks). This is definitely a sign of a movement that is not yet done and wants to achieve a lot more in the future.
- A proper way of evolving: Leaving frameworks and libraries aside, the language itself is constantly evolving. Thankfully though, this evolution is not controlled by a single entity. Actually, lets clarify: although JavaScript itself (the term) is owned by Oracle, the language is meant to follow the specifications of ECMAScript. And these specifications are in fact, controlled indirectly by the community itself, and regulated and organized by the TC39 committee. They review all the different proposals to evolve the language, and work with them until they’re mature enough. Once they are, then it’s up to runtime owners to implement those updates if they want to stay compliant. This hasn’t always been the case, backup 10 years and you had the browser’s war to see which one had the most “interesting” version of JS and you as a developer had to try and stay within the realm of compatibility and standards because you wanted your code to be bross-browser compatible. This is not the case anymore, lucky for everyone, all runtimes are trying to stay up-to-date with the latest version of ECMAScript.
- An incredibly alive ecosystem: Kind-of related to the first point, there is so much work being done by the community that is hard not to mention it. There are more front-end frameworks to try than actual time to learn them all. There are literally millions of modules shared in NPM, every day. This on one side makes a lot of noise for people who’re just trying to get started with the technology, but at the same time, allow for more people to join, since the different frameworks and modules end up doing the same thing, just in a different ways. And those different approaches help resonate with more individual developers. After all, React, Vue and Angular will help you create the same app, you just need to pick the one that you prefer.
So how do you see the future of JavaScript, considering what it was a few years ago and seeing how it has evolved overtime?
That is definitely a hard question to answer, but let me give you my impressions.
The Near Future
The language has been slowly evolving already over the past few years. If you’re new to JavaScript maybe you’ve not noticed it, but there was a huge jump from ECMAScript 5 to version 6 and a lot is happening in future versions as well. Here I’ll mentioned a couple of points I think are relevant and could potentially happen in the near future, meaning: continuing the current path and evolution rate it has now.
JavaScript as a Target Language
Even with the amazing community JavaScript has, and the immense amount of work being put into providing tools and frameworks for developers, there is still a huge portion of that group that plain hates JavaScript.
Yeah, you read that right, they hate it, or at least they don’t like a big chunk of it and think they can make it better. Thus, projects such as CoffeeScript (back in the day) and later Dart and now TypeScript have been created.
This is not bad, in fact, this is a very interesting opportunity for JavaScript to not only be widely used directly by developers all around the world, but also to be the target language of a lot of transpiler creators, trying to give other options to developers out there.
Essentially this movement would open the door to JavaScript of a huge different universe. Since Node.js entered the market and became popular, JavaScript stopped being “the front-end language” and allowed companies to simplify their tech stack having a single language across their domain. Think what would happen if you could do that with Python or Ruby as well? This is not such as crazy idea, there have been projects in the past trying to achieve it, we might just need more time playing around with the idea before we like it.
The problem with front-end development (the only problem with it if you ask me) is that you need to learn JavaScript in order to be able to work on it. Which is completely opposite to the back-end world. Currently, browsers allow for only one language to be king and that is JavaScript, if you want more you’ll have to compile (or rather transpile) your code into it.
Yes there is also WebAssembly and if they have it more power and access to other areas such as the DOM it could very well dethrone JavaScript and become the new king, but right now it has a very narrow area where it might work: heavy computation on the front-end. It is a tool for performance, not a completely independent environment for front-end devs (yet at least).
Evolution By Example
Another interesting way JavaScript has evolved to the point it is now is by seeing what the community wants through the frameworks they develop. If you’ve been using JavaScript for a while now, since ECMAScript 5 specifically, you’ll probably remember libraries such as lodash and underscore.
These libraries were must-have for any project because of all the extra functionality they added to the language, with methods such as map , some , find , reduce, get, set, merge, and so on. While it is true that they still provide a great deal of functionality some of these capabilities have been slowly added to the language in recent updates.
ECMAScript 6 for example, added a lot of array methods giving them quite a boost. Optional chaining made the get method obsolete, or almost. The spread operator did the same for the merge method. And the list goes on. The more popular a functionality becomes, the TC39 committee will eventually try to incorporate it natively to the language.
Another clear example of this is how classes were introduced. JavaScript tried to live with prototypical inheritance in an Object Oriented world and failed. Either because there weren’t enough advocates for the model or because it wasn’t correctly documented, but so many developers tried to forced an OOP model on top of it that they eventually added a thin OOP layer on top of it. At first it was more cosmetic than anything, but it is slowly evolving into a more mature model with the addition of private fields in the near future. There is still a way to go, but this is another example of how the language is evolving, even against its original nature, by the mere force of how the community of developers is using it.
The last addition to this list is the Svelte framework, which is trying to bring the concept of reactivity into the language itself, unlike other frameworks, such as React (ironically if you ask me) which tries to instead, provide developers with workarounds to impose a concept that JavaScript is not yet ready for.
With Svelte, you can write code that looks like this:
This will render a button that when you click it, will update its label value. You can find an interactive example following their online tutorial here. This of course needs to be compiled into actual JavaScript at the moment, but how long do you reckon will take until behavior similar to this gets absorbed into the proper ECMAScript specification?
Modules++
Another aspect of the language that has been evolving since the days of JavaScript for IE6 (yes, I was there when we had to tailor our code to work on that thing some people called web browser) is the language’s module system.
At first, it could hardly be called that, but with time, we’ve made progress towards a more usable and developer friendly way of packaging our code in order to re-use it. This is key because re-usability is a major concept in software development. You don't want to have to re-invent the wheel every time you start a new project or even when you have to call the same function from two different places within the same project.
With that in mind, we’ve seen the rise of AMD’s module syntax, allowing us to use import and export statements to choose which functions get shared and which ones end up being private. There are other alternatives to this syntax, but AMD’s seems to be the one winning the standardization race so far.
This is a great stepping stone, but maybe we need more. Maybe we need to start thinking about not only sharing or re-using functions but whole modules. And the concept of a “module” can mean a lot of things, depending on your context. If you’re working on a piece of re-usable code for the front-end, you might have managed to modularized your buttons, but since they’re not just an abstract but rather a visual construct as well, you might want to make sure your code is always exported with the required CSS and HTML.
The same can apply for back-end development, you could potentially be designing a logging component to re-use across all your projects. But you’re trying to make sure a set of configurations and constants get exported with the business code.
JavaScript itself is not yet able to resolve this for us, so different solutions have been created to help in this regard. For back-end folks, we have NPM or even Yarn providing a centralized global repository and even the new Deno allowing to import externally distributed modules, automatically mapping and downloading dependencies. For front-end, however, the story is not exactly the same, some users have decided to go with NPM and Yarn as well (if you pay attention, you’ll find a lot of React, Angular and Vue components inside them).
At the same time, others have decided to create more focused solution such as Bit (Github), which provides a centralized repository geared towards the main front-end frameworks out there (React, Vue, Angular, and yes, just like NPM, you can use Bit for Node as well), considering how they all deal, at a high level, with the same concept of “components”. The fact that they’re geared towards front-end, means you can visualize their presentations, interact with them as opposed to just seeing their documentation and their code (which is essentially the only thing you can do with back-end modules).
However you choose to solve this issue right now, the point is that just like it’s done in the past with single functions, JavaScript (or the TC39 committee to be more precise) might decide to adopt this practice in the future, allowing us to maybe move from the concept of “module” towards “components” and letting us package them into a single files, which we could re-use from other projects.
I wouldn’t want to assume we’ll have an “official” repository from JS itself, but rather, a more elaborated spec for how these components might be defined and shared, leaving room for existing solutions (again, Deno, Bit, Node and the rest) to adapt and provide their own implementations of it.
The Far Future
Now we’re entering into the land of the unknown. It’s easier to predict what will happen in the near future based on current trends and past experience. But making the jump into the far future and thinking in decades maybe, that’s not as easy because other factors start playing an important role as well, such as unknown mediums being developed where JavaScript could play an important role such as holographic displays, artificial humans that could act as your assistant or teacher were announced a little while back, who knows what they’ll do, maybe we’ll see the rise of a JavaScript as a language for machines to use and expand their capabilities.
The far future is really up for grabs and it really depends on what we do now with the language. That will really shape it into its future version, and although it is hard to properly predict how that will look, let me take my shot at it. Mainly because its a fun thought exercise.
The JavaScript of 2040 and beyond will:
- Have native support for ML instructions. Given the raise of ML and how it is starting to permeate every aspect of our industry, I would assume such a popular language will have to adapt before being overthrown by a newer model (i.e a new language).
- Reactive and functional programming will play a bigger role in the design of the language. I predict we’ll have to go through our OOP phase, and eventually, we’ll see the benefits of the functional approach and how it ties so well with reactivity, natively speaking course.
- We might even start seeing hints of logical programming start showing up. Because we’re always trying to bring back old concepts and paradigms as if they were new, we’ll eventually see people trying to adapt it into JavaScript, following the normal routes (first through frameworks, then through native support).
- Native brain-machine interface available. This will eventually be like having access to the DOM API, only that it will allow you to read input from your brain and, probably, interact with whatever passes for DOM at the time. Essentially we’ll become a new input device, such as keyboards and mice. And this is not that far-fetched either, companies such as OpenBCI already provide Node.js SDKs to interact with their open source hardware allowing you to read the electrical activity of your brain. This is of course far from being main-stream tech, but we’re already well underway (and with JavaScript!).
And yes, I am assuming JavaScript will not disappear or be replaced by another language, specially when it comes to representational environments (i.e whatever passes as front-end in the future). This is mainly because logically speaking, it makes more sense to build new technology on top of older one, in order to avoid having to re-invent the wheel every time.
So even if you’re creating a brand new display technology, one that gives you more capabilities than our current ones, you’ll still want the current software to function in there (i.e you’ll want browsers to work on your holographic 3D display, even if at first, they’re just boring 2D windows). Which means you’ll have to add your new functionality on top of what you’re building on, instead of directly replacing it. Mind you, you could also do away with everything and start from scratch and bring on the next technological revolution without JavaScript, but the adoption rate by the industry you’re trying to break into might be a bit slower and harder than it would by slowing evolving existing tech.
Final Words
Well, that was fun, wasn’t it! Up until the last section, I think the article makes sense (at least to me), now for the far future predictions, who knows!? Maybe in a couple of decades, if Medium is still there we’ll come back to this story and we’ll either reflect on how visionary I was or just laugh at my lack of foresight. Either way, I would love to know what your thoughts are on the near and certainly the far future for this language.
Leave a comment down below sharing your own predictions and we’ll see how’s right in a decade or two! Have fun!
