Browsers, JSON, and FormData

https://blog.jim-nielsen.com/2022/browsers-json-formdata/

by tannhaeuser • 4 years ago

68 52 4 years ago

akira2501• 4 years ago

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.

mort964• 4 years ago

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.

brigandish4• 4 years ago

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.

eurasiantiger• 4 years ago

And now we have websites where clicking a link does nothing until a few seconds later the page content suddenly changes.

If you’re lucky, the page will scroll to the top as well!

mort964• 4 years ago

Huh, I browse server rendered pages every day and rarely/never experience the page refresh flash.

satyrnein2• 4 years ago

And then pjax/Turbolinks attempted to address that more surgically, without giving up on server rendering.

megaman8213• 4 years ago

All modern browsers hold the old page for a bit so there is no flash.

_ZeD_• 4 years ago

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

denton-scratch2• 4 years ago

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

Kinrany2• 4 years ago

JSON is close to using the most fundamental logical primitives needed to structure serialized data. It's a set of value types, an ordered collection and a key-value collection.

TheRealPomax7• 4 years ago

Because it is a vast improvement over XML, the thing that XMLHttpRequest was designed to be used for. It was supposed to be an http request for a DTD'd XML asset, and thank god we stopped using it for that and went "no that's okay, it doesn't enforce XML compliance, we'll use it for any text content we want, thanks".

Which of course turned out to be incredibly dangerous when that text is (or is derived from) user-generated content, and that's where JSON comes in: JSON is a true data format, instantly turned into the native object that you can work with in the programming language that browser already has to speak in order to be considered a real browser. In stark contrast to XML, which ironically can't be turned into a data object, it can only be turned into a full fledged, separate document that you then need to use additional APIs for in order to extract data from.

XMLHttpRequest was a bad idea that worked because it was also the best option because it was the only option. Thank goodness we moved on.

Macha• 4 years ago

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

sixbrx• 4 years ago

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

TheRealPomax7• 4 years ago

Forms are for sending data to URLs, what would the use-case of a nested form even be?

mjburgess• 4 years ago

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.

TheRealPomax7• 4 years ago

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.

nonethewiser• 4 years ago

What is the plumbing and kitchen in this context?

ctxc• 4 years ago

Meta: Plumbing and porcelain is the more popular pair.

https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

lyptt2• 4 years ago

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

Timwi2• 4 years ago

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?

lyptt2• 4 years ago

From what I've seen, standards need to be picked up by browser vendors for them to become established.

Usually one vendor will implement it behind a flag, and if it gains traction then other vendors will follow suit before it becomes a generally available feature.

mjepronk• 4 years ago

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.

martin_drapeau• 4 years ago

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.

satyrnein2• 4 years ago

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

ithrow• 4 years ago

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.

TheRealPomax7• 4 years ago

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.

mro_name• 4 years ago

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/

lol768• 4 years ago

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?

Waterluvian• 4 years ago

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.

nsonha• 4 years ago

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?

Browsers, JSON, and FormData

Related Stories