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

21–30 of 48 posts

Re: Intro to WebAssembly

#21

Post by zurn »

bluejekyll wrote: post #9
Klathmon wrote: post #3

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all. JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really im…

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It…

JS is a much better compile target for many languages for the foreseeable future. "Without JS" is not a sensible end in itself.

Re: Intro to WebAssembly

#22

Post by bluejekyll »

kjksf wrote: post #11
bluejekyll wrote: post #8

I'm really surprised to read an article like this that doesn't mention Rust. The reason is that I find it hard to believe that developers will want to move to unsafe languages like C/C++. Many of the other languages mentioned require runtimes, runtimes that will need to be built on top of webassembly. Rust doesn't have any of these drawbacks, is runtime free, and can already target webassembly. Given that both of the…

WebAssembly is in a large part about re-using vast quantities of existing C/C++ code in the browser. C++ will dominate in that space over Rust for the same reason it'll dominate in all other spaces: the amount of existing C++ code and the number of existing C++ programmers will always dwarf the amount of Rust code and Rust programmers. Even if Rust was uniformly 10-20% better than Rust, economics dictate that for mos…

I tend to agree with you in the context of porting existing C/C++ code to the Web is going to follow exactly the pattern you mention.

But, for new software, with no previous dependencies? The stdlib in Rust is decent, and the ecosystem is growing quickly. For new projects, I do think these will help in it's adoption in a new environment like WebAssembly, but we shall see!

Re: Intro to WebAssembly

#24

Post by 6nf »

Klathmon wrote: post #3

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all. JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really im…

> JavaScript is going to continue to be used as "glue code"

This is a temporary situation. Eventually you'll be able to do everythign in WebAssembly, including DOM access etc. How long that will take is anyone's guess but it's certainly on the minds of the wasm team.

Re: Intro to WebAssembly

#25

Post by TheAceOfHearts »

bluejekyll wrote: post #9
Klathmon wrote: post #3

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all. JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really im…

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It…

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.

Re: Intro to WebAssembly

#26

Post by pjmlp »

TheAceOfHearts wrote: post #25
bluejekyll wrote: post #9

Earlier quoted context omitted.

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It…

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.

Re: Intro to WebAssembly

#27

Post by pjmlp »

bluejekyll wrote: post #22
kjksf wrote: post #11

Earlier quoted context omitted.

WebAssembly is in a large part about re-using vast quantities of existing C/C++ code in the browser. C++ will dominate in that space over Rust for the same reason it'll dominate in all other spaces: the amount of existing C++ code and the number of existing C++ programmers will always dwarf the amount of Rust code and Rust programmers. Even if Rust was uniformly 10-20% better than Rust, economics dictate that for mos…

I tend to agree with you in the context of porting existing C/C++ code to the Web is going to follow exactly the pattern you mention. But, for new software, with no previous dependencies? The stdlib in Rust is decent, and the ecosystem is growing quickly. For new projects, I do think these will help in it's adoption in a new environment like WebAssembly, but we shall see!

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 some fields, like embedded programming, C still reigns over C++.

So while I look forward to have my managed languages, OSes and performance critical libraries written in a safer language, my life experience tells me it will take a few decades to achieve the same level of market adoption.

Re: Intro to WebAssembly

#28

Post by flohofwoe »

bluejekyll wrote: post #8

I'm really surprised to read an article like this that doesn't mention Rust. The reason is that I find it hard to believe that developers will want to move to unsafe languages like C/C++. Many of the other languages mentioned require runtimes, runtimes that will need to be built on top of webassembly. Rust doesn't have any of these drawbacks, is runtime free, and can already target webassembly. Given that both of the…

Rust's compile-time safety guarantees are a lot less appealing if the generated code runs ins a sandbox anyway. If the C/C++ code compiled down to wasm goes haywire it is not a security concern, 'only' an inconvenience for the user.

Re: Intro to WebAssembly

#29

Post by kabes »

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.

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 possible in plain JS or with asmjs if you really hate JS that much.

In the end, HTML & CSS is fast enough for most business-style applications and frameworks like angular/vue/react are pretty good ways to make frontends.

Re: Intro to WebAssembly

#30

Post by bluejekyll »

pjmlp wrote: post #27
bluejekyll wrote: post #22

Earlier quoted context omitted.

I tend to agree with you in the context of porting existing C/C++ code to the Web is going to follow exactly the pattern you mention. But, for new software, with no previous dependencies? The stdlib in Rust is decent, and the ecosystem is growing quickly. For new projects, I do think these will help in it's adoption in a new environment like WebAssembly, but we shall see!

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 difficult. All of the complexity of those languages disappears into the Compiler in Rust. I think the big thing here is that Rust can appeal to many developers from all walks, not just those of us who've spent years or decades with Assembly/C/C++.

Post reply on HN