4 ms·

This is a common response to complaints about front end complexity, but how true is it, or how true does it have to be? We're posting on a very successful websi

This is a common response to complaints about front end complexity, but how true is it, or how true does it have to be? We're posting on a very successful website that could have easily been built in the early 2000s in terms of technology, if not earlier. In my day job, I write server-generated HTML for a growing and successful startup, without React, front-end frameworks or a particularly complicated front-end build setup (we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense), and the user experience is comparable with many other web apps I use, some of which are almost certainly full-fledged SPAs, and is well-loved by our users. My team's productivity is easily double what I've experienced at jobs using the latest and greatest technologies. Could I use this approach to build Google docs? Probably not, but then again, that's not what I'm building, and I don't need a tool capable of building that.

j45 6y ago
There's no shortage of hn clients with increased interaction and none have seemed to be used more than the site itself. Too often interactivity can seem forced where the primary use is consumption of information, like hn. The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.
ZephyrBlu 6y ago
> we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense Injecting HTML into the DOM is literally what React does... You can even server render that HTML and then hydrate the DOM with interactivity after the fact. I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway. The main value of React is being able to easily manage client state and efficient updating of the DOM. If not a framework, how do you add interactivity to your pages? Vanilla JS?
- ryanbrunner 6y ago
  > 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.

j45 6y ago

There's no shortage of hn clients with increased interaction and none have seemed to be used more than the site itself. Too often interactivity can seem forced where the primary use is consumption of information, like hn. The lack of distractions in the ui allows folks to focus on the conversation to some extent in a way that might be different.

ZephyrBlu 6y ago

> we do use AJAX, but in the "deliver server-rendered HTML and inject into the DOM" sense Injecting HTML into the DOM is literally what React does... You can even server render that HTML and then hydrate the DOM with interactivity after the fact. I don't understand why people make the distinction between server rendered and client rendered HTML when React can do both anyway. The main value of React is being able to easily manage client state and efficient updating of the DOM. If not a framework, how do you add interactivity to your pages? Vanilla JS?

ryanbrunner 6y ago
> 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.