Tue, 17 Apr 2018 19:35:13 GMT

What follows is part one in a series of articles in which I build a blog using both VueJS and Svelte. To be clear, I’m actually going to be building two blogs simultaneously — one for each framework. In the first part of this article, I’ll discuss the tools I’ll be using, and also why the heck I’d want to do this.

In the second part, I’ll go over the steps needed to lay the foundation for future work. At the end of this post, we’ll have two minimal sites deployed at publicly available URLs.

Once the blogs are finished (aside from applying some final CSS), I’ll do an evaluation of the two sites and make a determination about which one to keep and use for my personal blog. The “winning” framework will also be used to rebuild the JavaScript Report site, which is now on .

The criteria for “best” framework are:

Performance. The site needs to render in 2 seconds on 3G mobile.
Ease of use. As I try to complete what will ultimately be a fairly simple blog, do I hit any roadblocks? Is there something missing I need to write from scratch?
How well do I think the framework will scale? As I go along, I’m going to be looking for potential issues if I decided to use the framework to build something more complex.

If you want to skip ahead and get started building stuff, you can continue reading here. Otherwise, I’d like to explain a bit more about the how and why of this project.

The Tools

Aside from VueJS and Svelte, there are a number of other tools that I’ll need to use. The first is the hosting service from Zeit. If you haven’t heard of Now, this will be a chance for you to see how to use it. It’s very easy to get started with, but part of this exercise for me is to see if I’d actually want to host a production site with them. Server response time will be a very big consideration.

Another tool I’ll be using is , which is a “headless” CMS service. It provides a slick web-based content editor as well as solid image hosting. Your content is then made available via a .

For small sites, Contentful ends up being essentially free, but it has the ability to scale to pretty much whatever size you need it to (pay as you go), and that makes it a great all-around option. Contentful does have experimental support for GraphQL, but that is something for another series of articles. For the purposes of what I’m doing, good old REST is just fine.

Finally, I’ll need to integrate MailChimp. JavaScript Report has a newsletter (which you should definitely sign up for!), and so I’d like to see if there are any issues getting that up and running with either framework, though it's unlikely to be a problem.

Why the Heck Am I Doing This?

For the past 3+ years, I’ve been building React sites at a client services company. I appreciate React and the many things I’ve learned while working with it, but I’ve increasingly felt a need to branch out.

As I’ve explored other frameworks, I’ve seen a number of things that have looked really impressive. For starters, there are quite a few frameworks that have superior performance to React. In the case of Svelte, it’s much faster, and in the case of Vue, only slightly faster.

I’ve also come to appreciate the simplicity of , which both VueJS and Svelte implement. Doing something similar in React feels convoluted by comparison.

I’ve also heard that VueJS is much easier to learn than React, and what I’ve seen so far backs that up. My early experience learning Svelte is similar. Simplicity is good! But are there any tradeoffs? I haven’t found any so far, but part of this exercise is confirming that.

Both frameworks also have good communities (although Vue’s is much larger) as well as maintainers I’m familiar with and have confidence in. And I'm evaluating both because I want to compare them head to head to find out which one offers the most benefit. They have roughly similar approaches, so they are a particularly good pairing.

As I get started, I have to say Svelte starts with a lead because it has elite-level performance. It's very fast, and ultimately, excellent performance is one of the few things that has a measurable impact for end users. If that performance comes with a lot of friction (hard to do common tasks, for example), then that makes Vue more attractive.

So, we’ll see how it unfolds.

Getting Started with Now

The first step is the same for both frameworks — getting set up to use the . Fortunately, it’s very easy to get started.

Step One

Download . It makes deployments a breeze. It installs the Now CLI and keeps it up to date automatically.

Step Two

And that’s it! Once we have the basic scaffolding for our apps, we’ll be able to deploy with a single command.

Setting Up Vue

We’ll begin with Vue by installing the . The CLI (command line interface) provides a way to quickly scaffold a project. If you don’t already have the CLI installed, go to your command line and enter one of the following commands, depending on whether or not you have installed.

  yarn global add @vue/cli
# or 
npm install -g @vue/cli

By the way, the version of the CLI I’m using is 3.0.0-beta.6. It has some nice improvements over the 2.x version.

Install Using the CLI

Now that the CLI is installed, I’ll use it to provide a basic setup for the project.

  vue create vue-blog

After entering the command above, you’ll be prompted to answer a series of questions about what you want the CLI to create for you. If you’re following along, here are the selections I made. The initial prompt asks you to pick a preset. I chose “Manually select features”.

  Vue CLI v3.0.0-beta.6
Please pick a preset: (Use arrow keys)
❯ default (babel, eslint)
  Manually select features

The next step is a list of options:

❯◯ TypeScript
 ◯ Progressive Web App (PWA) Support
 ◯ Router
 ◯ Vuex
 ◯ CSS Pre-processors
 ◯ Linter / Formatter
 ◯ Unit Testing
 ◯ E2E Testing

The options I chose to get started were:

Progressive Web App (PWA) Support
Router
Vuex (state management)
CSS Pre-processors (SCSS/SASS)
Linter / Formatter (ESLint + Prettier, Lint and fix on commit)

I will add both of the testing options later, but that feels like an entirely different series of blog posts, and there is already quite a lot going on with just getting these sites built. If this was for a client project, I’d be writing tests from the start.

After that step, there are a couple additional question you’ll be prompted to answer:

  Where do you prefer placing config for Babel, PostCSS, ESLint, etc.?
  In dedicated config files
❯ In package.json

I chose package.json for this one. Next you’ll be asked about your dependency management tool.

  Pick the package manager to use when installing dependencies: (Use arrow keys)
❯ Use Yarn
  Use NPM

I chose yarn here, but it doesn’t matter much for the purposes of this exercise.

And that’s pretty much it! Open the directory that was created — if you followed along above it will be named vue-blog — and take a look at what has been created.

You’ll see there are a whole bunch of files that have been generated. Pretty nice! If you wanted to fire up your app in dev mode, all you’d need to do is type npm run serve and you’d have a dev server spin up for you. But for the present work, that’s not what is needed. There are a couple extra steps.

Add server.js

First, add a new file to the project root called server.js. The contents of the file should look like this:

  const express = require('express');
const path = require('path');

const app = express();
app.use(express.static(path.join(__dirname, 'dist')));

const port = process.env.PORT || 5000;
app.listen(port);

console.log('server started ' + port);

This will create a web server using , which is preferred over the Vue dev server.

In order to use Express, we’ll need to add it to the project.

npm install express

The last step is to modify the scripts in package.json.

Update package.json

By default, the Now service will look to see if a build script exists, and if you check package.json, you’ll see that we have that in place. The only requirement for Now is a start script, which is not present, so we’ll need to add it. Here’s the start script I’ve added in package.json:

"start": "node ./server.js"

And now we’re ready to deploy. Assuming you have Now Desktop installed, simply type the following command into your terminal:

now

Yeah, that is all it takes. Now will spin up a deployment for you that includes SSL. Here’s of the deployment for this first step in building a Vue blog.

All in all, this is pretty damn slick. Here is the link to at this point in development for reference.

Now let’s do the same for Svelte.

Setting Up Svelte

If you’re not familiar with Svelte, you should know that it’s a bit different than other frameworks. It’s very fast, and that speed comes from a compilation process that essentially removes the framework’s runtime, leaving a bundle that is, well, .

The isn’t recommended for production use and supports compiling single components, not entire websites, so a different approach is needed. That’s where degit comes in. It will help us scaffold our Svelte project. In your terminal, add degit globally using the command below.

npm install -g degit

Next you need to ask digit to get the Svelte template and add it to a new project.

degit sveltejs/template svelte-blog

In the command above, the new project is created in a directory named svelte-blog. Open up that directory and take a look at the files.

A couple of things may stand out to you. In the package.json file, we see references to Rollup instead of webpack. That’s because Svelte is authored by Rich Harris, who also wrote Rollup.

If you’re not familiar with , it’s similar to webpack, but more commonly used in libraries. For example, React, Vue and Angular all use Rollup in their projects. For this site, however, I’m going to use webpack, but switching that out will come in a later article. For now, Rollup works great.

Now, let’s get this app fired up and deployed.

Update Dependencies and Install

You may also have noticed that the Svelte app includes a serve package. This is a nice, lightweight http server option, but I prefer Express for production. So the first thing I’ll do is install the dependencies and add Express.

npm install && npm install express

Add server.js

Now I need to add a server.js file to the project. This is almost the exact same file added for Vue, except it’s pointing Express to the public directory instead of dist. Here’s the Svelte version of the file:

const express = require('express');
const path = require('path');

const app = express();
app.use(express.static(path.join(__dirname, 'public')));

const port = process.env.PORT || 5000;
app.listen(port);

console.log('server started ' + port);

Line 5 is the only change. And just like in the Vue example, this file is in the root of the project.

Update package.json

In order to use Express instead of serve, we’ll need to update the package.json file. In this case we simply update the scripts inside package.json with the exact same command used in the Vue version of the app.

"start": "node ./server.js"

OK, we have both a build and a start script, let’s deploy to Now. Again, the command is simply, now.

Here’s of the deployment for this first step in building a Svelte-powered blog. You can see in the GitHub repo.

Observations So Far

First of all, both of these frameworks are pretty easy to get started with. In the case of Vue, however, we have more provided by the CLI. The Vue app has state management, routing, CSS preprocessing, PWA and linting already set up. That’s pretty great.

On the other hand, open up DevTools and take a look at the size of the files each app generated. The total gzipped weight of the JavaScript for the Vue app is 43.9KB. For Svelte, it’s 1.56KB. That’s not a typo! The bundle for Svelte is under 2KB! Granted, there isn’t routing or state management added yet (beyond component state), but this is still very impressive.

For those of you that are familiar with these two frameworks, you may be wondering why I didn’t use or , two full-featured frameworks built on top of Vue and Svelte respectively. They both include support for all the goodies listed above (PWA, routing, etc), and then some.

Those are both great options, but they do too much. I’m trying to explore these two frameworks, and so I want to dig into things to deepen my understanding. I don’t want so much provided for me out of the box. However, if you want to get started quickly, consider giving them a try.

That’s it for part one! In a few weeks I’ll share part two where we’ll focus on setting up server side rendering.

If you liked this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

]]>

Tue, 03 Apr 2018 01:48:47 GMT

If you like fast JavaScript apps, you’ll love Svelte. It works a bit differently than some of the other frameworks that you may be familiar with. Instead of shipping a large runtime, is compiled. This means the code you end up with is optimized and dramatically reduced in size.

Before we look at the code, I’ll mention that I'm not a Svelte expert. I've been reading and writing about it quite a bit, and I decided it was high time to build something. So, this is that something. It's possible there are better ways to do things than what you'll see here, but I think anyone wanting to get started with Svelte will have a leg up after reading this article.

The bulk of what follows is a walkthrough of the code in that I made to accompany the article. We’ll go file by file and talk about what’s going on with the application and how it’s wired together.

The app displays quotes from the public API, and is built using four tools — Svelte, Express, webpack and Babel. So you have an idea of the end product, here's what the app looks like when it's up and running. You can click to see a larger image.

If you haven’t used Svelte before, I think you’re going to be pretty damn happy with it. I found the experience to be great.

The Code

Let’s start with a quick review of the package.json file. This is where the app's dependencies are listed, as well as the scripts used in the build process.

package.json

  {
  "name": "svelte-quotes",
  "version": "1.0.0",
  "description": "A demo app of Svelte that displays quotes",
  "main": "src/index.js",
  "scripts": {
    "build": "webpack",
    "server": "node server.js",
    "start": "npm run build & npm run server",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "svelte",
    "sveltejs",
    "javascript"
  ],
  "author": "John Hannah",
  "license": "MIT",
  "dependencies": {
    "express": "^4.16.3",
    "svelte": "^1.59.0"
  },
  "devDependencies": {
    "babel-core": "^6.26.0",
    "babel-loader": "^7.1.4",
    "babel-polyfill": "^6.26.0",
    "babel-preset-env": "^1.6.1",
    "html-webpack-plugin": "^3.1.0",
    "svelte-loader": "^2.5.1",
    "webpack": "^4.4.1",
    "webpack-cli": "^2.0.13"
  }
}

If you’ve used other JavaScript frameworks, this list of dependencies will look familiar. Most of them are used to transpile and bundle up the code. On lines 7-9 we have the scripts that build the app and fire up the web server.

Now let’s check out the webpack config.

webpack.config.js

  const path = require('path');
const webpack = require('webpack');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'development',
  entry: ['babel-polyfill', './src/index.js'],
  output: {
    path: path.resolve(__dirname, 'public'),
    filename: 'app.js',
    publicPath: '/'
  },
  plugins: [
    new HtmlWebpackPlugin({
      inject: true,
      template: './src/index.html'
    })
  ],
  module: {
    rules: [
      {
        test: /\.js?$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            cacheDirectory: true,
            babelrc: false,
            presets: [['env', { targets: { browsers: ['last 2 versions'] } }]]
          },
        },
      },
      {
        test: /\.svelte$/,
        exclude: /node_modules/,
        use: 'svelte-loader'
      }
    ]
  }
};

Notice the inclusion of babel-polyfill on line 7. The app needs to get data from the API and to do that I’ve chosen to use the and the new syntax of JavaScript. Using babel-polyfill helps with the latter. It's a nice new feature of the language when working with async operations like data fetching.

The second thing to note is on line 34, the use of svelte-loader. This is what webpack uses to compile the Svelte code to JavaScript so it will work in browsers. Notice that it’s for files with a .svelte extension. Many of the examples in the Svelte documentation use files with a .html extension, but as we’ll see, that’s not ideal for this app.

Now’s let’s take a look at the code for Express:

server.js

  const express = require('express');
const path = require('path');

const app = express();

app.use(express.static(path.join(__dirname, 'public')));

app.listen(8080, () => {
  console.log('App started and available at http://localhost:8080');
});

is used to provide a web server for the application. You’ll see on line 6 that it uses express.static. This means it's serving a static HTML file to users (which we’ll review in a moment).

This is the reason all the Svelte files use the .svelte file extension — I don’t want the HTML file to be processed by webpack and having a different file extension helps webpack tell them apart. Aside from this practical consideration, it’s simply a clearer distinction for me while I’m working to use a separate file extension for Svelte code.

Associating .svelte Files with HTML Syntax

A quick aside here about happily using the .svelte extension with your editor of choice. Most editors don’t yet recognize the .svelte extension, so you’ll need to associate it with HTML syntax to get all the nice code completion and highlighting you expect. Luckily, this is quick work.

You can see how to make the change in VS Code , for Atom and for Sublime . If you use another editor, just Google it. It’s a fast, straightforward task that is definitely worth doing.

Next, let's take a look at that HTML file I was just talking about.

index.html

  
  
    
    
    Svelte Quotes

There isn’t a lot to see, but it’s an important file. When we build our app, webpack takes this file and moves it to a directory named public. Webpack also adds our JavaScript file for us. The config for this process is on line 14 of webpack.config.js and uses the .

To see a bit more about how this works, you can follow the instructions for installing and starting the app that are found on . Once it’s done building, go to the public folder and notice that the app.js file has been added near the botttom of index.html.

Alright, we’re ready to dig into the main code for our Svelte app. The starting point is index.js:

index.js

  import App from './components/App.svelte';
const app = new App({
  target: document.querySelector('main'),
  data: {
    quotes: []
  },
});

This is the file that webpack is configured to use as the entry point of the application (line 6 of webpack config). On line 1, there is the import of the root component, App. It's initialized starting on line 3, and is passed an object with a couple of properties.

The first, target, tells Svelte which element in our index.html it should work with, in this case, main.

The second property is data. This is where the default state for the App component is set.

Now let’s look at the next file, the heart 💖 of the application, App.svelte. There's a lot going on, but we'll break it down into bit-sized chunks after we see the code.

