WebAssembly becomes a W3C Recommendation • Hacker News Board

Re: WebAssembly becomes a W3C Recommendation

#221

Post by wahern » Tue, Dec 17, 2019, 2:08 AM UTC

LessDmesg wrote: post #58

janpot wrote: post #17

Earlier quoted context omitted.

Honest question, in what sense is python a so much better choice for web development? syntax? subjective, and it would also mean all C-likes belong in the dustbin. performance? Why would python, as a language, be significantly more performant? It's just as dynamic. ecosystem? JS community is huge, JS package managers are huge (even though not flawless, but nothing their python counterparts do better) I mean I can sur…

For one thing, not being broken. Python doesn't have ("1"+1) and similar design flaws, Python doesn't need a new ECMAscript standard every year, Python has figured out modules and classes much earlier, and frankly, Python is what Javascript is only becoming after years of improvement. Really, I don't understand why we and the browser maintainers have to put up with a broken, insane language when there is a similar bu…

> Python has figured out modules... much earlier,

You expect that to carry over to WASM environments?

Re: WebAssembly becomes a W3C Recommendation

#222

Post by dwohnitmok » Tue, Dec 17, 2019, 3:08 AM UTC

chubot wrote: post #220

dwohnitmok wrote: post #111

Earlier quoted context omitted.

I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages c…

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…

The video creator is on HN so if the gods of internet attention shine upon us he may be able to comment here.

In lieu of that, I'll offer my one-line take of the prediction of the video. JavaScript will fade from popularity, but its (original) popularity will inspire a low-level assembly-like language (looking more and more like WebAssembly these days) that will provide a new substrate for most application development, web-based or otherwise, replacing traditional binaries.

As you point out it's not at all clear, even five years on from this talk, that this prediction will be correct. WebAssembly is currently complementary to JS and cannot fully replace it. The vast majority of websites these days use JS but not WebAssembly. Use of WebAssembly for applications that traditionally have not been run inside a web browser (e.g. GIMP, LibreOffice, etc.) is still nascent and it's nowhere near a sure bet that it'll take off there.

But maybe, just maybe, it'll happen.

Re: WebAssembly becomes a W3C Recommendation

#223

Post by Lx1oG-AWb6h_ZG0 » Tue, Dec 17, 2019, 3:22 AM UTC

chubot wrote: post #220

dwohnitmok wrote: post #111

Earlier quoted context omitted.

I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages c…

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 can be written in any language.

Re: WebAssembly becomes a W3C Recommendation

#224

Post by int_19h » Tue, Dec 17, 2019, 4:17 AM UTC

adrianmonk wrote: post #84

diegoperini wrote: post #65

Earlier quoted context omitted.

LLVM kinda proved having a common target back-end doesn't kill language diversity, it actually achieves the opposite.

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 beneficiary.

Re: WebAssembly becomes a W3C Recommendation

#225

Post by int_19h » Tue, Dec 17, 2019, 4:26 AM UTC

dwohnitmok wrote: post #222

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…

The video creator is on HN so if the gods of internet attention shine upon us he may be able to comment here. In lieu of that, I'll offer my one-line take of the prediction of the video. JavaScript will fade from popularity, but its (original) popularity will inspire a low-level assembly-like language (looking more and more like WebAssembly these days) that will provide a new substrate for most application developmen…

The sheer number of big corporate backers, and standardization, is what will make it happen. That's really what is different here versus Java applets, Silverlight, NaCl etc. Those all failed because nobody was big enough to single-handedly push something like that onto the ecosystem. Now that they're acting in concert, things are very different.

Everything else is "just engineering". E.g. as far as being complementary to JS, and not being able to replace it - they are already working on access to DOM.

Re: WebAssembly becomes a W3C Recommendation

#226

Post by int_19h » Tue, Dec 17, 2019, 4:35 AM UTC

nerdponx wrote: post #34

goatlover wrote: post #23

Earlier quoted context omitted.

> because the DOM and JS (meaning the GC) are very coupled. This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.

