Frontend developers can barely be arsed to read the short React docs once a year to catch up on any updates.

There is no way in hell we're going to be able to function in an industry with thousand page data sheets and programming manuals.

Lol, I know that people like to joke around that frontend engineers are dumb, but this is just unnecessary.

It's obviously exaggerated and reductive, but you have to admit that not knowing how to use React properly is massively prevalent in frontend, let alone being able to recognize _when_ to use React.

I daresay that not knowing how to use React is even more prevalent outside of frontend.

Most FE engineers I know have a very deep understanding of react’s inter workings. It’s the full stack engineers that think it’s JS with extra HTML sauce and call it a day.

>with thousand page data sheets and programming manuals.

Why aren't those just a library? There is no way everyone deplicates the same work for interfacing with a chip for every single project that wants to use it.

There are plenty of libraries: from low level hardware abstraction layers to high level libraries like you'd find in the Arduino ecosystem. Those closer to the former (the HALs) require more understanding thus more reading, the latter expose less of the power of the chip because they target the least common denominator.

However, when you're making a mass produced piece of hardware with a $10 BOM cost and it turns out that you can save even 25 cents by using 90% of the power of a cheap chip instead of 5% of the power of an expensive chip, you're going to have to dive down into the documentation to figure out how to get every last ounce of processing power out of the cheaper chip.

That usually means exploiting the unique configuration of peripherals on a chip which can't be cleanly abstracted away by a software library. My first few projects, for example, I had to work around silicon errata in the family of chips the projects had chosen: STM32F4s couldn't run both DMA channels simultaneously at max speed when outputting to different peripherals. I wouldn't have been able to figure out what's going wrong at any level of abstraction without reading the documentation.

That's why I'm now in frontend instead of embedded.

There are many libraries, but the peripherals on modern microcontrollers are wildly configurable and the odds of any particular library supporting every single mode possible is essentially nil. And even if it did, then the library documentation would approach the chip documentation in terms of complexity.

And it may be a foolish one because that ocean is filled with sea monsters that even TS can’t tame.

I’d rather say plankton than sea monsters.

I’ve never seen plankton sink a ship or halve its performance but sure. One can only take a metaphor so far.

Rust (or Zig) is a much better pathway for a "user friendly" language on embedded devices than JavaScript of all things.

And developers love Rust, advertise a job for an embedded Rust developer and you'll need to build a moat to keep the hordes out.

My best guess would be that Rust developers skew away from UI and interaction expertise.

And remains a dream far away from reality.