I was excited at first. Compile Javascript like code into WebAssembly text format? Zero dependencies? Count me in!
I thought: Great! Let's try it! So how do I use it? How do I hand over a string of Walt and get a string of WebAssemblyText back?
I though there is a javascript file somewhere in the project that has a compile() function that does that.
And then I clicked on the Quick Start Guide and it looks much more complicated. It tells me to install node, npm, webpack, walt-compiler, walt-loader... set up a project with a certain structure, create a landing page...
Help :) That's not what I want. I just want a function that takes a string and returns a string.
Would it be possible to just offer a javascript file to be used directly in the Browser? That exports a function which translates your JS dialect to WasmText?
Because different runtimes support different features and performance (like dealing with files and disk access) but I already posted the link for the browser version in that comment.
I think that's not quite what was asked for. What was asked for is one JS file with a function that takes a string and returns a string. Not a node package, not a website. Check out Three.js, it's a big library which can be used as one file three.min.js.
If you check the `dist` folder within the linked Git repository you can see a `walt.min.js` file[0]. You should be able to include that file and try out the package in your browser in a similar way to how you use `three.min.js`.
You don't need node to compile WASM or deliver it to the browser, either.
The only reason this "needs" NPM is because it's become convention that all javascript projects need NPM and some related toolchain regardless of their complexity.
No, the convention is that Javascript projects are distributed as source rather than as "binaries" (single minified JS files.) Source code generally needs a build tool. NPM is a build tool.
It doesn't translate to wasm text format, but to wasm binary format. The walt-compiler (https://github.com/ballercat/walt/tree/master/packages/walt-...) readme shows how to use it to compile text into a a buffer which you can write to disk or instantiate into a webassembly module.
It doesn't translate to wasm text format,
but to wasm binary format.
Oh, ok. That is interesting too. But I would have liked to build a tool where I type Walt on the left and see the resulting WASMtext on the right. So this seems to not be a solution for that.
Your argument is valid, the QuickStart example isn’t wrong though. Webpack is somewhat the bundling standard in front end. What they showed, I can easily get it working in a large project without a lot of kungfu.
If you want the walt->wasm function, it’s usually the loader.
And yes, you can invoke the loader standalone.
Perhaps they should give a much simpler example and then later a webpack example.
I help out every once and a while on the AssemblyScript team with like issues, docs, and things. And made wasmboy, which uses AssemblyScript: https://github.com/torch2424/wasmBoy
Incredibly, the segment below is valid TypeScript.
@inline
function rot(x: u32, y: u32, v: u32): void {
var a = max<i32>((v >>> 24) - BIT_ROT, 0);
set(x, y, (a << 24) | (v & 0x00ffffff));
}
You must be working on a different set of problems than me to be able to identify this as vanilla TypeScript.
Not given the context of a file extension, I would forgive anyone for mistaking this to be some kind of low level driver code and be confused on source language.
I wrote/maintain Walt. This question comes up a bunch.
The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation was simple. I wanted to learn WebAssembly and I wanted an accessible platform to do so with. At the time this wasn't really possible, tools like emscripten took forever to set up and were clunky to use. Plus I knew C already, I wanted to learn WebAssembly instead.
So where Walt is an attempt to write WebAssembly with a familiar syntax, AssemblyScript is an attempt to compile TypeScript to WebAssembly. To do so AssemblyScript comes with many more niceties/features out of the box IIRC, like optional(?) GC for example. Walt makes no such attempts and takes a more DIY approach.
Walt also has language extensions, via customizable syntax and compiler pipeline, where AssemblyScript is a TypeScript compiler more or less. My hope is that this allows for a babel-like situation for WebAssembly in the future via the tooling setup for Walt. I don't think this is a goal of AssemblyScript.
IMO this is a good decision. I much prefer a platform with a small API than I can personally extend over a large platform that has specific customization options or lots of extra features that all just "kind of" solve whatever problem I have.
Reading this makes me more interested in the project than I was before.
One quick recommendation, it was kind of hard to find the documentation for the Webpack free compiler (https://www.npmjs.com/package/walt-compiler). This is purely anecdotal, but I suspect that at least some of the people who are turned on by having a low-level library that doesn't include Typescript niceties will be turned off by seeing the quick-start immediately say to install Webpack. Might be a good idea to have the compiler documentation inside the wiki alongside the quick-start?
Are people really editing .wat files by hand to eek out the last bit of performance? Seems like you would need instruction level profiling to do it justice
Wasabi: A Framework for Dynamically Analyzing
WebAssembly
Binary size would probably be the main thing you'd want to optimize for. Which, at least a few months ago when I tried the wasm32 target in rustc, is a big issue.
Fascinating! Serious question: could this turn JavaScript (technically Walt) into a serious language for scientific computation? That now runs in any browser?
E.g. Python is used a lot together with NumPy/SciPy, but for performance the actual computation in NumPy/SciPy is done in C since Python is too slow. Would it be possible to create Walt-native versions of NumPy and SciPy... e.g. NumWalt and SciWalt? Or even Jupyter notebooks based on Walt?
This looks great. I've been looking for a project like this for a while - a simple language in which I can write hot code and compile it straight to web assembly for use in existing node and web projects.
However, I wonder whether Walt is markedly faster than JIT-compiled javascript? Have you benchmarked the performance gain?
I have not, this has been requested quite a bit though. My focus is currently on making sure the toolchain is stable and performant itself. It's likely that the performance of the compiled code is on par with other wasm vs JS comparisons though.
Superb! I would love to see native programs being ported using traditional JS to the browser, perhaps this is a step closer for a clone of Photoshop in the open web!
I like the progress of where webassembly is heading! :)
Let a thousand flowers bloom and all that, but come on. That particular flower is a freaking baobab already. I assume it's mostly for use outside of browsers.
I was excited at first. Compile Javascript like code into WebAssembly text format? Zero dependencies? Count me in!
I thought: Great! Let's try it! So how do I use it? How do I hand over a string of Walt and get a string of WebAssemblyText back?
I though there is a javascript file somewhere in the project that has a compile() function that does that.
And then I clicked on the Quick Start Guide and it looks much more complicated. It tells me to install node, npm, webpack, walt-compiler, walt-loader... set up a project with a certain structure, create a landing page...
Help :) That's not what I want. I just want a function that takes a string and returns a string.
Would it be possible to just offer a javascript file to be used directly in the Browser? That exports a function which translates your JS dialect to WasmText?
Is that file somewhere in there maybe?
Yes, that's the compiler: https://github.com/ballercat/walt/tree/master/packages/walt-...
It's written in JS so you'll need node to run it, and npm is a package manager for node so you should use that to install and call it.
If you just want a hosted site to play with code, it's linked right at the top: https://ballercat.github.io/walt/
I happily run JS in my browser all day. Why do I need node for this code?
> Why do I need node for this code?
The next paragraph of the comment you replied to answers that — you don’t, you can use https://ballercat.github.io/walt/ in your browser.
Because different runtimes support different features and performance (like dealing with files and disk access) but I already posted the link for the browser version in that comment.
I think that's not quite what was asked for. What was asked for is one JS file with a function that takes a string and returns a string. Not a node package, not a website. Check out Three.js, it's a big library which can be used as one file three.min.js.
If you check the `dist` folder within the linked Git repository you can see a `walt.min.js` file[0]. You should be able to include that file and try out the package in your browser in a similar way to how you use `three.min.js`.
[0] https://github.com/ballercat/walt/blob/master/packages/walt-...
https://unpkg.com/walt-compiler@0.16.2/dist/walt.js
Maybe so you can deliver precompiled wasm to a browser rather than having to deliver the source and a compiler?
You don't need node to compile WASM or deliver it to the browser, either.
The only reason this "needs" NPM is because it's become convention that all javascript projects need NPM and some related toolchain regardless of their complexity.
No, the convention is that Javascript projects are distributed as source rather than as "binaries" (single minified JS files.) Source code generally needs a build tool. NPM is a build tool.
It doesn't translate to wasm text format, but to wasm binary format. The walt-compiler (https://github.com/ballercat/walt/tree/master/packages/walt-...) readme shows how to use it to compile text into a a buffer which you can write to disk or instantiate into a webassembly module.
Oh, ok. That is interesting too. But I would have liked to build a tool where I type Walt on the left and see the resulting WASMtext on the right. So this seems to not be a solution for that.
What? Just use wasm2wat [1] and you’ll get the text format.
[1] https://github.com/WebAssembly/wabt
That tool already exists: https://ballercat.github.io/walt/ - though you have to switch 'tabs' to see the WASM code.
Yes, I saw that.
It's not the interface that I would like to use. I want to write Walt on the left and instantly see the WasmT on the right.
Also, that tool does not work here. It gives me 'Uncaught ReferenceError: getAST is not defined' as soon as I type something in the code tab.
These look less like questions about the project and more like feature requests.
Perhaps you should try unpkg:
And if that doesn't work, perhaps you can submit an issue or a PR.
Here you go :)
https://jsbin.com/nisoget/edit?html,js,console
Awesome! Thanks man!
This is what makes Hacker News great!
Actually, check again! I just updated it to NOT use wabt. Walt-compiler has its own semantic printer, so its output is more readable.
And yes! I think answering these kind of simple questions is important, so thanks for asking them.
Even better.
I'm already having fun with it.
Your argument is valid, the QuickStart example isn’t wrong though. Webpack is somewhat the bundling standard in front end. What they showed, I can easily get it working in a large project without a lot of kungfu.
If you want the walt->wasm function, it’s usually the loader.
And yes, you can invoke the loader standalone.
Perhaps they should give a much simpler example and then later a webpack example.
It’s open source, open a PR may be?
Go to https://flems.io/walt-compiler
You can then play with the `Walt` global.
What's the difference between this and something like AssemblyScript?: https://github.com/AssemblyScript/assemblyscript
EDIT: I see that this project actually existed slightly before AssemblyScript. Still seems like two very similar projects.
From a quick glance, it looks like AssemblyScript compiles TypeScript, whereas Walt uses its own dialect of JS with WebAssembly types.
A quick look at a sample .assembly file [0], make it look like a very different language from TypeScript.
That said, the familiar tooling, editor support, are wins over other WASM options.
[0] https://github.com/AssemblyScript/assemblyscript/blob/master...
I help out every once and a while on the AssemblyScript team with like issues, docs, and things. And made wasmboy, which uses AssemblyScript: https://github.com/torch2424/wasmBoy
But that being said, usually when people are interested in the language, we usually direct them to the "n-body" example: https://github.com/AssemblyScript/assemblyscript/blob/master... . Which kind of looks more typescript-y :)
Also, just to stay on topic, I think walt is awesome. Stoked to see so many projects coming up with a "Wasm for JS devs" approach/story.
Apart from the explicit number types (`i32` instead of `number`, etc.) it looks like standard typescript. What looks different to you?
Incredibly, the segment below is valid TypeScript.
You must be working on a different set of problems than me to be able to identify this as vanilla TypeScript.
Not given the context of a file extension, I would forgive anyone for mistaking this to be some kind of low level driver code and be confused on source language.
It is so impressive that this is valid TS though!
[edit: code formatting]
I wrote/maintain Walt. This question comes up a bunch.
The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation was simple. I wanted to learn WebAssembly and I wanted an accessible platform to do so with. At the time this wasn't really possible, tools like emscripten took forever to set up and were clunky to use. Plus I knew C already, I wanted to learn WebAssembly instead.
So where Walt is an attempt to write WebAssembly with a familiar syntax, AssemblyScript is an attempt to compile TypeScript to WebAssembly. To do so AssemblyScript comes with many more niceties/features out of the box IIRC, like optional(?) GC for example. Walt makes no such attempts and takes a more DIY approach.
Walt also has language extensions, via customizable syntax and compiler pipeline, where AssemblyScript is a TypeScript compiler more or less. My hope is that this allows for a babel-like situation for WebAssembly in the future via the tooling setup for Walt. I don't think this is a goal of AssemblyScript.
> Walt also has language extensions
IMO this is a good decision. I much prefer a platform with a small API than I can personally extend over a large platform that has specific customization options or lots of extra features that all just "kind of" solve whatever problem I have.
Reading this makes me more interested in the project than I was before.
One quick recommendation, it was kind of hard to find the documentation for the Webpack free compiler (https://www.npmjs.com/package/walt-compiler). This is purely anecdotal, but I suspect that at least some of the people who are turned on by having a low-level library that doesn't include Typescript niceties will be turned off by seeing the quick-start immediately say to install Webpack. Might be a good idea to have the compiler documentation inside the wiki alongside the quick-start?
I've been going with Lua for writing raw webassembly
Assembler setup: https://github.com/serprex/luwa/blob/master/rt/make.lua Resulting code for a gc looks like this: https://github.com/serprex/luwa/blob/master/rt/gc.lua
& it leaves the full Lua language at my disposal for metaproramming. At the end of a day a human usable assembler needs to be a macro assembler
It'd be neat to have a JS macroassembler, could then have the host browser runtime compile wasm modules dynamically
> It'd be neat to have a JS macroassembler, could then have the host browser runtime compile wasm modules dynamically
Use fengari (https://fengari.io/) to run your lua assembler?
Lua is fantastic.
> Resulting code for a gc looks like this: https://github.com/serprex/luwa/blob/master/rt/gc.lua
Nice! That's a compact gc, perfect for browsers.
Are people really editing .wat files by hand to eek out the last bit of performance? Seems like you would need instruction level profiling to do it justice
Wasabi: A Framework for Dynamically Analyzing WebAssembly
https://arxiv.org/pdf/1808.10652.pdf
Do web assembly files really have a .wat extension? This can't not be an easter egg reference to the famous talk, right? :)
Should have gone with .wtf. WebAssembly Text Format.
.wtf will always be Warcraft Text Files for me. Nothing like editing that Config.wtf file when playing WoW...
Binary size would probably be the main thing you'd want to optimize for. Which, at least a few months ago when I tried the wasm32 target in rustc, is a big issue.
Fascinating! Serious question: could this turn JavaScript (technically Walt) into a serious language for scientific computation? That now runs in any browser?
E.g. Python is used a lot together with NumPy/SciPy, but for performance the actual computation in NumPy/SciPy is done in C since Python is too slow. Would it be possible to create Walt-native versions of NumPy and SciPy... e.g. NumWalt and SciWalt? Or even Jupyter notebooks based on Walt?
Would it not be easier to take a language with existing libraries (e.g. Julia, C++) and make it compilable to WASM?
Or even figure out how to run a Python interpreter + WASM-compiled C extensions together to be able to use Numpy, Scipy, etc.
You could just port the C libraries that Python uses.
You might want to check that you’re actually gaining any performance, the JIT compilations of JavaScript aren’t often slow.
Not really, you would be better off running that code as GLSL shaders on the GPU.
This looks great. I've been looking for a project like this for a while - a simple language in which I can write hot code and compile it straight to web assembly for use in existing node and web projects.
However, I wonder whether Walt is markedly faster than JIT-compiled javascript? Have you benchmarked the performance gain?
I have not, this has been requested quite a bit though. My focus is currently on making sure the toolchain is stable and performant itself. It's likely that the performance of the compiled code is on par with other wasm vs JS comparisons though.
Superb! I would love to see native programs being ported using traditional JS to the browser, perhaps this is a step closer for a clone of Photoshop in the open web!
I like the progress of where webassembly is heading! :)
This is amazing. Yes! I’ve always wanted something like this.
I wonder if we could make a boiled down typescript language server that would give excellent code completion and squiggles for Walt.
Full circle?
Glad I took part of this project early and got the possibility to focus it to great goals
Doesn't JavaScript compile down to WebAss? Isn't that the point?
WASM is a very new standard. Some JavaScript implementations do compile to machine code at run time, but JavaScript does not "compile down to WebAss".
I'd rather use Rust than javascript 8 days a week
I wasted too much time trying to look if there was a way javascript date objects would report there being eight days in a week...
Well, good for you.
Let a thousand flowers bloom and all that, but come on. That particular flower is a freaking baobab already. I assume it's mostly for use outside of browsers.
> Highlights:
> No C/C++ or Rust required, just typed JavaScript.
That's not a flaw...!
It all depends which of all these ugly langages you are the least uncomfortable with. I hear they even use js for servers now. Rise and fall... lol
Honestly I thought you referring to Rust as an ugly language would send more replies your way.