HTMX may converse in form data requests and HTML responses, but for this article, eliminating JSON from form submissions is a means to eliminating JavaScript, not an end unto itself. HTMX still requires JavaScript.
Of course. I’m mentioning it, not because it avoids JavaScript, but because it encourages using form data (since one of the patterns with htmx to use the same form with and without JSON/JavaScript). Lots of JS frameworks bias you away from form data.
It seems I’m perpetually arguing with UI builders that if you have a form, use a <form> and not just a series of un-<label>’d <input> elements and doing that all with JavaScript. It’s a great progressive enhancement, but yeah, you shouldn’t require JS for something like this and even if you do, at least use the semantic, accessible elements.
That Remy Sharp quote’s taken a little out of context. He was complaining that Nuxt ships client-side JS that was out of proportion to the complexity of the web app he was building. Reading his article in full, he seems to be calling for moderation. That nuance seems to have been lost here.
My impression of the View Transitions API is that it’s intended to make building complex transitions easier. It certainly doesn’t eliminate JavaScript. Indeed, it won’t work without it.
Those are niggles, I suppose. Supporting JSON encoded forms without requiring JavaScript is an interesting idea. The converse idea—switching encodings server side to use form data instead of JSON—I read less generously. This sounds like treating JavaScript and its developers as weeds to be dried out by turning off the JSON spigot.
Would love this to be the ideal, but I think the war was lost a long time ago. I think it’s reasonable to expect (when developing a greenfield site) that users are probably going to have Javascript enabled. So why bother investing the engineering effort for those that don’t?
You don’t have to fold to trends. You can use HTML form, Vim, Perl, Firefox, etc. Even if culture tells you “it’s the wrong way/not the future/not perfectly compatible”. You’ll probably find their way often leads to the same place or nowhere at all.
If you stop viewing tech choices as a war that’s won/lost then you will become a stronger advocate for understanding the world around you and it’s many options instead of an advocate for Visual Studio Code and it’s way (for example).
So why bother investing the engineering effort for those that don’t?
Non-JS users and JS users can use HTML forms. Non-JS users can’t use JS. Why bother investing the engineering effort for those that do have JS enabled?
I wrote a little Python library to address the problem of a server endpoint that mostly works with JavaScript but that you want to be able to call using a regular HTML form with form encoded data: https://github.com/simonw/json-flatten
Coming from the PHP world the “forms as JSON” was always the exception. Working a lot more in Node these days and I am seeing the amount of workarounds to serialize form data as a JSON payload. I think APIs should be supportive of both content-types especially if you know for sure there will be an HTML form that sends data to your endpoints.
The server code should be able to determine the content type and work different methods for parsing data so I don’t see this as being too much overhead. I also like the proposal of being able to have the browser POST form data as JSON as per an HTML attribute or something.
Except that most form submissions respond with errors or a redirect.
I agree with the principles of the argument which is why I’ve been spending more time looking at htmx.
HTMX may converse in form data requests and HTML responses, but for this article, eliminating JSON from form submissions is a means to eliminating JavaScript, not an end unto itself. HTMX still requires JavaScript.
Of course. I’m mentioning it, not because it avoids JavaScript, but because it encourages using form data (since one of the patterns with htmx to use the same form with and without JSON/JavaScript). Lots of JS frameworks bias you away from form data.
It seems I’m perpetually arguing with UI builders that if you have a form, use a
<form>and not just a series of un-<label>’d<input>elements and doing that all with JavaScript. It’s a great progressive enhancement, but yeah, you shouldn’t require JS for something like this and even if you do, at least use the semantic, accessible elements.That Remy Sharp quote’s taken a little out of context. He was complaining that Nuxt ships client-side JS that was out of proportion to the complexity of the web app he was building. Reading his article in full, he seems to be calling for moderation. That nuance seems to have been lost here.
My impression of the View Transitions API is that it’s intended to make building complex transitions easier. It certainly doesn’t eliminate JavaScript. Indeed, it won’t work without it.
Those are niggles, I suppose. Supporting JSON encoded forms without requiring JavaScript is an interesting idea. The converse idea—switching encodings server side to use form data instead of JSON—I read less generously. This sounds like treating JavaScript and its developers as weeds to be dried out by turning off the JSON spigot.
Would love this to be the ideal, but I think the war was lost a long time ago. I think it’s reasonable to expect (when developing a greenfield site) that users are probably going to have Javascript enabled. So why bother investing the engineering effort for those that don’t?
To be the change we wish to see in the world.
You don’t have to fold to trends. You can use HTML form, Vim, Perl, Firefox, etc. Even if culture tells you “it’s the wrong way/not the future/not perfectly compatible”. You’ll probably find their way often leads to the same place or nowhere at all.
If you stop viewing tech choices as a war that’s won/lost then you will become a stronger advocate for understanding the world around you and it’s many options instead of an advocate for Visual Studio Code and it’s way (for example).
Non-JS users and JS users can use HTML forms. Non-JS users can’t use JS. Why bother investing the engineering effort for those that do have JS enabled?
I wrote a little Python library to address the problem of a server endpoint that mostly works with JavaScript but that you want to be able to call using a regular HTML form with form encoded data: https://github.com/simonw/json-flatten
Coming from the PHP world the “forms as JSON” was always the exception. Working a lot more in Node these days and I am seeing the amount of workarounds to serialize form data as a JSON payload. I think APIs should be supportive of both content-types especially if you know for sure there will be an HTML form that sends data to your endpoints.
The server code should be able to determine the content type and work different methods for parsing data so I don’t see this as being too much overhead. I also like the proposal of being able to have the browser POST form data as JSON as per an HTML attribute or something.