Search This Blog

I Shrunk my Dart-to-JS code by 11X and So Can You

Dart, the structured and scalable programming language for web apps, compiles to JavaScript thanks to dart2js. This means Dart apps run across the modern web. When you compile to JavaScript, you want to ensure dart2js generates the smallest amount of bytes. Less bytes means smaller bandwidth bills, and faster load times, and longer battery life. All good things! Read on to learn how to minify your generated JavaScript.

For this example, I will use the offline-enabled Todo app that I built to highlight Lawndart, my easy library for browser storage. The Todo app uses quite a few libraries:

dart:html

Lawndart

WebSQL

IndexedDB

Local storage

Web UI

The original generated JavaScript output size was 612,249 bytes. Minified, it became 289,840 bytes. Minified and gzipped it became 56,496 bytes. That's about 11X smaller than the original output!

(Measuring the original size of the code is tricky. Do I count the lines that I wrote? Do I count the lines generated by the Web UI compiler? I count 9,313 bytes of generated Dart code from the Web UI compiler, which is the code that would be shipped down to Dartium during development. This does not count the size of the packages required. Also, most developers would run a tree-shaking tool on the Dart code if they want to ship pure Dart in production. When I ran dart2dart to generate a single file that contained all the Dart code required for the app, I ended up with 44,860 bytes unminified and ungzipped.)

Let's learn how to get compiled JavaScript output as small as possible.

Step One: Turn on Minification

The editor does not ship with minification turned on by default. Say what?! Fear not, we can fix that.

The file shrinks to 56,496 bytes with gzip, a 11X shrinkage from the original!

Step Three: There is no step three!

Yup, just use --minify with dart2js and be sure your server has turned on compression/gzip.

To be sure, we're not yet happy with the output size and we're working hard to generate even smaller code. However, minification really helps and you should use it today. Please file bugs and feature requires at dartbug.com. Thanks!

Popular posts from this blog

Now, this has to have a built-in somewhere in Scala , because it just seems too common. So, how to convert an Array to a List in Scala? Why do I need this? I needed to drop to Java for some functionality, which in this case returns an Array. I wanted to get that Array into a List to practice my functional programming skillz. **Update**: I figured out how to convert Arrays to Lists the Scala way. Turns out it's a piece of cake. val myList = List.fromArray(Array("one", "two", "three")) or val myList = Array("one","two","three").elements.toList The call to elements returns an Iterator , and from there you can convert to a List via toList . Nice. Because my first version wasn't actually tail recursive, what follows is a true tail recursive solution, if I were to implement this by hand. The above, built in mechanism is much better, though. object ArrayUtil { def toList[a](array: Array[a]): List[a] = { d

In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F

In which the virtues of automated mechanical arboreal pruning are extolled over quaint manual labor, as applied to web development build processes. The setup Ever notice how the primary bit of marketing for many traditional web programming libraries is their download size? Why is that? Check this out: Why does size matter so much for these libraries? Your first instinct is probably, "because the more bytes you shuttle across the wire, the slower the app starts up." Yes, this is true. I'd also say you're wrong. The primary reason that size matters for these libraries is because traditional web development has no intelligent or automated way to prune unused code so you can ship only the code that is used over the wire. The web is full of links, yet web dev has no linker The web development workflow is missing a linking step. A linker's job is to combine distinct project files into a single executable. A smart linker will only incl