Hacker News Reader

Comment by decasia | Hacker News Reader

So, 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 any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)."

I find the ad hoc jQuery+endpoint tangle much harder to reason about than something built with a front end framework and a more uniform API.

View on HN

In my experience, this is false.

In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts, but had to be multi-lingual, predictive, mobile-friendly, and fully accessible.

They use all those little bits that you talk about - multi-part forms, date pickers, autocomplete, and conditional input.

The only JS is for the autocomplete. The rest is all HTML5/CSS3.

We did user testing on three of them (100 people from our target group, selected randomly at two of our facilities, with generally low levels of technology literacy), and the paginated HTML5/CSS3 versions all scored higher than the previous Javascript SPA mess the preceded them.

If you didn't use JS for date pickers, you didn't have very inclusive browser support - especially for something like a healthcare website. [1]

Were the designs and layout of these SPA and HTML5/CSS3 website also identical?

[1] https://caniuse.com/#search=input%20date

If it's public facing, that's a huge concern.

If it's intended for business users, particularly if on an intranet site, it's often very easy to limit the number of browsers and versions you need to support to just a handful.

The Web has been collecting dates from users in forms long before date-pickers existed.

The Web has been doing lots of things poorly for a long time as well. I know I've seen some implementations of date-pickers I don't like, and more old school implementations without date pickers that were just clumsy.

It's more than a little absurd that there isn't a passable date picker implemented across the major browsers. I have wasted far, far too much of my life fighting with different half-baked JS datepicker components already in my life.

Still better than supporting IE6.

86% isn't bad, particularly considering you can easily polyfill a date-picker in the missing browsers and attach it to input[type=date] elements.

I can believe that in your user testing people would score a non-spa higher, but that isn't relevant to the question of whether an spa had more complex state management hidden from the user than a mpa.

What I imagine happened in your tests is, you didn't compare two different implementations of the same UI, you implemented the form via two different UI's and the users preferred the experience of new one to the old one.

I believe that you compared different UI's because otherwise you wouldn't need user testing: you could just measure the latency and code complexity.

The person you are responding to is saying, for a fixed user interface design, the necessary state management will be the same and your only choice is how to implement it. You say you believe this to be false but it doesn't seem like you are responding to the point.

Isn't it unuseful to be pedantic to the point of completely missing the point of the post you're replying to?

That person had something to contribute that was worthwhile. Sorry it wasn't a double-blind placebo controlled clinical trial, but it was still useful info and very much related to the topic replied to.

You must've missed the "vs plain HTML forms" part.

As a top level comment, it is valuable to point out that many executions of SPAs are lack lustre and will not deliver a superior user experience. If it was a top level comment and didn't lead with contradiction of the prior comment, I would have affirmed and probably not have posted anything. That is why I started by telling the commenter that I believed he actually produced better implementations, because he has a point but not a point that is meaningful to back up his disagreement.

The point of the comment chain in question is that a given UI has a need for a given amount of state. That is the point that was "[believed] false" and the point I was reiterating. User feedback is not useful at all for determining whether SPA's will require more state than multiple "plain HTML form"s. Moreover, the key assertion of the article is that this is necessarily the case, a point which is asserted without evidence and used as the foundation of the entire article. If you remove that assertion, the whole article collapses.

The comparison doesn't make sense though. There's absolutely no reason you can't build an interface using single-page that functions to the end-user identically to any multi-page form. You can't necessarily do the reverse (multi-page to emulate single page), but that is also irrelevant to the top level -- if the SPA has 10 times the complexity to build an identical UI, then it's probably going to be harder to maintain for no value to the end user (which isn't to say no value).

What I got is that they built different UIs and found one of those UIs was better than the others; that says nothing about single-page vs multi-page. Maybe it was easier for them to build the "winning" UI as a multi-page app, but I didn't see that being said.

