The State of JavaScript: 2021 | Hacker News Reader

The State of JavaScript: 2021

2021.stateofjs.com

59 pointssaeedjabbar12 comments

Open articleView on HN

Discussion from five days ago: https://news.ycombinator.com/item?id=30357788

Ember's "Satisfaction" has been dropping every year. I wonder why.

This is a question I want to ask every time I see an ember post; Who uses ember?

Ghost (https://ghost.org/) uses it for their internal front ends.

Square has the largest Ember app outside of LinkedIn. I think it’s close to 3 million lines of JS?

Indie Hackers

IMO, it's because Ember is philosophically anti-react.

Ember is focused pretty heavily on convention over configuration which, IMO, ends up making everything a little harder to get into. You have to do things the "ember way" or you face a large uphill climb.

Ember is all encompassing as well. You make an Ember app. You don't make an app that happens to have some ember capabilities.

The reason react is popular (IMO) is because it's just the view layer. It allows for you to work with whatever other ecosystem you like in a fairly flexible manner.

I’ve always found the “convention over configuration” thing a bit of an odd descriptor for Ember. Outside of Ember CLI generating things for you or errors/unexpected results being thrown after something has been made, if you look for any documentation on those “conventions”, it’s really difficult to find (if it exists).

Do I really have to do things the “non-Ember” way just to figure out what the Ember way is on my own?

I found Ember to be very frustrating in that regard.

Probably because most of the apps are now considered legacy and their maintainers want to move to hotter tech

I used it recently and this was my take on it: Ember is behind the libraries it has overlap with. Whether it’s the router, data, or view layer, if you’ve chosen ember, you’re restricted not only to its convention but it’s inferior features. It has poor developer tooling, integrates with typescript poorly, and generates huge bundles with a hello world example.

It’s great if you like it and you’re productive with it, but if you’ve experience other options you might find it restrictive and stifling.

I mean I think Ember was ahead of the curve here and still is. React community finally caught up to ember style routing with react-location and remix. Ember has nested load states out of the box, ie: suspense loading. Ember data is essentially Apollo store. It has a decent reactivity framework built in similar to Mobx. It's actually positioned pretty well surprisingly.

You know, I don’t doubt you’re right - I only used it for a couple small projects. It could be that I’m bad at reading the manual. It could also be that the mediocre typescript support was getting in my way too much - that part was very frustrating.

I don’t think of it as a direct comparison to react or the react community though. There are other frameworks like it though and in my experience, it is better than they are. I guess what it came down to was that when I was confined to ember conventions, it seemed like I could often do so much more with other tools, with fewer constraints and restrictions. I suppose what the framework offered that the individual libraries didn’t wasn’t very useful to me.

Frameworks always come with trade offs and sometimes conventions are a great thing to trade for. A large team sharing an ember code base might actually be more productive than one using an ad hoc framework of all the other tools I like.

Back when I used symfony in php land for example (comparable to laravel), I loved its conventions in the context of a large team and rarely thought about the times it got in the way.

Reply on news.ycombinator.com