Can WebAssembly be used without any JavaScript? Or JavaScript is always required in some combination with it?
Rust and WebAssembly in 2019
71–80 of 97 posts
Re: Rust and WebAssembly in 2019
#72Earlier quoted context omitted.
As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick. A CDN may happen; there’s some details that make it tough. We’ll see. npm is already that package manager :)
No need to replace the millions of packages in npm. I predict there will never be a shortage of new javascript frameworks... No, npm is not THAT package manager. What I am talking about is a way for a user's Browser to download for example a Python 3.7.1 runtime (and similar packages) once, and use it on different sites and applications. In the simplest form Google or Python.org could serve these files on a CDN. In a…
Re: Rust and WebAssembly in 2019
#73Re: Rust and WebAssembly in 2019
#74It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.
There are plans to get garbage collection support into WASM, but GC is already possible, just not native. In my opinion the major benefit of WASM over Javascript is that it allows different runtimes to be used in browsers. Python for example has the pyodide project, which works quite well. But its download sizes are totally ridiculous. Which may not matter for certain applications, and even then, there should be a wa…
Don't know how this will play with other languages.
Re: Rust and WebAssembly in 2019
#75I decided that Rust is the natural next step for my personal side project stuff, which I want to be more on the browser-based gamedev side of things. The learning curve is enormous - since coming from like Unity and Flash, so much is done for you... I mean, one _can_ write their own shader code and physics and things, but it's not at all required in order to make impressive content. Even in JS, Three.JS and friends t…
The Flash devs I met went all downhill with Flash, because they never learned how to code and suddendly needed to do it.
Re: Rust and WebAssembly in 2019
#76I'm not quite into Rust yet, but it is a very candidate for useful webassembly frameworks/projects. It doesn't need a big run time, but is more expressive than C/C++. The big drawback is that, unlike Javascript or Python, there is just no way I'm going to be able to teach Rust to previously non-technical people. The learning curve is just too damn hard.
Plenty of "non-technical people" learn to write simple (buggy) programs in C in a matter of months. And once you know the basics of the C machine model, it is quite feasible to work up to Rust.
The thing about learning Rust though is that it's not really a mature language just yet - it's a hell of a moving target! Even Rust+NLL is a very different animal from Rust w/o NLL, and this goes for so many other features.
Re: Rust and WebAssembly in 2019
#77Earlier quoted context omitted.
That's only a problem for more traditional websites. For applications 1MB is just not an issue. I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?
As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick. A CDN may happen; there’s some details that make it tough. We’ll see. npm is already that package manager :)
Re: Rust and WebAssembly in 2019
#78Earlier quoted context omitted.
That's only a problem for more traditional websites. For applications 1MB is just not an issue. I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?
As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick. A CDN may happen; there’s some details that make it tough. We’ll see. npm is already that package manager :)
No, we should be working to replace NPM and the bad influence of the javascript community, not double down on their ubiquity. We should be able to do a lot better than sticking with NPM and wrapping everything in Chromium.
Re: Rust and WebAssembly in 2019
#79I wish something similar was officially worked on by the python core dev. Ouputting wasm and being able to interpret it is going yo be necessary for the language to stay relevant in 10 years. But it not a priority at all atm.
Python is extremely dynamic and compiling it into wasm would likely be impossible or would generate extremely low-performing code.
What more, i think it would make more sense to actually make a bytecode to wasm and vice versa compiler than directly use python code.
Besides, performances are not important at first. The goal is not python is the browser, as wasm can go far beyong the web. The greatest assests for wasm IMO is the interroperability.
Re: Rust and WebAssembly in 2019
#80IMHO, the next two years there is going to be a massive adoption of wasm as the library ecosystem for different languages matures and as browsers gradually improve their wasm support. Contrary to the popular belief with javascript people, it will not be limited to just the performance critical parts: everything people do with javascript today is in scope. Absolutely no exceptions. I fully expect to see a lot of projects where the goal is to be 100% javascript free and I don't see any fundamental blocking issues to get there.
If you are doing a greenfield project today, that is already a feasible goal to set but you may have to reinvent a few wheels along the way or be dealing with not so mature frameworks and tools. However, once you start doing rust or kotlin, it will just feel wrong to have to revert to back to javascript or pull in an npm and wrap that with some facade. That's like admitting defeat. Basically, Rust people already concluded that they can do it all and are now in the process of doing it.