9 ms·

Ember Fastboot

233 points by brett-anderson 11y ago

deleted 11y ago
[deleted]
lotyrin 11y ago
This is great! Anyone know how far analogous initiatives are for competing projects?
- sdornan 11y ago
  I believe this is the Angular 2 equivalent: https://github.com/angular/universal https://github.com/angular/universal
- __derek__ 11y ago
  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 https://github.com/mhart/react-server-example [2]: https://angular.io https://angular.io
  - tomdale 11y ago
    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 multiple instances concurrently, cheaply. Angular 2 is much more similar to what we're doing with FastBoot, and I'm excited to see where they go with that and crosspollinate ideas. (The work they're doing with Web Worker rendering is also very exciting.) 1: https://vimeo.com/157688134 https://vimeo.com/157688134
    - egeozcan 11y ago
      > 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.
      - ashleyw 11y ago
        @tomdale explains how fastboot runs concurrent instances here: http://youtu.be/xFTDNGZExuU?t=1h21m40s http://youtu.be/xFTDNGZExuU?t=1h21m40s
      - mwpmaybe 11y ago
        ...and "conventionalizing app boot" just means making it a few simple commands to implement for any given Ember.js application (instead of each application needing its own bespoke solution).
    - TN1ck 11y ago
      What about a more ambitious example like this: https://github.com/erikras/react-redux-universal-hot-example https://github.com/erikras/react-redux-universal-hot-example
      - hatsix 11y ago
        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?
    - morgante 11y ago
      Honestly, it comes off pretty poorly for you to downplay the work of your competitors. It might be easier to get server-side rendering working with React, but pretending that it's not the same thing is just condescending. There are dozens of examples out there showing how to render React pages on the server, including fetching the necessary data for that rendering. The mechanisms you use might be different, but pretending they're not analogous is duplicitous at best. Both let you ship a fully rendered first view to the client.
- leeoniya 11y ago
  supported in the tiny/fast domvm [1] out of the box. [1] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm
  - nilliams 11y ago
    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).
    - leeoniya 11y ago
      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.
      - nilliams 11y ago
        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.
        leeoniya 11y ago
        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.
- MatthewPhillips 11y ago
  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 https://www.youtube.com/watch?v=wRYdrfrL6ZQ [1]https://donejs.com/ https://donejs.com/ [2]https://github.com/canjs/can-zone https://github.com/canjs/can-zone [3]https://github.com/canjs/can-zone-jquery-example https://github.com/canjs/can-zone-jquery-example
  - hatsix 11y ago
    > What makes our solution unique is that you have to think about the server very little, if at all. What is an example of something a dev might have to think about with fastboot that they don't have to think about with DoneJS?
- arohner 11y ago
  For Clojure Om, there's https://github.com/arohner/foam https://github.com/arohner/foam Having access to .cljc (clojure files that can be loaded by either CLJS or standard CLJ) helps tremendously here. This means the server-side happens in Clojure on the JVM, so all of the async worries just go away entirely.
- dsp1234 11y ago
  markojs[0] also has async server side and client side rendering with placeholders, etc. [0] - http://markojs.com/ http://markojs.com/
- alanning 11y ago
  FastRender [1] for Meteor is a similar but not analogous project. Similar in that it improves initial render speed. Different in that it does so by delivering the data required to render the page along with the initial payload so things are still client-side rendered, not rendered for you on the server. For what its worth, FastRender was first released in 2013. The just-released Meteor 1.3 now has ES2016 module support which should enable more improvements in this area. 1. https://meteorhacks.com/fast-render-internals-and-how-it-works.html https://meteorhacks.com/fast-render-internals-and-how-it-wor...
- deleted 11y ago
  [deleted]
Corrspt 11y ago
Looking forward to see this project grow. Haven't had the time to check it out, but as I've been using Ember for the past months, it looks very interesting.
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.
diegorbaquero 11y ago
Amazing work. Just read all of this: http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/ 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!
- sotojuan 11y ago
  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 http://www.ember-fastboot.com/quickstart
  - hatsix 11y ago
    Good news is that on a medium-sized project (10s of routes and models), it still just takes two commands... haven't gone through setting up production yet, but I don't foresee any big issues.
    - reitoei 11y ago
      > haven't gone through setting up production yet, but I don't foresee any big issues Famous last words :)
