I thought the same thing.

I was once discussing a third-party integration with a React developer. The integration required that our app POST a couple of fields to the third-party's site. I found that the developer was struggling with the integration and they were asking me questions about it when I said something to them along the lines of "It's just an HTML form, with a couple of hidden inputs that when submitted make a POST request to this URL" they said to me "Yeah, well HTML is kinda old, it's not really used anymore"...

I'm sure I've said plenty of stupid things when I was green but I hope no one remembers them like I remember this one. It lives rent free in my head.

It's definitely true that many developers would benefit a lot from learning more about the basic HTML and the web platform. But I refuse to support the notion that this is somehow React's fault.

In my personal experience, react allowed me to rely more on the native web platform APIs, not less, than other frameworks (at the time that I switched to react)

> they said to me "Yeah, well HTML is kinda old, it's not really used anymore"...

> I'm sure I've said plenty of stupid things when I was green but I hope no one remembers them like I remember this one. It lives rent free in my head.

I'm doing gigging while my product is gaining traction. Last week, I received this verbatim rejection for a PR review at a client, who's oldest developer is 27:

"No, we don't want all the logic in the same place. You must split the logic up"

This is also one that will take up valuable space in my head till the end of time :-(

(PS. Yes, I split the logic so that it was evenly balanced in 3 different programming languages, instead of having the entire logic in C# alone)

The confusion in the article is so complete that I'm left wondering whether or not the author is aware that what they are writing is not, in fact, HTML.

Yeah, I am aware! Thank you for the concern :) I did address this in an adjacent comment, but I'll say again that I did contemplate over using JSX or not. Also yes, it may have been a good idea to add a disclaimer for the fact that the code I'm showing is JSX, but honestly there are so many other disclaimers I had in mind, all of them together would make the article twice as long and much more boring

It's exacerbated by the fact that the API they propose to make custom validation more ergonomic works for React, but would be much worse for plain Javascript and HTML.

The API I'm proposing would indeed bring much more benefit when used in a declarative way. That's the point I'm specifically trying to convey in the article.

I don't think I understand how it would be "worse" for plain JS and HTML though. Would love to hear your thoughts.

Actually, there is one possible concern. When HTML is returned by the server includes inputs with set "custom-validity" attributes and this HTML gets open by a browser with no javascript enabled, this would make the input "stuck" in an invalid state. This is an important edge case to consider but I do believe there is a resolution that would satisfy everyone

In plain HTML, you can't do:

  custom-validity={value.length ? "Fill out this field" : ""}

you can only use a static string for an attribute. So you'd need an event handler to set custom-validity from javascript when the input value changes, then a handler to setCustomValidity when custom-validity changes.

In other words, it's the same exact imperitive interface as setCustomValidity, except with an extra layer and the extra event handling has to be implmented along with it.

If I had a say, I'd go for an interface where custom-validation would take a javascript function name, and that function would take the value as input and optionally return a string with a validity message. Or it takes a javascript snippet like onclick, except one which returns an optional string value. Then again, there wouldn't be much difference from onchange.

Edit: to counterbalance some of the criticism, I think the article is very nicely written and formatted, and the interactive components are a good touch.

Sorry to disappoint, I did hesitate over this. But JSX is honestly very nice to read and also I didn't want to leave the impression that opting in to native form validation somehow forces you to not use javascript. And combination of javascript + html is, again, very nicely expressed with JSX.

The concepts are obviously easily translated to other component frameworks, but they also do apply to pure HTML and vanilla javascript.

The problem I am highlighting in the article is the absence of a declarative nature to the Custom Validity API, so I think it makes sense to use a declarative component approach in code examples