9 ms·

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

by lotyrin 11y ago

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.
    - tomdale 11y ago
      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.
      - exogen 11y ago
        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.
        hatsix 11y ago
        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.
  - mhart 11y ago
    Author of the simple React example here – Tom says there's a "huge gulf", but forgot to mention there's literally an example[1] of an asynchronous routing and data fetching app linked to in the first section of that page that's a logical progression of the first. (and others have pointed out much more complex examples you can achieve with React if you so wish) The goal of those small examples is to illustrate that you don't need complex frameworks to achieve server-side rendering with data fetching and routing. I have no doubt that FastBoot was a huge undertaking, and I think a large part of the reason for that is that it's aiming to fit into a very comprehensive existing framework, with pieces for routing, fetching data, "application instances", etc – there's a lot more work involved in that (for the framework author I mean, not the end user) than there is starting off with just a view library and adding your own pieces around that. 1: https://github.com/mhart/react-server-routing-example https://github.com/mhart/react-server-routing-example
  - zilean 11y ago
    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.
  - __derek__ 11y ago
    Touché. I reckon I should have read 'analogous' a bit more strictly.
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]

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

by 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.
  - tomdale 11y ago
    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.
    - exogen 11y ago
      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.
      - hatsix 11y ago
        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.
- mhart 11y ago
  Author of the simple React example here – Tom says there's a "huge gulf", but forgot to mention there's literally an example[1] of an asynchronous routing and data fetching app linked to in the first section of that page that's a logical progression of the first. (and others have pointed out much more complex examples you can achieve with React if you so wish) The goal of those small examples is to illustrate that you don't need complex frameworks to achieve server-side rendering with data fetching and routing. I have no doubt that FastBoot was a huge undertaking, and I think a large part of the reason for that is that it's aiming to fit into a very comprehensive existing framework, with pieces for routing, fetching data, "application instances", etc – there's a lot more work involved in that (for the framework author I mean, not the end user) than there is starting off with just a view library and adding your own pieces around that. 1: https://github.com/mhart/react-server-routing-example https://github.com/mhart/react-server-routing-example
- zilean 11y ago
  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.
- __derek__ 11y ago
  Touché. I reckon I should have read 'analogous' a bit more strictly.

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]