Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

471–480 of 522 posts

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

#471
post #452

Earlier quoted context omitted.

I want to be open-minded for you to have your fun. But at the same time, I want to let you know the problems with your approach from my perspective if you want me to interact with your site. No offense, but I don't know you, so I'm not going to run untrusted code you serve my computer without some good reason. That means your website is completely broken for me. It is also likely broken from an accessibility standpoi…

Relying on JavaScript doesn't "break the fundamental precepts underlying the web", that horse has sailed long past that bridge. Today, not running JS breaks the web. You can lament this, I too think it's not ideal, but you can't change it. So don't accuse devs of breaking the web for using an SPA just because you're part of the 0.002% of users that doesn't run js by default. Furthermore SPAs do not break accessibilit…

Hi and thanks for your responses. I think you may not be considering my post in the context of the above person's webpage. I would be interested to hear if you see my perspective a bit more after viewing the page and its source code if you haven't already.

(1) I do think I can make a small difference toward making the web better by pointing out the drawbacks of unnecessary JS. I also think it's fair to describe this page as breaking the way hyperlinks usually work on the web.

(2) I don't mean to say all SPAs always break accessibility -- again this is all in the context of the page above. I do think, for the reasons I gave, it's fair to say that a plain HTML page with a list of links is much more amenable to generic accessibility tools than a block of JS that emulates behavior of links.

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

#472

Earlier quoted context omitted.

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 wh…

Okay I can't believe that either! You're really talking about full Gmail loading in 1/3 of a second? That sounds impossible if we're loading the same Gmail...

Yeah, it's pretty crazy that there would be such a huge difference. Turning off Hangouts and using uBlock Origin might make a big difference because that's all I've really done to modify it.

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

#473
post #471

Earlier quoted context omitted.

Relying on JavaScript doesn't "break the fundamental precepts underlying the web", that horse has sailed long past that bridge. Today, not running JS breaks the web. You can lament this, I too think it's not ideal, but you can't change it. So don't accuse devs of breaking the web for using an SPA just because you're part of the 0.002% of users that doesn't run js by default. Furthermore SPAs do not break accessibilit…

Hi and thanks for your responses. I think you may not be considering my post in the context of the above person's webpage. I would be interested to hear if you see my perspective a bit more after viewing the page and its source code if you haven't already. (1) I do think I can make a small difference toward making the web better by pointing out the drawbacks of unnecessary JS. I also think it's fair to describe this…

I misunderstood your post regarding accessibility then :) it's unfortunate but some react and Vue patterns tend to lead to a lot of div soup. It doesn't have much to do with the tooling but rather a lack of education for the devs on the subject and it's a testament to how easy it is to create custom components in both.

> I also think it's fair to describe this page as breaking the way hyperlinks usually work on the web.

Well maybe. A good SPA imo will render the first pageload with SSR, which means that your links will actually work the same. You share a link or open it in a new tab or whatever and it will load a page full of HTML that might not even need JavaScript.

SPAs do hijack the link system but they do so to retain natural back button functionality. Back when they didn't, people complained about that, rightfully so.

Howe there's nothing emulating anything. SPA links are anchors, as they are anywhere else on the web, and all the apis are native to the browser. It doesn't have anything to do with accessibility, no.

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

#474
post #238

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…

It's funny how Google has been banging on about "just a few milliseconds of extra loadtime and your bounce-rate increases!" while in Gmail it's like they think the product is so good, people should be willing to wait 10 seconds to view their _mail_. The reason I'm even reading this comment section is because I wanted something to do while waiting for Gmail to load.

But the reason Gmail is so slow isn't because they've made it a SPA. It's because they made it a shitty SPA. They use nonstandard web technologies that work like ass. It was also a SPA before the new redesign and it worked pretty well.

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

#475

Earlier quoted context omitted.

Okay I can't believe that either! You're really talking about full Gmail loading in 1/3 of a second? That sounds impossible if we're loading the same Gmail...

Yeah, it's pretty crazy that there would be such a huge difference. Turning off Hangouts and using uBlock Origin might make a big difference because that's all I've really done to modify it.

Would you mind measuring how long it takes on a vanilla browser (e.g. guest mode of Chrome) without anything being turned off?

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

#476
post #417

Earlier quoted context omitted.

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…

1 Mbps and each page is 5 seconds? It sounds like huge pages you are viewing

Well satellite has bad latency on top of that. Not especially large pages, I'd say. eBay, IMDb, Wikipedia.

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

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

I have always felt as angular was the second major player and vue the one in the 3rd place.

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

#478

Unpopular opinion: I love SPAs for simple stuff. Yes, they're a ton of work. But the feel of them is unparalleled. I have my personal home page written as a Vue SPA. It was a silly amount of work to get together, and not everything works perfectly. BUT: it moves like a rocket. I pre-render the simple front page, so initial load is nearly instantaneous (especially with cloudflare &c), and, by the time a visitor finish…

That's clever. Could you give me some pointers on how you made (just) the front page pre-render, while the rest of the app loads?

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

#479

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…

Yeah we have read experiences like yours again and again on every HN thread about SPA, but why we never learn? We developers kind of helping this fashion to happen.

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

#480

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)

Also, on the majority of SPA frameworks you have the notion of components which makes making the UI a lot simpler than with traditional SSR abstractions (templating and partials are not sufficient).

Or your backend template engine is weak. In Elixir, EEx used in Phoenix, every template is a function. It's not supper good, but it's component (I hate term "component" and prefer "function")
Post reply on HN