[HN Gopher] Browsers, JSON, and FormData
___________________________________________________________________
Browsers, JSON, and FormData
Author : tannhaeuser
Score : 63 points
Date : 2022-11-10 09:49 UTC (2 days ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| mjburgess wrote:
| 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 wrote:
| 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.
| ctxc wrote:
| Meta: Plumbing and porcelain is the more popular pair.
|
| https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-
| Po...
| nonethewiser wrote:
| What is the plumbing and kitchen in this context?
| moritzwarhier wrote:
| Plumbing = DOM updates and events, and in the case of Web
| Components, Shadow DOM for scope isolation. Kitchen =
| Declarative way to define DOM structures depending on
| application state. Plus optionally some conventions around
| updating application state. What it boils down to is
| "components".
| mort96 wrote:
| 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 wrote:
| 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 wrote:
| 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!
| KronisLV wrote:
| > And now we have websites where clicking a link does
| nothing until a few seconds later the page content suddenly
| changes.
|
| Worse yet, sometimes people do "page" transitions in JS
| event handlers, which means that all of the sudden you no
| longer can ctrl/shift + click these UI elements to open up
| the page in a new tab/window, or even copy the link.
|
| Not that well made SPA solutions aren't pleasant to use,
| it's just that you can do all sorts of weird things that
| make using them miserable.
| capableweb wrote:
| I agree a lot of SPA implementations suck in the way you
| describe, just wanted to add that this was a issue before
| SPA navigation too.
|
| Some websites used iframes to render the main content,
| and kept navigation controls outside the iframe. So if
| you open a link in a new tab (or window, before tabs
| existed), you ended up on a page with just the content
| without the navigation.
|
| Some routers still use this way for page setup, for some
| reason.
|
| Shitty implementations will be shitty, no matter how you
| do it.
| brigandish wrote:
| I'd forgotten about those horrible iframes! It makes me
| wonder what other horrors I've left behind.
| solarkraft wrote:
| My health insurance provider has a website (seems mostly
| server rendered but with dynamic elements) that links
| documents that you can only access once (it seems).
| They're real links that will open a new tab when middle-
| clicked.
|
| ... but not of the document since the document is opened
| through some JS crap.
|
| Thank you, Techniker-Krankenkasse.
| mort96 wrote:
| Huh, I browse server rendered pages every day and
| rarely/never experience the page refresh flash.
| brigandish wrote:
| The internet was a lot slower 15/20 years ago.
| mort96 wrote:
| I'm not denying that it was accurate 15/20 years ago, I'm
| questioning whether it's accurate today.
|
| Maybe there's an argument to be made for it in developing
| countries, but in my experience, SPAs are way, way worse
| to use than SSR pages on slow devices and unreliable
| connections. Buttons are unresponsive for a minute as JS
| is downloaded and parsed and executed, content can't
| render incrementally, and the UI softlocks waiting for a
| failed or timed out API request. People don't seem to be
| making SPAs to benefit slow and unreliable devices and
| connections.
| brigandish wrote:
| I'm not arguing with you, I think most SPAs are
| unjustified, it's just that 15/20 years ago people really
| wanted to get rid of whole page refresh and all the
| problems that brings, which is a laudable aim, but has
| morphed into "why don't we make our own back button" and
| nonsense like that.
|
| The justification nowadays seems to be (in truth) "if you
| take away my tools I don't know how to build things so
| I'm going to run npm init and go from there".
| satyrnein wrote:
| And then pjax/Turbolinks attempted to address that more
| surgically, without giving up on server rendering.
| megaman821 wrote:
| All modern browsers hold the old page for a bit so there is
| no flash.
| lol768 wrote:
| 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 wrote:
| 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/
| lyptt wrote:
| See also: https://news.ycombinator.com/item?id=8664671
|
| Looks like supporting an enctype of application/json was
| proposed, but never went anywhere.
| Timwi wrote:
| 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?
| lyptt wrote:
| 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 wrote:
| 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.
| TheRealPomax wrote:
| 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.
| [deleted]
| Macha wrote:
| Honestly sounds more like an argument for adding a <form
| enctype="application/json"> to the standard to me
| sixbrx wrote:
| Together with allowing nested forms (finally), I think this
| would be great.
| TheRealPomax wrote:
| Forms are for sending data to URLs, what would the use-case
| of a nested form even be?
| Timwi wrote:
| Can't speak for the OP, but more than once I've run into a
| case where I need the form tags to be nested in the DOM,
| for reasons relating to the page structure but not the form
| contents. I would like nested form elements to just be
| allowed in the DOM, and if you submit the inner form then
| the outer should just be ignored, and if you submit the
| outer it should just submit all of the form values.
| rickstanley wrote:
| Today we have the form attribute [0] to alleviate some
| cases.
|
| [0]: https://caniuse.com/form-attribute
| TheRealPomax wrote:
| That sounds... confusing? What is the form supposed to do
| when you submit it if it has another form inside it but
| that form's values are... a separate form? Without a
| concrete use-case, I'm having a hard time understanding
| how this would make sense.
| artificialLimbs wrote:
| Would this not be a(nother) good use case for htmx?
| megaman821 wrote:
| Nested forms would be great if you could prefix the name
| attributes easily. Like filling out a form where it asks
| for your name and your spouse's name. Now the first name
| and last name keys are in the form twice.
| TheRealPomax wrote:
| Okay but that's a terrible example: lots of people _don
| 't_ have the same last name despite being married. So you
| better use separate fields for that if you want "last
| names". But of course, programmers famously have no idea
| what names are, resulting in a never ending stream of
| "why the fuck won't you let me use the name that I have?"
| for anything from ecommerce to government websites, so
| you really shouldn't even have a separate first and last
| name field, you should just have a "name" field, and it
| bloody well better support all of unicode, because the
| only person who can tell you what their name is, is the
| person filling out the field, not you as form designer =)
|
| [1] https://www.kalzumeus.com/2010/06/17/falsehoods-
| programmers-...
|
| [2] https://shinesolutions.com/2018/01/08/falsehoods-
| programmers...
| Waterluvian wrote:
| > 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.
| martin_drapeau wrote:
| 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.
| satyrnein wrote:
| Is this using Inertia.js? Did you consider Livewire?
| ithrow wrote:
| _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.
| _ZeD_ wrote:
| this... this is actually what we did in 199x, before
| xmlhttprequest. there's a reason we switched away from that.
| denton-scratch wrote:
| XMLHttpRequest is fine and groovy (if your user has Javascript
| enabled, of course). But why does everything have to be JSON?
| Kinrany wrote:
| 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.
| mort96 wrote:
| With a syntax that's ridiculously easy to write a parser
| and generator for (with the one exception of high unicode
| character escape sequences being encoded as two \uXXXX
| escapes after each other which form a surrogate pair rather
| than one \uXXXXXXXX escape, which is a bitch to deal with
| unless you use UTF-16 internally). It's certainly easier to
| write a mostly-correct JSON parser than an XML parser.
| artificialLimbs wrote:
| But why not just return hypermedia, assuming a web page?
| TheRealPomax wrote:
| 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.
| akira2501 wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-12 23:01 UTC)