3 ms·

Use the right tool for the job. Why is this so controversial? Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and

Use the right tool for the job. Why is this so controversial? Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.

shockinglytrue 6y ago
What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page. There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time. Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space. I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same. "The page content is smaller as JSON" .. "you introduced a round-trip, game over" "We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded" "We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"
- cageface 6y ago
  This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component. My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.
Scarbutt 6y ago
You are too rational ;) Joking aside, was thinking exactly the same while reading the article. This has been talk about for years, and today there is lots docs and resources for devs to be able to make a thoughtful decision of going SPA vs no-SPA.
theonething 6y ago
It's controversial because it directly effects us. I wish I didn't have to develop in a JS framework but as a full stack developer almost every company I come across requires me to.
dbbk 6y ago
Honestly, I think it's controversial because a lot of frontend developers lack critical thinking. There isn't a nuanced technical assessment, they just go "Oh React is the industry standard let's use that", with no regard for whether or not it fits their use case. I also see this a lot within the React community with things like Hooks, you have Dan Abramov giving one presentation and a lot of the immediate reaction is "this is a panacea, the future of web development, it's perfect".

shockinglytrue 6y ago

What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page. There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time. Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space. I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same. "The page content is smaller as JSON" .. "you introduced a round-trip, game over" "We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded" "We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"

cageface 6y ago
This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component. My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.

Scarbutt 6y ago

You are too rational ;) Joking aside, was thinking exactly the same while reading the article. This has been talk about for years, and today there is lots docs and resources for devs to be able to make a thoughtful decision of going SPA vs no-SPA.

theonething 6y ago

It's controversial because it directly effects us. I wish I didn't have to develop in a JS framework but as a full stack developer almost every company I come across requires me to.

dbbk 6y ago

Honestly, I think it's controversial because a lot of frontend developers lack critical thinking. There isn't a nuanced technical assessment, they just go "Oh React is the industry standard let's use that", with no regard for whether or not it fits their use case. I also see this a lot within the React community with things like Hooks, you have Dan Abramov giving one presentation and a lot of the immediate reaction is "this is a panacea, the future of web development, it's perfect".