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 😉
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:
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
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
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.
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 🚀
I think we should focus on the spill-overs from 2018 but I also have wishes for 2019
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.
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:
- only include what is needed aka tree-shaking
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
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.
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.
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 ☠
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 need
toArraybefore 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
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
|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|
|Make it an important but not top priority|
One critical skill to have as a more senior developer is to be able to view potential problems as a series of patterns that have already been solved somewhere else. Let's take a bit of a dive into some of them!