An Abridged Cartoon Introduction To WebAssembly • Hacker News Board

Re: An Abridged Cartoon Introduction To WebAssembly

#51

Post by devrandomguy » Mon, May 15, 2017, 6:36 PM UTC

JBiserkov wrote: post #32

copperx wrote: post #25

Earlier quoted context omitted.

I agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?

So the next generation can't have nice things either :). It seems to me that the history of computing so far can be summarized as "due to popular demand, things have been used far outside their creator's intended scope, with 3-4 non-horrible results". (Lisp is definitely one, can't think of another on the top of my head).

If only we had used Lisps for all the things!

We could have had Lisp instead of JS, but no, that would have worked too well; management wants Java. We almost had a Scheme instead of CSS: DSSSL, which could also do structural transformations of the document tree. But once again, no. The simplicity multiplied by the flexibility of a Lisp, equaled unacceptable complexity, for some strange definition of complexity.

XML looks like it really, really wanted to be a Lisp, what with its orderly nesting of tags. I almost wonder if XML stumbled and fell, due to the supporting pillars of parens being knocked out or corrupted, left, right and center.

Re: An Abridged Cartoon Introduction To WebAssembly

#52

Post by Rusky » Mon, May 15, 2017, 6:41 PM UTC

infogulch wrote: post #49

Rusky wrote: post #48

Earlier quoted context omitted.

Yes, JS and wasm can call each other. In the long run wasm should also be able to call web APIs directly.

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)

Re: An Abridged Cartoon Introduction To WebAssembly

#53

Post by wotamRobin » Mon, May 15, 2017, 6:42 PM UTC

throwasehasdwi wrote: post #18

gavinpc wrote: post #14

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a wo…

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…

At the very least, browsers are the new JRE.

Re: An Abridged Cartoon Introduction To WebAssembly

#54

Post by wotamRobin » Mon, May 15, 2017, 6:48 PM UTC

copperx wrote: post #25

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 agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?

To make an analogy, right now it's possible to write and include C++ modules in your Python scripts, just like it's possible to do with WASM/JS. But people still use Python, because it's a much faster/easier way to get a specific kind of thing done.

So WASM is a great tool, but not a good choice for building something like HN, where perf isn't an issue. Iteration speed, debuggability, and the GC make HTML/CSS/JS a better choice here.

Re: An Abridged Cartoon Introduction To WebAssembly

#55

Post by ericfrederich » Mon, May 15, 2017, 6:51 PM UTC

Currently browsers only support JS. If you want another language you have to transpile to JS or implement your language in JS, etc.

If the browser vendors were going to add another language I would have hoped it would be something so generic like LLVM instead of this WebASM which is too tied to JS.

Re: An Abridged Cartoon Introduction To WebAssembly

#56

Post by sova » Mon, May 15, 2017, 6:52 PM UTC

sqeaky wrote: post #17

sova wrote: post #15

Earlier quoted context omitted.

Webscale? I don't know, and I am really unclear as to why people are already writing about webASM, there is hardly an agreed-upon standard so far. In my professional opinion as a Computational Scientist, I believe a LISP-like graphically-enabled DSL for the Web that worked simply and easily with: Web Forms, Graph Query for endpoints, and had a sensible GUI layering would be perfect for the next 200 years of screen. I…

I think you have a different framing of the problem most people excited about WASM have. It is not about talking directly to the hardware, just getting speed gain like you are. So this component idea seems to be coming from out of the blue and indicates to me you haven't paid webassembly much attention until now. Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't…

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 programmers have been paying attention to language evolution in the past 5 decades.

Yes, Javascript is the best we can do at the moment, and that is truly sh. I do not disagree. My latest progress with regards to that is using something that compiles to JS, but there is still the indefatigable issue of having to use Javascript.

To me, WASM is an initiative to redesign the language behind the screen, and anything short would be inadequate because Javascript already does almost everything, just in an incredibly roundabout, piecemeal, poorly evolved way.

So, you are right in assuming I have not been paying attention to the news in the world of Web ASM, but I must also appeal to your logic and say that any of the news you read now is just theoretical debate. Maybe I should take up my issues with the language designers, as that may prove more fruitful.

Re: An Abridged Cartoon Introduction To WebAssembly

#57

Post by pfooti » Mon, May 15, 2017, 6:52 PM UTC

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…

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 moving fast because new ideas are evolving at speed (functional-reactive approaches, new ways to think about mixins vs multiple inheritance, etc), and those ideas lead to new framework architectures gaining popularity as they exploit these new ways of thinking about organizing data flow through a complicated system.

Couple that with some baseline things that aren't changing here - you're still going to have to interact with the DOM, you aren't going to magically get re-entrant multithreading, and the event model isn't changing. There's still going to be a lot about web programming that feels different from systems programming, and things are still going to move quickly. Probably even more quickly (but I'm not certain about that - I imagine one major reason JS shifts quickly is that it has so many programmers working with it, if the population fragments there will probably be a number of slow-moving communities that neither shift often nor take advantage of new features, which feels like the kind of neophile - neophobe split that's already apparent in different areas of programming).

So: I am not convinced that a (say) rust or go compiler to WASM will suddenly make front-end programming feel like systems programming. It'll be a new language, sure, but there's a lot more to web development and the (reasonable) complaints people have about a shifting landscape than just javascript and its funky definition of OO and triple equals sign.

Re: An Abridged Cartoon Introduction To WebAssembly

#58

Post by pfooti » Mon, May 15, 2017, 6:58 PM UTC

vivin wrote: post #26

> For now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Does this worry anyone else? Or I am getting worked up over nothing?

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 code to run on desktop computers.

That said, I wonder how the WASM runtime is sandboxed. Not having a runtime-provided memory manager makes me worry not just about memory leaks, but also about explicit shenanigans in different memory zones. It's hard to believe that a WASM runtime doesn't protect against this sort of escaping though, so it's more of an academic wondering than a real concern.

Re: An Abridged Cartoon Introduction To WebAssembly

#59

Post by kowdermeister » Mon, May 15, 2017, 7:16 PM UTC

I'll find it really amusing when devs outside the frontend world will storm in, devs who currently hate working with the browser because of JavaScript. The problem they will face is that a nice UI will still be needed. Since they will probably hate the DOM even more than than JS now they can just omit it. A canvas is canvas, right? :)

But then the next obvious problem will kick in. What should we use to implement a UI. GTK? WxPython? Swing? Tkinter? QT? JavaFX? Great candidates :) It will just be great. I mean not, but it will happen, because JS and "browser tech" is considered sub par (not by me, but I keep reading this).

WebAssembly will bring in lots of innovation, opportunities and also create the next level chaos. We will look back to the tooling hell as the good old days of frontend development :)

Re: An Abridged Cartoon Introduction To WebAssembly

#60

Post by sqeaky » Mon, May 15, 2017, 7:17 PM UTC

sova wrote: post #56

sqeaky wrote: post #17

Earlier quoted context omitted.

I think you have a different framing of the problem most people excited about WASM have. It is not about talking directly to the hardware, just getting speed gain like you are. So this component idea seems to be coming from out of the blue and indicates to me you haven't paid webassembly much attention until now. Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't…

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 knowledge. I assure you web assembly is not an attempt to replace javascript or make javascript look like C/C++, though you imply you believe such when you say things like "Wanting WASM to look like C/C++ is so hilariously misguided". I am not sure how language design factors into, if someone were so inclined they could compile JS to Wasm and have similar performance gains if the compiler optimized well.

Wasm is about nothing more than performance and they have nailed it. It is very fast compared to javascript, though it is slower than the C or C++ compiled to a native executable.