Feb
27
2013

Livenode — Live-code your NodeJS application

I'm working on a NodeJS application for Kendo UI. If you've been following me for a while, you probably know that I'm not the biggest fan of NodeJS—however, it seems that for this project Node is the best option, so I actually pushed for it.

A small annoyance that I'm trying to “fix” is the requirement to restart the server all the time in order to test changes. After some years with Common Lisp, I know there are better ways to do development than restarting the program — so here's Livenode, a module that allows to “live-code” a NodeJS application.

[ read more... ]


Jan
11
2013

Enterprise tools

Enterprise tools take an idea which is essentially simple and beautiful, and place a mountain of mud over it: acronyms, nouns, APIs, XML (and XSLT, DTDs, SOAP!, WSDL!) and the list is endless. Such that you don't see the beauty anymore; you don't see it simple anymore. You then live in constant fear that everything has to be enormously complex, ungodly hideous, and you thank your Enterprise Tools Vendor, your new God, for providing you with an IDE that makes life bearable, completely losing sight of the fact that it's the Enterprise Bullshit itself which adds in the complexity. You're locked to your Vendor, and you're doomed to never see beauty again.


Nov
13
2012

Thoughts on CommonJS / RequireJS

This rant is to explain this tweet. The short version is, I think they introduce more problems than they solve. While I do admit there is a need to define packages in JavaScript, it should probably be addressed at language level. In this fabulous class, Gerald Jay Sussman says “I consider being able to return procedural values, and therefore to have first-class procedures in general, as being essential to good modular programming” and continues saying that first-class functions cover all modularity needs, including making package systems. That's certainly true, but no language I know, not even Scheme, relies solely on that for defining a module system. Except JavaScript.

[ read more... ]


Nov
8
2012

Should you switch to UglifyJS2?

Every now and then somebody asks me if UglifyJS v2 is ready for production use. I'd say it is, but it's hard to back that claim without a lot of users. Version 1 got some huge popularity boost after John Resig's twit about it and after jQuery switched to it. Thanks to being so popular, a lot of issues were identified and fixed. Something similar needs to happen to V2.

Here are some views on the status of V2 compared to V1 and other compressors.

[ read more... ]


Oct
16
2012

UglifyJS online demo

The UglifyJS2 API documentation pages are more or less complete. I also worked on an online demo which allows you to minify scripts from your browser; the intended use case is just to demonstrate features of UglifyJS like compressor/beautifier options and source maps. You can minify a script and click some token in the minified output and the editor will move to the original position of that token in the initial code. You can easily see all the warnings that UglifyJS dumps, and click them to go to the original location and fix them.

It's only tested with Chrome and Firefox. Should work with Safari too, but I'm pretty sure it won't work in Opera or IE. Try it out! If it doesn't appear to work and you visited this website recently, please clear the cache. If you have any comments or suggestions I'd love to know about it!


Oct
4
2012

UglifyJS — why not switching to SpiderMonkey AST

Yesterday I wanted to publish version 2 on NPM and make it official, but I hit this NPM issue. Seems it's now fixed, but I'm holding it off to finish a new feature that I'm working on (import the SpiderMonkey AST), so you still have to use the Git tree to play with it.

I completed the CLI tool with a bunch of new options and wrote the documentation in the README. It's now possible to keep certain comments in the output. Still no API documentation so far, but it'll come shortly (I'll actually have a dedicated section on this website for UglifyJS).

Next, some points about why I'm not switching to the SpiderMonkey AST internally. Tl;dr: I don't quite like it. Also, I'd kinda have to rewrite the mangler and compressor from scratch. That's Esmangle's job. Any case, UglifyJS will support the SpiderMonkey AST by converting it to our internal AST.

[ read more... ]


Sep
17
2012

UglifyJS2: compression beats version 1

Thank you again for your contributions to my pledgie!

Today I pushed out another batch of commits. I've spent quite some time on the compressor and it does very well in my tests. On jQuery it beats version 1 by 227 bytes after gzip (although surprisingly, the size before gzip is bigger by 80 bytes).

Following there's description of some cases where it performs better than v1.

[ read more... ]


Sep
10
2012

Source maps for Emacs

Source maps turn out to be a handy tool not only for debugging minified code, but also for debugging the minifier ;-) My use case is this: (1) minify a big JS code, but request indented output. Then open that uglified code in Emacs and look at it, tryin' to figure out if compression is correct or wrong, and how could I make it better. It's extremely useful at this point if I could quickly jump to the original source, at the location where the thing under the cursor is coming from, starting from the minified file.

[ read more... ]


Sep
5
2012

UglifyJS v2 news

Update (Sep 18): I posted more news. The compressor beats UglifyJS v1 now on jQuery and on other libraries I tried. Also, the jQuery test suite is fully covered after minification.

First, a big THANK YOU! to everybody who donated so far! I was silent since I started the funding campaign, but my motto is “work, not talk”. I've been hard at work actually and I'm happy to announce that UglifyJS v2 has got support for generating source maps, a pretty exhaustive compressor (it beats v1 in some of my tests) and a minimal CLI utility.

I humbly remind you that the pledgie is still open and still far from the target. If you like what I'm doing, please consider contributing a few bucks!

Click here to lend your support to: Funding development of UglifyJS 2.0 and make a donation at www.pledgie.com !

UPDATE (Sep 07): Thanks to significant contributions from the jQuery Foundation and the Dojo Foundation, and from many individuals who heard the buzz, we are a lot closer to the target! Thank you people!

Update (Sep 11): Telerik matched the donations from jQuery and Dojo, providing more than enough to complete the campaign target! Thank you guys! I've been working on it, I'll post some updates and new code soon! What follows is old news.

Next, some information about the current state of affairs.

[ read more... ]


Aug
22
2012

JavaScript minification — is it worth it?

UPDATE: what I wrote here is very childish thinking. Please ignore it. Every Byte Matters™.

I've been secretly working on UglifyJS v2. I'll release some nice code, very soonish. Here's just a thought I've been pondering.

Some quick test against my 650K DynarchLIB reveals an interesting observation. It seems that the lion's share in compression is brought by name mangling (i.e. converting local names to single characters) and whitespace removal. Everything else is, well, quite insignificant.

“Compression”, meaning those complicated AST transformations that lead to replacing if with the ternary operator, or to block brackets removal, saves about 5.5K on my file. That's not bad, but after gzip the net savings go down to 500 bytes.

For those 5.5K 500 bytes, UglifyJS spends 2 long seconds only on squeezing the code (all the other steps combined, like parsing, mangling, lifting variables and generating code, take way less than 2 seconds).

Is it worth it? I'm not so sure... In any case, I do plan to make v2 compression as good as v1's, but I couldn't help noticing this fact: if I had 100,000 unique visitors each day (and that's quite an astronomical figure to me), and if that script would be served to each of them (no cache involved), then 500 bytes less in the file would save me about 1.5G/month, which is about 0.015% of my monthly bandwidth (which I pay for anyway). I'm not very sure it's worth the trouble.

Update: better than “is it worth it?” perhaps the question should be “how could I make it better?” Every byte matters after all, but it seems to me that working 2 seconds for a net saving of 500 bytes, which is 0.68% of the gzipped file size, means we're doing something wrong...


« Before 22 Aug 2012
Fork me on Github