5 ms·

I'm not anti-SPA (and in fact, I think of the tools out there react is a pretty good one if you're going to do SPA), but I do think it's the wrong tool for a lo

by Arcsech 10y ago

I'm not anti-SPA (and in fact, I think of the tools out there react is a pretty good one if you're going to do SPA), but I do think it's the wrong tool for a lot of jobs. If your site is mainly content-based, like a blog or a forum, why make it an SPA? I feel like React/Angular/Vue/etc apps are becoming "the way the web is done" when so many things would be simpler and more efficient as plain old web sites with server-rendered HTML. It's like everyone decided that because convertibles are cool, they should be used for everything, and are now spending a ton of effort hitching trailers to their convertibles when it would have been much simpler and more effective to just drive a boring minivan in the first place.

NoGravitas 10y ago
I very strongly agree with this. There are certainly web apps that can only reasonably be done mainly-client-side. I'd give Office 365 as a baseline example. But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible. Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well. [0]: http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1412524#.7dgoctho7 https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...
- chrisrhoden 10y ago
  The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache. Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster. I understand where you are coming from, but you picked a bad example.
  - TeMPOraL 10y ago
    > Javascript is used to (...) speed the experience of the page up That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?
    - cnp 10y ago
      Optimistic loading / prefetching / etc -- the list goes on if you take the time to think about it for more than a second.
    - callumlocke 10y ago
      Used correctly, it can hugely speed up the experience by preloading things. In an ideal case you could have a fast initial page load with static HTML. Then an async script tag quietly loads a script in the background while the user is reading (done properly, this can be imperceptible). Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load. That's not usually the reality but it's definitely possible.
      - debaserab2 10y ago
        How is that faster than loading a single HTML template with the "dom" already rendered correctly by the server?
        learc83 10y ago
        I think you missed this part >Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load. In the GP's example, the first page load is already rendered by the server. It's subsequent page loads that are rendered in JS.
        debaserab2 10y ago
        ..so you want to preload the content of every link on the page? Because if it's just to display comments or something, I stand by my original statement.
tannhaeuser 10y ago
I second this. If you spend a lot of time on HN and other tech-minded forums (fori?), I think you could get the impression that just because you setup a web site, you must use MVC or some other JavaScript-heavy SPA stack, because such projects are of course interesting and intellectually challenging, and get lots of airtime when established, basic Web techniques are boring. Of course MVC (React, Angular, ...) has its place for web apps and is great when it fits, but I think it's crazy and counter-productive to use complex and costly MVC frameworks for mere content-driven sites (like what most public websites are about).
- learc83 10y ago
  React isn't MVC, it's component based, and even then it's just a view library. Also when I think MVC I think of non SPA web stacks like Rails or Django.
  - tannhaeuser 10y ago
    Fair point. Seems like you're not alone in understanding the term "MVC" like this ([1]). [1]: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend...
muse900 10y ago
I agree with you mostly, but isn't fb a forum? It most certainly has more capabilities like playing games etc, but it still carries basic forum principles. So is facebook wrongly designed?
- holtalanm 10y ago
  look. a strawman. Don't kid yourself, Facebook is much much more than just a forum. It might have been little more than a forum initially, and the amount of javascript it originally had kind of upholds the OP's original statement. It was a pretty slim webapp originally.
- underwater 10y ago
  Facebook is not a single page app. Most functionality is still powered by Hack (PHP).
arenaninja 10y ago
SPA is certainly wrong for many things. Projects fail because people underestimate their implementation and something that could've been a web application without much state is a buggy mess that can't achieve liftoff. Even when your application is not an SPA, some areas could still be SPA: editors, etc.
threatofrain 10y ago
As a minor response, I actually think that the web app approach can be right for some blogs and "boring" content based websites -- if your goal is to lower user wait time or GUI latency, and if you're okay with making tradeoffs elsewhere (more data requested, heavier initial payload). Why? Because after the problem of initial load, I think that further web requests are among the most expensive things you can do in terms of user wait time or latency, and that if you only start moving at the very time of user request, then it's too late to prevent a moment user waiting.
Can_Not 10y ago
> a forum, why make it an SPA? A forum is actually a pretty solid choice for an SPA, specifically the isomorphic react kind next.js sponsors. If you disagree or don't need the benefits, most existing forum software is already not an SPA, so no big deal. But a forum as an SPA can enable some more high tech forum solutions that may blur the distinction between forum community and slack community. Once the groundwork is laid out, who knows what kind of alternative architectures or plugins we'll see for it. Also, when JS is disabled, the server will take you to the intended page and render it for you. Literally the best of both worlds.
- lenkite 10y ago
  Have a look at the D lang forums - which is written in D - statically rendered with very little JS and loads at _light speed_ to see why a forum shouldn't be a SPA. https://forum.dlang.org/ https://forum.dlang.org/
  - underwater 10y ago
    That's a big standard forum. Implementing it as an SPA would be silly. Parent comment's point was that you could create different experiences that bring it closer to Slack.
  - Can_Not 10y ago
    I've been a heavy forum connoisseur for a very long time, I'm talking about interactive and application-level possibilities, not "fast because fast backend language". That forum looks like any other forum.

