3 ms·

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

grandempire 2y ago
There are real websites people rely on that don’t work without JavaScript - and ones that depend on the h1 size too.
- eschaton 2y ago
  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.
  - toast0 2y ago
    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.
  - moring 2y ago
    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.
    - psychoslave 2y ago
      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.
  - grandempire 2y ago
    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.
  - bowsamic 2y ago
    > And that’s a bad thing Why? You’ve given no argument that this actually is “abuse”
  - mvdtnz 2y ago
    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.
- deleted 2y ago
  [deleted]
econ 2y ago
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?
- savolai 2y ago
  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.”
  - skydhash 2y ago
    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.
    - savolai 2y ago
      Yeah, it's just been a while so I felt sketchy advicing something that might have changed.
- zdragnar 2y ago
  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.
  - moring 2y ago
    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.

grandempire 2y ago

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

eschaton 2y ago
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.
- toast0 2y ago
  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.
- moring 2y ago
  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.
  - psychoslave 2y ago
    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.
- grandempire 2y ago
  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.
- bowsamic 2y ago
  > And that’s a bad thing Why? You’ve given no argument that this actually is “abuse”
- mvdtnz 2y ago
  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.
deleted 2y ago
[deleted]

econ 2y ago

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?

savolai 2y ago
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.”
- skydhash 2y ago
  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.
  - savolai 2y ago
    Yeah, it's just been a while so I felt sketchy advicing something that might have changed.
zdragnar 2y ago
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.
- moring 2y ago
  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.