> and "keep scripts separate from your CSS and HTML markup"

was for documents, not interactive applications, with the goal being that a document could be reformatted through CSS for multiple different displays. The earliest example I can recall was web vs print (as in, in the browser go File -> Print; you can specific different CSS rules so the page prints differently than it shows in the browser). Screen size / mobile displays are other examples that came later.

React on the other hand is great for interactive applications, which have always worked component-style - a checkbox or a dropdown in a native GUI would be used multiple times and knows how to style itself, for example, which is the same as what a React checkbox or dropdown would do.

> "don't use inline styles"

This rule was broken simply because there wasn't a better way to do the component packaging at the time. Nowadays we have CSS Modules, which separates them again.

You've a function that returns JSX which is your HTML where you can use Javascript to reference functions/variables (e.g. the state variables)

One of the key parts is that you can break it all down into different files/functions that return jsx so you can isolate complicated parts

Before, I could call myself a "full stack dev" because I could cobble together a site with JS, but it wasn't pretty. It didn't follow any real conventions, was a nightmare to maintain, forget about testing, etc.

After learning React, I actually can design, and structure the code in a logical way. Testing is a lot simpler, code reuse makes sense... it created a mental framework on which I could translate my ideas into usable code that pattern matched to how I was used to building code for the backend.

I will never feel like I'm a "frontend dev", but I don't need to be. I can take an idea, and turn it into a functioning service, and isn't that all we're here to do anyway?