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

Intro to WebAssembly

codelitt.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Intro to WebAssembly

#31

Post by TheAceOfHearts »

pjmlp wrote: post #26
TheAceOfHearts wrote: post #25

Earlier quoted context omitted.

I think people are severely underestimating the challenges of integrating WASM with JS an DOM. Right now styling and DOM are the two biggest performance bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't terrible out of the box. Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.

Not really, when WebAssembly gets better it will be the revenge of Java, Flash and Silverlight. Future web applications will be mainly plain WebAssembly + Canvas + WebGL.

Won't using Canvas or WebGL to render all content kill accessibility?

Re: Intro to WebAssembly

#32

Post by pjmlp »

bluejekyll wrote: post #30
pjmlp wrote: post #27

Earlier quoted context omitted.

For me Rust is a deja vu experience, in a certain sense. I started to use C++ around 1992, on MS-DOS, as my next loved programming language after Turbo Pascal. Never saw any value in plain C, other than writing code unsafer as straight Assembly (Assembly has less UB than C). Have taken part in C vs C++ flamewars on Usenet since those days, only to see C++ finally overtaking C in many fields in the last 10 years. In s…

By no means do I believe it will overtake these other languages quickly. But one huge benefit that Rust has over these others is this idea of "fearless programming". Watching Ruby Devs jump into Rust, fight the compiler for a bit, but then have a blazing fast app with some very detailed systems level interaction, is amazing. On top of that, it never segfaults! Jumping into C and C++ is in my own experience, much more…

I agree, but also feel a bit sorry for Ruby devs, in the sense that they could have had that experience with Dylan or even with Apple's short love with a Ruby AOT compiler (which eventually became RubyMotion), while staying in Ruby.

Re: Intro to WebAssembly

#33

Post by pjmlp »

kabes wrote: post #29
pjmlp wrote: post #26

Earlier quoted context omitted.

Not really, when WebAssembly gets better it will be the revenge of Java, Flash and Silverlight. Future web applications will be mainly plain WebAssembly + Canvas + WebGL.

But that's already possible today without WASM. E.g. there are react plugins that render to canvas, as being used here together with some WebGL: http://www.anagram.paris/ (try to drag). And yet, we don't see this often being used. Instead, we see more DOM being used on new places (e.g. electron applications). I think if WASM+Canvas would be the way forward, we'd have already seen it by now, since it was already possi…

Yes, but today it requires using JS or compiling into asm.js, which isn't always possible to keep the original language semantics.

WebAssembly is just yet another virtual CPU. more suitable as target for Go, .NET, Java, Flash, ....

They only need to target the framebuffer routines into Canvas/WebGL and we get desktop frameworks inside of a browser frame.

Re: Intro to WebAssembly

#34

Post by pjmlp »

TheAceOfHearts wrote: post #31
pjmlp wrote: post #26

Earlier quoted context omitted.

Not really, when WebAssembly gets better it will be the revenge of Java, Flash and Silverlight. Future web applications will be mainly plain WebAssembly + Canvas + WebGL.

Won't using Canvas or WebGL to render all content kill accessibility?

Native UIs have better accessibility support than the browser.

They only need to bring them along with the plugins, to what would become a portable framebuffer.

Re: Intro to WebAssembly

#35

Post by jjn2009 »

couchand wrote: post #19
michaelchisari wrote: post #12

Earlier quoted context omitted.

Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards. But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code. People talk about Javascript fatigue, and it's real and exhausting to keep up with the constan…

If the problem is really just JavaScript itself WASM won't be able to help -- WASM is basically just asm.js, which is just a restricted subset of JavaScript, but easier to parse and optimize.

>a restricted subset of JavaScript

This actually isn't the case. Browsers provide a virtual machine which can run assembly code with web assembly, its that simple, nothing about it necessitates javascript except that its the interface to the DOM, in the future it could very well be possible to have a new script tag type which is ASM and requires zero javascript or javascript runtime.

Re: Intro to WebAssembly

#36

Post by jjn2009 »

zzo38computer wrote: post #18
jjn2009 wrote: post #6

Earlier quoted context omitted.

DOM manipulation isn't currently supported, for now you will need to provide a javascript layer between the C code and DOM. Its in the roadmap to create these interfaces. Web assembly is better suited for CPU intensive tasks which you would want to offload from javascript but keep on the client.

I think that DOM manipulation should not be a part of WebAssembly, although the other way around may make some sense, where for example, the "window.wasm" property might be a WebAssembly module for accessing the HTML DOM (otherwise the module is not included and the WebAssembly code is sandboxed and cannot access DOM). If the WebAssembly module is loaded directly using a "script" tag in a HTML document, then it can a…

Its inevitable that all of those who want to replace javascript will push facilities into the web assembly spec to remove javascript from the equation.

Re: Intro to WebAssembly

#37

Post by jjn2009 »

michaelchisari wrote: post #12
jjn2009 wrote: post #7

Earlier quoted context omitted.

the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.

Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards. But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code. People talk about Javascript fatigue, and it's real and exhausting to keep up with the constan…

Well on one hand you will definitely increase the number of ways to do DOM manipulation, but on the other isolated communities could move at different paces. I think its hard to say if the dominate mode of ui web dev will slow down, I've definitely experienced this fatigue, its a huge issue. Some how the unix way of small composable parts which work well needs to find its way to the browser.

Re: Intro to WebAssembly

#39

Post by mvindahl »

pjmlp wrote: post #26
TheAceOfHearts wrote: post #25

Earlier quoted context omitted.

I think people are severely underestimating the challenges of integrating WASM with JS an DOM. Right now styling and DOM are the two biggest performance bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't terrible out of the box. Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.

Not really, when WebAssembly gets better it will be the revenge of Java, Flash and Silverlight. Future web applications will be mainly plain WebAssembly + Canvas + WebGL.

There is a tradeoff between development speed and execution speed. For web apps, development speed is usually the most important of the two and the language ironing away the most technical details tends to be a strong choice.

Roughly speaking, C is further from the metal than assembly (and WASM) for obvious reasons; Java is further from the metal than C (or Rust) due to having garbage collection, and Javascript is slightly further from the metal than Java due to abstracting away threads (the gap was far wider before Java got lambdas). LISP, of course is off the scale due to abstracting away readability ;)

On a serious note, though, I don't see the advantage that Java or Flash or Silverlight would bring to web apps unless they bring greater development speed.

But I do see WASM as an excellent future supplement to JS-based apps, for optimizing time consuming parts of the code.

Re: Intro to WebAssembly

#40

Post by mbel »

IshKebab wrote: post #38

Is anyone experimenting with using WebAssembly in non-web contexts? Could be great for cross-platform native apps, microcontrollers, etc.

What benefits do you expect? Which of them aren't provided today by JVM or .Net?
Post reply on HN