Hacker News Reader

Comment by kortilla | Hacker News Reader

> It's about making desktop-class applications more accessible via the web.

Everyone understands this is what devs are trying to do. The complaint is that my local newspaper doesn’t need a desktop class application. Nor does my bank, nor does Reddit for that matter.

There are vanishingly few websites that need a “desktop application” performance profile. Most websites are just viewing documents. The size of the SPA frameworks is frequently higher than the actual content being viewed.

Finally, if matching desktop app performance is truly the goal, the majority of SPAs fail horribly. Poor request patterns and transitions make the pages just as slow as server side rendered html. I would rather wait one second to get a JS-free response than look at another damn spinning circle for 5 seconds as the page sputters new elements in.

View on HN

Are there really that many local newspapers using SPAs though? I feel like advertisers delivering boatloads of JS with their ads sometimes gets conflated in this discussion.

Another point, it's true Reddit doesn't need a SPA. However, while I hate their new design, at the scale of Reddit an SPA can have real effects on server costs as well as user engagement. And, if you look at their growth numbers it seems to be working out for them, despite their design churning me as a user.

Third, the ecosystem of well-built components means that even if you don't really need a SPA, using React could save you money in launching your MVP, which is a big consideration for startups.

In the end, widgets with lower-latency interactivity, even when not absolutely necessary, is a better experience (for example, a form field that tells you what's wrong with your password as you're typing). Also, because the SPA crowd are building richer applications, you're going to have access to richer open-source widgets when building with that technology. So it's a hard thing to ask people to avoid React when it could be the difference between a great user experience and a mediocre one down the line.

Let's just continue to build better SSR tools so we can have the best of both worlds. We can build tools to help developers cut JS from their app, because it's true, eventually the latency bottle-neck isn't the speed of a round-trip request with PHP but the speed of downloading and executing all that JS with your SPA.

I believe this is a loosing battle, not because of hype, but because of the business reasons for using frameworks that are capable of delivering richer widgets. We can have our cake and eat it too, instead of fighting the shift in technology.

Don't know about local, but The New York Times is server-side-rendered React, ditto The Intercept, or Latvia-based Russian media called Meduza. The Times seems to be using server-side-rendered React and graphql/apollo as well.

In 2014-2015, React was eating the world, and newspapers didn't want to get left behind.

Our government's COVID statistics site[0] is a SPA. It doesn't need to be, it just shows tables and graphs, but these days any new page seems to needlessly be made as a sluggish SPA.

If you want to check hospital bed occupancy by state, it's 3 clicks, a 5 second spinner while it loads the results and shows the first 20 rows. It doesn't sound that bad, unless you refresh, in that case it throws you back at the landing page.

This should be a static site, but even if not, this is actually slower than a server-side rendered page. SPAs are not desktop-like when they constantly request server data, even if they hide it with slow animations and spinners.

[0] https://www.gits.igg.unam.mx/red-irag-dashboard/reviewHome

Yeah our county covid stats are the same. Static pages would work great here, instead of having to hit the API and DB for the data, since the data is updated once a day.

I've found that the new SPAified paypal is also unbelievably sluggish. I'm sure this is because they're doing something dumb rather than some intrinsic quality to SPAs, but SPAs sure do make it easy to do something dumb without noticing. especially if you're developing in 0-latency environments

Yes, SPAs can easily get horribly sluggish. The Josh Hopkins University dashboard[0] has been the de facto international source on this pandemic, and man, while I'm grateful for it, it is horribly sluggish. How much power has been wasted by clients rendering the exact same map and data over and over all over the world?

Compare their approach to Worldmeters' COVID statistics page[1], which while less functional, it's very lightweight and responsive.

[0]. https://coronavirus.jhu.edu/map.html

[1]. https://www.worldometers.info/coronavirus/

>Are there really that many local newspapers using SPAs though? I feel like advertisers delivering boatloads of JS with their ads sometimes gets conflated in this discussion.

Yes, I encounter it frequently. Some slow fucking main page loads for 5 seconds with no article in sight (presumably chewing on all of the trackers, assets, whatever, but no story nonetheless). Then a spinner starts to load the article and something stutters in after another 5 seconds and I get false hope that I can start reading. Another two seconds and gdpr cookie notice pops over, then a subscribe widget, then maybe a local weather widget. Close all this shit and now read the article on half of my screen because the top half is occupied by a banner with a breaking news ticker.

> Another point, it's true Reddit doesn't need a SPA. However, while I hate their new design, at the scale of Reddit an SPA can have real effects on server costs as well as user engagement. And, if you look at their growth numbers it seems to be working out for them

