Intro to WebAssembly • Hacker News Board

Re: Intro to WebAssembly

#41

Post by pjmlp » Fri, Jun 30, 2017, 12:12 PM UTC

mvindahl wrote: post #39

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.

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 sl…

It will be like Unity, Unreal do nowadays, and how many plugin runtimes used to do in the past.

The productivity of doing WPF/XAML development with RAD tools like Blend, using an export button to generate an WebAssembly executable.

I might be wrong, but that is where I see it going to.

Re: Intro to WebAssembly

#42

Post by rubber_duck » Fri, Jun 30, 2017, 12:23 PM UTC

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 don't think you should even aim for DOM integration, DOM sucks for apps, having to go trough JS bridge when you need to use it is fine.

I would be much happier if they exposed APIs such as WebGL, user input, IO, etc. to WASM trough WASM specific APIs than wrapping JS ones (but doubt they will do it)

Re: Intro to WebAssembly

#43

Post by timwaagh » Fri, Jun 30, 2017, 1:02 PM UTC

i read it but it does not really explain wasm the language.

Re: Intro to WebAssembly

#44

Post by codelitt » Fri, Jun 30, 2017, 3:01 PM UTC

timwaagh wrote: post #43

i read it but it does not really explain wasm the language.

This was just an intro. There will be a part 2. It's a pretty large subject.

Re: Intro to WebAssembly

#45

Post by codelitt » Fri, Jun 30, 2017, 3:02 PM UTC

nevi-me wrote: post #15

If the author states that there are already a number of Hello World examples, why not spend a bit more time and create something else that's still simple enough? As a self-taught programmer, one of the difficulties I found (before SO) was that the many articles one read up on would typically repeat what someone else said. This especially with new technologies. I think if authors pointed us to an existing "Hello World…

That's fair feedback. There will be a part 2 where we will dig in more. As I mentioned in another comment, it's eating an elephant. 1 bite at a time.

Re: Intro to WebAssembly

#46

Post by ZephyrP » Fri, Jun 30, 2017, 8:12 PM UTC

pjmlp wrote: post #34

TheAceOfHearts wrote: post #31

Earlier quoted context omitted.

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.

I am totally with you on WebAssembly, but I think this is a valid point that can't be swept under the rug.

Screen-readers operating against native applications aren't even close to their utility in browsers. Easy, reasonably universal text hooking is only possible on Windows and some OSX applications and while screen-fetching is universal, it yields extremely poor results in comparison to hooking. Very popular applications occasionally build Narrarator, sythesisprompt or NDK support but today "the web" (specifically HTML) is a much, much better experience for the visually impaired.

Re: Intro to WebAssembly

#47

Post by monocasa » Sat, Jul 01, 2017, 1:10 AM UTC

flohofwoe wrote: post #28

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.

I mean, security issues are just a class of bug. Just because the sandbox keeps you for causing more damage when you stomp on yourself, doesn't mean there's not value in not stomping on yourself at all.

Re: Intro to WebAssembly

#48

Post by couchand » Tue, Jul 04, 2017, 6:09 PM UTC

jjn2009 wrote: post #35

couchand wrote: post #19

Earlier quoted context omitted.

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.

I didn't say WASM was a restricted subset of JavaScript. I understand that it is a lower-level virtual machine, and that in fact it provides some primitives that asm.js doesn't (e.g. 64 bit integers). My point was that if you're looking to WASM to be some kind of silver bullet, you've got the wrong expectations. The causes of people's JavaScript fatigue have little if anything to do with JavaScript the language.