Wednesday, October 10th, 2007

MileScript: A new language that compiles to JavaScript

Category: JavaScript, Library

>Joshua Harrison has released MileScript which in his words:

…. is an object-oriented, strongly-typed high-level language which we developed from scratch, while following the models of Java and C#. Milescript allows developers to code Milescript source files and packages in a structured manner, and then generate those projects as applications or as libraries. The generated ECMAScript is 2.6.2 compatible, and runs in Firefox, Mozilla, Safari, Opera and IE. Although we still have a long way to go in fleshing out our libraries, we believe the compiler and language are at a state where the general community could gain significant value from them. The project is still under heavy development, and we are all very involved. Updates should come often. We are very excited about the possibilities; for instance porting the Dojo toolkit to our language would make it more robust, easier to distribute, and easier to work on for the majority of coders.

We really want to start hearing feedback so that we can grow this into a truly open-source, community driven project

It does look very much like Java with access to JavaScript objects like ‘window’:

  1. package com.milescript.test;
  2.  
  3. import com.milescript.dom.*;
  4.  
  5. public abstract class Parent {
  6.   protected Array<string> messages = new Array</string><string>();
  7.  
  8.   protected void assembleMessage(){
  9.     messages.push("Hello ");
  10.   }
  11.  
  12.   protected void alertMessage(){
  13.     assembleMessage();
  14.     String finalMessage = "";
  15.     for(String message in messages)
  16.       finalMessage += message;
  17.     window.alert(finalMessage);
  18. }

The demo brings back memories of sitting in school with a BBC Micro, as it is the old faithful worm game.

MileScript Demo

Related Content:

28 Comments »

Comments feed TrackBack URI

while JavaScript is a versatile language but if it comes to large projects it’s pain in the arse.
Another quite similar interesting project:
http://haxe.org/intro

Comment by Jan Mentzel — October 10, 2007

Looks good to me. Wonder how they compile protected, private and abstracts, though.

Comment by Thorsten — October 10, 2007

I think the Ext library should be ported to this project too. I just thought for some days to write an application to make Ext developement esier.

Comment by carstep — October 10, 2007

Just wonder: why another language?

@Thorsten
GWT and Java2Script already proved that compiling Java to JavaScript is feasible. So supporting protected, private and abstract should be just a small case.
protected, private and abstract are concepts at language level, while compiler treats them at compiler level: all compiled variables are visible.

Comment by Zhou Renjian — October 10, 2007

Interesting to see how many hoops people are willing to jump through, to get out of learning af very simple language and mindset.

I wonder how they plan to do any kind of useful automation against code produced this way … which pretty much forces people to either skip testing or learn both javascript and how Milescript get’s translated into javascript.

Somehow this reminds me of ASP.NET … where people spend countless hours trying to understand stuff like Viewstate … instead of just learning basic web development instead.

Comment by Morgan Roderick — October 10, 2007

Oh god no, please no!

*slashing wrists*

Comment by scriptkiddie — October 10, 2007

You lost me at “with access to JavaScript objects like ‘window’”

‘window’ isn’t part of javascript, it’s part of the BOM.

Comment by Steve Brewer — October 10, 2007

carstep – I have already written a library that integrates Ext with GWT. So you can write all your client side code in Java and have the GWT compiler produce the corresponding javascript.

Here’s the project page : http://code.google.com/p/gwt-ext/
And there’s the Showcase demo where you can see the Java code for each example under the “Source” tab:

http://gwt-ext.googlecode.com/svn/trunk/site/samples/Showcase/www/com.gwtext.sample.showcase.Showcase/Showcase.html

There’s also a project Script# that compiles C sharp code to Javascript.

GWT has put in a lot of work into optimizing the generated js output like dead code elimination and shorter variable names. It also has a very cool bootstrap mechanism such that the app is loaded from the server only if it code has changed on the server – and it does this transparently via a clever code – md5 file name generation.

Comment by Sanjiv Jivan — October 10, 2007

I second Morgan Roderick, this a waste of time.
People should first learn what the web is, then learn Javascript if they want to add a bit of behaviour on top of their HTML and get done with it.

“[...] porting the Dojo toolkit to our language would make it more robust, easier to distribute, and easier to work on for the majority of coders.”

I call BS. It would make it probably less optimised, and certainly less accessible to anyone who actually codes in the targeted language (yes, the whole planet doesn’t yet use your stuff).

Writing a compiler for a new high-level language for the sake of having it compile to another high-level language is a (good, maybe) programming exercise.
There is nothing productive about this sort of stuff.

Comment by Cyril Doussin — October 10, 2007

But the best thing ok Javascript are the language itself why work in another language that results into Javascript?

Comment by elalecs — October 10, 2007

I think I’ll go and write a C# to MileScript converter. And a VM for running MileScript, implemented in JavaScript so it can run in the browser!
/sarcasm

Comment by mike — October 10, 2007

It makes sense to write the server-side and client-side in the same language; however, I think folks writing GWT and similar tools are solving the problem backwards when they write the client-side in the language of the server-side. JavaScript on the server-side please.

Comment by Peter Michaux — October 10, 2007

DISCLAIMER: I am a developer of Milescript, therefore extremely biased :)

