My EmberJS in 2018
As you may know the EmberJS core team has launched Call for Blog Posts. The goal of the call is to get feedback from the community on what EmberJS should prioritize for its 2018 Roadmap.This article is my humble contribution.
Keep up
I’ve been using EmberJS for a little more than 2 years (damn time flies). During this time, EmberJS has evolved a lot, things like the javascript module API (rfc 176), glimmer 2, the new testing api… were added. I feel that EmberJS is moving in the right direction. My first wish for 2018 is to see EmberJS continue forward.
The new file layout (rfc 143)
EmberJS offers two differents file layouts to organize code: “default” and “pods”.
With the “default” layout, components and their corresponding templates are not in the same folder. The same goes for routes, which are not in the same folder as their templates and controllers. For big apps the layout system is not appropriate and can be error prone since you constantly have to switch from one folder to another.
In “pods” layout, components and their templates live in the same folder, as well as the routes, the controller and their template. This makes development super easy.
The problem with the “pods” layout is that everything is a pod: routes, model, components… This starts becoming a little confusing when you create routes, models, serializers, controllers, all with the same name, because everything will end up in the same folder. This makes it close to unmanageable for big apps, as it becomes harder to navigate the architecture. The project quickly becomes a happy mess of : components, models, routes…
To solves issues from both layouts, the rfc 143 introduces a new layout which keeps the idea of “pods” (components and templates in the same folder) but separates data from UI, routes from components. This actually makes way more sense and enables a clean architecture in your project where every “layer” is well defined and isolated. I hope to see this RFC land in 2018 and to be able to use this new layout for my current and next project.
Smaller bundles — (Tree shaking and more JS Module)
EmberJS 2.16 and the introduction of the new module API (RFC #176) with the idea of making EmberJS feel less overwhelming to new users and replacing EmberJS global with a first-class system for importing just the parts of the framework you need. Thoses changes offered the possibility to reduce the size of a bundled EmberJS app using tree shaking. By default EmberJS’s apps are heavy: a basic one has to load at least 150kb of js (minified and gzip). Included in this 150kb of js is a lot of never used code. If enabled by default, tree shaking would eliminate unused code from the project’s very beginning and make EmberJS’s app lighter and open the door to faster load times.
# More Quest
A month ago, I made my first contribution to EmberJS 🙌, I answered the call for a quest issue (issue 16391). All I did was to clean up the EmberJS tests output by removing unwanted errors message, it was not difficult but I enjoyed it. I feel like I’ve helped the “real” contributors by taking care of a trivial issue for them.
A good idea would be to continue creating quests for small things like documentation, code-cleaning… And maybe add a place where this quest can be found ^^. It could be for core package or even addons ^^.
By the way there are currently some open quests, for example to clean up the test output #16391, or to update official documentation #288 😉
# Community
One of the reasons I love EmberJS is that it has one of the best communities I’ve ever met. I’ve recently joined the EmberJS Slack (I highly recommend that you to do the same) and I’m amazed by the number of people that are ready to help solve your problems. The community is also really proactive and constantly creates amazing addons that solve problems in an elegant way. I know it sounds cheesy, but for 2018 I want this to continue, I want a nice community moving forward, kind, and ready to help.