App.svelte

  
  Great Quotes
  Curated by Chris Coyier
    {{#if quotes.length === 0}}
      Quotes loading...
    {{else}}
      
    {{/if}}

This is a single file component, and it’s one of the things I like best about Svelte. If you're thinking it reminds you a bit of Vue, I agree. Notice there are three sections to this file: the markup, the script and the styles. We’ll go through them one by one.

Markup
The markup is at the top of the file. For reference, here it is broken out from the rest of the code:

  
  Great Quotes
  Curated by Chris Coyier
    {{#if quotes.length === 0}}
      Quotes loading...
    {{else}}
      
    {{/if}}

This is just regular HTML, with some additional support for . Those are the bits in curly braces and they allow for adding and working with data inside the markup. Although the braces may remind you of the Moustache syntax Vue uses, they are actually JavaScript expressions.

Notice on line 4 we have this:

  {{#if quotes.length === 0}}

When the app first loads, the quotes are not yet available, so we have some logic to display a loading message. Once the quotes have arrived, we pass them to the Quotes component, as you see on line 7.

And finally we have a button that allows us to add more quotes to the list:

Notice the on:click attribute. This is a . Svelte uses directives for event handlers and refs, among other things. In this case, it handles the click event on the button. When a user clicks the button, a function called loadMoreQuotes is called, which, as you may guess, loads more quotes!

Script
There is a lot going on here. First, notice that this is JavaScript code wrapped in a standard

On line 2, the Quotes component is imported so that it can be used in the current component, which is App.

Next, we have a data fetching function called fetchQuotes. It’s an async fuction and if the syntax looks unfamiliar, check out this of async/await in JavaScript.

We then see the default export on line 13 which is a JavaScript object with some properties and a method on it. When App was imported in index.js, this is what was received.

First we see the oncreate method:

  oncreate() {
  let data = this.get();
  fetchQuotes(data, this);
}

This is a built-in Svelte lifecycle method or hook. I've understood it to be roughly analogous to React’s componentDidMount. By the way, Svelte has two — oncreate and ondestroy.

Inside oncreate, a variable called data is set to the value of this.get(). The get method is part of the and it's used to retrieve component state. In this case, the value is the empty array that was added when the component was initialized.

On line 3, is the call to fetchQuotes, and it's passed two parameters — data, which was just set, and this, which is a reference to the current component, App.

Let’s take a closer look at the code for fetchQuotes:

const fetchQuotes = async (data, component) => {
  const response = await fetch(`http://quotesondesign.com/wp-json/posts?filter[order]=rand&filter[posts_per_page]=3`);
  const json = await response.json();
  const quotes = data.quotes.concat(json);
  component.set({ quotes });
}

Lines 2-4 fetch and process the data. On line 5 is the call, component.set(), which is also a part of the and it sets values in state.

The quotes that are received from the API are passed in and Svelte updates the state of quotes so that it now holds an array of three quotes. Technically, I guess the array holds three objects that contain our quote data.

Quick aside here on state in Svelte. Component state works great for a lot of cases. However, if the app grew and needed something more, Svelte comes with a that is analogous to Redux or MobX in React. One feature I really like is that the API for managing component and global state is the same. It's comprised of just three methods — set, get and observe (which isn't used in this app).

Next up, we have the methods property:

methods: {
  loadMoreQuotes() {
    let data = this.get();
    fetchQuotes(data, this);
  }
},

The methods property is provided by Svelte for declaring your own methods. In the case of this app, there needs to be a function that will go out and fetch some more quotes when someone clicks the “Load More” button, and that’s what’s going on here.

It’s very similar to what was happening in oncreate except that the value of data will be an array with three quotes the first time a user clicks the button (because they were fetched in oncreate which runs right after the component is created). The rest is the same!

Finally, we come to the components property:

components: {
  Quotes
}

The Quotes component loops over the array of quotes, so it needs to be declared here. If the app grew and more components were imported into App, they'd need to be listed here as well.

Styles
Finally, the styles! I didnt include the code because it’s just plain old CSS. However, Svelte does some interesting things with it. First of all, the CSS is scoped to the component. So, if you add some styling for a

tag, for example, it will not be global, but instead scoped to the component.

Another interesting point is that the CSS isn’t bundled up and put into a separate CSS file. Instead, it’s injected directly into the document . This is great for a couple of reasons — no render blocking CSS that slows the app down, plus one less HTTP request.

I should mention that Svelte does support adding global styles. You can read about that in the Svelte docs on .

Now, if you’re familiar with React, this may sound a bit like CSS-in-JS and it does have some similarities. However, working with Svelte single file components is much nicer in my experience. It’s just plain CSS. There’s no config or unfamiliar conventions, it just works.

OK, now on to the last file, Quotes.svelte:

{{#each quotes as quote}}
  
    {{{quote.content}}}
    - {{quote.title}}
  
{{/each}}

I'd like to point out the triple curly braces that surround quotes.content. There are three because the API I used returns the quotes wrapped in

tags, and I wanted them evaluated as HTML. If I had used double curly braces, the

tags would have printed as part of the quote. This functionality is similar to dangerouslySetInnerHTML in React.

And that's the code! 🙂

You Should Try Svelte!

So, Svelte is pretty awesome, right? I love it for a number of reasons. First of all, it’s fast as hell, and that is arguably the most important quality an app can have.

Second, single file components are a pleasure to work with. I didn't appreciate them fully until I started using them.

Lastly, there are a lot of little things that make it a joy to work with. The "triples" syntax above is one example. It's so simple. The API for state management is simple. These little things add up to make for a really good experience.

And despite being a new framework, Svelte has a nice community building up around it. As I mentioned, Rich Harris created Svelte. He has other very successful projects and to me, that experience shows in the way he interacts in the issue queues. It’s a project that has a good feel to it.

Well, that's it for this week. I’ll no doubt be writing more on Svelte in the future. I encourage you to give it a try. You'll enjoy the experience and your users will appreciate the lightning fast app you've built for them!

Until next time, happy coding…

]]>

Tue, 27 Mar 2018 14:01:11 GMT

One of the reasons I love writing about JavaScript frameworks is that they are incredibly impressive pieces of engineering. That, and the fact that they have made my life as a frontend developer much, much better. That said, there is always room for improvement.

Using HTTP Archive (top ~500K sites) to analyze the state of JavaScript on mobile, we can see that 50% of sites take over 14 seconds to get interactive. These sites spend up to 4 seconds just parsing & compiling JS. ()

This state of affairs may be about to change in a big way.

The Era of Framework Compilers

Although there have been smaller frameworks that have made fantastic improvements in mobile performance, the big three — React, Angular and Vue — have not really been the best options in this area.

There is now work underway with both Angular and React that promises to change this up and dramatically improve important performance metrics like .

Angular Ivy

Angular had a fairly when it was first released. There have been some significant improvements since then, but things are being taken to a whole other level with , a new renderer that will become optionally available in Angular 6.

Ivy’s most crucial target is cooperation with Angular Element. By encapsulating Angular components to custom elements (web components), we can achieve standalone publication, independent importing and independent usage of Angular as widgets…

…The most important part of this strategy is code size. Even wihout (sic) common runtime library, Angular should work with minial (sic) size. Components used as Angular Elements will not depended on external packages like forms and router, hence creating great value for size reduction.. ()

There is a up of Ivy’s huge potential. Although it’s the simplest possible example, the bundle size is about 3.2 KB! 😮 Considering that the bundle size for a similar Angular app without Ivy would be around 45KB, this is a stunning improvement.

React Prepack

The React team is also hard at work on some future performance improvements, although with a slightly different emphasis. The work centers around another project at Facebook, called , that is at the heart of a .

Prepack is a tool that optimizes JavaScript source code: Computations that can be done at compile-time instead of run-time get eliminated. Prepack replaces the global code of a JavaScript bundle with equivalent code that is a simple sequence of assignments. This gets rid of most intermediate computations and object allocations…

…The Closure Compiler also optimizes JavaScript code. Prepack goes further by truly running the global code that initialization phase, unrolling loops and recursion. Prepack focuses on runtime performance, while the Closure Compiler emphasizes JavaScript code size.

The team working on Prepack have created a REPL that you can use to . The default example they include results in a dramatic reduction in the size of the code, but that’s not always the case. So, it’s unclear how much of a reduction in bundle size we’ll see once this work is released. That said, bundle size isn’t the only thing that matters with regard to start up time.

I recently wrote an article that featured the results of a test of Inferno, Preact and React. The results are in the image below (click to see larger).

You’ll notice that Preact is the fastest under JS Init Time (smallest bundle size of the three) but by First Render Time, Inferno is long gone. Inferno absolutely smokes the other two frameworks and indeed, Inferno shows up in other benchmarks as being very, very fast, even though it often doesn't have the smallest size. I‘m connecting the dots a bit here, but this could be what we see from React once the work on Prepack is ready. Perhaps it won’t have the smallest bundle size, but it may very well have an outstanding TTI, which is really what makes a difference to users.

As an aside, why the heck aren’t more people using Inferno?! It’s freaking awesome! Perhaps not coincidentally, it looks like the React team member leading up the compiler work is Dominic Gannaway, the original author of Inferno.

The Future Is Already Here

Yes, React and Angular are the two most widely used frameworks, so what happens with them is noteworthy. However, I’d be remiss if I didn’t mention that there is already a very good compiled framework available now — .

The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that's not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn't.

Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.

Given that, what if the framework didn't actually run in the browser? What if, instead, it converted your application into pure vanilla JavaScript, just like Babel converts ES2016+ to ES5? You'd pay no upfront cost of shipping a hefty runtime, and your app would get seriously fast, because there'd be no layers of abstraction between your app and the browser.

Svelte is a new framework that does exactly that.

Svelte is authored by Rich Harris. Another one of Rich’s big projects is , which is a module bundler typically used in libraries (it’s used by both React and Angular, for example). So, Rich knows a helluva lot about optimizing JavaScript, and with Svelte, it shows.

A companion to Svelte is Sapper. Sapper is to Svelte, what Next.js is to React. It’s a framework with all the good stuff you’ll need to build a real app baked in — routing, data fetching, code splitting, etc. When I took it out for a test drive, the gzipped size for the app was around 11 KB! Keep in mind, this was not a stripped down, “Hello World” example. It included the works.

Even if Svelte isn’t the right framework for your next project, consider . It’s definitely deserving of more attention — and usage!

If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

Until next time, happy coding…

]]>

Mon, 19 Mar 2018 19:22:17 GMT

Welcome to the first edition of a new feature here on JavaScript Report. Each month we’ll go over the important things you need to know about what’s happening with front end JavaScript frameworks. We’ll be covering usage, performance, conferences, trainings and more.

If you’d like to keep up to date on this, you can sign up for my newsletter. In addition to the latest news on frameworks, the newsletter also covers the week’s best writing on the JavaScript ecosystem, so it’s a useful all-around resource.

If you’re a framework author or contributor and you’d like to bring something to my attention, please to me. I’m happy to include any news or updates.

Framework Usage

Let’s begin by taking a look at current framework usage trends. Below is a chart showing the npm downloads of the the top four front end frameworks — Angular, AngularJS, React and Vue — over the past month. You can click all images below to make larger.

Framework	Growth rate past month	Growth past year
Angular	1.6%	102.6%
AngularJS	7.2%	97.4%
React	10.5%	153.3%
Vue	24.2%	168.4%

There are a couple of things to notice here. First, all the frameworks have strong annual growth rates, even the venerable AngularJS. In fact, the growth rate for Angular is lower than for AngularJS on a monthly basis and very similar for the one year period.

Another thing to note is that the monthly growth rate for Vue is a bit deceptive. Vue had a noticeable decline in early February and the big gain is partially attributable to it recovering from that drop. As recently as January 21, Vue was in third place, but it's currently the fourth most used framework. If we take a look at the chart for annual usage, this dip is a bit easier to see. Again, click to see larger image.

Another notable trend is the continued strong growth of React. Despite having more usage than the other frameworks combined, it continues to increase its lead vs both Angular versions and is similar to Vue in annual growth.

Other Frameworks of Note

Some pretty interesting numbers here for Preact, Inferno, Ember and Svelte.

Framework	Growth rate past month	Growth past year
Ember	1.5%	4.5%
Inferno	-0.4%	-77.7%
Preact	22.1%	489.1% 🚀
Svelte	174.3%	757.6% 🚀

The most significant thing in the chart above is Svelte overtaking Inferno. They may go back and forth over the next few months, but I think this is probably going to hold up over the long term. In the table above the numbers for Inferno look terrible (down 77%), but we can see they don't tell the whole story when we look at the entire year.

I don't know why it's the case, but the download numbers for Inferno are very volatile. Measuring on slightly different dates would have altered the numbers dramatically.

Despite that qualification, Inferno doesn't seem to be thriving. It pains me to say that, because it's an outstanding framework. I think it could use some promotion — blog posts, conference talks, for example.

and look very strong. It will be interesting to see if they carry the momentum forward in coming months.

Framework News

The past month or so has seen a number of important announcements. We’ll kick things off with the big news in the React community.

Beyond React 16

The biggest React news over the past month is no doubt Dan Abramov’s talk from JSConf Iceland. His presentation, lays outs how the upcoming React 17 will improve performance. If you've heard something about React "Suspense" lately, this is the talk where that was introduced.

Inferno 5 Released

You can check out the release notes .

ngAtlanta Report

Although it’s technically more than a month ago, from ngAtlanta is an important read to get a handle on what’s happening in the Angular community. Of particular interest to me is the which will be an option in the upcoming Angular 6. It promises to dramatically reduce bundle sizes.

Love Angular but just wish it was smaller, easier to debug, and compiled faster? These are our goals with Angular’s new renderer code-named Ivy. Its coming as a non-breaking change so you’ll get it automatically in a future release by just staying on Angular’s latest releases (which should be a breeze with ng update). We’ve got a ways to go, but we’re hopeful developers will be able to opt-in to a preview in the first half of this year.

State of VueJS 2018

Another great conference talk here, this time from Evan You, the creator of Vue.js. He gives a “State of Vue” address that reviews the latest work on that framework.

AngularJS Enters LTS

This bit of news is from earlier this year, but feels relevant to some of the other items in this article. The of AngularJS has been announced. After that, the project enters long term support (LTS).

After the release of 1.7.0 the team does not intend to merge any feature or fix that will require even a minor breaking change.

After 1.7.0 we will continue to develop AngularJS, publishing patch releases, 1.7.1, 1.7.2 etc, through Jun 30, 2018. These releases will only include non-breaking change features and fixes to the framework.

EmberConf Hits Portland

EmberConf wrapped up last week. To catch up on what’s happening in that community, you can watch the keynote from Yehuda Katz and Tom Dale (I recently did an interview with Tom 👍).

Radi.js Announced

A new framework has entered the fray, . It’s authored by Mārcis Bergmanis and he begins his announcement by answering an obvious question:

First of all I want to address elephant in the room that is one question you might be having: “Why the heck another JavaScript framework ?”. Well my answer is that I noticed a pattern in all of the frameworks I recently went through and all of them have the same problem. They are stuck in creating Virtual DOM and then running diffing algorithm over it, which led to diffing algorithm wars. And I thought that there is a better way of doing this (sneaking around this war), so I created a tiny JS Framework called Radi.js…

…What if we didn't use Virtual DOM at all, instead work with real DOM instead?

Vue.js Cookbook Released

The already good Vue documentation has gotten even better with of a "cookbook".

In the cookbook, each recipe can and should stand on its own. This means recipes can focus on one specific aspect of Vue, rather than having to give a general overview...we can include more complex examples, combining features in interesting ways. Each recipe can also be as long and detailed as it needs to be, in order to fully explore its niche.

Notable Tutorials and Articles

Wes Bos explains the coming up in React 16.3.

Chris Fritz about 7 secret Vue patterns [VIDEO].

Tyler McGinnis has updated his to React.

Máté Huszárik the transition from AngularJS to Angular.

Wolfgang Wedemeyer tells us about and how it improves on Redux.

Bartosz Szczeciński gets us up to speed on (this builds on Dan Abramov's talk featured above).

Vue Mastery is a site that looks promising. Only one free course for the time being, but more look to be on the way.

Here's an article I wrote about SvelteJS. It has some similar concepts to Vue, but also some other innovative stuff that makes it really fast.

Tyler McGinnis wrote another great tutorial, this time on React, React Router and server-side rendering.

Upcoming Conferences and Workshops

If you have a conference or workshop coming up and would like me to help get the word out, . I'll be happy to help.

Conferences

Date: April 12-14
Location: Amsterdam, The Netherlands

Date: April 18-20
Location: Salt Lake City, United States

Date: April 24-26
Location: Helsinki, Finland

Date: April 28
Location: Sofia, Bulgaria

Date: May 8-10
Location: Chicago, United States

Date: May 17-18
Location: Paris, France

Date: October 2-3
Location: Park City, United States

Date: October 10-12
Location: Orlando, United States

Workshops

Date: April 19-20
Location: New York City, United States

Date: April 21
Location: New York City, United States

If you’ve enjoyed this post, sign up for my weekly newsletter. In addition to framework news, I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

Until next time, happy coding…

]]>

Tue, 13 Mar 2018 13:37:44 GMT

This is a list of people who influence how I think, not only about JavaScript, but also about writing code for a living. If you don’t follow these folks, I encourage you to do so. For each person, I provide links to their Twitter profile as well as some of my favorite parts of their work.

Rich Harris

I’m kicking things off with Rich because I love the way he thinks. He’s the author of multiple projects that you may be familiar with including:

- an ES6 module bundler most often used in libraries
an innovative front end framework that is super fast 🚀
- another front end JavaScript framework Rich created while working at The Guardian

Here’s one from Rich that gives a sense of what he focuses on in his work:

We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use – and that what really mattered was performance once your app was already interactive.

But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly.

And on CSS:

It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.

So the JavaScript community rolled up its sleeves and got to work. Over the last couple of years, there's been a Cambrian explosion of libraries aimed at making CSS behave, collectively referred to as CSS-in-JS.

What you might not realise is that the biggest problems with CSS can be solved without CSS-in-JS. Without those problems, writing CSS isn't just tolerable — it's enjoyable. And you don't have to find solutions to the additional problems that CSS-in-JS introduces.

Selected writing:

Twitter:

Dan Abramov

Aside from being a great developer, Dan is one of the most generous and patient people I’ve seen in issue queues. He is the author of the popular state management library, Redux, as well as a member of the React team. And through his work on Redux, Dan is responsible for introducing me to functional programming.

A from Dan:

Experts often don’t know the problem any better than you. What they learned is not to trust themselves. They dig deeper and keep reducing the test case even if nothing obvious jumps at them for several hours. They know there is a problem somewhere, and finding it is a boring, mind-numbing but usually finite process.

Selected writing and talks:

(if you want your library to do well, write docs like Dan)

Twitter:

Kyle Simpson

Kyle is a prolific author and trainer. If you’ve been following JavaScript for a while, you’ve almost certainly come across his work at some point. There have been quite a few times when Kyle has made my brain hurt. This dude knows JavaScript in a deep way…and yet he makes it accessible for people just getting started.

A couple of my favorite books from Kyle are (that book is $2.99 by the way!) and his latest, , which is fantastic.

In addition to his books, Kyle has done a through Frontend Masters. You may also be able to access those courses on Pluralsight, Lynda.com and other places, so be sure to look him up if you have a membership to those sites.

Great by Kyle:

I've come to believe something very deeply in recent years, so much so you could almost call it a religious belief. I believe that programming is fundamentally about humans, not about code. I believe that code is first and foremost a means of human communication, and only as a side effect (hear my self-referential chuckle) does it instruct the computer.

The way I see it, functional programming is at its heart about using patterns in your code that are well-known, understandable, and proven to keep away the mistakes that make code harder to understand. In that view, FP -- or, ahem, FLP! -- might be one of the most important collections of tools any developer could acquire.

One …love this!

They say knowledge is power. I disagree. Knowledge is potential. Skill is what you do with knowledge. And that is power.

Selected writing:

(six book series)

Twitter:

Gregory Brown

It’s not just that Gregory is a good software developer, it’s that’s he’s a wise software developer. And he has a knack for saying things in a way that I really connect with. For example:

When first starting your career, spend time getting to know people much older than you... They have insights that will prepare you for the road ahead. As you advance in your career, spend time around people much younger than you. They will challenge your views and inspire you. ()

And…

Reading articles and books is not practicing, it's studying. Watching screencasts is not practicing, it's studying. Listening to podcasts is not practicing, it's studying. Attending talks is not practicing, it's studying. Want to improve quickly? Study less. Practice more. ()

He’s also the author of . Great title, right? Gregory isn’t a JavaScript developer per se, but his insights apply to anyone writing code for a living.

Selected writing:

Twitter:

Addy Osmani

For me, Addy is often the voice I hear on a project saying to me, “You can do better.” Since Addy is a tireless advocate at Google for web performance, his words often come when I’m trying to get a site to load just a little bit faster. To my mind, Addy is one of the people making the web a much better place.

Great from Addy:

When you’re given too much choice you can also end up increasing your expectations. Maybe you feel that if you hold out, you’ll find the ‘best’ one. The unicorn in the herd. Clearly, with so many options to choose from, the correct choice must be amazing. Often, however, on discovery of what the ‘correct’ choice is like we can feel unfulfilled. Such high expectations are difficult to meet, leaving us in a state of unquenchable dissatisfaction…

..If you’re an experienced developer speaking to someone stuck on a decision, try to help them simplify their options. It’s a freeing experience and may help narrow down their choices to something that doesn’t feel so daunting. Even taking a few off the potential list can give them an opportunity to get more clarity and choose something they can at least evaluate before making a final decision.

If you’ve followed my previous writing on speedy JavaScript frameworks, you’re seeing some of Addy’s influence coming through. He really inspires me to do well in this area and help promote a high performance web.

Selected writings and talks:

(conference talk)
(conference talk)

Twitter:

Evan You

Evan is the author of the wildly successful UI framework, Vue.js. At this writing, Vue is the third most used front end framework, and it has achieved this by a different path. Rather than having corporate backing, Vue is funded by donations from the community. I truly admire Evan for not only creating great software, but doing so solely with donations from the people that use his software, which is a hell of an achievement in itself.

Here’s a from Evan on how Vue differs from React and Angular. It offers some insight into the basic philosophy of the project:

On a framework level, we tried to build it with a very lean and minimal core, but as you build more complex applications, you naturally need to solve additional problems. For example routing, or how you handle cross component communication, share states in a bigger application, and then you also need these build tools to modularize your code base. How do you organize styles, and the different assets of your app? Many of the more complete frameworks like Ember or Angular, they try to be opinionated on all the problems you are going to run into and try to make everything built into the framework.

It’s a bit of a trade off. The more assumptions you make about the user’s use case then the less flexibility the framework will eventually be able to afford. Or leave everything to the ecosystem such as React — the React ecosystem is very, very vibrant. There are a lot of great ideas coming out, but there is also a lot of churn. Vue tries to pick the middle ground where the core is still exposed as a very minimal feature set, but we also offer these incrementally adoptable pieces, like a routing solution, a state management solution, a build toolchain, and the CLI. They are all officially maintained, well documented, designed to work together, but you don’t have to use them all. I think that’s probably the biggest thing that makes Vue as a framework, different from others.

Selected Talks:

Twitter:

Axel Rauschmayer

In my mind, Dr. Rauschmayer is a bit like Kyle Simpson — a super smart guy that has incredibly deep knowledge of the JavaScript language. He’s the author of , but he’s probably best known for the frequent posts on his which tends to focus on new features of the JavaScript language.

For some of his additional writing, see , a collection of freely available online books that deep dive into the latest JavaScript features and how to use them.

From Dr. Rauschmayer:

In almost all cases, the ergonomics of reading trumps the ergonomics of typing: code is only written once, read many times. ()

And…

The most beautiful programming language in the world is useless unless it allows you to write the program that you need. ()

Selected writing and talks:

(conference talk)

Twitter:

Sarah Drasner

Sarah is best known for her work with SVG animations. She’s recently had a book published on the topic, . That said, I think of her mostly in relation to Vue.js, where she’s a member of the core team. She’s also written a ton of great articles about the framework, mostly aimed at helping beginners get started.

From Sarah:

We lie to ourselves in myriad ways. We might spend the time writing a comment that could be better spent making the code cleaner to begin with. We might also tell ourselves we don't need to comment our code because our code is well-written, even if other people might not agree.

There are lazy crutches in both directions. Just do your best. Try not to rely on just one correct way and instead write your code, and then read it. Try to envision you are both the author and maintainer, or how that code might look to a younger you. What information would you need to be as productive as possible? ()

Also…

Animation is 10% learning browser specs, animation libraries, and motion theory and 90% sitting around adjusting timing until my eyes bleed. ()

Selected writing and talks:

(with Kent C. Dodds)
(conference talk)

Twitter:

André Staltz

One of the of reactive programming I’ve seen is by André. In addition to that write up, he created a that builds on the topic and delves into RxJS. He’s also the author of the functional, reactive JavaScript framework, .

But André makes my list because of his advocacy for an open web. Frequent targets of his criticism are Facebook and Google. He often reminds me of what’s at stake and why I should care deeply about those issues.

From André:

I actually have hope for the Web. There are legimately viable ways of preserving freedom on the Web while taking the platform forward and keeping it competitive against proprietary alternatives from tech giants. But it can only happen if the Web takes a courageous step towards its next level. If it stays in its current form, the Web has little chance of being relevant while America’s , the , and tech giants build their Web-less vision of the future. ()

Selected writings and talks:

(conference talk)

Twitter:

Until next time, happy coding…

]]>

