SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#581

Post by tekknik » Fri, Mar 04, 2022, 12:21 AM UTC

tored wrote: post #539

nrb wrote: post #454

Earlier quoted context omitted.

GraphQL is such a quality of life upgrade coming from this environment, especially at the scale where your frontend teams are potentially larger and shipping more than the teams closer to the SQL can provide.

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.

Re: SPAs Were a Mistake

#582

Post by tekknik » Fri, Mar 04, 2022, 12:22 AM UTC

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.

Because a human is writing the resolvers pulling the data from the database. Set whatever index you want to use.

Re: SPAs Were a Mistake

#583

Post by [deleted] » Fri, Mar 04, 2022, 1:40 AM UTC

dlisboa wrote: post #554

recursivedoubts wrote: post #413

Earlier quoted context omitted.

the original network model of the web was REST[1] a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2] htmx goes about it in the same way as the original web perhaps that is wrong, but the web was pretty successful overall [1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/

HATEOAS is great, but that's not my issue with HTMX. It's coding interactivity via HTML attributes that I have an issue with. It just never works. It overcomplicates things and there's an actual programming language right there in JavaScript to solve this. When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation . That can…

[deleted]

Re: SPAs Were a Mistake

#584

Post by hombre_fatal » Fri, Mar 04, 2022, 2:23 AM UTC

kitsunesoba wrote: post #246

hombre_fatal wrote: post #230

Earlier quoted context omitted.

Well, the browser has certainly evolved past the point of SPAs being nothing but a hack. The browser has evolved into a heavily generalized application environment, as much as we may want to bemoan that. A good web client can surely demonstrate this. It's certainly true that you don't get to lean on built-in features like history support, but that's why you can now drive history with Javascript. And all sorts of othe…

> Rich client development is always hard—on any platform—, and you always make concessions for the platform you're on. I certainly have to when I'm building iOS apps. But I see no reason for this to dissuade you if you can push a better UX to the user. I think the difference is how much you as a developer have to "fight" the platform. Having to implement history management yourself very much qualifies as "fighting" t…

As others have said, history management in a SPA tends to be done for you. But if you were to do it yourself, you would centralize your href-click handling in a single spot where you go history.pushState(path) and never bother with it again, it simply hooks into all .

While bad SPAs do this badly just like bad iOS clients do things badly (like incessant spinners, zero caching, and unselectable text), it's a small concesión to make in the scheme of client-side development.

On the other hand, have you ever wrestled with CoreData on iOS? It's like using the worst ORM with the worst Active Record abstraction, easy to get wrong, yet that's the tool you're given. And you're choosing between that built-in solution or going off the rails with another solution with its own trade-offs, and both paths feel like you're wrestling with the platform.

It just comes with the space of client-development, you just tend to get used to wrestling with the platform you have the most experience with, and it's easy to forget that when you judge the concessions that must be made on other platforms.

Re: SPAs Were a Mistake

#585

Post by recursivedoubts » Fri, Mar 04, 2022, 2:56 AM UTC

dlisboa wrote: post #554

recursivedoubts wrote: post #413

Earlier quoted context omitted.

the original network model of the web was REST[1] a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2] htmx goes about it in the same way as the original web perhaps that is wrong, but the web was pretty successful overall [1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/

HATEOAS is great, but that's not my issue with HTMX. It's coding interactivity via HTML attributes that I have an issue with. It just never works. It overcomplicates things and there's an actual programming language right there in JavaScript to solve this. When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation . That can…

yes, if you want to do things client side, hypermedia isn't going to be a great solution for you

htmx integrates with the existing HTML 5 validation API because, well, it's there, and that's what normal HTML does. I don't care much for the API, but that's the standard so we follow it. You can, of course, do client side validation however you'd like and integrate it with htmx using events, since events are the proper glue to tie things together in the DOM. I built a scripting language to help with this, and other stuff as well, called hyperscript: https://hyperscript.org

the "htmx" way for validation is the HTML/web 1.0/HATEOAS way: submit the form to the client side, validate and re-render. With htmx that can be inline, rather than a big clunky refresh-the-page action, which is why I say htmx extends and completes HTML as a hypermedia.

So long as you aren't willing to think about things in hypermedia terms, and htmx as an extension/completion of HTML as a hypermedia, you are going to miss the point. That's not to say that the hypermedia approach is always right, it isn't, but with htmx a lot more of the web application problem space is addressable with that approach.

And, as an aside, HATEOAS isn't great, outside the context of a hypermedia.

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

It is, rather, a fairly pointless category error, driven mainly by cargo-cult mentality from the early JSON API era.

Re: SPAs Were a Mistake

#586

Post by lmm » Fri, Mar 04, 2022, 3:31 AM UTC

manigandham wrote: post #536

lmm wrote: post #423

Earlier quoted context omitted.

> If this were true, you wouldn't need a REST API. I don't understand what you're trying to say here. When you make a REST call to get data, you instantly have two different sets of state: the client and the server. It's no different from SSR, it's just transmitted in a different data format (json vs html). SSR means you don't have a clear representation of the client-side state (as distinct from the presentation) -…

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 whether your framework can manage client-side state between those server-side calls. In theory you could create a server-side-rendering framework that was good at this. In practice, none of the big names has succeeded, and certainly not without significant costs. (I'd argue that Wicket does this well to a certain extent, but it comes at the cost of both relatively heavy server-side session state and significantly more network roundtrips than SPA style).

> This magical state that can only be managed on the client-side with a heavy SPA is a myth for 99.9% of sites.

On the contrary, 99.9% of sites have or could benefit from having some amount of client-side state. Any time you have a stateful UI, there's a usability benefit from persisting that. Any time you have so much as a form field - like the text box I'm typing in right now - there's a usability benefit from having that as managed state (I've lost comments because I closed the wrong tab or accidentally pasted over with something else), and in cases like this there would actually be a privacy concern with doing that on the server side.

In theory you don't need an SPA framework to do that. But in practice SPA frameworks are the only ones that do it well.

Re: SPAs Were a Mistake

#587

Post by MonaroVXR » Fri, Mar 04, 2022, 3:32 AM UTC

rtpg wrote: post #522

simonw wrote: post #479

Earlier quoted context omitted.

"It also seems extremely uncontroversial that sending data for a single item is going to require less text generation than sending over that data + the entire page." And yet... so many SPAs feel so much slower than MPAs. They suck down MBs of JavaScript, constantly poll for more JSON and consume crazy amounts of CPU any time they need to update the page. If you're on an expensive laptop you may not notice, but most o…

I'm on expensive machine and notice a lot, too! I also use a lot of "classic" websites where they fall over because of bad server-side state. An example, a train reservation site, where I choose dates + a destination. The next page, it shows me some results. I decide to change the date. I hit the back button, and it falls over, cuz the state management on the server is messed up. This happens a lot for me (this is ma…

> "I also use a lot of "classic" websites where they fall over because of bad server-side state.

An example, a train reservation site, where I choose dates + a destination. The next page, it shows me some results. I decide to change the date. I hit the back button, and it falls over, cuz the state management on the server is messed up."

any idea to not fall into a pit making an website/app/whatever?

Re: SPAs Were a Mistake

#588

Post by MonaroVXR » Fri, Mar 04, 2022, 3:38 AM UTC

qw wrote: post #543

tored wrote: post #542

Earlier quoted context omitted.

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

So what's the solution to this?

Re: SPAs Were a Mistake

#589

Post by recursivedoubts » Fri, Mar 04, 2022, 3:44 AM UTC

catlifeonmars wrote: post #447

recursivedoubts wrote: post #413

Earlier quoted context omitted.

the original network model of the web was REST[1] a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2] htmx goes about it in the same way as the original web perhaps that is wrong, but the web was pretty successful overall [1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/

> perhaps that is wrong, but the web was pretty successful overall Since HATEOAS is rarely implemented fully in practice, it would be simplistic to point to it as the reason the web is successful. The web allows an incredible variety of different architectures —- Some more closely aligned to HATEOAS and some less so. Perhaps this is the reason for the success of the web?

HATEOAS was and is implemented widely and effortlessly in hypermedia, since Fielding was describing the existing web architecture. It has failed fairly dramatically in JSON APIs, because JSON is not a native hypertext. Early API designers tried to shoehorn HATEOAS concepts into their APIs, which was somewhat plausible when APIs were XML, which, when squinted at, looked sort of like a hypermedia. Once we kicked over to JSON (and back to RPC as a network architecture) it became silly.

Re: SPAs Were a Mistake

#590

Post by lmm » Fri, Mar 04, 2022, 3:48 AM UTC

manishsharan wrote: post #553

lmm wrote: post #419

Earlier quoted context omitted.

Wicket has offered a beautiful component approach for over a decade now. Having seen it I can't stand page-oriented MVC frameworks (indeed it's good enough that it convinced me that OO actually has some merit in some cases).

