My thoughts on the Ember.js roadmap for 2019 #EmberJS2019
Coming from the old jQuery days I used to hear from core members about how interesting the Amber.js framework was. Quickly enough it became Ember.js and I jumped-in head-on.
I've never been "active" in the community, but whenever an SPA project pops up I have always pushed for Ember to be used as the an essential part of the project because it is the easiest to use, and most reliable framework to work with as a team. Conventions over configuration are that good.
Now with this Call for Blog Posts, I present you with a few ideas I would love to see in the plausible future.
Embroider and Ember CLI tools
I'm excited to hear about Embroider and its ability to allow users to use more tools in the build process. Please make this happen this year.
Node modules importer & Render Modifiers
@ember/render-modifiers are already mentioned in the new Octane guides, let's make sure they are included in the default Ember CLI blueprint.
Hot Module Reloading
The idea of hot module reloading sounds great, if you update a single line in a template let's just update that in the browser without the need to refresh the whole page.
ember-cli-hot-loader is an addon that started quite a while ago, maybe it's time to revisit it. Hopefully with the coming of Webpack through Embroider this can happen sometime soon.
Bundle builds based on browser & feature support
I would love to be able to create builds based on browser compatibility and feature support.
Most of the apps I often build are private and I can dictate the target browser; because of that it would be nice to create bundles based on browser support in which you don't need to transpile the latest ES features and there isn't the need for polyfills to be sent in the bundle reducing its file size and increasing performance (less code to parse and initialize).
Then we could have another bundle for older browsers, and maybe even one for Internet Explorer.
Staticly generated pages from Fastboot
While not familiar with the latest on Fastboot, I have used it before and I'm pretty sure it "just works" as per usual; though there is something I would love to see.
I would love to export a production Ember app as individual static HTML pages rendered by Fastboot. There is an addon called
prember that seems to accomplish this, not sure if it still works or is mantained.
Along the lines of rehydration, it would be nice to be able to render a route through any means either from an static page and/or a server side language that isn't Node and get the app to recognize it and just load right there without running Fastboot as a server. This might be possible already, but I can't remember seeing this anywhere in the guides or documentation.
Ember as a Back-end Framework
Here comes a crazy idea; if the previous two options were possible, I would even go one step beyond it and use Ember as a server-side framework.
Imagine to use all the conventions and good practices of Ember on Node.js, then serve the site as plain HTML & CSS without the need to use the heavy side of Ember on the browser; it could do wonders on older phones running Opera Mini while keeping the developer experience that Ember brings.
Better Code Editors and IDEs support
Can't really speak for all editors out there, but VS Code support seems to be lacking in comparison with other JS frameworks.
It would be nice to have a section in the guides where we explain a good process on how to leverage Code Editors and IDEs to code and debug Ember.js apps.
Also, it's likely that the Ember Server Language needs some love and care.
Could Ember Data be optional?
Ember Data is absolutely brilliant, yet I don't always require it and most often than not I end up removing it from the bundle. Maybe we could have an interative installer whenever Ember CLI initializes a project and allow Ember Data to be optional.
Guides and Documentation
Guides geared toward absolute beginners
The current guides walk you through the process of building a full blown SPA with routes, and data management; it is very well written and perfect for that use case.
Sometimes though, you want something simpler. Something as simple as just a few components and a service to keep state data running off the index route. I believe the current guides don't help much in scenarios like this and Ember could still help with that.
We could write simpler guides with clearer objectives, maybe as part of the non-existing cookbook we used to have. It could probably be structured how the old jQuery tutorials used to be, simple, and work from there the Ember way.
Removing unused features
Also, it would be very nice to have documentation on the guides on how to remove unused features from Ember to reduce the build size such as Ember Data.
Some sections I feel we could use on the documentation:
- Fastboot and some of its uses I mentioned above
- Code editors plugins and howtos on debugging and testing
- Ember Engines and lazyloading of its assets
- Building individual CSS files (aside from app.css) and lazyload it when needed
- Comparisons on how the "Ember way" differs from other frameworks and its use cases and be truthful about how Ember isn't perfect and how a simpler library could potentially be better for certain scenarios
- Guides for "coming from such and such framework"
- How to create your own Ember CLI blueprint
- More docs on how to create addons and use the all the features of Ember CLI and Broccoli
Pods and Module Unification
I loved Pods, was sad MU didn't go through, and am really exited that something else is still been worked on as a replacement.
Testing concepts and tools are still hard
Are there better ways to teach tests? I still think it's hard to teach them to beginners.
Ember isn't dead
I know it, if you are reading this you probably know it, but a lot of people don't. We need to do better when explaining this to people.
Recently I went to a tech meetup in my hometown in Lima, Perú. Afterwards I started talking about Ember in which everyone looked at me as if I was talking about a unicorn. Something that people heard of at some point, but most definitely didn't think it existed or even had a userbase; their concept of Ember is of an outdated pretty-much-dead framework no one uses or talks about. Interestingly everyone remembered Tom Dale and his talk at JSConf Colombia 2017 about how fast Glimmer and the Glimmer VM were ¯\_(ツ)_/¯
Phew, it was a lot. I had a few more ideas, but somehow felt redundant by the end of this very long post. Hopefully we can see some of these ideas discussed and maybe one of them aligns itself with the vision of the Ember team.