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

541–550 of 637 posts

Re: SPAs Were a Mistake

#541

Post by mattmanser »

manigandham wrote: post #237
mattmanser wrote: post #201

Earlier quoted context omitted.

Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked. Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean. But it's not that much different from Rails, Laravel, Django, etc.

What’s wrong with razor pages? They’re fantastically simple and productive. And WebForms wasn't a misunderstanding. It was a deliberate and brilliant design that brought WinForm developers and their experience to the web and allowed them to build complex web apps two decades ago that still work to this day.

Yeah, and as soon as soon as they tried doing that, they found out it was all superficial and the fact that there was HTTP calls inbetween meant everything started falling over and they saw weird behaviour. And instead of learning how to work with state management in general, they learnt how to work with WebForm's state management instead.

I'm working on one of those webforms projects right now, a legacy project that they need some fairly trivial tweaks to and it's an absolute nightmare of bad code. And I've done this before, it's become an accidental skill that I can still fix these awful messes.

One of the (many) reasons why webforms and the new Razor Pages are bad is because the code gets split up according to the UI instead of by function. So it gets scattered all over the place and is incredibly hard to do maintenance work on it.

The page-centric code layout that Webforms/Razor Pages/all the old PHP/Perl/etc. encourage is also extremely conducive in encouraging copy-and-pasta code for programmers trying to get stuff done asap.

So not only is it a nightmare to pick apart the code, you can often fine 2 or 3 copies of the same code that you only discover when one page is working as expected, but the same functionality is used somewhere else but someone just copied the page/control instead of actually splitting the page up into controls and re-using functionality.

I've seen this happen over and over and over. A single developer can avoid these pitfalls, a team cannot.

Re: SPAs Were a Mistake

#542

Post by tored »

qw wrote: post #534
int_19h wrote: post #486

Earlier quoted context omitted.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Even if you solve the security issue, a query can easily bring down the server if it has a complex join query. This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.

You can also use a VIEW.

How does GraphQL make sure to respect table indexes? If not you get a super slow query.

Re: SPAs Were a Mistake

#543

Post by qw »

tored wrote: post #542
qw wrote: post #534

Earlier quoted context omitted.

Even if you solve the security issue, a query can easily bring down the server if it has a complex join query. This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.

You can also use a VIEW. How does GraphQL make sure to respect table indexes? If not you get a super slow query.

You can still get performance issues with a view if you "select *" on a large amount of data, or join with other views. By exposing the SQL to a web page, you also open up for DDoS attacks more easily, as you can write complex SQL queries

You can get the same problems with GraphQL or stored procedures too of course, if the queries are not optimized correctly

Re: SPAs Were a Mistake

#544

Post by Ensorceled »

westoncb wrote: post #507
shkkmo wrote: post #490

Earlier quoted context omitted.

> From what I can tell most of the disagreement about SPAs results from devs who are building things that aren't app-like railing against their futility vs devs who are, who become perplexed by the vitriol when they have immediate experience with their architectural benefits. The SPA criticics from the article and this thread have repeatedly said that their issue is not with building things that need the benefits an…

I get that that's the biggest problem, but there are plenty of people in the thread talking about how they're a bad idea in general (including the comment I was replying to)—which incidentally lines up with the (apparently) clickbait title "SPAs were a mistake".

That’s the thing, they are a bad idea in general because, in general, people ARE building things that don’t benefit from an SPA article. You’re the one extrapolating that they are saying ALL SPAs are bad.

Re: SPAs Were a Mistake

#545

Post by i_have_an_idea »

randomsearch wrote: post #510
i_have_an_idea wrote: post #292

Earlier quoted context omitted.

It is definitely not solved for the vast majority of SPAs out there. Where it is solved, it is not solved for free or cheaply, as it would've been if these apps used server-rendering tech.

Obv there’s next Nuxt etc but Doesn’t Google’s crawler “render” JS now?

Kind of, but it is done separately from regular indexing, at a much lower volume and it is filled with loads of gotchas [1] that can make Googlebot skip your site.

In practice, what happens is Google spends their JS rendering resources on the top sites and will very rarely render a new site. Generally, assuming you stay clear of all the gotchas, Googlebot can eventually "see" your JS-rendered content but it will certainly take a lot longer to be indexed and, therefore, it will take longer to appear in search results. If you or your clients rely on organic search traffic for your site, then picking client rendering based tech is certainly a bad decision.

[1] https://developers.google.com/search/docs/advanced/javascrip...

Re: SPAs Were a Mistake

#546

Post by littlecranky67 »

dragonwriter wrote: post #540
littlecranky67 wrote: post #513

Earlier quoted context omitted.

Authorization & access restrictions. Yes, you can go quite far with table/row/column permissions, but a lot of business logic cannot be modeled using just those (i.e. "user cannot place orders if total outstanding invoice payments surpass value $X").

The combination of DB permissions, DB constraints, and simple (SQL, not procedural language) triggers gets you a lot, including the ability to enforce rules like the one you mention.

Yes, you can enforce a lot through SQL triggers/stored procedures etc. But you often end up abusing your DB/SQL as a business logic layer, where your business logic is encoded in a huge set of row/column permission and custom SQL triggers . This tightly couples your database into your whole business application stack.

Especially in Oracle PL/SQL, I've seen this often abused to an extend where no one ever understood the whole business logic anymore (as logic was spread out in frontend, middle-layer services, and DB mumbojumo), and the database became a fragile core-piece (with a significant vendor login) and hindered all sort of future development.

Seriously, your business logic should be modelled in code, ideally in some sort of service layer (which does not necessarily mean microservices!).

Re: SPAs Were a Mistake

#547

Post by littlecranky67 »

int_19h wrote: post #538
littlecranky67 wrote: post #513

Earlier quoted context omitted.

Authorization & access restrictions. Yes, you can go quite far with table/row/column permissions, but a lot of business logic cannot be modeled using just those (i.e. "user cannot place orders if total outstanding invoice payments surpass value $X").

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.

Re: SPAs Were a Mistake

#548

Post by tored »

shroompasta wrote: post #502
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…

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.

Re: SPAs Were a Mistake

#549

Post by littlecranky67 »

tored wrote: post #532
int_19h wrote: post #486

Earlier quoted context omitted.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Just give the end user an account to phpMyAdmin. Done. No complex frontend framework required.

You wouldn't belive how often companies use excel with external datasources like this. Excel basically is the common-ui for a lot of people.

And most of the projects I worked on in my professional career as a webdev, were replacing such workflow with a proper web application, because excel does not scale and eventually people fuckup their data.

Re: SPAs Were a Mistake

#550

Post by democracy »

nfw2 wrote: post #511
democracy wrote: post #501

Earlier quoted context omitted.

I am comparing apples to apples (CRUD to CRUD), not some random websites.

Okay apples to apples then This is Amazon in 2006 https://www.webdesignmuseum.org/timeline/amazon-2006 Now Amazon landing page has: - Omni-search with autocomplete - Dynamic language and region selection - Quick order forms accessible by profile dropdown - Many submenus embedded somewhere on the page - Multiple carousels of content embedded throughout the page Nothing like Amazon's current landing page existed on the…

yeah, most of them plugins are still jquery-compatible, so...
Post reply on HN