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

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

571–580 of 637 posts

Re: SPAs Were a Mistake

#571

Post by onaworkcomputer »

Tabular-Iceberg wrote: post #506
onaworkcomputer wrote: post #128

Earlier quoted context omitted.

> The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Yeah, but full page caching is a thing, and in my experience, teams writing traditional server-rendered pages are much more aggressive in their use of response caching than are teams writing JSON APIs. Honestly, a Rails/Django/Laravel app with smart caching headers and a Varnish instance in front feels more reliab…

How does that work if a user is logged in and private data is visible on the page? I’m thinking of building something that only renders public data on the server, and then later gets that which pertains to individuals through an API. But I don’t want to spend more time on a lot of complicated plumbing than on core functionality in my application. A SPA seems like the path of least resistance here, since all you have…

I've seen a lot of projects that use a full response cache to capture a view with holes where user-specific information would go and then fill in those holes with some client side JS. I wouldn't call those SPAs, though.

But I'd say it's more common to just use "private" cache headers in this case for any page that differs for logged in vs unauthenticated users. The user's browser will still serve as a full page cache, but shared caches will ignore those pages.

Re: SPAs Were a Mistake

#572

Post by ozim »

manigandham wrote: post #537
ozim wrote: post #357

Earlier quoted context omitted.

99% of people don't FRICKING care. Most of the users I have to deal with still have problems with double clicking. They don't understand basic browser features. They don't understand that they can set preferred language in their browser. History related features are not an argument in any way.

Why would people not care that browsing URLs work well?

Because they don't care about computer stuff. They just have to do computer stuff because they are forced to.

Re: SPAs Were a Mistake

#573

Post by me_me_mu_mu »

chilldsgn wrote: post #477
me_me_mu_mu wrote: post #176

I had the pleasure (aka hell mode) of building a content site as a SPA because some non-technical manager kept pushing it (it was one of those companies). It was an insane task to meet all the SEO requirements, we ended up doing server rendered pages, and keep in mind this was years ago so there was not a whole lot of support or tutorials on how to do it. Oh well, I got paid to learn a bunch of new stuff so I can't c…

Yeah, I was gonna say SPAs are not really good for marketing type of sites. Doesn't work easily with SEO. I learned this the hard way, but there are other use cases for SPAs. Just don't use it for sites that require good SEO. I am pushing for a rebuild of that site using Laravel and minimal amount of javascript, actually :D

That was the worst manager I've ever worked for. He also never pronounced my name right even after I told him, so he can go f** off. Still triggers me to this day :D

He pulled the SEO requirement at the last minute, since he would not invite the technical people to decision meetings.

Re: SPAs Were a Mistake

#574

Post by manigandham »

ozim wrote: post #572
manigandham wrote: post #537

Earlier quoted context omitted.

Why would people not care that browsing URLs work well?

Because they don't care about computer stuff. They just have to do computer stuff because they are forced to.

They do care that it works. That's the point being discussed.

Re: SPAs Were a Mistake

#575

Post by Draiken »

softwarebeware wrote: post #557
gls2ro wrote: post #197

Earlier quoted context omitted.

I give you Google Maps is a perfect example maybe for SPA. But Gmail? Why do we need SPA for that? Receiving emails notifications could be websockets and clicking on email should go to a new page displaying the email. I dont know if the initial gmail was SPA or not, but the current version is very very slow and consumes a lot of memory to display some emails that worked even in terminal clients, remember Pine? The sa…

Do you want a full page reload just because you deleted an email? Or flagged it? Or marked it as spam? Or even do you want your webmail in frames just to have a reader pane? Webmail is a great SPA candidate.

I do agree that perhaps email clients are a good SPA candidante, but at the same time most of that type of interaction can be done with a sprinkle of JS.

Because of a few simple interactions that are better without a page reload, people write the ENTIRE application on the frontend, with everything duplicated (modeling, validation, routing, error handling, etc).

Re: SPAs Were a Mistake

#576

Post by hinkley »

midiguy wrote: post #241
hinkley wrote: post #79

Earlier quoted context omitted.

Why are wood shops loaded to the rafters with tools? Because there is no Golden Hammer, only people who think they’ve found one. You’re saying you’re doubling down on a single solution, which is probably not actually true, but you are surrounded by younger developers who will copy what you seem to be doing rather than what you’re actually doing. All of these unresolved arguments are about team dynamics, not technolog…

> All of these unresolved arguments are about team dynamics, not technology No, it's definitely about technology. Let me simplify this for you. Technology A can do thing 1 very well, and thing 2 decently. Technology B can do thing 2 well, but can't do thing 1 at all. In reality, people who only do technology B claim technology B is necessary to do thing 2 and go to great extents to write blog posts claiming such, whi…

Yeah that’s not a technology problem, that’s an ego problem.

Re: SPAs Were a Mistake

#577

Post by shroompasta »

tored wrote: post #548
shroompasta wrote: post #502

Earlier quoted context omitted.

I mean, of course the co-creator of Django would say this. I wouldn't recommend newer generation of developers to build traditional web apps, let alone use jQuery. I don't understand why people think we're still in the age of form submissions and blog posts - There has to be a good majority of us here that has worked on something complex that required SPAs here, no? Not only would it be detrimental to a young develop…

> There has to be a good majority of us here that has worked on something complex that required SPAs here, no? You can still create a something complex without using any of the common SPA techniques, instead you can use things like Hotwire, Livewire, htmx instead.

not practical for hiring.

and although I find it intriguing that hey.com is using Hotwire, it's still insignificant compared to some SPA framework's ecosystems.

Performance isn't an end all be all, otherwise we should make another article and say "Python and PHP was a mistake for web servers"

There is some give to be had for the sake of practicality.

Re: SPAs Were a Mistake

#578

Post by Graffur »

Nextgrid wrote: post #434
Graffur wrote: post #351

Earlier quoted context omitted.

> developer convenience This is really, really important though.

Am I the only one preferring good old-school, "boring" stacks that I can run entirely on my own machine if needed and understand the sequence of operations as opposed to relying on dozens of third-parties, services, APIs, etc just to do what a stupid PHP script on shared hosting could do 20 years ago? I don't consider the modern complexity as convenience.

I assume you're not developing modern web applications then?

Re: SPAs Were a Mistake

#579

Post by gortok »

com2kid wrote: post #329
simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

> And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

> . You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.

Why would I want to keep any state on the client? What in the history of the web (the whole idea being its someone elses computer) would make it a good idea to take away the one major selling point of the web? That no matter what, someone else has the state I need, and I never have to worry about losing that if something happens to my connection. It either went through or it didn't.

Re: SPAs Were a Mistake

#580

Post by int_19h »

littlecranky67 wrote: post #547
int_19h wrote: post #538

Earlier quoted context omitted.

Then why aren't we working on improving the databases to allow for such complex rules, and instead wrap it in another layer (often multiple) to do all this stuff there?

because a database should not hold your business logic. It should hold your data, and that it can do well. See also my other post on parent for more reasoning.

Why shouldn't it? As noted above, database servers already have most of this (security) logic in them - likely tested much better than whatever you can write on top of the database yourself. And given how many apps are basically just CRUD, why reinvent the wheel every time?
Post reply on HN