> why bother learning two paradigms
Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.
> why bother learning two paradigms
Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.
That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.
Yet I know roughly what it is, but I couldn't begin to actually write the stuff myself.
Good abstractions mean you don't have to worry about the layer below.
Now of course it's not really the case that React holds up to being a good abstraction, especially when it comes to CSS and styling, but I don't think it's a forgone conclusion that abstractions force you to learn the level below.
Otherwise we'd all spend half our time learning assembly.
I do have sympathy though for a developer who just wants to focus on the higher level paradigm and let the library maintainers worry about the innards.
React is an abstraction over UI state, not the platform (ie HTML/CSS). This is by design and non-parallel to C#/CLR case. If you want something akin to this, then Flutter is what you should be looking at.
> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.
For a good part of your career this is true, but eventually you will need to justify your senior salary by being able to debug react via looking at library code itself, or understanding the event bubbling under the hood, or figure out why the output css isn't working.
Saw a video, wish I could remember who, someone developing a game in c-something. There was some bug they couldn't figure out so they jumped into I guess the assembly for that block of higher abstracted code, and was able to find some kind of memory issue. Vague, sorry, but point is I remember being really impressed, thinking oh shit yeah if I really want to be an expert in my field I better be able to really understand my stack all the way to the bones.
> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.
That's not a valid analogy, 99.99% of C# developers never see or touch CLR bytecode, where every React developer is still working with HTML+CSS.
That's possibly true, but I wonder why react as an abstraction fails to deliver that kind of independence.
In theory, react developers ought to be able to code against the react API in typescript, without seeing the "raw" HTML+JS that gets delivered to the browser.
So what's failing those developers? Is it the tooling, the abstraction itself, or something else?
> So what's failing
You're failing to understand the difference between react and react-dom.
> be able to code against the react API in typescript
https://github.com/chentsulin/awesome-react-renderer
Off the top of my head, C# is both the language & the runtime. React only throws things over the fence to browsers.
Probably helps a lot to keep abstractions from leaking.
That seems like an odd take. I don’t know that anyone ever intended React to completely insulate you from the actual UI framework (HTML/CSS in this case). You’d have to reinvent a whole new set of layout and styling features. Why would you bother? React is for orchestrating your use of the UI framework, not for replacing it.
That just makes HTML/CSS part of the React paradigm though. You can still use all those features in a React app, after all. The 'new paradigm' to learn with HTMX is how it does reactivity/interactivity.
This featured article is about HTMX not HTML. Ofc everyone working in the FE should know HTML/CSS
honestly both the react haters & the htmx haters are wrong on this
if you care about have a solid UI, you should learn everything
you should learn css, react, svelte, vue, rails, tailwind, html
if you don't and you say you actually care about your UI, your opinion is actually irrelevant