From Asm.js to WebAssembly - <AUTHOR> https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ <comment><USER2> I think this quote speaks volumes - "WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks." Sometimes I think maybe, just maybe the W3C and other web standards groups finally have some wind behind their sails.

It may have taken a while, but with all these individuals and organizations cooperating in an open space, we may finally advance yet again into another new era of innovation for the web.

I am really excited about this, much like others in these comments.

We have been beating around the bush to have a true assembly/development layer in the browser for a long time: Java applets, Flash, Silverlight, you name it - but no true standard that was open like Javascript is open. This component has the possibility of being the neutral ground that everyone can build on top of.

To the creators (Brendan Eich et. al) & supporters, well done and best of luck in this endeavor. It's already started on the right foot (asm.js was what lead the way to this I think) - let's hope they can keep it cooperative and open as much as possible for the benefit of everyone!

<comment><USER3> _> WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks_

Is Apple participating?

<comment><USER4> Yes: "I'm happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers "

[https://blog.mozilla.org/luke/2015/06/17/webassembly/](https://blog.mozilla.org/luke/2015/06/17/webassembly/)

<comment><USER5> This doesn't seem to necessarily imply that Apple is directly involved. But it's good to know that Safari should be included in this effort.

<comment><USER6> That WebKit issue about WebAssembly was filed by engineer working on "compilers and language runtime systems at Apple":

[http://www.filpizlo.com/](http://www.filpizlo.com/)

[https://bugs.webkit.org/show_bug.cgi?id=146064](https://bugs.webkit.org/show_bug.cgi?id=146064)

<comment><USER7> Although that doesn't necessarily mean that Apple the company is involved, no?

<comment><USER3> Maybe the engineer who is involved wasn't able to obtain organizational signoff in time for Apple to put their name on the list of top-level endorsers of the proposed standard? Hopefully Apple can issue a statement later.

<comment><USER8> _WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I'm sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off._

So, the effort to get buy-in from the big companies that matter has been going on for some time, and now that we've done that, here's the result: Every big company that matters except Apple.

It's not as though the list of the four big companies that matter is too long to reasonably be expected to name the fourth, and the name of the fourth is not webkit.org or Fil Pizlo.

So, it seems to be either an "Oops, we accidentally left one of the four out of this important announcement," or there is still enough of a problem with Apple that we decided not to delay the announcement any longer to wait for them.

<comment><USER9> You are assuming a false dichotomy. There's a third possibility: what with a big four-letter-acronym developer conference and lots of other spinning plates, the full buy-in to include the company name didn't make the deadline set to get everyone else on board.

Since Fil opened a webkit bug to implement wasm, I would at least hedge my false-dichotomy bet and avoid getting my mad on. Free advice, take it or leave it.

(The first paragraph is actually me telling you pretty much what happened. Same thing as with WHATWG launch in 2004, BTW. Does not mean "OMG there is something WRONG and only TRULY SHINY COMPANY noticed and OBJECTED". Yeesh.)

<comment><USER8> As long as Apple hasn't officially agreed to this, and you seem to have some sort of embargo on even referring to them by name, something other than full buy-in from them is still a possibility. This possibility makes me nervous, because I think wasm is just what the Web needs, and I don't necessarily trust Apple to have "whatever is best for the open Web" as a guiding principle.

As for "getting my mad on," you seem to have gone off on some sort of tirade at the end there implying--how ironic--that I actually wanted TRULY SHINY COMPANY to save us from wasm, and your caps-lock key seems to have gotten stuck when you banged on it.

<comment><USER9> Please accept my apologies for the ALLCAPs. You were nervous in a way that suggested to me the kind of fannish knee-jerking that I unfairly lampooned.

I hope you can relax. All will be clear pretty soon, I am certain. There's no need to be nervous. Well, no need to be more nervous than usual! ;-)

<comment><USER8> All is well between us, and I can't thank you enough for what you're trying to do. Here I thought ES6 was the best news of the year for Web dev, but wasm will beat it _by far_ \--as long as the long-term cooperation you (correctly) said it needs really comes through. It's hard to relax when we're soooo close to something this tantalizing, all but one have officially committed, but it has to be unanimous, and that one is not...yet...saying....

I'll watch these pages and let out a woot! the minute Apple officially makes it unanimous.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Does everyone think this is good news?

I'm all for making the web faster/safer/better and all that. But I am worried about losing the web's "open by design" nature.

Much of what I've learned and am learning comes from me going to websites, opening the inspector and stepping through their code. It's educational. You learn things you may never read about in tutorials or books. And it's great because the author may have never intended for their code to be studied. But whether they like it or not, other people will learn from their code, and perhaps come up with [occasionally] better versions of it on their own.

This has helped the web development to evolve faster, and it's obvious how democratizing this "open-by-design" property is, and I think we should be concerned that it's being traded away for another (also essential) property.

Human beings cannot read asm.js code. And a bytecode format will be more or less the same. So, no matter how much faster and more flexible this format/standard is, it will still turn web apps into black boxes that no one can look into and learn from.

<comment><USER11> WebAssembly isn't going to kill that notion; uglify already did. Nearly all codebases on big sites get run through a build process these days. The open web continues to live on through the open and free software movements.

<comment><USER10> I agree that the web is far from the full ideal of "open-by-design", but it's still the most significant platform providing it to some extent.

The problem of uglify can be mitigated if someone invented a binary format for JS that was interchangeable with the current text format. The format would reduce the code's size, while keeping it readable (you'd just have to run it through a binary-to-text decompressor).

I should also say that you _can_ read uglified/obfuscated code. It just takes more patience. Example: if PS was written in JS and then obfuscated, how hard do you think it would be to find out how their color transformation algorithms are implemented?

You can't say the same thing for asm.js code though.

<comment><USER12> What's the difference between deobfuscating code, and decompiling it? Either way you end up with a weirdly-structured, canonicalized, symbolless mess.

<comment><USER10> The binary format that I mentioned/proposed would map one-to-one with a text format. They would be interchangeable. That means if you open a file in that binary format in a text editor (with the right plugin), you'd see almost exactly the original code. It's not decompilation. Only decompression.

<comment><USER12> I think you're confusing _cost of parsing_ with _cost of lexing_. A 1:1 binary representation of JS (like HPACK is for HTTP headers) wouldn't decrease _parsing_ time (the time it takes to turn a stream of recognized tokens into an AST) at all, which was the goal here.

<comment><USER10> Agreed, but the idea is still beneficial. If 1:1 binary representation for the data from the lexer doesn't yield much benefit, then a representation for the AST might.

And reading from that data could be much faster. And with a supposedly smaller file format, it probably wouldn't be so necessary for a minifier to rename symbols to single-letter ones to save a few more bytes.

[Edit: added the following paragraph]

This could yield a smaller file format (which is what people usually want from JS minifiers), without sacrificing the readability of the JS code.

<comment><USER13> Renaming symbols, and minification in general, is not really "necessary", it's just something people do to extract a few % more of performance. If they had that file format, they'd still have exactly the same reasons to rename symbols, so they'd still do it.

After all, if people cared about leaving their files readable, they'd just publish the non-minified version as well. Those who don't, won't avoid renaming either.

<comment><USER10> I agree that renaming symbols would still save a few more bytes, but I still think that with the right file format, symbol renaming and mangling would become an insignificant, unnecessary micro-optimization.

But that should only be tested in practice, so ... :)

<comment><USER14> This seems backwards. If I have JS source and the identifiers take up 10% of it, then symbol renaming and mangling can shrink my code size by something less than 10%.

If we shrink that other 90%, so that the formerly 10% is now 80%, renaming becomes _more_ attractive.

This doesn't hold if people have a fixed problem with a fixed solution and fixed constraints... but problems and solutions grow.

<comment><USER10> > _If we shrink that other 90%, so that the formerly 10% is now 80%, renaming > becomes more attractive._

Convinced :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Having been on one side of the perpetual (and tiresome) PNaCl-versus-asm.js debate, I'm thrilled to see a resolution. I really think this is a strategy that combines the best of both worlds. The crucial aspect is that this is polyfillable via JIT compilation to asm.js, so it's still just JavaScript, but it has plenty of room for extensibility to support threads, SIMD, and so forth.

<comment><USER16> > The crucial aspect is that this is polyfillable via JIT compilation to > asm.js

So is PNaCl, with pepper.js. The difference there is that PNaCl also provided a more full-featured API, which nonetheless was harder for other browsers to support. Personally, I would have been happy to see NaCl-minus-Pepper standardized, since the sandbox would have been much easier to support than the APIs; browsers could then choose what superset of APIs to expose to that sandbox.

<comment><USER15> By "a more full-featured API" do you mean that Pepper has more features than the Web APIs? If so, then it's not polyfillable (and the solution is to add more features to the Web APIs). Or if you mean that PNaCl has more features than asm.js, then the solution is to add those features to JavaScript.

I'm glad that asm.js is the starting baseline for this work, because its exact semantics are standardized via ECMA-262. All that has to be done to define its behavior precisely is to create a new syntax for it. LLVM bitcode, by contrast, has a lot of undefined behavior. You could try to spec a subset of it, but why go to that trouble when TC-39 has already done the work for you?

<comment><USER17> _it 's not polyfillable_

I'd be interested to know where/when this "polyfillable" term came about. It's not readily Google-able yet.

<comment><USER18> If you dig through my comment history, you might be able to find a comment I wrote on my first exposure to this term maybe ~2 years ago. I was utterly befuddled because I thought it was a graphics rendering algorithm (setting pixels in a framebuffer corresponding to the interior of a polygon specified as an edge list), and was horribly confused about why an article discussing some web technology would suddenly transition into a geometric problem utterly disconnected from the original topic.

<comment><USER19> It's a pretty awful term...

<comment><USER20> It sure beats "shiv" though. Glad that one has started fading.

<comment><USER21> shim makes much more sense than shiv

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Oberon language had a similar system called Juice back in 1997. It does exactly the same thing, e.g. using binary format to store a compressed abstract syntax tree as intermediate format which can be compiled efficiently and quickly. I think it even has a browser plugin much as Java applet. Life has interesting cycles. I don't have the best link to the Juice.

[1] [https://github.com/berkus/Juice/blob/master/intro.htm](https://github.com/berkus/Juice/blob/master/intro.htm) [2] ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf

<comment><USER23> Honestly, everything we're doing recently feels like rediscovering Oberon.

Oberon had name-based public/private methods, like Go. It had ahead-of-time compilation of bytecode, as you pointed out. It had CSP-style concurrency, again like Go. The web for the last two years feels like we're rediscovering Smalltalk and Oberon and acting like we've just invented everything anew.

<comment><USER9> We didn't acknowledge a debt to Oberon (did Java? It owes one too, Bill Joy evaluated Oberon closely).

My pal Michael Franz at UCI studied under Wirth. Michael and a PhD student, Chris Storck, did an AST encoder years back that influenced me and that I referenced re: wasm.

Oberon's great. JS was in the right place and right time. What can I say? I've been taking all the best ideas from the best projects and trying to get them incorporated, ever since 1995.

<comment><USER23> Sorry, just to be clear, I don't see anything wrong at all with raiding the best ideas from older languages. It's actually awesome: it means those ideas get used. I'm genuinely just amused at the cycle.

</comment></comment></comment></comment><comment><USER24> This is enormous news. I could see a scenario where, in ~5 years, WebAssembly could provide an alternative to having to develop apps with HTML for the web, Swift for iOS, and Java for Android. Instead, you could build browser-based apps that actually delivered native performance, even for CPU- and GPU- intensive tasks.

Of course, there would still be UI differences required between the 3 platforms, but you would no longer need 3 separate development teams.

<comment><USER25> This was also what Java applets were meant to deliver – I remember running some pretty great Java Applet-based games back in the day.

But Java ran as an embed, not a browser-level feature, and was much slower to load than Flash (which came to offer much of the same functionality in an easy-to-use IDE).

<comment><USER26> I can already imagine a minimal java VM (just transforming bytecode to wasm instead of JITing to machine code) inside browsers, thus allowing java (or any of the other JVM languages) running in the backend and frontend.

<comment><USER27> Google previewed some Android to chrome app compiler a while ago - can't remember the details. I imagine it would be a pretty good starting point for such a project instead of a full vm.

<comment><USER28> ARC ([https://developer.chrome.com/apps/getstarted_arc](https://developer.chrome.com/apps/getstarted_arc))

</comment></comment></comment></comment></comment><comment><USER29> This is probably the best thing that can happen to web development.

For quite a while, I've been thinking about how instead of hacks like asm.js, we should be pushing an actual "Web IR" which would actually be designed from the ground up as an IR language. Something similar to PNaCl (a subset of LLVM IR), except divorced from the Chrome sandbox, really.

<comment><USER30> I think that's what lots of people have thought since the 90s with Java applets. Despite ES6 and "it's not _that_ bad", there's a lot of people that would really like to not have to deal with JS.

Edit: Really, it's annoying this didn't happen sooner. If Microsoft would have thought of this early on and pushed it, they could have gained a lead in compilers and developer tools, for instance.

</comment></comment><comment><USER31> I think the biggest win is [https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom- integration). Now instead of asm.js being only for emscripten-compiled code (or other non-GC code) WebAssembly can be used for higher level, GC'd languages. And even better, [https://github.com/WebAssembly/design/blob/master/NonWeb.md](https://github.com/WebAssembly/design/blob/master/NonWeb.md), means we may get a new, generic, standalone VM out of this which is always good (I hope I'm not reading in to the details too much). As someone who likes to write compilers/transpilers, I look forward to targetting this.

<comment><USER16> I'm _really_ hoping that WebAssembly doesn't bake-in higher-level features like garbage collection. That would preclude replacing GC with something better, such as Rust-style memory management.

Hopefully this will take more inspiration from actual assembly language and virtual machines, rather than from bytecode languages.

<comment><USER32> GC support doesn't prevent having Rust-style compile-time memory management. In fact, Rust itself may add a GC at some point.

<comment><USER16> As a library, though, which is very different than providing it as an inherent part of a language runtime.

I'm hoping WebAssembly doesn't inherently imply a runtime.

<comment><USER32> Efficient GC requires tight integration with LLVM, and I assume that means also tight integration with the Rust compiler. I don't think that can be done as a library or even a plugin.

<comment><USER33> Rust doesn't need an efficient GC like the kind Java has. Most of the resources you need in Rust are freed when they get out of scope.

What Rust needs is just a better RC implementation. This is because only a small part of your data is reference counted, so it fits better with how Rust works, so an efficient implementation allows it to combine with ownership semantics to outperform even very advanced generational GCs.

</comment></comment></comment></comment></comment></comment><comment><USER34> Prepare for the onslaught of new (and old) languages targeting the web.

While this is welcome news, I am also torn. The possibilities are pretty amazing. Think seamless isomorphic apps in any language that can target WebAssembly and has a virtual dom implementation.

However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform.

Either way, it will be an interesting time... and a time to keep up or risk being left behind.

<comment><USER16> > However, it finally seems like JS is getting some of its core problems > solved and is getting usable. I wonder if it might have short term > productivity loss as the churn ramps up to new levels with a million > different choices of language/platform.

This announcement means JavaScript can no longer rely on "you must target JavaScript to work on the web" as a motivating factor. The set of people who like JavaScript as a language in its own right can keep using it, and will have the advantage of new JavaScript engines and extensions implemented on top of WebAssembly. However, the set of people who would rather write in another language will no longer be constrained by waiting for JavaScript to catch up.

Personally, I think this will be a good thing for both JavaScript and other languages.

<comment><USER27> I'm 100% ready to jump ship there. I would rather work at a shop that does any other language besides Javascript for web guis even with more than a decade of js dev under my belt. The problem is they are impossible to find.

<comment><USER35> > The problem is they are impossible to find.

Scala.js[0], GHCJS[1], and Js_of_ocaml[2] among others.

[0] [http://www.scala-js.org/](http://www.scala-js.org/)

[1] [https://github.com/ghcjs/ghcjs](https://github.com/ghcjs/ghcjs)

[2] [http://ocsigen.org/js_of_ocaml/](http://ocsigen.org/js_of_ocaml/)

<comment><USER36> I believe smrtinsert is referring to places that you could work at to write those languages, not that the languages themselves are impossible to find. I don't know if anyone is actually being paid by someone else to write ScalaJS, GHCHS and/or Js_of_ocaml.

<comment><USER35> > places that you could work at to write those languages

Ah, missed that, assumed OP meant if only there was a way to write JS without having to write JS.

</comment></comment></comment></comment></comment></comment><comment><USER37> So it's basically bytecode for the web without compiling to javascript right ?

Any language can now target that specific bytecode without the need for javascript transpilation.

For instance Flash can target this format in place of the Flash player, making swf files future proof since backed by standard web techs.

So it's basically the return of Flash,Java applets and co on the web. And web developers won't have to use Javascript anymore.

The only constraint is obviously the fact that the bytecode has only access to web apis and cant talk directly to the OS like with classic browser plugin architectures.

</comment><comment><USER38> It is really too bad that at some point in the last 18 years of Java VMs being in browsers that they didn't formalize the connection between the DOM and Java so that you could write code that interacted directly with the DOM and vice/versa in a mature VM that was already included. Would have been way better than applets, way faster than Javascript and relatively easy to implement. The browsers actually have (had?) APIs for this but they were never really stabilized.

<comment><USER39> I find it interesting that Java didn't become the standard for this as it seems like it has everything and is both fast and mature.

What might be the reason?

<comment><USER40> There are several important lessons to learn from the Java bytecode format and members of the WebAssembly (including myself) do have experience here. In particular, JVM class files would be a poor fit for WebAssembly because:

1\. They impose Java's class and primitive type model. 2\. They allow irreducible control flow. 3\. They aren't very compact. Lots of redundancy in constant pools across classes and still a lot of possibility for compression. 4\. Verification of JVM class files is an expensive operation requiring control and dataflow analysis (see stackmaps added in the Java 7 class file format for rationale). 5\. No notion of low-level memory access. WebAssembly specifically addresses this, exposing the notion of a native heap that can be bit-banged directly by applications.

</comment></comment></comment><comment><USER41> If I could just use my favourite language and not feel like a second class citizen, then I am not sure there would be anything else to complain about as a developer, really. A mark-up bytecode so that we could forget about the nightmare of HTML and CSS as well?

<comment><USER16> Fast-forward a few years, and imagine if a browser engine were nothing more than a WebAssembly engine and a "default" HTML/CSS implementation. You could replace that engine with anything you like written in WebAssembly, doing all its own rendering and input using the lower-level APIs provided by WebAssembly. So, every browser gets the latest rendering and elements, or at the very least polyfills via WebAssembly rather than JavaScript.

<comment><USER42> Sounds terrible for SEO, screen readers and adblockers.

<comment><USER16> You can already build awful, non-semantic HTML today, with a giant pile of <div> tags, CSS, and JavaScript. The web hasn't fallen apart.

Similarly, just because it'll be possible to implement a full web engine efficiently in WebAssembly doesn't mean sites will suddenly stop paying any attention to standards or accessibility.

As for adblockers, I can think of several ways to block ads in such a world, including hooking the sockets API to block or sandbox access to ad-serving hosts, or providing hot-patches that stub out common ad-serving libraries. It'll get harder, but not impossible.

<comment><USER43> "The web hasn't fallen apart" for sighted users. Those non-semantic, unusable- to-screen-reader sites are in fact an accessibility disaster for blind users, who can find it nearly impossible to use some sites.

(And a disaster for the companies that build them and get sued later.)

<comment><USER16> > "The web hasn't fallen apart" for sighted users. Those non-semantic, > unusable-to-screen-reader sites are in fact an accessibility disaster for > blind users, who can find it nearly impossible to use some sites.

I'm saying that div-itis is possible today, but it's a bad idea, and as far as I can tell many new sites still use semantic markup when available.

Along the same lines, I would expect that even if people implement a web engine in wasm, many will still use semantic markup.

That said, I agree that people don't pay enough attention to accessibility, and should. But I don't think wasm or wasm-based rendering engines will make that _worse_.

<comment><USER42> Even if you use only divs, the actual text is there in UTF-8 to parse out of the DOM, today.

If you go all-in on wasm to do "your own rendering", external software won't know where to find a "DOM" or how to understand it, unless some other kind of reinvented HTML-for-a-wasm-rendering-engine-defacto-standard is invented?

(This is more a rant against "let's reinvent html/css in canvas" rather against a VM-based javascript replacement in general. Even though the latter sounds a bit terrible as well for the open web; imagine what the web would have looked like if .js never existed, and a flash/java .swf/.jar engine was the only way to do scripting in a webpage.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> Has any consideration been given to using a subset or derivation of LLVM bitcode a la PNaCl? I know there are significant potential downsides (e.g. according to [1], it's not actually very space efficient despite/because of being bit-oriented and having fancy abbreviation features), but it already has a canonical text encoding, it has been 'battle-tested' and has semantics by definition well suited for compilers, and using it as a base would generally avoid reinventing the wheel.

[1] [https://aaltodoc.aalto.fi/handle/123456789/13468](https://aaltodoc.aalto.fi/handle/123456789/13468)

<comment><USER32> Of course, several of the people working on WebAssembly are actually from the PNaCl team. And others, like the Emscripten people, have lots of LLVM experience as well. WebAssembly is being designed while taking into account previous approaches in this field, including of course using LLVM bitcode for it.

LLVM bitcode is simply not a good fit for this:

* It is not portable.

* It is not designed to be compact.

* It is not designed to be quick to decode and start up

* It has undefined behavior

* It is not sandboxed.

* It is a moving target (see recent big changes to LLVM IR on geps and loads/stores)

Each of those can be tackled with a lot of effort. But overall, better results are possible using other approaches.

</comment></comment><comment><USER45> Finally. IMO this is what the web has been calling for since AJAX went mainstream.

They are doing great work. The client's operating system matters little now, but it will not matter at all soon.

</comment><comment><USER46> This still doesn't fix the biggest issue with running non-javascript code in the browser: browsers _still_ offer _no_ way to know when a value is collected.

e.g. if I allocate a callback function, and hand it to setTimeout, I have no way to know when to collect it.

Sure, you can encode rules about some of the common functions; but as soon as you get to e.g. attaching an 'onreadystatechange' to an XHR: you can't follow all the different code paths.

Every time a proposal comes up to fix this:

      - GC callbacks
      - Weak valued maps
      - Proxy with collection trap

The proposal gets squashed.

Unless this is attended to Javascript remains the required language on the web.

<comment><USER9> Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn.

Note turn-based notification. No way will exact GC schedule be leaked via callbacks from the GC. Ditto anything like Java's post-mortem finalization.

But your "e.g." is unclear, though. Why do you need to manually deallocate a callback function passed to setTimeout?

<comment><USER46> > Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to > notify in next event loop turn.

Got a link to the memo? I haven't heard about this one.

> Why do you need to manually deallocate a callback function passed to > setTimeout?

One of my use cases is running lua in the browser. see lua.vm.js: [https://kripken.github.io/lua.vm.js/repl.html](https://kripken.github.io/lua.vm.js/repl.html)

When you pass a lua function to a javascript function, I create a 'proxy' object that holds a reference to the function in the lua VM. Only if javascript tells me it's "done" with it can I drop the ref inside the lua VM.

<comment><USER9> See, e.g.,

[https://esdiscuss.org/topic/weak-event- listener#content-2](https://esdiscuss.org/topic/weak-event-listener#content-2)

It's hard to find something fresh. I will stir the pot at the July TC39 meeting and get the committee on the record for weak refs with turn-delayed notification, or bust!

<comment><USER46> > See, e.g.,

> [https://esdiscuss.org/topic/weak-event- > listener#content-2](https://esdiscuss.org/topic/weak-event- > listener#content-2)

> It's hard to find something fresh. I will stir the pot at the July TC39 > meeting and get the committee on the record for weak refs with turn-delayed > notification, or bust!

As recently as September last year you told me it may happen... but with an indeterminate timeframe: [https://mail.mozilla.org/pipermail/es- discuss/2014-September...](https://mail.mozilla.org/pipermail/es- discuss/2014-September/039078.html)

<comment><USER9> Yeah, it needs an active champion. I'll poke likely champs.

</comment></comment></comment></comment></comment></comment><comment><USER16> I'm interested to see what the API side of WebAssembly looks like in browsers; hopefully this will make it easier to expose more full-featured sandboxed APIs to languages targeting the web, without having to tailor those APIs to JavaScript. For instance, API calls that actually accept integers and data structures rather than floating-point and objects.

For that matter, though in the short-term this will be polyfilled via JavaScript in browsers, it'll be fun to see the first JavaScript-to- WebAssembly compiler that allows you to use the latest ECMAScript features in every browser.

<comment><USER32> The API story for wasm on the web is the set of existing web APIs. That provides the same security model and capabilities as the web has right now.

Currently wasm can't access web APIs except by calling out to JS, which would then call the API, but in the future, direct calling paths are intended.

<comment><USER16> My hope is that WebAssembly will start motivating a set of lower-level APIs, with higher-level APIs being provided on top of those by WebAssembly "libraries". JavaScript tends to motivate much higher-level APIs, and you can't turn high-level APIs into low-level APIs, only the other way around.

<comment><USER47> This seems orthogonal to WebAssembly. This is already a goal for its own sake --see the Extensible Web Manifesto.

</comment></comment></comment></comment><comment><USER48> So for now, the idea is to write C++, compile it to ASM.js, translate it into WebAssembly, GZIP it, transmit it, unGZIP it, then run a polyfill to translate the WebAssembly into ASM.js?

This sounds absurd. I can't even get through getting Clang, LLVM, and Emscripten built from source as it is, it's such a house-of-cards with configuration and dependency settings. Have any of you tried building Chromium from scratch? I have, on three separate occasions, as I'd like to try to contribute to WebVR. End result: fewer gigs of free space on my hard drive and no Chromium from source.

Part of that is my impatience: I'm used to C# and Java, where dependencies are always dynamically linked, the namespacing keeps everything from colliding, and the semantics are very easy to follow. But even Node's braindead NPM dependency manager would be better than the hoops they make you jump through to build open-source C++ projects. I mean, I just don't get how someone could have at any point said "yes, this is a good path, we should continue with this" for all these custom build systems in the wild on these projects.

I could be way off. I'm only just reading the FAQ now and I'm not entirely sure I understand what has actually been made versus what has been planned. There seems to be a lot of talk about supporting other languages than C++, but that's what they said about ASM.js, and where did that go? Is anyone using ASM.js in production who is not Archive.org and their arcade emulator?

I don't know... I really, really want to like the web browser as a platform. It has its flaws, but it's the least painful solution of all of the completely-cross-platform options. But it's hard. Getting harder. Hard enough I'm starting to wonder if it'd be smarter to develop better deployment strategies for an existing, better programming language than to try to develop better programming languages for the browser's existing, better deployment strategy.

This telephone game being played by translator tools and configuration management tools and polyfills and frameworks and... the list goes on! This thing we consider "modern" web development is getting way out of hand. JS's _strength_ used to be that all you needed was a text editor. Everyone--both users and developers--can already use it and run it.

If it's just one tool, I'll get over it. But stringing these rickety, half- implemented tools together into a chain of codependent systems is unacceptable. It just feels like they're foisting their inability to finish and properly deploy their work on us. Vagrant recipes are nice, but they should be a convenience, not a necessity.

Sorry. Good for them. Just finish something already.

<comment><USER9> For years, I've laughed (from skull throne) at the "whyyyy no bytecode" posts on HN. Now bytecode, still complaints. Still laughing, too.

<comment><USER48> I never complained about no bytecode. And I'm not complaining about bytecode now. I'm complaining about an apparent lack of commitment to bringing any of these projects to a useful status.

Don't you think developer tools should have good UX, too? Microsoft does, and Visual Studio just works. Oracle does, and Java and Netbeans just work. Even setting up Node and NPM was a better overall experience than trying to get Emscripten working correctly and integrated into my projects.

Emscripten and NaCL are both like 4 years old now. Why hasn't there been greater adoption of these tools? I postulate it's the bad UX. I mean, Emscripten only working with VS2010, three whole versions behind latest, is a pretty good indicator that there is a whole class of users that have just written it off. Is there any concern for that with WebAssembly?

<comment><USER9> I know, I kid.

Things took a while because vendors had their own prior paths to pursue, while asm.js had to prove it could get close enough to native perf. (You could say Mozilla's prior path was JS.)

Tools for JS are pretty good; VS does TypeScript and JS, will do wasm. Firefox devtools are giving Chrome devtools a run for their (bigger) money.

I think tools are the least of it, while agreeing they make a difference (see Mandreel with VS integration, vs. Emscripten).

NaCl (PNaCl, you must mean) never went cross browser as such, nor could it. WebAssembly is the PNaCl end-game, and a pretty good one.

As for Emscripten, it's a huge win that both Unity and Epic (Unreal Engine) support JS/WebGL as first-class targets. This happened over the last few years, tools built into the game engines. Doesn't disprove your point, you could be right! Let's find out.

<comment><USER49> Hey Brendan, thanks for not flipping a huge bird to the web community and sticking with it.

For myself, I've had very little to complain about web development since '08 or '09\. It became an application platform for me with the emergence of the canvas tag, and since then it has grown into a full operating environment of sorts. There have always been awkward and limiting features to the web because it is such a hodgepodge and I think that's where most of the complaints come from. But the browser compatibility situation continues to improve, which has always been my biggest gripe.

I worry a bit about the exploit potential of WebAssembly as more features are layered atop what Asm.js offers. Don't add too much, okay? ;)

<comment><USER9> Thanks, Ed.

I see any web-scale runtime standard inevitably having versions spread across the installed base of any server, so prone to the same pressure JS was, which led to polyfills, graceful degradation, object detection, monkey-patching in full. People who complain about this are complaining about physics.

You're right to worry about security, which is why the "MVP" for wasm is co- expressive with asm.js, just faster-to-parse syntax. After that, we must be even more careful.

</comment></comment></comment></comment></comment></comment><comment><USER50> Interestingly, about five years ago, he said he couldn't see this ever happening: [https://news.ycombinator.com/item?id=1905291](https://news.ycombinator.com/item?id=1905291)

<comment><USER9> In that comment, I wrote

"A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good compression; see Ben Livshits' JSZap from MSR, and earlier work by Michael Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not on TC39's radar."

And WebAssembly is indeed a compressed AST encoding, not a stack bytecode. Shhh, don't tell anyone. You can still call it bytecode if you like.

<comment><USER17> With an AST representation, one can do interesting things. Everyone could have their own custom code formatting rules, and it wouldn't have to affect anyone else. Comments would have to be included in the AST for this to work sanely.

This might even go as far as languages, though for this to work well, the code would have to cover an intersection of the functionality in all the languages "rendered" to.

(Haven't watched the presentation yet. I'm in public without headphones.)

</comment></comment></comment><comment><USER51> I guess this is in the spirit of NaCL and its bytecode, and the Java VM/Java bytecode, and the .NET runtime/.NET IR. It makes a lot of sense and I get it then sort of gets competitive with those efforts as well.

<comment><USER52> It does compete with those efforts in a sense, but ideally it is going to learn from those efforts and provide a powerful cross-browser equivalent to them instead of just trying to replace them.

</comment></comment><comment><USER53> Combined with something like e.g. Flipboard's react-canvas, this means we could bypass _and_ re-implement most of the browser stack...

</comment><comment><USER54> [https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...](https://github.com/WebAssembly/design/blob/master/FAQ.md#will- webassembly-support-view-source-on-the-web) makes me happy as that was the first concern I had when reading these news :)

</comment><comment><USER55> Can someone explain why not just go the JVM or .NET CLR path ?

Both well tested, well executed, great tooling, supported on many platforms, compilation targets of many existing languages.

Serious question.. is it licensing ?

<comment><USER32> 1\. Both the JVM and CLR have different focuses in terms of startup speed, which matters more on the web than anywhere else (this is one reason Java failed on the web). JavaScript and WebAssembly are designed to start up quickly.

2\. If you have both the CLR and a JS engine in the same browser, you have problems with cross-VM GC cycles and the overhead that causes. That is one reason why WebKit opposed adding Dart bindings, for example. WebAssembly is designed to integrate with existing JS VMs.

3\. Both Java and the CLR are open source, but both are patented. Both have licenses for those patents, but this has been the cause of much debate, as there are corner cases in those licenses (e.g. if you do not fully implement all of the VM per the license, you may not fall under its protection). This could be resolved - all existing patents could be offered up to the public domain - but I don't see Microsoft or Oracle (and there may be others with patents) doing so.

</comment></comment><comment><USER56> This is pretty awesome, and is a pretty good use of all the effort that's been going into asm.js

One question though - I found a proposal somewhere on a Mozilla run wiki about a web API for registering script transpiling/interpreter engines. I've lost the web address, but if anyone know any more about this is love to see it rekindled.

<comment><USER57> I think you're talking about module loaders[1]. I remember seeing on es- discuss that they have been postponed to ES7.

[1] [https://github.com/lukehoban/es6features#module- loaders](https://github.com/lukehoban/es6features#module-loaders)

<comment><USER56> Functionally that's it (didn't realise it'd been rolled into es6 modules though). Looks like what I was referring to was a third party library: [https://developer.mozilla.org/en-US/Add- ons/Code_snippets/Ro...](https://developer.mozilla.org/en-US/Add- ons/Code_snippets/Rosetta)

</comment></comment></comment><comment><USER58> Nice, but I'm still waiting for 64-bit integer arithmetic!

For our use case, what I like about this is that we can continue to use emscripten and the technology will come to us, rather than requiring app developers to invest in yet another technology (our switchover from NaCl to emscripten was very time consuming!)

<comment><USER9> 64-bit ints coming along with SIMD in ES7^H2016.

</comment></comment><comment><USER59> Very very happy to see this.

Politically it appears to be a fantastic collaboration.

Technically it looks like they have really thought through this hard -- if you look through the post-MVP plans ([https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md)) there are a lot of exciting ideas there. But it's not just pie-in-the-sky speculation, the amount of detail makes it clear that they have some really top compiler people who are really rigorously exploring the boundaries of what can be accomplished inside the web platform (SIMD, threading, GC integration, tail calls, multiprocess support, etc).

</comment><comment><USER60> WebAssembly Backend RFC on the LLVM mailing list:

[http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend- td...](http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td82554.html)

</comment><comment><USER61> This is awesome.

We will probably need a package manager after that (like apt or npm).

A use case could be with ImageMagick, OpenCV, OpenSceneGraph or qemu inside the browser. All of them are huge and useful projects with many common dependencies.

</comment><comment><USER62> So, is this the long way around to get us Java Applets all over again?

</comment><comment><USER63> I hope that someone ports mruby to this. I've come to terms with javascript's syntax (via coffeescript), but I'd still rather not deal with javascript's semantics.

<comment><USER32> There is already an mruby port to the web using emscripten. When emscripten targets wasm, that port will get that for free.

</comment></comment><comment><USER64> > "MS seems to get the modern Web".

This made me laugh, sadly. They _get_ the modern Web because they aren't winning at _native_ app development.

<comment><USER65> I think it's more that native app development isn't winning (except in a few niches).

</comment></comment><comment><USER66> Didn't WMLScript (a subset of Javascript used for WML) have a required byte code representation?

</comment><comment><USER67> Praise the lord, that was sooner than I expected. Next up: the DOM. Then there will be peace on Earth.

Does anyone know when all this started? I ask because only 83 days ago Brendan was on here telling us pretty emphatically that this was a bad idea and would never happen.

<comment><USER9> Please cite my post from 83 days ago. I think you're misreading it (perhaps "bytecode" is overloaded). I have good reason to, since I was in on wasm from the start, which was longer ago than 83 days.

<comment><USER67> I didn't intend to ruffle anyone's feathers with that comment. Yes I suppose I am misreading it, but I don't think I can be blamed for walking away from that exchange thinking transpilation to JS was the last word on the subject.

Anyway great work man. It's a happy day.

<comment><USER9> Thanks.

Here's Tim Sweeney on diff between "bytecode" and wasm:

[https://twitter.com/TimSweeneyEpic/status/611237145857138688](https://twitter.com/TimSweeneyEpic/status/611237145857138688)

<comment><USER68> Hi Brendan, just hopping on the end of this thread to tell you that I think it was just disgusting the way that you were boycotted for your donation. It seemed really hypocritical for them to mistreat you for your opinions.

<comment><USER4> Maybe we won in the end. If Brendan was spending all his time doing CEO type stuff, he'd be spending less time giving us awesomeness like this.

<comment><USER9> This was a group effort and I am last, not first. Mainly I played prophet, peace-maker, coach, bartender.

Not quite the Tetralogy of Tony Stark (genius, billionaire, playboy, philanthropist) but I'll take it! ;-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER54> This page makes Firefox on Android crash.

<comment><USER69> It crashes in iOS Safari on an iPad Air 2 for me.

</comment></comment><comment><USER70> I'm curious what the debugging story for this is going to be? Source maps?

<comment><USER71> Yep

[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#source- maps-integration)

</comment></comment><comment><USER72> Without support for proper threads, web assembly programming feels the same as programming a Z80 or 6502 back in the 80s.

And no, webworkers don't cut it, because they don't support structural sharing of immutable data structures in an efficient and flexible way.

<comment><USER9> Tedious to read out-of-date objections. Please do a bit of research and find out the latest. JS is getting shared memory thread support:

[https://blog.mozilla.org/javascript/2015/02/26/the-path- to-p...](https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel- javascript/)

This means the MVP wasm likely includes threads (same timeframe, later this year), and post-MVP wasm can go for full-strength pthreads.

</comment></comment><comment><USER73> Isomorphic Python here I come...

</comment><comment><USER74> w00t w00t. This is pretty great overall.

</comment><comment><USER75> Is there already a plugin out there that blocks this crap?

</comment><comment><USER76> So this is like PNaCl but targeting the web API and by making it collaborative, hopefully a real standard allowing independent reimplementation?

Ironic that Eich is the one to pull the trigger on JS.

<comment><USER9> Pepper was floated on email@example.com a long time ago, roc replied advocating not reinventing web APIs:

[https://mail.mozilla.org/pipermail/plugin- futures/2010-April...](https://mail.mozilla.org/pipermail/plugin- futures/2010-April/000088.html)

The collaborative aspect is important, but one side of a coin whose other side is polyfillability. Nick Bray of the PNaCl team stubbed out Pepper.js more recently, and JS finally got some SIMD and threads love. It's all converging, finally. Yay!

<comment><USER16> There are a few key aspects where web APIs will want to differ between JavaScript and WebAssembly, though. For instance, some APIs really do need 32-bit and 64-bit integers, _not_ floating-point, and the APIs should be specified as accepting and returning values of those types. An API tailored to JavaScript would have to specify how to encode such a number into what JavaScript can express.

Ditto for data structures (with actual layout, not JavaScript "bag of key- value properties" objects).

Ultimately, I'm hoping new web APIs will be specified as a WebAssembly ABI, without taking JavaScript into account; the JavaScript interface to those APIs can be responsible for questions like "how do I call a function specified as taking a 64-bit unsigned integer?".

<comment><USER9> JS is getting int64 and uint64, so you need a better example, like zero-cost exceptions, dynamic linking, call/cc (listed in my post).

<comment><USER16> > JS is getting int64 and uint64

It's a fine example for today's browsers that don't have those. Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs. And it doesn't invalidate the point that JavaScript limitations should not be web limitations.

For instance, how about efficient structs with defined in-memory layout?

Targeting web APIs to WebAssembly means that the web can tell JavaScript to keep up, rather than JavaScript telling the web to wait up.

<comment><USER9> Wait, how does wasm help APIs being designed today?

Please use the same yardstick when comparing.

Important that JS grow too, including SIMD, shared memory, value types including 64-bit int. Does not alter the case for wasm, per the FAQ: parse time win soon, divergence to relieve JS from serving two masters in longer run.

<comment><USER16> I'm using the same yardstick, relative to the baseline implementation of each language. APIs won't be able to natively target WebAssembly until browsers have native support for it. However, once browsers natively support WebAssembly, there won't need to be a "today's WebAssembly" versus "tomorrow's WebAssembly" issue; interesting new features belong in the languages _targeting_ WebAssembly, with WebAssembly itself handling things like "how do we efficiently generate SIMD instructions on every target platform". Questions like "what datatypes do we support" become uninteresting; the answer is "whatever both ends of an ABI can agree on".

<comment><USER9> You wrote

"Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs."

and I asked

"Wait, how does wasm help APIs being designed today?"

Your different yardstick is the shift from "today" to "future". WebAsm that is a super of JS is in the future, past the polyfill era of co-expressiveness. Fault JS today for lacking int64 by the same (temporal) yardstick should fault wasm today.

In general we agree, but you are arguing carelessly. There is no essential difference between int64 for JS in the future, and int64-equipped wasm in the future. Both are in the future.

The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and _then_ wasm can run ahead of JS. But it'll be a managed standards, so don't expect a huge iteration-time win. It'll be good for both JS and wasm in that farther future to decouple concerns, I agree.

Are we done yet?

<comment><USER16> I'm talking about the meta-problem here: APIs designed today have to care about today's JavaScript semantics, which are high-level JavaScript-specific constraints. APIs designed for browsers with native wasm support care about the semantics of wasm, but those semantics are language-agnostic. APIs should be designed based on a language-agnostic ABI, not based on JavaScript. That's the world I'm looking forward to.

Even the planned future ABI for interoperable dynamic linking is a guideline; any caller and callee that agree can use a different, extended ABI.

> The solid ground on which to argue is where browsers all update to support > wasm, whose syntax and extension model(s) stabilize, and then wasm can run > ahead of JS.

Of course, and that's exactly the world I'm talking about.

> But it'll be a managed standards, so don't expect a huge iteration-time win.

WebAssembly is in a very critical way _smaller_ than JavaScript, so its iteration time is less important. wasm iterations will be important for performance (to provide constructs that will efficiently translate to the native machine code you or a compiler would have written), and we'll need new APIs for things like thread-spawning, but new language features and functions using those features won't require any changes to wasm.

> Are we done yet?

By all means let's stop violently agreeing with each other. :) Thanks for working on WebAssembly; I look forward to using it.

<comment><USER77> > APIs should be designed based on a language-agnostic ABI, not based on > JavaScript.

Has there ever been such a thing?

<comment><USER16> [http://x86-64.org/documentation/abi.pdf](http://x86-64.org/documentation/abi.pdf) , for one example.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER78> To an end user, how is this a different experience from flash? You browse to a website and must execute binary blobs in order to view the site.

Even worse, it's like Flash but where the flash 'plugin' has been written from scratch by each web browser, giving us endless possibilities of incompatibilities which are a nightmare to fix.</comment>


Anti idiot actually - <AUTHOR> https://gizmodo.com/sam-altman-is-an-idiot-1821327260 <comment><USER2> Mr. Estes, instead of taking on Altman's argument, declares it idiotic and proceeds to attack Altman's person on all sides because, frankly, he just has to write something about the whole thing... or so it seems.

</comment><comment><USER3> Here's an uncomfortable idea to contemplate.

Suppose Kary Mullis had expressed some of his more wingnut extreme ideas before he got hired, and that had caused him no to be employable? And he then failed to have the opportunity to invent the polymerase chain reaction? People now alive would likely be dead.</comment>


Hidden Dangers of the Great Index Fund Takeover - <AUTHOR> https://www.bloomberg.com/news/features/2020-01-09/the-hidden-dangers-of-the-great-index-fund-takeover <comment><USER2> The extremely simple and correct solution here is to not let index funds _themselves_ vote. Only allow the votes to be cast directly by the index share holders. Problem solved, I don't know why people keep hand wringing about this and not suggesting the supremely obvious solution here.

<comment><USER3> That doesn't solve the big part of the problem which is the co-ownership of competing companies. A blackrock manager voting for you or you voting doesn't change anything. Through the fund, you co-own multiple competing companies, therefore you won't vote for policies that would increase competition between those companies.

<comment><USER4> I would say this does solve the problem. If you have enough money for your vote to matter, then you can just own all the stocks in an index yourself and get to vote. This is now even more practical as trade costs have recently been cut to zero for all major brokerages.

The average index fund owner is also not likely be spending time looking over the voting possibilities of 500 companies and aligning votes to decrease competition between them, even if that was possible. They just wouldn't vote on issues. The problem is that three funds can decided to vote on policies that reduce competition between companies and that they are big enough for the votes to matter.

Transferring votes to the underlying owners of the fund would in reality likely just cause those votes not to be cast. It is similar to just saying that the funds can't vote, but doesn't disenfranchise people who really want to vote and still gives all those shares the index funds own possible power.

</comment></comment></comment><comment><USER5> I think at some point we'll hit a saturation point on passively managed funds. What they're really doing is edging out the non profitable actively managed funds, and forcing managers to prove they can beat the market if they want investment. I also think we'll see more brokerages starting their own indices, which will lessen the power of any individual fund

<comment><USER6> Well think of it this way. Since index funds replicate the market exactly, then the non-index funds also on average replicate the market. It's just some funds beat the market while others underperform.

<comment><USER7> No. In theory we could have just two active (non-index) managers, and their average returns certainly would not replicate the market.

</comment></comment></comment><comment><USER8> Isn't it possible for the index funds to simply _not_ wield the power they have, and abstain from every vote? I was surprised that funds that are not actively managed are still actively engaging with public companies.

<comment><USER9> I don't know how votes are counted, but will that make it impossible to make positive changes? Or if they are not part of the total count, allow a minority of shareholders to vote against the fund's interests?

<comment><USER8> > [W]ill that make it impossible to make positive changes?

Yes, but that's consistent with the passive philosophy at the heart of index investing. I was surprised that index funds had an active interest in anything beyond reducing fees to customers.

</comment></comment></comment><comment><USER10> This is such a fascinating problem. On the one hand Jack Bogle's invention of the index fund has been so good for retail investors but because the process currently requires a middle man - i.e. one of the big three - these index funds have slowly become bloated with power.

What if the algorithm Vanguard uses was open sourced and could be self-hosted by independent investors?

Where each investor owns their portfolio outright and adjustments to the portfolio are made automatically by a free index manager bot that runs the simple algorithm an index fund manager like Vanguard would.

Why wouldn't something like that work?

<comment><USER11> Having spoken with few people, the process is still mostly people, building algorithms in Excel. Much of what drives decisions is research, and personal decision's, not automation.

I've heard AI trading has done very poorly as the system isn't predictable, it's people making decisions in ways which can become self fulfilling prophesies.

Algorithms when distributed would also fall victim to the fastest person benefiting the most

<comment><USER12> An index fund isn't doing research or making decisions though.

They invest in companies that make up an index. When a company enters the index they buy units in that company, when a company leaves the index they sell those units.

</comment></comment></comment><comment><USER13> While this seems (incredibly) scary it makes me think that this could be a huge opportunity for entrepreneurs (and some are currently undertaking it).

The fintech entrepreneur can carefully paint the picture of the dangers of the big 3 while advocating for smaller index funds for a smaller set of investors.

This smaller set of investors can have stocks based on their individual goals and interests. You just duplicate this over a lot more funds. The returns won't be as high initially but if the entrepreneur can convince customers that this must be done it should help spurn new markets towards sustainability or carbon reduction etc.

Edit: plz tell me if I totally misunderstood the article.

<comment><USER14> You just described M1 Finance (custom funds users can construct). Google Warren Buffett's Long Bet about passive vs active fund management (he won the passive argument). Even sophisticated active investors are having a tremendously difficult time achieving passive returns net fees. If you're not a sophisticated investor, I'd implore you to be cognizant of the challenges you'll face attempting active investment strategies, especially if you're investing retirement funds.

Passive index investing might not be perfect, but it seems to be the least worst option when evaluating fund costs and risk adjusted returns, and we're aways off from significant second order effects.

<comment><USER15> There are other use cases than returns, sometimes it has to do with availability of funds or tax issues that constrain the possibilities. Even something as simple as the full spectrum of risk tolerances and time-horizons isn't well served by existing index retirement funds (they all skew to be highly risky and equity focused). It's better to have the running of an index fund be a separate service from the selection of its holdings or the choosing of goals. Right now if you have a slightly different goal than the horde, you can only go to expensive active funds, advisors, or spend a great deal of time self-managing.

</comment></comment></comment><comment><USER16> > Index funds "are great for investors," says Elhauge, "but part of the reason > they're great for investors is exactly because of the anti-competitive > effects." Elhauge says the trusts of the late 19th century that gave rise to > today's antitrust laws also involved a form of common shareholding.

> She might want Coca-Cola to take big risks to crush Pepsi, and invest > capital in new products and markets to do so. An investor who holds both, on > the other hand, would prefer that Coke and Pepsi avoid price wars.

So the way we can solve this problem is to outlaw shares ownership of competing companies? Seems like a fair solution.

<comment><USER17> No because that is essential for hedging, and hedging is good.

<comment><USER18> I absolutely agree. If you could only invest in one tech company, who would have invested in Apple/Amazon/Google instead of IBM? These are now large, successful companies that were able to succeed because investors were able to hedge and invest in an entire sector.

<comment><USER16> > If you could only invest in one tech company, who would have invested in > Apple/Amazon/Google instead of IBM?

IMHO there shouldn't be Apple/Amazon/Google/IBM companies as they are today. I want Google and other companies be splitted to AdWords, GoogleSearch, YouTube, Android, Waymo companies. And they should not use their dominant/monopolistic position in search/ads areas to get unfair advantage in other areas.

So you would have to choose your investment between Android/Apple/WinMobile OS, AdWords/AdMob ads, Waymo/Cruise cars, Google/Yahoo/DuckDuckGo search, YouTube/Vimeo videos.

<comment><USER19> Including DuckDuckGo in your list of search companies exposes one of core issues that makes this idea unworkable. DuckDuckGo is basically just a skin that shells out to Bing, Yandex, or Google.

</comment></comment></comment></comment></comment><comment><USER20> Are we really supposed to get excited about _Bloomberg_ whining about the evils of index funds?

</comment><comment><USER21> How about the danger of three corporations being responsible for _liquidity_ in 30% of these shares.

What happens if one of these companies goes down, and with it, a need to liquidate 8% of Apple in a single day?

</comment><comment><USER22> Giant organization overseeing a huge number of competing interests and accountable by proxy to millions of individual shareholders.

This sounds like a government. Maybe we'll see voting for representatives and parties.

</comment><comment><USER23> I think there's a bigger issue with passive inversing. Once an equity is in a cap weighted index like the S&P 500 with a high weighting, like Apple, can't we end up in a situation where the individual company performance is irrelevant? Nobody will sell Apple because they just own it through their SP500 fund. As long as they are buying and holding the index fund, Apple remains at a high valuation. The only thing that differentiates individual stocks is active investors. And as they make up a smaller and smaller fraction of over investment, they become less relevant.

<comment><USER24> AAPL and similar stocks do show their share price changing in response to financial announcements, sales numbers, etc.

This concern is valid but I believe it only prevents price movement once a much larger majority of the market is passively managed.

<comment><USER25> I don't think it'd be much of a concern at a larger scale either. I stopped actively investing a long time ago because it wasn't worth my time, but if the market got to the point where it was responsive to reality, the increased returns would probably draw me back in. And before me would be institutional investors, picking up ~free returns. The system is designed to be self- equilibriating in this respect</comment></comment></comment>


FCC Kills Net Neutrality Hours After Comcast Introduces Nationwide Data Caps - <AUTHOR> http://www.dslreports.com/shownews/Comcast-Confirms-Usage-Caps-Going-Nationwide-After-Trials-128963

<comment><AUTHOR> [http://www.washingtonpost.com/blogs/the- switch/wp/2014/05/15...](http://www.washingtonpost.com/blogs/the- switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-priority-on- internet/)

The FCC proposal is supposed to prevent ISPs from degrading their non-fast lane service, but clearly that doesn't include data caps in Comcast's mind.

COMING SOON: 5 GB / Month non-fast lane access.</comment>


For C programmers that hate C++ - <AUTHOR> http://users.softlab.ntua.gr/~ttsiod/cpp.html

<comment><USER2> Hmm, the C code and C++ code aren't even solving the same problem, and they aren't using the same data structures. C++ uses inheritance while C uses a union, for no good reason. What in C++ is struct A : B { } is in C struct A { struct B b; }, not some weird union. Of course unions are not type safe.

And in practice, you can come close to the template solution with a macro for the loop. Sure, it will be a little more explicit about which functions are being called, but that's not a bad thing in my book. And, as with the C++, you'll have to build up the equivalent scaffolding and associated code, which I notice is conveniently left out of the C++ examples.h</comment>


Ask HN: What should future world-wide vulnerabilities be called? - <AUTHOR>

<comment><AUTHOR> StackWhack</comment>


McCarthy leads GOP charge against Silicon Valley - <AUTHOR> http://thehill.com/homenews/house/404642-mccarthy-leads-gop-charge-against-silicon-valley#.W41kDP-75FA.twitter <comment><USER2> Looks like someone grafted half a headline from the 1950s onto a modern one.</comment>


Ask HN: How can I boycott pro-SOPA Comcast if I live in San Francisco? - <AUTHOR>

I want to boycott Comcast because of their SOPA support.  I was thinking of switching to Monkeybrains, but my landlord won't let me install the needed antenna on the roof.<p>Any ideas? <comment><USER2> Try, for a start: <http://www.yelp.com/c/sf/isps>

And: <http://www.dslreports.com/forum/sanfran>

<comment><USER2> And: <http://www.netindex.com/download/4,30/San-Francisco/?tab=1></comment></comment>


Micropackages and Open Source Trust Scaling - <AUTHOR> http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/ <comment><USER2> I think this is a serious set of reasonable thoughts about the incident, and don't want to demean the article.

That said, I wish more people would talk both sides. Yes, every dependency has a cost. BUT the alternatives aren't cost free either. For all the ranting against micropackages, I'm not seeing a good pro/con discussion.

I think there are several lessons to be learned here (nixing "unpublish" is a good one, and I've not been impressed with the reaction from npm there) the most important of which is probably that we should change our build process: Dev should be pulling in updates freely to maintain the easy apply-fixes-often environment that has clearly been popular, then those should be pinned when they go past dev (to ensure later stages are consistent) and we should have some means of locally saving the dependencies to reduce our build-time dependency on package repos.

Sadly, though, I've not seen a lot of discussion on a reasonable way to apply those lessons. I've seen a lot of smugness ("Any engineer that accepts random dependencies should be fired on the spot", to paraphrase an HN comment), a lot of mocker ("haha, look at how terrible JS is!"), and a lot of rants against npm as a private entity that can clearly make mistakes, but not much in the way of constructive reflection.

Clearly JS and NPM have done a lot RIGHT, judging by success and programmer satisfaction. How do we keep that right and fix the wrong?

<comment><USER3> Essentially we're trying to figure out when it's appropriate for "my" code to become "everyones" code, and if there are steps in between. ("Standard library", for example.)

One thing that would be useful to this debate an analysis of a language ecosystem where there are only "macropackages" and see if the same function shows up over and over again across packages.

<comment><USER4> > One thing that would be useful to this debate an analysis of a language > ecosystem where there are only "macropackages" and see if the same function > shows up over and over again across packages.

Look no further than C++, where nearly every major software suite has its own strings, vectors, etc. implemented, frequently duplicating functionality already implemented in (1) STL, and (2) Boost. I seem to recall that the original Android Browser, for example, had no fewer than 5 kinds of strings on the C++ side of the code base, because it interfaced with several different systems and each had its own notion of what a string should be.

The advantage (or disadvantage) of including common functionality in macro packages is that you can optimize for your particular use case. In theory, this may result in more well-tailored abstractions and performance speedups, but it also results in code duplication, bugs, and potentially even poor abstraction and missed optimization opportunities (just because you think you are generalizing/optimizing your code doesn't mean you actually are).

Clearly, we need some sort of balance, and having official or de facto standard libraries is probably a win. Half the reason we're even in this situation is because both JS and C++ lack certain features in their standard libraries which implicitly encourage people to roll their own.

<comment><USER5> > Look no further than C++, where nearly every major software suite has its > own strings, vectors, etc. implemented, frequently duplicating functionality > already implemented in (1) STL, and (2) Boost.

In many ways problem exists because there used to be different ideas in how strings should be set up. Today we mostly decide on UTF-8 and only convert now to legacy APIs if needed. This is a bad comparison because it's literally caused by legacy code. C++ projects cannot avoid different string classes because of that.

</comment></comment></comment></comment><comment><USER6> > _Sentry depends on it 20 times. 14 times it 's a pin for 0.0.1, once it's a > pin for ^1.0.0 and 5 times for ~1.0.0._

This is what I was mentioning in the other thread (and being called a troll for... sigh). I appreciate the idealism of "if we have micromodules, we don't have to reimplement common helper functions, which scales to _thousands_ of bytes saved!". But in practice, there's craptons of duplicate dependencies with different versions. Which negatively scales to hundreds of kilobytes wasted. In code, in downloads, in install time, in developer time (because devs install things too. A lot more than end users in fact...), etc.

One of the many problems which means what's on paper doesn't at all correspond to what we actually get.

<comment><USER7> I don't see how that is worse than the alternative where every library rewrites its own version of the micromodules. With N libraries with their own version of leftpad, you get N copies of leftpad. With N libraries sharing versions of leftpad, you get <= N versions. Seems like a win to me...

<comment><USER8> Ideally you would cut down on dependencies on every level, and end up with significantly less than N dependencies.

If you have 5 similar string formatting libraries that depend on leftpad, you could collapse them into one, and have a single instance of leftpad inside the combined library. Less licenses, less READMEs, less time downloading, and with tree shaking you still get similar end result.

<comment><USER9> It would nice for packages to include other packages in it...

</comment></comment></comment></comment><comment><USER10> The problem with standard libraries is they are a standard library. A place where good code goes to die. Standard libraries also mean you can't use the particular version of the module you need; now you are pinned to the version of the standard library comes with the version of the language you are running on. The workaround there is to fork out the standard library code into...a module. Now, a lot of these modules are designed for old JS runtimes like old versions of IE, so you wouldn't have a standard library anyway.

There's plenty of good libraries like lodash and math.js that are pretty much the next best thing to a standard library.

If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault. That's like blaming git because you pushed some crappy code.

The problem was fixed 10 minutes later anyway. This whole discussion surrounding this is a combination of knee-jerk reaction, "waah", and realization of "Oh shit, depending on external code means _we are dependent on external code!_ "

If you want to code without dependencies, go write JavaEE. Everything is included, you don't need any third party dependencies, and you can use cutting-edge tech like JSP, app servers and JavaServer faces.

<comment><USER11> >If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault.

While I sort of agree, in the case of JavaScript, the language is so limited that people are attempting to make it into a general purpose language by gluing on stupid dependencies that really did belong in a "standard library", or directly in the language. The "isarray" function is silly, if you write code that need that kind of inside into data types, then you shouldn't have picked JavaScript.

I agree that it's a knee-jerk reaction, and only a few people where really affected. It does however highlighted a major short coming of JavaScript, the fact that it's not a usable language in it self, it needs libraries to be usable as a general purpose language. Hopefully ES6 will fix a lot of this.

<comment><USER12> Well, first of all, you don't have a choice on the client, and secondly, Array.isArray is in ES5 (see: [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray)).

</comment></comment></comment><comment><USER13> Since at least the 70s people have been trying to "componentise" software in the same way that electronics is componentised: rather than assembling something out of a pile of transistors, build _integrated circuits_ instead. The intent is to reduce cost, complexity and risk.

This has never yet quite worked out in software. Object-orientation was part of the resulting research effort, as are UNIX pipelines, COM components, microkernels and microservices. When it goes wrong you get "DLL Hell" or the "FactoryFactoryFactory" pattern.

It looks like the javascript world has forgotten about integration and instead decided to do the equivalent of assembling everything out of discrete transistors every time. The assembly process is automated, so it appears costless - until something goes wrong.

But really this is the fault of the closed source browser manufacturers, who prefer to attempt lockin over and over again through incompatible features rather than converge on common improvements.

<comment><USER14> I disagree. I think it has worked out quite well. Nowadays nobody has to write basic data structures or algorithms themselves. Unfortunately, the hard part of building software that is useful to today's businesses is not sorting lists or storing dictionaries.

But remember that things like computing a KWIC index used to be real problems back in the day that required serious programmer work. They have become trivial thanks to better libraries and better computers.

</comment></comment><comment><USER15> > My opinion query quickly went from "Oh that's funny" to "This concerns me".

This was my response as well:

> The combination of a micro-library culture, "semver" auto-updates, and a > mutable package manager repository is pretty terrifying.

[https://mobile.twitter.com/tlrobinson/status/712442098381754...](https://mobile.twitter.com/tlrobinson/status/712442098381754370)

Either of the second two properties are dangerous on their own, but culture of micro-libraries compounds the problem.

</comment><comment><USER16> Everyone is blowing the "micropackages are the problem" completely out of proportion. The real problem with the left-pad fiasco is that someone was able to revoke a package other people depended on. Packages should be immutable.

</comment><comment><USER17> To quote an old adage, package size doesn't matter.

The actual issue has to do with trusting a package of any size over time. This is true regardless of whether the package implements 1 line of code or 1000.

The trustworthiness of a package is a function of several factors. Code that is not actively maintained can often become less trustworthy over time.

What we need is one or more 3rd party trust metrics, and our bundling/packaging utilities should allow us to use that third party data to determine what is right for our build.

Maybe some of us want strong crypto, maybe others of us want adherance to semver, maybe others want to upgrade only after a new version has had 10K downloads, maybe others only want to use packages with a composite "score" over 80.

On the continuum of code quality from late night hack to NASA, we all must draw a line in the sand that is right for a particular project. One size does not fit all.

It's a big mistake (as well as a profound example of bad reasoning) to blame micropackages. The size of the package has nothing to do with it. Any codebase with any number of dependencies faces some risk by trusting the maintainers or hosting of those dependencies to third parties, which is the problem we need to do a better job of solving.

<comment><USER18> The size of the package matters when smaller packages tends to higher numbers of packages as dependencies.

<comment><USER17> Larger projects tend to have more dependencies too, so why not rail against large projects?

<comment><USER18> Because there will be fewer of them.

<comment><USER17> Fewer packages? Who is to determine the optimal number of packages? Not sure how that benefits anyone. I hesitate to accuse you of trolling but your argument does not seem all that coherent.

<comment><USER18> It's pretty simple: the more dependencies there are, the more upstream authors you have to trust.

<comment><USER17> That assumes a lot. My code may utilize one dependency that itself utilizes a few dozen useless ones. Whereas someone else may carefully choose 20 dependencies, none of which include any dependencies.

The issue is measuring the trustworthiness of a dependency, and recursively doing that operation throughout the dependency graph.

Simply focusing on the number of dependencies or the size of a dependency is silly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I heard one of js "devs" refer to npm as nano package management. It sounded more like abdication of duty as a developer to understand what you are adding as a dependency, why, and the long-term cost.

How many developers here would gladly add a rogue "dependency", like a developer they had never spoken to before, into their project without some care? And yet the willingness to open the front and literal back doors of the project to so many dependencies, like low-quality functions-as-a-module is astounding.

</comment><comment><USER20> The large amount of python standard packages is clearly a benefit for Python. Node should start a vetting process to be included into a standard package system, and start moving in key libs, then host official doc.

I guarantee that the weaknesses of the NPM ecosystem are already known and exploited by bad actors. There are people who earn large 6 figure salaries / consulting fees for finding and exploiting these issues. This is a wakeup call that we need to do something about it.

</comment><comment><USER21> A lot of the value in these remarks is that they are coming from the author of Flask, the most popular micro _framework_ for Python, which itself has a _massive_ extension tree that also does suffer a lot of the same problems as NPM - trying to update or maintain a Flask project often involves navigating a tremendous amount of dependency hell on all kinds of modules, from flask- sqlalchemy to flask-wtforms to flask-bootstrap to flask-oauth.. etc. The worst part is tons of these modules and extensions are dead projects that code rot for years, but when you implement everything independently in its own git tree it gets many fewer eyes upon it, as Armin mentions in the OP regarding one liner Node packages.

But it does not spiral out of control nearly as bad as any attempt at frameworks on NPM, because unlike Node almost every Flask extension depends on three things - Flask, the external package the extension attaches to( ex: WTForms) and Python's standard library.

A similar Node package would depend on possibly hundreds of tiny one liners to replace the absence of standard library.

Which gets to the heart of the problem, right? The reason I've never even considered Node is because Javascript is like PHP - a mutant language born of need rather than intent, that kind of just grew over time to fill use cases constrained by its unique position in the ecosystem rather than as what someone considered the "best answer to the job". Python (3) is almost entirely anthesis to that. Writing Python is a joy because it is designed ground up to be a paradigm to solve problems, not a problem that breeds a paradigm.

There is no way for Node to fix this as long as it tries to be browser compatible. We will never see ECMAScript standards adopt an ISOC++ stance of maturing the language with a comprehensive standard library to meet the needs of the language in the day and age it is being used, because there are _very_ disparate interests involved in Javascripts language design going forward. That is its blessing and curse - Javascript will never grow into a Java-scale monstrosity of standard library bloat because a tremendous number of people involved in Javascript also have to implement Javascript and thus don't want a larger surface area of work to do. But it is important to remember that Javascript was never _meant_ to be anything. It was made for dynamic HTML pages in Netscape. The fact that two decades later it is being shoehorned into web server dev and desktop applications _should_ be scary.

</comment><comment><USER22> Maybe we could start to publish signed approvals of specific package hashes.

For example: "I, mbrock, think that pad-left v1.0.3 with hash XYZ seems like an uncompromised release."

Then the tool that upgrades packages could warn when a release isn't trusted by someone you trust (or transitively via some trust web scheme).

The approval system becomes like a "release review" process.

<comment><USER23> That would probably be doable using a PGP-style trust system. Don't know if it'd add much security in practise though, since the "trust these declarations of trust" decision would most likely be automated.

<comment><USER22> Yeah, just GPG with Keybase and some place to publish the messages.

Trustworthy people wouldn't approve releases automatically... but then, who's trustworthy?

Like Pynchon wrote, paranoia is the garlic of life...

<comment><USER24> You still have to decide who to trust, but having a collection of many independent parties verifying a package can be a useful signal even if you don't have anyone directly in your trust chain. It makes it a lot harder for rogue releases to go unnoticed.

</comment></comment></comment></comment><comment><USER25> Help me understand why these micropackages exist in a world where tree shaking is a thing? Why is there no stdlib that rolls up all of the commonly used small dependencies? (I'm kind a n00b to JS so it's a non-rhetorical question.)

<comment><USER26> There are packages which roll these up. Lodash is popular.

But there's a philosophy and mindset in JS which is relatively unique to other languages which is to optimize for download size to the browser (noting in another comment, tree shaking its not entirely yet "a thing"). Users don't want to include all of Lodash (or a stdlib) in their download package to just use _.isArray. Now Lodash does also provide the ability to use subpackages specific to a function (lodash.isArray) can be loaded as an independent package to mitigate that download hit but its relatively unique in that sense.

<comment><USER5> I find tree shaking a much better solution for that issue.

</comment></comment></comment><comment><USER27> Good article even though I don't agree with all the conclusions.

I find a good way to think about things is that every single dependency you have adds another set of people you have to trust.

You're trusting the competence of the developer (i.e. that the library has no security flaws), you're trusting their intent (i.e. that they don't deliberately put malicious code into the library) and you're trusting their Operational Security practices (i.e. that their systems don't get compromised, leading to loss of control of their libraries).

Now when you think about how little you know about most of the owners of libraries you use, you can see possibility for concern.

The bit I disagree with the article about is signing. I personally think that developer signing is a useful part of this as it takes the repository owner out of the trust picture (if done correctly). Without it you're also trusting the three items above for the repository provider and it's worth noting that a large software repo. is a very tempting target for quite a few well funded attackers.

Docker at least has provided some of the technical pieces to address this in their repositories with content trust...

</comment><comment><USER28> I think the problem is in npm and not in the micro-modules.

Writing isomorphic, cross-browser code in a language full of edge-cases, like JavaScript is hard.

Oneline function, but 20 lines of tests and another 20 test environments.

The solution should not come from people that write only front-end JS code. I'm waiting for a response by the libraries that were broken by left-pad.

</comment><comment><USER29> Maybe the solution for highlevel languages is to just routinely add useful helper functions, either in separate name spaces or directly to global with a naming convention to avoid conflicts. If thousands of people are doing the same thing it really doesn't make any sense for them to all come up with their own version.

<comment><USER30> Thinking about this for the last few days, I think the Java SE / commons- approach seems the most sensible to me.

Your stdlib is bundled with the language runtime and contains binaries, OS interactions and the necessary fundamental stuff. Updating this is hard, because this depends on hard things like the OS, and because it must maintain compatiblity with everything.

However, the commons-package can add all kinds of pure (as in, just the language in question) stuff to the language, such as several dozens of collections, all kinds of utility languages, and so on. Updating this would be a lot less risky than updating the entire language runtime, especially if it uses proper semantic versions. This would allow this lib to iterate faster and include these utility-functions easier as well.

<comment><USER29> The example that always drives me crazy is itertools in the Python standard library. In the documentation there is a recipes* section that lists 23 helpful functions, instead of just including them in the library

* [https://docs.python.org/2/library/itertools.html#recipes](https://docs.python.org/2/library/itertools.html#recipes)

<comment><USER31> What's super frustrating is that Python 3 would've been an ideal opportunity to move those into the standard library, but it was never done.

</comment></comment></comment></comment><comment><USER32> There is a bigger debate on micropackages, for sure. But even in the sort term, breaking your build instantly every time third parties make changes is just madness. Reduce operational dependencies as well as library dependencies.

This is one approach we used to deal with this last year, for example, on build/devops side: [https://medium.com/@ojoshe/fast-reproducible-node- builds-c02...](https://medium.com/@ojoshe/fast-reproducible-node- builds-c02bca056739#.it1j8qp2q)

</comment><comment><USER33> Isn't this similar to broken links on the web? You can either:

1) Bundle everything in your distribution. Not unreasonable, but would be nice to have a hybrid protocol that lets the publisher store a signed copy of all the dependencies but only send them on request (so less duplication is sent over the wire).

2) Have the same as 1 but in dedicated "mirrors" and persistent distributed storage a la freenet. Files are only deleted if there isn't enough space on the network and they are the least-- recently-requested ones.

</comment><comment><USER34> I asked about this last year:

[https://news.ycombinator.com/item?id=9629091](https://news.ycombinator.com/item?id=9629091)

</comment><comment><USER35> Totally agree, I never understood this fetish developers have with small packages. It's probably related to the 'Unix philosophy' but it just doesn't scale in a web context...

Personally, I much prefer a single nice, complete, well-polished module that works perfectly over lots of tiny modules which are awesome individually but which suck when used together.

</comment><comment><USER36> This was well written. The balance between convenience and liability is something that takes time to digest.

I don't really understand why there isn't a stdlib of these "micropackages" that can be downloaded to save a lot of effort.

</comment><comment><USER37> Micro deps are the sign of something missing from the core language. We should be working to have that expanded and not have it shouldered to a package manager system and community to fill IMO.

</comment><comment><USER38> There's where git-vendor [0] comes in place!

[0]: [https://brettlangdon.github.io/git- vendor/](https://brettlangdon.github.io/git-vendor/)

</comment><comment><USER39> Learn about clean room. If you saw the code. You'll copy it subconsciously. If the license requires attribution and you don't. You're in trouble.

</comment><comment><USER40> > _Multiplied with the total number of downloads last month the node community > downloaded 140GB worth of isarray._

This is not true. NPM locally caches every module the first time it is downloaded.

Therefore with widely downloaded modules such as isarray, it is very likely it has already been downloaded on the local system and so is pulled from the cache.

The actual percentage of fresh downloads from NPM in a real-world deployment is overwhelmingly small.

<comment><USER5> > This is not true. NPM locally caches every module the first time it is > downloaded.

This is literally coming from the npm website. Presumably that number is what it says: downloads.

</comment></comment><comment><USER41> Why is nobody talking about the real issue? That NPM unpublished someone's module because a lawyer threatened them in an email.

People should be upset that NPM will just take your module away if they feel it's appropriate. The whole reason left-pad was unpublished has been completely ignored.

</comment><comment><USER42> Holy crap, I had a look through [https://www.npmjs.com/~sindresorhus](https://www.npmjs.com/~sindresorhus)

There are so many one line packages:

[https://github.com/sindresorhus/is- finite/blob/master/index....](https://github.com/sindresorhus/is- finite/blob/master/index.js)

[https://github.com/sindresorhus/is- fn/blob/master/index.js](https://github.com/sindresorhus/is- fn/blob/master/index.js)

[https://github.com/sindresorhus/is- gif/blob/master/index.js](https://github.com/sindresorhus/is- gif/blob/master/index.js)

[https://github.com/sindresorhus/is-github- down/blob/master/c...](https://github.com/sindresorhus/is-github- down/blob/master/cli.js)

[https://github.com/sindresorhus/is- ip/blob/master/index.js](https://github.com/sindresorhus/is- ip/blob/master/index.js)

[https://github.com/sindresorhus/is- npm/blob/master/index.js](https://github.com/sindresorhus/is- npm/blob/master/index.js)

[https://github.com/sindresorhus/is- obj/blob/master/index.js](https://github.com/sindresorhus/is- obj/blob/master/index.js)

[https://github.com/imagemin/advpng- bin/blob/master/lib/index...](https://github.com/imagemin/advpng- bin/blob/master/lib/index.js)

[https://github.com/chalk/ansi- regex/blob/master/index.js](https://github.com/chalk/ansi- regex/blob/master/index.js) (my favourite)

[https://github.com/sindresorhus/array- move/blob/master/index...](https://github.com/sindresorhus/array- move/blob/master/index.js)

[https://github.com/sindresorhus/compare- urls/blob/master/ind...](https://github.com/sindresorhus/compare- urls/blob/master/index.js)

[https://github.com/sindresorhus/debug- log/blob/master/index....](https://github.com/sindresorhus/debug- log/blob/master/index.js)

[https://github.com/sindresorhus/file- url/blob/master/index.j...](https://github.com/sindresorhus/file- url/blob/master/index.js)

[https://github.com/sindresorhus/fix- path/blob/master/index.j...](https://github.com/sindresorhus/fix- path/blob/master/index.js)

[https://github.com/sindresorhus/fn- args/blob/master/index.js](https://github.com/sindresorhus/fn- args/blob/master/index.js)

[https://github.com/sindresorhus/fn- name/blob/master/index.js](https://github.com/sindresorhus/fn- name/blob/master/index.js)

[https://github.com/sindresorhus/globals/blob/master/index.js](https://github.com/sindresorhus/globals/blob/master/index.js)

[https://github.com/sindresorhus/imul/blob/master/index.js](https://github.com/sindresorhus/imul/blob/master/index.js)

[https://github.com/sindresorhus/is-text- path/blob/master/ind...](https://github.com/sindresorhus/is-text- path/blob/master/index.js)

[https://github.com/sindresorhus/is- up/blob/master/index.js](https://github.com/sindresorhus/is- up/blob/master/index.js)

[https://github.com/sindresorhus/is- travis/blob/master/index....](https://github.com/sindresorhus/is- travis/blob/master/index.js)

[https://github.com/sindresorhus/is- video/blob/master/index.j...](https://github.com/sindresorhus/is- video/blob/master/index.js)

[https://github.com/sindresorhus/is- webp/blob/master/index.js](https://github.com/sindresorhus/is- webp/blob/master/index.js)

[https://github.com/sindresorhus/is- archive/blob/master/index...](https://github.com/sindresorhus/is- archive/blob/master/index.js)

[https://github.com/sindresorhus/is- admin/blob/master/index.j...](https://github.com/sindresorhus/is- admin/blob/master/index.js)

[https://github.com/sindresorhus/is-absolute- url/blob/master/...](https://github.com/sindresorhus/is-absolute- url/blob/master/index.js)

[https://github.com/sindresorhus/ipify/blob/master/index.js](https://github.com/sindresorhus/ipify/blob/master/index.js)

[https://github.com/sindresorhus/is-url- superb/blob/master/in...](https://github.com/sindresorhus/is-url- superb/blob/master/index.js)

[https://github.com/sindresorhus/is- tif/blob/master/index.js](https://github.com/sindresorhus/is- tif/blob/master/index.js)

[https://github.com/datetime/leap- year/blob/master/index.js](https://github.com/datetime/leap- year/blob/master/index.js)

[https://github.com/sindresorhus/lpad/blob/master/index.js](https://github.com/sindresorhus/lpad/blob/master/index.js)

[https://github.com/sindresorhus/md5-hex/blob/master/index.js](https://github.com/sindresorhus/md5-hex/blob/master/index.js)

And I ran out of willpower, at only L. Seems to me the complete lack of any decent standard library has caused this Cambrian explosion of packages, and the overhead is astounding. Sure it's appealing to google "nodejs validate ip", then run "npm install is-ip" and use it with "require('is-ip')", but fuck me how wasteful do you want to be. My frontend ember app ends up installing over 500mb of dependencies (most of which is useless test files and other redundant fluff files). How has this happened?

What's to stop one of those one line packages adding a malicious one liner that concatenates and uploads your super-secret private source code to somebodies server? You're really trusting the complete integrity of your codebase because you depend on "is-array", because you can't be bothered to write "x.toString() === '[object Array]'", and JS introspection (which seems so (ab)used) is so broken that this is needed? Woah.

<comment><USER43> > because you can't be bothered to write "x.toString() === '[object Array]'"

([1,2,3]).toString() => "1,2,3"

<comment><USER42> My bad, '({}).toString.call([1,2,3])'.

Because type introspection is so ugly in JS, but so needed, that it's hidden behind 'require('is-array')' to make it palatable. Ridiculous.

</comment></comment></comment><comment><USER12> It's telling that only the immature JS ecosystem thinks this is a good idea.

</comment><comment><USER44> If you don't know history.....

40 years of computer experience as EE, coder, IT security, DBA tells me; when IT moved from a way to do work (science) to a thing of its own (marketing); this happened during Dot-Com bubble, time to market became the goal and security was tossed. You here this in mantras like:

Push NOW fix latter. Fail fast and often.

I say: Secure, Complete, Fast - Pick two.</comment>