Wed, 07 Mar 2018 17:05:48 GMT

I recently had the pleasure of interviewing Tom Dale, a member of the Ember.js core team who has been with the project since the very beginning. In our talk, we discuss how he got started as a programmer, a bit of JavaScript history, as well as what to expect from this year's , among other topics.

There's a lot of wisdom from Tom in what follows...

Tom Dale: Nice to meet you, John.

John Hannah: Yeah it's nice meeting you, and thanks for taking the time to answer some questions for me.

Tom Dale: Thank you for covering it.

John Hannah: You bet. So I want to start with a part of Ember that fascinates me — it’s the Ember history. Can you talk a little bit about the origins of the Ember project? How you got involved...and I’ve read something about SproutCore, and a company called Strobe. I mean, how did that all begin? The genesis of Ember.js?

TD: Oh geez. You know, I could talk your ear off. I love this stuff. I actually really love the history of all these things and I actually do think that part of the reason Ember has lasted so long is I think we are very aware of history. I think that helps us avoid going into trends that are not long term trends, they're kind of like a fad. People tend to chase fads but I think because we do take a long view of history, that kind of helps us avoid that.

So was a very interesting project. So this was an open source project that ported Cocoa, the Apple Objective C framework for building Mac apps. It ported it to JavaScript. I think SproutCore was really, it was revolutionary. I don't think it gets enough credit for just how revolutionary it was.

So this was back in 2007, I think, was when Charles Jolley created the SproutCore open source project and I think this was really the first mainstream framework with some popularity to do client side rendering; where all the UI, all the DOM was created in the router and not on the server somewhere. Even though we take that for granted today, my goodness, that was a controversial idea in 2007.

JH: Yeah.

TD: I think most people learned about SproutCore because Apple built the MobileMe websites, like the web applications, in SproutCore. That was my first real programming job, working on that team at MobileMe where I met Charles and the rest of the SproutCore team. And I really got thrown in on the deep end. I had no idea what I was doing. It was my first job. I did not have a computer science degree, and I kind of like picked up programming on my own, got hired into the job, and next thing I know ... How did I do that?

JH: How did you land that job? That's an awesome first job.

TD: It is an awesome first job. I agree and it was career defining. Like I don't think I'm particularly smart or skilled in any way. Honestly, I think I was just in the right place at the right time. I was hired into that team to work on the JavaScript framework before JavaScript frameworks were considered a good idea. In fact, they were widely considered a bad idea.

So long story short of how I got that job, is that I was working at the Apple store in the Genius Bar, and I had a friend who had a job at Apple corporate and he had kind of heard that I knew how to program, I kinda taught myself. I learned Rails so I could build a website for my World of WarCraft skills. (laughter) …this is like my very early 20's and he said, "Hey, we got this project that we want to build, but we don't actually have the budget so we can't hire real software developers." What they did was they kind of did this rogue operation where they pulled I think it was like five of us from retail employees. I think I was making like 12 bucks an hour.

They pulled us up to work on this web development project and they wanted to do it in Rails and SproutCore and everyone knew Rails. No one really knew JavaScript but 2007, JavaScript was considered a poor language. So we built the Rails API in two weeks and then the SproutCore app, I don't think we even started up. (laughter) So they were like, okay, you have to learn JavaScript. You have to learn SproutCore.

So here I am making 12 bucks an hour, learning JavaScript in 2008 and through that process of, "Oh my God I'm going to get fired because I don't know what the heck I'm doing”. We went over to Charles and the rest of the MobileMe team and we said, "Please help! Anything…oh my god, we’re dying!" That's how I met him, and I guess they didn't think I was a complete idiot, and hired me.

JH: Wow. That's a great story. At some point, the transition from SproutCore to Ember, how did that happen? Was that something that happened internally at Apple? Or was that afterwards?

TD: That was after Apple. So I was working on SproutCore at Apple. We were working on the transition from MobileMe to iCloud. Charles left Apple to start a company called Strobe, the one you mentioned, and Yehuda joined Strobe as a co-founder, which is , it's how I met Yehuda. That was kind of the start of what has been a very fruitful collaboration and career for both of us. Although of course, Yehuda's reputation precedes him. He had quite a good career before I came along. He worked on Rails and jQuery and all sorts of stuff.

But for me, it was amazing. I think I was like 22, maybe 23. I left Apple, joined this start up with Charles and Yehuda and I think ... I remember walking into that office day one, and Yehuda handed me a keyboard and mouse and said, okay we're going to be pair programming. The next five years of my life, there was basically not a day where I didn't pair program with Yehuda.

JH: Wow!

TD: Which is quite a learning experience. So that was life changing. So what ended up happening was that SproutCore was a port, like I said, of Cocoa to the web. That meant that it tried to extract over things like the DOM and CSS and tried to make building a web application much more like building a native app, like a Mac app or iOS app. I think a lot of people liked that. There was also Cappuccino, which was another kind of take on decisions.

But I think what we underestimated was people really like ... web developers really like the tools in the browser. They're very powerful. HTML, CSS, those are the tools they feel comfortable with. Those are the tools the browser has optimized for. Those are the tools that there is a wealth of resources available for. So what happened was, we said people don't want to build apps like this because it involves a lot of manual DOM operations if you want to do anything custom.

So Yehuda had just written handlebars and he said, "Why don't we add this templating language to SproutCore for people who do want to write HTML, there's a nice app for that and it's not just kind of like painful customization process." But that caused a little bit of tension in the community because they're kind of polar opposites. One has a vision for the web as an app development environment where it's like you're building an app and this vision was more like, let's go back towards HTML and CSS.

So ultimately what happened was we were working on SproutCore 2 and I think that caused a lot of branding confusion so ultimately we rebranded SproutCore 2.0 to Ember.

JH: So one of the things that I've read is one of the big early contributions that Ember made, really to all JavaScript frameworks, is the router. Can you talk a little about that and the significance of it? How big of an achievement that actually was and how it has that legacy today?

TD: Oh boy. Absolutely. You know, it's so interesting because almost every framework has a routing story now. It's just table stakes if you want to be competitive. But before Ember, JavaScript applications, single page apps, the apps where you do all the rendering in the browser, they had a very bad reputation. A very bad reputation.

Every time someone would post a link to a JavaScript framework or a library on Hacker News, or anytime someone posted on Hacker News and said, "Look at this app that I built", people would come out the woodwork and say, "I hate JavaScript apps. They're so terrible. I can't command click on things. The back button's broken. If I reload the page, I lose the state." It's just broken, right? And what had happened is that, I think, people had taken the architecture of native applications too literally. When you build an iOS app, or a Mac app, there's no URL bar, there's no address bar.

JH: Right.

TD: So, you don't really have to think about that. Applications, they kind of just happen in this ad hoc fashion. And a lot of people were treating it like JavaScript intrinsically was a problem, that we will not do JavaScript, this is just, these are the problems and they're insurmountable. But after we had noodled on it, I think we came to realize that the URL is really just a serialization of the current state of the app right now. It's a serialization of a combination of what views or components are on screen, and what is the data backing those views. And it was, in retrospect, it's so obvious.

But at the time, it really wasn't. And our initial attempt at this was, we kind of went to the academic literature. We looked at a paper about state charts by David Horrell, Dr. David Harel, I guess. He has his PhD. And so we imported this concept of state charts quite literally. And the API was just very unpleasant to use, so this is one of the reasons people didn't like Ember at the time, was just that we were very rigorous about the routing, and it produced good applications that helped get the views, but the process of writing them was awful.

