Hacker News new | past | comments | ask | show | jobs | submit login

The bare minimum for a hello world is 6 KB (before gzip). But of course as soon as you start using Scala collections, it's getting bigger. The minimum for a realistic application is 90 KB (before gzip).

That's less than your typical JavaScript framework, so for any realistic application it shouldn't be a concern.




For refernce- Jquery unzipped is similar size- 87K and while it adds much more functionality, Scala collections easily trump jquery's in usability and power.

SJRD, Would you also add a bit more info about how this size increases? I haven't cared much but it seems from your comments that the slope should be much less once you reach 90kb.


ClojureScript ends up somewhere around the same size. Maybe it's some magic number that a full-featured environment converges to.

Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.


There is a significant difference between CLJS and Scala.js regarding their use of GCC (Google Closure Compiler).

In ClojureScript, GCC is a user-visible feature of the toolchain, so users are encouraged to use GCC-compatible libraries and the Closure Library in particular.

In Scala.js, GCC is really an implementation detail of the toolchain, and its constraints are completely abstracted away from the user. This does not really encourage using GCC-oriented libraries like the Closure Library.

The two approaches each have pros and cons:

* CLJS' approach allows tree shaking across the CLJS code and the GCC-compatible libraries that are used. However, it makes it more difficult to use libraries that do not comply with GCC's Advanced Optimizations requirements, as one needs to declare the proper `externs` files.

* Scala.js' approach means that you can use any JavaScript library out of the box, whether or not it was designed for GCC, and without having to declare any `externs` file. However, it means that GCC's tree shaking will not be applied across the Scala.js code and the JS libraries. It only applies to Scala.js' own code.


I think the externs file maneuver might be outdated.

Admittedly, I'm using shadow-cljs as my go-to compiler (so I'm not sure what the state of vanilla is), but all I do is yarn add <package>, and then require it in the file where I want to use it, and interact with it as if it were any other library.

Though it is true of shadow-cljs as well that it doesn't try to tree-shake external (non-CLJS/Closure) libs by default, though it will do it for project code and Clojure libraries.


Yes once you're at 90 KB the slope will be much less. It will simply grow with the actual code of your app.


Indeed, once you end up pulling in most common Scala classes (collections, futures, etc.), adding new functionality to your app increases app size by very little. Our app has ~600KB gzipped js (attributable to Scala.js compiled code) + ~200KB of React and other libraries. The overall size has barely moved beyond +-100KB in last few years despite adding new functionality all the time.

Once Scala.js supports lazy loading of modules (hopefully soon after 1.0), the size issue will have significantly less practical impact.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: