App Should Have Been a Website (and Probably Your Game Too)

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.

Native apps are sticky. As an example a Webshop has no reason to have a native app (likely it is a browser wrapper anyway).

However, being installed puts you right in front of the users noses everytime the unlock the phone. Just look at the discounts that are offered for installing Native apps or shops that are app only to begin with.

Very constructive, thank you.

I'm talking about the defaults of HTML. There's no pit of success, just lots of div-wrapping and tweaking until things fall into place. Compare with SwiftUI, where you plop two controls and they're spaced sensibly from one another without you doing anything. This was also the case in VB6.

> And then there's another person who didn't take the time to learn JS and just hates it for reasons.

I've been writing TS for awhile now, it's mostly fine. Should've expanded further: npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."

> Show me a native app with a polished UI and any useful functionality in only 50-100loc.

I'll concede that. At 50-100loc, you can have a decent looking native app for a simple task. Presentation layer for a webapp blows through that immediately. Some of that is accepting the medium as is and learning to work with it. Some of it is also the fundamental impedance mismatch of the web writ documents/apps.