4 ms·

Most site interactivity could be handled with forms (though some form inputs need improvement) or some sort of conditional view state (for menus and HN's collap

Most site interactivity could be handled with forms (though some form inputs need improvement) or some sort of conditional view state (for menus and HN's collapse comment feature). For anything more complex I think the "click to enable" model that flash and applets eventually followed is compatible with anything that actually deserves custom code.

ComputerGuru 7y ago
I’ve given this a lot of thought over the years and I think html needs slightly more functionality to completely obviate JS. The hardest impact of no JS is dynamic input forms, and I remember when ajax first became a thing and forms that didn’t lose their content on an input error became commonplace. There was never a good reason for them to lose their input, of course, as that’s just lazy coding. But when writing JS-free front ends for my web apps, the ugliest UX is trying to fill out a form that requires either filling out n identical sections (eg a fieldset for each student you want to add) or selecting an item from a drop-down w/ the option of adding to it if the desired option doesn’t exist. Error validation is now clean and easy with modern MVC frameworks that take as input the same structure of data they used to generate the page in the first place, so it is easy to rebuild the page exactly as it was but also include an error message. There is no jarring user experience when the page is submitted and reloaded with the error shown inline. But having to navigate to a separate page to add an entity then refresh the form to fill out the data selecting the newly added entity sucks. HTML needs some sort of functionality that would enable a) dynamic non-Turing-complete remote resource backing of form input values, b) allowing a form input to return post submission to a dom element rather than a document (E.g. imagine an input to “add location” to a drop down; submitting that field would return the new content of the select option elements to replace the existing). A JS powered example is intercooler JS. More generally, a content response type that says “patch the existing DOM with the following” would preserve pretty much all the good parts of Web 2.0 without the crap that came with it; keeping in mind that submissions could only happen when a user explicitly requested them.

ComputerGuru 7y ago

I’ve given this a lot of thought over the years and I think html needs slightly more functionality to completely obviate JS. The hardest impact of no JS is dynamic input forms, and I remember when ajax first became a thing and forms that didn’t lose their content on an input error became commonplace. There was never a good reason for them to lose their input, of course, as that’s just lazy coding. But when writing JS-free front ends for my web apps, the ugliest UX is trying to fill out a form that requires either filling out n identical sections (eg a fieldset for each student you want to add) or selecting an item from a drop-down w/ the option of adding to it if the desired option doesn’t exist. Error validation is now clean and easy with modern MVC frameworks that take as input the same structure of data they used to generate the page in the first place, so it is easy to rebuild the page exactly as it was but also include an error message. There is no jarring user experience when the page is submitted and reloaded with the error shown inline. But having to navigate to a separate page to add an entity then refresh the form to fill out the data selecting the newly added entity sucks. HTML needs some sort of functionality that would enable a) dynamic non-Turing-complete remote resource backing of form input values, b) allowing a form input to return post submission to a dom element rather than a document (E.g. imagine an input to “add location” to a drop down; submitting that field would return the new content of the select option elements to replace the existing). A JS powered example is intercooler JS. More generally, a content response type that says “patch the existing DOM with the following” would preserve pretty much all the good parts of Web 2.0 without the crap that came with it; keeping in mind that submissions could only happen when a user explicitly requested them.