Blog

What Does the Future of JavaScript Tools Look Like?

Placeholder Avatar
Arunan Skanthan
August 25, 2020

The Past

It seems like the dust has settled on the JS framework wars , and clear winners have seemingly emerged

The daily announcements of a new JS framework or tool has subsided and the industry has settled on more or less the popular options.

If someone asks me for my personal recommendation on which JS framework to learn, after having set up and used both in production apps‚ I would recommend React for professional development and Vue for a hobbyist.

Why React? Well for one, recent popular surveys by Stack Overflow and State of Javascript, seem to suggest React has been the most popular choice for a few years now.

It also seems to be the most hyped (for good or for worse) on my social media and work buddy circles‚ although this could be an echo chamber. Also, depending on where you live, if you search your local job search site, you are most likely to find more roles for React, rather than Vue or Angular.

Okay, so you’ve got React, what else did you need to learn? I suggest the basics of Node.js and Webpack for tooling, and then React Hooks or GraphQL, depending on [where you work or want to work].

It also looks like TypeScript is gaining more traction with a lot of projects using it. On top of these, if you’re responsible for setting up a project, you need to look at additional tools such as ESLint, Prettier, etc.

Then you have to learn about optimising your SPA for performance with code splitting, etc. Does that seem like a lot of things to learn? I sure think so. “Okay, fine, I’ll learn those things, but what about the future?” you say.

The Future?

There are some new tools being worked on that excite me. Not because they’re another shiny new tool to learn, but because they eliminate the need for some existing ones, especially the need to have multiple tools.

Deno

Deno is similar to Node.js, created by the same original author, Ryan Dahl, to fix existing issues with breaking changes. There are some security-by-default, backend related standard modules and performance features that differentiate it from Node.js.

But what excites me about Deno is the fact it uses ES modules, instead of CommonJS. That means they let you import paths or URLs to modules without needing the disk-space-grabbing node_modules folder.

Deno also tries to match Browser APIs unless it’s a non-browser feature, meaning there is less to learn.It also has TypeScript support built in, so you don’t need to set up a transpiler for that.

Rome

Rome is a Front-end toolchain. “Another one?” you ask. Yes, BUT, it consolidates many tools into a single one. “Wait, what?”

From their website:

Rome is a linter, compiler, bundler, and more for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.

Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Rome unifies functionality that has previously been separate tools. Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelising work, caching, and configuration.

Rome has strong conventions and aims to have minimal configuration. Read more about our project philosophy.

HUZZAH! ONE-TOOL-TO-LEARN! Minimal configuration. What’s not to LOVE?

Pika and Ispm

Remember when I mentioned that Deno lets you import files instead of the node_modules mess? Well Pika is trying to do that inside browsers. Rather than bundle and build libraries into one package, what if we could import them in-real-time in the browser itself? Pika and jspm are projects attempting to solve that problem. Of course there are caveats like not bundling increases latency. But this is exciting to me as it helps reduce bundling and optimising steps. Or at least I think it will.

The Present

Sadly, these tools are not necessarily complete, or production ready. So we may have to wait a few years for them to mature. Hopefully new people coming into Front-end development will have less tooling and optimising to worry about.

I cannot wait for the future to arrive sooner, rather than later!

Footnotes

1. Or is this just the calm before the storm?

2. Well, first I’d ask them if they really, really need a framework at all. These things solve specific problems and add a lot of complexity, which may not be needed.

3. See 2018 State of JavaScript survey for React use hotspots.

4. Personally, I’ve found Vue a lot more learnable, and better for beginners. You don’t need to start with a build system to learn it, and instead can drop in a script to the library‚ like we used to do back in the day when we’d only use jQuery. React touts the same capability but gives you warnings about non-production mode, and I’ve found it slowish without the build in place. This may have changed now.

5. I don’t like how Angular forces you to start off with TypeScript. It’s one more barrier to entry for newbies. I’m sure there are options to setting up without TypeScript, and ways around it, but the default “Getting started” tutorial is what drives these things IMHO.

6. I mention React Hooks apart from React as previously it was popular to use Redux, but you may not need that anymore

7. I recommend Webpack, GraphQL for the same reasons as React.