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

Compiling to WebAssembly: It’s Happening

hacks.mozilla.org

Post reply on HN
Print view View original

201–210 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#201

Post by lispm »

nostrademons wrote: post #23
klodolph wrote: post #14

Earlier quoted context omitted.

I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your…

Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those…

> Richard Gabriel founded a company to write software for Lisp Machines,

The company Gabriel founded (Lucid Inc.) was never supposed to write software for Lisp Machines. Its mission from day zero was to develop a Common Lisp implementation for stock hardware (SUNs, etc.). Symbolics, the Lisp Machine maker, refused to fund a portable Common Lisp implementation (which Gabriel and Benson, the latter then at Symbolics, proposed).

> found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business

Actually the Lisp business of Lucid Inc. financed the C++ development.

It was a gamble. They easily could have continued to develop and sell Common Lisp (their main competitors from that time, Franz Inc. and LispWorks are still alive) and stay in a small/shrinking niche. But Lucid tried to diversify and to grow. The idea was to write a C++ environment with a similar and improved development experience as a Lisp system. They used the cash cow they had and eventually sunk the whole company when the C++ system flopped in the market. Their C++ system (Energize) was very expensive, technically complex, ...

Re: Compiling to WebAssembly: It’s Happening

#202

Post by masswerk »

masswerk wrote: post #53
nwah1 wrote: post #6

Earlier quoted context omitted.

The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anyt…

I really don't get the down voting: While we've come globally to the conclusion that we require signed software, curated app stores and kill switches for traditional applications, because sh#t happens, we're going to distribute binary software in the browser without any such limitations? With the average user not even knowing that she is running some software from untrusted sources? (Yes, I know, it will be sandboxed, and there will never be a zero-day anymore in any browser ...)

Re: Compiling to WebAssembly: It’s Happening

#203

Post by teh64 »

wwweston wrote: post #54
klodolph wrote: post #17

Earlier quoted context omitted.

What makes WebAssembly like Flash? Please elaborate. You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force…

> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right…

> JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages

I don't know about Perl, but Python and Ruby both give you a type error for [] + {} or {} + [] or 1 + "1". And both Python and Ruby give you an error when you do something like "".notavalue, whereas javascript just gives you undefined. They might look similar enough visually, but under the hood they are different in terms of strictness and types.

Re: Compiling to WebAssembly: It’s Happening

#204

Post by heinrich5991 »

fulafel wrote: post #196
wwweston wrote: post #54

Earlier quoted context omitted.

> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right…

> JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages There's a big difference to strongly typed dynamic languages that go out of their way to catch programming mistakes at runtime. With JS you get some "wtf" result when things go wrong and it propagates a long way before manifesting (if it's caught at all). Combine with JS's many weird semantics and special cases that are h…

Can you explain that one? Does it have something to do with parseInt being able to take more than parameter?

Re: Compiling to WebAssembly: It’s Happening

#205

Post by fulafel »

heinrich5991 wrote: post #204
fulafel wrote: post #196

Earlier quoted context omitted.

> JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages There's a big difference to strongly typed dynamic languages that go out of their way to catch programming mistakes at runtime. With JS you get some "wtf" result when things go wrong and it propagates a long way before manifesting (if it's caught at all). Combine with JS's many weird semantics and special cases that are h…

Can you explain that one? Does it have something to do with parseInt being able to take more than parameter?

Array.map does not work like map in other languages.

They decided that map shall receive the array index as the second argument, and there's also a third argument that does something else. JS happily mashes these 3 arguments into parseInt's argument list of (stringValue, radix) without error. Hilarity ensues.

(This code also sins against "never call parseInt without the radix argument", see point about too many minefields to remember at once)

Re: Compiling to WebAssembly: It’s Happening

#206

Post by MichaelGG »

masswerk wrote: post #158
MichaelGG wrote: post #102

Earlier quoted context omitted.

Why are you under the impression there won't be disassemblers and decompilers for WebAssembly? It's not like a bunch of minified JS is going to be "quick" to go through.

Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, t…

This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder.

But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are.

It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.

Re: Compiling to WebAssembly: It’s Happening

#207

Post by tmerr »

spc476 wrote: post #190
tmerr wrote: post #154

Earlier quoted context omitted.

We should have had a standard like WebAssembly from the beginning. The lack of it is the reason for the outrageous explosion of features in web browsers. At first html made sense: it was ideal for quick transfer and rendering of documents. But today that's not enough. So we keep tacking on layers atop already fat abstractions. And all this fat is trying to support a moving target. At first it was about rendering text…

