Hacker News Reader

Comment by joverholt | Hacker News Reader

Ember.js seems to check off a lot of those boxes, if you are willing to use a complete solution and not do the 'pick and choose' method of react and friends. While it has lost popularity in the last few years, it has been moving forward technically. It has become leaner and meaner.

Really learning the "Ember Way" to do things can reduce some of the friction the author mentions.

Ember Data can allow you to talk to multiple api backends (differing schemas) while presenting the same model to your UI. If you use the default JsonApi[0] based backend, you get a lot of things for free: powerful filtering, side loading data (relationships), consistent error handling. Sometimes it can be chatty, but that's a spot where HTTP2 can help.

Use ember-concurrency add-on and you have a nice way to manage your requests, things like de-bouncing, handling loading spinners, etc.

[0]https://jsonapi.org/format/

View on HN

I'm saddened to see that almost a decade after Ember's release, the front-end world still insists rolling their own (terrible) reimplementation of it.

I would've expected that a decade later we would've settled on an Ember-like framework for the front-end and moved beyond constructing URLs and parsing JSON responses manually but apparently not.

The rest of the world moved on from Ember because Ember is a pain in the ass to use.

It has improved a lot though - checkout ember octane

As someone who's not a front-end developer, but who works near them and sees the (React) code they produce and their general productivity (or lack thereof), what's so bad about it?

To me as a backend developer just reading Ember's docs, it seems like Ember provides most of the conveniences I take for granted in a backend web framework such as Django, Rails or Laravel.

On the other hand, the front-end code I see from the people I work with seems to have no standard for structure (every project has its own), reinvents the wheel all the time (using Axios and building the URLs manually with string concatenation for example), etc. Most of the stuff they do (and redo) from scratch seems like something that would be handled by Ember to begin with.

So what's so bad? I feel like (as an outsider - feel free to prove me wrong) Ember is fine for most purposes, and edge-cases where React or alternative approaches do provide a benefit can be used ad-hoc without having to use it for your entire application.

Ember does indeed include a lot, and it’s all designed to work nicely together. I also develop backend much more than front end, but knowing that we just are using the primary Ember way of doing something reduces the number of decision one has to make. And it should allow other Ember devs to hop into your software more easily due to its opinionated nature.

I thought Sails.js or something like it would take the JS scene by storm, and React would move into more of a specialty application spot, but instead everyone decided they were special.

Ember is the closest to what I thought JS development should have been like, and I really appreciate what they’ve built. RedwoodJS seems promising too but we’ll see.

I was just talking with someone earlier today about how I sometimes wonder if we traded off “performance” (heavy air quotes intended) for developer productivity too quickly. Ember solves a lot of the big problems of modern web dev and data handling like this blog post points out, and when I think back to my times working with React and wonder if that trade off was really worth it.

Seconded, it even handles batching for you.

How does Ember.js compare to Angular? Both seems to aim to be a complete solution.

(I'm not familiar with Ember.js)

Reply on news.ycombinator.com