Congrats to the team!
Downvoted for positivity, damn HN. That's harsh.
From the hn guidelines: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading."
How we switched our template rendering engine to React
11–20 of 42 posts
Re: How we switched our template rendering engine to React
#12Congrats to the team!
Downvoted for positivity, damn HN. That's harsh.
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.
Re: How we switched our template rendering engine to React
#13Would 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?
> 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?
Server rendering has advantages when first loading the SPA from the server: better user experience - faster loading because you don't need to wait for AJAX calls to do their round trips between browser and server to get data to populate the page - and better SEO - you don't need to rely on the search engine to correctly render the whole page.
With state changes after the initial load, though, client rendering is much better for UX (responsiveness). The whole point of "universal javascript" is that you can get both (initial server rendering and subsequent client rendering) with the same code base.
Re: How we switched our template rendering engine to React
#14Earlier quoted context omitted.
Downvoted for positivity, damn HN. That's harsh.
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…
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'
Re: How we switched our template rendering engine to React
#15Would 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?
javascript taken into consideration by crawlers is still likely to be less efficient and sure than just giving the crawlers html they can understand, thus with universal javascript the same code on client and server can render both places and give crawlers a server rendering of what a non-crawler will see with client rendering (it's what I do, I find the benefit minimal but there is a benefit)
Re: How we switched our template rendering engine to React
#16Earlier quoted context omitted.
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.
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.
>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.
Re: How we switched our template rendering engine to React
#17Earlier quoted context omitted.
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…
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'
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.
Re: How we switched our template rendering engine to React
#18Would 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?
> 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? Server rendering has advantages when first loading the SPA from the server: better user experience - faster loading because you don't need to wait for AJAX calls to do their round trips between browser and server to get data to populate the…
Can't one populate the initial state from the server to skip the extra round trip of the ajax call? Eg. dump a json somewhere on the page and have react load it from there, like a global JS variable.
Re: How we switched our template rendering engine to React
#19Earlier quoted context omitted.
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.
>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.
Not OP but think about the window object in the browser. In a client-side only JS application, you can assume that window will always exist. In a server-side PHP application, you never have to worry about interacting with window. In a SSR React application, you have to manage that complexity of window existing sometimes and it not existing other times if you want to share components between the client and the server.
Re: How we switched our template rendering engine to React
#20Would 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?
Crawlers/indexers take JS into account to varying degrees. In my experience they will execute client side code, but AJAX calls are ignored. So at the very least you want to send down data for the initial load.
I've definitely seen Googlebot hitting the API endpoints of a site via AJAX calls. I can't say definitively how they treat that data, but they definitely call it.