EmberConf 2017: State of the Union | Hacker News Reader

EmberConf 2017: State of the Union

emberjs.com

132 pointschadhietala119 comments

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.

Upgrading from 1.13 to 2.x isn't terribly challenging. (1.12 to 1.13 was much worse.) What's holding you back?

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.

There was a lightning talk on TypeScript at EmberConf that also gave a status update on how TS and Ember work together:

* https://www.youtube.com/watch?v=ZCHFjGSCqP4&feature=youtu.be...

It looks like full support could be landing soon. I know TS 2.2 added flexible enough class modeling to handle Ember's object system: https://blogs.msdn.microsoft.com/typescript/2017/02/22/annou...

Of course we're attacking that from the other side as well, and experimenting with native ES classes in Glimmer.

<3 mixonic, thanks for the reply, I was scouring the repo / blog for any word on typescript support, this looks promising.

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!

Glimmer looks awesome! Is it easy switch out handlebars for some other templating language?

The typical strategy is to design a language that compiles to Handlebars, e.g. http://emblemjs.com/.

It would be possible to support other languages more directly but they will tend to have a Handlebarsy flavor.

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 because my colleagues generally consider the frontend landscape to be the Wild West.

The only analog I can think of is statically typed SQL, which is in fact awesome.

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.

Props for the Eminem reference. I didn't see that coming AT ALL and I laughed for a good couple minutes.

GlimmerJS is going to be amazing. I can't wait to check it out soon.

Reply on news.ycombinator.com