I like that BuckleScript has chosen the module-by-module design, if only to explore more design space than what was previously done in Scala.js and ClojureScript.
I do not think this is what makes the 150 KB tax of Scala.js, though. The dead code elimination of Scala.js is really good, plus we combine it with Closure as well. But it faces a very difficult challenge: the entanglement of the Scala standard library. The collection library was designed when the JVM was the only target, and decoupling within the collections library was definitely not in the requirement set. This is why, once you touch the Scala collections library in Scala.js, you receive 150 KB worth of (non-gzipped) code. There is currently a large-scale effort to redesign the collections library for Scala 2.13 [1], with, among others, a desire to reduce inter-dependencies (while keeping most of user-level compatibility). This should hopefully significantly improve the situation of Scala.js regarding code size for smallish applications, as you will only pay for the collections you actually use; not the entire set of collections once you require one of them.
Are you implying that Scala.js didn't work out? That would be denying the huge success it has within the Scala community. It is notably supported by most major Scala libraries. To back this by data, it appears 5th in a ranking of Maven artifacts based on the number of artifacts depending on it [1]. Above it are Scala itself, Specs2, Akka and scoverage.
Scala/.NET didn't work out because we never managed to reconcile the type system of Scala with that of the CLR. For JavaScript, we did manage that, and pretty easily: it's much easier to erase all types than converting from an advanced type system to another advanced type system.
I do not think this is what makes the 150 KB tax of Scala.js, though. The dead code elimination of Scala.js is really good, plus we combine it with Closure as well. But it faces a very difficult challenge: the entanglement of the Scala standard library. The collection library was designed when the JVM was the only target, and decoupling within the collections library was definitely not in the requirement set. This is why, once you touch the Scala collections library in Scala.js, you receive 150 KB worth of (non-gzipped) code. There is currently a large-scale effort to redesign the collections library for Scala 2.13 [1], with, among others, a desire to reduce inter-dependencies (while keeping most of user-level compatibility). This should hopefully significantly improve the situation of Scala.js regarding code size for smallish applications, as you will only pay for the collections you actually use; not the entire set of collections once you require one of them.
[1] https://github.com/scala/collection-strawman