I think its important to note that if you already know JavaScript, you are intimately familiar with the object model in Milescript (because its the HTML DOM that ships with your browser!). We were trying to address, in Milescript, features that are readily available in Java and other high-level languages, as well as JavaScript2 (in several years) such as type checking and OO.

The primary motivator for creating Milescript was the problems we had developing a very large JavaScript application, in excess of 30,000 lines. The project had become unwieldy and difficult to maintain. Milescript helped us turn this project into a robust and maintainable client-side application.

Simply put, Milescript is like JavaScript2 with a compiler and distributable libraries, and if other people get the same benefit we did, that’s wonderful, and if not, that’s cool too! Use what you’re comfortable with…

Comment by Ray — October 10, 2007

Crap, you mean someone beat me to this? I was going to do the same thing, except I was going to name my project “WTFWhyWouldYouDoThis…. Script” Oh well, back to the drawing board….

Comment by Sean — October 10, 2007

i wonder what the generated javascript code looks like. can the compiler produce optimized javascript code, or could you write a programm with only using javascript in half of the code lines?

will the generated code work on all major browsers? what happens, if a new browser-version breaks something – thats a common problem with internet explorer for example and there i am at the next question:

i think debugging will be a very hard task. there are always possibilities of failure – how can you map the failure from javascript to your milescript code?

i don’t think, that client and server application code has to be in the same language – if you still want it, you should write your server application in javascript, too. but for example: a lot of people write there web app in php – but i don’t know much people, which use php also for the tools (they use shell-script, make or perl instead).

what i would like to say is: you should always use the language, that is the best solution for it’s target. if milescript is implemented in browsers in 10 years, i would say – ok, why not use milescript. but till than, i only see possible problems …

Comment by Harald — October 10, 2007

i’ve forgotten something – if it comes to code maintenance problems because of a very large codebase:

i split my javascript project in single-files as i would do in other programming language and write script, which concatenates all single files to one big file when accessed through the webbrowser.

in the development environments all source documentation will be preserved, so it’s very easy to locate a problem in your source files.

Comment by Harald — October 10, 2007

@Harald
When generating in “Debug” mode, the javascript produced by the compiler contains comments that link each line of generated code to the line of the Milescript class that generated it. You can view this in the “code view” part of the demo page. We are currently working on how to best optimize the generated code.

Comment by Joshua Harrison — October 10, 2007

@Harald
I wrote a lot of the application Ray mentioned, the Javascript application with 30,000 lines of code. We put each Javascript “class” in it’s own file, as you mentioned. The problem came from small errors in the code which would have been caught by a compiler. For example, misspelling a variable name causes Javascript to create the variable for you, which doesn’t throw an error in the browser. However, it caused a runtime issue which took several hours to track down. After finding out it was a misspelled variable name, we decided that our application was not maintainable in Javascript format. In Milescript, a misspelled variable name immediately throws a compile time error, saving time in the development process. For runtime debugging, we use Venkman, and each line of generated code is linked to the Milescript class via an end-line comment. Javascript is great for doing quick and dirty programming, but it is lacking when it comes to developing large applications. From my experience, debugging Milescript has been much easier than debugging Javascript, and our development time has been cut by far more than half.

Comment by Greg Youree — October 10, 2007

@Harald
Oops. Forgot to mention the Logging feature of Milescript. The LibDom package includes a ConsoleLogger, which is infinitely valuable for debugging, but any logger can be implemented. For example, you could log to a remote server rather than the console if you like. This can be helpful for keeping track of log events in the production environment.

Comment by Greg Youree — October 10, 2007

bring me the same horror of .NET programming. You gain control while trying to squeeze out as much project as possible, but you loose control when you need to optimize.

