4 ms·
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. W
by joverholt 6y ago
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/ https://jsonapi.org/format/
- Nextgrid 6y agoI'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.
- whalesalad 6y agoThe rest of the world moved on from Ember because Ember is a pain in the ass to use.
- enspandi 6y agoIt has improved a lot though - checkout ember octane
- Nextgrid 6y agoAs 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.
- karmelapple 6y agoEmber 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.
- shakezula 6y agoI 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.
- orf 6y agoSeconded, it even handles batching for you.
- yrio 6y agoHow does Ember.js compare to Angular? Both seems to aim to be a complete solution. (I'm not familiar with Ember.js)
- shakezula 6y agoI 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.