There was. It's Java. I remember when it was first released and it promised the ability to "write once, run anywhere" but delivered via the Web to run as web applets. And before that in the 80s, there was UCSD Pascal. I know it was available for the Apple ][ (used it in high school) and the IBM PC (one of three operating systems available when IBM launched the IBM PC in August of 1981) and probably a few other platfo…

Web applets are terrible because

  - The JVM takes forever to spin up  
  - The JVM tries to do too much with tons of class libraries  
  - The JVM is insecure  
  - The JVM is proprietary. While there are open source
    implementations, it is still tethered to Sun and now
    Oracle. They call the shots on the features and have
    sued both Google and Microsoft for implementing their
    own versions.
Similar arguments can be made against Flash.

We shouldn't expect WebAssembly to have the same pitfalls, since

  - WebAssembly does not take forever to spin up  
  - WebAssembly doesn't try to do too much. There is no huge
    standard library. For now it doesn't even include a GC.  
  - WebAssembly isn't insecure. Why would it be? I assume
    applet exploits are a product of the large standard 
    library (more attack vectors) and privilege escalation
    (certain exploits let you break out of its security
    settings to gain control). All of this seems like it's
    because web applets are monkeypatched on top of the 
    existing JVM.  
  - WebAssembly isn't proprietary.

Re: Compiling to WebAssembly: It’s Happening

#208

Post by icebraining »

bigger_cheese wrote: post #160
Yen wrote: post #130

Earlier quoted context omitted.

I agree with you on some points, and disagree with you on others. > The open web is a web where no company is the gatekeeper. Absolutely! > The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. I think "view source" was essential to the web we have today. It's not just a technical solution to a technical problem -…

I learnt to write HTML files in the early 90's (The Geocities era as you refer to it - forget tables back then everything was frames). I learnt exactly how you surmised by using view source on existing websites. As a 13 year old kid who was mildly curious I was able to build a web site for my high school by hand in 'pure' html code. It looked laughably simple compared to the web pages of today but it was easy. I can…

In some ways, the recent HTML specs allows the dev to go back to that old-school handwriting.

For example, instead of bringing in a JS framework, you could now just replace the input type with "date", and a modern browser would show the date picker.

Re: Compiling to WebAssembly: It’s Happening

#209

Post by pcwalton »

catnaroek wrote: post #174
pcwalton wrote: post #141

Earlier quoted context omitted.

> In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones. I would be happy to take a bet that this will not be the case. The fact is that JS is much easier to learn than C++, has a broader ecosystem in the browser , is faster to write than C++ due to memory safety among other considerations, and is fast enough for app logic. Think about it. C++ code has been supported…

I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite. C++ is a giant beast, but most of it was relatively easy to learn after I internalized the general principles that guide the language's design. These principles were the first coherent account I ever found of how programs manipulating ephemeral resources should be written. [I am aware that Rust impr…

> I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite.

You are a tiny minority in this. I've taught C++ and JS and have never once seen JS be harder to pick up.

> On the other hand, in JavaScript I have never found anything even remotely close to methodological guidance for writing programs.

The #1 selling JS book is (was) literally called "JavaScript: The Good Parts". It teaches "methodological guidance" for writing JavaScript programs. Just as modern C++ books teach the "good parts" of C++.

> JavaScript seems to make sense of anything as long as it is syntactically valid - a very low bar.

That's (a) not true, with the static resolution semantics in modules; (b) to the extent that it is true is mostly a criticism of dynamic typing, which has a lot of advantages and is not a criticism of JavaScript.

> JavaScript's ability to run in the browser is, as !far as I can tell, its only advantage over C++.

Memory safety? GC? A module system (as compared to #include)? Dynamic typing? This is silly.

(NB: I also think C++ has a lot of advantages over JS for certain domains. I'm a language pluralist.)

Re: Compiling to WebAssembly: It’s Happening

#210

Post by pcwalton »

cballard wrote: post #161
pcwalton wrote: post #151

Earlier quoted context omitted.

> If you're dissatisfied with JavaScript call performance, you have no choice. Other than the topic of this article?

Right - but this subthread is saying that JavaScript is enough and everyone should write JavaScript and not complain.

That's not what I said. What I said was that JavaScript would continue to be the most important client-side language on the Web. It's great that Web Assembly gives developers alternatives, and I hope it gets used to write games and to accelerate performance-critical parts of apps. I also hope that it allows people who don't want to code front-end logic in JS to deploy alternatives--I'm not even passing judgment on whether you should use JS (although I think choosing C++ over JS for high-level front-end app logic is a very poor decision). I'm just nearly certain most code will continue to be written in JS.
Post reply on HN