JavaScript
Article
By Tim Severien

3 JavaScript Libraries to Keep an Eye on in 2017

By Tim Severien
Last chance to win! You'll get a... FREE 6-Month Subscription to SitePoint Premium Plus you'll go in the draw to WIN a new Macbook SitePoint 2017 Survey Yes, let's Do this It only takes 5 min

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.

Vue.js

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>
</div>
import Vue from 'vue'

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

      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.

Svelte

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>

<script>
export default {
  data () {
    return {
      message: 'Hello World!',
    }
  },
  methods: {
    reverseMessage () {
      const reversedMessage = this.get('message')
          .split('')
          .reverse()
          .join('');

      this.set({
        message: reversedMessage,
      });
    }
  }
};
</script>

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.

--ADVERTISEMENT--

Conditioner.js

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);
    this.update();
  }

  /**
   * 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.

Conclusion

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!

Login or Create Account to Comment
Login Create Account
Recommended
Sponsors
Get the most important and interesting stories in tech. Straight to your inbox, daily.Is it good?