I was wondering if I might be able to ask you some questions about those healthcare forms? (I wanted to send a private message but couldn't find any contact information.)

I'm working on a product that can fill out very complex PDF forms, as well as automatically generating web-based forms for people to fill in, so I would be very interested in hearing some more details.

>In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts...

Can you maybe elaborate a little bit more? I've had to do some pages for configuring industrial machinery, some having over 100 parameters, many of which would affect what other parameters could then be used or selected. Used Vue.js which worked pretty good, but I'm curious of other ways...

Some of our forms have 150+ fields with a rule engine that hides/shows various sections of the forms or hides items from particular drop downs, even auto populating fields with custom data via 60+ rules. All using jQuery, and it's impossible to work on.

Were you able to stop page refresh after form submit without JS? That's something I've been looking for, for a long time.

yeah that's also what I'm curious about, unless he adds a confirm page for some actions (which is actually more work) than just confirm('Text');

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 multiple pages. That stuff should be impossible. We really ought clear all state between pages, but apparently it's harder to fight the framework to do this. Carrying state around is just fundamental for it.

I'm currently on hiatus from that project to work on a small one that's needed quick. So far, I haven't used a single line of javascript, and it's a multi-page form. I can add, remove, and edit rows from an HTML table without javascript or server side state. Instead of an autocomplete input, I used an input and search button and had the server return a page with search results to select from. State is maintained through inputs, hidden or not. Different submit buttons perform different actions, but they all send all fields to be re-rendered in the next page.

I gotta say, it's just refreshing to do things this way after so much time. It's super-responsive not having to load and run bunches of javascript. It's also cool to see the forward and back buttons work for free, without any special consideration on my part. I can use them to replay every action I've taken in the form, all additions, edits, and removals of rows in the aforementioned HTML table, and the different form pages.

Were I asked to do things "prettier" (to somebody else's standard of what's pretty), I would just use minimal javascript. There is no reason to go all-in with a front-end framework just for a dynamic datepicker.

Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathize. Nobody wants to transfer state across page loads, it's a mess...

The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.

You know, TimJYoung, I think I may have misunderstood what you were asking. It's still one page that loads the initial HTML layout, javascript files, and HTML templates. What I meant by "page" in my original post were front-end "pages" that just modify the content of the main container tag in the actual page. I don't need to transfer state because it's already there. Clicking a link causes the framework to destroy the content in a tag, run some javascript functions that probably make some requests to the back-end and fill the tag with the "page" of the new front-end route. The problem is that because of front-end framework supposedly-helpful automagic, unexpected things happen due to keeping state from previous front-end routes.

Ahhh, yes, in that case it seems like you might possibly be better off (and happier ! :-) ) with just using a page-oriented architecture. It seems like the client-side state is just getting in your way, as opposed to being helpful in any way.

The way that I look at it is this: if you're going to do an SPA, then do it like you're writing a desktop client application: all content is manipulated on the client, the only requests to the back-end are for data (JSON/XML), and the client typically will maintain quite a bit of state. Complex applications that are ports of desktop applications and sit behind authentication dialogs are ideal candidates for SPAs. Here's an example case study of such an application from our company web site:

https://www.elevatesoft.com/articles?action=view&category=ew...

The one exception to this would possibly be something like an online manual/help browser application, in which you might be able to make an exception and have the content driven by an SPA, thus allowing for more control over advanced content navigation via a tree view or vertical menu.

In general, though, if you find yourself needing to do a lot of history/page management, then that is a good indication that you might be trying to shoehorn a traditional, page-oriented architecture into an SPA.

> 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.

You do still have state, but with a MPA you have a cleaner break between each page and thus far less ability for state to persist and cause problems (though there are plenty of technologies to shoot yourself in the foot if you so desire). I wonder if the most optimal solution is to have a MPA but using some SPA technology. This reduces the overall state of every page, but still gives you decent technology to work with the state of the page that you just cannot do away with.

shrug

