A great read that recaps the history of Ember, what helped it stand out from the crowd in the past, and what worked and what didn't, segueing into the introduction of Glimmer.js, a standalone UI component library extracted from Ember 2.10. Congrats to Tom, Yehuda, Godfrey, and the rest of the Ember Core Team! Looking forward to another productive year.
I was playing with glimmer.js, it feels like you can now "NPM your way to a full app" similar to the react eco system (if you're into that sorta thing).
Our company's main application is built on top of ember 1.13. We've pushed off doing the upgrade and are leaning towards a move to react (all our mobile apps are done in RN). This might be a solution.
Just now seeing this. Honestly it's just a big project and everything else in our solution has moved on to react. Upgrading would be far less work for sure but it's still an investment.
I hope they start making TypeScript a first class citizen in Ember, just as they have done with Glimmer, it really makes development so much easier, hopefully with .get() and .set() going away it will make it easier for the typescript compiler to figure out what is mutating what.
Yes! Ember is a really awesome framework, when coming from the likes of Django where there is a blessed version of everything you need (like a router, file layout, template language etc) it's really nice for those to all be included.
This post hits the nail on the head with Embers problems though, and it does seem like it's been left behind a bit in terms of using the latest and greatest tools. For example migration to Babel 6 from Babel 5 is only just finishing for the core components. get() and set() are also not so nice for newcomers.
As the post highlights this is mostly due to the projects age and baggage Ember carries. I see this as a positive though, Ember is pretty damn mature and well thought out, even if it's lacking in some syntactical sugar (and sometimes the latest and greatest in JS libraries/tools is such a fast moving target that it's just not possible to track it).
The future is looking bright for Ember! Well done!
Write in a language that compiles to another language that itself compiles to markup...
The web frontend world is crazy to a backend engineer. We have hard problems to solve too, but ours usually arise from well-understood problems, such as CAP theorem.
It's somewhat jarring when people use "we" as if they're in a faction and they're the spokesperson of that faction. It's almost as bad as using "you guys" when faced with a single commenter.
Anyways, you can't think of a single analogue for the emblem->handlebars example?
It's crazy, sometimes web frontend is an echo chamber and you will get burned to the stake if you suggest doing anything simpler like just writing markup instead of a template language that translates to markup or a language that translates to that language that translates to markup. But it keeps people employed.
Some days, I can handle the front-end world. Other days, I just want to go back to writing old-school desktop clients in VB6 or WinForms. Mostly, this state has to do with whether the Goldbergian accretion of tooling on the front-end side is working today, or if somebody has deprecated a package and brought the whole Jenga tower down.
I don't believe so. However the rendering engine is optimised for Handlebars, it can statically analyse what parts of your template are dynamic and what are not. I think the performance benefits are worth learning a new template syntax.