Comment by Simon Jia — October 10, 2007

What a waste of effort. Javascript is an excellent language, especially considering the updates that are coming. Why anyone would want to compile something inferior to Javascript is beyond me.

Type checking is good, but it is overrated. When I was programming in Python I did not experience many bugs related to using wrong types.

The biggest issue for me was that interfaces were not naturally self-documenting. In a statically typed languages types tell you what to expect in an argument to a function. So the documenting nature of types was more useful to me than the actual compiler enforced type checking.

Other than this self-documenting nature types are overrated imo. In other words, the “safety” aspect of types is not what makes types useful. I found that generally my Python programs were as safe as my Java programs.

Compiling one high level language into another high level language is a waste of effort.

Comment by Leo Lipelis — October 10, 2007

“For example, misspelling a variable name causes Javascript to create the variable for you, which doesn’t throw an error in the browser.”

Wouldn’t it be more prudent to write a static Javascript source code checker for this purpose? Simply make sure that all the variables inside a function are either parameters or declared explicitly by the var construct. That will catch the mindless “oops” type of misspelling for you.

Compiling one high level language to another is overkill.

It’s far better to contribute to making Javascript a first class programming environment than to make system that simply sweep under the rug various Javascript shortcomings (as you perceive them).

Comment by Leo Lipelis — October 10, 2007

thanks for the answers to my questions – that makes a lot much clearer. however, if it comes to misspelling variable names: if you test in firefox and configurate him to strict-mode you will discover most of this problems, because the misspelled variable will be catched as unitialized variable in the javascript console.

there are a lot of very good debugging tools for javascript, too – firebug or if it get’s more complex even venkman is still a very good solution for debugging javascript code. sometimes it’s still hard though …

Comment by Harald — October 10, 2007

I would also like to add another reason why I don’t like the idea of compiling Java code to javascript. There are great javascript libraries out there (ExtJS, YUI, JQuery..etc) and it will take substantial effort to integrate those libraries into the Java-to-Javascript compilers (like the GWT-ExtJS library that Sanjiv created). This seems like duplication of efforts to me, and the Java-to-Javascript compilers will be always playing catch up with the javascript libraries every time a new library version is released.

Comment by Bashar Abdul — October 10, 2007

While Javascript has it’s issues I really don’t see that it’s that hard to work with. I work with Javascript of similar size to that and actual maintenance of that Javascript has not been a big problem. The main issues we have are related to browser problems more than Javascript itself.

Comment by Glen — October 10, 2007

nice project,but i don`t want another Java/C# clone to convert to JavaScript.
for me JavaScript is way better than C#/Java,static-typing language are just pain.

if any language compiler should be made it should be Ruby/Python to JavaScript.
for one last time,JavaScript is a good language we don`t need a compiler.

Comment by Uriel Katz — October 10, 2007

This discussion actually reminds me of an article a couple of days ago about Sun Labs Kernel, except that its the other way around: http://ajaxian.com/archives/sun-labs-lively-kernel-morphic-ui-for-the-web-self-and-squeak

I don’t understand why people think that learning and using more than one technology/language is a bad thing. Actually using one language for everything is a step backward not forward. There is no such thing as a swiss army knife that is perfectly capable of doing everything and programmers must understand that in order to be a good programmer you must be willing to learn and work with more than one language/technology. I would much rather use multiple technologies where each technology is focused on doing one thing the right way rather than use one technology that tries to do everything and ends up being mediocre at most things. A Java to javascript compiler is just that, it gives you the false impression that you can do everything with Java, even client side coding and CSS positioning.

Comment by Bashar — October 11, 2007

I think this is a great effort. We don’t move forward technologically by just declaring JavaScript good enough. Programming in the large is a weakness of JavaScript, and this has been one of the major impetuses of ES4. It should be noted that there are various different levels of compilation. GWT does pretty dramatic transformation, however there are much smaller transformations that I think still preserve much of the developers ability to interact directly with the browser. Continuation transformations are one example, and even JS minifiers do transformations on code. I think these can add a lot of value to JavaScript without trying to do major conceptual transformation. Some of milescript’s features have value, and actually I think are better performed in development (like static type analysis) than in the browser. However, I would prefer that MileScript implement ES4, rather than a new creation though. I would love to see an ES4 compiler to ES3. Good effort though.

Comment by Kris Zyp — October 11, 2007

Leave a comment

You must be logged in to post a comment.