3 ms·

It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been eas

by baddox 6y ago

It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been easier to start a new Django or Rails app), but your clients will probably want features they’re accustomed to in modern web applications that are not easily implemented in server-rendered web sites.

grey-area 6y ago
What kind of features require you to use react?
- baddox 6y ago
  None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.
  - grey-area 6y ago
    I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense). Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse. Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.
    - baddox 6y ago
      I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former). Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.

by baddox 6y ago

grey-area 6y ago

What kind of features require you to use react?

baddox 6y ago
None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.
- grey-area 6y ago
  I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense). Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse. Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.
  - baddox 6y ago
    I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former). Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.