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

591–600 of 637 posts

Re: SPAs Were a Mistake

#591

Post by rosenjcb »

bcrosby95 wrote: post #229
rosenjcb wrote: post #208

Earlier quoted context omitted.

Yeah, but the function itself doesn't return that view. The framework you're working in essentially composes the view based on the associated code and template. This is fundamentally different from just returning the view itself in the function. These are all declarative approaches, but leaving your view in code is a lot better. Every template-based framework I've seen has involved a lot of magic, syntax and DSL. Tha…

It's okay because despite JSX being a DSL you don't have to use it even though everyone does? Your line of thought is a large part of why I prefer ClojureScript to Javascript for SPAs. With reagent your components just work like the language, with nothing particularly special to remember.

Surprisingly enough, I'm a clojure developer and I really do like the hiccup syntax in Reagent. I haven't had the courage to use it in anything professional yet though.

EDIT: To answer your question, I actually think that JSX is a downside to React. I get that it was needed to convince the web crowd to adopt the library, but we need to stop pretending like we're writing HTML. We're not. The framework will take our JSX and do whatever it wants to it. I wish we just treated the DOM like a compilation target. That's actually what I like about Flutter - it treats the view as a render target and not as a document that you write to. Flutter web actually uses the canvas API to draw actually. And because of this, you can define your View model in a much more sane way (while still being fast). E.g. Flutter's Layouts make much more sense than HTML and flexbox/grid. They managed to separate the layout from elements. https://docs.flutter.dev/development/ui/layout

Re: SPAs Were a Mistake

#592

Post by tored »

tekknik wrote: post #581
tored wrote: post #539

Earlier quoted context omitted.

GraphQL is a consequence of the SPA design, a bad design leads to a worse fix. The drawback is that the frontend now has its own schema, often it starts as a naive direct mapping of the real schema. Thus any changes in the real schema also need to change the frontend schema and every use of it, or the mapping to the frontend schema needs to change. Eventually these two schemas will diverge because it is not feasible…

What a tortured usage of GraphQL. Schema files are automatically generated by the backend, and components pull data that they need, and know more. If you find yourself changing schemas constantly, then you’re not defining them in a scalable manner. You’ve basically misused the tech, and blamed it on the tech instead of your misuse.

That is even more horrible what I thought. Automatically generate schemas 1:1 and then expose it. Let me guess tons of information leakage, ddos attacks and queries not hitting indexes. This is absolutely the worst idea I come across in web development. Horror.

Re: SPAs Were a Mistake

#593

Post by int_19h »

MonaroVXR wrote: post #588
qw wrote: post #543

Earlier quoted context omitted.

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

So what's the solution to this?

Performance quotas.

Re: SPAs Were a Mistake

#594

Post by xenreal »

I was writing comment explaining how we can use new browser API's to get rid of SPA for 30 minutes.

Accidentally pressed F5 and all my message text disappeared in void. The same way it happened 15 years ago, same now, browsers not improved.

That's why we do SPA, we want reusable text input component out of box which automatically saves user generated content in forms on typing.

Re: SPAs Were a Mistake

#595

Post by fennecfoxy »

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…

Idk I don't think the problem is the SPA itself, it's bad design patterns that that make it terrible as you say.

I think really clean, performant SPAs can definitely be written and I think the overall experience of using a SPA can be much better than a multi-page site if the task at hand requires it.

There should be two parts of the web now really: * Traditional multi-page websites * SPAs that could have been a native app on the device, but are much more accessible in web form and without requiring an install

Re: SPAs Were a Mistake

#596

Post by manigandham »

lmm wrote: post #586
manigandham wrote: post #536

Earlier quoted context omitted.

That state lives on the context of the page. That's the point of having a URL/page lifecycle that reloads the context. If you need to persist past a reload then a few lines can save to localstorage. Anything more requires server-side calls anyway. This magical state that can only be managed on the client-side with a heavy SPA is a myth for 99.9% of sites.

> If you need to persist past a reload then a few lines can save to localstorage. Sure, and pretty soon you've got a dozen random little copies of bits and pieces of your state, all out of sync with each other. > Anything more requires server-side calls anyway. The issue isn't whether you need server-side calls (ultimately every webapp needs server-side calls, otherwise why would it be a webapp at all?), the issue is…

There's usability benefit in reloading to reset state and it's the common expectation when browsing. Regardless, if you do decide to add it then its a few lines of code to persist all forms on the page.

SPAs don't automatically provide any state management, and often the complexity requires even more work to manage forms. This is the complaint here, taking a simple requirement and forcing a webapp into it. It's completely unnecessary.

Re: SPAs Were a Mistake

#597

Post by Graffur »

lolinder wrote: post #398
Graffur wrote: post #344

Earlier quoted context omitted.

That just sounds like poor performing developers to me. You don't need snazzy animations between states. Just not reloading the full page is a benefit.

We have a PHP app that doesn't reload the full page. We use jQuery's .load(), which has been around since 1.0: https://api.jquery.com/load/

Okay - build a complex site with JQuery and see how it goes..

Re: SPAs Were a Mistake

#598

Post by midrus »

rrrhys wrote: post #456
lolinder wrote: post #376

Earlier quoted context omitted.

Your arguments seem to be assuming a particularly bad implementation of a traditional backend. 1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL. 2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML ins…

> Your arguments seem to be assuming a particularly bad implementation of a traditional backend. These weekly SPA complaint threads always assume a particularly bad implementation of a SPA as well though.

The key here is that if we consider equivalent good and robust implementations, equivalent capable teams, same UX, etc of an SPA and a traditional full stack MVC application with a modern ajax tool such as livewire, hotwire, etc the latter takes a fraction of the time and cost to build and the result is far less complex and easier to maintain.

I've worked in both kinds of environments, and unless you're building an offline first app, dogma, or Google maps...SPAs make absolutely no sense from the engineering point of view.

Re: SPAs Were a Mistake

#599

Post by midrus »

rtpg wrote: post #464
lolinder wrote: post #376

Earlier quoted context omitted.

Your arguments seem to be assuming a particularly bad implementation of a traditional backend. 1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL. 2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML ins…

Multi-page forms without some front end stuff ends up with the very clunky either "rerender previous form pages over and over again, except hidden", or "have some token to track partial form data", or "build up a DB to store a partially complete form". With some frontend work you can have a multi-page form just work, with the data stored in the client up until final submission, and only sending in partial checks ahea…

The alternative to SPAs is not 90s pages reloads.

Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

Re: SPAs Were a Mistake

#600

Post by midrus »

lolinder wrote: post #559
rtpg wrote: post #464

Earlier quoted context omitted.

Multi-page forms without some front end stuff ends up with the very clunky either "rerender previous form pages over and over again, except hidden", or "have some token to track partial form data", or "build up a DB to store a partially complete form". With some frontend work you can have a multi-page form just work, with the data stored in the client up until final submission, and only sending in partial checks ahea…

I've built a multi-page form in an SSR app with a tiny dash of JavaScript. The form's children are divs. The Next button hides the current div and shows the next one. The final Submit button is just a regular submit. If you get into more than 3 pages, this isn't a great approach for various reasons, but you don't need to reach for a framework the instant you have a multi-page form.

The alternative to SPAs is not 90s pages reloads.

Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

Post reply on HN