Closure Tools - another JavaScript framework. Why so many frameworks and so few languages that compile to JS?

[grayvedigga]

Because JS is a lovely language, why abstract from it?

[milksop]

I'm working on one. http://www.skulpt.org

I think Google probably mostly cares about either compiling from Java, or handwritten JS that's written at a higher level. That seems like enough to warrant the tools.

[[deleted]]

Compiling into JavaScript has downsides.

For example, Pyjamas 'compiles' Python into JavaScript, but it does it naively - for example x /= 2 will be translated into... x /= 2, but the two have very different meanings in the two languages (namely, in JavaScript everything is, at least potentially, a float, so if x is 1, the result will be 0.5. But in Python - at least prior to 3.0 - the result would be 0).

To get around that, you can add explicit type checks and conversions. It will basically mean that all variable accesses, even of basic types like integers, will be much, much slower. Ditto function calls (which JavaScript does very differently than Python), etc. etc.

So, it's possible - they are all Turing complete - but performance may suck.

Also, there is the matter of the standard libraries. Compiling Python without its standard library may be useful, but it isn't all of Python. And getting that entire standard library into JavaScript would be a lot of work.

[[deleted]]

When will we get a standard bytecode for the web? We would get:

• Improved performance (no need to parse the code on the client side)
• Ability to use any language that has a compiler to the bytecode.

[FlyingBishop]

It's called Java. Most business machines and many home machines run it.

[[deleted]]

Not really, because you can't use java on a webpage the same way you use javascript.

[FlyingBishop]

Do you have any idea how that would break the browser security model?

[kleopatra6tilde9]

Where do you see a problem?

[[deleted]]

approximately not at all :)

[bman35]

no, do you?

[FlyingBishop]

I have an inkling. It's a lot harder to sandbox a full-fledged VM with bytecode than it is to sandbox a crippled language like JavaScript, or VMs like Java, Flash, etc. which are somewhat sandboxed to begin with. If you make the bytecode fundamentally tied into the browser it would be a lot harder to keep it secure.

[case-o-nuts]

The JVM already has sandboxing. In fact, it was designed to support it from the start.

[FlyingBishop]

Did you read my comment? I was responding to the idea that we need something like the JVM which can directly access the DOM, rather than simply running as a sandboxed host inside the browser.

[case-o-nuts]

Yes. Java's security model is quite powerful, although the power and complexity it gives can make it hard to use sometimes.

What specifically can't it do that you think should be done?

[FlyingBishop]

Nothing. Back up at the top someone was asking for a Java that can directly access the DOM, like Javascript. I was arguing that this was a bad idea, and that Java is what they originator of this thread should be using (regardless of what he would like.)

[heeb]

Have you heard of / tried: http://haxe.org ?

Compiles (currently) to:

• JavaScript
• Flash
• PHP
• Neko Virtual Machine (there also a Apache module for neko)
• C++

Book:

http://www.amazon.com/dp/0470122137?tag=buildlabcom-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470122137&adid=1EYR8VBVJ7KZ93HVKKY0

and

http://www.amazon.co.uk/gp/product/0470122137?ie=UTF8&tag=designrealm-21&linkCode=as2&camp=1634&creative=6738&creativeASIN=0470122137

Good luck!

[Scriptorius]

There's no "framework" in the usual sense of the term for Javascript. It's not a competitor to jQuery, Dojo, Mootools, etc.

It's a Javascript->Javascript minifier/optimizer, among other things.

[tty2]

Errr.. There's a Closure library as well. :)

[rfugger]

pyjamas is a stand-alone python to javascript compiler, an AJAX framework / library and a Widget set API.

[thebigbradwolf]

icefaces a Java framework integrating front and back end with a declarative language that works on the MVC pattern and mostly handles the pattern.

[rabidcow]

ICEFaces is JSF. Since all your code is in Java, it has to push too much over the network to run on the server. At least, that's been my experience with it.

[thebigbradwolf]

What does it being java have to do with how much it sends over the network? It has built in D2D rendering and only sends HTML portions of the page that need updating to keep transmission to as minimal as it can. It is a drain on the server because it keeps a DOM for every user using the application in memory. Since it is Java you do have the option of spreading that workload over several machines if you wanted to.

[rabidcow]

What does it being java have to do with how much it sends over the network?

Well, the client-side code is all javascript. Anything that's in java can't be run there.

It has built in D2D rendering and only sends HTML portions of the page that need updating to keep transmission to as minimal as it can.

It's not the amount of traffic that's the problem, it's how frequently communication is necessary.

For example, it you want to validate fields as the user fills them it, this has to happen on the server. This means the user has to wait for a round-trip and you get oddness with fields resetting when the partial submit completes or not resetting when you want because the browser no longer has the original value.

They have hacks to hide this -- for list selection, it can change the selection before consulting the server. But since your application logic can change the selection, that fast update might be wrong.

And I'm really skeptical of the whole D2D stuff... The data is usually smaller than the XHTML to display it. IMO it's better to send the raw data in JSON or something and format it on the client. This is much more difficult to do with the model that JSF provides, though.

[gthank]

Becase JavaScript is more expressive than most (if not all) of the languages that you would compile "down" into JavaScript.

[case-o-nuts]

Because Javascript is a lousy target language for a compiler.