6 ms·

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 t

by tomdale 11y ago

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

jakubp 11y ago
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 :)
- lossolo 11y ago
  Yes it's correct for first route you visit, it's rendered on server and sent already rendered to your browser, then the rest of the framework is downloaded and another request is rendered in your browser.
- tomdale 11y ago
  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 contains <script> tags that point at your JavaScript payload. First the browser downloads the HTML, then the JavaScript, then the JavaScript runs and fetches the data via XHR. Only then does the user see the content they were after in the first place. This actually works surprisingly well for "workspace" apps where the user is using it throughout the day (Gmail, Google Docs, etc.) On modern devices with good broadband, the difference is negligible. But the thing this sucks for is content sites, where you aren't using an "app" but you're just clicking a link in Twitter or something. If it doesn't load within a second or so, you aren't that invested that you don't just close the tab. That has been the biggest source of pushback on frameworks like Angular and Ember for sites like this. FastBoot bends the curve by replacing that static HTML file. Rather than serving an empty document that just points to JavaScript assets, we keep your Ember app running in Node.js on the server. When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser. You can think about this is as effectively outsourcing the JavaScript runtime to the server for the first load, but then the browser can take over again on subsequent navigations so it's very fast. I think FastBoot is a great option for search crawlers, Facebook and Twitter embedding (it supports Open Graph and Twitter Cards), and supporting JavaScript-less clients. Most importantly, it's a way to get content quickly to users with a cold cache. That said, we are planning to aggressively take advantage of App Cache and Service Worker, so ideally any second-time visitor to your site only has to fetch the raw data to see what they're after. 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 :) Currently it does a full rerender once it loads, but one of the motivating features for writing Glimmer 2 is the ability to quickly "rehydrate", so that rerenders are imperceptible to the user assuming nothing has changed. We'd also love to automatically serialize the backing models of the app so you don't have to double fetch.
  - Scarbutt 11y ago
    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.
    - hatsix 11y ago
      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 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.
  - jakubp 11y ago
    Thank you for a thorough answer.
  - mtberatwork 11y ago
    > When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser. Aren't we now just back to square one again in terms of MVC frameworks? What are the advantages here over simply implementing Django, RoR, Spring, Laravel, etc and cutting back on the JS (at least in terms of content-driven sites)?
    - orf 11y ago
      > What are the advantages here over simply implementing... You get all of the advantages of single page apps, without the unresponsive initial load time. There are also whole classes of apps you can't build with Django, RoR etc, so the question is a bit ridiculous IMO.
      - takno 11y ago
bl4ckm0r3 11y ago
is the ember inspector working 100% with fastboot? (having some error while inspecting the index controller). Btw great job!
- tomdale 11y ago
  The Inspector works by injecting some debug code into the running app, so it won't work with FastBoot because the JavaScript is running on the server. That said, it should work just fine once the Ember app finishes loading and running in the browser. I would love it if you could file an issue on the Ember Inspector GitHub page with the error you're getting.
  - bl4ckm0r3 11y ago
    At the ember conf now...will do some testing and eventually file a bug!
clessg 11y ago
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?
- sandstrom 11y ago
  There were some regressions, but it's back on par since the last few releases (2.3+ or so). In addition, Glimmer 2 is near completion, and when ready will provide further speed ups to initial rendering.
- gavinjoyce 11y ago
  We're running Ember 2.2 on Intercom and we've found it to be faster than 1.x. In addition to this, it looks like Glimmer 2 will bring significant render time improvement for both initial render and subsequent DOM updates.
