[flagged]
You can certainly do a lot with JavaScript and there's a massive echo system around it. But that doesn't mean it's good.
Which other languages work comparably well in the browser, with similar functionality but without large runtime / standard library downloads?
Deno is one of the pioneering projects (via https://fresh.deno.dev/) pushing SSR to the maximum so we don't need MBs to render DOM elements... unless you know, you want any sort of interactivity which every single client-facing SaaS app ends up needing (for which hydrated 'islands' are used only when necessary).
Unless you remove the need for desktop-style interactivity on the internet JS is never going away. Maybe WASM will help here (w/ even worse Web standards), but I could reverse your same critique and point at all the horror-show UIs backend devs have built using backend-style code.
I don't personally use JS server-side but I get why people do and it's not the language/runtimes making apps slow. Backend JS adoption is heavily informed by the dominance of JS on the client side, ease of hiring, and an effort to keep data structures DRY.
> Enough of OOP that has horrible.
OOP is not a requirement in JS and I rarely see it being used heavily these days. Nothing like Java or some awful Ruby projects I've seen.
Everyone acts like there was no reason why people started adding Javascript to webpages. Whole swaths of the entire developer community just fell into because they were dumb.
If static pages alone could accomplish what people wanted from the internet they would have figured it out a decade+ ago. Now the industry is shifting to delivering the same level of functionality with the bare minimum of JS on-page. Yet people act like it's all the same.
Probably because they've never actually used any of these modern high-performance desktop-tier web apps like https://linear.app
Yes. I believe desktop.com was launched in the late 90s, so well over 20 years ago.
https://web.archive.org/web/20021217213351/https://www.inter...
> Now the industry is shifting to delivering the same level of functionality with the bare minimum of JS on-page. Yet people act like it's all the same.
It mostly is. Best practice was never to avoid JavaScript, that was just a caricature repeated by bad JavaScript developers. Best practice was to start with a solid foundation that worked for everybody and add on the interactivity as an optional extra. All the best JavaScript developers of the time were writing stuff that was client-side interactive but was still primarily server-driven.
This is very important. Take rails for example, modern projects have `/app/views` for ERB templates and `/app/javascript` for the React/Vue views. It's natural for frontend teams to push more and more stuff into `/app/javascript` instead of the static `/app/views`. Because the JS frontend is where the highend-CSS tooling/clean reusable component libraries/high quality UI testing libraries/etc/etc live.
Sure you could be extremely careful and divide the two. But in practice it's much harder than it sounds. You're basically running two different frontends.
Having the components that compose the views simply be a single SSR (y/n) checkbox is far better AND even when it's not SSR it still renders static in the UI instantly, then hydrates in the background. So no vDOM loading time. We've never had anything like that before for high-functionality JS views.
And it goes beyond that too. Linear has made tons of innovation in how data is synced with the UIs + offline support. see:
https://replicache.dev/ <- static HTML offers none of this sort of fully offline cached data performance + realtime syncing UIs
You can drop into WASM to get more speed without performance cliffs, or for Deno itself, they use Rust.
Even if we get to a place where wasm performs much better than javascript, javascript will remain dominant due to the fact that it's the default. It is what it is, we're stuck with it short of something like AI changing everything.
Yes there are still areas of JavaScript that suck, e.g. the whole prototype system, and the standard library (how they managed to fuck up String.replaceAll() is anyone's guess), but the overall package is actually pretty good!
Way better than Python for example (though that isn't saying much).
But there are alternatives. I would reach for Go. I’m not great at it but good enough that I know I can code up a server. And I know it will be be stable and simple to deploy - upload the binary and run it via systemd.
Your username is "msie." Do you remember what Microsoft Internet Explorer 6 did to the web?
So if someone likes the current version of Dart then rejection by the browser might be inherent in how it came to be.