If you want to find out how the JavaScript ecosystem will evolve, it can be interesting to know which features and tools are most valued. So for each of the following features, I asked developers to pick the option that they felt applied best:

  • I don't know what that is
  • Not needed
  • Nice-to-have, but not important
  • Major feature
  • Vital feature

Server-Side Rendering

  • Percents
  • Numbers

The whole point of building JavaScript apps is to let the browser do the work, instead of requiring a round trip to the server every time you want to request new content.

But as it turns out, the server can have its own role to play, too. Server-side rendering lets you generate your markup on the server and send a fully formed page to the client to speed up that critical first load, and it's also useful for SEO and accessibility.

That being said, server-side rendering is most critical for public-facing sites (like this one!), rather than apps that sit behind a log-in screen for which SEO isn't such a big worry. Which might explain why most developers only see it as a nice-to-have.

Code Splitting

  • Percents
  • Numbers

Despite the language's decades-long history, the art of building JavaScript apps is still in its infancy. And one of the consequences is that a lot of us are still sending monolithic app bundles to the client.

Code splitting aims to change that by splitting up your codebase and only sending the features that are actually needed at any given point. In other words, it lets you avoid loading the code for your admin features for every single regular user.

The big performance gains associated with this technique probably explain its popularity.

Optimistic Updates

  • Percents
  • Numbers

A lot of the complexity of JavaScript apps come from handling client-server interactions, and this pattern is a perfect example of this.

Rather than wait for the server whenever the client performs an operation, optimistic updates let you simulate the result on the client and display it immediately, fixing any conflicts later on in case the server operation ends up returning a different answer.

While nice in theory, the complexities involved in setting this up properly with most frameworks make it a relatively low-popularity feature.

Hot Module Reloading

  • Percents
  • Numbers

Hot module reloading means being able to see any changes to your code reflected in your browser instantly, without having to refresh the page.

And while this feature is strictly limited to the developer experience, it makes it so much better that you can understand why so many consider it a major feature.

Time-Travel Debugging

  • Percents
  • Numbers

With better state management tools such as Redux coming out, new coding and debugging patterns are emerging as well.

Time-travel debugging takes advantage of the fact that Redux stores the successive states of your app to let you "travel" through them, simulating infinite undos and redos.

As more developers embrace these new state management libraries, I expect this technique will become more and more popular.

Real-Time Operations

  • Percents
  • Numbers

We've come a long way since the web's origins as a collection of static images and text.

These days, with modern browsers and broadband speeds, you can almost envision a world where real-time becomes the default, rather than a premium feature.

We're not quite there yet, but with major sites like Facebook leading the way and getting us used to instant-everything, we might get there sooner than we think.

Dead Code Elimination

  • Percents
  • Numbers

While code splitting lets you split up your file and only send out the parts that are needed, dead code elimination goes one step further and digs into your codebase to remove unneeded code altogether.

Now, instead of importing the entire Underscore library, you can have a tool like Rollup go through the Underscore code and get rid of any function you're not actually using before bundling the whole thing up.

Progressive Enhancement

  • Percents
  • Numbers

With all this talk of fancy JavaScript features, it's easy to forget that not everybody benefits from them.

And no need to travel to faraway lands here: just whip out your brand new, state-of-the-art phone and many sites and apps become unusable due to bloat, incompatibilities, and crappy mobile connectins.

This is why progressive enhancement is still important: it's about making sure your app can be used in as many situations as possible, without sacrificing what made it worth using in the first place.

Highest-Rated Features

So what do we get if we average out all the ratings and rank features by how useful they were deemed?

Unexpectedly, code splitting and dead code elimination lead the pack, which is surprising given that these two features are not yet very widespread. But being forced to serve oversized bundles feels a bit like being given too much food at the restaurant, so I can understand why developers would welcome any tool that lets them make their apps less wasteful.

Hot module reloading also got a comparatively high score despite not having any impact on the user experience, which again shows just how much of a game changer it is when it comes to speeding up your workflow.

Finally, optimistic updates and time-travel debugging both suffer from being somewhat complex, misunderstood features with low awareness. It'll be interesting to keep an eye on them and see how their rating evolves in future editions of this survey.

Other Features

Here are some of the other features frequently mentioned:

Offline Usage

What happens to our apps when the user's Internet connection goes down? Do we know? Do we even care?

It can be tempting to dismiss this as an unsolvable edge case, but there's a growing awareness that maybe we shouldn't, as shown by the fact that offline access was by far the most frequently mentioned other feature (23 mentions).

Any app that might conceivably be used from a smartphone should account for the possibility of disconnects, reconnects, and the offline use and data syncing issues that they entail.

Service Workers

Service workers (11 mentions) are instrumental in implementing the offline capabilities mentioned above.

Even though browser support is currently still lacking, 2017 might very well be the year when service workers start seeing more widespread usage.

Static Type System

JavaScript may not have a static type system, but that doesn't mean you can't give it one. Angular 2's adoption of TypeScript and projects like Flow are a big indicator that strong type systems (11 mentions) are considered by many to be a welcome addition to JavaScript.


Accessibility (10 mentions) is too often one of the first casualties when new, unfamiliar technologies are introduced. After all, it can be hard to find the time to make your app accessible when you're already days behind schedule.

That's why it's great when frameworks can offer tools to help you nail accessibility right from the start.

Isomorphic Architecture

“Isomorphic Architecture” (3 mentions) is a fancy way of saying you should be able to share code between client and server.

The biggest challenge of building JavaScript apps is managing the client/server split, so it makes sense that you'd want to share the same language and code across both environments to minimize complexity and context switching.

This is not always straightforward though: even though some frameworks like Meteor make this one of their core tenets, it's not always easy to know how to draw the line and decide what should go where.