3 ms·

I think a more important point is that you should design your website to still be functional even if Javascript is disabled. Why? Because some users, such as

I think a more important point is that you should design your website to still be functional even if Javascript is disabled. Why? Because some users, such as those who use Tor, may have legitimate reasons to disable Javascript execution while browsing. Another reason is that Javascript-generated content can screw up your website's SEO when crawlers visit your site. Using Javascript for your form validation is okay if your form will still work with Javascript disabled. Yes, the user will lose some functionality of not seeing pretty validations, but it's okay if they can still use your site. [1] Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you. ----- [1] One way to improve the experience of form input validations for Tor users could be to have both a JS runtime validation and server side validation of your form inputs, and then put the validation messages that both would generate in the same place so that they stay in sync.

mhink 10y ago
I'd argue that single-page apps are a completely new emerging paradigm- the "web-page-as-application" rather than "web-page-as-interface-to-application" (or "webpage-as-hypertext-document", before that.) This isn't to say the previous two paradigms are bad, just that they're solving different problems. In light of that, here are a few responses to your points: > Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you. Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript. HOWEVER > I think a more important point is that you should design your website to still be functional even if Javascript is disabled. There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)
- kelseydh 10y ago
  I agree with what you're saying, but many, and I mean many, single page web applications get used for things that are essentially Web documents. If you're building a game or something interactive, I get it. But many SPA's are used to give database-backed forms a pretty skin. It's the overuse of Javascript in this way, and the lack of graceful degradation for forms like this when Javascript is disabled, that I think is beginning to create concern.
Semiapies 10y ago
you should design your website to still be functional even if Javascript is disabled True, but irrelevant to the issue of "can you do X on the client side without Javascript?". I can imagine a Javascript form validator that somehow makes the form unusable with Javascript turned off, but I've sure never seen one. And server-side validation is website 101 stuff that you should always be doing regardless of the front-end technology, not a counter to the many good uses of front-end validation.
- kelseydh 10y ago
  I agree. Though sadly keeping your JS validation messages in sync with the ones your server produces can still be a surprisingly high amount of work and headache. Many people can think of the time it takes to build functionality like this as gold plating.

mhink 10y ago

I'd argue that single-page apps are a completely new emerging paradigm- the "web-page-as-application" rather than "web-page-as-interface-to-application" (or "webpage-as-hypertext-document", before that.) This isn't to say the previous two paradigms are bad, just that they're solving different problems. In light of that, here are a few responses to your points: > Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you. Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript. HOWEVER > I think a more important point is that you should design your website to still be functional even if Javascript is disabled. There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)

kelseydh 10y ago
I agree with what you're saying, but many, and I mean many, single page web applications get used for things that are essentially Web documents. If you're building a game or something interactive, I get it. But many SPA's are used to give database-backed forms a pretty skin. It's the overuse of Javascript in this way, and the lack of graceful degradation for forms like this when Javascript is disabled, that I think is beginning to create concern.

Semiapies 10y ago

you should design your website to still be functional even if Javascript is disabled True, but irrelevant to the issue of "can you do X on the client side without Javascript?". I can imagine a Javascript form validator that somehow makes the form unusable with Javascript turned off, but I've sure never seen one. And server-side validation is website 101 stuff that you should always be doing regardless of the front-end technology, not a counter to the many good uses of front-end validation.

kelseydh 10y ago
I agree. Though sadly keeping your JS validation messages in sync with the ones your server produces can still be a surprisingly high amount of work and headache. Many people can think of the time it takes to build functionality like this as gold plating.