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.
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.
The fabulous ember-auto-import and @ember/render-modifiers are already mentioned in the new Octane guides, let's make sure they are included in the default Ember CLI blueprint.
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 has a similar effect when updating CSS. HMR is obviously harder when used on templates with logic or plain JavaScript logic, but it would be great to see this worked on.
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.
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.
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.
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.
Ever heard of Svelte.js? I only recently started looking at it after it was mentioned in the annual community survey.
The idea of this framework is to provide you with the developer experience of a full front-end framework, but gets transpiled to a very simple and plain JavaScript code that is significantly smaller in file size and better at performance. I might be remembering it wrong, but it reminded me of something Tom Dale mentioned in a conference talk in which Ember could potentially do this in the future thanks to the new Glimmer VM and some ridiculously advanced binary templates as part of the build process. It was amazing, and yet not sure if it ever happened. I'd be happy to see this or even read more about it.
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.
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.
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.
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
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.
Are there better ways to teach tests? I still think it's hard to teach them to beginners.
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.
Never too much to insist on those points:
Last but not least
Ember isn't dead Ember, the core team, the community of developers should not have to explain anything about that. It sounds like the real topic behind that is the marketing/communication position of Ember. New developers have to join us :)
Thanks for sharing your thoughts. I agreed with most of it.
I hope more developers will realize how Ember is robust, reliable, and not-that-difficult to learn.