Hacker News Reader

Comment by wanderr | Hacker News Reader

I think SPAs make sense for a very limited set of applications. I worked on Grooveshark, which was an SPA by necessity - you don't want page refreshes breaking music playback. We had to do an insane amount of work to get initial load times down, and it was never as fast as we wanted it to be. Some things about an SPA were nice, your server side code can be very fast and very simple and scalable when you can rely on the client side to maintain state for example, but with that comes a lot of fragility and ultimately, a lot more work.

Working on a SPA can be lots of fun, so I'd consider it for a hobby project, but I wouldn't go the SPA route for a production app unless there were some very compelling reasons to do so.

View on HN

I think Grooveshark helped me create more code than coffee did for the few years it was active.

Just wanted to take a moment to thank you, and all the others who worked on it for making that possible. I know I wasn't alone to feel very, very lost and sad when it closed up.

So, free beer in case we ever meet IRL.

Your bad experiences are not because SPA is a bad idea, but because you did it wrong. Once an app is loaded there's simply no reason to every throw it out and start over. Do native apps have to throw any data away every time they open a dialog, or change an aspect of the gui? No, because that is silly and stupid. The only reason page refreshes even exist is because the original design of the internet was for viewing documents. However that's not was the web is used for any longer, for the most part. The web is not simply for viewing documents. It's at least as much for running apps now. A good webapp loads ONCE and then simply makes ajax calls to get JSON from the server when it needs to re-render part of the screen or even most of the screen, but if you are still doing entire page refreshes in 2017, then i'm just sorry but you are clueless. That's just not the way to do it. Web development is complicated, and I admit just reloading the entire page every time something happens is easier, but that doesn't make it better. Like the old expression "anything worth doing is worth doing right". It applies here.

What is your favorite SPA? HN's experience on a mobile phone, loading pages when clicking links, is far superior to any SPA I know of. Compare HN to glitchy sites like Twitter or Reddit, where swipe from left back doesn't work without flashing.

If you are simply rendering content and don't require high degrees of in-page interactivity, your traditional web page centric app will be much better user experience.

SPA's for content dominant sites are often a crutch to work around slow backend. A full page refresh (with optional pre fetching of next click HTML) is vastly superior to SPA's and spinners while loading. Browsers are good at loading web pages.

Once your browser has loaded the page, it's always (and I mean 100% of the time) more efficient to get whatever data you need from your server in the form of JSON, and then use that json to update ONLY the part of the page that is changing. Even if your entire DOM tree is changing that's STILL no excuse to do a page reload. The only page reload that ever needs to happen is when the user first browses to your url.

Why do you think executing JavaScript to render a piece of content fetched from the server as JSON is always more efficient?

Browsers are really efficient rendering HTML, so it all depends on how complex your JSON to DOM element transformation is. With async parsing / loading of JavaScript, your new page can be rendered before the JS is even loaded, so the extra initializaion per page view is hidden from the user.

Which site feels better, yours or Wikipedia?

My site is not finished, so you can't judge it by the experience. However, it is most definitely vastly superior to Wikipedia. meta64 is hierarchical like a directory tree, and can go to any depth. I haven't written the whitepaper yet, but my design makes wikipedia look like the ancient artifact it truly is compared to meta64.

All my API is fully JSON up and JSON down(REST-like), and is like a microservice api. The server is a service with an API. The javascript client is in control of rendering the data it gets from the server. I'm convinced that's the most efficient design.

Yoiks. 12 seconds until the first piece of content is displayed (compared to Wikipedia's 0.6s). That there (TTFC - Time to first content) is the perennial problem of client-side apps, the inability to get the first piece of content immediately to the user.

Since you say it's all JSON APIs, it should be trivial to build something on the server to server-render the initial page with content and serve that up while the rest of the application tries to download itself into the browser.

if I had minification on, your comparison would be apples-to-apples. I have it off for now, for debugging. Also my APP installs itself the first time you visit the page. Think of it as an APP INSTALL. Wikipedia is NOT an app, and has nothing to install.

Thinking of it as an app install feels like an anti-pattern. Like when you turn on the Xbox for a quick five minute play, and have to sit through a 15 minute update before you can even do anything. It's a bad user experience.

This approach was a commercial failure on the native platform level (those Office-like app suites with network install of components each time you needed them). It was also a commercial failure on the "build my desktop from scratch when I boot up" environments.

It yet another tick in the "does not belong in a browser" list.

Perhaps Single Page Applications need to run inside a window where there's no browser navigation bar, no url bar. Stripped down so far it's not actually a functioning browser. That feels very much like a native GUI library at that point. Except for that ludicrous notion of the app needing to be installed each time the chrome/window is launched.

I can't see how "install the app each time you land on this website" is competitive against native's "install this app once, and run many times" approach.

A well-designed web app will have a version number embedded in the filename(s) of the large file(s), (like the filename of a minified JavaScript file containing the entire app) so that upon first visit to the page the app is downloaded and "installed" (cached), but on subsequent visits your browser grabs the file from its local cache. This is really a seamless and excellent form of deployment, and when done correctly the browser only waits for new downloads when a new "version" of the app has been deployed to the server. So well written SPAs like meta64 do have the "install this app once, and run many times" behavior.

What are you talking about? Where does he say he throws anything out? The guy built Grooveshark, one of best SPAs ever so I'm pretty sure he knows what he's doing.

A page refresh is what I call "throwing things out". Once you load your page, you don't need to load it again. Just make ajax calls to server from then on, and use the JSON response from the server to update the DOM. A page-refresh blows away the entire DOM, and is just a bad design IMO.

He said that he built a single-page app to avoid page refreshes; where did you see in his comment (or when using Grooveshark? somewhere else?) that he refreshed the page or otherwise threw things out?

I think we agree and are misunderstanding each other. Yes if you have an SPA there is no refresh, no throwing things out, and it's good.

I think you need to read the post you replied to again. There are no page reloads going on in Grooveshark. It's a proper SPA.

Was*, GrooveShark shut down in 2015.

You are correct. My post was not about grooveshark or in any way related to grooveshark.

"A page-refresh blows away the entire DOM, and is just a bad design IMO."

Why? Really seriously question. Assuming everything is cached and it is not some super large app what's the problem with that?

meta64 is more of an APP than a webpage. For example, opening and closing dialogs is done by creating and destroying a DIV. It's not done by reloading the page, and rendering a new template on the server to send down. The reason I don't want to destroy the state of the DOM and client side variables is this: Have you ever seen a desktop app that resets all its variables back to null when a user clicks a button? Have you ever seen a desktop app that calls its 'main()' routine over and over again? Ask yourself why. There's just no reason to reload everything. Just start the app, and let it run. DOM is perfectly capable of updating the screen/page without a URL request being sent. Sending a url request to update something is stone-age thinking and 1990s design. It's the exact reason the world is moving to SPAs

Reply on news.ycombinator.com