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

11–20 of 100 posts

Re: Ember Fastboot

#11

Post by egeozcan »

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…

> conventionalizing app boot and figuring out how to run multiple instances concurrently

I am a software engineer who usually develops also for the client side and I follow and experiment with the JS trends because I find them interesting. However, I don't understand what you mean by these. Could you please be more specific? Thank you.

Re: Ember Fastboot

#12

Post by MatthewPhillips »

lotyrin wrote: post #3

This is great! Anyone know how far analogous initiatives are for competing projects?

I work on server-side rendering for DoneJS[1] and ours is probably the best solution out there today, in my biased opinion. We provide:

* Fully asynchronous rendering, so you don't have to awkwardly architect your app so that it can be rendered synchronously.

* Everything is fully progressively loaded. This means if you go to a particular page in your app, only that page's JavaScript and CSS will be downloaded in the client. Additionally the correct css link elements will be inserted.

* Caching XHR requests so that they are not repeated on the client (data used to render is included in the page).

What makes our solution unique is that you have to think about the server very little, if at all. If you need to make a request to services, just make it in your code. No additional wiring is needed and everything will be server rendered.

Much of this is possible because of Zones, a spec that is being worked on for standardization in TC39. We have a library that implements Zones[2] with SSR in mind. This is what makes XHR caching possible, for example. Check out this simple jQuery example app[3] (using jsdom on the server) to see how easy Zones make things.

I did a talk at Node Interactive this year about SSR and what goes into a good SSR solution: https://www.youtube.com/watch?v=wRYdrfrL6ZQ

[1]https://donejs.com/ [2]https://github.com/canjs/can-zone [3]https://github.com/canjs/can-zone-jquery-example

Re: Ember Fastboot

#13

Post by nilliams »

leeoniya wrote: post #8
lotyrin wrote: post #3

This is great! Anyone know how far analogous initiatives are for competing projects?

supported in the tiny/fast domvm [1] out of the box. [1] https://github.com/leeoniya/domvm

This is rendering a component server-side though correct, a la. React?

(In the comment above Tom is suggesting fastboot goes significantly further than this, to make your 'client-side app' render server-side).

Re: Ember Fastboot

#14

Post by sotojuan »

Ember just keeps getting more and more interesting (Ember NYC meet ups have been great so far!). Going to have to give a good, lengthy try. Coming from React, I like the cli tool and strong community conventions.

Re: Ember Fastboot

#15

Post by jakubp »

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.)

Hi, I'm new to Ember and more complex JS apps in general. Can you confirm my initial "understanding" of what you did?

Normally Ember app would render everything within the browser after all JS is downloaded and components etc. are processed. 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) and sends the output to the client. It does it for every route separately. I'm guessing that somehow the client's processing is disabled on that first "pageview" to avoid double calculation. Is that correct? (if it is, it's very cool :)

Re: Ember Fastboot

#17

Post by ashleyw »

egeozcan wrote: post #11
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…

> conventionalizing app boot and figuring out how to run multiple instances concurrently I am a software engineer who usually develops also for the client side and I follow and experiment with the JS trends because I find them interesting. However, I don't understand what you mean by these. Could you please be more specific? Thank you.

@tomdale explains how fastboot runs concurrent instances here: http://youtu.be/xFTDNGZExuU?t=1h21m40s

Re: Ember Fastboot

#19

Post by leeoniya »

nilliams wrote: post #13
leeoniya wrote: post #8

Earlier quoted context omitted.

supported in the tiny/fast domvm [1] out of the box. [1] https://github.com/leeoniya/domvm

This is rendering a component server-side though correct, a la. React? (In the comment above Tom is suggesting fastboot goes significantly further than this, to make your 'client-side app' render server-side).

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.

Re: Ember Fastboot

#20

Post by sotojuan »

diegorbaquero wrote: post #10

Amazing work. Just read all of this: http://tomdale.net/2015/02/youre-missing-the-point-of-server... This is probably the thing I hate the most from client-side apps. Can't wait to test this and Angular 2 on production!

And I just read the quickstart[1], amazingly it only seems to take two commands to do (obviously just the basic example, but still).

[1] http://www.ember-fastboot.com/quickstart

Post reply on HN