5 ms·
> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly
by wwweston 11y ago
> 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 thing for some applications.
But to the extent that the browser becomes something developers see primarily as The VM That Lived (and there are clearly a lot of developers in this boat) yes, we're forgetting lessons we should have already learned from the difference between Flash/Java and the open web.
> 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.
I'm clearly in the minority, but I had qualms about uglify and other source manglers from the beginning for the same reasons people have qualms about Web Assembly: they break the benefits of view source.
I get that they can also be tools that help squeeze out performance, and I use them selectively for that reason, but as far as I can tell, most of the web development world uses this as an excuse to stop actually thinking about the issue -- and for that matter, to stop thinking about how they're putting together their web app ("we're using minification and gzip and doing an SPA using Ember/Angular/LatestDesktopLikeFramework because that's what professionals do now, why do we have performance problems?").
Similarly, I've seen a lot of people use compiling to JS as an end run around what are essentially aesthetic/subjective issues with JS as a language when they'd probably do just as well spending more time learning to use it (as far as I can tell in years of working with all of them, JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages). That doesn't mean there are no beneficial cases for JS as a target (personally, I'm intrigued by Elm), but I think I'm justified in being afraid that people will use it as insulation from superficial problems.
> that force you to write code in Lisp
Lisp doesn't force you to write code in Lisp. That's one of the reasons why it's awesome -- and potentially horrible. Transpiling/compiling can be similarly awesome and potentially horrible for a lot of the same reasons.
- bromuro 11y ago> I'm clearly in the minority, but I had qualms about uglify and other source manglers [...]: they break the benefits of view source Not really: we have source maps for this.
- jacobolus 11y ago“View source” is a tool for outside end-users who want to understand or reverse-engineer code on websites they don’t control. “Source maps” is a tool for inside developers trying to debug their own code. Whether or not the browser supports source maps is irrelevant if you don’t have access to the original code, but only the minified/mangled version with all single-character variable names.
- Arnavion 11y ago>Whether or not the browser supports source maps is irrelevant if you don’t have access to the original code Sourcemaps can embed the original source inline, though of course that is a decision made by the author and they can decide not to make sourcemaps that way. It is more likely that the end-user doesn't have access to the source maps anyway.
- wwweston 11y agoI would love to see examples of source maps working in the wild.
- tahssa 11y ago> they break the benefits of view source. The benefits are not that great these days. At least not for people who don't support a web ad monetization model or have no interest in being on the VC boat to float model.
- klodolph 11y agoI'm sorry, this is going to be a rant. Feel free to ignore if you don't care about my opinions on the subject. 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. It's why we use JSON or XML instead of ASN.1 for our daily work. The open web is a web where no company is the gatekeeper. It's a web where we have multiple browsers, competing JS engines, et cetera. No one company can hold the web hostage. This is exactly why Flash, Java, ActiveX, and Sliverlight failed. Every one of those technologies was owned by a single company. Every one of those technologies failed because it's impossible for one company to be the gatekeeper for a technology that is supposed to run on billions of heterogenous devices. So the lessons of Flash are this: don't put all of your eggs in the Adobe basket. Meanwhile, you're fighting against WebAssembly because you are ideologically against black box software. Getting rid of WebAssembly does not actually achieve that goal. It's like you're fighting against condoms because they encourage promiscuity. The promiscuity is already there, and condoms just make it a better experience for everyone involved. ---- Footnote: JavaScript is on par with Python/Ruby/Lisp in a lot of ways, but there are some important deficiencies with respect to typing and static analysis, deficiencies which cause actual bugs in real world problems and cost developers time and money to deal with. It's why we've been inventing TypeScript, Flow, Dart, CoffeeScript, et cetera. You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly. People are going to write code in C++ because they can hit performance targets on platforms where they ship native code, and WebAssembly means a lot to the folks working with Unity, Unreal, or thousands of other existing projects which the new open web. The new open web, with WebAssembly, is an open web with more diversity than ever before, rather than a JavaScript monoculture.
- EdSharkey 11y agoYeah ... blackbox blob binaries (BBBB's?) don't strike me as the parent commenter's problem. It's not having access to a software's _original_ sources that you can build and deploy yourself that is the problem. Ideally, there would be some nuclear-powered version of View Source that gave you nice access to the original sources for the code loaded on a page - sort of a formalized "Fork Me on GitHub". When I am being philosophical, smoking a cigar and sipping tequila after midnight, I begin to understand that the only software I've written that has a chance of outliving me is my open source. Everything else I've done has just been to serve up fleeting amusements. There is literally nothing commercially closed that I have contributed to that shouldn't be utterly scrapped. If I died tonight, my positive impact on this planet for its people now and in the future is probably just constrained to my kids surviving me. Not an inconsequential thing, I love my kids like crazy and they're going on to do greater things than me. I just have the sense I've got more to offer than procreation and raising good people. In my opinion, any hairy audacious moonshot goals humanity chooses to tackle should be open sourced in every way possible - otherwise the efforts cannot be fully genuine and transparent to generations that follow. Perhaps the increased open-sourcing of code and designs we see from industry today versus 20 years ago is the best we can hope for in competitive capitalist societies; maybe what we have is good and is the most we can expect.
- odonnellryan 11y ago> It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. A huge part of the project is to ensure decompilation to asm.js
- fulafel 11y ago> 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 hard to keep in mind at once... Recent favourite (minimized case after discovering unexpected piles of NaN's in some faraway place) > parseInt("0") 0 > parseInt("1") 1 > parseInt("2") 2 > ["0", "1", "2"].map(parseInt) [ 0, NaN, NaN ]
- heinrich5991 11y agoCan you explain that one? Does it have something to do with parseInt being able to take more than parameter?
- fulafel 11y agoArray.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)
- nly 11y agoSeems to me the answer here would be to bind the radix argument of parseInt with a wrapper before applying map
- teh64 11y ago> 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.