So the key insight that we had that I think solved this is that we decoupled ... It had two responsibilities throughout, right? One responsibility is when you were running the possible URL in your app. And then the other responsibility is then taking them, and then going and fetching the right data. It was like this data fetching responsibility.

JH: Right.

TD: And we had coupled those into a single object, so I think if you look at the Ember router API today, it's very similar to other routers. The key insight that we had, that was not at all obvious at the time was to decouple these things. Have one file that says, "Here's all the URLs," and then have other objects that are responsible for doing the data fetching. And once we did that decoupling it felt so good. We knew we really had something special there.

JH: So Ember has been around for a long time, like 7 or ... Yeah, it's like 7 years now, right?

TD: I wanna say 8.

JH: 8 so ...

TD: If you count SproutCore 2 ...

JH: Yeah. So, been around for a long time, but just a few weeks ago 3.0 was released. What's new in 3.0 for Ember?

TD: Well Ember 3.0 is a very exciting release, and the reason it's very exciting is because there are absolutely no new features.

JH: No new features?

TD: There are no new features. And we are very proud of that fact. So, I think our model is a little bit different than ... You know, most people think of major releases as ... Usually there's some hot, new feature that it's supposed to entice people to operate.

JH: Yeah.

TD: And you do the big press tour, you know, telling everyone about this cool, new feature.

JH: Yeah.

TD: But I think it actually says a lot about Ember's…like the thing that we value. Because rather than saying, "Hey, you need to upgrade to this new, major version in order to get the latest, hot feature," what we did is we took all the hot, new features that we wanted to deliver to users, and we did them in the 2.x series. We spent the extra time to do it in a backwards-compatible way.

So what Ember 3.0 is about, is it's really just a garbage collection sweep where we already gave you the hot, new features. We deprecated some features. So in order to make the jump to Ember 3.0, you just get the last version of Ember, Ember 2.18. You make sure that it runs without any deprecation warnings, and then you just move to Ember 3.0 and there are no changes. Other than we have made the framework smaller, slimmer, more svelte.

JH: That kind of leads into another question I had for you. I was reading an article that you wrote, I think it was last year, in 2017, The State of Ember. I think you wrote it right before EmberConf, or perhaps right afterwards. And you talked a little bit about performance there, and I saw that you had a code repo that asks, "Is Ember fast yet?" Or something to that effect. So one of the concerns that developers sometimes have about Ember is performance. So how do you answer that? What do you say to developers who might think that Ember is too large, or not fast enough?

TD: Sure. So I think that Ember does come from a world where, it does predate the mobile revolution. There's no question about that. I think, in terms of performance, we have been doing a lot of work over the last few years to kind of remove features that are no longer being used, pulling things down, improving performance, so there's been a dramatic improvement there. So I think on desktop applications, if we're talking about if we consume broadband, desktop applications…basically the Western market, I don't think that there are any noticeable performance problems with Ember.

People like to take Ember as a build which includes a lot of functionality that most apps have been kind of needing. And they compare it to a library that is just the V in MVC, and those things are just apples and oranges. And what I have noticed is a lot of the times, people put these small little benchmarks. Oh, this is much faster. But actually when you build a full production application, and you have to bring in things like the router, and you can bring in things like a data library, and you can bring in all these additional helpers to build the production application, they end up being comparable.

So if you look at the final size of the Ember app, compared to the final size of the JavaScript payload built for an app using other libraries, they end up being about the same. On average, this is of course a different thing. But you can do this experiment. Go to a website. Look at the size of the JavaScript. It's always between 500K and a megabyte. It just always is.

So that being said, I think there really is an opportunity to build something that is even more optimized. Particularly, one thing that I've been focusing a lot in the last year or so is we can use audiences that are in emerging markets where the devices are not quite as high powered as what we might expect in the US where network connectivity is both slow, and often times very spotty.

JH: Yeah.

TD: And I think what's great about focusing on that use case is that if you make that fast, it's going to be screaming fast in developed markets. Screaming fast. And so that's what the GlimmerJS project has been about. GlimmerJS is our laboratory, our experimental laboratory for conducting experiments of what is the absolute fastest web app that we can build if we can put aside the backwards compatibility for a moment, embrace cutting edge, new web technology.

Stuff like binary data, service workers, WebAssembly. If we can combine all of those ingredients, not yet worry about backwards compatibility, what is the absolute maximum performance that we can get out of the web? And I think what's been so great is that we have done that. We did that experiment at LinkedIn. We rebuilt the feed in GlimmerJS. And it was super, super fast.

JH: Oh, wow.

TD: I think what's awesome about the Ember model is that Glimmer's the laboratory for experimentation, but we have a way of taking that experimentation, taking the learning from that, and up streaming them to Ember in a way that you know is going to be stable, you know it's going to be mature, you know it's going to be battle tested, and most important, we know it's around for the long term. It's not going anywhere.

And so that kind of tick-tock cycle of experimentation in Glimmer, up streaming ... Ember, despite being as old as it is, has never been more technically advanced than it is now. Glimmer and Ember share the same Glimmer VM rendering engine, so a lot of the improvements that we do when we're targeting these emerging markets kind of up streams to Ember automatically.

JH: Sounds like a lot of energy and time has been put into that. That's cool. So EmberConf is coming up next week, and you're giving the keynote. What should attendees expect from this year's event? Not necessarily your talk. I know you probably don't want to give anything away, but, what about the event? What should they be looking forward to?

TD: Well, so here's the interesting thing about Ember is that we are ... I work for LinkedIn, but Ember is a community project. The members of the core team, we work for many different companies, big and small, from LinkedIn all the way to 1 or 2 person consulting shops. So the thing that's interesting is there is nothing that we're going to talk about in the keynote that is not on GitHub right now.

JH: That's cool.

TD: And I think that makes us a very special framework. We do literally everything in the open. We do everything for the RFC process. All the code is pushed to get out the second it gets written. And that is very important to me. I think that's how to do open source right.

So there's no worries about giving anything away. I think there are really two themes in the upcoming EmberConf. The first is ... Our vision for the series for 3.0 series is about simplifying Ember. We really want to keep distilling it down to just a few core concepts. What is the minimum we need for robust routing? What is the minimum you need to know for a robust data layer? Simplifying the component model.

And then I think the other thing is looking at the landscape, because there are so many cool, new features that are now landing in browsers... features that we can start taking advantage of…classes, decorators, async functions. We want to take advantage of those, but I think there's a tendency to rush in and say, "Oh, this new feature's available. Let's start using it right away."

For us, because we are used in so many real world production applications, it's very important for us to adopt those new features in a productive way. You can't adopt new features, but regress from productivity. So I think what you're going to see at conference this year is a way of making the developer ergonomics that Ember is known for in a way that can break into all these cool, new technologies.

JH: So this might be a little bit of a weird question, but what's it like to be part of a project like Ember that blows up the way that it has? So you were telling the story you're at Apple, and you're a new developer, self-taught, and then you're part of this project that just blows up and developers all over the world start using it. Big companies start adopting it. And now it's got, for many years now, it's own conference. What's that like?

TD: It is very cool. It's not a weird question at all. It is a fantastic question, because I consider myself to be one of the luckiest people in the world. I absolutely love my job. I have friends from all over the world. I think I have friends now on every continent because of the incredible gift and the honor of being invited to speak at conferences all over the world. It is so humbling, and it is so rewarding. The code is not really ... code is code. But for me, the Ember community is such a fantastic, welcoming, hard working community. So friendly, and I think dedicated to a higher purpose.

But even outside of the Ember community, open source is such a shift in the way that we work. And it has allowed me to work with the smartest people, the kindest people from around the world even though we don't work at the same company. And that is so liberating. For me, I know there's often times talk of burn out and open source's sustainability. I think those are really important conversations to have, but open source has completely changed my life for the better, and I am ... Sometimes I wake up in the morning and I am just sick with gratitude.

JH: That's great. My last question that is about open source and what advice you have for new developers who, they feel like they want to start contributing to open source, but it's intimidating, they don't know how to go about it. What would you say to a new developer who wants to do it, but is nervous about getting into an open source project?

TD: That's a great question. I think that a lot of times, the impression of open source is that you have to contribute code, and you have to contribute features, and that is what open source is. But there is tremendous value ... I'll say this as a maintainer. Having people who hang out on GitHub issues and just try to help triage ... If someone posts a problem that they're having. If someone comes along and says, "I have reproduced this. Here is the reproduction." Or, "It looks like you are just using the API wrong, here’s a link to StackOverflow. This can be closed." Stuff like that is such a time saver. Just hanging out wherever the community hangs out in chat rooms, and just helping people. Those are contributions. They matter.

And whatever your skills are. Whether it's ... If you can write well and contribute documentation, write blog posts. Design is important. Infrastructure is important. There are a lot of people who got their start with Ember, they didn't even particularly know JavaScript that well. Maybe they had a Ruby background, but they were able to help us out by working on our release infrastructure or provisioning AWS S3 buckets for us. Those are all valuable contributions. So I think there's a lot of resources that cover those things and say that. That's not really fairly a novel insight.

There is one thing that I think I contribute that's novel, which is ... Or something I haven't heard other people say, which is that for me, as a maintainer, your consistency is actually more important than your raw skills. Because raw skills can be improved over time, but as an open source maintainer, there's thousands of people in the community. A lot of people mean really well. They say that they want to help. But, for me, I have the same 24 hours in the day as everyone else does. And I like to sleep, so far less than 24 hours. And you gotta figure out how to spend that time. And even if someone is really skilled, if they show up and I don't have confidence that they're going to cross the finish line on it, then it doesn't make sense for me to invest the time.

So I think the biggest thing, if people want to get involved. The biggest thing that they could do is show up, take on the task, and if you are going to ... If you say you're going to do the task, actually follow through and do it. For me, it is more valuable to have someone who has four hours to spend every week on open source work, than someone who can dedicate two weeks to some big project, and then I'm never going to hear from them again. Because now I have to maintain that. Because now their problem is my problem.

So consistency, even in small amounts, I think ends up compounding in a way that just big blocks of time don't. So if you optimize for that, I think it makes the process a lot easier. It certainly makes the maintainer's life a lot easier.

JH: That's great advice. And I really appreciate you answering my questions and spending time with me today, Tom.

TD: It was great talking to you. These were fantastic questions. I am extremely impressed.

JH: Thank you. Thank you very much.

And Finally...

Huge thanks to Tom for talking with me. It was a fascinating conversation and I particularly loved the parts about JavaScript history and how he fell into programming. There's a good lesson there for new devs, I think.

If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is below.

Until next time, happy coding…

]]>

Mon, 26 Feb 2018 13:23:01 GMT

In this article we’re going take a look at some libraries you can use to give your React app a big performance boost. When we’re talking about JavaScript frameworks and performance, we’re usually talking about one of two things — start up performance or UI performance. In this article we’re talking mostly about start up performance (page load, e.g.), but we’ll briefly touch on UI performance when we discuss the last library on the list.

React LazyLoad

One of the strategies you can use to improve the performance of your app is to lazy load assets, and that’s where comes in. I’ve used this library in a recent project and it’s very easy to get going.

The first step is to add the library to your project (via npm or yarn) and import it into the file where you want to use it. Then if you want to lazy load an image, for example, you simply wrap it like you see in the image below:

Notice the offset={100} bit. That tells the library to begin loading the image when it’s within 100px of the viewport. Loading the image before it’s visible provides a nice experience for users. You can of course adjust that number to whatever works for your app, but too big and you lose some of the benefits.

In addition to images, you can also lazy load components. There is a bit more to lazy loading components by default, but it’s still pretty straightforward.

If for some reason this library isn’t right for you but you’re still interested in lazy loading, the library is a good fallback.

React Loadable

Code splitting builds on the idea of not loading assets until you need them. Instead of images, however, we’re talking about JavaScript files. The basic idea is that you split your code into a bunch of separate files. Only the files required for a given page will be loaded, thus reducing the amount of JavaScript that needs to be downloaded, parsed and run. As you click around the app, the files needed for the new views or routes will be dynamically loaded as needed. It’s a slick idea.

Until recently, this has been a big pain to accomplish in React, particularly when doing server rendering. The most popular library for React code splitting is , written by James Kyle. Although the implementation for server rendering is more involved, the basic usage is straightforward:

Bundle sizes in React apps can get pretty big and using a library like React Loadable is a very effective way to trim them down to size.

An alternative code splitting library I’ve used is . You can see it demonstrated in the React starter kit, .

Preact

Yes, I'm actually suggesting that you improve the performance of your React app by not using React. But that's really why exists in the first place. It’s much smaller than React and easy to drop in as a replacement. Although it's a completely different UI library, Preact has the same API as React. And when using preact-compat alongside it, you get compatibility with other React libraries you may be using (some may work without using compat).

I’ve mentioned this next reference in previous posts, but it’s a great example of what switching out for Preact can get you. It’s a by Google’s Addy Osmani. In the study, Treebo hotels swapped out React in favor of Preact and saw a 15% improvement in time-to-interactive. With so many in recent years showing the value of even modest improvements in performance, Preact is definitely something to consider.

Although…

InfernoJS

Another React alternative that can give your app a significant performance boost is . It also has the same API as React. And, like Preact, it features a helper library, inferno-compat, to allow almost full compatibility with the React ecosystem.

The thing that makes Inferno unique is that not only will it give you a boost in start up performance over React, it’s also much faster in UI performance. I’ve written previously on the topic of framework performance, but below I include some results from a benchmarking tool I have not highlighted before, . Here are the results for Inferno, Preact and React (click on image to see larger).

I want to draw your attention to a couple sets of numbers. We see values for each of the libraries under JS Init Time. Both Inferno and Preact are faster on this metric than React, with Preact fastest overall. This is because at 3KB, it’s the smallest of the three. Under first render time, however, we see Inferno come in far ahead of the other two libraries. That’s because Inferno is really damn fast. Even though Preact had a faster init time, by first render, Inferno was long gone. 🚀

It’s an interesting illustration that library size isn’t the whole story when it comes to start up performance. So although it doesn’t get mentioned as much as Preact, Inferno is a fantastic replacement for React that can deliver massive speed improvements to your app.

And Finally…

These libraries aren’t the only ones you can use to give your React app a boost, of course, but they’re some of my favorites. I also need to mention that adding the “compat” modules with Preact and Inferno will impact UI performance and add a small bit to your bundle size. If you’re interested in getting the most from those libraries, leave "compat" out (or use as a bridge) and adjust accordingly.

Until next time, happy coding…

]]>

Mon, 19 Feb 2018 12:57:00 GMT

When I first saw Svelte, the first thing that struck me was that it reminded me a lot of Vue. As I dug into a bit more, I realized that despite many similarities, there were also some big differences.

What follows is not the perspective of either a Vue or a Svelte expert. I build React sites at my day job. But I like a lot of what I see with both of these frameworks and I thought I’d share some of what I’ve found out about them.

Template Syntax

Both and use HTML-based template syntax. The most basic examples from their respective docs looks very similar.

Here’s Vue:


  {{ message }}

And here’s Svelte:

Hello {{name}}!

Pretty similar, right? Other template syntax differs, however. Here’s a loop in a Vue template:


  
    
      {{ todo.text }}

And now in Svelte:

