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

71–80 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#71

Post by moosingin3space »

white-flame wrote: post #61
pfooti wrote: post #58

Earlier quoted context omitted.

Yeah, it's of moderate concern. I can see why it's not really a priority here, since they're probably targeting languages that already don't have GC to compile into WASM, like c++ as a canonical example. I have to imagine that GC is also a pretty huge section of performance / JIT compilation problems in the javascript runtime. So shipping a spec that doesn't support it is no worse than allowing statically compiled co…

The addressable memory space doesn't include code, globals, stack, etc, but only that memory which could be considered the heap. Pointers into memory are 32bit base + 32bit offset, non-wrapping, so 33-bit distances from a base pointer. Each memory access needs a check to that (relatively non-changing) pointer. Memory spaces can request expansion in multiples of 64KB, and can have configured maximum sizes. This leaves…

> The addressable memory space doesn't include code, globals, stack, etc

Really? In that case, how does a language like Rust, where stack allocation is used regularly, compile to WASM?

Re: An Abridged Cartoon Introduction To WebAssembly

#72

Post by moosingin3space »

Rusky wrote: post #52
infogulch wrote: post #49

Earlier quoted context omitted.

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

No, though neither is Javascript. (I am not sure how far along non-WebWorker-based wasm threads are, but here's the proposal: https://github.com/WebAssembly/threads )

Shared-memory threads are something I hope lands in WASM, since they're part of the reason you'd want to drop down to WASM in an application in the first place.

Re: An Abridged Cartoon Introduction To WebAssembly

#73

Post by IvanK_net »

apo wrote: post #45
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?

Right now, "tooling" is quite the same as the tooling for Javascript. You can write your code in a Notepad and the web browser will tell you about errors.

WebAssembly has two representations: a binary form .WASM and a text form .WAST (with one-to-one correspondence). The browser environment can convert between them (or you can write a short piece of code to do it).

If you know C, this website may help you get familiar with WASM syntax: https://wasdk.github.io/WasmFiddle/ (when you press Build, the WASM code will appear at the bottom).

Re: An Abridged Cartoon Introduction To WebAssembly

#74

Post by monkmartinez »

pfooti wrote: post #57
monkmartinez wrote: post #21

Earlier quoted context omitted.

I wholeheartedly agree with your statements. I think there are a legion of developers who would love to program for the web, but refuse to learn|use and simply can not keep up with JS. The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon e…

On the one hand, I hear you and don't disagree - programming ergonomics is a big deal, and access to the language you like is important. I for one really don't want to program in a language that uses significant whitespace, if I can avoid it. On the other hand, "keep up with JS" is something of a misnomer here. It's not javascript that's moving super-fast, it's the web ecosystem (plus the node one, in parallel). It's…

I am not sure I am qualified to really debate the merits of the JS ecosystem; perceived or real at this time. I tried to do front-end stuff when Knockout and Backbone were popular and Node was just starting. Maybe a better phrase is; I had a hard time keeping up... it was the paradigm changes (as you mentioned), but it was also the volume.

Paralyzation due to choice and only so much time to evaluate each framework. Couple that to "staying" power, that is, will this library be around in 6 months? I have taken a peek from time to time and been thoroughly aghast at the volume and not really seeing any of the old stand-bys around.

Now compare that to Python. There is no dearth of choice and one will find many of these choices have been around for more than a decade. They have evolved and changed of course, but not anywhere near the pace of JS. Again, I could take a 3 to 6 month break from looking at Python news and libraries... then come back and jump right into most of the libs I already know. Can a JS dev do that?

> Couple that with some baseline things that aren't changing here

Doesn't webASM give the power to abstract those things away? React creates a virtual DOM, right? Why can't Python create a virtual DOM via webASM?

I stand with you in that I agree things are going to move quickly once Python and others become peers with JS in the browser. I am sure it will be insane as everyone figures out which lib will have staying power like Django, or similar in another lang. I do think that people who generally gravitate toward languages like Python, Go, C#, Java will bring those attitudes with them... that is, they aren't going to re-invent the wheel every three months unless there is a super compelling reason to do so.

Re: An Abridged Cartoon Introduction To WebAssembly

#75

Post by sova »

sqeaky wrote: post #60
sova wrote: post #56

Earlier quoted context omitted.

For example, I just googled briefly for the Chrome WASM platform status and to quote directly, "WebAssembly is in the early stages of language and spec design." Although I would love to have a working model of WASM to play with, the fact is that it is a fresh idea and that any spec you see today will not be around in five years. Wanting WASM to look like C/C++ is so hilariously misguided that I wonder if any programm…

Last night I tried a web assembly demo of Ogre3d, an open source 3d rendering engine. It worked in Chrome and Firefox. (I will put the link here after work, it is sitting in my personal email) Whatever you are reading about the spec is not lining up with the reality of progress. We have two implementations now. I encourage you to read the article, it is a decent primer for someone with your apparent level of knowledg…

Thank you for taking the time to clarify the status of the project to a stubborn mule such as myself.

Re: An Abridged Cartoon Introduction To WebAssembly

#76

Post by Risord »

monkmartinez wrote: post #21
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…

I wholeheartedly agree with your statements. I think there are a legion of developers who would love to program for the web, but refuse to learn|use and simply can not keep up with JS. The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon e…

I agree that js world move fast but there is lot of reinvention of wheel and every new shiny thing have relatively small "payload". Also lot of things are just workarounds for js badparts. Currently I feel that js is out newest Java: clearly technically behind but since it has all the libraries it must be best forever. Of course ecosystem size has benefits but there more than just "they can't keep up with js". Es5 -> es6 -> elm, why bother with hot fixes when major update is available?

Re: An Abridged Cartoon Introduction To WebAssembly

#77

Post by amelius »

aardvark179 wrote: post #19
amelius wrote: post #3

Since JS is already quite fast nowadays, how much faster will WASM typically be? (Yes, I know, it depends. I'm just looking for a rough estimate.)

Well, possibly no faster than can currently be achieved by asm.js if the JIT likes you, but I think discussions of raw speed miss the point. 1. Parsing text based JS is much slower than parsing something like WASM. 2. Initialising data required for programs can take significant time in JS as that data is just a program that must be parsed and run. 3. Those first two points, along with better type support should help…

> WASM seems to provide a pretty good basis for building many things low level things on, but less useful for higher level languages which might want garbage collection

Would it be possible to implement a garbage collector in WASM? And could it be a concurrent garbage collector, using advanced techniques such as memory barriers?

It would be cool if we could run e.g. Haskell or Go in WASM. Or even C programs which rely on the Boehm collector.

Re: An Abridged Cartoon Introduction To WebAssembly

#78

Post by andrewflnr »

gavinpc wrote: post #36
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…

People could be perfectly happy with today's performance levels (or tomorrow's, or yesterday's) if the prevailing systems were designed to serve and empower them, rather than to exploit them. The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se . If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that…

I'm a little confused by this comment. Are you saying it would be better for the world if companies were limited to a "smaller human-resource pool"? Does anyone besides JS devs benefit from that scenario?

Re: An Abridged Cartoon Introduction To WebAssembly

#79

Post by monkmartinez »

andrewflnr wrote: post #78
gavinpc wrote: post #36

Earlier quoted context omitted.

People could be perfectly happy with today's performance levels (or tomorrow's, or yesterday's) if the prevailing systems were designed to serve and empower them, rather than to exploit them. The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se . If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that…

I'm a little confused by this comment. Are you saying it would be better for the world if companies were limited to a "smaller human-resource pool"? Does anyone besides JS devs benefit from that scenario?

Me too, but I am drawing a different conclusion. Perhaps he/she means that companies ultimately drive the market forward as it were. I mean, most people do not strictly trade time/effort for no reward. Reward can mean different things for different people, but I would tend to land on most people trade labor for money. Companies invest in tools all the time, especially internet companies. They would have the bigger reason to get behind efforts that increase the share of developers available.

Re: An Abridged Cartoon Introduction To WebAssembly

#80

Post by drdrey »

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?

Applets were confined to a horrible UI toolkit instead of working natively with the DOM
Post reply on HN