7 ms·

> Really, there is no reason why a form should require JavaScript. I’m a web developer who has never done significant forms without JavaScript. So I’m curious

> Really, there is no reason why a form should require JavaScript. I’m a web developer who has never done significant forms without JavaScript. So I’m curious: how would you handle reactive form fields without client side scripting? For example (perhaps a bad example): the user is entering data in “rows”. The user clicks “add row” and then a new row of fields appears. The user can also delete rows on a whim. Their changes should only be persisted once submit is clicked. Would the “right” way be a full page reload with the row added/deleted, and caching all the values? Not to mention, if fields require cross validation, is it customary to have to submit the form to get the validation error messages to occur? On some of the forms I’ve worked on, this would be very complex.

AtticusTheGreat 7y ago
In the old days the user would submit the form, the validation would happen on the server, then return a result. If the result was a failure, you would render the errors on a new page load. If the result was a success, you could redirect the user to "confirmation" page or reload the same page but with a different output.
malvosenior 7y ago
> Would the “right” way be a full page reload with the row added/deleted, and caching all the values? If the user didn't have Javascript enabled, then yes. You'll have to do the validation server side anyway, client side scripting is just a "nice to have" it shouldn't be mandatory. There are also probably too many people using the web to build applications that should be native.
- danShumway 7y ago
  > There are also probably too many people using the web to build applications that should be native. I hear this a lot, but I'm personally glad I don't need to download an app to my phone/computer to order pizza or find directions. Obviously this is a balance, but of the two extremes that could exist, having too many web-apps seems to be better than having too few. The quickest, simplest step you can take ATM to improve your device security is to install fewer apps -- particularly if you use an OS like Android. It's not clear to me that situation would get any better if half of the web disappeared.
deanclatworthy 7y ago
Split the form into pages, and use session variables to maintain state. Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing. I find it mind-boggling there’s a generation of developers after me that doesn’t know the basics of server side state. No offence intended to yourself, and good on you for putting yourself out there to ask :)
- hn_throwaway_99 7y ago
  As a web developer for the past 20 years, I do know how server-side state works. What baffles me is that, while there is certainly much to complain about the state of front-end JS dev today, the attitude of some that moving the web back 15 years is a good thing. There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. The dismissive attitude that "Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing" flies in the face of how 90% of heavy consumer front ends out there work today.
  - malvosenior 7y ago
    Single-page apps became a thing because of lack of development resources to build native apps or properly engineer server side solutions (as well as a business desire to centralize and lock down the product so people have to experience ads, pay subscriptions...). It has nothing to do with creating a user friendly experience. 100% of the time a user would benefit from a native app or properly engineered server-side rendered web page over a SPA.
    - JumpCrisscross 7y ago
      > 100% of the time a user would benefit from a native app I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.
      - AnIdiotOnTheNet 7y ago
zonidjan 7y ago
Yes. Use JavaScript for adding rows and validation, and fallback to new requests for both tasks if JavaScript is disabled. This is not difficult to do.
- davnicwil 7y ago
  It's not difficult to do, I agree, but time spent doing it, testing it, maintaining it carries the opportunity cost of doing other things that may be more valuable. Usually, such things are in abundance and take priority over supporting browsers without JS. For the vast majority of apps and businesses, JS as a minimum entry requirement is a perfectly acceptable tradeoff of lost users vs additional development cost.
  - zonidjan 7y ago
    I don't disagree. Heck, all of the websites I maintain for work require JS (although to be fair I also control the requirements for users: the latest version of Firefox or Chrome). I do wish the cost of requiring JavaScript was higher, though.
    - davnicwil 7y ago
      Genuinely interested, not assuming/implying I'm right - why? I think just insisting on JS is, for most applications, the best thing for the most people. If the app is such that it has maximum availability as one of its top goals (government public service, public infrastructure, bill paying etc) I completely get it, but otherwise I'm just not convinced that not requiring JS is somehow inherently good. If you'll allow a pretty weak analogy, it's almost like refusing to use a car and insisting upon using a horse and cart. You may have your own good reasons for doing that, and that's completely fine, you are free to make that choice, but you absolutely should expect the modern roads not to cater to you, and to be very often inconvenienced. Indeed, you shouldn't really expect society to spend lots of tax money catering to your choice and designing all roads, junctions, etc with it in mind, beyond the very minimum level so you can at least use the most important roads.
mixmastamyk 7y ago
The main article was talking about login forms, posting comments, and other simple use cases.
slim 7y ago
I would add a new @type property to table elements and publish it as HTML6 standard. @type=reactive would let you add/delete rows in the table.
pmoriarty 7y ago
99% of the forms I run in to in the wild are one-page forms without any interactivity, and just a single "Submit" button. Yet these web sites usually require Javascript (usually for tracking and ad delivery). Something like 90% of sites I run in to deliver static content, yet almost all use Javascript (again, for tracking and ad delivery). Fortunately, the overwhelming majority of these sites still work great or at least good enough without Javascript. Most sites out there really have no legitimate need for Javascript, with the exception of truly interactive sites like ones that let you play games in the browser, let you use some sort of application (like a spreadsheet, word processor, graphics program, or, arguably, web mail) in the browser, or do something like let you see live updates of things like stock tickers. But most sites are not like this. They just serve static content that could be served up just as well or even better without JS.
shkkmo 7y ago
> I’m a web developer who has never done significant forms without JavaScript. Perhaps you should give it a try and learn how to do it. That way you'll know when building non-js fallbacks is feasible and how do it easily. > is it customary to have to submit the form to get the validation error messages to occur? You trust the client to perform validation? Client-side validation should only be used to improve UX, not as a substitute for server-side validation.
c22 7y ago
> Would the “right” way be a full page reload with the row added/deleted, and caching all the values? I don't know if this is the "right" way, but it sure sounds like a more reasonable fallback for clients without JS than serving them a blank page.