Cats of YouTube

  {{#each cats as cat}}
    {{cat.name}}
  {{/each}}

If you look at the Vue syntax and think it looks just like AngularJS, you’d be right. In the case of Svelte, however, the curly braces are actually JavaScript expressions. So, they look similar, but work a bit differently. The differences are not so great that they add up to much, though. If you understand one, you’ll quickly grasp the other.

One thing I should note here is that Vue also supports JSX, which has been popularized by React. Svelte does not. And as far as I can tell, JSX is not that popular in the Vue community. It’s an option, though.

Single File Components

Both Vue and Svelte have the concept of single file components. This means that the HTML, JavaScript and CSS for a given component lives in a single file. It’s a simple, but powerful, idea and one that makes working with these two frameworks easier than some of the alternatives.

Here’s an example of a single file component in Vue:

You can see we have our template, script and style tags all in one place, and the CSS is automatically scoped to that component. Now let’s take a look at an example from Svelte:

<:Head>
  My project


  Hi there
  Boom!

Looks pretty similar, right? You may notice in the Svelte file above that it has a <:Head> tag. That’s a built in component that lets you add meta tags to the of your document. Vue doesn’t have anything similar included by default, but there are a couple libraries called and that you can use to acheive the same result. If we wanted to add the meta information to our Vue component using vue-meta, we’d need to update the script section to something like this:

import AppLogo from '~/components/AppLogo.vue'
export default {
  components: {
    AppLogo
  },
  metaInfo: {
    title: 'My project',
  }
}

A final point here is that the HTML and CSS in these examples are no different than what you are used to working with outside of JavaScript frameworks. This is in contrast to React, which as mentioned previously, uses JSX.

I’ve focused on the similar template syntax and single file components because if you’re building an app, you’re going to be spending a lot of time with these features. Before we move on, however, there are a few other similarities I’d like to briefly mention.

Both have reactive programming models (if the data changes, the view automatically updates). Both also have computed properties, lifecycle hooks, and custom methods. If you poke around in the docs for each of these frameworks, you’ll notice other common approaches and concepts...but there are also some major differences.

The Magical Disappearing UI Framework

Without question, the biggest difference is that Svelte is a compiled framework. From the docs:

…rather than interpreting your application code at run time, your app is converted into ideal JavaScript at build time. That means you don't pay the performance cost of the framework's abstractions, or incur a penalty when your app first loads.

The result of this is that Svelte apps will end up considerably smaller than those using Vue. To demonstrate this, I spun up the most basic Vue app possible using . It's a framework that has all the stuff you’d need to build a server-rendered Vue application with routing and state management. In fact, some of the code snippets above were adapted from the default Nuxt.js app.

Although much newer, Svelte has a similar framework called . It also has everything you need to build a server-rendered app with routing and state management. I’m not super familiar with the internals of these two frameworks, so perhaps Nuxt.js has something cool that Sapper doesn’t, but this was as close to an apples-to-apples comparison of a real app as I could get.

Here are the results for production builds:

Framework	Total JS size (minified, not gzipped)
Nuxt.js	182.1 KB
Sapper	11.4 KB 💥

Some comments about these numbers…they include all the JS files each framework loaded on the home page (both use code splitting). The Sapper number actually includes additional files that we probably should exclude to give a fairer comparison. There are two routes set up in Sapper that don’t exist in the Nuxt.js example (resulting in two additional files). If we remove those, then Sapper comes in at about 8KB. I mean, seriously…8KB! That’s incredible!

This shows up in performance benchmarks, as well. Below is a screenshot showing the start up metrics for Vue and Svelte from a popular . In the chart below, smaller numbers === faster performance.

Svelte is very fast, even faster than the vanilla JS example in two of the benchmarks. Svelte is hard to beat in this regard. I’m not saying Vue is slow — far from it. But if fast page loads are a priority on your project, Svelte is a framework to seriously consider.

The Progressive Framework

Another difference between these two frameworks is that Vue can be used as a jQuery replacement in a way that Svelte can’t. Sarah Drasner has done a great on this, so I won’t go into it further, but it highlights a versatility that Svelte — and many other frameworks — don't have.

And Finally…

The last difference I’ll note is that Vue has a much larger community and ecosystem. There are a lot of great available to help get you started and the third party libraries can speed up development.

That said, these are both great frameworks. Vue certainly deserves all the attention it’s received over the past year, and I hope you agree that Svelte should definitely be getting more attention that it currently does. It’s a young framework, so no doubt big things are ahead.

Until next time, happy coding…

]]>

Tue, 13 Feb 2018 12:40:32 GMT

I spend a good deal of time thinking about JavaScript frameworks. One thing that I've been considering lately is if the default choices — React and Angular mostly, but also Vue — are really the best choices for many of the projects that end up using them. What follows are some of my thoughts as I work through that question.

I've created a few hypothetical scenarios below that will hopefully illustrate the trade-offs that can arise when evaluating frameworks. They are loosely based on real situations I’m familiar with, and I’ll tell you now that there isn’t a “best” framework. It's about which one is best for your project and your team.

There is something called the project management triangle that will help frame our conversation. It’s illustrated in the graphic below:

The is this:

The quality of work is constrained by the project's budget, schedule and scope.
There are trade-offs between constraints. For example, a shorter schedule will increase costs, reduce scope or lower quality — or some combination of those. If one thing changes, something else has got to give.

As we go through these scenarios, we’ll see how these trade-offs come into play with our choice of software. In particular, we’ll see how the framework we choose might impact cost, schedule or quality.

Nobody Ever Got Fired for Buying IBM

There is an that goes, “Nobody ever got fired for buying IBM”. Several decades ago, this phrase was used to indicate that many organizations are risk averse and will often choose the option with the best track record, regardless of other factors. There is a lot of this that goes on with JavaScript frameworks.

It’s understandable, too. Imagine you’re the one choosing the technology a large front end project will use. It has a budget of $750,000. Now look at the project management triangle above and note the bottom two corners — cost and schedule. If you're worried about keeping a handle on those two factors, which feels like a safer bet — choosing React or going with Svelte?

With React, you know there will be abundant training resources, lots of experienced developers available if you need to grow your team, and a large ecosystem that can help accelerate development. Those advantages can help you keep both the project on schedule and control costs. That safety explains why a lot of projects stick with React (and Angular), but as we’ll see, many — but certainly not all — would benefit from making other choices.

The Java Team Branching Out

Let’s imagine a hypothetical team of Java developers that are going to build a front end for a large project at their company. Yes, they’re back end devs, but they’re smart and have proven themselves on big projects before. Plus, they want to do the project. When upper management talked about bringing an agency in to help, the team lobbied against it. They could handle it in-house, they said.

This sort of thing actually happens, and when it does, it introduces some additional risks. The choice of framework here is important because choosing one that will slow the team down will likely blow up the schedule, and because they aren’t well-versed in front end, they’ll be slower anyway. Not good. Project schedules are fantastical enough as it is.

The team was aware of these risks, so they wanted to go with a well-established framework — the safety thing — and I don’t blame them. The two choices they narrowed it down to were React and Angular. Which one should they choose?

The Smart Choice

For this team, the choice is clear — Angular. There are a couple of reasons. The first is that React is famously, “just a view library”. There are going to be a lot of decisions that need to be made by this team if they pick React. Which state management solution will they use? What about routing, http, and everything else? Does anyone know how to configure webpack? With Angular, all of these decisions are made for you. One major obstacle averted.

Since this is a large project, this team will probably end up picking Redux as the state management library. Some people argue that paradigms don’t or shouldn’t matter that much. In my experience, however, they do matter. A team of Java developers will be very well-versed in object-oriented programming techniques. Redux, a functional library, will probably slow them down.

Paradigms like object-oriented or functional programming, help developers form mental models and shortcuts that they use to solve common problems more quickly and with fewer bugs. When you adopt a new paradigm, many of your shortcuts are gone and you may find yourself struggling with the new patterns and unfamiliar syntax.

The scenario outlined above is based on an article I read about a team of C# developers who took on a React/Redux project and struggled. Their big problems were understanding the patterns and best practices they should be using. If that team had chosen Angular, which generally encourages an object-oriented approach, I doubt they would have had as many difficulties. They would have been working in a familiar paradigm, with well-defined patterns, and with much of the required functionality provided for them.

The point here is that when picking a framework, the skills of your team matter, particularly if the schedule is tight. If your schedule is looser, experimenting can have some big advantages, but beware of the added risks.

The Need for Speed

Our next scenario involves a client services team that is experienced in building React applications. They have a good boilerplate that they can use to get off to a fast start and they are highly confident they can solve any problems that arise both quickly and effectively.

The client, however, has said that their highest priority is performance. The app has to load quickly and it has to perform well on slow mobile networks. Should they use React?

Probably not.

If we think back to our project management triangle, we feel confident that our team will be able to produce a React app on budget and on schedule. But what about the quality? That’s a slippery thing, isn’t it? Because what do we mean when we talk about quality? The app will no doubt be put together well. It will be a fine React application. But will it best meet the most important client criterion, performance?

You can definitely make a pretty fast React app. I do it regularly in my work at a client services agency. But you will be able to deliver more value — a higher quality product — in this case if you choose a different framework or library. Why is this so?

Performance First?

In recent years there have been a lot of that demonstrate that even modest performance gains can give a big boost to important business metrics — conversion rate, revenue, time on site, and other measures. Basically, more money, donations or whatever else is important.

Addy Osmani published a a while back about a hotel chain in India that converted their site from React to a progressive web app (PWA) using Preact. Obviously a PWA is going to provide benefits beyond whatever framework you use, but the move to Preact, “…was responsible for a 15% improvement in time-to-interactive alone.”

Who wouldn’t want a 15% improvement in time-to-interactive? And if you’re not familiar with Preact, it’s a 3KB library with the same API as React and improved performance is its main selling point. Having the same API as React makes it very attractive and there is even a companion library called preact-compat that allows you to use almost all libraries in the React ecosystem.

Some time after reading the case study from Addy, I saw this tweet from James Kyle:

Serious Q: How many of you can confidently give a reason for not replacing React with Preact in your app that doesn't amount to laziness?
— Jamie (@jamiebuilds)

Admittedly, James was drunk at the time of that tweet (his words, not mine), but I still think he had a pretty good point. There were some as to why some folks needed React, but not many. I think James is wrong about it being down to laziness, however. It’s that IBM thing…the safe bet, the long track record.

Considering what we know about the benefits of performance, why not make it the top line consideration for all projects? Start with fast and let other considerations fight for the spot at the front of the line?

And this is not a bash on React! Preact exists because of React. And I’m just using Preact as an example here. You could go with Inferno, Svelte or perhaps a couple others.

The point in this scenario is that the safe bets — React, Angular and even Vue — come with a trade off. They aren’t the fastest frameworks. Are they fast enough? That depends on the project. They may very well be fast enough. There are also a lot of other considerations besides speed that may push their way to the top.

Imagine that our client in this situation wanted a very fast app, but the schedule was extremely tight. Maybe it’s even tied to a hard deadline like a television broadcast or music festival. I’ve worked on a project like that, and that changes things a bit, doesn’t it?

I’m sure you can think of many other complicating factors. The point here is that the safe bet isn’t always the best choice. Not prioritizing performance may leave some money on the table. Maybe a lot of money.

I Love Shiny Pennies

Next scenario. A client has come to me and they want a fast site, but they have a really tight deadline. I’ve seen the client’s analytics and I know they will get huge value if we build them the fastest site possible. I recommend Sapper.

What the hell is Sapper, you ask? Well, scenario aside, Sapper is a real framework built on Svelte. I have a bit of a crush on it. It’s shiny and new — and super fast. You can read more here, but the relevant point for our scenario is that Sapper is not a mature framework at this time.

As the deadline approaches, some problems arise. Perhaps Sapper has a few bugs that are slowing development. Maybe I don’t quite know what I’m doing with it because it’s new. Probably a bit of both. I’ve blown the schedule. I start to question my life choices and break into a cold sweat before every client call. I’ve descended into the fifth hell of software development and it’s entirely my own fault.

It's a very unpleasant scenario. This sort of thing happens, though. It’s part of the reason why people go with the safe bets. The point here is to balance performance with other factors — framework maturity, the experience you and your team have with it, among other factors. It can save you a lot of pain.

Big Fish, Little Fish

I know most of you reading this will choose one of the big three — React, Angular and Vue. That’s cool and I totally understand. They’re all great and I use React everyday at work. There are good reasons for choosing them. However, one point I hope you’ll take away from this discussion is that there are some lesser known frameworks out there that deserve more consideration than they get. And using them could yield some major benefits.

Hopefully the Sapper example didn’t traumatize you, because picking Preact or Inferno is actually pretty low risk for a React team, and they can deliver real gains. 💰 In time, I’m confident Sapper will be a great choice as well. If your deadline allows, using a to evaluate your options is time well spent.

Until next time, happy coding…

]]>

Sun, 11 Feb 2018 16:58:14 GMT

Over the past week or so there have been some conferences and workshops announced that look outstanding. They are mostly focused on the front end, but the last one on this list will have a lot of great sessions on Node.js and other back end topics.

Framework Summit 2018

I’m really excited about this one! Instead of a conference that focuses solely on React or Angular, for example, is open to speakers on any JavaScript framework. There is already a great line up, with more to be announced as sessions are submitted. The speakers so far:

Chris Fritz (Vue core team)
Tyler McGinness (React trainer)
Sean Larkin (webpack)
Merrick Christensen (former ng-conf organizer)
John Papa (Microsoft developer advocate)
Lin Clark (Mozilla)
Dan Wahlin (trainer, consultant, speaker)
Richard Feldman (author, Elm expert)

The location for the event is Park City, Utah, which is absolutely beautiful. It’s being held October 2nd and 3rd (Looks like October 1st will be pre-conference workshops). Early bird tickets are $650 and are available until May 1st.

I’m seriously considering this one, so if you’re going to attend and want to grab a drink or what not, let me know!

Workshop.me

When I saw the line up for this one, I was super impressed. is actually a series of workshops that will be held across the United States and taught by some of the highest profile folks in the JavaScript community.

Want to from its creator, Evan You? That one is happening in New York, April 19th and 20th. Or maybe learn pro Angular with Todd Motto? Todd is teaching in July. This series of workshops really makes me wish I had a larger training budget!

Some of the other instructors include:

Kent C. Dodds
Sarah Drasner
Ken Wheeler
Ryan Florence (the guy behind Workshop.me)
Sean Larkin

It’s a great line up, and if you really want to learn one of the topics being covered, these workshops will be hard to beat. You can view the full schedule .

JS Interactive

Last year this event was called Node.js Interactive, and, as the name suggests, it focused primarily on Node topics. I attended and it was a lot of fun. This year the Node.js Foundation is teaming up with the JS Foundation and broadening the scope of the conference to bring you . This one is a bit cheaper, only $250 for the early birds. Also, it’s being held in Vancouver BC, which is a great city. If you love seafood, then you’re in for a real treat because Vancouver has an abundance of amazing seafood restaurants.

How to Decide?

All three of these sound pretty great, right? How do you decide which one to attend? Well, it depends on what you want to get out of it. Last year when I attended Node.js Interactive, it broadened my horizons because I work mostly on the front end. That said, workshops are typically a better learning experience.

For example, if you’d like to , how can you beat a two-day course with Evan You where you spend the first day going deep on Vue.js core and the second on building scalable enterprise applications? You can’t!

Conferences can be great learning experiences, and many have pre-conference workshops (for an extra fee), but they are mostly about community and connections — and great parties! If you’re in it to learn, the workshops are probably your best bet.

Until next time, happy coding…

]]>

Mon, 05 Feb 2018 17:47:05 GMT

Before we look at the numbers, I’d like to note a few things about the data and how the frameworks are grouped. I recently published a large reference guide for JavaScript frameworks. The groupings — Big Three, Historically Significant and Notable — come from that guide. I find it’s a useful way of breaking them into manageable chunks.

In that guide there are also two frameworks included under, “Notable” that are not addressed here: Elm and ReasonReact. Those two have factors that make their daily npm download data (which is what we’ll see below) a poor or confusing indicator of usage. It was simply not an apples-to-apples comparison with the other frameworks listed here.

We’ll look at the most recent data available at the time I wrote this article and compare it to a year previous. This is something I do every three months or so. The numbers are for daily downloads and are sourced from .

The Big Three

These three frameworks — React, Angular and Vue — are currently the most popular. Although all three are going strong, Vue has a lot of momentum. Last year it topped all other JavaScript frameworks in , but still trails React and Angular in usage as seen in the chart below. You can click on all the charts in this post to view them larger.

Framework	Jan. 29, 2017	Jan. 28, 2018	Percent change
React	708,421	1,786,699	152.2%
Angular	229,375	609,087	165.5%
Vue	60,283	299,840	397.4% 🚀

We see Vue with the highest growth rate, and if current trends continue, Vue will overtake Angular as the second most used framework sometime in late 2018 or early 2019.

Historically Significant

This is a group that contains three older and highly influential projects. In 2012, these were the “Big Three”. They have since seen their popularity fade relative to newer frameworks. Despite no longer being in the top three, they all continued to see growth over the past year.

