Compiling Down to JavaScript 1.5

Published August 5, 2007 in JavaScript, Compilation

New period of JavaScript instability.

Firefox 2 implements JavaScript 1.7.

Firefox 3 with JavaScript 1.8 is soon.

JavaScript 2.0 in Firefox by end of 2008?

Internet Explorer 7 has JavaScript 1.5.

No hint that Internet Explorer 8 will be moving forward.

Microsoft has interest in slowing down JavaScript progression.

Man! Does that Silverlight site sure load slowly.

More people browse the w3schools with Internet Explorer 5 than Safari.

The w3schools is biased towards tech readers!

People don't upgrade their browsers...they buy new computers.

Today's computers will satisfy their owners for many years to come.

We are stuck serving JavaScript 1.5 or at least JavaScript <2 for 10 years.

#define JavaScript JavaScript 1.5
#define sucks is less than optimal

JavaScript is the most popular programming language in the world.

Programmers don't choose JavaScript.

No viable runtime outside the browser to choose.

JavaScript is only used where we cannot choose.

Why?

Prototype-based inhertance sucks.

JavaScript uses prototype-based inheritance.

JavaScript sucks.

It's transitivity.

Blasphemy!

The prototype-based inheritance experiment failed.

People don't get it.

Witness the popularity of Self and NewtonScript

Try two levels of inheritance in JavaScript.

JavaScript built-in OOP sucks.

Can't change it.

Can wrap it.

People work around JavaScript OOP all the time.

Prototype-based inheritance can do some class-ish things.

But can't wrap it and make it do everything.

Using the dot operator binds you to the built-in OOP.

Don't use dot and you can roll your own OOP.

Any OOP pattern is possible.

It's just really ugly

and slower than the built-in OOP

but if the built-in OOP can't do something....

Macros would clean the mess.

Learning about Lisp is a blessing.

And a curse.

Maybe we can rely on macros in the browser by 2020.

How patent are you?

JavaScript is not an acceptable JavaScript.

But even Lisp is Not an Acceptable Lisp

JavaScript is still pretty good

  • higher-order functions
  • lexical closures
  • garbage collection
  • global variables
  • familiar syntax

Better than most.

I like JavaScript.

All this fuss over just the built-in OOP?

No (but it's a big deal.)

  • E4X
  • iterators
  • generators
  • array comprehensions
  • destructuring assignments
  • block scope
  • macros

All the features that make code dense.

All the feature we won't have until JavaScript is succeeded by new versions.

JavaScript files were written as they were served.

Browser applications continue to get heavier.

Working on huge source code files sucks.

Serving many small files is slow.

Identifying dependencies between development files necessary.

Don't want to serve all JavaScript in one file for first page.

JavaScript wasn't designed for big programs.

Handcuffed.

Want a better development language and tools now.

source code → manglers → served code

Freedom.

Performance manglers

Lanaguage manglers

If the mangler is complex enough it is usually called a compiler.

JavaScript as a compilation target language.

Others have noted this trend.

Can compile down to JavaScript until a subsequent version can do something really new (eg. concurrency)

Takes very liberated thinking to embrace haXe and Links approach in general.

OpenLaszlo is the opposite direction: JavaScript compiled into Flash.

JSON and template compilation are like the haXe/Links approach.

Develop all in the language you know best.

DRY. Share source code on server and client.

Please:

source code → macro expansion → JS2.0 to JS1.8 → JS1.8 to JS1.7 → JS1.7 to JS1.6 → JS1.6 to JS1.5 → obfuscation → minification → file concatenation → gzip compression → served code

Assembly programmers argued against this logic.

They lost.

A long time ago.

Developing solutions was less costly than the status quo.

  1. edit
  2. mangle
  3. test

I better not have run step 2 manually.

Not even type make.

People only adopt transparent tools.

That someone else wrote.

Debugging runtime errors in mangled code sucks.

It still might be a good compromise.

Development must be easy.

Deployment must be easy.

There's a difference.

Need a framework to do this.

Written in JavaScript.

On the server.

"No!"

"You've had development tools for years, now why not me?"

Update November 15, 2008 Interesting to note the negative comments about the prospects of debugging generated JavaScript. I agree. No thanks!

Comments

Have something to write? Comment on this article.

Joe Winter August 7, 2007

"OpenLaszlo is the opposite direction: JavaScript compiled into Flash."

Well, it also does compilation to HTML/JS: http://www.openlaszlo.org/advancedajax

José Jeria August 15, 2007

IE 7 support JScript 5.7, not JavaScript 1.5.

JScript 5.7 lacks watch/unwatch, setters and getters etc

Breton September 18, 2007

I like prototypal inheritence, I find it to be incredibly powerful. It is fallacy ad populum to say that it failed based on the popularity of self and newtonscript. Look at the popularity of javascript and actionscript as counter example. Yes, you do note that people don't choose javascript- The same forces work on all other languages, they are not popular because they are good, powerful, useful, or logically sound. Social and economic forces control popularity, not the inherent quality of an idea.

It is my unpopular opinion that oop is a flawed meme to begin with, (particularly classical) but that's the subject for another post.

Chris Wilson has pledged to keep pace in IE8 with at least the speed of Javascript in Mozilla, if not the features, so compiling down may be an even more attractive option in the future. (if mozilla's screaming monkey fails anyway)

NBA September 21, 2007

I Think ;

IE 7 support JScript 5.7, not JavaScript 1.5.

JScript 5.7 lacks watch/unwatch, setters and getters etc

Pete Duncanson July 30, 2008

I like your mangler idea, we use something similar here. We have a big site thats mostly written in Classic ASP using JScript. It's a lot of fun to work with and we get to re-use some of our code both server and client side.

When developing we want to view our code easily and get to the correct line number. We luckily don't have to compress our server-side code but our client side code does get compressed but only on live. Heres how we sort of do it:

You can add client-side code using a few helper functions:

  • addJSFile - accepts a filename and group name
  • addScriptBlock - takes a function and renders out your JS
  • addDomReadyScriptBlock - takes a function you want to run ondomready

When you hit any of our pages our BasePage renders out all the addJSFile grouped together by group name (sitewide, search_forms, homepage, etc.) in the footer of the page (for download speed). If on live it concats them all together, seperated by ~, in one long filename, dev just writes them out in separate script tags. On live we have a 404 handler which looks for missing js files, splits on the ~ and then sucks the real JS files in, JSMin's (ported to JS Serverside ASP) on the fly (caching them in memory for speed), concats them all together then returns them to the user. We have on average 24 JS files per page when on Dev, on live thats squished down to 4 lots of merged files.

Then the addJSBlocks are rendered followed by the addDomReady blocks which each get wrapped in the required domready code.

This makes for easy debugging when developing locally (where there is no problem with download speeds) but on live we get all that hard work done for us automatically. The site has a BuildNumber which gets appended to the end of the concatenated JS filenames so when we do a new release, we up the BuldNumber and everyone is forced to get the latest compressed file.

This works a treat and is all automatic and make the development cycle so much easier, allowing you to not worry about it and to just code. We have a similar thing with our CSS files too.

Have something to write? Comment on this article.