Ember talks about their JavaScript framework

ADM: As one of the founders of Ember, what takeaways do you have to share from the latest Ember Conference?

Dale: There were two main themes at the conference this year.

The first is that we love Ember, and feel very productive using it, so our focus over the next year is about refining and simplifying what already exists rather than changing the fundamentals. We want to continue to distill Ember down to just a few core concepts, so its power and productivity are accessible to even more developers.

The second theme was excitement around the larger JavaScript landscape. There are so many new features that are now landing in browsers, but it’s important that we adopt new features in a productive way, rather than rush to adopt something simply because it's new and shiny.

There was a lot of discussion at the conference about how to take advantage of new JavaScript features like classes, decorators, and async functions while preserving Ember's legendary productivity and compatibility.

ADM: Who is using the framework today, other than LinkedIn?

Dale: Off the top of my head, EmberConf had speakers from Square, Condé Nast, Toyota, Intercom, and Blue Apron telling us about how they’re using Ember.js in production. Other big companies using Ember include Apple, Microsoft, Sony, and more.

It feels like most big companies have at least one or two Ember apps, either powering an internal dashboard or being used by customers directly. And of course there are a ton of startups and consultancies working with Ember every day.

Most importantly, members of the core team work for companies of all sizes that have embraced Ember, from large companies like LinkedIn to small, one- or two-person consulting firms. I think that gives us a wide range of perspectives that help us tailor Ember to many different use cases.

ADM: What updates are planned for Ember in the coming year?

Dale: We just announced the release of Ember 3.0, and the best feature is that there are no new features.

Hopefully, that answer surprised you! Most projects advertise big new features to go along with a new major version. But one of the tenets of Ember is what we call Stability without Stagnation. Of course, we care about big new features, but we care just as much about how people with existing apps can adopt them.

In that spirit, we already landed all of the big new features in the 2.x series, so people with existing apps can start using them right away. In 3.0, we simply removed old, deprecated API.

You can think of new major versions in Ember as being like a “garbage collection” pass of our codebase. Normally, every six weeks, we release a new minor version that contains new features and deprecates old APIs that have fallen out of favor. But every few years, when we bump the major version, we pause new features and just clear out any cruft that may have built up.

That means Ember 3.0 is all about simplicity, stability and svelteness. And we’re starting from a strong foundation to build out even more cool stuff in the 3.x series.

ADM: You recently made the move to LinkedIn, what attracted you to the company?

Dale: The fact that LinkedIn is so invested in Ember is one obvious reason. What really drew me to this opportunity is LinkedIn’s long-standing commitment to the larger open source community. LinkedIn has supported its own open source projects like Samza, Voldemort and Kafka for years, and I got to know many LinkedIn employees through their contributions to Ember.

I knew that I would be able to continue my own work in the community, while helping LinkedIn build great web apps for our members. I’ve been with Linkedin for a little over a year now and I love my job.

ADM: Why did LinkedIn select Ember over other Javascript frameworks?

Dale: I joined the company after their decision to adopt Ember, but my understanding is that there were several key differentiators that helped them decide.

First, it’s important to remember that LinkedIn is a huge engineering organization spread across different offices, countries and continents. Ember’s strong conventions mean apps built by different teams are still structured similarly. This makes collaboration much easier, and means an engineer moving from one app to another can be productive right away.

Another factor is Ember’s fantastic testing infrastructure that comes out-of-the-box with every new application. Ember’s emphasis on automated testing dovetailed well with the culture of testing that was already so important at LinkedIn, helping us deliver quality products in less time.

ADM: Tell me about this test you ran with the projects, Preact and Glimmer.js.

Dale: One exciting trend to emerge in the JavaScript world recently has been the idea of using compilers to “bend the curve” of tradeoffs between file size and robustness. A compiler can analyze your entire application and, at least theoretically, produce optimized output and assets that include only what you need.

However, some argue that compilers introduce extra complexity, and even with all of that complexity, they will have trouble beating a hand-tuned lightweight library.

Unfortunately, it’s very difficult to test these competing philosophies in the real world. Here at LinkedIn, we really wanted data to drive our decision-making. To gather that data, we built the same app twice - once in Preact and once in Glimmer.js - to see how they performed.

Some of the engineers on our team believed Preact, an open source JavaScript library that implements a subset of the React component API, would help us build the fastest site possible.

What sets Preact apart is its truly remarkable file size. While the standard build of React is about 30kb minified and gzipped, Preact is just 3kb - 10x smaller - for very similar functionality.

Others believed that Glimmer.js would yield a faster experience. Like Preact, Glimmer.js is an open source JavaScript library for building UI components for the web. It is built on the same rendering engine as Ember.js, but unlike Ember, provides just the UI layer - no routing, data loading, or other features.

To reduce the cost of building the same app twice, we shared as much implementation as possible between the Preact and Glimmer flavors. All of our code went into a single repository that we organized into packages. You can read more about the specifics of that in our blog post on the topic: https://engineering.linkedin.com/blog/2018/03/how-we-built-the-same-app-twice-with-preact-and-glimmerjs

ADM: What were the results and what can readers take away from them?

Dale: The difference in performance between the two flavors was so small as to be effectively imperceptible. Both technologies allowed us to build an app that beat the initial load time of the control version.

Ultimately, both Preact and Glimmer.js are fantastic tools for building fast, modern web applications.

It is important to note that we focused only on initial load times. There are other important performance metrics, such as responsiveness to interaction, that were out of scope for this experiment.

That said, the outcome of this experiment is particularly exciting because Glimmer.js shares a rendering engine with Ember.js, which we already use to build LinkedIn.

We are now taking what we’ve learned from our two prototypes and contributing performance improvements back to Ember.js, so that we can make our existing app even faster, and share our learnings with the larger open source community.