3 JavaScript Libraries to Keep an Eye on in 2017

By Tim Severien

3 JavaScript Libraries to Keep an Eye on in 2017 was peer reviewed by Aurelio de Rosa and Vildan Softic. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

Signpost pointing back to 2015/2016 and ahead into 2017

Phew, 2016 is over! It was a crazy year for both the world and JavaScript land. Countless new impressive libraries and frameworks popped up, You Might Not Need JavaScript showed some patterns that made many question their use of JavaScript (a little) and one tweet of a slide from Nolan Lawson’s talk on Fronteers caused some commotion and responses from great names like Jeremy Keith and Christian Heilmann, all summarized in a post by Nolan. I’m starting to think “crazy” is an understatement. 2016 was insane.

This year also included JavaScript fatigue. In case you missed it, many developers are experiencing fatigue over JavaScript’s ecosystem, as a lot of tooling and configuring is required to set up a “modern” JavaScript project. At one point, so many developers had shared their thoughts that a few more articles surfaced on “JavaScript fatigue fatigue”!

To help both you and me sleep at night, I have a compiled a list of 3 promising generic libraries/frameworks for front-end development.


If you weren’t keeping an eye on Vue.js already, you definitely should. Vue.js is a tiny JavaScript framework.

No, don’t run away!

Vue.js seems to primarily focus on views and give you only a handful of tools to regulate data for those views. Instead of a framework stuffed with programming design patterns and limitations, Vue.js’ minimal approach doesn’t get in the way, which is nice for a change.

Vue.js comes in two flavors: a stand-alone version that includes the template compiler and the runtime version that doesn’t. In pretty much all cases, you will want to precompile the templates using Webpack or Browserify, and only load the runtime package client-side. See Vue.js’ installation page for more info.

To demonstrate its simplicity, below is an example of a component that shows a message and adds interactivity to a button to reverse the message.

<div id="app">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">Reverse Message</button>
import Vue from 'vue'