That feels like a straw man, you can obviously also use modern js and a decent framework (vue react whatever) to make the portions of the page that need state, transitions and complex interactions very user friendly and easy to reason about without pulling the entire site or section of site up into an SPA. I have seen far too many implementations pull whole sites or large sections of sites up to SPA to mitigate one complex form or stateful interaction area. There is obviously a range of implementations that can be done from SPA|--------------------------|Page-Level and none of the areas on that spectrum require you to do anything in a"jquery tangle" let alone with any jquery include at all.

The author recommends that as an option as well

> Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React. The same applies to Vue.js and the rest of the pack.

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 state to another valid state.

Actually, thinking of an application as a series of transitions between valid states is why I enjoy using things like Redux. Used properly, it acts as a gatekeeper that makes it hard to move the application from a valid state to an invalid one. It adds a fair amount of boilerplate, though, which I know some people find frustrating.

Maintaining state on the front end and keeping it in sync with the back end is a pain. But I don't think it has to be. it's just an artifact of us being stuck in a certain paradigm of application development that we don't seem to be able to get out of.

It wouldn't be impossible to design a system that runs over a network, but doesn't require the front-line application developer to think about the network. It sounds like something Alan Kay might have worked on at some point. :)

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. And when it receives this message, it transmits itself across the network, validates its data, and persists itself into a database. Maybe an object database like Gemstone/S. But the application developer wouldn't have to worry about all the details most of the time. Just tell the object to save itself, and it'll report back whether it was able to or not, so you can update the application accordingly.

I'm sure I'm overlooking a ton of potential pitfalls, of course. I think we can do a lot better than we're doing right now, but I'm not 100% certain what better looks like, or quite how to get there. Maybe I just need to watch a few Bret Victor talks for inspiration and then get to work trying to build something. :)

> 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 it is to end up with a monster.

The complicated things take more expertise/skill/experience to design, and _also_ take more development time to produce -- and on an ongoing basis to maintain. And it's not always clear where development resources come from on 'shared commons' like platforms (unless they are proprietary and only available for a fee). The current front-end JS environment is already _pretty darn complex_ of course. How well it's pulling it off, well, is a matter of debate central to the OP.

On, and then there's getting different actors to coordinate in thing that require that (like browser's supporting something).

I can envision it too. But I wouldn't wager much on it happening in a way that actually results in an improved development environment (instead of a monster).

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.

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

https://pouchdb.com/ works more or less like that. You just save objects, and then it'll report back when it's synced with the server.

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

That's not really "rendered" server side; the data is fetched from the server by JavaScript in JSON form, then dynamically inserted into the DOM.

Honestly no it wouldn't suck and from a end user perspective for a calendar. It is actually far superior. Granted this is only my personal opinion. There seems to be this desire to overcomplicate the front end when simple solutions work quite well. Granted they don't have all the catchy buzzwords. But they make for a better less bug filled solution.

Calendar UIs commonly demand stuff like auto-refreshing, datetime selects, drag-dropping items around, resizing those, list goes on. Please elaborate how you'd build a "simple solution" that does not resort to client-side rendering.

Yeah, even a "Select All" button that checks all checkboxes requires Javascript.

Aside: I don't understand the premise of this thread that suggests it's a "SPA" just to, say, use React on a single page of an application. The whole basis of the "SP" in "SPA" is that the Javascript (state) spans multiple pages.

I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker. It stands out in my memory as one of the worst pieces of software I've ever seen produced.

> I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker

ASP.NET Webforms? I have good memories of being able to do that easily, with zero (or almost zero) JavaScript.

It's not the best user experience ever (the whole page has to reload after each click, and the state is persisted by serializing structs in <input type="hidden"> fields), but I had a pleasant experience when I developed with it.

ASP.NET Webforms components were the best thing until we finally had React/Vue!

The only problem was that it was way too easy to make a mess in your backend code.

Did he ever have trouble finding employers or paying clients?

