> 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?

> The whole point of WebAssembly was to find some way to get away from JavaScript

The goal is to "Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities...."[0].

[0] https://webassembly.org/docs/high-level-goals/

WASM is then the new JVM. Birth and Death of Javascript indeed.

Everything old is new again, and the Wheel of Time turns, and ages come and pass, leaving memories that become legend. Legends fade to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the third age by some, an Age yet to come, an age long past, a virtual machine specification was created in an attempt to achieve the goal of write-once, run everywhere code. The specification was not the beginning. There are neither beginnings or endings to the turning of the Wheel of Time. But it was a beginning.

Just like CPUs.

In the beginning Assembly became bytecode and CPUs included interpreters via microcode, then everything was supposed to be executed directly by hardware gates, now Assembly has become another form of bytecode and all major CPUs have reverted back to microcode.

Same applies to GPUs.

Everything old is new again, indeed.

Thanks for bringing some poetry to tech land :)

What a weird argument. C is not "better" than Javascript, it is vastly worse for the vast majority of current Javascript uses - where raw performance is a less important consideration than development time.

Javascript is far from perfect, but it has improved by leaps and bounds the last few years. WebAssembly is great, but a variant of Javascript or other high-level languages will continue to dominate web development, not C. People aren't going to "escape" from Javascript to C, except certain niches where performance is vital.

I disagree about "better", but...

If you like your JavaScript, you can keep your JavaScript. You have no reason to care about WebAssembly. Why would you build a JavaScript imitation on WebAssembly when you can just use JavaScipt?

WebAssembly is for the rest of us.

That's the thing though. We are all "us" here. We can all compile whatever we want to WebAssembly, that's the point of WebAssembly. One way of doing things doesn't take away from another.

It's not a JavaScript imitation. This is a JavaScript-like syntax for writing WebAssembly. Other than that, (excepting the closure helper) it's 1-to-1 WebAssembly.

Not everyone enjoys writing verbose S-Expressions [1], even if it makes for a good canonical format.

If you despise JavaScript so much that you can't bear the thought of something that vaguely looks like JavaScript, then don't worry there are other "skins" for writing WebAssembly [2-4] and it should not be too hard to write your own.

Finally, nobody owns WebAssembly. It's for clever people like yourself just as much as it is for dirty JavaScript programmers like me.

[1] https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo...

[2] https://github.com/tmcw/wah

[3] https://github.com/serprex/luwa

[4] https://medium.com/cirru-project/webassembly-s-expression-an...

You might like a JavaScript-like language but want to get rid of the garbage collector, or work closer to the bare metal than Javascript currently allows.

WebAssembly is for everyone.

Escaping JavaScript is not a perspective shared by all (most?), though.

It's has been a weird and interesting project, but that's not really a bad thing is it.

You'll have to excuse HN Guy that assumes that every project on GitHub is done to try and take over the world and not because, you know, learning is fun. So keep on doing weird things with your weird and awesome language.

I may be in the minority then: one of the big advantages, for me, of WASM is that I can use not-Javascript in the browser. Some of the issues I have with JS are an artifact of being one of the first things to run in the browser (e.g. atrocious standard library) and some are just baked in poor designs (e.g. implicit type casting, == vs ===).

Oh gosh, let's not forget what happens when you try to use map and parseInt together.

[‘1’,’2’,’3’,’4’,’5’,’6’,’7’,’8’,’9’,’10’].map(d => parseInt(d));

Returns

[1,2,3,4,5,6,7,8,9,10]

Sure, but you're putting a workaround in – there really shouldn't be any need for that no-op arrow function. But you do actually need it in order to drop all but the first arguments.

This is simple, straightforward, and wrong:

    ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt)

This doesn't work because map() stuffs a counter into the second argument of parseInt(), which is expecting a radix for its second argument. So the iterations of the map go like this:

    parseInt("1", 0)
    parseInt("2", 1)
    parseInt("3", 2)

…and so on, which obviously gives garbage results. JavaScript is littered with these kinds of weird edge cases. Even your example with the workaround isn't 100% reliable, it's browser-dependent – when you have leading zeros in your strings, some browsers will interpret them as octal, and some won't.

so what is your problem with all this? that these functions have both provided a flexible interface for use cases that are not this single one?

> browser-dependent

Language version dependent rather than browser dependent.

It may seem the same (after all, different browsers implement different versions of the language), but it's a bit different, if you say 'browser-dependent' it makes it sound like there is no standard when in fact, the leading zero behaviour hasn't been the case since ecmascript 5. You'll struggle to find a browser in common use that doesn't support at least ecmascript 5. It's as browser-dependent as the array.map function which was added at the same time.

Your example code would never have the leading 0 problem since you're using array.map and array.map didn't exist in the engines that had that leading 0 'feature'.

I'd expect your example to return a syntax error as those aren't single or double quotes. Try:

["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt);

Backticks are used for template literals. Try evaluating `2 + 2 = ${2 + 2}`.

Those weren't backticks (`) either. They were "smart" quotes (’ -- you may need a different font to view the differences more readily ’ vs ').

But you understood what they meant right?