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?
How we switched our template rendering engine to React
31–40 of 42 posts
Re: How we switched our template rendering engine to React
#32Best 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 arou…
As someone who spent the whole week migrating a static site to React, I hear you. I don't care if it means I have to learn another language or framework, just stop making SPAs for no reason!
Re: How we switched our template rendering engine to React
#33Earlier quoted context omitted.
>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.
So then there's:
- code-splitting needed for larger codebases
- taking the window object into account
Other stuff I can think of:
- more limited options for routing/etc. because you want to avoid having to maintain two codebases. This means you might have to use Redux+redux-router+whatever instead of express/hapi/etc. because you can't (?) run those frameworks client-side.
- less freedom to modularize state in your app, because last I checked it was still rather messy to ensure that all the separate data-loading events are taken care of server-side before everything is sent to the client. If you're a fan of the Redux approach this shouldn't be a problem though.
- Possible 'issues' with using ESNext features server-side without going through Babel.
All in all I think it's worthwhile and, nowadays, pretty doable to create a 'universal app'. But it has its own complexities and at least last time I tried, I could find very few examples of how to best do this, and we're probably still far away from a 'canonical' solution.
Furthermore, in practice I've found that in many cases it's not really worth the extra effort. If your app is large/complex enough to have a noticeable load-time, it's probably fine for the user to load the entire app first (it might even still be cached), and it's often the case that SEO is not really important.
In my experience, the few cases where a big-ish app needed to load stuff quickly involved going straight to some subpage in the app. In that situation I often found it easier to either just render that bit server-side the old-fashioned way, with its own logic (in which case React is still a good option).
Re: How we switched our template rendering engine to React
#34Earlier quoted context omitted.
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.
I suspect that in most cases time spent loading the initial data is dwarfed by the initial app payload and turning the data into html. Server-side rendering solves this by sending you a full 'screenshot' of the initial app, even before the app is downloaded and 'fresh' data is requested. The clever thing React does in this use-case is that even though the initial load is 'finished' html, React won't have to re-render…
You can achieve that with almost any framework.
Re: How we switched our template rendering engine to React
#35Best 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 arou…
I don't agree with this logic one bit. What you seem to be experiencing is SPA's that can use improvement. There is no reason why a SPA is required to load the entire app at once. There are many ways to split out the code so that each page only loads the bare minimum of what it needs. It is totally possible to provide a better user experience on mobile devices when the app only has to download the JSON required to render the next page. There are many tricks that can be done to take advantage of this. The SPA can load the bare minimum to render the page requested and then start pre loading the rest of the app or leave it on demand.
While I agree that there are many situations where a straight port of a static site to a SPA doesn't give too much benefit, it sets them up to move to more advanced interactions moving forward.
The web, although maybe not originally intended, has become the most powerful software platform we have. Things are getting dramatically better and the rate of innovation isn't showing any signs of this slowing down. It is already amazing and it's going to get better.
Re: How we switched our template rendering engine to React
#36Best 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 arou…
[deleted]
Re: How we switched our template rendering engine to React
#37Best 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 arou…
The web paradigm also supports accessibility for people with visual disabilites.
single page apps are part of the web paradigm. They too benefit from this.
Re: How we switched our template rendering engine to React
#38Best 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 arou…
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…
A CMS seems to me like exactly type of thing where a SPA is a large UX improvement. It's an app you would frequently be spending a large amount of time in which easily offsets the few extra seconds of page load time.
Re: How we switched our template rendering engine to React
#39Earlier quoted context omitted.
I suspect that in most cases time spent loading the initial data is dwarfed by the initial app payload and turning the data into html. Server-side rendering solves this by sending you a full 'screenshot' of the initial app, even before the app is downloaded and 'fresh' data is requested. The clever thing React does in this use-case is that even though the initial load is 'finished' html, React won't have to re-render…
You can achieve that with almost any framework.
I never claimed otherwise, but yeah, it's not something unique to React.
Could you elaborate on how this works with other frameworks? Does it work out of the box in most cases, or require some plugin/module?
Re: How we switched our template rendering engine to React
#40Would 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?
>It sounds from this article that server rendering is more advantageous? Rendering on the server feels faster to the user. With client side rendering, you will often get a skeleton of the site that loads, and then the content that fills that skeleton 100ms or so apart from one another. This sounds like nothing, but it is perceptible to the user. There are absolutely ways around this, but even the Big Guys get it wron…
Initial page load feels faster when rendered on the server. The very moment you navigate to another part of the site, client-side rendering is a huge win for apparent load times. Not only can you give the user feedback that something's loading, but you only need to retrieve the delta from the server between the page you're on now and the one you're going to. Within a few clicks, the amortized cost of the SPA in terms of both latency and over-the-wire size is already lower.