The future of JavaScript for the frontend

Ryan Kuruppu
Ascentic Technology
7 min readAug 24, 2021

Ah JavaScript. The battle-scarred, most popular solution for almost all frontend development.

JavaScript has been the main choice for almost every frontend developer on the web and with Node.js on the server-side, it’s now a viable option for both frontend and backend development.

From libraries like React and Svelte to frameworks like Angular and Vue, developing for the Web to developing for mobile, the JavaScript ecosystem spread’s far and wide. With nearly infinite possibilities if you’re creative enough.

But the question remains.

How long can we rely on JavaScript to build User Interfaces?

It’s a given that JavaScript alongside other helper libraries are tried and tested ways in providing efficient and performant frontends and frankly with the number of Junior Developers flooding into the world of JavaScript, there’s no doubt there’d be an abundance of capable developers in the pool to pick and choose from.

But here’s where the problem starts.

Lets get something straight. I love JavaScript through and through but even I have to admit that JavaScript is getting more saturated everyday and by that I mean it’s just getting more boring by the second.

TypeScript is slowly becoming a flat out replacement for JS in my opinion and more and more people switch to TypeScript due to the lack of options available in JavaScript which make it difficult to work with at times. This is partly the reason why JavaScript alone is essentially considered inelegant, inefficient, unstructured, buggy and hard to write well.

From head to toe, JavaScript is a living nightmare behind the scenes. Part of it contains internal logic that leads to unpredictable outcomes by design but the other part of it is that ultimately that doesn’t matter as long as you know how to use it.

JavaScript is also very unstructured and unopinionated. Any developer can come into the language, write anything anywhere in the correct syntax and bam!! If you coded it right, it works. The issue here is that it leads to more problems than solutions down the line. Your developers NEED to know the best practices before hand unlike in other languages like Java, Dart or C# where the architecture is more defined since there are systems available to enforce that structure. The only tools that can help enforce best practices are the community driven Linters.

And finally, JavaScript is very loosely typed. This means you could declare a variable and it could essentially be of any type at compile time(but then again this is the whole idea behind a loosely typed language).

Essentially you could do this,

And JavaScript won’t complain. In other languages this would be a problem. Usually in languages like Python for example, the maintainers of Python introduced type hinting which is essentially a way of using Static Types even though Python itself is loosely typed like JavaScript.

But JavaScript doesn’t have this and then the problem of “Silent Errors” rises which is when JavaScript won’t complain about the problem during compile time but it will during execution and you still won’t know until you go and manually check your browser’s console.

So as a developer in JavaScript, this can be very very frustrating and annoying since all you’ll see is a white screen or your UI with literally no changes.

Overall JavaScript is flexible by default but it’s that flexibility that makes it so frustrating at times. But then again. This is just one side of the whole view, so there are obviously going to be more things to talk about but I’ll leave it to that enthusiastic mind of yours to find out more

You go getter.

Okay moving on…

Node Package Manager (NPM)

The NPM repository is the biggest collection of libraries in the developer world with over 1 MILLION libraries available at the time of writing. It is large and part the reason why building applications in JavaScript has become easier over time.

Even with frameworks like Angular or React, they both require dependencies from the NPM repositories in order to work themselves and as such this shows the huge amount of reliance on the NPM repositories.

Kudos to NPM for providing every developer in Node this wide array of packages and services.

But because there are so many packages, it’s near impossible to curate and check every single one that gets published into the massive repository and this leads to all sorts of problems like packages filled with Malware, horribly optimized libraries and packages with no details about the functionality of their libraries which may execute rather shady code in the background.

Put yourself in the shoes of a Junior or even a Senior Developer and you understand how big of a problem this is. The heavy reliance on npm and yarn opens up possibilities for all sorts of problems.

Deno, a Secure runtime environment for TypeScript and JavaScript created by Node’s own creator Ryan Dhal, is solving this issue where instead of relying on NPM, it resorts to using URL’s provided by the creators of these libraries which can only access certain features of your app if and only if you allow it to through Deno’s security measures which disable networks, storage and other services by default.

So what are our alternatives ?

Right now. There are 2 main competitors as far as I’m concerned.

  1. Flutter for Web
  2. Web Assembly (WASM)

Flutter

Flutter Logo

Flutter is a library for building native applications with a single codebase and it has been a raging topic since it was released with the ability to convert Dart Code (The language flutter is written in) to Native Code faster and more efficiently than any other available option out there. Flutter for web is fairly new but promises the same feature set of that being made for mobile. With the set of amazingly simple Widgets already provided for mobile development, there’s no doubt that when Flutter makes itself known in the world of web development, it will prove to be a force to reckon with.

Flutter is a crazy interesting topic with a heavy love for Google’s Material Design and considering its being driven by Google of all companies there’s a lot of development R&D that will be put into it in the near future and hopefully it doesn’t become one of Google’s disbanded projects.

If you wanna see the stuff that google has killed in the past few decades,

Check out the Google Graveyard — Killed by Google

WASM — Web Assembly

This one is gaining some rapid traction with some calling it the future of web development. It technically allows you to write client side code with languages such as C# or Rust and run it on the web in a way that wasn’t possible until now. WebAssembly according to the MDN (Mozilla Developer Network) is

“ designed to complement and run alongside JavaScript ” — MDN

But its more or less a gateway to writing Web Applications using an array of different languages. The reason WebAssembly is so popular however isn’t because of its ability to use any language you like for development (although that’s a definitive talking point). It’s actually due to its ability to bring near native performance through a web application after writing the application in something crazy like COBOL for example (also with stuff like C#, JS and Rust etc.)

So JavaScript definitely has some competition but

Credit where credit is due 👏👏

Despite everything I said about JavaScript Frameworks before. It’s still the driving force behind frontend development and will continue to be for many years to come especially with new concepts like the JAMStack being built on top of JavaScript.

Saying that, React, Angular, Vue to name the more popular few, have provided massive advantages when developing our web applications and frankly without them we’d just be writing a bunch of duplicate HTML and CSS everywhere. So I’m thankful. With all these considered they’re also the reason behind the massive community behind frontend web development and is partly the reason so many of these helper libraries exist in the first place. There’s so much developer support out there for JavaScript so it doesn’t seem like it’ll slowing down anytime soon either.

So like the title says, credit where credit is due and I hope that JavaScript can get its act together and possibly get progressively better over time.

What are your thoughts ? Share them below 😀

--

--