Browsers, JSON, and FormData

[mjburgess]

There's a lot of value in modern browsers asking "what are all these JS frameworks providing?" and providing primitives for the top 20% of features natively.

The existence of JS frameworks to build apps, in this sense, I think can be seen as a browser failure. The browser exists to provide a GUI for HTTP, and it's failing to provide "the common default" we now expect.

[TheRealPomax]

They tried, but made the mistake of stopping once the low-level stuff was done. Welcome to Webcomponents, it can do what you currently use Angular, Vue, or React for, but it only covers the plumbing, not the actual kitchen itself, so you either have to write your own kitchen, try to mimic the kitchens that vue/angular/react/etc already made, or use a kitchen made by someone else and hope that does everything you needed.

Which is an unfortunate side-effect of the whole "JS is about giving people APIs to make things with, not dictate what those things are" philosophy. In this specific case, that leads to APIs that technically cover the needs, while also offering exactly nothing that people can "just use" for writing UIs that are natively understood by the browser.

[Macha]

Honestly sounds more like an argument for adding a <form enctype="application/json"> to the standard to me

[sixbrx]

Together with allowing nested forms (finally), I think this would be great.

[mort96]

The quote in the beginning seems ridiculous on its face. I've heard a lot of reasons why people choose SPAs, and "I can make a transition animation between pages" is never it. In fact, almost no SPAs I've used have transition animations between pages.

[brigandish]

I believe "swish transitions" refers to the lack of the page refresh flash, which really was one of the initial attractions to SPAs when they first came to prominence.

[lyptt]

See also: https://news.ycombinator.com/item?id=8664671

Looks like supporting an enctype of application/json was proposed, but never went anywhere.

[mjepronk]

Personally, I don't like the use of indexing to determine the JSON structure (like this `<input name="foo[0][1]">`). I think it's way more powerful to derive the JSON structure from the DOM tree. That's why I wrote some code to do exactly that: https://gist.github.com/mjepronk/5b33eaa90ecf11a5c2c47935a2c...

The use of `<fieldset>` and `<section>` may not be the best choice. You could use `data-` attributes on arbitrary tags for instance.

[Timwi]

As someone who doesn't follow the standardization process, I would love an explanation how proposals like this fail even when they have widespread support and no downsides. Is there an easy answer to this or is it different from case to case?

[martin_drapeau]

I wish front-end developers would use the right tool for the right situation. Not everything is a nail!

Forms are a great example. Browsers and back-end languages have supported those very well for a long time without the use of JavaScript.

Routing is another thing browsers and back-end languages do very well.

The SaaS we are building is in Laravel + Vue. Laravel has a powerful validation engine and top notch routing and session management. We leverage those 100%.

Vue shines for user interaction. Instead of a single SPA, we usually have one per rendered page (i.e. User Interface). Works very well.

I haven't found any downside to this approach vs a full-blown SPA. Only benefits.

[ithrow]

Vue shines for user interaction. Instead of a single SPA, we usually have one per rendered page (i.e. User Interface). Works very well.

That means you have to parse all the JS on every rendered page.

[satyrnein]

Is this using Inertia.js? Did you consider Livewire?

[Waterluvian]

> A big impediment to moving away from SPAs is that we’ve collectively spent years building up an entire infrastructure of backend services which power the internet by communicating with browsers in JSON

Something I like about Django/DRF (and likely many others I haven’t used) is that it makes the above an imaginary problem. Django trivializes accepting form or Json or xml or whatnot. It just wants a Python object after deserialization and usually you can get a few of those formats for free, or otherwise very little work.

[TheRealPomax]

This really strikes me as a shining example of "porque no los dos":

  "So many third-party services have APIs you can integrate with and guess what? They probably speak JSON exclusively. But browsers don’t send user-entered data as JSON by default, so what’s one to do? You can:
  
  "1. Create a URL that accepts the structure of a default browser POST request (<form method="post" action="/my-url">).
  
  "2. Throw progressive enhancement out the door, expect JavaScript to work for all your users, and drop a <script> tag on the page somewhere that handles the logic to submit a JSON payload to whatever service will store this information for you."

No, you do both: you create a server route that accepts that form's POST (or PUT or DELETE or whatever) and you write the code necessary to intercept the form's submit event and runs that same post operation backed by a Fetch request instead, then work the result into the page without needing the navigation action that a bare form uses. Congrats: your site now works both with limited-to-no JS, and as progressive web page when JS is fully available. All you had to do was stick with the basics: have a restful server.

[nsonha]

Summary: article complains that JSON has a monopoly as the transport for web apps, they think the transport should be... HTML, you know the thing that doesn't know if it wants to be a programming language or a document mark-up, the thing with like a gazillion tags, none of which is about your domain. Hey what about GRPC, websocket... aka real transports?

[akira2501]

Often, I'm going to have to be trucking an OAuth token around to make this API work and I'm going to want to respond to expired tokens and other exceptions in a rational way for the users benefit. Further, having History State and Custom Validation at my disposal are great tools to use when designing anything other than very simple forms.

I'm not sure javascript should be seen as a burden here.

[lol768]

People rely on browsers not being able to POST a JSON body to a (cross-origin) API to prevent cross-site request forgery.

Maybe this is obsolete in a SameSite=Lax by default world, but simply allowing browsers to support a JSON enctype has consequences that need to be carefully thought through.

If you wanted browsers to do this properly, you'd probably need to send a pre-flight?

[mro_name]

this asymmetry between html form post to binary dump wire format bugged me a lot. So I made glue to convert formdata dumps back to html forms (which then can be processed with standard xml tools or viewed as is): https://code.mro.name/mro/form2xml

Works like a charm in e.g. https://mro.name/2021/ocaml-stickers/

[_ZeD_]

this... this is actually what we did in 199x, before xmlhttprequest. there's a reason we switched away from that.

[denton-scratch]

XMLHttpRequest is fine and groovy (if your user has Javascript enabled, of course). But why does everything have to be JSON?