Skip to content

Instantly share code, notes, and snippets.

@neojp
Created June 18, 2019 06:55
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save neojp/d7b2cdc38a04776cf3e41a6e698fb07e to your computer and use it in GitHub Desktop.
My thoughts on the Ember.js roadmap for 2019 #EmberJS2019

My thoughts on the Ember.js roadmap for 2019 #EmberJS2019

Introduction

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

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.

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 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.

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.

Rehydration documentation

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.

Svelte.js-like compiler

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.

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.

More documentation

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

Random thoughts

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 ¯\_(ツ)_/¯

Closing note

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.

@tleperou
Copy link

Never too much to insist on those points:

  • Embroider - get a more flexible build process would drag users from Webpack and others-build-systems land to consider Ember as a viable option.
  • Statically generated pages from Fastboot - referring to the JAM stack, it will seduce developers who want to create a fast, reliable and flexible website quickly.

Last but not least

  • Ember Engines is the only option available to develop large enterprise applications. Lazy loading code source should be as simple as modules in Angular. However, Engine is still in beta, and the Ember's documentation does not spotlight.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment