And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.
I disagree.
As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script languages such as BASH, for doing small amounts of interactive stuff.
What JS has morphed into is a Jeckyll & Hyde monstrosity. Frontend devs now routinely dump 200kb+ of junk down the pipe at people's browsers because its somehow "better" to dump the processing/rendering on the user's desktop instead of server side.
And then there's the monstrosity of server-side JS. I think few people can argue that JS was ever supposed to be server-side. Things like Node are basically square-pegging JS into that round hole.
The browser is simply the single best application distribution method humanity has ever created. Full stop.
There are literally no other tools that give anywhere close to the same benefits.
So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of applications 200kb is ridiculously small.
When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB?
Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care.
Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds.
Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience.
That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload.
Music player? It's a website now. JS.
See my point?
So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.
That web application delivery is "fucking amazing" doesn't mean javascript is. Javascript very much is not.
What javascript is, is the only complete option until wasm is way more fleshed out than it currently is.
> Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb
With an entire browser and server farm to do that.
> and load in less than a few seconds.
Instead of instantaneously.
> That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload.
10% the functionality, 20% the performance, at twice the heft. Amazing.
> Music player? It's a website now. JS.
Your music library? Doesn't exist now.
No.
Because your point only works if you make (at least) two prior assumptions which are not always true.
Number one you assume everyone has high-speed broadband and "unlimited" 5G on mobile. This might well be the case in many parts of the Western world. But I can point you to a number of rural areas in the Western world and beyond that, in Africa and Asia where this assumption falls flat.
Number two, given most developers use JS to outsource the processing duties, you assume everyone has a half-decent computer. Many people use cheap laptops with lousy Celeron processors and a minuscule amount of RAM, likely also with an ancient browser that has not been updated for ages. Their experience of a browser-app will likely be very different to the cool-kid developer sitting on his bean-bag in a fancy office coding on a spec'd out beast of a machine.
In an ideal scenario of application design, these two assumptions apply as well. So I don't think there is any merit in mentioning them as they're not counter points in any way.
Javascript is not the sole domain of small executables, its not even its primary feature - hell, one of your own examples isn't even very good. Outlook loads nearly 30MB of javascript immediately when you load your inbox, and they update it nearly every other day so you end up downloading hundreds of megabytes just to read your email every single week instead of just once.
But in the context of applications, JavaScript is slow as dog shit.
It takes "seconds" to open my spreadsheet? That is an absolutely deplorable regression.
Personally, I'm fine with 200KB initial downloads, sure that's great and I don't mind repeating them. (But, also don't care about 50MB or even 500MB downloads that I only do once.)
But for the browser to really become the "single best application distribution method humanity has ever created" it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. Not just the putrid UX, but we now understand that slow, inefficient code also cooks the planet and destroys various life forms.
I work at a company that uses Google Sheets. So yeah, it does often take seconds to open a document. And I've spent way more time waiting for those sheets to load over the past 5 years than I have waiting for software installers.
And many web apps bog down and lag behind even just typing, because they are doing some (trivial) computation on every keystroke. It doesn't have to be that way, but it often is... because JavaScript.
I'm also bullish on the browser's future as an app-delivery channel — but that is only because I think doing it without JavaScript will become easy, and thus common.
JavaScript is relevant because of the browser, not the other way around.
WebAssembly executes efficiently, it keeps its overhead within a small multiple of natively compiled binaries which is totally par for the course for any JIT-compiled intermediate code. You can write slow and inefficient code in any language, but Rust makes it a bit easier to do things the efficient way.
We are already seeing real world web apps using WASM. (What I have seen is indeed mostly Rust, but in theory there are lots of other languages that can already, or will be able to, play in that same sandbox.)
The other fun thing about WASM is that there are already a bunch of ways to run it on the server (including "at the edge"). That makes it really easy to chop apps up into pieces that run in the browser, or run elsewhere.
Honestly, with my previous experience as a frontend web, compile time for frontend is starting to become as bad as a standard compiled language. When you start to have a whole framework, many (many!) dependencies (you know, the kind that make just deleting the node_modules directory slow) and webpack with some plugins for CSS, es-lint and all that, the tooling just can't keep up. It doesn't help that much of the tooling is also done in JS which is fast but not that fast.
If you don't need vite's extensibility, you can go with 'pure' esbuild and slim down transpilation + minification + bundling to only a few seconds.
Lol. That's not why JS was invented, at all.
JS was invented to provide basic interactivity to static html pages. By accidents of history it snowballed in the current monstrosity.
I've definitely seen JS builds be slower than medium to large size Rust builds on the same machine, especially since JS builds often involve large steps that are not parallelized. Rust parallelizes builds pretty well until the very last optimization pass and linker stage.
Go builds are impressively fast, so if that's a big pain point for you I'd look at Go frontend stuff.
There are big pushes behind wasm and Rust is leading the way here in a big way. I think you underestimate people and their will not to run javascript. Rust and WASM in particular will make it so that you can bring whatever language you want to the front end.
I believe that while it's very impractical now, wasm will slowly take over and in the future basically no one will use javascript except for basic things and most sites will use wasm for front end logic.
Why? Because it just makes sense for many reasons. You can use whatever language you want both on the server side and in the browser, you can achieve near native speeds and we're already sending big minified javascript blobs anyway so we may as well just send a binary instead. yes it's very hard to make a SPA with Rust today but it is possible and the tooling will become better over time and especially with other languages joining in.
To me it's clear that using javascript on the front end will become slowly irrelevant as more and more devs ship a binary blob. Right now, we need javascript as a glue but I think that will change as well with time.
JavaScript really is a Scheme in disguise with a little bit of Smalltalk. Which really is good. If you don't like junk coming from {}+[] - don't use it, but I consider the lack of errors thrown to be a correct behaviour. Use TS or any other linter to control stuff.
As we can see, Clojure wasn't accepted widely despite the fact it also has first class functions and closures. In my opinion the answer is simple: people want to have syntax for stuff which we agreed is good. Using macros and ((())) is not what people want to do long term.
As someone doing both, my frontend JS/react pipeline has noticeably longer compile times (both to build locally, and for users rendering client-side) than my server-side one.
> There is a reason why JS was invented.
JS isn't here because it's "fast". JS is here because it shipped in browsers, and browsers were popular. JS got fast, after lots of people put a ton of effort into their JS implementations for almost two decades straight to make it so.
(See https://blog.mozilla.org/javascript/2012/12/04/arewefastyet-... from ten years ago as just one of many, many examples)
> And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.
IMO, it really depends on the workload.
For the stuff that JS is being used for today, you're probably right.
But say someone wanted to implement a CAD program in the browser. I'd say, JS is probably inadequate for that[1]. In that case, performance matters more than for a chat app.
If you look at web development as a spectrum from webpage+ to high performance application, Javascript is a good fit for a large section of that spectrum. But probably not all of it.
---
1. I suppose it depends on the complexity of what you want to display, but "regular" local applications struggle to display extremely complex models today. I'd imagine putting the software in the browser would only introduce additional performance problems.
You have never actually looked at the history of javascript have you? Or at the current "best practices"?
And then ironically they then use a complex and runtime-heavy Java-based CI/CD to manage the compilation of their Go codebase.
Go is great though, best bit is how its so useable for web-stuff out of the box. Unlike Rust where you have to spend half your life either re-inventing the wheel or choosing which of hundreds of crates you want to use to do stuff that should be part of stdlib.
Go was created to overcome complexity issues and compile times of C++ (not Java):
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
If Java could have filled this role in both compile time and memory efficiency, Go in all likelihood would never have been created.
But yes, Go beats Java in compile-time speed as well.