Project goals?

[sledorze]

I wonder what are the project goals?
Is there any long term plans?
Have the past tests showed some intrinsic limits to its support?
Glad to know more about it.

Stephane

[Alvaro Carrasco]

Hi Stephane,

Some goals that I have in mind (of course these might change as we get some feedback from users):

The short term goals:

1. Support for all the runtime js constructs necessary to write javascript code using the bare minimum scala subset.
   
2. Full compatibility with the closure library and js code that uses the same conventions, meaning you can mix s2js-scala code with regular closure-javascript code.
3. Externs for all of the closure-library APIs
   

Medium term goals:

1. Expand the subset-of-scala to most-of-scala.
2. Create a sister library that provides a more idiomatic API to the closure library that feels more like scala style.

Long term goals (would love to get to these at some point):

1. Eclipse plugin
2. Integration with some frameworks like Play! and/or Lift.

I haven't found any intrinsic limits yet, so I feel pretty good about its potential.

I've taken a break from it for the past couple of weeks, but I'll be spending some more quality time with it again next week.

Alvaro

[Alvaro Carrasco]

I should say that on the short term goals I would characterize the progress so far as:

1: 85% - I'm actually using it for a project already
2: 85% - Occasionally I still find a few js constructs that are not implemented yet
3: 20% - I have externs for the basic stuff (most of goog.dom, goog.events, some of goog.ui, etc)

Alvaro

[Erick Fleming]

Ok, It took me a lot longer to figure things out then I thought.  Scala's compiler API is not for the faint hearted (nice work figuring this stuff out Alvaro).

I'm on my second attempt at refactoring the S2JS code base (for leaning purposes), becuase my first attempt was a disaster.  I was just trying to walk through Alvaro's design, but things just got more complex than I was expecting (at least for my little brain).

Anyhow, after a break and having gained some knowledge of the API, I decided to tackle the problem from a different perspective.  It's not in complete working order, nor do I have even close to the original feature set, but I think I've got a decent handle on how things work now.  I've uploaded my attempt to the develop branch of my fork.

As a result of my experiment, I've ended up with some questions and thoughts.

First, why not use Scala's native trees as the bases for printing?  I got really confused in the multiple transformations when all I really care about is writing javascript to a file.  Scala's trees seem to be fairly easy to traverse, so I couldn't find any value in the additional JsTree layer.  Please let me know if I'm missing something.

Second, is it a design goal to produce code that can be used in Closure specific projects?  Personally, I don't think the Closure library will ever grow to mass adoption and many of it's components are poorly desinged and inconsistent accross the board.  Having said that, I do like it best as a core library but producing idiomatic javascript + closure's dependency system with a compatibility to closure's library, might be a better goal.

AFAIK The Closure compiler does not do any optimizations for type information and the JsDoc system are clumbsy at best, so it would be nice to ignore a lot if not most of the type annotations and other such things.  I do think producing JavaScript that can be optimized by the Closure compiler should be a main goal, but simply using the peuso-classical inheritence is will give us the most benefit.

Just some of my thoughts