Ugh. I just don't get it. Am I just old and curmudgeonly? And what's with the 200+ line package.json. That's a helluva lot of tooling for a simple web app. GET OFF MY LAWN!
As for your biological linter- you will be surprised at how quickly you are able to get used to it. The key for me was to stop thinking of it as HTML or markup- because it isn't. It's really just a different way to call functions and create objects.
It's far better than handlebars or other template languages because it's an actual regular syntax that you can use a linter with so you know it's going to work as you intended.
I will say that I initially disliked the inline markup as well, but it honestly just makes practical sense. When we used Handlebars still, I always had the template open in a split when I was editing a view anyway, why not just keep it all as one contained unit?
For those of us who have been coding since before there was even JS, it's hard to let go of the Html / JS split but honestly, it's so much nicer when you just grab the React approach and run with it.
Yes for me too.
While making web applications with JEE and PHP for a decade, every best practice article on creating maintainable web apps told me to keep markup and logic different. That too in different files preferably in different folders like Controllers, Views, etc. Same for not mixing JS and CSS with HTML. And in practice it worked very well for me. So when I saw React's approach of putting JSX straight in JS code, I was thrown off a bit.
Even Angular 1.x felt wrong with adding nonstandard directives in plain HTML. Common wisdom before Angular was only to use standard HTML/XHTML that passes W3 Validator, then use JavaScript to enhance the page.
But then I just made peace with Angular and React way of doing things. If I want to get the benefits of the Angular/React eco system, then I need to use their approach, and still make sure that I produce maintainable code.
I have been told that .NET works in a similar way, but with a key difference of that diffing happening on the server, so it isn't as fast. This is just hearsay, please don't take my word for it, I don't claim to know how .NET works.
What's with that 200+ line package.json? That's like a makefile, with everything already configured for you. Sure, it's a lot of tooling, but you could say the same about most software development tooling. Why is XCode 4 gigs? That's a lot of libraries just to create simple mobile apps. Back in my day, all we needed was a tiny WML XML 200 byte file to display to a cell phone. And yet, here we are, in the future.
Perhaps you're thinking of components (or "controls" as they're known) in WebForms for .NET? They had a component style architecture but everything about them was difficult to understand and hard to use. Compared that to React where components are cheap and easy to build/compose, to such an extent that almost everything even things which don't actually render their own UI) ends up as components in React.
At the risk of getting long-winded, I like React, not because it is the best among its peers of JS view-layer libraries, but because it has an effective ecosystem that can give you a fairly consistent development experience in a somewhat narrow set of use cases.
To put it in more concrete terms, I see efforts like React Native as something that can give a single developer or a small team some reach into several different platforms with some reusability of the code base + tools + dev workflow, though none of the implementation will be the best-of-breed for any of the platforms (maybe with the exception of desktop web browser).
I could see many people disagreeing with it, and I could see myself being convinced by them, too. But really, it's something I've had easy enough time learning to use in production and made some parts of development work easier than the ball-of-mud feeling I had in the past using others, so I've found that to be a plus.
But I truly empathize with the red squiggly lines in the editors! :)
Yes