3 ms·

There are definitely more server-side options than front-end options. The approach here isn't necessarily just about React - the point is using web sockets and

There are definitely more server-side options than front-end options. The approach here isn't necessarily just about React - the point is using web sockets and rendering HTML directly (sped up via DOM diffing) will replace heavy Javascript logic (whether React, Vue, etc) for most use cases.

throwaway189262 6y ago
I really doubt it. Loading HTML fragments was the norm with AJAX. Part of the DHTML days. It makes more sense to have UI logic in the client.
- bdcravens 6y ago
  If your logic is complex enough, sure. (I mispoke - it won't replace "heavy" logic, but most UI needs aren't heavy) But for many the logic really isn't that complex; they just want reactivity. There's a frustration with needing to roll out a complex build process, JWTs, state management, etc, just to speed things up a bit. This is an alternative to that, in a way that really doesn't differ much from React in terms of speed or reactivity. For those truly complex UI logic cases, React components are still a tool you can use. The approaches aren't mutually exclusive.
  - throwaway189262 6y ago
    I used to use MVC frameworks a lot. The problem I ran into was as soon as you have one thing on the page that can't survive the reload, you can never reload again. Cue 3k lines of JQuery and regret. I think of it this way, would you stream pre-rendered markup to a native iOS, Android, or Windows app? The thought of it is crazy, who would ever do that. I think most people agree that the web is getting closer to native all the time. I think we're reaching the pivot where you're better off using React and co for any kind of interactivity. Page reloads are already used in media to portray slow/old websites. I don't see that getting better
    - cutler 6y ago
      Agreed. The rise in mobile usage has made server-side rendering redundant. Single page web apps are really a by-product of this, not the main cause. If you're serving your content to iOS, Android and the browser rendering needs to be done on the client.

throwaway189262 6y ago

I really doubt it. Loading HTML fragments was the norm with AJAX. Part of the DHTML days. It makes more sense to have UI logic in the client.

bdcravens 6y ago
If your logic is complex enough, sure. (I mispoke - it won't replace "heavy" logic, but most UI needs aren't heavy) But for many the logic really isn't that complex; they just want reactivity. There's a frustration with needing to roll out a complex build process, JWTs, state management, etc, just to speed things up a bit. This is an alternative to that, in a way that really doesn't differ much from React in terms of speed or reactivity. For those truly complex UI logic cases, React components are still a tool you can use. The approaches aren't mutually exclusive.
- throwaway189262 6y ago
  I used to use MVC frameworks a lot. The problem I ran into was as soon as you have one thing on the page that can't survive the reload, you can never reload again. Cue 3k lines of JQuery and regret. I think of it this way, would you stream pre-rendered markup to a native iOS, Android, or Windows app? The thought of it is crazy, who would ever do that. I think most people agree that the web is getting closer to native all the time. I think we're reaching the pivot where you're better off using React and co for any kind of interactivity. Page reloads are already used in media to portray slow/old websites. I don't see that getting better
  - cutler 6y ago
    Agreed. The rise in mobile usage has made server-side rendering redundant. Single page web apps are really a by-product of this, not the main cause. If you're serving your content to iOS, Android and the browser rendering needs to be done on the client.