There's no point in replacing JS with another dynamically-typed language. JS has received a lot of attempts at depessimization. If you're going to replace it, it would have to be a language with real types (but reflection is still viable as a strictly-superior alternative to dynamic types)
this post was submitted on 18 Jul 2023
13 points (100.0% liked)
No Stupid Questions (Developer Edition)
14 readers
1 users here now
This is a place where you can ask any programming / topic related to the instance questions you want!
For a more general version of this concept check out !nostupidquestions@lemmy.world
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
I would just replace it with a compile target - aka WASM. Then the web is not tied to one language but many can be built on top of it. WASM does need to more features then what is currently available to fully replace JS. DOM access for one, and probably a GC to reduce the amount of runtime you would need to ship (at least for languages that use a GC).
Well, there is webassembly, this will enable static programming languages like c, c++, and rust. Rust is high enough level that it's a pretty good sell for web apps. Even so, once webassembly calms down, we can build alternative interpreters that run on it, and run Python/Go/Java/etc. in the web. This will not be quite as efficent, but as c is about 50% slower in webassembly than on native hardware, I think a Go/Java would run well, Python might be a bit behind, but Lua is simple enough it might work.
TLDR: You don't have to kill JS to get those language functionalities, just wait for webassembly and all the cool stuff that comes about from that.
Caveat: Though I'm a developer, I'm not a webassembly developer. I've heard of these things as theoretical possibilities, but don't know the specific limitations. Sounds promising but who knows how long it will take to get there.
Webassembly can't access the DOM, so it can't replace Javascript completely. It's more of a way to write libraries, but JS still needs to glue everything together.
Another issue running interpreted or bytecode languages that way may be the size (memory + download) of the runtime.
You could transpile different languages into JS. So you write in the language of your choice, transpile it to JS, then send the transpiled JS to the user’s browser. You could possibly do the same thing but use webasm as well.
If you want lightweight it's probably better to stick with js or some language that compiles directly to wasm.
That's being said, there are libraries for running python/lua/ruby in a browser and interacting with the dom. I've only personally used python, which is great for running scientific computation things in browser since python has such an ecosystem for that type of thing. It is a pretty big addition to bundle size initially iirc, so I'm not sure how useful it is as a general purpose replacement for js.
Chrome had native support for Dart for a few years, there were some experiments with Ruby, and Coffee script transpiler