6 ms·

The future looks like everyone's going to use his fav language to compile to WebAssembly Am I the only one who feels like it's the end of the web as we knew it

The future looks like everyone's going to use his fav language to compile to WebAssembly Am I the only one who feels like it's the end of the web as we knew it in the 90s and 00s, where you could open any web page, understand how it works and learn from it ?

digi_owl 8y ago
I think that time is long gone, as so much of the web today is simply bespoke remote UIs for black box databases rater than static documents.
sp332 8y ago
I don't think it's that different from minimized and sometimes intentionally obfuscated JS. In fact I think it's been getting better recently as there are tools developed to debug that kind of code - sourcemaps etc.
pjmlp 8y ago
Yep it is the plugins' revenge, the only way to be competitive against native apps it for the browsers to become yet another general purpose VM.
- deleted 8y ago
  [deleted]
trgv 8y ago
I thought wasm was going to have a human-readable equivalent, called wast. See: https://webassembly.org/getting-started/advanced-tools/ https://webassembly.org/getting-started/advanced-tools/ My understanding (maybe wrong) was that this was going to be available in the browser.
- err4nt 8y ago
  I'm not an expert, but my understanding is that WASM has two formats: a text-based format called WAT, and a binary format called WASM. In order to run the code in the browser, the code will have to be compiled to the binary format. So where WAT comes in is your methods for producing WASM files now become one of the following: Source in <otherlang> -> WAT -> WASM Source in <otherlang> -> WASM WAT -> WASM So the human-readable WAT can either be used as a compile target for another language, which can easily be compiled into WASM, or you can write the WAT manually and compile it. Alternatively other languages might be able to compile directly to the binary format, skipping WAT representation entirely.
  - steveklabnik 8y ago
    Generally, WAT is produced from the binary format. Compilers don't go through WAT; they produce the binary output directly. The translation between WAT and the binary format is lossless, so there's no advantage of producing WAT as an intermediate step.
    - err4nt 8y ago
      Since WAT -> WASM is already easy to do, compiling <otherlanguage> to WAT makes it really easy for people to create their own abstractions for writing WebAssembly in nearly _any_ other programming language, not just those that can compile directly to the binary format.
      - steveklabnik 8y ago
        I don't understand why that would be true. It's also just as easy to get WASM from WAT as it is WAT from WASM. I don't know of any languages that compile to WAT and then compile to WASM; as far as I know 100% of languages compile directly to WASM.
- sp332 8y ago
  It's only human-readable like disassembling a binary into assembly code. https://webassembly.github.io/spec/core/text/index.html https://webassembly.github.io/spec/core/text/index.html Whether you can make heads or tails of the code in that format depends on how friendly the compiler was that produced the binary.
emily-c 8y ago
I think that disassembling WebAssembly is easier than trying to make sense of a highly minified/obfuscated JavaScript bundle. The time of easily readable web code has been dead for quite a while now I would say.
z3phyr 8y ago
Well, someone is bound to make disassemblers/decompilers/debuggers for us to dissect the innards of the VM. As a side note, I am half expecting the announcement of a web assembly ISA any day.
- pjmlp 8y ago
  It is just a matter of someone bothering to create a FPGA for it. :)
  - TomMarius 8y ago
    It has been explored and it's been decided that it's better to JIT on a classical CPU. Obviously it's still very early so we'll see, but I redirected my excitement to JITs and kernel mode / ring 0 execution.
87 8y ago
I think it's quite the opposite in terms of languages. Javascript will have the best WASM interop story for quite a while. As WASM gets adopted we'll see it get used in all sorts of places outside the browser. Many projects need a high-level scripting language and JavaScript will be the obvious choice.
megaman22 8y ago
If it means the end of JavaScript, I'm all in. Let's get back to having real application languages for applications, and markup languages for text. I hope that we'll come around to the idea that this two-decades long fascination with abusing the hell out of web technology was a fever dream, and go on to build something better on more substantial foundations. I'm probably going to be disappointed...
- wrinkl3 8y ago
  I don't see Javascript going away anytime soon, tbh. We've already reached the point where it's the first language for a mind-boggling number of developers, it absolutely dominates the frontend frameworks and it's been steadily becoming more popular on the server side.
