Comment by jolmg | Hacker News Reader

Comment by jolmg | Hacker News Reader

Parent Full thread

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.

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

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.

Reply on news.ycombinator.com