Framework	Jan. 29, 2017	Jan. 28, 2018	Percent change
AngularJS	169,245	310,622	83.5%
Backbone	139,392	190,721	36.8%
Ember	72,966	91,179	25%

You’ll notice that in the data here AngularJS actually has more downloads than Vue. This is down to some weird variability in the numbers. Late last year Vue passed AngularJS. As you can see in the chart, AngularJS had an unusual surge at the end the period being measured. It won’t change the long term trend of Vue being more widely used, however.

Notable

This is a group of frameworks that I really love. They aren’t as popular as the “Big Three”, but they’re all good. In fact, a few of them are excellent and deserve more consideration than they get. The chart here is a bit noisy with three of the frameworks bunched together at about 7500 downloads per day.

Framework	Jan. 29, 2017	Jan. 28, 2018	Percent change
Preact	8293	29,385	254.3% 🚀
Inferno	2057	7744	276.5% 🚀
Aurelia	5151	7689	49.2%
Polymer	4223	7356	74.1%
Svelte	521	1831	251.4% 🚀

There are three that stand out here: , and . They all have outstanding growth rates that are only exceeded by Vue. Obviously Preact is the leader in this group, being the most popular alternative to React.

If you’d like to learn more about these three frameworks, I have an article about why you might want to use them. Spoiler: they're all really fast.

And Finally…

]]>

Tue, 30 Jan 2018 13:00:00 GMT

This month we have a lot of high quality writing. And it covers a lot of ground — front end frameworks, Node.js, npm security, machine learning and more. We'll kick things off with a look at which projects have been the most popular over the past year...

This one is pretty cool. It ranks JavaScript projects by the increase in GitHub stars the projects had over the past year. The big winner in 2017 — Vue! In fact, Vue is getting very close to topping React for most stars overall, despite lagging behind in usage.

Another surprise for me was the strength of Preact. It had almost as many new stars as Angular. It’ll be interesting to see where things land next year.

Burke Holland wrote this article and it's loaded with great tips on getting the most from Visual Studio Code. I switched to VS Code a few months ago from Atom and love it. It’s so good I almost forgive Microsoft for all the years I’ve spent hacking around Internet Explorer.

The Ultimate Guide to JavaScript Frameworks

This is one of my articles from earlier this month. It’s a huge guide that aspires to be a reference to all known JavaScript frameworks. Despite having write-ups on over 50 frameworks, I have a list of other frameworks people have shared with me that need to be added. I’ll be tackling that this weekend…lots of ClojureScript ones I missed.

Gatsby is freakin’ great and should be used more often. It’s not right for every project — for example those that need authentication. But if it’s a fit, you get a great developer experience and a really, really fast site.

You can also use it as a decoupled front end. Write your content in WordPress, Drupal or Contentful (among others) and publish with Gatsby. 🎯

The Best JavaScript Frameworks You’re Not Using

A lot of discussions of front end frameworks begin and end with the “Big Three” — React, Angular and Vue. That’s too bad because there are some fantastic alternatives, particularly if performance is your top consideration. In this article, I introduce you to three frameworks that are excellent choices — two of which are easy for React developers to pick up.

This article from Samer Buna is filled with solid tips, particularly for folks who are new to React. Most of these are just general tips for JavaScript, so it’s worth a read even if you aren’t learning React.

I thought this article was a bit scary. It’s a look at how incredibly vulnerable npm packages can be. But it’s not all doom and gloom. Author David Gilbertson ends with solid advice on building more secure applications. He’s followed this article up with part two, . Highly recommended.

Building a boilerplate is a fantastic learning experience. There are great CLI tools that help you get started building applications quickly — Create React App, for example — but what happens when you need to understand how it’s all put together? Consider making a boilerplate for yourself, even if you don’t end up using it.

If you’d like deeper insight into how React works, this article from Gurusundesh Khalsa is a great place to start. He walks readers through the process of building a simplified, “mini React” clone. Good stuff.

Deep post here from Robin Wieruch. The article is specifically targeted at web developers who want to learn more about machine learning and still leverage their existing knowledge of JavaScript.

Spoiler alert: Go is insanely fast. I think that when Go supports WebAssembly, there’s going to be a surge in JavaScript developers learning the language.

Static typing in JavaScript is becoming more popular and TypeScript is leading the charge. Todd Motto provides this excellent introduction.

Sapper — The New JavaScript Framework You Seriously Need to Try

You may not have heard about Sapper, but it’s really great. It’s built on top of the Svelte library and makes it easy to build very lightweight, very fast websites. If you like the way Vue works, it’s another good reason to check this framework out.

State machines sound kind of complicated and scary. However, Jean-Paul Delimat does an outstanding job of explaining how, when and why you might want to use them in your React applications. Also, not scary at all.

My favorite tip is to use the displayName property for debugging. Say you have multiple instances of a component, for example a form input. You can set the displayName to easily tell them apart in DevTools. 👍

And Finally…

Until next time, happy coding…

]]>

Fri, 26 Jan 2018 11:54:00 GMT

Over the past couple of weeks some really cool new libraries have come out. Two of them are from the insanely prolific , the author of Preact. The third is from , who created the framework.

Workerize

We’ll kick it off with from Jason Miller. It allows you to export a JavaScript module into a Web Worker. The benefit is that this allows you to pass off computationally heavy code to a separate thread and not bog down the performance of your app.

aren’t a part of JavaScript, but rather a HTML5 browser feature that can be accessed by JavaScript. And they aren't always a performance boost because they have a bit of overhead to them.

I found an interesting that you can play around with to see the sort of benefit you might expect. I'm not sure how "real world" that benchmark is, but for some solid Web Worker performance tips, is a good place to start.

Stockroom

picks up on the theme of Web Workers. It's a companion to another one of Jason Miller’s libraries, , which is a tiny state management library he wrote to complement Preact. Unistore is similar to Redux, but even smaller (650 bytes).

Stockroom runs a Unistore store and its actions inside a Web Worker. He’s created a graphic that nicely demonstrates the advantages of Stockroom:

The UI of your app is in one thread and logic and network calls are in another. This division of labor may give you a significant bump in performance.

Redux-Bundler

If you’ve used Redux before, you know it has a fair bit of boilerplate. This is probably the biggest gripe developers have with it. isn’t a bundler in the sense that webpack is. Instead, it allows you to group Redux functionality into “bundles” and then it composes them into a Redux store.

From the README:

In this way you group related reducers, selectors, action creators. Redux-bundler then takes bundles like this and combines them all into a store and pre-binds and attaches everything to the redux store itself.

It looks really slick and Henrik says it’s not a “toy” project, but already being used on some of his production apps.

And Finally...

Until next time, happy coding…

]]>

Tue, 23 Jan 2018 11:41:03 GMT

In my writing here on JavaScript Report, I try not to be a cheerleader. But every once in a while something comes along that gets me excited. is one of those things. It’s a new JavaScript framework built on top of the Svelte library. If you like fast websites, you’re going to love Sapper.

First, a bit about . It works differently than some of the other front end libraries/frameworks that you may be familiar with. Your code is compiled at build time and this has big performance benefits. In fact, Svelte is one of the best performers in .

However, Svelte is similar to React in that it leaves things like routing, build process, etc. to the developer. Those things can be a lot of work to implement. That’s where Sapper comes in. It’s a framework that takes care of all that heavy lifting. It includes things like:

Server rendering
Routing
Code splitting
Progressive web app by default
Prefetching of routes
Per route head tags (meta, link, etc.)
Ejecting as a static site
Cypress tests (free, easy, end-to-end testing)

If you’re familiar with , the framework built on top of React, it’s the same idea, but with one major difference — better performance.

To test the potential performance benefits of Sapper, I decided to do a quick comparison of it with Next.js. In each case, I followed the basic “Getting Started” instructions for each framework. Both have very good documentation, so this part was smooth for both, although Svelte includes some demo routes, which was nice.

I then did a production build for both and the results were pretty amazing. Check it out:

Framework	Total JS size (minified)
Next.js	205 KB
Sapper	11.4 KB 💥

I ran these tests three times thinking I had made a mistake, but no, those are really the numbers. Keep in mind, I was just stepping through the basic tutorials and there could be some cool things in the Next.js bundle that I don’t know about. But my first impression is — Wow!

Why This Is a Big Deal

Over the past few years there have been a lot of published about web performance. The results show that even modest performance improvements can have very big impacts — more revenue, more user engagement, and reduced costs. One quick statistic from — 53% of mobile sites that take longer than 3 seconds to load are abandoned. That’s pretty sobering.

In a , Addy Osmani dug deep into why JavaScript has an especially big impact on web performance. A 100KB JavaScript file is not equivalent to a 100KB image. This is because JavaScript has parse and compile costs:

Spending a long time parsing/compiling code can heavily delay how soon a user can interact with your site. The more JavaScript you send, the longer it will take to parse & compile it before your site is interactive.

As a developer, I often forget that the average user has a much slower phone than I do. Below is an image that serves as a great reminder. It’s from Addy’s article and shows parse costs for 1MB of uncompressed JavaScript. The device highlighted in red is the average device (click image to view larger).

From the article:

There is a 2–5x difference in time to parse/compile code between the fastest phones on the market and average phones.

The article goes on to give a real-world example — the CNN website.

On the high-end iPhone 8 it takes just ~4s to parse/compile CNN’s JS compared to ~13s for an average phone (Moto G4). This can significantly impact how quickly a user can fully interact with this site.

Frameworks offer a lot of benefits to developers. They accelerate development, reduce bugs, and provide consistency across projects. They also have a lot of little things that add to “developer experience” and make our lives easier. Most of these things, however, come with a cost.

Frameworks like Sapper provide the best of both worlds — great developer experience and outstanding performance for users. Even on mobile!

One Caveat

For Sapper, it’s still early days. As the guide states:

Sapper is in early development, and some things may change before we hit version 1.

A very young framework like this isn’t going to be the right fit for every project, of course. But I’m excited to see what the future holds for Sapper. I plan on using it myself for an upcoming project. I’ll let you know how it goes!

Until next time, happy coding…

]]>

Tue, 16 Jan 2018 13:02:00 GMT

Updated March 4, 2018: Added CxJS, Stencil and Stimulus.

Keeping up with JavaScript frameworks can be a challenge. There are a lot of them, and seemingly another one every month. How do you know which ones might be right for your project? What are their strengths and weaknesses? How do you get started?

That’s where this guide comes in. It’s a living document that is a reference for all known front end JavaScript frameworks (archived or deprecated projects are not included). In this case, the term “frameworks” is being used in a broad sense. It includes user interface (UI) libraries like React, as well as full frameworks like Angular.

Why Is This Useful?

Some of you may be wondering why a guide like this is useful. Most readers will end up using one of the frameworks I call the "Big Three" — React, Angular and Vue. That's OK. They're great choices. That said, a guide like this has value. Here's an example...

Perhaps you've heard of the Dojo framework. Probably not, though. Dojo focuses on a couple of things that make it unique — accessibility and internationalization. All Dojo widgets are accessible by default and it provides everything needed to internationalize an application.

Another example...maybe you're making an app that needs excellent performance on mobile networks. There are a number of very good, high performance libraries and frameworks listed below that may just fit the bill.

There are also small frameworks that provide a fantastic opportunity for learning. You can dig into the code and find out for yourself how one goes about building this kind of software. Ultradom is a library that you can use to build your own framework. Very cool, right?

How This Guide Is Organized

The frameworks are broken up into broad categories — you’ll see that in the listing tables below. To the extent possible, each framework will have a section that explains the rationale for the framework, it's pros and cons and some additional learning resources.

If you are a framework author — or a fan of one — and you don’t see your framework listed, or wish to correct some information, on Twitter. I’ll be happy to add or update the listing.

Guide to icons:

The icons below are meant to help readers understand general framework characteristics and tendencies. They are only rough guides.

🔥 Performance: A top five performer in
Functional programming paradigm
Reactive programming paradigm
Object-oriented programming paradigm
TypeScript as primary development language

DIO 🔥

Dojo

Domvm 🔥

Hyperapp 🔥

Ivi 🔥

petit-dom 🔥

RE:DOM 🔥

Riot

Surplus 🔥

Ultradom 🔥

The Big Three

The three frameworks that currently dominate in popularity and usage are React, Angular and Vue. They each have large communities and lots of training resources available. If you’re a new developer learning a framework to help you get a job, these three are your best bets. Here's a look at their npm downloads over the last six months:

We can see that React is far ahead of Angular and Vue. What is less apparent is that Vue has had roughly double the growth rate over the past year compared to Angular. If GitHub stars are an indicator of developer enthusiam or interest, then Vue looks strong there as well, with 79,000 stars compared to Angular's 32,000. React has almost 86,000 stars at this writing.

React

was introduced as an open source project in May, 2013. The original author was Jordan Walke, an engineer at Facebook.

React bills itself as, "a JavaScript library for building user interfaces", as opposed to a full framework like Angular. Concerns like routing, state management and data fetching have been left to third parties. This has resulted in a large and very active ecosystem around React.

Many large React applications will use the popular library for state management and for routing, but there are other good alternatives available.

React is responsible for popularizing principles among a new generation of developers. Although not a purely functional library, it allows developers to work in a largely functional style, particularly when combined with Redux.

For more information on how React compares to the other popular frameworks, see my article on React and Angular, and this one on React and Vue.

Pros

Hugely popular with a strong job market
Lots of training resources and third-party libraries to help accelerate development
Best choice for cross-platform teams (web, mobile, desktop, other devices)
Versatile
Strong corporate support (Facebook)

Cons

Abundance of choice can be overwhelming at first
Best practices not always clear to newcomers
Learning curve can be steep for building larger applications

Additional Resources

(Free video course)

⬆️ Return to top

Angular

is the successor to AngularJS. It is a full-featured and opinionated framework that provides defaults for data fetching, state management, development language, and build toolchain.

Perhaps the most notable feature of Angular is its use of as the development language. This has made the framework to those coming from traditional object-oriented languages like Java and C#, as TypeScript takes inspiration from those languages.

It's been said that "enterprises" are the the target users for Angular. In the sense that many large companies have teams familiar with Java and other object-oriented languages, this may be correct.

Pros

Full-featured framework with well-tested defaults
TypeScript provides familiar language for those with background in object-oriented programming
Strong corporate support (Google)
Clear best practices

Cons

Learning curve can be steep
TypeScript may be a barrier to adoption
Poor start up metrics in benchmarks

Additional Resources

(Free video tutorial)

⬆️ Return to top

Vue.js

Although often seen as the "new kid on the block", has been around since 2013. Evan You is the creator and primary developer, and unlike React and Angular, Vue is not directly supported by a major company. It instead relies on individual and corporate donations.

Of the three most popular frameworks, Vue is widely considered to be the easiest to learn. It is similar to React in many respects, but also has things in common with AngularJS — for example, directives and templates.

Vue's relative simplicity, developer experience, and good performance have contributed to a huge surge in its popularity.

One notable feature of Vue is that it's a "progressive framework" and can be used as a jQuery replacement as well as for large single page applications. From the Vue documentation:

Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects.

While Angular is opinionated and React agnostic about concerns like routing and state management, Vue takes a middle approach, with official routing and state management solutions that are optional, but kept in sync with the core library.

To learn more about how Vue compares to React, see my article that reviews the differences.

Pros

Easy to learn
Good documentation
Surging in popularity and usage
Best performance of top three frameworks

Cons

Current job market is less than that for React and Angular

Additional Resources

(Free video course)

⬆️ Return to top

Historically Significant

There was a time some years ago when these frameworks would have been considered the "Big Three". Although less popular today, they are still widely used and have been influential in the development of later frameworks.

AngularJS

In 2013, was the most popular framework. Some of the factors contributing to its popularity during that period were its MVC architecture, declarative programming style, two-way data binding, and robust feature set.

AngularJS has an opinionated approach and aims to provide developers with a :

AngularJS is not a single piece in the overall puzzle of building the client-side of a web application. It handles all of the DOM and AJAX glue code you once wrote by hand and puts it in a well-defined structure. This makes AngularJS opinionated about how a CRUD (Create, Read, Update, Delete) application should be built. But while it is opinionated, it also tries to make sure that its opinion is just a starting point you can easily change.

In late 2013 React was introduced. React used unidirectional data flow and argued that two-way data binding made it difficult to understand applications, particularly as they scaled. In 2014, the Angular team announced Angular 2, which would subsequently be renamed to simply, Angular. This new version would introduce unidirectional data flow among other . This marked the beginning of a long decline in the popularity of AngularJS.