My problem with the idea that SPAs, as an idea, are inherently more difficult to develop is that this doesn't translate to desktop/mobile applications, which are, conceptually, very similar in architecture (fat UI client, app server on the back-end). What may be more true is that the way in which we develop SPAs is so flawed that it causes serious issues with quality/development effort. IOW, perhaps the issue is with JS and its limitations with large, complex client applications, not the SPA architecture.

Disclaimer: my company sells a web development product that creates SPAs that work like desktop applications.

I agree, but using a front-end framework does not mean you must build your entire app as an SPA. You can still have separate pages, and UI components on each page get handled by your framework of choice. Also, there's a big difference between the state of a single form vs. keeping the state of your whole application in the frontend!

...and this is really what it comes down to. State management should come down to what the front end has to manage in order to be well-organized and structured. By creating a multi-page app, all you are doing is forcing yourself to organize your state by page. This is something that can be done simply enough by using modules in your state manager of choice. With a SPA, you have the option, with MPA, the decision of overall organization has already been made.

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?

Most JSON/data APIs for SPAs are similar to SQL database servers: maintaining a persistent connection is useful for performance reasons, but there's nothing about the API that dictates that it's required. The only state that is required across API calls is an authenticated session, and that is maintained on the server side.

and even authentication can be done stateless. Makes load balancing easy since each request can go to a different server

It is generally accepted that when someone uses the phase "stateless API" they mean session state not data persistence.

Yes, and this does nothing to help with the problem of state coherence between the backend and frontend.

There are some interesting implementations out there taking advantage of persistent connections to allow the server to handle the rendering while having targeted fragment updates come from the server.

Here's a thread I posted about some FOSS I've been working on that relies entirely on the server for rendering and using VDOM diff/patching on the server for updates. I'm definitely biased, but in my opinion this approach is vastly more user friendly because it enables realtime data updates as easily as request/response style updates.

here's the thread https://news.ycombinator.com/item?id=18318415

if you need some click bait, here's a gif of me in seattle over cell phone internet interacting with a SSR realtime app with the server in cali. https://imgur.com/z8pKt8t - all operations going round trip, with no application level JS written

Is this kinda how next.js works? I have not used it myself but I think it looks neat.

I believe nextjs is just taking react and rendering the initial page load on the server. So this library (texas) and nextjs don't really have much in common.

Thanks! Texas looks awesome.

having worked with JSF, I can safely say that me and server side rendering with peristent client connection to push updates are ... not friends.

You have multiple scopes in the same document. You have the jsp scopes which gets rendered once, when the client requests the page, and the jsf scope which lives longer. Initially when rendering these scopes seem to share variables, but after the request is rendered, the jsp scope gets removed

I promise you that your complains are with the abstractions chosen and implementation and not the concept. Texas doesn't have any of the issues you're talking about. You don't even worry about the data that populates the view. You simply write view code like any other templating engine that knows how to render itself and when data changes you send a small message to a process that handles updating the client and texas handles all the logic for efficiently updating its client.

From the blog post

> Third, if you’re implementing a very complicated component then you can use React just for that component.

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.

I'd assume it is to have a enormous front end library to handle all your complicated components and the author would be horrified by the prospect of every component written with a different front end library. It does present an issue if you literally have a single component that needs it, but I think this advice was aimed at cases where there are many such complicated components.

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.

HTML has support for everything you listed without resorting to JavaScript. Maybe some sort of graphic editor for a special file type isn’t possible without JavaScript? But most things really have been thought of and incorporated into html.

HTML doesn't have support for autocomplete elements and conditional input elements. Even date pickers are spotty.

Datepickers, specifically datetime pickers, in pure html are vomit inducing.

Or just have multiple pages with the complicated ones rendered with something like React. Nothing stops you from having more than one app bundle and with proper packaging it’s not even particularly slower to download or parse.

You don't have to use jQuery... https://news.ycombinator.com/item?id=18336429

That's why I love to use Vue to handle complex frontend states without building a full SPA

Reply on news.ycombinator.com