4 ms·

I can't think of any good "update on submit" sites that don't benefit from JS, but I'd love an example to prove me wrong. Even a forum like HN, an obvious choi

by Cpoll 3y ago

I can't think of any good "update on submit" sites that don't benefit from JS, but I'd love an example to prove me wrong. Even a forum like HN, an obvious choice for this, benefits from some JS for things like collapsible comments, upvoting/downvoting, etc. My other thought would be e-commerce checkout workflows, but those benefit from more advanced validation than you can do with HTML alone.

IggleSniggle 3y ago
HN does use js for expand/collapse, but could be using <summary> / <details> native element to do the same thing. Upvote/downvote could use <input type="submit"> instead, no reload required. These have the same fundamental behavior, no js necessary. If you need conditional behavior based on the response from the server, see my previous comment. None of that requires js. I say this as a person who does js frontend/backend all day, and I really don't have a bias against js like some devs do. I just wish people better knew the platform.
- gzalo 3y ago
  Hmm, how can you post a form without js and not require sending and loading the full page from the server? I don't think there a way to do a partial form submission? An iframe could work but it's really messy and likely slow?
  - IggleSniggle 3y ago
    Keeping in mind that I'm not advocating this per se but in the spirit of exploration: In the case of HN ui, no response from the server is strictly necessary on submit, and thus no reload is needed. Hence mentioning <input type="submit"> rather than <form>. You can indicate that the vote was made by using a checkbox and styling appropriately. A submitted comment can be similarly controlled with CSS. For non-HN cases, you can do long-polling, where the original response from the server is never closed, and thus you can always append new HTML to the end, hiding outdated elements as necessary with CSS. Example: <iframe name="do_nothing" style="display:none;"></iframe> <form action="vote" target="do_nothing"> <input type="submit" name="my_vote" value="up"> <input type="submit" name="my_vote" value="down"> <input type="hidden" name="comment_id" value="234"> </form>
  - otikik 3y ago
    Something like HTML-over-the-wire [1]. It means rendering HTML on the server side instead of JSON, and using javascript (mostly) to replace some parts of the current page with some parts of the returned response. It sounds kind of bad, tbh, but it works ok. The inconveniences get offloaded by all the javascript that you no longer need. And someone using a non-js browser still can get a regular form-that-you-send-and-reloads-the-whole-page. https://hotwired.dev/ https://hotwired.dev/
    - palmer_fox 3y ago
      Sounds like HTMX? So far I have failed to understand the attraction of this solution outside of very small personal projects. Front end is not just a presentational layer - we are rendering _data_, so having business logic on the front end makes perfect sense. I have built many BE template driven websites in the past (early 2000s PHP, then Django) and this approach does not scale well. What parts of the page do you reload with HTMX when user's state changes? A GET request to retrieve updated page header? Another request to retrieve updated page footer? Another request to reload the dropdown menu below a post? All of which could be rerefencing user's state. And then do you implement endpoints for literally every partial and propagate state to all these endpoints?
      - infamia 3y ago
        It doesn't have to work like that. You can fetch the entire body and then let HTMX or whatever hypermedia lib you're using DOM diff the parts that have changed in place.
      - otikik 3y ago
        No familiarity with HTMX, but familiar with the thing I linked. There, you render the whole page on the server side. The js "picks" which parts it needs to refresh by essentially using specific classes/attributes. It is a very "pedestrian" system, really. The fact that the whole page is sent is what makes "graceful degradation" possible. > Front end is not just a presentational layer I agree that front is not a presentational layer in all projects, but I also think that most web projects out there are CRUD-like, and for a lot of those, front can be just a presentational layer. I'm just saying that the effort of making front more than that and going the Single Page App route needs to be justified by some business reason - even something vague like "we want to leave the door open releasing a mobile app later so we need an API anyway".
- palmer_fox 3y ago
  Pretty sure type="submit" just means that clicking the button triggers form submit (as opposed to a button without type="submit" that woudn't submit the form). Submitting the form reloads the page, there is no way to repevent that without JS.

by Cpoll 3y ago

IggleSniggle 3y ago

HN does use js for expand/collapse, but could be using <summary> / <details> native element to do the same thing. Upvote/downvote could use <input type="submit"> instead, no reload required. These have the same fundamental behavior, no js necessary. If you need conditional behavior based on the response from the server, see my previous comment. None of that requires js. I say this as a person who does js frontend/backend all day, and I really don't have a bias against js like some devs do. I just wish people better knew the platform.

gzalo 3y ago
Hmm, how can you post a form without js and not require sending and loading the full page from the server? I don't think there a way to do a partial form submission? An iframe could work but it's really messy and likely slow?
- IggleSniggle 3y ago
  Keeping in mind that I'm not advocating this per se but in the spirit of exploration: In the case of HN ui, no response from the server is strictly necessary on submit, and thus no reload is needed. Hence mentioning <input type="submit"> rather than <form>. You can indicate that the vote was made by using a checkbox and styling appropriately. A submitted comment can be similarly controlled with CSS. For non-HN cases, you can do long-polling, where the original response from the server is never closed, and thus you can always append new HTML to the end, hiding outdated elements as necessary with CSS. Example: <iframe name="do_nothing" style="display:none;"></iframe> <form action="vote" target="do_nothing"> <input type="submit" name="my_vote" value="up"> <input type="submit" name="my_vote" value="down"> <input type="hidden" name="comment_id" value="234"> </form>
- otikik 3y ago
  Something like HTML-over-the-wire [1]. It means rendering HTML on the server side instead of JSON, and using javascript (mostly) to replace some parts of the current page with some parts of the returned response. It sounds kind of bad, tbh, but it works ok. The inconveniences get offloaded by all the javascript that you no longer need. And someone using a non-js browser still can get a regular form-that-you-send-and-reloads-the-whole-page. https://hotwired.dev/ https://hotwired.dev/
  - palmer_fox 3y ago
    Sounds like HTMX? So far I have failed to understand the attraction of this solution outside of very small personal projects. Front end is not just a presentational layer - we are rendering _data_, so having business logic on the front end makes perfect sense. I have built many BE template driven websites in the past (early 2000s PHP, then Django) and this approach does not scale well. What parts of the page do you reload with HTMX when user's state changes? A GET request to retrieve updated page header? Another request to retrieve updated page footer? Another request to reload the dropdown menu below a post? All of which could be rerefencing user's state. And then do you implement endpoints for literally every partial and propagate state to all these endpoints?
    - infamia 3y ago
      It doesn't have to work like that. You can fetch the entire body and then let HTMX or whatever hypermedia lib you're using DOM diff the parts that have changed in place.
    - otikik 3y ago
      No familiarity with HTMX, but familiar with the thing I linked. There, you render the whole page on the server side. The js "picks" which parts it needs to refresh by essentially using specific classes/attributes. It is a very "pedestrian" system, really. The fact that the whole page is sent is what makes "graceful degradation" possible. > Front end is not just a presentational layer I agree that front is not a presentational layer in all projects, but I also think that most web projects out there are CRUD-like, and for a lot of those, front can be just a presentational layer. I'm just saying that the effort of making front more than that and going the Single Page App route needs to be justified by some business reason - even something vague like "we want to leave the door open releasing a mobile app later so we need an API anyway".
palmer_fox 3y ago
Pretty sure type="submit" just means that clicking the button triggers form submit (as opposed to a button without type="submit" that woudn't submit the form). Submitting the form reloads the page, there is no way to repevent that without JS.