3 ms·

From Why BuckleScript[1] Large JS output even for a simple program "In BuckleScript, a Hello world program generates 20 bytes JS code instead of 50K bytes. Th

From Why BuckleScript[1] Large JS output even for a simple program "In BuckleScript, a Hello world program generates 20 bytes JS code instead of 50K bytes. This is due to the fact that ... all BuckleScript’s runtime is written in OCaml itself so that these runtime libraries are only needed when user actually call it." What happens when you go beyond Hello World though? Surely there's some overhead vs. plain JS. For example, Hello World in Scala.js is tiny, but once you touch, say, the Scala collections library, then file size increases significantly. In the end, once you go beyond trivial applications, there's a 150KB baseline tax to pay for using the full power of Scala in the browser. If BuckleScript provides an OCaml-like language with file sizes comparable to plain JS that is both compelling and impressive. [1] http://bloomberg.github.io/bucklescript/Manual.html#_problems_of_javascript_how_bucklescript_solves_it http://bloomberg.github.io/bucklescript/Manual.html#_problem...

hongbo_zhang 10y ago
Unlike scalajs, bucklescript maps one OCaml module to one Js module, it is like coffecscript/typescript compilation model, there is no tax on the code size. You can write very clean code, here is an example of avl tree in ocaml compiled into JS(http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tree http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tr...)
- virtualwhys 10y ago
  ^ that's completely ridiculous. Sounds like Reason can run the show as well (OCaml's crufty syntax has always bothered the SML'er in me), going to give this a look.
- sjrd 10y ago
  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. [1] https://github.com/scala/collection-strawman https://github.com/scala/collection-strawman
  - paulddraper 10y ago
    .NET was (past tense) also a target of Scala. Also didn't work out. Java is the greatest and worst part of Scala. Without Java, the language would be far, far less popular than Haskell. With Java, it has a lot of forced compatibilities, e.g. null.
    - sjrd 10y ago
      > Also didn't work out. 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. [1] https://scaladex.scala-lang.org/search?q=&page=1&sort=dependentCount https://scaladex.scala-lang.org/search?q=&page=1&sort=depend...
      - paulddraper 10y ago
        > Are you implying that Scala.js didn't work out? Er, definitely not. Bad mis-statement on my part. Should have said "also had challenges." And you're correct about type erasure. Scala/Scala.js/SBT are my tools of choice for web apps. I gave a talk "Scale your code with Scala.js" at Fluent last year https://conferences.oreilly.com/fluent/fl-ca-2016/public/schedule/detail/46780 https://conferences.oreilly.com/fluent/fl-ca-2016/public/sch...
        sjrd 10y ago
        Cool! I had completely misunderstood your earlier comment ;)
Volundr 10y ago
I've actually been playing around with building a Screeps AI in various languages, and found the sizes the be interesting. It's not really apples-to-apples since all of the implementations aren't near the same, but I think it provides a bit of context in terms of order of magnitude. Everything using the closure compiler with advanced compilation (for screeps I don't usually minify, but I think the dead-code elimination is important when comparing sizes): Bucklescript: 16K Haste (Haskell): 36K ClojureScript: 144K It's worth noting the Clojue version is the furthest along, and the Bucklescript version is the least, but all do some ffi and list manipulation. I did some simple tests with ghcjs, but it was producing files over 1m even for simple "Hello World" type code (I think because it includes the entire Haskell threaded runtime), so I didn't go very far with it. [1] https://screeps.com/ https://screeps.com/

hongbo_zhang 10y ago

Unlike scalajs, bucklescript maps one OCaml module to one Js module, it is like coffecscript/typescript compilation model, there is no tax on the code size. You can write very clean code, here is an example of avl tree in ocaml compiled into JS(http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tree http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tr...)

virtualwhys 10y ago
^ that's completely ridiculous. Sounds like Reason can run the show as well (OCaml's crufty syntax has always bothered the SML'er in me), going to give this a look.
sjrd 10y ago
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. [1] https://github.com/scala/collection-strawman https://github.com/scala/collection-strawman
- paulddraper 10y ago
  .NET was (past tense) also a target of Scala. Also didn't work out. Java is the greatest and worst part of Scala. Without Java, the language would be far, far less popular than Haskell. With Java, it has a lot of forced compatibilities, e.g. null.
  - sjrd 10y ago
    > Also didn't work out. 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. [1] https://scaladex.scala-lang.org/search?q=&page=1&sort=dependentCount https://scaladex.scala-lang.org/search?q=&page=1&sort=depend...
    - paulddraper 10y ago
      > Are you implying that Scala.js didn't work out? Er, definitely not. Bad mis-statement on my part. Should have said "also had challenges." And you're correct about type erasure. Scala/Scala.js/SBT are my tools of choice for web apps. I gave a talk "Scale your code with Scala.js" at Fluent last year https://conferences.oreilly.com/fluent/fl-ca-2016/public/schedule/detail/46780 https://conferences.oreilly.com/fluent/fl-ca-2016/public/sch...
      - sjrd 10y ago
        Cool! I had completely misunderstood your earlier comment ;)

Volundr 10y ago

I've actually been playing around with building a Screeps AI in various languages, and found the sizes the be interesting. It's not really apples-to-apples since all of the implementations aren't near the same, but I think it provides a bit of context in terms of order of magnitude. Everything using the closure compiler with advanced compilation (for screeps I don't usually minify, but I think the dead-code elimination is important when comparing sizes): Bucklescript: 16K Haste (Haskell): 36K ClojureScript: 144K It's worth noting the Clojue version is the furthest along, and the Bucklescript version is the least, but all do some ffi and list manipulation. I did some simple tests with ghcjs, but it was producing files over 1m even for simple "Hello World" type code (I think because it includes the entire Haskell threaded runtime), so I didn't go very far with it. [1] https://screeps.com/ https://screeps.com/