Hacker News Reader

Comment by Arcsech | Hacker News Reader

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.

View on HN

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 [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...

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.

> 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)?

Optimistic loading / prefetching / etc -- the list goes on if you take the time to think about it for more than a second.

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.

How is that faster than loading a single HTML template with the "dom" already rendered correctly by the server?

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.

..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.

That's a big revision of your original comment ;)

Speeds up subsequent pages accessed at least.

The related articles and comments are not rendered until after the page is readable. If they had to be rendered on the server, it would cause the article to take longer to be readable.

There's a lot of different caching and persisting strategies you could put in place to load comments or related articles quickly that don't involve entire HTTP round trips. There's a definite trade-off there (and a not insignificant one, especially on mobile)

Not to mention, HTTP2 mitigates a lot of this, without the downside of huge upfront downloads.

Yes, sources are packed pretty well, but there's still a lot going on for a blog article:

* 10 XHR requests on page load

* 3 downloaded fonts

* Continuous XHR requests as you scroll through the article

* ~400ms time spent executing javascript (according to timeline benchmark)

I'm not really sure why all those things need to happen to load some text in a blog article.

Does it stop downloading after that initial 100K? If not, then I think the original claim is a reasonable description. Reading one sentence will cause one megabyte of data to be transferred.

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).

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.

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...

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.

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?

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.

Facebook is not a single page app. Most functionality is still powered by Hack (PHP).

> 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.

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/

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.

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.

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.

Reply on news.ycombinator.com