Hacker News Reader

Comment by eschaton | Hacker News Reader

Sure they are, they’re just not sexy. And making this change will ultimately save orders of magnitude more than the cost.

View on HN

I got stuck trying that. To facilitate non JS by default my products are checkboxes and the checkout button submits the form (it is a spa). This works well but navigating back the user is presented with an "error" page asking if they want to submit the form again. Is there a solution for that?

I have done this in projects with POST forms: ”To avoid the resubmit warning when hitting back, use the Post/Redirect/Get pattern: after a POST, redirect with a 303 to a normal GET page. The browser skips saving the POST in history, so back just takes you to the form without complaining.”

I thought that was the normal pattern, either rendering the form again when there's an error or redirect to the correct page in case of success.

Yeah, it's just been a while so I felt sketchy advicing something that might have changed.

The usual way to deal with it is to respond to form submissions with an HTTP redirect to another page. The user can still hit the back button, but the scary popup won't occur.

However, you run the risk of the user re-submitting the form anyway. Since this is involving orders and money, you may want the order confirmation / submit page to have a nonce or temporary ID representing the checkout session in the URL such that, upon revisiting that page, you can lookup the order status on the backend and redirect them to the order success page again.

This will prevent re-submission but still be confusing for the user. Why even allow submitting when navigating back? If the order has been submitted already, the submit button should be greyed out with a message saying that the order has been submitted already.

The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.

> Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server

And how would one do that without using JS?

Which part exactly?

Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today.

Identifying the order using an ID in the URL is standard practice everywhere.

When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.

The must have js part for me starts where one can open the store in multiple tabs then add and remove things on the first two and check out on the 3rd tab.

This is why I suggested the URL for the submission page be unique- having a session nonce / token or similar. That way, once the user checks out you invalidate the checkout session, and if the user hits the back button you redirect them to the appropriate page.

I specifically called out the issue of re-submitting certain forms and proposed the above solution. I don't think relying on cache headers is going to be sufficiently reliable.

I'm not arguing against a re-submission check. You'll need that anyway to prevent attackers from bypassing the browser and messing up your data.

But even with a nonce and a re-submission check, the cache headers are essential to make sure that when the user presses the back button, they'll see a greyed-out submit button. If the browser does not reload that page, the button will still be clickable. It won't work correctly because the re-submission check will fail, but a clickable and guaranteed non-functional button is very bad UI.

The latter is one of the main reasons that we have so much JS/SPAs. Sure, you can build an application without it that is somewhat functional, but the UI will be low-quality -- even if this particular example might be fixable with cacheability headers.

There is no re-submission check. When the user hits the back button, and requests the HTML from the server, the serve responds with a redirect. The user never sees the expired cart.

The user you’re replying to thinks the web is the wrong tool for any app

There are real websites people rely on that don’t work without JavaScript - and ones that depend on the h1 size too.

And that’s a bad thing, and the people involved in making those sites should feel bad and do something about their mistakes rather than just shrug. And we should call them what they are: Mistakes, abuses of the web.

Sure, the people making these things should feel bad about it, and ideally change their choices... But if 5% of Firefox users can't use your page, and your page is important, they'll consider Firefox broken and go use something else.

Firefox isn't doing so well on market share, and appearing to be broken isn't going to help.

You have now stated that "those people should feel bad" for the second time. Personal attacks will hardly bring any change into this world. I'd instead suggest that you propose actual ways to solve the same problems that Javascript-based SPAs have solved which the non-JS web is still stuck with.

Just add a matter of precision, personal attacks won't generally improve the world on the overwhole aftermaths. But they do generally change the world into a less pleasant place to live in.

And you are failing to observe a difference between what should happen and what has actually happened.

Changing the latter costs money - time from people’s lives.

> And that’s a bad thing

Why?

You’ve given no argument that this actually is “abuse”

I made a web game that's simply not possible without js. Is it your contention the it simply shouldn't exist? Lots of people seem to enjoy it and I think they'd be disappointed.

Reply on news.ycombinator.com