Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ember.js Octane Edition

blog.emberjs.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Ember.js Octane Edition

#41

Post by pier25 »

dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

My current Mithril app weights 30kb gzipped. That includes a router and an http client (both included in Mithril).

Re: Ember.js Octane Edition

#42

Post by atonse »

I've been using Ember in some capacity for 6+ years now I think. And have been using ember on about 5-8 different production-shipped projects (with Elixir backends) and it's been a great combination for our company from a tech standpoint.

The bigger issue has been finding contracting talent that's more affordable. Since there's a real dearth of talent in general (and freelance contractors) in the Ember world since the community is already so small, the few that are there are too expensive for us to hire for more than a couple week bursts.

I hope Octane helps bring more people to the Ember ecosystem and introduces more variance into the contractor rates, since I want to keep using Ember for future projects.

Re: Ember.js Octane Edition

#43

Post by pier25 »

The ergonomics look nice but Ember still needs to make a lot of progress in bundle size and performance.

Glimmer is certainly much faster than previous Ember versions but it's barely competitive by today's standards.

https://krausest.github.io/js-framework-benchmark/current.ht...

Also, in that link check how Glimmer fares in start-up metrics (very bad). And it's not even the complete Ember framework.

Re: Ember.js Octane Edition

#45

Post by preommr »

k__ wrote: post #32
jchw wrote: post #12

With a cursory glance, a lot of these changes make Ember look more familiar for React users, w.r.t. not treating root specially (versus Angular for example) and with moving away from mixins for more functional composition. All in all I think this is great and would like to take a look at Ember and see what it has to offer nowadays.

Yes, basically all frameworks became React-like after the success of React. In my opinion, the only one that got a really interesting take on components was Cycle.js, the rest simply tried to bend their APIs to look more Reactish.

More like everything is seen from the viewpoint of react. I've seen people lump in frameworks like angular and vue with react while comparing them in a way that don't make sense for the first two.

Re: Ember.js Octane Edition

#46

Post by DigitalSea »

I kind of hoped that Ember would ditch Handlebars for templating and move towards something a bit nicer. I find Handlebars syntax to be quite annoying and tedious to write. Kudos to the Ember team for persisting with the framework, I know LinkedIn is using it (and learned in this thread that Intercom is as well).

If this latest Ember release excites people, I highly recommend that people check out what the Aurelia team have been working on with Aurelia 2 https://aurelia.io/blog/2019/10/31/aurelia-vnext-2019-fall-u.... I have always seen Aurelia being similar to Ember, except the syntax is cleaner (especially templating) and is conventions based. There are a lot of similarities between the two.

One thing that Aurelia are doing in Aurelia 2 is an option to shake it down to a tiny app. The problem with frameworks like Angular, Ember and Aurelia 1 is they ship a lot of code to the browser and startup time can be quite slow. In Aurelia 2 they're working on quite a nice and promising AOT compiler. I really wish the Ember team would focus on bundle size, what I have seen with Octane, the bundles are huge.

My money is on Aurelia 2 when it launches in 2020, so it is nice to see Ember firing back as well, great timing given the recent State of JS survey yielded people are really frustrated with Angular.

Re: Ember.js Octane Edition

#47

Post by DigitalSea »

k__ wrote: post #32
jchw wrote: post #12

With a cursory glance, a lot of these changes make Ember look more familiar for React users, w.r.t. not treating root specially (versus Angular for example) and with moving away from mixins for more functional composition. All in all I think this is great and would like to take a look at Ember and see what it has to offer nowadays.

Yes, basically all frameworks became React-like after the success of React. In my opinion, the only one that got a really interesting take on components was Cycle.js, the rest simply tried to bend their APIs to look more Reactish.

Aurelia is a framework that didn't rewrite their API's to try and become Reactish either. They have been over in their own lane, while Vue seemingly becomes React Lite.

Re: Ember.js Octane Edition

#48

Post by nullvoxpopuli »

pier25 wrote: post #43

The ergonomics look nice but Ember still needs to make a lot of progress in bundle size and performance. Glimmer is certainly much faster than previous Ember versions but it's barely competitive by today's standards. https://krausest.github.io/js-framework-benchmark/current.ht... Also, in that link check how Glimmer fares in start-up metrics (very bad). And it's not even the complete Ember framework.

those tests there are not using current stuff. The glimmer VM has had loads of perf improvements since those versions.

something else to keep in mind is that both the glimmer and ember benchmarks in that test are full framework-level apps. Not just the view layer. This is largely what impacts the startup time and memory usage.

Re: Ember.js Octane Edition

#49

Post by nullvoxpopuli »

Touche wrote: post #22
dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

Just for anyone reading, 100kb is the max you want for initial load if targeting mode. This means that Ember is a bad choice for most web apps today. React isn't a great choice either because the lack of features and relative large size means you have to add more stuff and quickly get large builds.

100kb is an ideal right now. Many apps will have more than that in just CSS.

Re: Ember.js Octane Edition

#50

Post by nullvoxpopuli »

pier25 wrote: post #41
dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

My current Mithril app weights 30kb gzipped. That includes a router and an http client (both included in Mithril).

what does it do?
Post reply on HN