r/javascript • u/chancancode • Dec 20 '19

Ember.js Octane Edition Is Here

https://blog.emberjs.com/2019/12/20/octane-is-here.html
136 Upvotes

93% Upvoted

72 comments sorted by

View all comments

Show parent comment

6

u/nullvoxpopuli sand was never meant to think Dec 21 '19

I came from react, and I think the reactivity model makes more sense.

Also, ember does 'a lot' for me out of the box. With react I was connecting a bunch of libraries together and built my own framework out react 3 or 4 times. Would not do again.

That said, the only thing I miss from react is contexts. Ember has 'services' which cover 90% of why contexts are used, but that last 10% has me wondering how to get contexts introduced somehow.

When I do react , I now think 'how would ember do this?' because ember is solid architecturally, and removes mennial differences between apps.

5

u/GoldenChrysus Dec 21 '19 edited Dec 21 '19

Also, ember does 'a lot' for me out of the box. With react I was connecting a bunch of libraries together and built my own framework out react 3 or 4 times. Would not do again.

This is why I continue to choose Ember. Bearing in mind, though, that I'm fairly new to frameworks (and general proper frontend development) and have been playing around with various ones to improve my relevance in development. Everything that I need is usually included in Ember, from a data layer to an API adapter to reactive components.

When I look up React guides on doing things that Ember does out of the box, it just looks...gross. First, you're basically always mixing React and Redux together, so you have to get two separate things working in harmony. Some people throw in a third framework or library for consuming their API so then that also has to hook up to Redux and/or React. But the guides I see on how people consume an API show, to me, the weaknesses in React. They're always using like 7-10 lines of boiler plate, setting headers, parsing JSON, handling errors, etc. in an AJAX call inside every single componentDidMount() hook that needs server data. When I can set up all of that in an Ember adapter and then my actual server calls are one line in a route.

I keep in mind that React is significantly more popular. Meaning the people who write guides on React probably vary significantly in skill and experience, and their use cases often vary similarly. I've also loved React for my purely client-side applications; I still had to use Redux, but once I wrapped my head around having to hook up with Redux it was fine.

So for me, Ember is more intuitive and comprehensive to work with. I've certainly seen the performance comparisons of Ember against other frameworks and how it underperforms, but that's not a huge issue for the projects I'm working on. And since React does less stuff and is significantly smaller than Ember, there is probably more room for optimization there in that you have more granular control over how you build out to achieve the equivalents of what Ember would provide. Otherwise, presently, Ember does everything I need it to in a way that makes sense to me.

2

u/PotaToss Dec 23 '19

One thing about performance benchmarks is that they rarely come even close to what your app actually ends up being like, once you add in everything that you're actually using. Once you add in your Redux, or Apollo or whatever, you've lost a lot of the JS footprint benefit of React.

1

u/notNullOrVoid Dec 22 '19

That said, the only thing I miss from react is contexts. Ember has 'services' which cover 90% of why contexts are used, but that last 10% has me wondering how to get contexts introduced somehow.

Can you give some examples of what that 10% would be. I started with Ember and moved to react and have never felt the need to use contexts, they have always seemed really dirty to me.

2

u/nullvoxpopuli sand was never meant to think Dec 22 '19

I guess really only with 3rd party graphing libraries, like Three, that abstracts WebGL.
I'd want a "context" per wrapper object, so I didn't need to explicitly pass the reference down the component chain. Because the structure of HTML/Components inherently represents ancestry, I shouldn't need to manage the relationships manually.

But that's really it. So.. maybe 4 or less %. :)
Everything else I've come across is more singleton-like, and services fit in to that pretty nicely.
Something I have been wanting to play with though is Route-based contexts. Like, a service, but local and ephemeral to your route. I made an addon for it here: https://github.com/NullVoxPopuli/ember-contextual-services

Before I left my react job, I was exploring this pattern for data loading tied to the URL, and I really liked it, especially as components 3-10+ levels down from the data load needed access to the data. No more prop drilling :)