Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Abridged Cartoon Introduction To WebAssembly

smashingmagazine.com

Post reply on HN
Print view View original

41–50 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#41

Post by khedoros1 »

thaumasiotes wrote: post #29
throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?

I'd assume something like the conceptual difference between HTML5 canvas/video ("good") and Flash ("bad"). No plugins. Better sandboxing. Open specification not owned by some specific company. An expectation of multiple competing implementations.

Basically, it's a lot of the same stuff, but a (hopefully) better implementation, and promoted in a way that appeals to the people likely to use it. Start with an old technology. Tweak, relabel, and market under the new name.

Re: An Abridged Cartoon Introduction To WebAssembly

#42

Post by westoncb »

tamat wrote: post #39

after reading many tutorials about WASM I still figured out one of the most important questions for me: Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds. Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know wh…

It seems like it would be a little backward to go from WASM to javascript in order to invoke native code (in e.g. an OpenGL driver). More likely WASM will have some way of its own to interface with such things. Right?

Re: An Abridged Cartoon Introduction To WebAssembly

#43

Post by rustyhacker »

throwasehasdwi wrote: post #18
gavinpc wrote: post #14

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a wo…

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

I'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now.

Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web.

I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and secondly the speed of development. As much I complain about writing js code, it's a lot faster to get things done compared to Rust/C++.

Re: An Abridged Cartoon Introduction To WebAssembly

#44

Post by Rusky »

thaumasiotes wrote: post #29
throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?

Java applets have a radically different security model from Javascript and wasm. There's only thing that makes wasm any closer to Java applets than Javascript already is- it's distributed as a bytecode that's not dynamically typed, rather than text.

But Javascript's dynamically typed textual representation has nothing to do with what makes it better than Java applets. It's the security model, which wasm shares.

Re: An Abridged Cartoon Introduction To WebAssembly

#45

Post by apo »

IvanK_net wrote: post #24

They often forget to mention, that WebAssembly is just a low-level programming language (much lower than C), it has extremely simple syntax (it has just four data types, no system calls, the specification takes 5 pages instead of 500 pages of C spec). You may call it a "bytecode", but typical bytecodes also have around-500-page specifications. Also, its relation to javascript is not any bigger than the relation to an…

Really helpful link. What's the current state of tooling to directly write WebAssembly? What assembler/editor/debugger you would you recommend?

Re: An Abridged Cartoon Introduction To WebAssembly

#46

Post by khedoros1 »

acomjean wrote: post #28
hmottestad wrote: post #23

Earlier quoted context omitted.

Same way you would C code. Tell the compiler you want to compile for debugging, and then connect your debugger to the running program. Marks in the code will tell your debugger what things are called and which line in the source code you are on. JS today is often transpiled anyway, so you have to use some mapping to the source code to do debugging (eg. source maps).

Thanks I figured the built in browser debuggers wouldn't work so well for this.

The debuggers would need to be modified to support it, but I don't think there's a reason that you couldn't debug wasm inside a browser, if they were built to understand the debug annotations in the wasm code.

Re: An Abridged Cartoon Introduction To WebAssembly

#48

Post by Rusky »

tamat wrote: post #39

after reading many tutorials about WASM I still figured out one of the most important questions for me: Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds. Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know wh…

Yes, JS and wasm can call each other. In the long run wasm should also be able to call web APIs directly.

Re: An Abridged Cartoon Introduction To WebAssembly

#49

Post by infogulch »

Rusky wrote: post #48
tamat wrote: post #39

after reading many tutorials about WASM I still figured out one of the most important questions for me: Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds. Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know wh…

Yes, JS and wasm can call each other. In the long run wasm should also be able to call web APIs directly.

Is wasm also restricted to running on one thread like js?

Re: An Abridged Cartoon Introduction To WebAssembly

#50

Post by amyjess »

thaumasiotes wrote: post #29
throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?

Conceptually? It's not that different, and the only problems with Java were its implementation.

* Java was plagued with security problems. One area where Java really shot itself in the foot was that unsigned applets were sandboxed, but signed applets had unfettered access to everything, so you had to choose between signing and sandboxing. And then once security concerns became a big thing, Sun responded by killing support for unsigned applets saying it'll increase trust, but what they really did was make the problem worse by killing the sandbox.

* Java was proprietary until long after its star had fallen.

* Java was introduced when computers weren't that powerful. The JVM took forever to start up and would slow down your whole computer while running. Most of us kept Java disabled unless we had to use an applet for something just because of the massive performance hit.

You can make similar arguments about Flash, too: it too had security holes, proprietary software, and performance issues.

There is one thing I really liked about Java and Flash, though: you could turn it off. If you don't want a site loading some heavy Flash monstrosity and eating all your RAM (I had so many issues with Flash killing the RAM on my old laptop with only 512 MB of RAM), you could just turn plugins off or install an extension to force you to click to load Flash content. You can't do that with JavaScript, so maybe WASM will bring that part of the old days back too.

Post reply on HN