4 ms·

At this point, I think JavaScript programmers are just trolling. The argument that "because others are doing SPAs, we have to do too" is invalid, the "others"

At this point, I think JavaScript programmers are just trolling. The argument that "because others are doing SPAs, we have to do too" is invalid, the "others" are just either your friends or popular JavaScript programmers, and you follow them because you lack better arguments to go against this development technique. An SPA adds unexpected behavior to every web application, when we have spent years learning how a popular web browser behaves, people come to re-invent the wheel (back buttons, custom scroll bars, custom routers, and who knows what else). Normally, I encourage people to learn and work on whatever thing they are interested in, not just technology-wise. But when you start promoting your project trying to make people use it as if it was good, well, then you have to expect some rants here and there. I am sure there is a lot of people who would disagree with me, and people who have good arguments for the development of an SPA, I would love to hear those arguments, I am being serious.

ameliaquining 9y ago
The primary argument in favor of SPAs is that otherwise the entire page and every resource on it has to be reloaded every time the user navigates, and the resulting user experience is vastly inferior to that of an SPA (or native app), especially for users on low-end devices and/or high-latency connections.
- tscs37 9y ago
  Alternatively, just don't load as much crap. I've purposefully reduced my website to a minimal amount of HTML so that even on connections with high latency and low bandwidth, it loads quickly into the browser. A lot of webapps I've seen lately could have just as easily been a lightweight, single PHP script with minimal styling and scripting. That saves battery and bandwidth. SPAs only save bandwidth.
- thinkxl 9y ago
  I see this argument everywhere, but, when the application is done properly, the reloading doesn't feel that bad. Related past threads: - Ask HN: Are there any solid arguments against SPAs in 2017? https://news.ycombinator.com/item?id=13315444 https://news.ycombinator.com/item?id=13315444 - Do you really want a single-page application framework? https://news.ycombinator.com/item?id=12956059 https://news.ycombinator.com/item?id=12956059 - The Disadvantages of Single Page Applications (2014) https://news.ycombinator.com/item?id=9879685 https://news.ycombinator.com/item?id=9879685
- stephenr 9y ago
  > every resource on it has to be reloaded every time the user navigates Since when? Browser cache is a thing that exists. > especially for users on low-end devices and/or high-latency connections I use an original iPad Mini (so basically the guts of an iPad 2 with a smaller screen) for occasional browsing. It definitely works better on simple, JS free pages. I use said iPad Mini in Thailand. Regardless of our ISP provided line-speed, connections out of the country are always a throttling point for data. Having a regular browser-provided loading indicator (which can actually be intelligent and use things like the Content-Length header) is definitely preferable to some in-page JS (see above) spinner that gives zero indication of what % is loaded, or if it's hung, or whatever. I am convinced at this point that SPA's basically exist to be 'portfolio' sites for front-end developers, the way designers would (maybe still do) create their own take on a popular app/website/etc and publish it, to show off what they're capable of.
mi100hael 9y ago
For this particular use-case (and other relatively static content in general) I'd always go with static pages a la Jekyll. I was a SPA skeptic for a long time, but ultimately I've moved that direction, especially as frameworks continue to mature. For sites that aren't strictly static content, you're going to need to make some sort of AJAX call to update some component on the page. Using a framework like React that's purpose-built for that use-case is a lot cleaner and more maintainable than bolting together jQuery and DOM appends, especially as the number of calls & components continues to grow over time. Plus, these days the UX is pretty much identical as interacting with a static site. React Router has natively-functioning history & link-able URLS. You can render a React page server-side just like a traditional web framework, so the initial page load doesn't take forever (which makes the site feel faster than a traditional web app because subsequent page loads are AJAX and partial DOM modifications). You can use React Native to build your SPA as a mobile app with real, native components, not just a web wrapper. I can't believe I just defended React.

ameliaquining 9y ago

The primary argument in favor of SPAs is that otherwise the entire page and every resource on it has to be reloaded every time the user navigates, and the resulting user experience is vastly inferior to that of an SPA (or native app), especially for users on low-end devices and/or high-latency connections.

tscs37 9y ago
Alternatively, just don't load as much crap. I've purposefully reduced my website to a minimal amount of HTML so that even on connections with high latency and low bandwidth, it loads quickly into the browser. A lot of webapps I've seen lately could have just as easily been a lightweight, single PHP script with minimal styling and scripting. That saves battery and bandwidth. SPAs only save bandwidth.
thinkxl 9y ago
I see this argument everywhere, but, when the application is done properly, the reloading doesn't feel that bad. Related past threads: - Ask HN: Are there any solid arguments against SPAs in 2017? https://news.ycombinator.com/item?id=13315444 https://news.ycombinator.com/item?id=13315444 - Do you really want a single-page application framework? https://news.ycombinator.com/item?id=12956059 https://news.ycombinator.com/item?id=12956059 - The Disadvantages of Single Page Applications (2014) https://news.ycombinator.com/item?id=9879685 https://news.ycombinator.com/item?id=9879685
stephenr 9y ago
> every resource on it has to be reloaded every time the user navigates Since when? Browser cache is a thing that exists. > especially for users on low-end devices and/or high-latency connections I use an original iPad Mini (so basically the guts of an iPad 2 with a smaller screen) for occasional browsing. It definitely works better on simple, JS free pages. I use said iPad Mini in Thailand. Regardless of our ISP provided line-speed, connections out of the country are always a throttling point for data. Having a regular browser-provided loading indicator (which can actually be intelligent and use things like the Content-Length header) is definitely preferable to some in-page JS (see above) spinner that gives zero indication of what % is loaded, or if it's hung, or whatever. I am convinced at this point that SPA's basically exist to be 'portfolio' sites for front-end developers, the way designers would (maybe still do) create their own take on a popular app/website/etc and publish it, to show off what they're capable of.

mi100hael 9y ago

For this particular use-case (and other relatively static content in general) I'd always go with static pages a la Jekyll. I was a SPA skeptic for a long time, but ultimately I've moved that direction, especially as frameworks continue to mature. For sites that aren't strictly static content, you're going to need to make some sort of AJAX call to update some component on the page. Using a framework like React that's purpose-built for that use-case is a lot cleaner and more maintainable than bolting together jQuery and DOM appends, especially as the number of calls & components continues to grow over time. Plus, these days the UX is pretty much identical as interacting with a static site. React Router has natively-functioning history & link-able URLS. You can render a React page server-side just like a traditional web framework, so the initial page load doesn't take forever (which makes the site feel faster than a traditional web app because subsequent page loads are AJAX and partial DOM modifications). You can use React Native to build your SPA as a mobile app with real, native components, not just a web wrapper. I can't believe I just defended React.