http://osteele.com/sources/javascript/functional/

Implicit parameters, implicit returns, and a lots of handy functions taking advantage of short lambdas.

It doesn’t do any DOM-y stuff by itself, but I’ve been using it along with Prototype for some pretty happy code.

They address size-on-the wire. They don’t address human factors.

Trav:

I *wrote* one of those minifiers. You don’t need to lecture me on the topic of what is and isn’t effective in terms of reducing byte count

As for readability, it’s a human-factors argument, and I’m arguing that seeing the word “function” all over the place really isn’t as clear as you think it is. Java tends to be difficult to comprehend for similar reasons…stuff gets munged into structures that don’t fit the intent as a side-effect of insufficient semantics married to bad syntax. JS is better on the functional side of things (the semantics are fine), but the sytnax is lousy. I’ll absolutely agree that a non-lame class composition system (traits, anyone?) would go a very long way to addressing some of the bigger issues in the language, but if the WG is going to chew of lambdas (and it looks like they are), we should propose something that doesn’t suck.

We can absolutely make both sides of the language easier to use at the same time. There’s no either/or here.

Regards

All languages have compilers to optimize their performance. Javascript has minifiers. I can have a large amount of human-readable source code while still sending a minimal amount of code to the browser. Please don’t make things more complicated than they should be.

I posted something not dissimilar to the ES lists some time ago, but it’s not clear to a native JS parser what the {| production should mean. As we were talking through it, Erik pointed out to me that the { ... } syntax (maddeningly) seems to be taken by a anonymous block syntax that many JS interpreters already support but which doesn’t actually *DO* anything. Grr.

As a result, both of those syntaxes would involve lots of look-ahead, which some implementers are (apparently) loathe to contemplate.

Regards

With that said, isnt there a javascript implementation of Ruby? HotRuby or something.

sed -E -e ‘s/\s*function\s*/#/g’ -e ‘s/\s*return\s*//’

…and got a savings of 4,220 bytes. So either the library grew an awful lot, or you were using a version that had been minified with something like packer using base62 encoding (which would have already removed nearly all uses of “function” and “return” at the cost of eval time). If the latter case is true, I don’t think that’s a very fair test, since the packed version is effectively doing (to a much greater extent!) what Alex is suggesting already.

This isn’t to say that I think the size over the wire is really the most important consideration here (gzipping both versions reduces the difference to 339 bytes). The function(){} form in JS is as annoying as the array() literal in PHP.

The minified version I used:
http://code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.3.2.min.js

Packer:
http://dean.edwards.name/packer/