sotojuan 11y ago
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.
k__ 11y ago
Is this available with Ember-CLI only?
- tomdale 11y ago
  Yes, it relies heavily on Ember CLI.
  - k__ 11y ago
    Sad to hear. I switched to React last year because I had the fear this would happen.
    - quaunaut 11y ago
      May I ask what your reticence is to Ember-CLI?
      - k__ 11y ago
        I dislike code generators and want to use my own tooling for building, testing, etc. In my eyes Ember has become an old-school Rails like Blob and newer frameworks are more about modules and "Bring Your Own Tools". I mean who, besides Ember, uses Broccoli?!
        quaunaut 11y ago
        But what exactly is the point of a framework if you're bringing your own tools?
        k__ 11y ago
        To me it always feels like they devs admit they failed the day they start to include code generators into their frameworks.
        quaunaut 11y ago
deleted 11y ago
[deleted]
look_lookatme 11y ago
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.
- elliotec 11y ago
  I love Ember. It seems to be one of the only sources of sanity and reason in this community.
  - girvo 11y ago
    > 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.
    - elliotec 11y ago
      I'm not being hyperbolic, and I think the React ecosystem deserves a large part of the blame for this mess. I am totally aware that is an unpopular opinion. The fact that Ember can distill the insanity of the community into an opinionated and usable framework (and also take wonderful ideas from things like Rails) is exactly what I mean by a source of reason.
- hardwaresofton 11y ago
  While I love Ember, one of it's biggest downfalls is definitely has a longer ramp up period, and more complexity than other frameworks. Ember's documentation is very good now, but still, there is a lot you have to read (and eventually experience to truly understand) about how ember works under the covers. One of ember's greatest benefits is that it adapts to change and doesn't miss out on features for very long at all (you can look at fastboot as a reaction to isomorphic react apps, or something that the ember team would have just pursued anyway). However, that benefit can also be a pitfall for newcomers to ember as it's hard to find consistent discussion, help, and resources for a framework that changes so fast. BTW, while Ember CLI makes things much easier, it does not improve the complexity situation, it just becomes one more thing you have to learn when learning Ember (even as a newbie). What if a newbie isn't familiar with node? what if they're not sure why you're precompiling? what if they're not familiar with task runners like grunt and gulp? Contrasted with frameworks like Angular 1, Backbone+Marionette, Ember definitely has the most rampup and complexity, not the least.
taveras 11y ago
I saw Tom give a great presentation on FastBoot back in January. for those interested, here is the checklist for getting to 1.0: https://github.com/tildeio/ember-cli-fastboot/issues/98 https://github.com/tildeio/ember-cli-fastboot/issues/98
cubano 11y ago
Trying to run the demo in win10.... Build error The Broccoli Plugin: [object Object] failed with: RangeError: Maximum call stack size exceeded at new Error (native) at Error (native) at Object.fs.mkdirSync (fs.js:794:18) at sync (C:\Users\marke\ember\github-fastboot- example\node_modules\ember- network\node_modules\broccoli- templater\node_modules\broccoli-stew\node_modules\broccoli- funnel\node_modules\mkdirp\index.js:71:13) at sync (C:\Users\marke\ember\github-fastboot- example\node_modules\ember- network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:77:24) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) The broccoli plugin was instantiated at: undefined Any ideas?
- mixonic 11y ago
  Opening an issue on https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot is probably the best way to get help tracking down a bug.
  - cubano 11y ago
    Yes of course. Thanks. Looking around on the site I didn't see a link to report something like this, and I didn't immediately think to goto github with it. Please excuse my ignorance.
tcfunk 11y ago
Funny that this came up on the same day as the blog post / rant about progressive enhancement :)
qaq 11y ago
Was just about to start a new app in Angular 2 because it seamed progress on fastboot was slow now might need to re-evaluate.

