7 ms·

How we switched our template rendering engine to React

122 points by eldude 10y ago

abritinthebay 10y ago
Congrats to the team!
- abritinthebay 10y ago
  Downvoted for positivity, damn HN. That's harsh.
  - hd4 10y ago
    From the hn guidelines: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
    - abritinthebay 10y ago
      Well it was that or just assume that HN comments are only for bitching about minor discrepancies in the article, nerdy holy wars, or for general negativity. Of course that's the general impression outside HN so perhaps they're correct and I'm just fighting a lost cause.
  - MildlySerious 10y ago
    More likely downvoted for not contributing to the discussion. While I'm sure it's appreciated, imagine comments like this being on top of the comment thread. I don't think anyone reading HN goes to the comments to scroll through a dozen of "Well done!" and "Congratulations!" comments before seeing comments with substance. It's probably safe to say people on this site go to the comments for extra information, insight and different perspectives on the topic.
    - spraak 10y ago
      I wish there were a way to share the voice of appreciation e.g. like that. Sometimes I really appreciate what a comment or submission had but I'm not sure how to express it. While up voting does that, it is anonymous to the receiving user, though on the other hand, I guess it's what keeps HN from becoming only about the 'likes'
      - MildlySerious 10y ago
        I absolutely share the sentiment, but like you said, not having this feature is the sacrifice to make in return for a high(-ish) quality discussion board. The other end of this spectrum would be reddit, where you need [SERIOUS] tags and heavy moderation, and still get inside jokes, memes and circlejerking for the sake of karma/likes.
bwd1992 10y ago
Would have liked to have seen some figures or graphs visualising the React performance boost. Also I thought one of the advantages of using a js framework is that rendering can be done on the client? It sounds from this article that server rendering is more advantageous? Also SEO was mentioned, but I thought javascript was taken into consideration by web crawlers?
- codycraven 10y ago
  Real world experience with clientside rendering for SEO has tons of downsides. Inconsistency in indexing, delayed indexing (yes Google), some (many) bots not doing it... etc.
- untog 10y ago
  It isn't solely server side rendering - the power of React and Node is that you can render on both server and client side, and get the best of both worlds.
  - Bahamut 10y ago
    Creating a universal JS app on the web has some extra cons too - not only is the code run on the server, but also a not insignificant JS payload is downloaded & executed on the client, as well as increased app complexity in order to maintain client/server separation at extension points. One should be cognizant that one doesn't get benefits for free with the choice to go with universal JS.
    - abritinthebay 10y ago
      The data is transmitted yes. In practice, after gzip, this is negligible compared to say... any average image loaded on that page.
    - scottmf 10y ago
      >as well as increased app complexity in order to maintain client/server separation at extension points. Can you explain what you mean by this? And are you comparing client-only vs universal, or client-only vs server-only? Large JS can be solved with code-splitting. The necessary code is downloaded in chunks when needed.
xmatos 10y ago
Best web app I've developed was basically Django, with bare minimum JavaScript to handle some in-page effects. People been trying to shoehorn desktop concepts in the web since forever and it will never work. A desktop app is installable, a web site is not. It makes no sense to wait your js app to download for the sake of smooth page transitions. Take a look at reddit's new mobile site, written in react. It takes around 7 seconds to load, to display text and links. Compare that to HN's, which loads in 0.1 sec, for basically the same content. SPA's have their place, for things like games or the likes of google maps. But for the rest, please respect the web paradigm . Your site will be simpler to build, faster and most importantly, lighter. The web world has become mobile-first, not js-centric...
- deleted 10y ago
  [deleted]
- zachlatta 10y ago
  You're betting against history.
- hh2222 10y ago
  The web paradigm also supports accessibility for people with visual disabilites.
  - todd3834 10y ago
    single page apps are part of the web paradigm. They too benefit from this.
- lucaspiller 10y ago
  I honestly feel the same. I've been working as a web developer for 8 years now, so it's not like I've been locked in a basement for decades and don't like all this new fangled stuff because it's not what I'm used to. I just don't get what SPAs provide over server rendered pages with a sprinkling of JavaScript to make things more interactive. Ok maybe it makes sense if you are building a game. Or something that needs to run offline. Or Facebook. But most web sites aren't like that. The other day there was a Ask HN about what stack a CMS should be built in. Most people were recommending their favourite client-side JavaScript framework. I just don't get it...
nsomaru 10y ago
I saw a presentation about REST and it included the concept of 'on demand code'; why do we need to serve up all our react components in a js blob? Can't we serve up minified and compressed components preemptively on the wire to keep load times small? Would this offer a benefit or am I missing something?
christophilus 10y ago
This is totally anecdotal, but my wife and my mom both commented to me recently on how Pinterest's latest UI changes have really slowed the site down in their experience. I wonder if React is partially at fault there?
krob 10y ago
SPA is mostly useful for reducing the cost of large application deployments. It improves speed for loading the initial bootstraping of the application. That means index is delivered almost instantly, and depending on the async loading of the code, can be dramatically speed up. SPA will reduce the overall server-rending of content besides json results which will be compressed, and json is smaller than html markup. Also SPA provides for a more sophisticated user experience. But like all things, the original cars got people from a-z, but not in style or comfort. As technologies improve over time, so will the reasons for using SPA. Browsers eventually will allow offline browsing as a standard feature, and having the SPA JS installed & json written to localstore/indexedDB will make using that UI rather nice, instead of always getting a 404 response when you have no internet and such. SPA is about control, server-rendered requires connectivity and difficulty handling response when failure occurs. 1st Major SPA's were email clients, consider google's gmail or microsoft web outlook service for exchange servers. Huge benefit with SPA, because the UI is complex and should not be constantly refreshing, because it can cause contextual change on what is displayed and present in-app state from re-initialization.

