5 ms·

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it. Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.

jaggederest 9y ago
> How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem. If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.
- aaron-lebo 9y ago
  You're glamorizing old web. Old web had the same quality issues, most form submissions were not taking 100 ms and JS validation does not (have to) take 100 ms today. If you exaggerate the numbers, you can't make any useful comparisons.
- vecinu 9y ago
  What about all of the information that was already in the submitted form? We can now keep the user's state and inform them of errors in a way that is more difficult with server-ride rendering.
  - bildung 9y ago
    > What about all of the information that was already in the submitted form? Of course the form gets returned from server validation will all user input prefilled? At least with Django that's the default behaviour.
    - DCoder 9y ago
      Does "all user input prefilled" include file uploads?
      - hawski 9y ago
        It's not complicated. Server could offer to use already uploaded file or selecting a new one. Identifying it with session cookie or some kind of file hash.
ehnto 9y ago
You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules. Where simple works, pick simple. 5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice. While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.
- TeMPOraL 9y ago
  This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".
  - mrighele 9y ago
    I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)
    - nojvek 9y ago
      This. Every major client lib out there uses some variant of vdom. If this dom diffing was natively supported, browser would request with current dom hash and server could efficiently reply with a diff that both server and client can compute to be the same new hash. If it's forms. Client calls server with base hash + changes made by client and server replies with. Base hash + new diff to apply. The new diff includes validation changes. It's trees and diffs all the way down.
mattmanser 9y ago
Well, you don't need a SPA to do that at all. You don't have to do the validation client-side, you can still get the server to do it with some extremely simple javascript. You can render server-side, then switch it to an ajax post in javascript. On submit, post the form back in ajax (a simple `.serialize()`) and if there's a validation error in the form, return the HTML form back in the response with the validation errors and replace it in the DOM. Virtually instant feedback, no page reload, no 30 second initial SPA load. In ASP.Net MVC, for example, this is as trivial as changing the `Layout` property of the page in the controller, the full layout for GETs, no layout in POSTs. Technically you don't even have to support progressive enhancement, but it's so trivial in most frameworks you may as well. I believe Rails has a built in turbo feature which essentially does this and more. Example ts code, though usually put more in to disable double clicks and add a loading spinner: onSubmit = (e: JQueryEventObject) => { e.preventDefault(); let $form = $(e.currentTarget); $.ajax({ type: $form.attr("method"), url: $form.attr("action"), data: $form.serialize() }) .done(() => { //do something }) .fail((e) => { if (e.status == 400) { $(".js-form-wrapper").html(e.responseText); this.wireUpControls(); } else { //handle error } }) } And wire it up on initialize with: $("#your-form").submit(this.onSubmit);
- nawitus 9y ago
  The comment said "no Javascript", no "no SPA".

jaggederest 9y ago

> How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem. If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.

aaron-lebo 9y ago
You're glamorizing old web. Old web had the same quality issues, most form submissions were not taking 100 ms and JS validation does not (have to) take 100 ms today. If you exaggerate the numbers, you can't make any useful comparisons.
vecinu 9y ago
What about all of the information that was already in the submitted form? We can now keep the user's state and inform them of errors in a way that is more difficult with server-ride rendering.
- bildung 9y ago
  > What about all of the information that was already in the submitted form? Of course the form gets returned from server validation will all user input prefilled? At least with Django that's the default behaviour.
  - DCoder 9y ago
    Does "all user input prefilled" include file uploads?
    - hawski 9y ago
      It's not complicated. Server could offer to use already uploaded file or selecting a new one. Identifying it with session cookie or some kind of file hash.

ehnto 9y ago

You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules. Where simple works, pick simple. 5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice. While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.

TeMPOraL 9y ago
This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".
- mrighele 9y ago
  I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)
  - nojvek 9y ago
    This. Every major client lib out there uses some variant of vdom. If this dom diffing was natively supported, browser would request with current dom hash and server could efficiently reply with a diff that both server and client can compute to be the same new hash. If it's forms. Client calls server with base hash + changes made by client and server replies with. Base hash + new diff to apply. The new diff includes validation changes. It's trees and diffs all the way down.

mattmanser 9y ago

Well, you don't need a SPA to do that at all. You don't have to do the validation client-side, you can still get the server to do it with some extremely simple javascript. You can render server-side, then switch it to an ajax post in javascript. On submit, post the form back in ajax (a simple `.serialize()`) and if there's a validation error in the form, return the HTML form back in the response with the validation errors and replace it in the DOM. Virtually instant feedback, no page reload, no 30 second initial SPA load. In ASP.Net MVC, for example, this is as trivial as changing the `Layout` property of the page in the controller, the full layout for GETs, no layout in POSTs. Technically you don't even have to support progressive enhancement, but it's so trivial in most frameworks you may as well. I believe Rails has a built in turbo feature which essentially does this and more. Example ts code, though usually put more in to disable double clicks and add a loading spinner: onSubmit = (e: JQueryEventObject) => { e.preventDefault(); let $form = $(e.currentTarget); $.ajax({ type: $form.attr("method"), url: $form.attr("action"), data: $form.serialize() }) .done(() => { //do something }) .fail((e) => { if (e.status == 400) { $(".js-form-wrapper").html(e.responseText); this.wireUpControls(); } else { //handle error } }) } And wire it up on initialize with: $("#your-form").submit(this.onSubmit);

nawitus 9y ago
The comment said "no Javascript", no "no SPA".