Ember Fastboot

233 points by brett-anderson 11y ago

deleted 11y ago

[deleted]

lotyrin 11y ago

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

sdornan 11y ago
I believe this is the Angular 2 equivalent: https://github.com/angular/universal https://github.com/angular/universal
__derek__ 11y ago
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 https://github.com/mhart/react-server-example [2]: https://angular.io https://angular.io
- tomdale 11y ago
  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 multiple instances concurrently, cheaply. Angular 2 is much more similar to what we're doing with FastBoot, and I'm excited to see where they go with that and crosspollinate ideas. (The work they're doing with Web Worker rendering is also very exciting.) 1: https://vimeo.com/157688134 https://vimeo.com/157688134
  - egeozcan 11y ago
    > 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.
    - ashleyw 11y ago
      @tomdale explains how fastboot runs concurrent instances here: http://youtu.be/xFTDNGZExuU?t=1h21m40s http://youtu.be/xFTDNGZExuU?t=1h21m40s
    - mwpmaybe 11y ago
      ...and "conventionalizing app boot" just means making it a few simple commands to implement for any given Ember.js application (instead of each application needing its own bespoke solution).
  - TN1ck 11y ago
    What about a more ambitious example like this: https://github.com/erikras/react-redux-universal-hot-example https://github.com/erikras/react-redux-universal-hot-example
    - hatsix 11y ago
      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?
  - morgante 11y ago
    Honestly, it comes off pretty poorly for you to downplay the work of your competitors. It might be easier to get server-side rendering working with React, but pretending that it's not the same thing is just condescending. There are dozens of examples out there showing how to render React pages on the server, including fetching the necessary data for that rendering. The mechanisms you use might be different, but pretending they're not analogous is duplicitous at best. Both let you ship a fully rendered first view to the client.
leeoniya 11y ago
supported in the tiny/fast domvm [1] out of the box. [1] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm
- nilliams 11y ago
  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).
  - leeoniya 11y ago
    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.
    - nilliams 11y ago
      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.
      - leeoniya 11y ago
        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.
MatthewPhillips 11y ago
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 https://www.youtube.com/watch?v=wRYdrfrL6ZQ [1]https://donejs.com/ https://donejs.com/ [2]https://github.com/canjs/can-zone https://github.com/canjs/can-zone [3]https://github.com/canjs/can-zone-jquery-example https://github.com/canjs/can-zone-jquery-example
- hatsix 11y ago
  > What makes our solution unique is that you have to think about the server very little, if at all. What is an example of something a dev might have to think about with fastboot that they don't have to think about with DoneJS?
arohner 11y ago
For Clojure Om, there's https://github.com/arohner/foam https://github.com/arohner/foam Having access to .cljc (clojure files that can be loaded by either CLJS or standard CLJ) helps tremendously here. This means the server-side happens in Clojure on the JVM, so all of the async worries just go away entirely.
dsp1234 11y ago
markojs[0] also has async server side and client side rendering with placeholders, etc. [0] - http://markojs.com/ http://markojs.com/
alanning 11y ago
FastRender [1] for Meteor is a similar but not analogous project. Similar in that it improves initial render speed. Different in that it does so by delivering the data required to render the page along with the initial payload so things are still client-side rendered, not rendered for you on the server. For what its worth, FastRender was first released in 2013. The just-released Meteor 1.3 now has ES2016 module support which should enable more improvements in this area. 1. https://meteorhacks.com/fast-render-internals-and-how-it-works.html https://meteorhacks.com/fast-render-internals-and-how-it-wor...
deleted 11y ago
[deleted]

Corrspt 11y ago

Looking forward to see this project grow. Haven't had the time to check it out, but as I've been using Ember for the past months, it looks very interesting.

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.

diegorbaquero 11y ago

Amazing work. Just read all of this: http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/ 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!

