The problem is that webpack has been innovating rapidly while we are left reimplementing that stuff with far fewer contributors. We’re going to get left in the dust
-
-
npm install thing -> import stuff from thing is absolutely 100% a real and significant feature of using webpack that ember still lacks (though I know we're getting closer) and the cost of not having this feature is far from trivial in real life apps
-
I definitely quickly feel paralyzed when I go down the path of wanting to use a 3rd party module to solve some problem or experiment with an idea.
-
When I started thinking about Ember in 2018 over the holidays, "being able to easily import from npm" quickly shot up to the top of my list. It sucks wanting to use an npm module and having to remember the song and dance. Let's fix it.
-
(sounds like a good choice for my own
#emberjs2018 post)
End of conversation
New conversation -
-
-
I totally get the frustration of wanting to do something in your app and feeling held back by your tools.
-
Emma the problem is that for Ember to go full webpack the "right way" they need to use modules top down, which is (last I worked with the cli team and ember team) is a pretty tough feat. Glimmer is promises of the future however. Just know we actively want to have webpack+ember
-
Ember makes a very valuable yet discrete tradeoff: Compat at the cost of being held back a little, but with a much more stable moving ecosystem.
-
Dependency Injection would need (or should in my subjective opinion) be repalced with ESM, and that's a whole archetectural rewrite almost.
-
Some cases of DI might want to be rewritten as pure modules, but DI *state* would still want to be separately managed. Also, cases where you use DI to swap out different versions of a service wouldn't necessarily be able to reference a module name directly.
-
Some sort of build-time DI would be necessary (so that importing from "services/fetch" would be able to be swapped out if needed), but then we could end up with something like:
-
import Fetch from "app/services/fetch"; import { service } from "@ember/injections"; export default class {
@service(Fetch) fetch; handle() { this.fetch // an instance of fetch } } -
Note that an import *roughly* like this is already necessary for
@typescriptlang to have enough info to be usable for services today (`@service fetch!: Fetch;`) so rationalizing DI in something like this way would be
from where I stand. - 14 more replies
New conversation -
-
-
It's not any specific things, it's just the ecosystem as a whole intangible thing. The minor pain points which are found and solved by the large Webpack community just aren't with the smaller ember community
-
We need to accept that we're tiny compared to the broader JS ecosystem and try to match conventions with them, as Rails has done with Ruby's ever-evolving conventions
-
Not to toot my own tweet, but this is exactly what I wrote about in my
#EmberJS2018 post today:https://mobile.twitter.com/brianmfitch/status/992475638652112898 … -
Yes, this is pretty much everything I've been thinking! Thanks for writing that
-
Awesome. Happy to do it.
End of conversation
New conversation -
-
-
Speed, code splitting, async imports, import from npm. Also other things that are fixed now but required extra work in addon land line typescript support, GraphQL, etc. Those were solved problems in Webpack that took longer to get to Ember.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.