I used Wicket quite extensively about 10 years ago so my comments may not be true anymore. I began using Wicket as it was so much better than Struts and JSF. However, the development of new custom widgets in Wicket was so much more convoluted than implementing the same widget in Backbone.js. And it was hard to inject new functionality into and existing page. I eventually refactored all my UI code into jquery+ backbon…

> However, the development of new custom widgets in Wicket was so much more convoluted than implementing the same widget in Backbone.js.

Hmm, I found developing custom widgets was a joy, though the key was to keep them very small and compositional - e.g. if you want a user details widget with an address entry, it's probably best to make that address widget its own smaller widget that the user details widget just uses - and aligned with your model hierarchy. Often you end up with a parallel hierarchy where e.g. you have a user model that contains an address and phone number, so you've got a user display widget whose model is that user object and in that there's an address display widget whose model is the address field of that user object (and similarly for your edit widgets).

I tried to look up examples of what doing the same thing in Backbone.js looks like, but the search results don't seem to be about making custom widgets as I understand it. To be fair I'm struggling to find examples in Wicket as well. But I'd be interested to hear what it does better.

> And it was hard to inject new functionality into and existing page.

Hmm, what kind of functionality do you mean? I will say that again making pages very compositional was key - my team settled on a pattern where most of our pages were just a single top-level panel (so you could always reuse or embed a whole page if you wanted to) and then most panels were made of a handful of smaller panels, similar to the clean code style where you try to make each function only call three or four other functions. And then it was easy to change whatever we needed because the code structure corresponded directly to the logical business/model structure and the inheritance structure corresponded to the visual structure (e.g. we had an abstract class for what an "editing panel" looks like and all our editing panels inherited from that. So if you want to add a new field to the user model, you add it in the user model and the user display panel and user edit panel are right next to that. And if you want to change the visual design of all our editing panels, you change that in the parent component and it will apply to all of them).