Ember CLI core team would love to get your feedback on the 2018 roadmap: features, improvements, pain points, and anything that would improve your DX.
Here’s what we are planning to discuss during EmberConf:
Tree-shaking/Code Splitting/Dynamic Imports/out-of the-box npm support (already underway)
Yarn Workspace support
Improved documentation (potentially merge with Emberjs website)
Drop support for Node 4
Remove broccoli-builder fork (this will let us take advantage of the system $TMPDIR and remove tmp folder)
Deliver Module Unification
Make errors more ergonomic (potentially introduce error index).
Web/Service Worker Support
Better PWA support
Updates based on the feedback:
Working sourcemaps (for small and large apps)
Reducing build & reload times/easier debugging of slow build times (identify and reason about slow build steps; the ability to identify add-ons that don’t cache properly)
Improved documentation:
how to write fast addons, use Broccoli, and on all the hooks
best practices
naming conventions (e.g. does ember-cli-* and ember-* actually mean anything?)
better blueprints (e.g. index.js could include all available hooks as blank functions)
Plan forward for Ember Fastboot
Plan forward for Ember Engines (difficult to understand; lazy loading should be much easier to setup)
I’m excited to see a lot of these ship. Some things that come to mind:
Easier debugging of slow build times. For instance, making it easier to identify and reason about slow build steps or the ability to identify addons that don’t cache properly.
JS Sourcemaps improvements for large apps. They are currently extremely slow and pretty much unusable.
Ember Engines (although probably not strictly an Ember CLI team concern)
Also any plans for supporting the upcoming Babel 7
Absolutely rebuild+reload times. Especially on bigger apps, waiting on each save, tens/hundreds of times a day, is a major waste of developer time and focus.
This sounds good. Perhaps settle on some deploy default so ember-cli can optimize more based on what we are deploying. The deploy can than split vendor.js in a browser tread and Web/Service Worker treads to get even more speed.
It’s pretty frequent for me to see huge variability in my first build times. Sometimes the time jumps from ~20s to around 60-70s. Sometimes that’s right after updating addons, but often it occurs from just a restart of ember serve.
In almost all cases, the time goes back down to the normal range just by blowing away tmp and dist and restarting ember serve.
It would be a huge quality-of-life improvement if I never had to deal with the rebuild process inexplicably taking way longer than a fresh build.
Otherwise the list of priorities sounds great! Keep up the good work.
From my experience, I see ember-cli is extremely slow on windows, while the same app builds very fast on *nix (including mac) environments.
We did follow the instructions for ember-cli-windows and the issue persists still. Another thing we notice is the “so-called” anti-virus kicks in every time we build ember apps.
Working in a corporate environment where we do not have any* say on the exclusions, we have no choice but to wait for AV to complete it scanning (which takes around 10 - 15 minutes or more at times).
And these build times are the major roadblock to increasing ember utilization in a corporate world.
Any possibility of having anti-virus not to be too much suspicious on ember-cli would be of great help.
Ember engines are incredibly difficult to understand or at least time I read them they were so complex. I feel like lazy loading should be much easier than having to do all of this setup.
Currently environment.js, targets.js, coverage.js, deprecation-workflow.js, dotenv.js all reside in the config folder. Would love to see ember-cli-build.js moved to the config folder as well. It will suite well there perhaps with a simpler file name like build.js.
Faster Build times, ambitious but amazing goal would be to make it 10x faster.
Drop ember ES6 shimming, direct native npm imports.
ember microlibs importable in node.js. People should be able to require or import EmberObject or Ember.Route or Ember.Component and play with it/debug it interactively in node or use them in their npm packages(particularly Ember.Object/computed properties could be very useful in backend ORMs).
ember fastboot should be actively maintained with more focus on its development and advertising.
If we can get these things we will win the javascript space. I still believe that. This comes from someone who avoided Ember back in the days, I love ember since 2.0.
We should spin up a separate thread about this specifically. This is largely already possible, but likely poorly documented and probably has rough edges we should discuss…
Module unification would be the most important feature for us. We have about a thousand files now. Our current, unsatisfying workaround is to group the files using in-repo addons.