tucosan 11y ago
What is the font face you use for the logotype? It looks quite nice.
- mschoening 11y ago
  A slightly modified version of Tablet Gothic (https://typekit.com/fonts/tablet-gothic https://typekit.com/fonts/tablet-gothic).
girvo 11y ago
Having implemented a similar concept using React (and Flummox), I'm curious how FastBoot solves the async data fetching problem; does it require the developer to be careful about how things are set up, or does a solution naturally fall out of how Ember works? Running what amounts to an event-loop once to get the HTML result wasn't that difficult, but ensuring that the app wasn't relying on said event-loop to render parts we needed out as HTML on the server was slightly annoying (but not insurmountable).
- zilean 11y ago
  Ember has default model() hook for routes, and propose to add extra data fetching you need in children components into afterModel hook. Everything is working just like you would set it up with React, except that with Ember declaring data dependencies on route is existing convention. And React gives you maybe a little bit more control around that.
  - girvo 11y ago
    > declaring data dependencies on route is existing convention That makes sense, I believe that's exactly what react-async does (if I recall correctly?) with react-router. For our project, we basically call "await ApiActions.getData(routeParams)" in the server's route, after pulling that params out, which is effectively the same idea, and it worked quite well. I'm curious how one would tackle that from a different perspective, but it seems we all end up coming to the same conclusion!
qaq 11y ago
Congrats on great feature. Do you guys have any solid plans on when rehydration might become available?
staticelf 11y ago
I use Ember everyday. But still I don't understand the most basic questions: What is this? And why should I use it? I slummed through the quick start but that didn't make me any wiser. EDIT: I read up on your blog post and you guys should definitely put some of that into the web page.

by tomdale 11y ago

jakubp 11y ago

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

lossolo 11y ago
Yes it's correct for first route you visit, it's rendered on server and sent already rendered to your browser, then the rest of the framework is downloaded and another request is rendered in your browser.
tomdale 11y ago
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 contains <script> tags that point at your JavaScript payload. First the browser downloads the HTML, then the JavaScript, then the JavaScript runs and fetches the data via XHR. Only then does the user see the content they were after in the first place. This actually works surprisingly well for "workspace" apps where the user is using it throughout the day (Gmail, Google Docs, etc.) On modern devices with good broadband, the difference is negligible. But the thing this sucks for is content sites, where you aren't using an "app" but you're just clicking a link in Twitter or something. If it doesn't load within a second or so, you aren't that invested that you don't just close the tab. That has been the biggest source of pushback on frameworks like Angular and Ember for sites like this. FastBoot bends the curve by replacing that static HTML file. Rather than serving an empty document that just points to JavaScript assets, we keep your Ember app running in Node.js on the server. When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser. You can think about this is as effectively outsourcing the JavaScript runtime to the server for the first load, but then the browser can take over again on subsequent navigations so it's very fast. I think FastBoot is a great option for search crawlers, Facebook and Twitter embedding (it supports Open Graph and Twitter Cards), and supporting JavaScript-less clients. Most importantly, it's a way to get content quickly to users with a cold cache. That said, we are planning to aggressively take advantage of App Cache and Service Worker, so ideally any second-time visitor to your site only has to fetch the raw data to see what they're after. 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 :) Currently it does a full rerender once it loads, but one of the motivating features for writing Glimmer 2 is the ability to quickly "rehydrate", so that rerenders are imperceptible to the user assuming nothing has changed. We'd also love to automatically serialize the backing models of the app so you don't have to double fetch.
- Scarbutt 11y ago
  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.
  - hatsix 11y ago
    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 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.
- jakubp 11y ago
  Thank you for a thorough answer.
- mtberatwork 11y ago
  > When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser. Aren't we now just back to square one again in terms of MVC frameworks? What are the advantages here over simply implementing Django, RoR, Spring, Laravel, etc and cutting back on the JS (at least in terms of content-driven sites)?
  - orf 11y ago
    > What are the advantages here over simply implementing... You get all of the advantages of single page apps, without the unresponsive initial load time. There are also whole classes of apps you can't build with Django, RoR etc, so the question is a bit ridiculous IMO.
    - takno 11y ago

bl4ckm0r3 11y ago

is the ember inspector working 100% with fastboot? (having some error while inspecting the index controller). Btw great job!

tomdale 11y ago
The Inspector works by injecting some debug code into the running app, so it won't work with FastBoot because the JavaScript is running on the server. That said, it should work just fine once the Ember app finishes loading and running in the browser. I would love it if you could file an issue on the Ember Inspector GitHub page with the error you're getting.
- bl4ckm0r3 11y ago
  At the ember conf now...will do some testing and eventually file a bug!

clessg 11y ago

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?

sandstrom 11y ago
There were some regressions, but it's back on par since the last few releases (2.3+ or so). In addition, Glimmer 2 is near completion, and when ready will provide further speed ups to initial rendering.
gavinjoyce 11y ago
We're running Ember 2.2 on Intercom and we've found it to be faster than 1.x. In addition to this, it looks like Glimmer 2 will bring significant render time improvement for both initial render and subsequent DOM updates.

tucosan 11y ago

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

mschoening 11y ago
A slightly modified version of Tablet Gothic (https://typekit.com/fonts/tablet-gothic https://typekit.com/fonts/tablet-gothic).

girvo 11y ago

Having implemented a similar concept using React (and Flummox), I'm curious how FastBoot solves the async data fetching problem; does it require the developer to be careful about how things are set up, or does a solution naturally fall out of how Ember works? Running what amounts to an event-loop once to get the HTML result wasn't that difficult, but ensuring that the app wasn't relying on said event-loop to render parts we needed out as HTML on the server was slightly annoying (but not insurmountable).

zilean 11y ago
Ember has default model() hook for routes, and propose to add extra data fetching you need in children components into afterModel hook. Everything is working just like you would set it up with React, except that with Ember declaring data dependencies on route is existing convention. And React gives you maybe a little bit more control around that.
- girvo 11y ago
  > declaring data dependencies on route is existing convention That makes sense, I believe that's exactly what react-async does (if I recall correctly?) with react-router. For our project, we basically call "await ApiActions.getData(routeParams)" in the server's route, after pulling that params out, which is effectively the same idea, and it worked quite well. I'm curious how one would tackle that from a different perspective, but it seems we all end up coming to the same conclusion!

qaq 11y ago

Congrats on great feature. Do you guys have any solid plans on when rehydration might become available?

staticelf 11y ago

I use Ember everyday. But still I don't understand the most basic questions: What is this? And why should I use it? I slummed through the quick start but that didn't make me any wiser. EDIT: I read up on your blog post and you guys should definitely put some of that into the web page.