Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

Post reply on HN
Print view View original

351–360 of 522 posts

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

#351

Post by dimgl »

brazzy wrote: post #259
amoitnga wrote: post #226

Earlier quoted context omitted.

> 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. This doesn't seem like a problem of "MVC vs SPA". The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for examp…

You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks

Yeah, I don't buy that. React and Vue are dead simple.

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

#352

Post by julianlam »

Twirrim wrote: post #79
kyledrake wrote: post #67

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…

With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to…

Thanks for the tip! I realized this existed but didn't clue in to the fact that it could be set default. I've done so now, and already feel the absurd javascript weight lifting...

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

#353

Post by ng12 »

pmlnr wrote: post #23
ttty wrote: post #2

Normally you'll always need to add something interactive, therefore js. To do that with server side rendering you'll couple the client side to the server side. For example the server has to send a tag with a class name that the client also is aware of that. Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.

> Normally you'll always need to add something interactive Especially in news, articles, longreads, right? /s Most of the internet content would be perfectly fine without interaction, or with ordinary, oldschool POST forms

That's why I think these conversations are so meaningless. My job would be a nightmare if I didn't use SPAs. It's all about the right tool for the job.

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

#354

Post by ccalvert »

WrtCdEvrydy wrote: post #150
ccalvert wrote: post #39

I have modest skills as a developer. I was trying to convert an old static web site into something more interactive. Without really thinking it through, I started building a SPA. I got stuck on the SEO part. I found it innately complex, but the real trouble came from trying to bring together the disparate sections of the old static site while preserving and abetting SEO. One day I just ditched the SPA and rebuilt the…

React Server Side rendering with Next.js is the best of both worlds. You get streamed JS, with pre-rendered HTML for SEO.

Thanks. This does look interesting. It's hard to keep up with all the frameworks, but this does look like something worth investing some time in. I'll check it out.

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

#355

Post by dimgl »

I can't agree with this article at all. Having an JSON API and a small web app bundle that you can deliver with a highly-available CDN removes a ton of scaling problems related to SSR and gives a clean separation of concerns both from a managerial and architectural standpoint.

It also makes testing dead simple: you just make contracts on what the response bodies will look like and just feed mock data structures into your stateless web app. This allows the API team to make changes to the API layer with confidence that as long as they don't change the contracts with the web app, everything will still work.

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

#356

Post by Trisell »

It seems like a good 80-90% of the hate of SPAs doesn’t seem to be aimed at SPAs as much a poor programming and poor user experience because of that. In a lot of the cases that people here use. It’s not the SPAs fault as much as the programmers that messed it up. And honestly why do we think that putting it all back to SSR is magically going to fix poor programming?

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

#357

Post by eeZah7Ux »

ryukafalz wrote: post #189
mattmanser wrote: post #181

Earlier quoted context omitted.

This is a load of nonsense. If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA. Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.

>Plus you've got the extra layer of an API to maintain too On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.

Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.

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

#358

Post by expertentipp »

superkuh wrote: post #289
tyingq wrote: post #8

I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.

As browsers close the gap they simply become the OS but slower, more abstracted, and with less security. And they stop being good browsers. It's the old emacs situation come round again. The only positives are to corporations and institutions with profit motives to decrease dev time and increase ability to spy on users and extract rent from them.

> As browsers close the gap they simply become the OS but slower, more abstracted, and with less security

Browsers are forced to implement standards like CORS, single-origin policy, and multiple levels of SSL certificate validation and thus are more secure than most of native apps. How do you know whether that mobile app is not signing in over HTTP? In a web browser it's obvious instantly.

> motives to decrease dev time and increase ability to spy on users and extract rent from them.

Literally the worse what can happen over web browser is tracking based on various forms of fingerprinting. Native apps? MAC addresses, SSIDs, serial numbers - EVERYTHING is available for the native app to send ANYWEHERE, even over HTTP.

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

#359

Post by fiddlerwoaroof »

GordonS wrote: post #273
mandeepj wrote: post #218

Earlier quoted context omitted.

Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requ…

> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then…

I’ve occasionally thought of doing SSR but making it possible to server render only a small part of the page in response to an API request and then just use JavaScript to swap in the html from the backend.

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

#360

Post by fiddlerwoaroof »

fiddlerwoaroof wrote: post #359
GordonS wrote: post #273

Earlier quoted context omitted.

> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then…

I’ve occasionally thought of doing SSR but making it possible to server render only a small part of the page in response to an API request and then just use JavaScript to swap in the html from the backend.

You could use `Accept: text/html` to indicate that an API should return html rather than Json.
Post reply on HN