... 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 had to do this. :-)

I mean, I don't like any existing template systems.

I don't like mine either.  But still I think it's better than others.  I was looking at Tenjin and they have something like this:

<?js for (var i = 0; i < list.length; ++i) { ?>
<?js     var el = list[i] ?>
     <li>#{el}</li>
<?js } ?>

Functional, maybe, but downright ugly.  In YAJET, we can write it like this:

$(FOREACH (el => list)  <li>$el</li>  $)

which I think is a lot better.  YAJET compiles the templates into JavaScript code, so for your template you get a function that runs blazing fast.  It tries hard to do this The Right Way, so you don't have weird variable name clashes, or side effects.

Give it a try.  There's a jQuery plugin too, for those who can't live without jQuery. :-)

Here is a JavaScript implementation (using the <canvas> element) of an idea that my father discovered like 20 years ago. To the best of our knowledge, the idea wasn't known at the time. We recently found a similar image in Knuth's “The Art of Programming”, vol. 4, which according to Wikipedia was not published until 2005. Hence, in lack of a better name, I'm going to call this “the Bazon fractal”.

The idea is simple. To draw the pixel (x, y) of the image, you compute the value of some function and select a color based on that value. Certain functions lead to impressive results. But you need to be either too lucky, or a truly passionated mathematician, to discover a function that returns something meaningful.

[ read more... ]

Want to know who that is?  It's me. ;-)

I submitted my Ymacs project to Ohloh (Ymacs project page at Ohloh).  They have a nice feature that gives some statistics, based on the source code (they can understand some source control repositories, including Mercurial, which is what I use).  The Ymacs statistics say the following (the whole source taken into consideration):

• estimated effort: 4 person-years
• project cost: $210,926 (for a $55000/year salary)

Counting only the JavaScript files, which is the main programming language, we have:

• estimated effort: 1 person-years
• project cost: $61,739 (same $55000/year salary)

The fact is: I did this myself in a bit more than 2 months (work on the website and infrastructure included).

It's true that Ymacs includes a build of DynarchLIB in it's source repository, and DynarchLIB started in 2005 (I didn't work on it full-time, though, far from it).  However, Ohloh counts DynarchLIB as a single line of code, because the code is minified, so it probably doesn't add much in the 1 person-years estimation.

Once I put up a public code repository for DynarchLIB, it will be interesting to see how much Ohloh underestimates me. :-)

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. ;-)

As you probably know already, Firefox's browsers' regexp engines don't "know" Unicode.  The \w specifier seems to be equivalent to [a-zA-Z0-9_], which is far from sufficient to match word characters.  After some googling I found XRegExp, a pretty cool library that extends the basic JS RegExp object.  It adds some useful magic, and—surprise—unicode support is available as a plugin.

Nice going, but since I need this in a very time intensive operation, it was rather slow.  (As you will see below, it's quite possible that XRegExp isn't to blame for the slowness).

So I thought I'd copy the bits that I need from the source code, and use them with standard JS regexps, rather than XRegExp.  If you look at the source code, it has a huge line for a "L" property (it's lowercase in the code) in a hash which defines the Unicode ranges for characters that are letters.  Later in the code, with a for loop it constructs the actual regexp.

[ read more... ]

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 wrote about this topic before.  My small hackish mode attracted a few people for its good indentation, but it still had some issues that were hard to track down.  In short, it's quite impossible to use c-mode's indentation.

In the last few days I played with Steve Yegge's excellent js2-mode and I'll write about my setup here.  js2-mode is different from most other programming modes that you can find in Emacs (and in any other editor for that matter), because it employs a full, solid parser of the language.  Instead of guessing the syntax with buggy regexps, js2-mode actually parses your code into an abstract syntax tree (AST) and can therefore provide complex information about it, not to mention very good syntax highlighting.  For example, js2-mode can and does warn you about syntax errors such as misplaced parens, or missing semicolon, or trailing comma.  Or about undeclared variables — a ”must have” with JavaScript, since it's usually the source of many subtle bugs.

I noticed this excellent mode about an year ago, but indentation was simply unbearable so this is why I didn't use it.  But now I decided to give it a second try.  Indentation can be fixed.

[ read full story... ]

This is a minor mode that I wrote on top of js2-mode which automatically highlights all occurrences of the variable under the cursor within its defining scope.  I once saw this at a friend who was using Eclipse, and I thought it's pretty cool.  With the powerful API that js2-mode exposes, it was pretty easy to write it, even despite my limited (E)Lisp experience.

[ read more... ]