... for NodeJS.

With minimal changes it should work on any JavaScript engine, but currently NodeJS is the main development platform.

It implements a JavaScript parser which produces a clean abstract syntax tree from JS code (this part is ported from parse-js, a great JS parser for Common Lisp).  Then it contains a few functions that manipulate the AST to compress variable names to single characters, and provide various other compression techniques such as:

• join consecutive var declarations:

  var a = 10; var b = 20;  ==>  var a = 10, b = 20;

• remove block brackets {} where possible

• transform foo["bar"] into foo.bar

• various optimizations for IF statements:

• remove "else" where possible (when the last statement in an IF block is "return", "throw", "break" or "continue")

• transform simple IF-s like:

  if (foo) bar(); else baz();  ==>  foo?bar():baz();
  if (!foo) bar(); else baz();  ==>  foo?baz():bar();
  if (foo) bar();  ==>  foo&&bar();
  if (!foo) bar();  ==>  foo||bar();

and some others.

It compresses better than the YUI compressor, and safer than Google Closure.  And it's a lot faster than any of these.

Get the code here: http://github.com/mishoo/UglifyJS and spread the word! :-)

I'm playing with Node.js lately.  Node is an asynchronous environment that allow you to use JavaScript on the server.  The asynchronous nature makes it a bit different from other programming environments, and I'll describe in this article how I'm using some obvious features of the language (closures and exceptions) to accomplish something not-quite-trivial.  In short, I've written a Redis client library and a WebSocket library (and yes, I know these things exist already, but I suffer from the NIH syndrome).

JavaScript has exceptions, and JavaScript has closures—combining them you can get “restarts”.  It's not the same as Lisp's condition/restarts system, in that once it throws an exception a function can not return anymore.

In order to make use of this technique you have to write your code in “continuation-passing style” and avoid iterative loops.  While this might seem too complicated, it's easier and more natural than it sounds (and it's almost a requirement in environments such as NodeJS).

[ read more... ]

I just released a new project that I've been working on for about a month: Ymacs is an AJAX text editor, suitable for editing source code (currently there is support for JavaScript and XML, but more modes could be easily implemented).

Ymacs is a DynarchLIB widget, which makes it easily embeddable into any DynarchLIB application.  This doesn't sound impressive, isn't it, but here's the real good news: I've decided to open source DynarchLIB and release it under a BSD-style license.  Some folks might believe this project is already dead, but this isn't so; it is true that there was no new release in almost two years, but the thing kept being improved and there are people using it in successful commercial applications.

Well..  This should happen any minute, but I'm running out of time, as usual.  So it could take a few more days to push a new DL release.  In the mean time, go check Ymacs, it's pretty cool.  It has Emacs key bindings too. ;-)

I'm pretty sure you know the Foo.prototype.bar = function(){ ... } syntax for declaring object methods, and also the Bar.prototype = new Foo stuff for setting up inheritance.  You also probably know that Prototype.js and jQuery have devised new, shorter/cleaner ways to declare objects.

In the article below I'm presenting my own, which I developed around 2005 and kept refining it.  The described "syntax" is used in DynarchLIB (although not in the released version, which still uses the old eval()-based hacks).

[ Read full article ]

I found an interesting discussion about closures. I find this quote particularly true (and amusing):

There has been a great deal of interest in closures lately, driven in great part by the fact that there is talk of adding some form of anonymous functions to the Java. Most of the time, people talk about “adding closures” to Java, and that prompts a flurry of questions of the form “what is a closure and why should I care?”

Yes, why would they care? As someone put it, if you always programmed in Basic, you think you don't need recursion. You can't comprehend a complex language feature—such as recursion—unless you actually try to make some sense of it. Yes, no matter how many computer science courses you'd take, you can't do real programming unless, well, you do real programming. In other words, your teacher might have told you what recursion means, but unless you actually use it, you'll never know what is it good for.

Consequently, I think there are 2 types of programmers.

1. Some would spend a lot of their free time trying to understand and make use of some techniques that might—or might not, but usually will—serve them for real-world problems.

2. The other camp is very boring: those are the people that are payed for some job and only do what their boss asks.

Now, the boss will never ask you to use closures (or any other language feature for that matter). He'll just tell you “do this” ASAP, and you have to figure out how to finish it as soon as possible. Well, using closures, ASAP can mean a lot sooner than without them, no matter what language are you programming in (assuming of course that it supports this 30-years-old concept; some new and much hyped languages still don't.).

I have former colleagues that have completed their B.S. in computer science (which I still didn't). One of the courses you do in the college is an AI course which, of course, uses Lisp as the supporting language. Well, the horror is that none of them understands what's a closure, and asks me every time I mention the word “OK, Java/C# might not have that, but why would I need it anyway?”.

So after preaching functional programming for some time, and after I saw my fellows here ignore me, I've come to the conclusion that it's better for them not to understand it. A boss is a boss, and he'll favor someone who has a B.S. (which I don't). So I at least want to keep the technical advantage. :-p

So, ya Java folks, don't even think about closures. You don't need them. Just focus on writing specs and UML-s and Factories and Managers and Listeners and Executors.