That's really false. The type coercion matrix does make sense for the job it is supposed to accomplish, even if you personally don't agree with it for whatever your reasons are.
If you haven't seen the info presented like this before, then I can understand why Javascript might seem "CRAZY" after reading so many blog posts by people who like to complain for clicks. If you think this chart doesn't have any "rhyme or reason", then please explain why.
>single threaded nature makes it gunk up browsers crazy quickly
That's one way to look at it. Another way is to learn how to work with the system you have, not the system you want. Improvements to the system can be slow, and can't be breaking changes. This is true about every system humans have ever devised.
Webworkers are great, you can absolutely do multi-threaded Javascript, I've done it, it was easy. If that solves the problem in a reasonable amount of time, great, if not then I'll probably do it in C and run it from Javascript since it's so easy to write the rest of the application with Javascript.
Not everything needs maximum performance. For some embedded systems I usually write 100% assembly language because every byte and clock cycle matters. But I know all of this really well, so maybe it seems easy for me. When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges. But today? Naaa. It's easy, it's got a huge support system, a lot of progressive enhancements, thousands of videos, millions of developers and about a billion blog posts on medium.com.
I switch back and forth from C to Javascript and it's a great combination. Less context switching, the syntax close to 1:1 as far as I'm concerned. But C is a pain in the ass in comparison to Javascript, and I know both languages extremely well. I've been writing software almost 50 years.
>the insane bloat of "frameworks"
I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
I have complex front-ends running "at web scale" based on jQuery (for business reasons). We decide every byte that gets included, and manage to score 100% on all page speed tests. No bloat.
>which attempt to completely replace already great APIs,
Citation needed.
> IS CRAZY!
People have been using Javascript successfully for decades. Sorry Javascript isn't your favorite language, but it's not as you describe it either.
> When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges
Best bug I saw there was how it would sometimes just...give up on running JS if you held it wrong (probably a Netscape thing) and you had to figure out why.
> I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
50KB sent to the client in total? What UI libraries do you use? Happy to try out things; I'm currently a fan of Svelte but haven't tried Preact yet.
I started the project with create-react-app a long time ago. I've since updated it to latest versions of webpack and switched from React to Preact. It's not using any hooks or any modern React conventions, but I don't really need it. I've kept it simple, the only two libraries I include are preact-easy-state and preact-router. Everything else is components I wrote. All images used are SVG, I'm using LESS to compile to CSS, and everything is bundled into a single HTML file that gets gzipped down to about 48KB. I've tweaked the default Webpack configs to get exactly the payload I want. This gets compiled into my ESP32 firmware and served directly from flash. The web app handles all devices configs as well as wifi access point config, and it controls all kinds of device functions using custom sliders and buttons, etc.
That's really false. The type coercion matrix does make sense for the job it is supposed to accomplish, even if you personally don't agree with it for whatever your reasons are.
https://media.geeksforgeeks.org/wp-content/uploads/advanced-...
If you haven't seen the info presented like this before, then I can understand why Javascript might seem "CRAZY" after reading so many blog posts by people who like to complain for clicks. If you think this chart doesn't have any "rhyme or reason", then please explain why.
>single threaded nature makes it gunk up browsers crazy quickly
That's one way to look at it. Another way is to learn how to work with the system you have, not the system you want. Improvements to the system can be slow, and can't be breaking changes. This is true about every system humans have ever devised.
Webworkers are great, you can absolutely do multi-threaded Javascript, I've done it, it was easy. If that solves the problem in a reasonable amount of time, great, if not then I'll probably do it in C and run it from Javascript since it's so easy to write the rest of the application with Javascript.
Not everything needs maximum performance. For some embedded systems I usually write 100% assembly language because every byte and clock cycle matters. But I know all of this really well, so maybe it seems easy for me. When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges. But today? Naaa. It's easy, it's got a huge support system, a lot of progressive enhancements, thousands of videos, millions of developers and about a billion blog posts on medium.com.
I switch back and forth from C to Javascript and it's a great combination. Less context switching, the syntax close to 1:1 as far as I'm concerned. But C is a pain in the ass in comparison to Javascript, and I know both languages extremely well. I've been writing software almost 50 years.
>the insane bloat of "frameworks"
I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
I have complex front-ends running "at web scale" based on jQuery (for business reasons). We decide every byte that gets included, and manage to score 100% on all page speed tests. No bloat.
>which attempt to completely replace already great APIs,
Citation needed.
> IS CRAZY!
People have been using Javascript successfully for decades. Sorry Javascript isn't your favorite language, but it's not as you describe it either.