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

WebAssembly becomes a W3C Recommendation

w3.org

Post reply on HN
Print view View original

231–240 of 248 posts

Re: WebAssembly becomes a W3C Recommendation

#231

Post by traverseda »

baja_blast wrote: post #152
LessDmesg wrote: post #15

Now if only we get a good web-oriented Python with a WASM backend, we'll finally be able to throw Javascript where it belongs: into the dustbin of history.

Python would be a bad choice for the web since it was not designed around events. JS was designed specifically to turn on top of a browser with an event loop to respond to events as they happen. Python would just make a slow non responsive browsing experience. Also WASM wasn't designed for "any languages goes" in mind, it was designed for lower level languages like C/Rust which have manual memory management to run hi…

Python wasn't designed around events, but using python-style async/await syntax under javascript has made my life a lot easier.

Re: WebAssembly becomes a W3C Recommendation

#232

Post by nine_k »

c-smile wrote: post #195

Some retrospective ... Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times. WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way. WebAssembly is…

JVM is seriously more complex and heavier-weight. It does too much, and is shaped by Java the language too much (no functions, only objects!). It brings in mandatory GC. It's built around shared mutable data.

WA is much smaller, assumes way less, is isolated from DOM and JS code way better, communicates with them via message-passing. It has a smaller attack surface, and less room to screw up in the implementation.

Yes, I think not having WA married to DOM is a good idea from many angles. One of them is security, of course. Another is wider applicability: a WA VM could be useful outside the browser, and it already is.

Re: WebAssembly becomes a W3C Recommendation

#233

Post by [deleted] »

mollyporph wrote: post #148
kllrnohj wrote: post #79

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

We use it at IKEA to use a c-based OCR library in a pwa. And other small things like that. Like a legacy integrator.

[deleted]

Re: WebAssembly becomes a W3C Recommendation

#234

Post by lucasverra »

mollyporph wrote: post #148
kllrnohj wrote: post #79

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

We use it at IKEA to use a c-based OCR library in a pwa. And other small things like that. Like a legacy integrator.

could you name or recommend an open source library for OCR on web that is good enough for ikea ?

Re: WebAssembly becomes a W3C Recommendation

#235

Post by BlueTemplar »

gnulinux wrote: post #153
BlueTemplar wrote: post #103

Earlier quoted context omitted.

The "web" app will have worse performance.

You mean for accessibility? Maybe but there shouldn't be any fundamental reason why an accessibility tool can read a windows app and not web app, since under the hood Chrome and Firefox can use the same interface this tool interfaces with. If you meant performance in terms of runtime, I'm not convinced this is the case. Obviously WebAssembly will have some overhead, but I don't think the overhead is critical enough f…

You're right, it might be only so slightly worse as to not matter, or be better than a language that is close to the metal, but with worse design.

Obviously, for such a wide prediction I can only speak theoretically...

Re: WebAssembly becomes a W3C Recommendation

#236

Post by snak »

int_19h wrote: post #224
adrianmonk wrote: post #84

Earlier quoted context omitted.

One could still ask the question, though. The way that coding language and deployment/executable language have been tied together (JS for both) has served as a force that pushed everyone toward that single language. Now that WebAssembly promises to remove that force, will it be a free-for-all, or will other forces push toward standardization on a few languages? And if so, what will those forces be?

Likely the ones that are on the bandwagon early. To be even more specific, in the early days now, the main allure of wasm is performance. So the focus will be on languages and toolchains capable of generating optimized native code. Out of those, look at which ones are easy for the developer to set up (both in general, and for wasm) on all popular developer OSes. So, I'd say that Rust will probably be the biggest bene…

C#/.NET will be in that bandwagon. They have been pushing WebAssembly usage with their Blazor framework.

Re: WebAssembly becomes a W3C Recommendation

#237

Post by prashnts »

lucasverra wrote: post #234
mollyporph wrote: post #148

Earlier quoted context omitted.

We use it at IKEA to use a c-based OCR library in a pwa. And other small things like that. Like a legacy integrator.

could you name or recommend an open source library for OCR on web that is good enough for ikea ?

(Not GP) I haven’t tried it myself yet but tesseract.js’s demo looks promising.

https://tesseract.projectnaptha.com/

Re: WebAssembly becomes a W3C Recommendation

#238

Post by tcard »

weberc2 wrote: post #83
Jasper_ wrote: post #19

Earlier quoted context omitted.

The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem. [0] https://github.com/webassembly/interface-types

I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with infor…

In mobile code, a builtin runtime means less code to download, which may be preferable to GC performance.

Re: WebAssembly becomes a W3C Recommendation

#239

Post by chubot »

Lx1oG-AWb6h_ZG0 wrote: post #223
chubot wrote: post #220

Earlier quoted context omitted.

OK, yeah the "metal" part is fair. He showed asm.js and then posited that there would be something called "metal" that causes JavaScript to die and enables application written in more languages. And major apps could be ported to it. Originally my conception of the video was more like this commenter below: It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly lang…

> Also, JS is at a pretty good level of abstraction to manipulate the DOM I agree with your point in general, but surely the fact that there are 10 million js frameworks invented every week is proof that the native DOM APIs are not a good abstraction? As a mostly front end dev, most of my UI logic these days target _React_, not the dom APIs. To the extent that I write JavaScript, it’s pure data manipulation, which ca…

That's true, although for another example, React is also commonly used with JSX to express DOM fragments. And JS has that syntax but Python, C, Rust, etc. don't.

In other words, the particulars of the language matters. I wouldn't underestimate 20+ years of JS evolution toward expressing the problem better.

I'm working on my own language and all those details are hard. When they work, they're invisible to users. You only notice when it's not there or doesn't work! I would agree that Python is a better language than JS in most respects, but it's not clear to me that it's a better language for writing web front ends.

e.g. the async abstractions and promises are different and I believe that matters.

Re: WebAssembly becomes a W3C Recommendation

#240

Post by adrianmonk »

int_19h wrote: post #224
adrianmonk wrote: post #84

Earlier quoted context omitted.

One could still ask the question, though. The way that coding language and deployment/executable language have been tied together (JS for both) has served as a force that pushed everyone toward that single language. Now that WebAssembly promises to remove that force, will it be a free-for-all, or will other forces push toward standardization on a few languages? And if so, what will those forces be?

Likely the ones that are on the bandwagon early. To be even more specific, in the early days now, the main allure of wasm is performance. So the focus will be on languages and toolchains capable of generating optimized native code. Out of those, look at which ones are easy for the developer to set up (both in general, and for wasm) on all popular developer OSes. So, I'd say that Rust will probably be the biggest bene…

The performance angle is interesting. Right now JS has lots of mindshare and momentum for obvious reasons, so maybe the things that will take off at first are the ones that help web developers in specific areas where JS performance is not good enough, perhaps graphics for example.
Post reply on HN