4 ms·

> Injecting HTML into the DOM is literally what React does... The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as

> Injecting HTML into the DOM is literally what React does... The key part of that phrase is "server-rendered", not AJAX. Which yes, is possible with React as well, but it's incredibly rare to see a React app that utilizes actual browser navigation for the majority of it's interactions (posting forms, sessions via cookies, little to no JSON interaction). There's certainly nothing stopping me from using React as a templating language, I don't but whatever, it's a fine choice. When I'm talking about "React apps", I guess I can be a bit more precise and say apps where control flow is dictated by the front end and the backend largely serves as an API (and maybe occasionally bootstraps a view). > If not a framework, how do you add interactivity to your pages? Vanilla JS? Mostly, yeah. We used a bit of Vue early on, but didn't see much benefit, there's still some code kicking around due to be transitioned. We'll use Stimulus when it makes sense, otherwise it's just vanilla JS and maybe helper libraries (checking our package.json, the only libraries we're using that aren't for CSS or third-party things like stripe are stimulus, codemirror, debounce, trix, and vue).

ZephyrBlu 6y ago
I don't really see a big difference between POSTing with a form vs a request or between sessions and tokens. Flow control is definitely different between React apps and standard server rendered websites, but you are still effectively implementing the same thing in both cases. I guess I'm not understanding how your team's productivity is "easily double" when to me, it sounds like you're describing run of the mill stuff that could easily be done in React or a backend framework.
- ryanbrunner 6y ago
  Oh, we're absolutely using a backend framework, I didn't mean to imply that we're building everything with raw CGI scripts or something like that. In terms of increased productivity, things I've noticed that have helped with productivity: - Using native browser functionality for navigation and form submission allows the browser itself to take on some of the work that would otherwise be filled in by custom code like maintaining browser history. - A standard SPA requires that you maintain an API for the front end to talk to, which a server rendered framework has no need for (we do have an API, but it's specifically for customer usage and doesn't need to cover all use cases we need for our application) - The backend is a 100% known environment, and while you always have to think about browser / device capability, this is greatly reduced when you have small amounts of Javascript, particularly when it's not essential for your page to function - there's also far lower demands on client machines since the bulk of the work is performed by the server. Changes can often be applied in a single "layer". If I need to add a new field to a view, I can just add it to a template, whereas in an SPA I'd need to modify my React components as well as my API, potentially needing to care about API versioning, etc. - More of a broader thing, but I find that environments that use front-end frameworks heavily tend to become more specialized quicker, and environments where you have specialization between front-end and back-end leads to increased needs for coordination for any non-trivial work, which ends up being a pretty big tax on velocity compared to having full-stack developers who can work on anything.

ZephyrBlu 6y ago

I don't really see a big difference between POSTing with a form vs a request or between sessions and tokens. Flow control is definitely different between React apps and standard server rendered websites, but you are still effectively implementing the same thing in both cases. I guess I'm not understanding how your team's productivity is "easily double" when to me, it sounds like you're describing run of the mill stuff that could easily be done in React or a backend framework.

ryanbrunner 6y ago
Oh, we're absolutely using a backend framework, I didn't mean to imply that we're building everything with raw CGI scripts or something like that. In terms of increased productivity, things I've noticed that have helped with productivity: - Using native browser functionality for navigation and form submission allows the browser itself to take on some of the work that would otherwise be filled in by custom code like maintaining browser history. - A standard SPA requires that you maintain an API for the front end to talk to, which a server rendered framework has no need for (we do have an API, but it's specifically for customer usage and doesn't need to cover all use cases we need for our application) - The backend is a 100% known environment, and while you always have to think about browser / device capability, this is greatly reduced when you have small amounts of Javascript, particularly when it's not essential for your page to function - there's also far lower demands on client machines since the bulk of the work is performed by the server. Changes can often be applied in a single "layer". If I need to add a new field to a view, I can just add it to a template, whereas in an SPA I'd need to modify my React components as well as my API, potentially needing to care about API versioning, etc. - More of a broader thing, but I find that environments that use front-end frameworks heavily tend to become more specialized quicker, and environments where you have specialization between front-end and back-end leads to increased needs for coordination for any non-trivial work, which ends up being a pretty big tax on velocity compared to having full-stack developers who can work on anything.