3 ms·

> So is your app mostly forms or displaying content? User preference panels? Mortgage applications? Implement it with server-side rendering with a sprinkling of

by d_watt 6y ago

> So is your app mostly forms or displaying content? User preference panels? Mortgage applications? Implement it with server-side rendering with a sprinkling of JS to implement widgets the web lacks. If only part of your app requires low-latency interactions, use client-side rendering only there. While I understand it's easy to make the argument that SSR is better, lighter, etc. It's easy to quickly violate the "Single Responsibility Principle" in that you now have two systems with little knowledge of each other both in control of rendering the UI. I lived the era of jQuery with apps just being a bunch of jQuery extensions + SSR. Eventually the app needs to make XHR (type ahead search, nested picklists, etc), and you end up in a situation where there was just one thing controlling presentation.

setr 6y ago
well no, you have a very strict layering of control server owns it at first, and generates the base system client-side js then owns it, and does whatever it wants there's no back and forth, or dual simultaneous control of the UI. There's only one owner at a time; just two different systems who ever own it (and single-responsibility-wise: separating static UI from dynamic UI)
- cactus2093 6y ago
  The concern is not about race conditions or shared memory where two things would be editing it at a time. Even though the server always renders it first then the frontend, you still need to share knowledge across both the backend and frontend about all the details of all the components to know how to change the values in jquery or whatever you want to do. Any time you change something on the backend, you have to make sure the jquery stuff is updated to still work, and potentially in many different places if you have different interactions that can update the same state. It makes for very tightly coupled and brittle code. It’s still a matter of preference, you might still prefer that over a full frontend react codebase. But having seen both nightmare jquery messes and react messes, they can both be painful to work with. I definitely don’t agree that things were much simpler in the old days.

by d_watt 6y ago

setr 6y ago

well no, you have a very strict layering of control server owns it at first, and generates the base system client-side js then owns it, and does whatever it wants there's no back and forth, or dual simultaneous control of the UI. There's only one owner at a time; just two different systems who ever own it (and single-responsibility-wise: separating static UI from dynamic UI)

cactus2093 6y ago
The concern is not about race conditions or shared memory where two things would be editing it at a time. Even though the server always renders it first then the frontend, you still need to share knowledge across both the backend and frontend about all the details of all the components to know how to change the values in jquery or whatever you want to do. Any time you change something on the backend, you have to make sure the jquery stuff is updated to still work, and potentially in many different places if you have different interactions that can update the same state. It makes for very tightly coupled and brittle code. It’s still a matter of preference, you might still prefer that over a full frontend react codebase. But having seen both nightmare jquery messes and react messes, they can both be painful to work with. I definitely don’t agree that things were much simpler in the old days.