Comment by cobertos
5 years ago
Ember was the first framework I used and also the most frustrating. At least with Vue and React I can poke at the internals and they make sense, but Ember's internals had so many oddities that thoroughly confused me.
5 years ago
Ember was the first framework I used and also the most frustrating. At least with Vue and React I can poke at the internals and they make sense, but Ember's internals had so many oddities that thoroughly confused me.
What I like about Ember is that it gives a lot of rigid structure that, at least at one point, made it comparatively easy to work on multiple Ember based projects and be productive sooner.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it out of necessity anyway.
Why might that be, you may ask?
> [...] we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
https://github.com/emberjs/ember-render-modifiers
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need. Go ahead and try interacting with individual elements of a Glimmer component in a vanilla Ember project and see how productive and ambitious your web app will be.
Strangely (and thankfully), the RFC for what I think is a needlessly complicated alternative for lifecycle interaction is effectively stalled:
https://github.com/emberjs/rfcs/pull/567
By their own verbiage, the only official way to interact with component/element lifecycle is an antipattern.
So far Svelte and SvelteKit are avoiding all that extra crap. The day that Svelte calls its own solutions "antipatterns" and spends years pontificating things like the actor pattern will be a sad one.
/rant
This is so HN, in an Svelte thread memories from Ember (sharing your sentiments though).
HAHAHA
I try not to go full HN, but sometimes you do.
And I shouldn't have made it about that. As I get older I the more I just get tired of extra things. There's always a price when you add more things. Svelte technically does add things, but I think it has better bang for its buck. The fact it doesn't pointlessly impose OOP constructs upon the end-developer is a big win for me.
Yeah, Svelte is pure gold.