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

Ember Fastboot

ember-fastboot.com

Post reply on HN
Print view View original

41–50 of 100 posts

Re: Ember Fastboot

#41

Post by hatsix »

Scarbutt wrote: post #34
tomdale wrote: post #24

Earlier quoted context omitted.

With Fastboot, somehow an additional, non-interfering layer of computation on the server does the same loop (without having to download anything and without significantly slowing down overall client app JS initialization) Right. Typically, the way most client-side JavaScript applications (or "SPAs") work is by having a small, static HTML file that doesn't contain much content (beyond maybe a loading page). It contain…

This is actually a very good comment that helps newbies decide whether they should create/need a "universal" app or not for SPAs. To add to this, there's also the claim about code reuse.

There are other initiatives in the ember-verse for solving the 'universal app' issue.

Specifically, ember-engines provides a way to separate code into logical apps, but having them appear to be a single app. It's currently 'experimental', but in very active development.

https://github.com/dgeb/ember-engines

For us, it provides the best-of-both worlds... a single interface to the customer, without having to load up all of the code, services, etc that are used in every corner of the app.

Re: Ember Fastboot

#42

Post by leeoniya »

nilliams wrote: post #33
leeoniya wrote: post #19

Earlier quoted context omitted.

i'm not sure i understand the distinction you're making. you write a client-side app and can render on server via Node and hydrate/attach the js on client after the dumped html. you get "instant" initial render and "progressive enhancement" once the js executes. ...or do everything on client.

My naive understanding is fastboot actually understands stuff like your client-side routing, and how an Ember app 'loads' and fetches data (from your API) so you don't have to recreate that stuff with duplicate code on the server-side like you would have to with the aforementioned React example, and I think, your library.

i think it heavily depends on how coupled your router is to your view and data/fetch layer. with domvm everything is decoupled, so wiring any of those modules up is pretty trivial.

a more fleshed-out demo would be valuable for a more realistic comparison. they mention the non-congruence between ajax vs node's fetch, but this is easy to shim so the same code works on both.

the main complexity is the view rendering and post-render hydration.

Re: Ember Fastboot

#43

Post by clessg »

tomdale wrote: post #9

One of the authors of FastBoot here. I'm happy to answer any questions anyone has. (P.S. One thing I think that's pretty meta-cool about the FastBoot site is that it is, itself, a FastBoot site, running on Heroku.)

How is initial render performance currently? If I recall correctly, Glimmer 1.x unintentionally slowed down initial render performance. Has this been or will this be addressed?

Re: Ember Fastboot

#44

Post by tucosan »

tomdale wrote: post #9

One of the authors of FastBoot here. I'm happy to answer any questions anyone has. (P.S. One thing I think that's pretty meta-cool about the FastBoot site is that it is, itself, a FastBoot site, running on Heroku.)

What is the font face you use for the logotype? It looks quite nice.

Re: Ember Fastboot

#46

Post by hatsix »

exogen wrote: post #39
tomdale wrote: post #36

Earlier quoted context omitted.

If I wanted to downplay competitors, why would I acknowledge that Angular 2 is doing something similar? Angular has much larger marketshare at the moment than React. It is fundamentally different, as I outlined above. That's not downplaying the work of React—they've done significant work in advancing the state of the art of DOM rendering that has hugely inspired the work of both Glimmer and Glimmer 2, as we have said…

I totally believe the work you've done here is significantly more polished and "conventionalized", that is awesome and congrats! Ember's tools are really slick. That said, everything you're describing – "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently" – is really, really, really the same thing we're (my team at least) doing with React. People aren't just using `renderToStr…

I think this argument is coming down to semantics.

Is there an 'analagous initiative' in React? No.

Can you end up with the same result in React? Yes.

There are people doing this in React, but each team needs to do it slightly differently because their app is setup differently. There are guides and examples on how to do it, but unless you setup your project exactly like the original author, you'll have to figure out portions of it on your own.

On top of that, you won't know if the modules that you are using will play well with the offline rendering.

The convention-driven approach IS the product... You make it sound like that is just a little bit of polish, maybe a page or two of documentation... But it took over a year of planning and architecture to make all of the changes. (There was a great demo of fastboot a year ago) Because of the planning and framework changes, however, every addon that follows the conventions will 'just work' with fastboot.

When Tom says "An App"... he means "Any App"... and that isn't something that I've seen being worked towards by the React community. It IS being done by other communities, as seen in this thread, so I think that it's valid for Tom to call this out as not being analogous.

Re: Ember Fastboot

#47

Post by zilean »

tomdale wrote: post #6
__derek__ wrote: post #5

Earlier quoted context omitted.

It's been possible with React for quite some time[1], and it appears to be included in Angular 2[2]. [1]: https://github.com/mhart/react-server-example [2]: https://angular.io

Sorry to nitpick, but I don't think the React example is an analogous initiative. ;) There is a huge gulf between "synchronously render a component in Node" and "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently." I touch on this a little bit in this talk[1], but the bulk of the work we've done over the last year is conventionalizing app boot and figuring out how to run multi…

Hi, Tom!

> do it concurrently

Does ember renders concurrently?

> There is a huge gulf between "synchronously render a component in Node" and "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently."

I dont think it is fair to say it that way. React implementation doing all this (except async/streaming rendering) is man-week at worst in existing medium sized project, and man-day for a new project with no pre-existing code.

Re: Ember Fastboot

#48

Post by elliotec »

look_lookatme wrote: post #28

Ember continues to be an antidote to the insane package/build madness in the JS ecosystem. It's opinionated for sure but it's also very easy to get started with.

I love Ember. It seems to be one of the only sources of sanity and reason in this community.

Re: Ember Fastboot

#49

Post by hatsix »

TN1ck wrote: post #23
tomdale wrote: post #6

Earlier quoted context omitted.

Sorry to nitpick, but I don't think the React example is an analogous initiative. ;) There is a huge gulf between "synchronously render a component in Node" and "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently." I touch on this a little bit in this talk[1], but the bulk of the work we've done over the last year is conventionalizing app boot and figuring out how to run multi…

What about a more ambitious example like this: https://github.com/erikras/react-redux-universal-hot-example

This looks similar to what was demo'd a year ago at EmberConf 2015... Something that works for a subset of people with a specific setup.

It looks really cool... if I'm understanding it correctly, it can hot-load code in production, which is awesome and scary.

It appears to be a quickstart, so what is upgrading like?

Re: Ember Fastboot

#50

Post by girvo »

elliotec wrote: post #48
look_lookatme wrote: post #28

Ember continues to be an antidote to the insane package/build madness in the JS ecosystem. It's opinionated for sure but it's also very easy to get started with.

I love Ember. It seems to be one of the only sources of sanity and reason in this community.

> only sources of sanity and reason in this community

Oh come on now, lets not be hyperbolic. I'm a massive fan of Ember, but I'm a bigger fan of Redux with React; the reason that Ember can afford to be opinionated is because the team is extremely smart and takes the best winning ideas from the outside "insane" community.

Post reply on HN