Despite the growth of its successor project, AngularJS is still widely used and is in active development.

Pros

Abundant training resources
Good documentation
Very well established
Full featured

Cons

Two-way data binding, other technical issues that may not be desirable
Declining popularity

Additional Resources

⬆️ Return to top

Backbone

Authored by Jeremy Ashkenas, who also created CoffeeScript, was initially released in the fall of 2010. A key part of the Backbone ecosystem is , a framework that simplifies development.

Backbone is significant because it was one of the first frameworks to bring more structure to front end applications by implementing a . From the documentation:

The single most important thing that Backbone can help you with is keeping your business logic separate from your user interface. When the two are entangled, change is hard; when logic doesn't depend on UI, your interface becomes easier to work with.

In recent years Backbone has seen a decline in usage, although it continues to be shipped in the latest version of the Drupal content management system. One relevant on a possible reason for the decline:

Backbone’s author, Jeremy Ashkenas made a decision to call Backbone “finished” in terms of API and feature set after the 1.0 release. This has the advantage of leaving Backbone as by far the most stable major JavaScript framework, but hinders efforts to pull in lessons from other frameworks

Pros

Provides code structure
Stable project

Cons

Declining popularity
Imperative programming style (as opposed to popular declarative style)

Additional Resources

⬆️ Return to top

Ember

was authored by Yehuda Katz, a prolific creator or contributor to numerous open source projects. Ember is based on the MVVM pattern and has a rich feature set. It also has a strong :

Ember sets out to provide a wholesale solution to the client-side application problem. This is in contrast to many JavaScript frameworks that start by providing a solution to the V in MVC (Model–View–Controller), and attempt to grow from there...

Ember is one component of a set of tools that work together to provide a complete development stack. The aim of these tools is to make the developer productive immediately. For example Ember CLI, provides a standard application structure and build pipeline. It also has a pluggable architecture and over 3500 addons to enhance and extend it.

One of the major criticisms of Ember is its large size, which has a negative impact on performance. Ember is also viewed as having a steep learning curve and difficult to master.

Pros

Clear best practices
Very well established
Full featured

Cons

Large size
Steep learning curve
Declining popularity

Additional Resources

⬆️ Return to top

Notable

The frameworks listed in this section all have good documentation and healthy communities around them. Although they aren’t as widely used as "The Big Three", they fill important niches and are notable for their unique or innovative approaches.

Aurelia

, authored by Rob Eisenberg, can be seen as a decendant of both AngularJS and Eisenberg's previous framework, Durandal. Prior to creating Aurelia, Eisenberg was a part of the Angular team, leaving in late 2014 over disagreement with the direction of the Angular 2 project.

Aurelia is a complete framework. Here's the basic pitch from the documentation:

Aurelia provides core capabilities like dependency injection, templating, routing and pub/sub, so you don't have to piece together a bunch of libraries in order to build an application. On top of this rich core, Aurelia also provides a number of additional plugins for internationalization, validation, modal dialogs, UI virtualization and much more.

You also don't have to cobble together a bunch of different tools. Aurelia provides a CLI for generating and building projects, a browser plugin for debugging and a VS Code plugin as well. Yet, you're not forced to use any of these as Aurelia is structured to enable you to swap out any detail, even down to the templating/binding engine, in order to guarantee maximum flexibility.

Pros

Complete solution
Language agnostic, works with JavaScript, TypeScript and other languages
Stable API

Cons

Smaller community vs top frameworks
Fewer job opportunities

Additional Resources

⬆️ Return to top

Elm

is somewhat unique on this list. Rather than a typical framework, it's actually a separate language that compiles to JavaScript, similar to Reason. However, it positions itself as an alternative to React:

Elm is a functional language that compiles to JavaScript. It competes with projects like React as a tool for creating websites and web apps. Elm has a very strong emphasis on simplicity, ease-of-use, and quality tooling...I can safely guarantee that if you give Elm a shot and actually make a project in it, you will end up writing better JavaScript and React code.

Elm has also been highly influential, including being one of the sources of inspiration for the popular state management library.

The basic advantages of Elm:

Forget what you have heard about functional programming. Fancy words, weird ideas, bad tooling. Barf. Elm is about:

No runtime errors in practice. No null. No undefined is not a function.

Friendly error messages that help you add features more quickly.

Well-architected code that stays well-architected as your app grows.

Automatically enforced semantic versioning for all Elm packages.

No combination of JS libraries can ever give you this, yet it is all free and easy in Elm. Now these nice things are only possible because Elm builds upon 40+ years of work on typed functional languages.

Pros

Elimination of virtually all runtime errors
Strong architecture
Simplified refactoring

Cons

Interoperability with JavaScript required in some cases (added complexity)
Smaller commmunity
Fewer job opportunties

Additional Resources

⬆️ Return to top

Inferno

If performance is your primary concern, might be the framework for you. Originally authored by Dominic Gannaway — now a member of the React team — Inferno was initially designed to prove that a JavaScript framework could perform well on mobile devices.

Inferno started as an idea two years ago, to see if a UI library could really improve the experience, battery, memory usage and performance on mobile devices. At the time we really struggled to get good performance on any UI library/framework – it simply wasn't happening...

Inferno proves that it is possible to be fast on mobile...In terms of performance, Inferno is currently the fastest JavaScript UI library there is – both in benchmarks and actual real-world scenarios. It excels on the browser at initial page load, parse times, render times and update times. Inferno's server-side rendering is around 5x faster than React, around 3x faster than Angular 2 and around 1.5x faster than Preact and Vue.

Inferno has an API that is very similar to React and it's possible to port a React app directly to Inferno using the inferno-compat library.

Inferno also has it's own router, soon to be updated to match the API of React Router 4, and is compatible with the Redux and MobX state management libraries.

Pros

Excellent performance
Familiar API for React developers
Good documentation

Cons

Small community
Using inferno-compat may impact performance

Additional Resources

⬆️ Return to top

Polymer

is a Google-backed libary focused on , a proposed group of technologies that are currently not well-supported in browsers. Polymer, along with the Polymer App Toolbox, helps developers use these technologies today to build web applications.

Polymer is a lightweight library that helps you take full advantage of Web Components.

With Web Components, you can create reusable custom elements that interoperate seamlessly with the browser’s built-in elements, or break your app up into right-sized components, making your code cleaner and less expensive to maintain.

Polymer sprinkles a bit of sugar over the standard Web Components APIs, making it easier for you to get great results.

A primary motivation of the Polymer project is to move the web platform forward. The Polymer team have a #UseThePlatform hashtag that they explain on their About page:

...there are real costs to doing too much outside and above the platform itself—costs that both developers and users pay. Developer costs come in the form of complexity and lock-in.

Over time, the stacks we’ve built on top of the platform have pushed web development further and further from the simplicity of view-source and shift-refresh, to a place where every project begins with an overwhelming sea of choices.

Thanks to new web platform primitives, many of the needs we’ve addressed by building over and around the platform can now be met by the platform itself...

We believe the patterns, libraries and tools we work on are beneficial, and we're happy to see them widely adopted. But our campaign to #UseThePlatform is ultimately not about driving people to use the stuff the Polymer Project builds. It’s about promoting the use of the web platform to deliver the best apps possible

If you've followed Google's much-appreciated efforts to promote the web platform over the years, much of this will sound familiar and in line with other efforts from the company.

Pros

Strong corporate support (Google)
Supports emerging web standards

Cons

Community complaints around communication
Poor browser support limits options/implementation of vision

Additional Resources

⬆️ Return to top

Preact

Authored by Jason Miller, is a well-established React alternative that emphasizes small library size. Coming in at 3KB gzipped, Preact uses the same API as React and is compatible with much of the ecosystem.

Preact itself is not intended to be a reimplementation of React. There are differences. Many of these differences are trivial, or can be completely removed by using preact-compat, which is an thin layer over Preact that attempts to achieve 100% compatibility with React.

The reason Preact does not attempt to include every single feature of React is in order to remain small and focused - otherwise it would make more sense to simply submit optimizations to the React project, which is already a very complex and well-architected codebase.

Preact is used by a number of large organizations including Lyft, Pepsi and . Although Preact has better start up performance (page load, for example) than React, in the latest benchmarks React is faster at updating the UI once the page is loaded.

Pros

Lightweight
Good documentation
React-compatible

Cons

Smaller community than React (but lots of overlap, intermingling)
Using preact-compat may impact performance

Additional Resources

⬆️ Return to top

Reason

In a way, can be thought of as a part of the React ecosystem. However, it is much more than that. Reason is a syntax on top of the OCaml langauge. It can compile to JavaScript, but it can also compile to assembly and be used to build desktop and mobile applications. Here's some further explanation from the documentation:

Reason is not a new language; it's a new syntax and toolchain powered by the battle-tested language, OCaml. Reason gives OCaml a familiar syntax geared toward JavaScript programmers, and caters to the existing NPM/Yarn workflow folks already know...

Reason compiles to JavaScript thanks to our partner project, BuckleScript, which compiles OCaml/Reason into readable JavaScript with smooth interop. Reason also compiles to fast, barebone assembly, thanks to OCaml itself.

Reason (sometimes referred to as ReasonML) has a companion project, :

ReasonReact is a safer, simpler way to build React components, in Reason.

By leveraging the latter's great type system, expressive language features and smooth interoperability with JS, ReasonReact packs ReactJS' features into an API that is:

Safe and statically typed

Simple and lean

Familiar and easy to insert into an existing ReactJS codebase

Well thought-out (made by the creator of ReactJS himself!)

It is often said that writing ReactJS code feels like "just using JavaScript". The same applies to ReasonReact, but we push it further; writing routing, data management, component composition and components themselves feel like "just using Reason".

Pros

Strong corporate support (Facebook)
Good documentation
Versatile
Familiar for React developers

Cons

Very new??

Additional Resources

⬆️ Return to top

Svelte

Authored by Rich Harris, takes a unique approach. It compiles your app at build time so that you ship the lightest weight code possible. From the documentation:

...Svelte has a crucial difference: rather than interpreting your application code at run time, your app is converted into ideal JavaScript at build time. That means you don't pay the performance cost of the framework's abstractions, or incur a penalty when your app first loads.

And because there's no overhead, you can easily adopt Svelte in an existing app incrementally, or ship widgets as standalone packages that work anywhere.

An interesting project related to Svelte is , a framework similar in philosophy to , but with a greater emphasis on performance.

Sapper is a framework for building extremely high-performance web apps...There are two basic concepts:

Each page of your app is a Svelte component

You create pages by adding files to the routes directory of your project. These will be server-rendered so that a user's first visit to your app is as fast as possible, then a client-side app takes over

Building an app with all the modern best practices — code-splitting, offline support, server-rendered views with client-side hydration — is fiendishly complicated. Sapper does all the boring stuff for you so that you can get on with the creative part.

Pros

Fast and lightweight
Good documentation
Innovative

Cons

Small community
Very new (but promising!)

Additional Resources

⬆️ Return to top

The Rest of the Pack

There are a lot of interesting frameworks here. Some are the product of a single developer, while others have strong communities with a large number of contributors and corporate sponsorship.

If you're an author or contributor to one of these projects and you'd like to provide more or updated information, please .

AppRun

Authored by Yiyi Sun, in a small (3KB) library that uses TypeScript as the development language and takes inspiration from Elm:

AppRun is a lightweight library...using the elm style model-view-update architecture and event publication and subscription.

Additional Resources

(YouTube)

⬆️ Return to top

Binding.scala

Binding.scala is a one-way data-binding library written in Scala, although it targets both JavaScript and JVM. From the :

Binding.scala can be used as a reactive templating language in both web and desktop GUI development. It enables you use native XHTML literal syntax to create reactive DOM nodes, which are able to automatically change whenever the data source changes...Binding.scala has more features and less concepts than other reactive web frameworks like ReactJS.

Additional Resources

⬆️ Return to top

Bobril

takes inspiration from React and Mithril. From the documentation:

It is fast, low size framework with rendering based on Virtual DOM. The main focus is on speed and simplicity of code generation...Content and behavior of any page can be defined simply by composing JavaScript objects.

The page content rendering is based on comparison of Virtual DOMs. The application has some state in time and bobril application generates the Virtual DOM according to this state. Virtual DOM is an object representation of the resultant DOM. If some state-changing event occurs and the previous Virtual DOM is different than currently generated Virtual DOM, the real DOM will change according to this change.

Additional Resources

⬆️ Return to top

Choo

is a functional library for building user interfaces. It's small (4KB) and supports server rendering. The Choo philosophy:

We believe frameworks should be disposable, and components recyclable. We don't want a web where walled gardens jealously compete with one another. By making the DOM the lowest common denominator, switching from one framework to another becomes frictionless. Choo is modest in its design; we don't believe it will be top of the class forever, so we've made it as easy to toss out as it is to pick up...We want everyone on a team, no matter the size, to fully understand how an application is laid out. And once an application is built, we want it to be small, performant and easy to reason about. All of which makes for easy to debug code, better results and super smiley faces.

Additional Resources

⬆️ Return to top

CxJS

CxJS, or simply Cx, is a feature-rich JavaScript framework for building complex web front-ends, such as BI tools, dashboards and admin apps. Modern frameworks such as React and Angular provide an excellent base for building UI components, however, component implementation and many other application aspects are left to the developer to figure out. CxJS tries to fill that gap and provide the all necessary ingredients required for modern web applications.

Additional Resources

⬆️ Return to top

Cycle.js

Billed as a "functional and reactive JavaScript framework for predictable code" is primarily the work of . It has over 100 contributors and corporate sponsorship. From the documentation:

Cycle’s core abstraction is your application as a pure function main() where inputs are read effects (sources) from the external world and outputs (sinks) are write effects to affect the external world. These I/O effects in the external world are managed by drivers: plugins that handle DOM effects, HTTP effects, etc.

Additional Resources

(free video course)

⬆️ Return to top

DIO

is a lightweight (7KB), declarative UI library that offers an alternative to React:

There a lot of small details that give DIO its edge that don't realy touch on new API's but rather on creating a larger surface area of what React already supports and adding to this.

For example React can render strings, numbers, elements and components but what if it was able to render Promises or Thenables? This would help solve a lot of "problems" with data fetching and lazy loading that is possible with React but not declaratively incentivised at the library level.

Additional Resources

⬆️ Return to top

Dojo

One of the important principles behind is accessibility, which makes me think it's a potential candidate for projects in government and higher education, where there are often stringent compliance requirements. From the website:

Dojo 2 is grounded in the belief that accessibility is as important online as it is in our physical environments, and architects of both share a similar responsibility to provide access to all...all Dojo 2 widgets have been designed to be accessible by default, and any tools needed to meet WCAG standards have been integrated into @dojo/widget-core and @dojo/widgets.

Internationalization is another area of focus:

Internationalization, or i18n, is the process of decoupling an application from a particular language or culture, and is a major requirement of most enterprise applications. As such, internationalization is one of Dojo 2’s core concerns. @dojo/i18n, Dojo 2’s internationalization ecosystem, provides everything that is needed to internationalize and localize an application, from locale-specific messaging to date, number, and unit formatting.

Additional Resources

⬆️ Return to top

Hyperapp

Coming in at a very slender 1KB, is a library with a minimalist API. It does, however, support server rendering. The Hyperapp approach:

Hyperapp is a JavaScript library for building web applications.

Minimal: Hyperapp was born out of the attempt to do more with less. We have aggressively minimized the concepts you need to understand while remaining on par with what other frameworks can do.

Functional: Hyperapp's design is inspired by The Elm Architecture. Create scalable browser-based applications using a functional paradigm. The twist is you don't have to learn a new language.

Batteries-included: Out of the box, Hyperapp combines state management with a VDOM engine that supports keyed updates & lifecycle events — all with no dependencies.

Additional Resources

⬆️ Return to top

Hyperdom

Formerly named, Plastiq, , is a "fast, feature rich virtual-dom framework for building dynamic browser applications." From the documentation:

Hyperdom applications are made of regular JavaScript objects that represent application state with render() methods that define how that state is represented in HTML. Hyperdom supports a simple event-update-render cycle, promises for asynchronous operations, JSX, non-JSX, client-side routing, SVG, two-way data binding, and optimises for performance, developer usability and simplicity of application architecture.

