I saw Tom give a great presentation on FastBoot back in January. for those interested, here is the checklist for getting to 1.0:
Ember Fastboot
31–40 of 100 posts
Re: Ember Fastboot
#32Earlier 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…
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.
Re: Ember Fastboot
#33Earlier quoted context omitted.
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.
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.
Re: Ember Fastboot
#34Earlier quoted context omitted.
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…
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.
Re: Ember Fastboot
#35This 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…
> 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?
Re: Ember Fastboot
#36Earlier 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…
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 prete…
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 frequently and publicly.
I have tremendous respect for the Angular and React teams and consider many contributors to both to be personal friends. I'm not downplaying their work—it just really, really, really is not the same thing.
Re: Ember Fastboot
#37Earlier 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…
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 prete…
From one point of view (a user of the framework who doesn't care how the sausage gets made) they are analogous. But from the point of view of someone who developed the solution or who has to micro optimize the solution I believe tom dale is right that it is quite different.
You're right that tomdale came off condescending (as he often does when promoting/defending ember...ah well). But it certainly isn't "duplicitous at best"!
Re: Ember Fastboot
#38Earlier quoted context omitted.
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…
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…
Thank you for a thorough answer.
Re: Ember Fastboot
#39Earlier quoted context omitted.
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 prete…
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 `renderToString` and calling it a day.
Re: Ember Fastboot
#40Earlier quoted context omitted.
is the ember inspector working 100% with fastboot? (having some error while inspecting the index controller). Btw great job!
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.
At the ember conf now...will do some testing and eventually file a bug!