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

Ember.js 1.13.0 and 2.0 Beta Released

emberjs.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Ember.js 1.13.0 and 2.0 Beta Released

#31

Post by insin »

empyrical wrote: post #14
Nemcue wrote: post #11

Earlier quoted context omitted.

You didn't provide a link. I assume you were going to link the blog post announcing their switch to Mithril — that didn't contain any rationale behind it. I did find this however, which goes into details about why Ember was not a good choice for them: http://discuss.flarum.org/139-introducing-flarum-s-fast-new-... Seems to be a well based choice. Doesn't seem to have anything to do with performance though. While Mith…

Has anyone made a JSX transformer that plays nice with Mithril? Seems like it would make using that api you provided a snippet of less painful

You can use Babel's JSX transformer for HTML elements by sticking this in a .babelrc file:

    {
      "jsxPragma": "m"
    }
You'll also be able to use it for Mithril components when the next version of Mithril is released. Relevant issue: https://github.com/lhorie/mithril.js/issues/632

Re: Ember.js 1.13.0 and 2.0 Beta Released

#32

Post by ffn »

I, for one, am glad Ember is still going strong. And, as a heavy emberjs user, most of these changes feel like a step in the right direction. But after reading through the change log blog, I have several questions (not complaints) for the core team (in case Dale / Katz and cronies are reading this):

1. What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has that feature been scrapped / moved into a separate project altogether?

2. There was no mention of the deprecating changes to the initializer API (i.e. the splitting into instanceInitializer and vanilla initializer). Have we gone back to the old initializer API in 2.0?

3. With the removal of action bubbling, do we now have to manually bubble up actions that start in some nested controller but gets handled in application route? For example, say you have an AdminUserController and it has an action that generates an ephemeral flash message, but you handle flash rendering in your application route. Do you now have to laboriously put an actions: { handleFlash { ... } } on every route along the way?

Re: Ember.js 1.13.0 and 2.0 Beta Released

#33

Post by lennexz »

ffn wrote: post #32

I, for one, am glad Ember is still going strong. And, as a heavy emberjs user, most of these changes feel like a step in the right direction. But after reading through the change log blog, I have several questions (not complaints) for the core team (in case Dale / Katz and cronies are reading this): 1. What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has tha…

I am not (Dale / Katz and cronies) but I read somewhere that major fastboot work will begin after 2.0 beta is released. This will be to align it with glimmer changes. So hold on tight we still have more goodies coming in the 2.x series :)

Re: Ember.js 1.13.0 and 2.0 Beta Released

#35

Post by wycats »

ffn wrote: post #32

I, for one, am glad Ember is still going strong. And, as a heavy emberjs user, most of these changes feel like a step in the right direction. But after reading through the change log blog, I have several questions (not complaints) for the core team (in case Dale / Katz and cronies are reading this): 1. What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has tha…

> What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has that feature been scrapped / moved into a separate project altogether?

SEO-only FastBoot shipped in canary a while ago (as the `ember-application-visit` feature). It is designed to work with the FastBoot addon (https://github.com/tildeio/ember-cli-fastboot).

Rehydration, the big enchilada, depends heavily on the Glimmer work, and should begin momentarily.

> There was no mention of the deprecating changes to the initializer API (i.e. the splitting into instanceInitializer and vanilla initializer). Have we gone back to the old initializer API in 2.0?

We're sticking with the split-apart API we shipped a few releases ago. It's important to make FastBoot efficient with real-world addons.

> With the removal of action bubbling, do we now have to manually bubble up actions that start in some nested controller but gets handled in application route? For example, say you have an AdminUserController and it has an action that generates an ephemeral flash message, but you handle flash rendering in your application route. Do you now have to laboriously put an actions: { handleFlash { ... } } on every route along the way?

We're starting with more laborious (with services as an escape valve), but have some ideas for conventional situations where you could get away with less ceremony. Stay tuned! (by which I mean, there will be RFCs in the near future addressing this kind of issue).

Re: Ember.js 1.13.0 and 2.0 Beta Released

#37

Post by Tankenstein »

ffn wrote: post #32

I, for one, am glad Ember is still going strong. And, as a heavy emberjs user, most of these changes feel like a step in the right direction. But after reading through the change log blog, I have several questions (not complaints) for the core team (in case Dale / Katz and cronies are reading this): 1. What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has tha…

I'm not really an Ember dude, but i might have some input on 3. In react, when you start, it looks the same way. A bunch of functions passed down like 5 components. Fortunately, there's a way better way, and it's flux. I'm guessing Ember will let you use something like flux.

Re: Ember.js 1.13.0 and 2.0 Beta Released

#38

Post by girvo »

lobster_johnson wrote: post #29
hajile wrote: post #22

Earlier quoted context omitted.

Most React devs use react-router which is heavily inspired by ember's router but the JSX-syntax makes it easier to work with IMHO. That said, I think Ember's an excellent choice and basically on par with React (it's up to your development style).

It's been a while since I used react-router, but I think this is one place where the Flux flow is better. Navigation is state, so we built a store to track it. It mediates between a UI model (which abstracts the window location and pushstate stack) and an internal state. Routing involves dispatching an action to request a specific URL, and changing the view to the navigation state is handled by the app's root "applic…

We built a very similar component for React, hooked into Flummox. The nice part is that async "just worked", and having the entire router available as a Flux store with actions that you can fire to change the page made integration powerful.

We also added some extra little code to make it run on the server: the component renders down to an tag, and the router runs correctly, so everything works isomorphically, and as a neat bonus the bulk of the site works without Javascript enabled.

Post reply on HN