[bob1029]

How many distinct aspects of your product actually require asynchronous submission of form data?

A little bit of javascript/AJAX/etc is perfectly acceptable. We didn't get 100% of the way there with multipart/form because iOS/Safari exists and will crash hard if you try to post big forms.

You don't need ReactJS to submit a user input and avoid a page load. This is ~20 lines of vanilla javascript.

[chrismorgan]

> iOS/Safari exists and will crash hard if you try to post big forms.

I find things like https://stackoverflow.com/questions/10195459/ios-safari-cras... and https://bugs.webkit.org/show_bug.cgi?id=84168, from 2012. Is that still an issue? I find it difficult to imagine you could have a bug that prevents you from submitting a form with even half a megabyte of data being allowed to last for long.

[bob1029]

> I find things like https://stackoverflow.com/questions/10195459/ios-safari-cras... and https://bugs.webkit.org/show_bug.cgi?id=84168, from 2012. Is that still an issue?

Yes. It is 100% still an issue. That is the exact bug I was looking at. I can get Safari on my latest gen iPad to crash hard after only 3 submissions pretty much every time. We are sending large images in our forms but it's only like 1-5 megabytes.

[chrismorgan]

Wow. That’s bonkers. That’s not even large images, that’s just regular photos. Upload a few photos the traditional way and your browser crashes? In 2024? Madness.

(I guess the size threshold has increased as device memory has increased.)

[bob1029]

The whole experience has been like discovering a dead canary in a coal mine.

This tells me that very few developers are doing things "the old" way or otherwise questioning mainstream technology narratives.

I sometimes find myself wondering if multipart/form is going to be deprecated soon. If you look at the latest Azure Function isolated worker stack, this hasn't even been dealt with yet. I had to grab a 3rd party library to parse these submissions out of my request bodies.

If you have a fancy web socket use case, no problem - we got your back. Want to build a boring LOB business app? Better be ready to start shimming those HTTP post mechanisms.

[chrismorgan]

I have certainly found myself surprised at times in the last decade or more when frameworks and similar have simply not supported multipart/form-data for a long time, given that it’s the only way you can use <input type=file> (since it needs to convey the file name as well, as a header on the part; application/x-www-form-urlencoded has no way of conveying that).

[selalipop]

It's not just about web requests: Small things like the select that reflects various font choices correctly, consistently styling form elements as deeply as the site does, the live updating rich formatting inside the main input (shockingly annoying to deal with, even with React), the per-word fade-in effects for text with memoization and other state-dependent optimizations since Chrome chokes on too many spans, handling accessibility for all of these little pieces...

There'd be a lot of "just a little bit of vanilla Javascript and CSS" sprinkled all over that'd all need to have state managed in a manual way that wouldn't be a meaningful improvement over React.

Like I said, I'm working on something where seemingly minute UI/UX details matter to the target user. So I can't just say "CSS and Vanilla JS don't support that without pulling teeth, it's a small thing, so I'm going to ignore it". Sometimes that's going to be a valid strategy and sometimes it's not.