by Arcsech 10y ago

NoGravitas 10y ago

I very strongly agree with this. There are certainly web apps that can only reasonably be done mainly-client-side. I'd give Office 365 as a baseline example. But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible. Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well. [0]: http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1412524#.7dgoctho7 https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...

chrisrhoden 10y ago
The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache. Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster. I understand where you are coming from, but you picked a bad example.
- TeMPOraL 10y ago
  > Javascript is used to (...) speed the experience of the page up That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?
  - cnp 10y ago
    Optimistic loading / prefetching / etc -- the list goes on if you take the time to think about it for more than a second.
  - callumlocke 10y ago
    Used correctly, it can hugely speed up the experience by preloading things. In an ideal case you could have a fast initial page load with static HTML. Then an async script tag quietly loads a script in the background while the user is reading (done properly, this can be imperceptible). Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load. That's not usually the reality but it's definitely possible.
    - debaserab2 10y ago
      How is that faster than loading a single HTML template with the "dom" already rendered correctly by the server?
      - learc83 10y ago
        I think you missed this part >Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load. In the GP's example, the first page load is already rendered by the server. It's subsequent page loads that are rendered in JS.
        debaserab2 10y ago
        ..so you want to preload the content of every link on the page? Because if it's just to display comments or something, I stand by my original statement.

tannhaeuser 10y ago

I second this. If you spend a lot of time on HN and other tech-minded forums (fori?), I think you could get the impression that just because you setup a web site, you must use MVC or some other JavaScript-heavy SPA stack, because such projects are of course interesting and intellectually challenging, and get lots of airtime when established, basic Web techniques are boring. Of course MVC (React, Angular, ...) has its place for web apps and is great when it fits, but I think it's crazy and counter-productive to use complex and costly MVC frameworks for mere content-driven sites (like what most public websites are about).

learc83 10y ago
React isn't MVC, it's component based, and even then it's just a view library. Also when I think MVC I think of non SPA web stacks like Rails or Django.
- tannhaeuser 10y ago
  Fair point. Seems like you're not alone in understanding the term "MVC" like this ([1]). [1]: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend...

muse900 10y ago

I agree with you mostly, but isn't fb a forum? It most certainly has more capabilities like playing games etc, but it still carries basic forum principles. So is facebook wrongly designed?

holtalanm 10y ago
look. a strawman. Don't kid yourself, Facebook is much much more than just a forum. It might have been little more than a forum initially, and the amount of javascript it originally had kind of upholds the OP's original statement. It was a pretty slim webapp originally.
underwater 10y ago
Facebook is not a single page app. Most functionality is still powered by Hack (PHP).

arenaninja 10y ago

SPA is certainly wrong for many things. Projects fail because people underestimate their implementation and something that could've been a web application without much state is a buggy mess that can't achieve liftoff. Even when your application is not an SPA, some areas could still be SPA: editors, etc.

threatofrain 10y ago

As a minor response, I actually think that the web app approach can be right for some blogs and "boring" content based websites -- if your goal is to lower user wait time or GUI latency, and if you're okay with making tradeoffs elsewhere (more data requested, heavier initial payload). Why? Because after the problem of initial load, I think that further web requests are among the most expensive things you can do in terms of user wait time or latency, and that if you only start moving at the very time of user request, then it's too late to prevent a moment user waiting.

Can_Not 10y ago

> a forum, why make it an SPA? A forum is actually a pretty solid choice for an SPA, specifically the isomorphic react kind next.js sponsors. If you disagree or don't need the benefits, most existing forum software is already not an SPA, so no big deal. But a forum as an SPA can enable some more high tech forum solutions that may blur the distinction between forum community and slack community. Once the groundwork is laid out, who knows what kind of alternative architectures or plugins we'll see for it. Also, when JS is disabled, the server will take you to the intended page and render it for you. Literally the best of both worlds.

lenkite 10y ago
Have a look at the D lang forums - which is written in D - statically rendered with very little JS and loads at _light speed_ to see why a forum shouldn't be a SPA. https://forum.dlang.org/ https://forum.dlang.org/
- underwater 10y ago
  That's a big standard forum. Implementing it as an SPA would be silly. Parent comment's point was that you could create different experiences that bring it closer to Slack.
- Can_Not 10y ago
  I've been a heavy forum connoisseur for a very long time, I'm talking about interactive and application-level possibilities, not "fast because fast backend language". That forum looks like any other forum.