What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!
> That's what the C devs said about all the people learning Java.
That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions!
We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.
> but for me it's a really wide list of items and not a very tall stack.
That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba.
Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.
I meant to constrain my comment to the web development sphere. Niche cases mean some scenarios where bandwidth limitations prevent the use of React or something.
Although you can use React for mobile (Native) and desktop (Electron)
I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.
Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ...
... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.
So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.
I did get a $1k security bounty from Google, though, so that was cool.
And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.
It literally does, unless you have the form POST or GET to an API directly + a redirect from the API.
You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.
You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever.
You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever).
Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.
Also, per the form libraries question: Formik and React Final Form are the two standard packages I suggest folks look at. React Hook Form seems to be gaining some popularity. Also, I recently ran across https://github.com/wsmd/react-use-form-state and tried it in one of my own projects, and was pretty impressed with it as a lightweight option.
It's sad how convoluted something as simple as form submission has become with "modern" Javascript frameworks. I'm not sure if it is React's fault, or the way most people use it, but it does seem to degrade into a mess of over-complexity. (I've been working on web sites since CGI scripts were a thing.)
Its as simple or as complex as you make it, you can use react to render a perfectly plain html form or you can manage it totally in react. And honestly, once you have everything set up and some previous examples, managing and submitting forms in react is trivial as well.
> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
Show me the HTML standard that supports SPA submissions that don't reload the page.
It seems that your problem is about SPAs, not React.
That was a thing even before AJAX came along, eg via forms targetting an iframe.
A long time ago, I wrote a single-page chat application that continuously updated through chunked transfers, with submission via a plain old HTML form that received a 204 response.
IMO, it's kinda hard not to end up learning those things even if you are in react all day.
At one point or another things don't work and it's because of simple HTML... and not react.
Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.
"We are raising a cohort of developers who knows nothing about memory management."
Sure, there are things you do not know if all you know is React, but technological changes make it irrelevant in all but the most niche of cases.