new Vue({
  el: '#app',
  data: {
    message: 'Hello World!',
  methods: {
    reverseMessage: function () {
      const reversedMessage = this.message

      this.message = reversedMessage;

Do you miss features you really enjoyed from other libraries? Many plugins for Vue.js are available, and several guides are available to use and write a Vue.js plugin.

You should definitely try this framework if you want to get productive fast. It scales well as the project grows. It is worth mentioning this library is maintained by one person with the help of generous contributors and sponsors.

Regardless whether you choose the stand-alone or runtime flavor, Vue.js supports ES5-compliant browsers by default. Although not documented, I am sure you can increase support by manually adding an ES5 shim.

For more information, check out Vue.js website or its GitHub repository. If you’re interested, be sure to check out Nilson Jacques’ editorial on Vue.js and Jack Franklin’s introduction to Vue.js 2.0.


Having only been released in mid-November 2016, Svelte is really new. It is a JavaScript framework similar to Vue.js but leaves a smaller footprint. “Traditional” frameworks need runtime code to define and execute modules, keeps state, update the views and do whatever frameworks do. Svelte dissolves into clean JavaScript code as if you didn’t use a framework at all. The major benefit of this is file size.

The framework is actually a tool that compiles your source code to plain JavaScript that doesn’t have dependencies. Svelte has plugins so you can compile the source code using Webpack, Browserify, Rollup or Gulp. Check out the compiler’s repository for all available tools.

For comparison, I’ve recreated the Vue.js example with Svelte:

<p>{{ message }}</p>
<button on:click="reverseMessage()">Reverse Message</button>

export default {
  data () {
    return {
      message: 'Hello World!',
  methods: {
    reverseMessage () {
      const reversedMessage = this.get('message')

        message: reversedMessage,

The very same module created with Vue.js produces a 7kb bundle. Svelte produces a 2kb file.

The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison, React plus ReactDOM without any app code weighs about 45kb zipped.

A js-framework-benchmark test proves Svelte competes with Inferno in terms of performance. You should definitely give this a try if care about your application’s footprint.

If you’re considering using this in production, I advise you to wait a little longer. The framework is really new and no future plans are announced, except for the TODO’s in the documentation which seem to refer the documentation itself and plugins. Despite being super new and not battle-tested, I expect this to gain some traction next year and might influence libraries and/or frameworks yet to come.

At the time of writing, Svelte either doesn’t have its plugin system documented, or doesn’t have one at all. The TODO indicates that Svelte will support plugins and might have an API to hook into the framework.

The compatibility of the compiled code depends on your build workflow stack, so it’s hard to say what its default compatibility is. Technically you should be able to achieve pre-ES5 support by including ES5 shims.

For more information, check out Svelte’s website or its GitHub repository.


Last but not least, Conditioner.js. With Conditioner.js, you can conditionally load and invoke modules. The difference from other module loaders is that Conditioner.js allows you define conditions under which to load and/or show a module. This allows you to reduce loading time and save bandwidth.

Built with Progressive Enhancement in mind, Conditioner.js suggests you should already have functional components in place that are enhanced with a given JavaScript module. How those modules are defined is entirely up to you. You could even make it load modules from your favorite framework.

The library doesn’t expose a global variable and recommends using an AMD loader such as RequireJS. It is compatible with Browserify, Webpack, Rollup and other AMD bundlers, but you will want to create tiny bundles so Conditioner.js can only load the modules the page needs.

To get started, you can install it via npm: npm install conditioner-js. More info can be found on the project’s homepage.

This demo is unlike previous ones to better illustrate Conditioner.js’ features. Imagine we wish to show the time remaining to an event. A module for that could look like this:

import moment from 'moment';

export default class RelativeTime {
   * Enhance given element to show relative time.
   * @param {HTMLElement} element - The element to enhance.
  constructor(element) {
    this.startTime = moment(element.datetime);

    // Update every second
    setInterval(() => this.update(), 1000);

   * Update displayed relative time.
  update() {
    element.innerHTML = this.startDate.toNow();

Initializing this module is as simple as:

<time datetime="2017-01-01" data-module="ui/RelativeTime">2017</time>

Conditioner will then load the ui/RelativeTime module at this location in the DOM. Note the content is already present and in an acceptable format and the module only enhances that.

If you want a module to initialize only when it’s visible to a user, you can do so with conditions:

<!-- Show RelativeTime only if it is visible to the user -->
<time datetime="2017-01-01" data-module="ui/RelativeTime" data-conditions="element:{visible}">2017</time>
<!-- Keep showing RelativeTime after it was visible to the user -->
<time datetime="2017-01-01" data-module="ui/RelativeTime" data-conditions="element:{was visible}">2017</time>

Conditioner.js has quite an extensive list of monitors, which you use to define conditions. Don’t fret! You only have to include those you need, preventing the inclusion of unnecessary code.

You can also pass along options as a JSON string or a slightly more readable JSON variant.

<!-- JSON variant -->
<div data-module="ui/RelativeTime" data-options='unit:"seconds"'>...</div>
<!-- Or good old JSON -->
<div data-module="ui/RelativeTime" data-options='{"unit":"seconds"}'>...</div>

The reasons to use or avoid Conditioner.js are similar to Svelte: if you care about your application’s footprint, you should definitely consider using this library. On the other hand, the future of the library is unclear as no future plans have been announced. Conditioner.js lets you define custom monitors, allowing you to make it work for all complex module loading.

By default, Conditioner.js is compatible with browsers that support ES5. Much like Vue.js and Svelte, better compatibility can be achieved using specific ES5 shims.

For more information, check out Conditioner.js’ website or its GitHub repository.


I think these frameworks and library are going to be great in 2017. Although not a fan of frameworks, I believe both Vue.js and Svelte are taking steps in the right direction to solve problems that exist in current frameworks, possibly causing the industry to shift towards new ways of building or defining things. Any improvement is a change I look forward to.

I am under the impression that building applications in a component-based fashion is considered the way to go. Although I don’t expect a major shift to be caused by Conditioner.js, it certainly solves problems that I believe are fairly common in component-based applications, making it a great addition for more complex loading.

What libraries do you expect to be great in 2017? Please let us know your thoughts in the comments section!

  • Rasmus Schultz

    I’ve been playing with Svelte (in the REPL on the site) tonight, and this looks extremely promising! For something this new, it’s already extremely useful – definitely something I will be keeping an eye on.

    It’s not strictly 100% true that it “dissolves into clean JavaScript code as if you didn’t use a framework at all” – what it’s actually doing (for the most part) is linking (parts of, as needed) a small library of extremely small run-time functions into the output file. While this approach certainly has merit, it’s not radically different from what you’d get if you were to do the same with rollup.js, e.g. bundling only the functions from the run-time library that were actually in use. At the scale of hundreds of components, that approach (strictly speaking) could become sub-optimal, since you’d end up with a net 100 copies of many of the same run-time functions.

    I don’t know if there’s an option to omit the embedded run-times and import them from a common run-time or not. As said though, this approach does have merit – if there’s a breaking change to any of these run-times, it won’t matter, because each component has a built-in copy of the version it needs. Again though, the same would be true if the application had been built with rollup.js where this could have been done optimally, e.g. with two copies of the same function if there are two different versions, and each component would effectively import the version it needs.

    Either way, the Svelte approach, for the large majority of all use-cases (e.g. small to medium size apps) is probably very much preferable to the situation with frameworks like Angular, React, Vue, etc. where you have this big external dependency you have to download first – Svelte is definitely an extremely viable option, especially for apps that target mobiles. I’m pretty excited to see where this goes :-)

    • Tom Conlon

      plus the author of Svelte also created Rollup and Buble so he knows what he is doing. Find it not quite as elegant as Vue but given it’s at an early stage, refinements might change this a little – it feels very lightweight and am also very interested to see its progress

    • Tim Severien

      I’ll agree that it’s not strictly true, but I still stand by my statement though. For traditional frameworks, a bundler prepends its bundle to yours, and your code still communicates with that. Even after compilation, you can still speak of two separate pieces of code. Although Svelte indeed prepends its utility functions, it is hard to tell the compiled code contains a framework, so it’s still _as if_ you haven’t used a framework as all ;)

      Anyway, I’m positive Svelte is able to avoid including the same utility function several times. Only when you’re generating multiple bundles, this could become an issue. As @tomconlon:disqus states, Svelte and Rollup share authors. I’m sure he has considered all of the above, but considering its age, Svelte should be used with a healthy dose of skepticism :)

  • Jaroslav Benc

    I really fell in love with – React + Polymer with enjoyable syntax, small learning curve and tiny size. Wrote website in a couple of months using RiotJS..

    I’ve used a HTML template to start with and just injected RiotJS tags where I needed to componentize stuff. No need to build everything from scratch.

    • Tim Severien

      I’ll admit I haven’t consider including Riot.js. Thanks for sharing!

    • Nick Coad

      Your datamatic website is really impressive, nice work!

  • Constantin Chirila

    I’ve heard good things about Preact as well, which basically does almost everything as react does, with a lower footprint and faster :)… I shall try InfernoJS as well, as you made me curious!

  • Gavin Thomas

    The inferno guy is now working on the react team

  • Ahamed Imran

    Mark my words. InfernoJS will make it big this year :-)

  • Rico Alexander

    Aurelia just feels right to me. Makes modular development dead simple and every decision they make attempts to conform with current and future web standards.

  • Tim Severien

    Aurelia looks awesome, and has definitely been considered. Although I care a lot about maintainability, scalability and other aspects of developer experience, I care more about user experience. Aurelia looks perfect for developers, but has remarkable impact on users. I assume that is a trade-off you have accepted, but with alternatives like Vue.js and Svelte, I would rather choose those.

    • Christian

      I struggle to see this as a problem “Vue.js’ minimal approach doesn’t get in the way, which is nice for a change.” in bigger libraries. From reading about javascript fatigue and the tremendous amount of libraries that exists what do you really gain from using Vue.js? Sure it does not get in the way but it also doesn’t really help you structure your app in the way like ember, angular(which is still not a full framework) or even Microsoft MVC . I think that these small libraries are rather overrated (react, vue etc). They may be small and do only 1 thing really well but then you need to figure out how they can interact with a lot of other libraries (from redux to bootstrap) which is a LOT of work figuring out. And they are never as easy as use library X and then whatever other library you want (most of the libraries you want need to be adapted for library X in some way or another).
      In my experience doing “regular” stuff like form validation or input management which should be super trivial, is not (refering to React).

      Just corious to see what others think about this.

      • Tim Severien

        By reading your comment, I’m under the impression we work on different kind of projects.

        Large frameworks are effective, but for larger application, often single-page apps. Coincidentally, the project I’m working on used to be a SPA, but I refactored into a multi-page app. We used HTTP for routing and for form submission ;)

        Quite frankly, I doubt majority of the web would make a good SPA. Saying tiny libraries have no place or aren’t as effective as large frameworks is only true for a small proportion of the total web. I think both have pros and cons, and we can use those to judge which is best for an application :)

        • Christian

          Very good point. I have also used React as a small component without other dependencies on a multipage app and I do see the appeal. Technology should of cause be used where appropriate. It is just that I see all these tutorials/scaffolds/put together frameworks everywhere and I think to myself… sure its neat but what kind of maintainability do they have when putting together the flavors of today in compared to a fullfledged framework.

  • Tim Severien

    Elm certainly is interesting, but not really a JavaScript library. I’m glad you do mention it!

    The fact that Ember.js is still going strong definitely proves something. I was hoping everyone was keeping an eye on that already ;)

  • Tim Severien

    Yeah, Inferno looks awesome. It would have made the article if I didn’t stick to just 3 libraries :)

  • Tim Severien

    That is awesome and super helpful. Thanks!

Get the latest in JavaScript, once a week, for free.