I’m sure their developers smoke some pot too, but we don’t attribute that to their growth. Why would you think an SPA helps when it’s one of the most widely hated features of the site? Has it occurred to you that the growth might be happening for a different reason?

> Third, the ecosystem of well-built components means that even if you don't really need a SPA, using React could save you money in launching your MVP, which is a big consideration for startups.

The ecosystem of server side stuff is far deeper and more mature. I don’t buy this argument.

> believe this is a loosing battle, not because of hype, but because of the business reasons for using frameworks that are capable of delivering richer widgets. We can have our cake and eat it too, instead of fighting the shift in technology.

Unlikely. Once the hype dies down people will realize SPAs are like mobile apps. You don’t need them for the vast majority of use cases and their instability and general shit performance will result in punishment by the search engines to the point where people with html5+css sites will rank higher and suffocate the bloated turds.

> Third, the ecosystem of well-built components means that even if you don't really need a SPA, using React could save you money in launching your MVP, which is a big consideration for startups

In my experience, that ecosystem of components does not compensate the cost os having to take a thousand decisions and making an equal amount of discussions and considerations and trade/off evaluations within your team (How to do state management, what router to use, class or funcion components, do we do SSR or not? Should we use typescript? etc,etc vs just using Ruby On Rails / Symfony / etc.

> Let's just continue to build better SSR tools so we can have the best of both worlds

Yes, just adding more and more complexity to compensate what you get by default with traditional MVC seems to be the right approach (irony).

Almost none of the SPAs I've been involved in in the last 5 years, required "desktop like" interativity. All of those would have been served a lot better by more traditional approaches.

I think SPAs and in general frontend-heavy frameworks are an amazing technology, but certainly overused. Bussiness wise, it makes no sense. Most of us, building SPAs, shouldn't. Problem is, it is not trendy or hip to use RoR, and everyone wants to have fun too.

I use 3 different banks quite regularly and there is a huge difference between them. My latest bank has great interest rates but also the worst UI experience mostly due to every interaction causing a page reload. I’m very much hoping for more JS usage in the banking world to make the experience a bit smoother!

> I’m very much hoping for more JS usage in the banking world to make the experience a bit smoother!

As a React developer this makes me anxious, lol.

> My latest bank has great interest rates but also the worst UI experience mostly due to every interaction causing a page reload.

I think this is heavily dependent on how fast the screen refresh is. Page reloads can be quick enough to appear pretty responsive - but if the website takes 3 seconds to serve the page up that’s obviously no good.

Did I forget to mention that they store the application state on the server end so the back button in your browsers doesn’t work?

Totally agree. One of the banks I bank with has a fully interactive JS application with no reloads. It's super smooth to interact with and makes the experience amazing.

I also bank with another bank that does full-page reloads and it's a huge pain. And it's frustrating when I have to do something because of how slow it is comparatively.

Between my wife and I we actively use 3 different banks (until recently 4), and we've also been through a bunch of redesigns, modernizations and acquisitions. I must have used some 10 banking UIs by now, not counting mobile apps.

One thing I can tell is: they get worse over time, and the more JS they involve, the worse they end up being. I can talk a lot about the UI design itself and it won't be nice (suffice to say: it's getting worse, and it's most likely because the goal of the bank isn't to provide a productive financial management UI, but to confuse you and upsell you financial products), but beyond that, performance goes down with each iteration.

(My least favorite piece of garbage of user interfaces is the offering of IDEA Bank in Poland - an Angular.js monstrosity where every operation - like opening account history, or downloading a PDF with transaction details - seems to take 30 second to one minute on a good day. The interface itself lags a lot, starts to visibly slow down if listing more than couple dozen items - say, transaction history for the past 6 months. But showing such long lists isn't a good idea anyway, because if you scroll to the end of it, some random XHR will fire and reset the list to "last month" or something like that, because of course it's a reasonable thing to do.)

Banking pages absolutely do not have anything in them that would require "desktop like functionality". They're the poster child of the document model - their job is literally to be digitized bureaucracy. They present you with forms and respond to queries. Every interaction you want to have on a banking interface boils down to that. Request a list of this. Request details about that. Send that much money there.

This is pretty spot on. The problem isn't JS, it's people turning small blogs, brochure sites, static pages, etc into SPAs

Amusingly, my local newspaper's paywall only works with JS enabled. Disable it, and you can read everything unencumbered.

Reply on news.ycombinator.com