Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

401–410 of 522 posts

Re: You probably don't need a single-page app

#401
post #305

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…

> I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. But even Slack is subject to the same clunky and slow user experience you're describing because its entire user interface is an SPA. In my opinion, a site for the SPA hall of shame is the Starbucks.com progressive web app [1]. My grievances abo…

The Starbucks app in Edge is _miles_ faster than Amazon.com or eBay.com for me on my slow satellite connection. I think this is one often underlooked feature of SPAs. SSR stuff is a blank white screen about 50% of the time for people on slow connections, SPAs have a slower initial load and then from then on are either faster or _feel_ faster because they don't go completely blank for 5+ seconds every time you click something. Even a slowly-loading SPA feels better than any SSR site for that reason, IMO.

Re: You probably don't need a single-page app

#402
post #366

Earlier quoted context omitted.

You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

There was indeed a moment few years ago when front-end frameworks/libs were changing at warp speed, but last year or so I think the situation crystalized a lot. You now have React and Vue as major players and Angular competing for the 3rd place against some fresh libs... and I don't see that changing anytime soon.

Re: You probably don't need a single-page app

#403

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…

Thank you for pointing the real issue with SPAs: they deliver awful user experience. It's quite telling how this fact is missing from the article and from most of the discussion here. We're a bunch of self-referential techies who've lost connection with reality.

I couldn't disagree more. For anyone on a slower connection (I use a satellite connection that's 1 Mbps on a good day) a SPA is almost always a greatly superior user experience. A server-side rendered application is a blank white screen for roughly 50% of the time I'm using it. Even if a SPA takes longer to initially load, it's much nicer to keep the application actually onscreen while it's loading new content. Even if the SPA takes longer to load content it will often feel as if it's faster because you're looking at the application while it loads rather than staring at a blank screen for 5-10 seconds with every click. When people talk about SSR applications being a better user experience I always assume they're operating on first-world 10+ Mbps broadband connections or cellphones in developed cities, because the difference is night and day for those of us on slower.

I also disagree with the idea that SPAs are pushed by developers who have lost touch. Clients frequently push for them and ask questions like "Twitter/Instagram/YouTube don't show these blank white pages after every click, why does my site? Can't you make it like YouTube?" Clients want to have them more than developers want to make them.

Re: You probably don't need a single-page app

#404

Earlier quoted context omitted.

If Gmail is taking 10 seconds to load it might be worth your time to consider a faster computer for your own sake. It can be like 3-4 seconds on a faster computer.

Nah, just tested and mail.google.com took 23.3 seconds to load in Chrome and 30.2 seconds in Firefox. I have a 4-core 8-thread i7 and am on a 20Mbps internet line. It's the website, it isn't my computer.

Is that from scratch? I'm using an i3 on a 1 Mbps satellite connection, and opening up Gmail now (having opened it earlier today), it was 0.27s until DOMContentLoaded and I could interact with it. It continued asynchronously loading stuff in the background but from my POV it loaded in 1/3 of a second, which in Chrome is faster than the app opens on my iPhone 7. I have disabled the Hangouts/Chat feature in settings which apparently makes a big difference.

Re: You probably don't need a single-page app

#405
post #366

Earlier quoted context omitted.

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

There was indeed a moment few years ago when front-end frameworks/libs were changing at warp speed, but last year or so I think the situation crystalized a lot. You now have React and Vue as major players and Angular competing for the 3rd place against some fresh libs... and I don't see that changing anytime soon.

Every year this is said like burning man is dead.

I predict a bigger react ecosystem. The slide of vue but the raise of the Quasar framework for apps. The rise of Angular once again.

Re: You probably don't need a single-page app

#406
post #254

Earlier quoted context omitted.

It's difficult to tell the person who's writing your paycheck "this is totally possible I just don't like it and so won't do it." Like if you're doing SSR you could at least use something like turbooinks to implement state transitions.

How about “that’s totally possible. It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix. I personally would love to work on it, just keep in mind that any changes will require 10x the time and budget” And ... “Here are a couple of technologies which would allow us to speed up the experience at a very low cost. I recommend we try these first.” Turbolinks for the win :)

Sure, you can say that. You will lose your clients to the agency down the road who happily use React and say "no problem." Especially once it turns out that it _doesn't_ require 10x the time and budget and your prospective client tells everyone you bullshitted them.

Re: You probably don't need a single-page app

#407

This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…

Eh. The problems you talk about have little to do with SPAs in general, and have more to do with "rewriting things from A to B". If you had started out with SPAs first and wanted to un-SPA everything, you'd be making the same comments. The issues you mentioned aren't intrinsic to SPAs, they're intrinsic in redoing things.

Re: You probably don't need a single-page app

#408
Agree that SPAs are usually unnecessary. The big problems with JS SPA's is due to the limitations of javascript and the browser runtime. The one major innovation has been component-based view models while server-side frameworks have been stuck with older template-based approaches.

Component-based views are starting to get to server-side frameworks so that should reach parity within 2 years and WebAssembly will change the rest. Now apps can be built using many different languages with OOP/functional styles, strong typing, dependency injection, etc, and run at native speeds in the browser. With the next gen of WASM running threads, GC, and DOM abilities, JS frameworks will likely start a slow death as the existing web frameworks start to have both server and client side delivery models.

ASP.NET Core with Razor/Blazor is a great early example of this: https://www.youtube.com/watch?v=Qe8UW5543-s

Re: You probably don't need a single-page app

#409
post #366

Earlier quoted context omitted.

You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

Not only that but you have to reinvent SSR with front end frameworks. Why do something simple when you can make it 10x as hard but ultimately end up with the same result.

Re: You probably don't need a single-page app

#410

Earlier quoted context omitted.

If Gmail is taking 10 seconds to load it might be worth your time to consider a faster computer for your own sake. It can be like 3-4 seconds on a faster computer.

Nah, just tested and mail.google.com took 23.3 seconds to load in Chrome and 30.2 seconds in Firefox. I have a 4-core 8-thread i7 and am on a 20Mbps internet line. It's the website, it isn't my computer.

Takes 2.5 seconds with Chrome on my Quad Core i7 (laptop)
Post reply on HN