AtticusTheGreat 7y ago

In the old days the user would submit the form, the validation would happen on the server, then return a result. If the result was a failure, you would render the errors on a new page load. If the result was a success, you could redirect the user to "confirmation" page or reload the same page but with a different output.

malvosenior 7y ago

> Would the “right” way be a full page reload with the row added/deleted, and caching all the values? If the user didn't have Javascript enabled, then yes. You'll have to do the validation server side anyway, client side scripting is just a "nice to have" it shouldn't be mandatory. There are also probably too many people using the web to build applications that should be native.

danShumway 7y ago
> There are also probably too many people using the web to build applications that should be native. I hear this a lot, but I'm personally glad I don't need to download an app to my phone/computer to order pizza or find directions. Obviously this is a balance, but of the two extremes that could exist, having too many web-apps seems to be better than having too few. The quickest, simplest step you can take ATM to improve your device security is to install fewer apps -- particularly if you use an OS like Android. It's not clear to me that situation would get any better if half of the web disappeared.

deanclatworthy 7y ago

Split the form into pages, and use session variables to maintain state. Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing. I find it mind-boggling there’s a generation of developers after me that doesn’t know the basics of server side state. No offence intended to yourself, and good on you for putting yourself out there to ask :)

hn_throwaway_99 7y ago
As a web developer for the past 20 years, I do know how server-side state works. What baffles me is that, while there is certainly much to complain about the state of front-end JS dev today, the attitude of some that moving the web back 15 years is a good thing. There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. The dismissive attitude that "Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing" flies in the face of how 90% of heavy consumer front ends out there work today.
- malvosenior 7y ago
  Single-page apps became a thing because of lack of development resources to build native apps or properly engineer server side solutions (as well as a business desire to centralize and lock down the product so people have to experience ads, pay subscriptions...). It has nothing to do with creating a user friendly experience. 100% of the time a user would benefit from a native app or properly engineered server-side rendered web page over a SPA.
  - JumpCrisscross 7y ago
    > 100% of the time a user would benefit from a native app I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.
    - AnIdiotOnTheNet 7y ago

zonidjan 7y ago

Yes. Use JavaScript for adding rows and validation, and fallback to new requests for both tasks if JavaScript is disabled. This is not difficult to do.

davnicwil 7y ago
It's not difficult to do, I agree, but time spent doing it, testing it, maintaining it carries the opportunity cost of doing other things that may be more valuable. Usually, such things are in abundance and take priority over supporting browsers without JS. For the vast majority of apps and businesses, JS as a minimum entry requirement is a perfectly acceptable tradeoff of lost users vs additional development cost.
- zonidjan 7y ago
  I don't disagree. Heck, all of the websites I maintain for work require JS (although to be fair I also control the requirements for users: the latest version of Firefox or Chrome). I do wish the cost of requiring JavaScript was higher, though.
  - davnicwil 7y ago
    Genuinely interested, not assuming/implying I'm right - why? I think just insisting on JS is, for most applications, the best thing for the most people. If the app is such that it has maximum availability as one of its top goals (government public service, public infrastructure, bill paying etc) I completely get it, but otherwise I'm just not convinced that not requiring JS is somehow inherently good. If you'll allow a pretty weak analogy, it's almost like refusing to use a car and insisting upon using a horse and cart. You may have your own good reasons for doing that, and that's completely fine, you are free to make that choice, but you absolutely should expect the modern roads not to cater to you, and to be very often inconvenienced. Indeed, you shouldn't really expect society to spend lots of tax money catering to your choice and designing all roads, junctions, etc with it in mind, beyond the very minimum level so you can at least use the most important roads.

mixmastamyk 7y ago

The main article was talking about login forms, posting comments, and other simple use cases.

slim 7y ago

I would add a new @type property to table elements and publish it as HTML6 standard. @type=reactive would let you add/delete rows in the table.

pmoriarty 7y ago

99% of the forms I run in to in the wild are one-page forms without any interactivity, and just a single "Submit" button. Yet these web sites usually require Javascript (usually for tracking and ad delivery). Something like 90% of sites I run in to deliver static content, yet almost all use Javascript (again, for tracking and ad delivery). Fortunately, the overwhelming majority of these sites still work great or at least good enough without Javascript. Most sites out there really have no legitimate need for Javascript, with the exception of truly interactive sites like ones that let you play games in the browser, let you use some sort of application (like a spreadsheet, word processor, graphics program, or, arguably, web mail) in the browser, or do something like let you see live updates of things like stock tickers. But most sites are not like this. They just serve static content that could be served up just as well or even better without JS.

shkkmo 7y ago

> I’m a web developer who has never done significant forms without JavaScript. Perhaps you should give it a try and learn how to do it. That way you'll know when building non-js fallbacks is feasible and how do it easily. > is it customary to have to submit the form to get the validation error messages to occur? You trust the client to perform validation? Client-side validation should only be used to improve UX, not as a substitute for server-side validation.

c22 7y ago

> Would the “right” way be a full page reload with the row added/deleted, and caching all the values? I don't know if this is the "right" way, but it sure sounds like a more reasonable fallback for clients without JS than serving them a blank page.