It's interesting that the web standardized on one programming language. In hindsight I feel like this isn't surprising. How many platforms (that aren't themselves operating systems) support scripting in more than one language? Vim/Neovim is the only one I can think of off the top of my head.

It's easy forget these days, but Windows had this thing called Active Scripting, that was basically a set of COM-based interfaces for scripting languages to expose their functionality OS-wide, and for apps to use any scripting language available on the system. And Internet Explorer, at the peak of its popularity, used that interface to implement the tag - so long as the user had some language installed on their machine, it could be used to script web pages in IE. Active Scripting came with JavaScript and VBScript supported out of the box, which is why both were available in IE. But there were quite a few third-party ones - I recall seeing Perl, Python, Tcl, and REXX.

But, of course, other browsers didn't have that. And even at the time when some websites really only cared about IE, they couldn't assume that people had any third-party runtimes installed - so you very occasionally saw VBScript, but pretty never anything else.

Re: WebAssembly becomes a W3C Recommendation

#227

Post by int_19h » Tue, Dec 17, 2019, 4:37 AM UTC

shantly wrote: post #184

mark_thompson wrote: post #162

Earlier quoted context omitted.

Was going to ask in the main thread but perhaps here is a better place. For someone just starting with programming, but targetting WASM, which would be a good first programming language? Java? In my particular case, I've been learning Python for Data Analysis for about one year, and a few months of Haskell (love Haskell so far, but my interest/job is related to data analysis and web dev). I've heard bad things about…

Since Java relies on the JVM I think I'd avoid it, and any other languages that'd require running another VM on top of the WASM VM. Seems like useless stacking of technology that serves basically the same purpose. Not saying it wouldn't work and that it won't be done, but just seems kinda gross and missing-the-point. Personally I'd also avoid anything with a fatter runtime than maybe Go or C#. If it doesn't already,…

Speaking of C# and wasm, take a look at Blazor.

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Re: WebAssembly becomes a W3C Recommendation

#228

Post by int_19h » Tue, Dec 17, 2019, 4:44 AM UTC

didibus wrote: post #199

eb0la wrote: post #68

Earlier quoted context omitted.

For me Java is legacy. A good runtime for the web will have a lot of developers worldwide. I am betting on it not just for the web, but to replace legacy apps as soon as we get a good runtime not just for the web. Probably Electron can be one of such new runtimes

I don't know what your experience with the JVM is, but it really isn't legacy. It's actually much more state of the art. Can you explain a bit more in what way you see it as legacy? Because the JVM has some of the best GCs, and JIT + AOT compilation of any VM around. And its portability story is quite impressive. You can argue Java as a language has some legacy hanging around, though they've made great progress there…

> Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages.

Not necessarily. The problem is that JVM is too high-level, and imposes not just a memory model, but also an object model, with many constraints to impose memory safety. That can be difficult to work around without performance penalties. So languages that are designed to target JVM from the get go, tend to be designed with those limitations in mind, constraining them.

.NET bytecode is somewhere in the middle between that and wasm. It has things such as raw pointers and pointer arithmetic, dynamic allocation of stack, unions, and other things that aren't memory-safe. This allows languages that don't want to have memory safety imposed on them (like C++), or that have their own ideas about how to impose it properly (like Rust), do whatever they want, and run efficiently on top of CLR. But it still has that high-level object model, much like JVM, which can be used for interop that's higher-level than just a C ABI.

wasm, for the time being at least, is a VM that is limited to a C ABI. Their future plans, such as interface types, can potentially approach the complexity of the JVM and CLR object models, but with more isolation boundaries (because memory isn't shared between modules).

Re: WebAssembly becomes a W3C Recommendation

#229

Post by [deleted] » Tue, Dec 17, 2019, 4:51 AM UTC

cbhl wrote: post #139

dwohnitmok wrote: post #111

Earlier quoted context omitted.

I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages c…

> Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer. By…

[deleted]

Re: WebAssembly becomes a W3C Recommendation

#230

Post by strbean » Tue, Dec 17, 2019, 4:59 AM UTC

LessDmesg wrote: post #58

janpot wrote: post #17

Earlier quoted context omitted.

Honest question, in what sense is python a so much better choice for web development? syntax? subjective, and it would also mean all C-likes belong in the dustbin. performance? Why would python, as a language, be significantly more performant? It's just as dynamic. ecosystem? JS community is huge, JS package managers are huge (even though not flawless, but nothing their python counterparts do better) I mean I can sur…

For one thing, not being broken. Python doesn't have ("1"+1) and similar design flaws, Python doesn't need a new ECMAscript standard every year, Python has figured out modules and classes much earlier, and frankly, Python is what Javascript is only becoming after years of improvement. Really, I don't understand why we and the browser maintainers have to put up with a broken, insane language when there is a similar bu…

I feel like almost every one of those points is highly debatable.

- New ECMA standard every year VS. new PEPs every year

- Modules and classes: cyclic dependency hell, obscure multi-import issues, __init__.py ugliness, imperative class declaration. Python only figured these things out much earlier to the extent that it has actually figured these things out.

...