If I let the browser handle internal links so everything reloads, is my SPA now an MPA?
A single-page app is almost always worse than a multi-page app
111–120 of 152 posts
Re: A single-page app is almost always worse than a multi-page app
#112Earlier quoted context omitted.
I'm not sure stateful vs stateless is even the right way to frame it. With no JavaScript at all, your application is still stateful. Even if an individual HTTP request is stateless, your app as a whole still has state. The state just lives in the database in that case, and each request you make either gives you a view of part or all of its current state or provides data to transition the application from one valid st…
> I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. It sounds to me like "what if Javascript had SOAP", heh. We can envision lots of things. The beauty of software engineering/architecture is you can envision almost anything. The trick is that the more complex the thing is, the harder it is to pull of _well_, and the easier i…
Using SOAP from JS is doable if you really want to. :)
But if we're comparing to crufty tech, I'd say what I was talking about in that sentence was more like DCOM or CORBA. Both of which were nice in concept but a bit of a PITA in practice.
Re: A single-page app is almost always worse than a multi-page app
#113This is a load of garbage.
Re: A single-page app is almost always worse than a multi-page app
#114So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have…
You are making a false comparison. Why would an SPA not be a "ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries" ? I think it's quite possible to design an SPA like that.
Re: A single-page app is almost always worse than a multi-page app
#115Earlier quoted context omitted.
> I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. It sounds to me like "what if Javascript had SOAP", heh. We can envision lots of things. The beauty of software engineering/architecture is you can envision almost anything. The trick is that the more complex the thing is, the harder it is to pull of _well_, and the easier i…
Using SOAP from JS is doable if you really want to. :) But if we're comparing to crufty tech, I'd say what I was talking about in that sentence was more like DCOM or CORBA. Both of which were nice in concept but a bit of a PITA in practice.
Thanks, you're right, that's what I meant. I have thankfully forgotten most of what I ever knew about these technologies.
Re: A single-page app is almost always worse than a multi-page app
#116Earlier quoted context omitted.
With SPA you usually dont add frontend state on top of backend state, you only have the frontend part, and a stateless API. This makes it very easy to test and reason about.
> stateless API Does it not access any data?
It is generally accepted that when someone uses the phase "stateless API" they mean session state not data persistence.
Re: A single-page app is almost always worse than a multi-page app
#117Earlier quoted context omitted.
LOL. So avoid complexity by writing in VanillaJS, but feel free to load an enormous frontend library for a single component. Makes sense.
Eh, let's avoid eye-rolling hysterics on this forum and stay practical. There are components that are complex enough to warrant a view library, embedded in an application that's not. In fact, it doesn't take much complexity at all, in my experience. At which point loading a view library a la carte is your only real option. What doesn't make sense about that?
There are applications that warrant a view library. There's not a single case where importing two view frameworks with one handling the "complex components" makes any sense. React can also do very simple components. Pick one and run with it. If your application is complex enough to warrant a complex UI library, use a complex UI library.
The complexity involved in using two different libraries that handle the rendering in very different ways (one doesn't even do the rendering, so now you have two rendering solutions in addition to two view libraries. Yay!) in the name of simplifying your code is an absolute joke.
Re: A single-page app is almost always worse than a multi-page app
#118Earlier quoted context omitted.
This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).
is that true? googles auto-suggestions are rendered server side, as you type in the field they update. (unless I am mistake, but I thought that was the case)
I think it's a combination of local cache immediately, followed up by a server response
Re: A single-page app is almost always worse than a multi-page app
#119Earlier quoted context omitted.
I'm not sure stateful vs stateless is even the right way to frame it. With no JavaScript at all, your application is still stateful. Even if an individual HTTP request is stateless, your app as a whole still has state. The state just lives in the database in that case, and each request you make either gives you a view of part or all of its current state or provides data to transition the application from one valid st…
> I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. It sounds to me like "what if Javascript had SOAP", heh. We can envision lots of things. The beauty of software engineering/architecture is you can envision almost anything. The trick is that the more complex the thing is, the harder it is to pull of _well_, and the easier i…
Check out Lively4 [1] and see what you think. It's the fourth incarnation of dan ingalls' LivelyWeb concept.
[1] https://lively-kernel.org/lively4/lively4-core/start.html [2] https://github.com/LivelyKernel/lively4-core
Re: A single-page app is almost always worse than a multi-page app
#120Earlier quoted context omitted.
That's like saying that if you have to kill a fly, why opt for swatter when you can use a bazooka? After spending some years building an SPA webapp, I'm really missing the simplicity of stateless HTML. The front-end framework my colleagues picked really likes to carry state around, like between pages, which has caused numerous hard-to-find bugs. These bugs are triggered when you do certain sequence of actions across…
> I can add, remove, and edit rows from an HTML table without javascript or server side state I may be being dense, but can you provide me with a hint as to how? I guess the answer is "css", but it's not obvious to me how you would do this.
Not css but html5. It allows you to have multiple submit buttons, each linked to a different action through the formaction attribute. So I have an "add item" button that submits all fields (of the whole document) to a "/foo/form/add_item" route and simply adds a row of empty inputs. All other fields are filled with the same values they were submitted with. I also have a submit button per row where each has an action with a route that includes the index of the item to be deleted. Likewise, all fields are submitted, the indicated row is omitted, and all other fields are rendered with the values they were submitted with.
I got the backend prepared to facilitate this. I just call a function with another function that manipulates a datatype representing the form. It parses the submitted data into that, passes it through my function argument, renders it, and responds with it.
In the example I gave, the HTML table holds the inputs for the row data, but initially I thought the items would need more fields than would be pleasant to work with in the table. What I was doing then was displaying a subset of the data in the table, hold the raw data of all items in hidden fields, and have a subform below the table for new items and item edition. This was somewhat more complicated, specially because of the way the backend framework I was using thought of forms. I had one HTML form that I wanted to treat like multiple, validating one or the other depending on what submit button was used. Getting that to work in Yesod was a little troublesome but I imagine it would have been easier (though less safe) in e.g. Rails.
Anyway, I think continuing that way would probably have also been doable, had I not switched to having the inputs in the HTML table for simplicity.