mchahn 8y ago
> where you could open any web page, understand how it works and learn from it ? Web browsers will/already show wasm disassembly when opened in the browser tools. A file can contain label metadata which makes it very readable.

digi_owl 8y ago

I think that time is long gone, as so much of the web today is simply bespoke remote UIs for black box databases rater than static documents.

sp332 8y ago

I don't think it's that different from minimized and sometimes intentionally obfuscated JS. In fact I think it's been getting better recently as there are tools developed to debug that kind of code - sourcemaps etc.

pjmlp 8y ago

Yep it is the plugins' revenge, the only way to be competitive against native apps it for the browsers to become yet another general purpose VM.

deleted 8y ago
[deleted]

trgv 8y ago

I thought wasm was going to have a human-readable equivalent, called wast. See: https://webassembly.org/getting-started/advanced-tools/ https://webassembly.org/getting-started/advanced-tools/ My understanding (maybe wrong) was that this was going to be available in the browser.

err4nt 8y ago
I'm not an expert, but my understanding is that WASM has two formats: a text-based format called WAT, and a binary format called WASM. In order to run the code in the browser, the code will have to be compiled to the binary format. So where WAT comes in is your methods for producing WASM files now become one of the following: Source in <otherlang> -> WAT -> WASM Source in <otherlang> -> WASM WAT -> WASM So the human-readable WAT can either be used as a compile target for another language, which can easily be compiled into WASM, or you can write the WAT manually and compile it. Alternatively other languages might be able to compile directly to the binary format, skipping WAT representation entirely.
- steveklabnik 8y ago
  Generally, WAT is produced from the binary format. Compilers don't go through WAT; they produce the binary output directly. The translation between WAT and the binary format is lossless, so there's no advantage of producing WAT as an intermediate step.
  - err4nt 8y ago
    Since WAT -> WASM is already easy to do, compiling <otherlanguage> to WAT makes it really easy for people to create their own abstractions for writing WebAssembly in nearly _any_ other programming language, not just those that can compile directly to the binary format.
    - steveklabnik 8y ago
      I don't understand why that would be true. It's also just as easy to get WASM from WAT as it is WAT from WASM. I don't know of any languages that compile to WAT and then compile to WASM; as far as I know 100% of languages compile directly to WASM.
sp332 8y ago
It's only human-readable like disassembling a binary into assembly code. https://webassembly.github.io/spec/core/text/index.html https://webassembly.github.io/spec/core/text/index.html Whether you can make heads or tails of the code in that format depends on how friendly the compiler was that produced the binary.

emily-c 8y ago

I think that disassembling WebAssembly is easier than trying to make sense of a highly minified/obfuscated JavaScript bundle. The time of easily readable web code has been dead for quite a while now I would say.

z3phyr 8y ago

Well, someone is bound to make disassemblers/decompilers/debuggers for us to dissect the innards of the VM. As a side note, I am half expecting the announcement of a web assembly ISA any day.

pjmlp 8y ago
It is just a matter of someone bothering to create a FPGA for it. :)
- TomMarius 8y ago
  It has been explored and it's been decided that it's better to JIT on a classical CPU. Obviously it's still very early so we'll see, but I redirected my excitement to JITs and kernel mode / ring 0 execution.

87 8y ago

I think it's quite the opposite in terms of languages. Javascript will have the best WASM interop story for quite a while. As WASM gets adopted we'll see it get used in all sorts of places outside the browser. Many projects need a high-level scripting language and JavaScript will be the obvious choice.

megaman22 8y ago

If it means the end of JavaScript, I'm all in. Let's get back to having real application languages for applications, and markup languages for text. I hope that we'll come around to the idea that this two-decades long fascination with abusing the hell out of web technology was a fever dream, and go on to build something better on more substantial foundations. I'm probably going to be disappointed...

wrinkl3 8y ago
I don't see Javascript going away anytime soon, tbh. We've already reached the point where it's the first language for a mind-boggling number of developers, it absolutely dominates the frontend frameworks and it's been steadily becoming more popular on the server side.

mchahn 8y ago

> where you could open any web page, understand how it works and learn from it ? Web browsers will/already show wasm disassembly when opened in the browser tools. A file can contain label metadata which makes it very readable.