Also, JavaScript really is not a very good programming language. We are just stuck with it because it's the only language the browser understands. (Well, until recently: things are going to change with the introduction of wasm).
But for the shell, we're not stuck with any one language. Whatever you want to do can be programmed in your favorite language. You can easily write a python script instead of a bash function.
people have been saying this for years already and nothing seems to have come of it :(
There aren't many languages that are practical for WASM output. Scripting and managed languages need to ship their interpreters and runtimes with their WASM blobs, and can end up relatively large. JavaScript's interpreter and runtime are baked into every browser already.
That leaves only compiled and unmanaged languages for potentially good WASM targets. As mentioned before, Rust is seeing a lot development in that space. If LLVM can compile it, then Emscripten can output it to WASM.
Figma for example seems to be largely powered by WASM and the core of the product seems to be written in C++
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
https://www.figma.com/blog/building-a-professional-design-to...
I think the majority of web developers are just slow at catching up with this new things.
I thought that was the case but I can’t recall where I read it. If that’s not true then I should probably reconsider my thinking about wasm
We've been forgetting and relearning that for the past two decades.
Actually it turns out that having an interpreted runtime causes a stream of endless problem. We keep try to patch them over but new problems keep coming up.
It turns out that a standarized low level byte code is the right way to ship cross platform applications. We already knew that. It just took a long time to go through the standarization process and be implemented by browsers.
If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it).
So why hasn’t it taken over the world with Java and now with wasm?
> If it seems like it's not in use today, it's largely because JavaScript has momentum and the majority of web programmers don't yet know how to take advantage of wasm (or maybe don't think they need it).
There’s another possible reason. I’m sure you can come up with the answer yourself.
Java applets really sucked. They took a long time to load and initialize. They all looked ugly (probably because of the default libraries?).
Also Java itself as a language was really bad and the development experience was awful. I want to say that no one wants to program in Java but in reality many people do (I don't understand those people).
The important lesson here is the implementation is more important than the idea.
Good idea with bad implementation -> goes no where.
wasm is not java.
The important quality about wasm is that it's not garbage collected. It's pretty close to just good old assembly.
Chrome was released at the end of 2008, JavaScript was thriving way before that. We had Gmail since 2004, jQuery since 2006. WebApps were the “sweet solution” considered for iPhone apps at first in 2007. Chrome exists because of the healthy ecosystem that Firefox and Safari provided, not the other way around.
>It's pretty close to just good old assembly.
Precisely, and it's yet to be proven that's the best solution for the Web. I love it from the computer science perpective, but historically that idea hasn't struck a chord.
> JavaScript really is not a very good programming language.
Go look at ES6 (the javascript version that came out in 2015) and even TypeScript. You'll be pleasantly surprised, no matter if you're coming from C++, Java, C# or even other "scripting" languages such as PHP and Python.
Ultimately I want a langauge with value types like structs and arrays that you can use to do computations without allocating things on the heap.
In Go I can write a function that returns two numbers.
In Javascript I can only return two numbers by allocating an array on the heap with two items. These two items themselves are probably pointers to two number objects allocated separately. So that's 5 allocations to return two numbers. It's insane.
This means fundamentally it's impossible to create applications in javascript that are both sophisticated and high performance.
A great example to illustrate this is the tooling around Javascript itself.
There were all kinds of bundlers: webpack, rollup, parcel, etc. Rollup was considered the fastest and lightest. They were all programmed in Javascript itself. They were all slow. But no one really knew how bad it was because there was nothing really better.
Then esbuild comes along, and blows all of them completely out of the water, out performing them by 100 times. And it's written in Go. A language that supports structs and arrays as value types.
For example, you are worried about value types but under the hood the JIT compiler will actually generate efficient representations that are passed by value if you do not mess things up for it. Modern JS compilers are extremely sophisticated.
For returning values without an allocation, you’d create such a “struct” and then use a memory pool. It would still be heap allocated I believe but not totally sure. People who know more than I do could probably tell you a better method to return multiple values from a function efficiently.
Yes, and in my experience this kind of applications (and the browser in general) are one of the only things these days that still push me to upgrade my hardware to have better CPUs and more RAM, as it's perfectly sufficient as is for pretty much everything else I do.
Its tooling got significantly better in the last decade or so, but you still need to intentionally rely on it in order to work with the language in any sensible way. You can't really hope for any other outcome when maintaining backwards compatibility.
Everything else is either unmanageably complicated (webpack) or slow (rollup, parcel, babel).
React mainstreamed the idea of using a virtualdom to accelerate UI building (accelerate in the computational sense: by not dealing directly with the slow DOM).
A couple of years ago, I challenged myself to write some complex scripts and apps using only Bash, and came to this conclusion myself.
You can get pretty far with just Bash alone, especially if you strive to write readable and maintainable code, and not just one off scripts. If you need access to data structures, especially nested ones, you can shell out to another language and then print the results back to stdout so Bash can use them:
$ get_data | transform_data | python3 ./complex_script.py | consume_resultsI just hate doing things with files in the shell, all those stupid escaping rules, and god forbid you have files with spaces or quotes in the names, or leading or trailing spaces.
It's just spending time learning hacks to get around shell limitations instead of actually getting things done, and at the end it's an ugly mess.
Or maybe I'm just bad at it, but I don't think it's only that.
Packaging in Python is a bit more of a pain.
> Windows doesn't have bash preinstalled
> On all OSes I've used in the past 3-4 years all of them have been Python3 by default.
should read
"no reason to think ... couldn't"