sotojuan 11y ago
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 http://www.ember-fastboot.com/quickstart
- hatsix 11y ago
  Good news is that on a medium-sized project (10s of routes and models), it still just takes two commands... haven't gone through setting up production yet, but I don't foresee any big issues.
  - reitoei 11y ago
    > haven't gone through setting up production yet, but I don't foresee any big issues Famous last words :)

sotojuan 11y ago

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.

k__ 11y ago

Is this available with Ember-CLI only?

tomdale 11y ago
Yes, it relies heavily on Ember CLI.
- k__ 11y ago
  Sad to hear. I switched to React last year because I had the fear this would happen.
  - quaunaut 11y ago
    May I ask what your reticence is to Ember-CLI?
    - k__ 11y ago
      I dislike code generators and want to use my own tooling for building, testing, etc. In my eyes Ember has become an old-school Rails like Blob and newer frameworks are more about modules and "Bring Your Own Tools". I mean who, besides Ember, uses Broccoli?!
      - quaunaut 11y ago
        But what exactly is the point of a framework if you're bringing your own tools?
        k__ 11y ago
        To me it always feels like they devs admit they failed the day they start to include code generators into their frameworks.
        quaunaut 11y ago

deleted 11y ago

[deleted]

look_lookatme 11y ago

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.

elliotec 11y ago
I love Ember. It seems to be one of the only sources of sanity and reason in this community.
- girvo 11y ago
  > 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.
  - elliotec 11y ago
    I'm not being hyperbolic, and I think the React ecosystem deserves a large part of the blame for this mess. I am totally aware that is an unpopular opinion. The fact that Ember can distill the insanity of the community into an opinionated and usable framework (and also take wonderful ideas from things like Rails) is exactly what I mean by a source of reason.
hardwaresofton 11y ago
While I love Ember, one of it's biggest downfalls is definitely has a longer ramp up period, and more complexity than other frameworks. Ember's documentation is very good now, but still, there is a lot you have to read (and eventually experience to truly understand) about how ember works under the covers. One of ember's greatest benefits is that it adapts to change and doesn't miss out on features for very long at all (you can look at fastboot as a reaction to isomorphic react apps, or something that the ember team would have just pursued anyway). However, that benefit can also be a pitfall for newcomers to ember as it's hard to find consistent discussion, help, and resources for a framework that changes so fast. BTW, while Ember CLI makes things much easier, it does not improve the complexity situation, it just becomes one more thing you have to learn when learning Ember (even as a newbie). What if a newbie isn't familiar with node? what if they're not sure why you're precompiling? what if they're not familiar with task runners like grunt and gulp? Contrasted with frameworks like Angular 1, Backbone+Marionette, Ember definitely has the most rampup and complexity, not the least.

taveras 11y ago

I saw Tom give a great presentation on FastBoot back in January. for those interested, here is the checklist for getting to 1.0: https://github.com/tildeio/ember-cli-fastboot/issues/98 https://github.com/tildeio/ember-cli-fastboot/issues/98

cubano 11y ago

Trying to run the demo in win10.... Build error The Broccoli Plugin: [object Object] failed with: RangeError: Maximum call stack size exceeded at new Error (native) at Error (native) at Object.fs.mkdirSync (fs.js:794:18) at sync (C:\Users\marke\ember\github-fastboot- example\node_modules\ember- network\node_modules\broccoli- templater\node_modules\broccoli-stew\node_modules\broccoli- funnel\node_modules\mkdirp\index.js:71:13) at sync (C:\Users\marke\ember\github-fastboot- example\node_modules\ember- network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:77:24) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17) The broccoli plugin was instantiated at: undefined Any ideas?

mixonic 11y ago
Opening an issue on https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot is probably the best way to get help tracking down a bug.
- cubano 11y ago
  Yes of course. Thanks. Looking around on the site I didn't see a link to report something like this, and I didn't immediately think to goto github with it. Please excuse my ignorance.

tcfunk 11y ago

Funny that this came up on the same day as the blog post / rant about progressive enhancement :)

qaq 11y ago

Was just about to start a new app in Angular 2 because it seamed progress on fastboot was slow now might need to re-evaluate.