⬆️ Return to top

hyperHTML

Framework agnostic, was created to, "simplify DOM performance best practices...is 100% ECMAScript compliant and it weighs in at less than 4Kb". From the introductory article:

It’s nothing more than a function, that works bound with DOM nodes and fragments as context. You bind your target node once, or even more if you don’t care, and you render the same template literals over and over simply passing new data.

Additional Resources

⬆️ Return to top

Ivi

The documentation notes that, although Ivi is small, size is at the bottom of its list of priorities:

It seems that nowadays many people in javascript community were brainwashed that small library size is a synonym to fast performance and simple implementation. In reality it usually means that library is using different tricks to reduce code size by using inappropriate data structures (slower performance), initializing data structures at runtime (slower bootstrap performance), reusing code for many different data types (slower performance), etc.

Library size in ivi library is at the bottom on the list of priorities:

Correctness

Consistency / Predictable Behavior

Performance / Developer Experience

Library Size

Additional Resources

⬆️ Return to top

Knockout

Using the MVVM pattern, is a library that has been around for a while. From the documentation:

Knockout is a JavaScript MVVM (a modern variant of MVC) library that makes it easier to create rich, desktop-like user interfaces with JavaScript and HTML. It uses observers to make your UI automatically stay in sync with an underlying data model, along with a powerful and extensible set of declarative bindings to enable productive development.

Additional Resources

⬆️ Return to top

Maquette

is a lightweight (3KB) library inspired by React, Mithril and Mercury:

Maquette is a virtual DOM implementation that excels in both speed and simplicity. It solves the problem of keeping the user interface in sync with underlying data.

Maquette allows you to specify the UI using plain Javascript. This makes maquette easy to learn, easy to debug and easy to deploy. Maquette is very unopionated by design, making integration with other frameworks and libraries as painless as possible.

Although it's not the default, you can use TypeScript with Maquette.

Additional Resources

⬆️ Return to top

Marko

A product of eBay Open Source, is a reactive front end framework that emphasizes UI performance. Similar to Vue, you can use single file components that include component logic, template and CSS.

Here's a quote on Marko vs React from the lead developer, Patrick Steele-Idem:

While many of the features in Marko were inspired by React, Marko and React offer very different usability and performance characteristics. Marko was designed to avoid almost all boilerplate and is more closely aligned with HTML. In almost all cases, a Marko UI component will require less lines of code than its React JSX equivalent while maintaining readability and allowing the same expressiveness as JSX.

Additional Resources

⬆️ Return to top

Mithril

is a lighweight framework. Unlike React, it incudes functionality for routing, XHR and state management. The pitch for Mithril:

Why use Mithril? In one sentence: because Mithril is pragmatic. This 10 minute guide is a good example: that's how long it takes to learn components, XHR and routing - and that's just about the right amount of knowledge needed to build useful applications.

Mithril is all about getting meaningful work done efficiently. Doing file uploads? The docs show you how. Authentication? Documented too. Exit animations? You got it. No extra libraries, no magic.

Additional Resources

(YouTube)

⬆️ Return to top

Moon

A small (7KB) library, positions itself as an alternative to React, Vue and Mithril.

Moon is a minimal, blazing fast library for building user interfaces. It combines the positive aspects of popular libraries into one small package. It's super lightweight, and includes advanced optimizations to ensure fast render times. The API is small and intuitive, while still remaining powerful. Moon is compatible with IE9+.

Yes, there have been a lot of front end libraries released lately, and many people prefer different parts about each of these libraries. For example, React provides the ability to use JSX and uses a virtual DOM, Angular provides easy to use directives, and Ember provides a nice templating engine built in.

Moon aims to combine the best parts of these libraries into a single, lightweight package, while providing improved performance.

Additional Resources

⬆️ Return to top

Nerv

is a new framework out of China. It bills itself as a, "blazing fast React alternative, compatible with IE8 and React 16." In fact, you can convert a React app to Nerv simply by adding an alias in your webpack config. All of that and a library size of 4.4 KB.

Because it is so new and makes claims of superior performance vs React — some members of the React community asked for clarification on those claims, as well as more information about Nerv. From the author's reply:

In my humble opinion, The biggest difference between preact, Inferno, and Nerv, is not some technical issue like what’s the right way to implementing a React feature. It is about the what does the library want to achieve. In preact, maybe they just want a lite library, Inferno want to be fast as they can, React compatibility just a bonus, they are both need a compat module to do that. But for Nerv, compatible with React is our main goal, by doing that, we can sacrifice performance and size.

Peter Mikitsh’s criticism is right. Nerv can’t pass React fiber(16) 100% unit test, which is predictable —— the React team takes whole year to achieve the target, how can two guys come from nowhere(says by some guy in Hacker news) be able to do that?

So, What’s the tradeoffs? Obviously, some third-party React component/library couldn’t work properly in Nerv. But which one? To be honest I don’t know. I’m glad to be heard that Next.js next-news worked on first try., but in the meantime, Benchmark tabs don't work in Firefox (fixed) —— All of this, We wouldn’t know if we don’t go public.

Rome wasn't built in a day. Nerv is not perfect, no library is, particularly in early stage, maybe there still tons of bug we don’t know. Therefore we decided to open source, to go public, we need the community’s help, we need your help.

Additional Resources

⬆️ Return to top

NX

NX is the work of Bertalan Miklos, JavaScript engineer at RisingStack. From the documentation:

NX is a modular front-end framework - built with ES6 and Web Components. The building blocks of NX are the core, the middlewares, the components and the utilities. These are all hosted in separate GitHub repos and npm packages.

The NX core is a tiny library, responsible for one thing only. It allows you to create dumb components and to augment them with middlewares. A component executes its middlewares when it is attached to the DOM and it gains all the extra functionalities from them. NX comes with some core middlewares out of the box, which you can find listed below.

Additional Resources

⬆️ Return to top

petit-dom

Authored by Yassine Elouafi and one of the fastest in performance benchmarks, takes a minimalist approach:

Diff algroithm is based on pre-optimizations described at and the algorithm presented in the paper "An O(ND) Difference Algorithm and Its Variations. There is also an excellent article which explains how the algorithm works. The article includes a GUI application to play with the algorithm

⬆️ Return to top

Pux

is a framework that uses , a strongly-typed, functional programming language that complies to JavaScript. There are currently problems with performance:

The slow performance arises from translating Pux's (smolder) virtual DOM to React's virtual DOM. The goal is to write a purescript virtual DOM module for smolder, which would avoid that translation step and could be optimized for a monadic datastructure. I suspect this would achieve performance on par with Halogen.

Additional Resources

⬆️ Return to top

Ractive.js

Originally created for use on the Guardian website, is a reactive, template-driven UI library:

Unlike other frameworks, Ractive works for you, not the other way around. It doesn't have an opinion about the other tools you want to use with it. It also adapts to the approach you want to take. You're not locked-in to a framework-specific way of thinking. Should you hate one of your tools for some reason, you can easily swap it out for another and move on with life.

Additional Resources

⬆️ Return to top

react-lite

Aiming to be a lighter-weight version of React, , is an "implementation of React that optimizes for small script size." From the documentation:

React-lite supports the core APIs of React, such as Virtual DOM, intended as a drop-in replacement for React, when you don't need server-side rendering in browser(no ReactDOM.renderToString & ReactDOM.renderToStaticMarkup).

Additional Resources

⬆️ Return to top

RE:DOM

Authored by Juha Lindstedt, is a small (2KB) and fast UI library. In fact, it's one of the best performers in the latest benchmarks. From the website:

RE:DOM is a tiny (2 KB) DOM library by Juha Lindstedt and contributors, which adds useful helpers to create DOM elements and keeping them in sync with the data.

Because RE:DOM is so close to the metal and doesn't use virtual dom, it's actually faster and uses less memory than almost all virtual dom based libraries, including React (benchmark).

It's also easy to create reusable components with RE:DOM.

Another benefit is, that you can use just pure JavaScript, so no complicated templating languages to learn and hassle with. Plus RE:DOM plays nicely with others. No need to write wrappers for things like Google Maps.

Additional Resources

⬆️ Return to top

Reflex

Authored by Irakli Gozalishvili of Mozilla, is a library heavily inspired by Elm:

Reflex is a functional reactive UI library that is heavily inspired by (pretty much is a port of) elm and it's amazingly simple yet powerful architecture where "flux" in react terms is simply a byproduct of a pattern. In order to keep a major attraction of elm — algebraic data types & type safety — the library uses flow, a static type checker for JS. All types are separated from implementation though, so it's your call if you want to take advantage of it or just ignore it.

⬆️ Return to top

Riot

The documentation gets straight to the point:

The frontend space is indeed crowded, but we honestly feel the solution is still “out there”. We believe Riot offers the right balance for solving the great puzzle. While React seems to do it, they have serious weak points that Riot will solve.

A major feature of Riot is custom tags (which look a lot like a Vue single file component):

A custom tag glues relevant HTML and JavaScript together forming a reusable component. Think React + Polymer but with enjoyable syntax and a small learning curve.

And...

Riot is Web Components for everyone. Think React + Polymer but without the bloat. It’s intuitive to use and it weighs almost nothing. And it works today. No reinventing the wheel, but rather taking the good parts of what’s there and making the simplest tool possible.

Additional Resources

⬆️ Return to top

rxdomh

Although interesting, has the look of an experimental project. It was inspired by Binding.scala and react-flyd.

⬆️ Return to top

San

is another project from Chinese developers. The documenation is in Chinese, but Chrome does a pretty good job with the translation:

San, is a MVVM component framework. Its small size (12K), good compatibility (IE6), high performance is a reliable and dependable solution for implementing a responsive user interface.

San also supports data-to-view binding instructions, the most commonly used branches in business development, looping instructions, etc. in addition to supporting the syntax features of all native HTML through declarative HTML-like view templates that remain well-used on the basis of, based on the complete frame template string parsing, and build a view of layer node relation tree generated by the UI view of the quick view of a high-performance engine.

Additional Resources

⬆️ Return to top

Simulacra.js

It's fair to say that no other framework has a smaller API than :

Simulacra.js returns a DOM Node that updates when an object changes. Its API is a single function, and it does not introduce any new syntax or a template language. It recursively adds metaprogramming features to vanilla data structures to work.

It is a fairly low cost abstraction, though it may not be quite as fast as hand-optimized code. The approximate size of this library is ~5 KB (minified and gzipped).

⬆️ Return to top

Slim.js

Authored by Avichay Eyal, is a lightweight web component authoring library:

Slim.js is a lightning fast library for development of native web-components and custom-elements based modern applications. No black magic involved. It uses es6+DOM native API and boosts up HTML elements with superpowers.

Additional Resources

⬆️ Return to top

Stem JS

Authored by Mihai Ciucu, is the framework that tries not to be a framework:

The syntax might look familiar, but Stem is designed to empower individual components and not the framework...

Stem was designed with code maintainability as a primary purpose, regardless if your project has 100 or 100k lines of code.

We also hate it when libraries force programmers to jump through hoops to make any non-standard change to it, so everything is designed to be easily modified.

Additional Resources

⬆️ Return to top

Stencil

From the Ionic team, is a "compiler that generates Web Components". But also a bit more than that:

Stencil combines the best concepts of the most popular frontend frameworks into a compile-time rather than run-time tool. Stencil takes TypeScript, JSX, a tiny virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline (similar to React Fiber), and lazy-loading out of the box, and generates 100% standards-based Web Components that run in any browser supporting the Custom Elements v1 spec.

Additional Resources

⬆️ Return to top

Stimulus

is a framework from the folks that brought you Basecamp.

Stimulus is a JavaScript framework with modest ambitions. Unlike other frameworks, Stimulus doesn’t take over your application’s entire front-end. Rather, it’s designed to augment your HTML by connecting elements to JavaScript objects automatically.

Additional Resources

⬆️ Return to top

Surplus

In performance benchmarks, was very fast. It also has a different approach, utilizing S.js:

Surplus is a compiler and runtime to allow S.js applications to create high-performance web views using JSX. Thanks to JSX, the views are clear, declarative definitions of your UI. Thanks to S, they update automatically and efficiently as your data changes.

Also...

Surplus is not a React “work-alike,” but it uses the JSX syntax popularized by React to define its views...JSX mitigates some of the risk of adopting (or abandoning) Surplus. Much Surplus JSX code already works as React stateless functional components, and vice versa. Surplus avoids arbitrary differences with React when feasible.

Differences with React:

Surplus makes real DOM elements, not virtual, and they update automatically. This removes most of the React API.
The ref property takes an assignable reference, not a function.
Events are native events, not React's synthetic events.
Surplus is a little more liberal in the property names it accepts, like onClick/onclick, className/class, etc.

⬆️ Return to top

Thermite

is another library that uses , the functional language that compiles to JavaScript. From the documentation:

It does not provide all of the functionality of React, but instead to provide a clean API to the most commonly-used parts of its API. It is possible to use purescript-react for more specialized use cases.

Additional Resources

⬆️ Return to top

TSERS

stands for Transform-Signal-Executor framework for Reactive Streams. From the documentation:

In the era of the JavaScript fatigue, new JS frameworks pop up like mushrooms after the rain, each of them providing some new and revolutionary concepts. So overwhelming! That's why TSERS was created. It doesn't provide anything new. Instead, it combines some old and well-known techniques/concepts and packs them into single compact form suitable for the modern web application development.

Technically the closest relative to TSERS is Cycle.js, but conceptually the closest one is CALM^2. Roughly it could be said that TSERS tries to combine the excellent state consistency maintaining strategies from CALM^2 and explicit input/output gates from Cycle - the best from both worlds.

Additional Resources

⬆️ Return to top

Ultradom

(formerly picodom) is interesting in that it's authored by the same guy behind Hyperapp, Jorge Bucaran.

Ultradom is a minimal virtual DOM view layer for building browser-based applications and frameworks. Mix it with your favorite state solution architecture or use it standalone for maximum flexibility. Features include server-rendered DOM recycling, keyed updates & lifecycle events — all with no dependencies.

⬆️ Return to top

Vidom

Authored by Filatov Dmitry, is another React-inspired library:

Vidom is just a library to build UI. It's highly inspired from React and based on the same ideas. Its main goal is to provide as fast as possible lightweight implementation with API similar to React.

Additional Resources

⬆️ Return to top

Vuera

is an unusual library. It allows you to use React componets inside Vue and vice versa. The anticipated use cases are when migrating between React and Vue or when using both frameworks with a single project.

Additional Resources

⬆️ Return to top

Hey! You made it all the way down here! If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

Until next time, happy coding…

]]>

The Tools

Why the Heck Am I Doing This?

Getting Started with Now

Step One

Step Two

Setting Up Vue

Install Using the CLI

Add server.js

Update package.json

Setting Up Svelte

Update Dependencies and Install

Add server.js

Update package.json

Observations So Far

The Code

Associating .svelte Files with HTML Syntax

Great Quotes

Great Quotes

You Should Try Svelte!

The Era of Framework Compilers

Angular Ivy

React Prepack

The Future Is Already Here

Framework Usage

Other Frameworks of Note

Framework News

Beyond React 16

Inferno 5 Released

ngAtlanta Report

State of VueJS 2018

AngularJS Enters LTS

EmberConf Hits Portland

Radi.js Announced

Vue.js Cookbook Released

Notable Tutorials and Articles

Upcoming Conferences and Workshops

Conferences

Workshops

Rich Harris

Dan Abramov

Kyle Simpson

Gregory Brown

Addy Osmani

Evan You

Axel Rauschmayer

Sarah Drasner

André Staltz

And Finally...

React LazyLoad

React Loadable

Preact

InfernoJS

And Finally…

Template Syntax

Hello {{name}}!

Cats of YouTube

Single File Components

Demo

My project

Hi there

The Magical Disappearing UI Framework

The Progressive Framework

And Finally…

Nobody Ever Got Fired for Buying IBM

The Java Team Branching Out

The Smart Choice

The Need for Speed

Performance First?

I Love Shiny Pennies

Big Fish, Little Fish

Framework Summit 2018

Workshop.me

JS Interactive

How to Decide?

The Big Three

Historically Significant

Notable

And Finally…

The Ultimate Guide to JavaScript Frameworks

The Best JavaScript Frameworks You’re Not Using