Send Ember on a diet and thrive innovation
The deadline for the #EmberJS2019 blog posts is coming closer very quickly but as always I need deadlines to finish my stuff.
At first, I want to give some background information about me and the company I work for. We at Roomle use Ember since it’s very early days. Our first commit to our Ember project dates back to the beginning of 2013. Over this time we got a lot of experience and got to know the good and the bad parts of Ember. We also launched production web apps which use Glimmer.js as their UI framework. Right now we rewrite parts of our main app in Ember Octane with TypeScript so we also know how it is to be an early adopter.
Because we are a small startup and focused on building our own product we didn’t contribute addons or a big amount of code but we helped to fix some issues and also created small PRs for several projects of the Ember eco-system.
Before I start I want to add a disclaimer: we really like Ember and I do not want to create the impression that we dislike it. This blog post is about areas to improve and not about the nice things 😉
🤔 Recap of Roadmap 2018
Before I dive into the future I want to do a quick recap on the Roadmap of 2018. I want to mention that I do the recap as an outsider who is not part of any core team. So be aware that it’s very likely that I miss some important things. Nevertheless, I think I can provide good feedback because this is also how other none-contributors could see the progress of the framework. Let's see the topics we as a community wanted to improve last year:
🗣 Improve communication and streamline decision-making
There was a lot of improvement on this topic. Also, the switch to Discord was good and went smoothly. But I think the communication around Ember Octane was not super ideal. People were holding back project because they didn't want to start with “legacy” Ember. Since Ember Octane still isn’t shipped (only preview) some of my colleagues looked around on other frameworks and some of them left Ember in favor of Vue and Vue-CLI (mostly because of the superior build tools).
In my point of view, the communication around Octane had two big problems
Over communication: it was hard to keep track on what’s happening and what makes sense to adopt. Of course, everyone could have stayed at the “happy path” but when you start a new project you don’t want to use the old way of doing things. We also started a new Ember project shortly before Ember Conf 2019 and we were also afraid that we start a brand new app in a legacy way of doing things. My feeling was that communication around Octane created some uncertainty.
Over Promising and Under Delivering: when we look at the goals which were set for Octane many of them were postponed (especially long-awaited improvements for the build, I’ll go into details about the build in the next section). Don’t get me wrong I really love Ember Octane but most of the work done is for developer experience. I know that things like native classes lay out the ground for further improvements but right now these things are not really leveraged. Ember has a history of promising things e.g.: routable components, module unification etc which never land therefore I think we need to be very careful what we promise and how we communicate this promises to the public.
The tldr; communication improved massively but in some cases, we should be more sensitive what and how we communicate
🏋♂ Finish what we started and Ship Ember Octane
These both roadmap goals had a lot of overlap. I think the Ember community was able to finish a lot of the things which were started. Concerning Ember Octane we failed to ship it within the time of the 2018 roadmap (it is still a preview version I think). I also want to highlight some of the goals of Ember Octane which weren’t shipped and I think should be part of the 2019 roadmap again, therefore I start with some quotes of 2018 roadmap:
Content apps, where pages are text-heavy and where the first load is critical. In performance-constrained environments, Ember’s strong conventions can help developers build faster apps by default.
They key phrase here is first load. If you do ember init and create a simple “Hello World” app the JS bundles sum up to about 700KB. My first experiments with Embroider were better but still didn’t delivered satisfying results. The bundle was still around 400KB of JavaScript. That’s just too much. Although I really like Ember we had to leave Ember for certain projects because of the JS bundle size. Not every project is an admin interface for entering data for a backend. Especially for our e-commerce projects, Ember was not a viable option just because of bundle size. I would love to see massive improvements in this area 💖
Treeshaking to automatically remove code unused by the application
This is very much related to the point from above. Ember has to become first class and industry-leading in terms of tree-shaking. Since Ember is a “batteries included” framework our bundles will be always huge if we have no excellent tree-shaking.
Svelte builds, where deprecated features are stripped out of framework code. We will get more aggressive about deprecating code that is not widely used.
I think a modern build tool like Embroider should just remove everything that isn’t needed. No matter if a feature is deprecated or not.
FROM NONE GOALS: Further Glimmer VM optimizations. Glimmer performance is industry leading and not a bottleneck in most Ember.js apps. At this point, the Ember.js payload is the primary performance bottleneck, and we should turn our attention to enabling better performance there.
To sum it up, the core team is aware that payload size is a big topic and it was addressed accordingly in the 2018 roadmap but we didn't achieve this goal.
We really need to bring payload sizes down and only ship what is needed for the initial render!
Everything else has to be loaded on demand and lazily. Since Ember has strong conventions we could make this complex stuff pretty pleasant for developers.
The tldr; my 2018 recap is: please please please fix the payload size of Ember to make it an option for more kinds of projects 🚀
🎁 Wishes for 2019
I think we should focus on the spill-overs from 2018 but I also have wishes for 2019
👩🏼🔬Thrive innovation again
Years ago Ember was industry-leading in many aspects. Let’s think of the great router, ES6 and ES-Module adoption, the usage of Promises, the CLI etc. During the last years, it seems like Ember is running behind the big frameworks and has troubles to keep up.
I don’t think we should try to innovate faster than the others but we should start again to thrive innovation inside the Ember space. Maybe it would be a good idea to create an “innovation” team, like we have a core-team, learning-team etc. The innovation team could focus on things which are unique to Ember. Some things I’ve not seen on any other framework:
- Binary templates
- Render engine as WebAssembly module
- not directly related to Ember but something like css-block would be awesome
The first two features were already presented at Ember Conf 2018 but they are still not shipped. Ember should again have some features which set it apart from all the others. “Convention over Configuration” alone will be too less to stay relevant.
👷 The Build and Embroider
Many others already pointed out that Embroider is the most important project of 2019. I can totally agree because it will enable Ember to use industry-standard tools for packaging. Some wishes to Embroider and the improved build system:
- create different versions of the JavaScript bundles so we can deliver small and modern code to modern browsers and legacy bundles for old browser
- only include what is needed aka tree-shaking
- make it easy to lazy load stuff. In times of HTTP2, server push, preload etc and JavaScript primitives like async/await we should start to use lazy loading extensively
If we have an extraordinary great build and bundle tool we could also fulfill the promise of npm install your way to Ember. I think we should rename this phrase because an ember init could still install all packages into the node_modules folder but the developer only adds something to the payload if she/he imports it at some point of the application. I like this idea because we could still deliver a curated set of tools and do not punish users which only need small parts of the framework.
If we keep using Broccoli we must document better how to write plugins. If I really have to write a build plugin I always end up copying similar Broccoli plugins and removing stuff I do not need. Often I have to debug with node --inspect-brk. Developing build plugins is no fun at all
👵 Rethink “stability without stagnation”
I really love Ember for making upgrades easy and not breaking backward compatibility. But always when I start a new Ember project I think:
“Why do I have to carry all this baggage from years ago”
It also feels like focusing on backward compatibility slows us down a lot. I’m not sure how to solve this problem and I think it’s really hard to hit the sweet spot between “breaking” things and leaving everything like it is. Maybe we could provide polyfills for old apps and remove the legacy code from the Ember codebase. Sometimes I have the feeling that we are more on the stagnation side, especially on big topics, like the build, controllers, new file system layout etc.
💪TypeScript
We work with ember-cli-typescript since February 2019 and it works like a charm. We love the productivity boost TypeScript gives us. Also it makes code discoverability for all developers on the project easier. With TypeScript it’s far less likely that someone implements something which already exists. Especially for libraries and addons it’s great to have things like code-completion and IntelliSense.
Despite the fact that TypeScript and Ember play nicely together I think we should further improve TypeScript support in the Ember eco-system. It would be great if the top 100 addons would have TypeScript definitions and are coded to work with TypeScript.
Recently we have some troubles with TypeScript decorators and the new TC39 decorator spec. Not sure what's the problem there but we should always consider TypeScript users as well.
Besides that, it would be awesome to see stuff like typed templates etc.
✨ Glimmer.js
We use Glimmer.js in one of our projects and it works great but it feels somehow like dead land. There was so much development going on at the beginning but right now it seems like all forces are bundled to get Ember Octane shipped. We need some way to get Glimmer.js users back into the Ember “happy path”. Maybe the new build system and Embroider could help here but right now we feel lost with Glimmer.js ☠
🚚 Ember-Data
When we started our last Ember project we had to onboard new developers. And the main Ember concepts were easy to grasp for them. But often confusion arose when they had some question in combination with Ember-Data. From the learning perspective, I think there are three main challenges
- What is Ember-Data and what is Ember? The lines are very blurry.
- Why do we need special methods like
objectAtsometimes and sometimes not? Why we needtoArraybefore applying native array methods etc. - Improve the docs and explain what Ember-Data is, provide some best practices and recipes and compare it with tools from other frameworks. Some of our developers who switched from React always thought Ember-Data is the Redux in Ember
Furthermore, we also need to consider how to reduce payload size of Ember-Data
🌃 Mono-Repos
We have some mono-repos and it’s not always trivial to include Ember projects into these mono-repos. It would be nice to have some documentation or best practices on how to setup a mono-repo with several Ember project. Also it would be great to make it easier to share code from within the mono-repo. Maybe that’s already possible but I didn’t find a good tutorial for that. So I think it would be beneficial if a framework for ambitious web apps would also cover this topic somewhere in the advanced guides. For example we have the following setup:
mono-repo/
├── common-stuff/
│ └── this code is imported by all projects
│
├── ember-project-1/
│ └── want to import from common-stuff but that's harsd
│
├── ember-project-2/
│ └── want to import from common-stuff but that's harsd
│
├── three-js-project/
│ └── imports from common-stuff it's super easy here
│
└── some-node-js-2/
└── imports from common-stuff it's super easy here
I didn't find an easy way to import from common-stuff folder. Would be great if I just could do an import.
💫 Simplicity
As pointed out in many other blog posts 2019 should be the year we rethink old concepts and start to deprecate and remove them from the framework e.g.: Controllers. I won’t go into details here because many other blog posts described it very well. Furthermore, we should remove concepts which don’t feel like JavaScript, Ember.Run.Later vs setTimeout etc. But from my point of view, these things are more second priority. We really need to focus on build, bundle size and alignment with the wider JavaScript community.
Summary
| The tldr; | Just read this table if you don't have much time |
|---|---|
| 🤔 2018 | Communicate a lot but be more sensitive who and how |
| Ship the things which were descoped from Octane | |
| 👩🏼🔬 Innovation | Finalize some industry-leading features like binary templates etc |
| Create an innovation team like we have teams for guides, Ember-Data and core | |
| 👷 The build | Make Embroider top priority for 2019 |
| Lean on industry standard tools | |
| Document and simplify the creation of build addons | |
| Enable first class tree shaking, code removal (aka svelte) | |
| Make lazy loading as easy as using a dynamic import | |
| 🔝Fix bundle size 🔝 | |
| 👵 Finish things | Don’t let the mantra “stability without stagnation” hold us back from delivering features |
| 💪 TypeScript | Embrace TypeScript across the whole eco-system |
| Type the top 100 addons and maybe include type information in emberobserver score | |
| Create new features like typed templates | |
| ✨ Glimmer.js | Provide a way from Glimmer.js back to “happy path” |
| Do not forget about Glimmer.js users | |
| 🚚 Ember-Data | Improve Ember-Data docs |
| Clarify the role of Ember-Data in the eco-system | |
| Explain how Ember-Data can be compared to tools like Redux for new Ember users | |
| Fix payload size of Ember-Data | |
| 🌃 Mono-Repos | Make guides how to use Ember projects within mono-repos |
| Make it easy to import files from other packages within a mono-repo | |
| 💫 Simplicity | Rethink old concept, deprecate and remove them |
| Align closer with the wider JavaScript eco-system | |
| Make it an important but not top priority | |
| _____________________ | ________________________________________________________________________ |
Top comments (3)
Hello! thanks for writing out your thoughts on this :)
couple things:
mono-repos:
Bundle size:
Also, feel free to poke around the bundle analysis: emberclear.io/bundle.html
I agree with this so much. Unfortunately, it seems there is a schism in the js world :(
I'm hoping that this becomes less and less over time, as there are more success stories with Typescript. People just don't like being told they're wrong, or don't like learning it. :shrug: idk. it's weird.
Overall, I actually agree with most of what you've written <3
Just a couple last things though:
This is a HUUUUUUGE bonus for long-term projects though, and especially large projects who aren't as capable of adopting the latest and greatest patterns at the drop of a hat.
However, one of the goals of embroider, editions, and all the recent efforts is to make everything modular enough for our weekend worriers to "just pick up ember" and build something cool in a couple days.
idk how long glimmer.js as an independent project/app ecosystem is going to live? I know some things need to be supported, and many of the core projects live on in ember, but I think the future of npm-installing your way to ember is going to be less about glimmer, and more about answering the question "what makes up an application?" -- like starting with the glimmer components and vm, adding services, adding routing, etc.
that's just my perspective on stuff. I have no official knowledge from anywhere
without embroider, an octane app:
164.71KB gzipped
(I agree that this is still large)
With embroider
126kb
Still large for an empty app, but an improvement!
Thanks for the details about build sizes. This is exactly what I wanted to post as well but didn't have the time to. You were faster than me 😎 For us not only the gzip size is important especially for our e-commerce projects also the parse time of the JS is important. Many of the e-commerce businesses we work with heavyly rely on mobile traffic so it's even more important to ship less JS.