122 points by eldude 10y ago

abritinthebay 10y ago

Congrats to the team!

abritinthebay 10y ago
Downvoted for positivity, damn HN. That's harsh.
- hd4 10y ago
  From the hn guidelines: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
  - abritinthebay 10y ago
    Well it was that or just assume that HN comments are only for bitching about minor discrepancies in the article, nerdy holy wars, or for general negativity. Of course that's the general impression outside HN so perhaps they're correct and I'm just fighting a lost cause.
- MildlySerious 10y ago
  More likely downvoted for not contributing to the discussion. While I'm sure it's appreciated, imagine comments like this being on top of the comment thread. I don't think anyone reading HN goes to the comments to scroll through a dozen of "Well done!" and "Congratulations!" comments before seeing comments with substance. It's probably safe to say people on this site go to the comments for extra information, insight and different perspectives on the topic.
  - spraak 10y ago
    I wish there were a way to share the voice of appreciation e.g. like that. Sometimes I really appreciate what a comment or submission had but I'm not sure how to express it. While up voting does that, it is anonymous to the receiving user, though on the other hand, I guess it's what keeps HN from becoming only about the 'likes'
    - MildlySerious 10y ago
      I absolutely share the sentiment, but like you said, not having this feature is the sacrifice to make in return for a high(-ish) quality discussion board. The other end of this spectrum would be reddit, where you need [SERIOUS] tags and heavy moderation, and still get inside jokes, memes and circlejerking for the sake of karma/likes.

bwd1992 10y ago

Would have liked to have seen some figures or graphs visualising the React performance boost. Also I thought one of the advantages of using a js framework is that rendering can be done on the client? It sounds from this article that server rendering is more advantageous? Also SEO was mentioned, but I thought javascript was taken into consideration by web crawlers?

codycraven 10y ago
Real world experience with clientside rendering for SEO has tons of downsides. Inconsistency in indexing, delayed indexing (yes Google), some (many) bots not doing it... etc.
untog 10y ago
It isn't solely server side rendering - the power of React and Node is that you can render on both server and client side, and get the best of both worlds.
- Bahamut 10y ago
  Creating a universal JS app on the web has some extra cons too - not only is the code run on the server, but also a not insignificant JS payload is downloaded & executed on the client, as well as increased app complexity in order to maintain client/server separation at extension points. One should be cognizant that one doesn't get benefits for free with the choice to go with universal JS.
  - abritinthebay 10y ago
    The data is transmitted yes. In practice, after gzip, this is negligible compared to say... any average image loaded on that page.
  - scottmf 10y ago
    >as well as increased app complexity in order to maintain client/server separation at extension points. Can you explain what you mean by this? And are you comparing client-only vs universal, or client-only vs server-only? Large JS can be solved with code-splitting. The necessary code is downloaded in chunks when needed.

xmatos 10y ago

Best web app I've developed was basically Django, with bare minimum JavaScript to handle some in-page effects. People been trying to shoehorn desktop concepts in the web since forever and it will never work. A desktop app is installable, a web site is not. It makes no sense to wait your js app to download for the sake of smooth page transitions. Take a look at reddit's new mobile site, written in react. It takes around 7 seconds to load, to display text and links. Compare that to HN's, which loads in 0.1 sec, for basically the same content. SPA's have their place, for things like games or the likes of google maps. But for the rest, please respect the web paradigm . Your site will be simpler to build, faster and most importantly, lighter. The web world has become mobile-first, not js-centric...

deleted 10y ago
[deleted]
zachlatta 10y ago
You're betting against history.
hh2222 10y ago
The web paradigm also supports accessibility for people with visual disabilites.
- todd3834 10y ago
  single page apps are part of the web paradigm. They too benefit from this.
lucaspiller 10y ago
I honestly feel the same. I've been working as a web developer for 8 years now, so it's not like I've been locked in a basement for decades and don't like all this new fangled stuff because it's not what I'm used to. I just don't get what SPAs provide over server rendered pages with a sprinkling of JavaScript to make things more interactive. Ok maybe it makes sense if you are building a game. Or something that needs to run offline. Or Facebook. But most web sites aren't like that. The other day there was a Ask HN about what stack a CMS should be built in. Most people were recommending their favourite client-side JavaScript framework. I just don't get it...

nsomaru 10y ago

I saw a presentation about REST and it included the concept of 'on demand code'; why do we need to serve up all our react components in a js blob? Can't we serve up minified and compressed components preemptively on the wire to keep load times small? Would this offer a benefit or am I missing something?

christophilus 10y ago

This is totally anecdotal, but my wife and my mom both commented to me recently on how Pinterest's latest UI changes have really slowed the site down in their experience. I wonder if React is partially at fault there?

krob 10y ago

SPA is mostly useful for reducing the cost of large application deployments. It improves speed for loading the initial bootstraping of the application. That means index is delivered almost instantly, and depending on the async loading of the code, can be dramatically speed up. SPA will reduce the overall server-rending of content besides json results which will be compressed, and json is smaller than html markup. Also SPA provides for a more sophisticated user experience. But like all things, the original cars got people from a-z, but not in style or comfort. As technologies improve over time, so will the reasons for using SPA. Browsers eventually will allow offline browsing as a standard feature, and having the SPA JS installed & json written to localstore/indexedDB will make using that UI rather nice, instead of always getting a 404 response when you have no internet and such. SPA is about control, server-rendered requires connectivity and difficulty handling response when failure occurs. 1st Major SPA's were email clients, consider google's gmail or microsoft web outlook service for exchange servers. Huge benefit with SPA, because the UI is complex and should not be constantly refreshing, because it can cause contextual change on what is displayed and present in-app state from re-initialization.