8 ms·

JSweet: A transpiler from Java to TypeScript/JavaScript

54 points by renaudpawlak 11y ago

solomatov 11y ago
I don't get why this library is better than GWT.
- pipeep 11y ago
  There's a "Features and comparison" section on the linked page that addresses exactly this.
  - solomatov 11y ago
    They didn't persuade me in anything. Even worse, I don't understand some of them. What're well typed Java libraries. BTW, GWT, support in browser java debug via sourcemaps for a long time.
    - chii 11y ago
      Source maps doesn't compare to actual debugging that GWT used to be able to do (via a browser plugin). GWT died the day they decided that they will no longer support that.
      - cromwellian 11y ago
        It wasn't the GWT team that made this decision, it was the browser vendors. They killed the NPAPI. For good reason too, it was a major source of insecurity. PPAPI (NaCL) could not replace what was lost, because modeling JVM -> JSVM -> JVM calls requires synchronous re-entrant execution. BTW, you don't have to debug in Chrome. If you attach IntelliJ to the JSVM, you can debug right inside your IDE, stepping over breakpoints in Java, etc. SDBG for Eclipse does the same things. (https://www.youtube.com/watch?v=icJEa5lcJaQ https://www.youtube.com/watch?v=icJEa5lcJaQ)
        chii 11y ago
        As far as I can tell, you cannot eval arbitrary expressions. I used to use it like a REPL back then. That's what I would miss now with source map
        cromwellian 11y ago
        It might be possible to pull this off with the new compiler because it's draft mode is a true incremental unoptimized draft, and translating an expression to call the JS is a relatively straightforward ABI.
      - solomatov 11y ago
        Actually, source maps and browser based debugging are quite good. They aren't as good as Java debugger, but good enough. I am working on a large scale project which uses GWT, and we are absolutely ok with source map debugging.
- timv 11y ago
  The essential argument seems to be 2 things: 1. It can generate node.js compatible JavaScript so you can run Java code in node. I'm not sure how many people have felt the need to do that, but it's not something GWT can do. 2. It understands TypeScript, so it can make use of the work people have done to (essentially) create type annotations over various JavaScript libraries, and automatically (? or at least painlessly) build Java wrappers for them.
  - cromwellian 11y ago
    GWT in Node JS https://github.com/cretz/gwt-node https://github.com/cretz/gwt-node Generating Java interfaces from TypeScript is coming soon. We have done this in the past from WebIDL in the Elemental library provided by GWT. A new tool which can do it from WebIDL, Closure JsDoc, or Typescript (all three) is being developed.
    - renaudpawlak 11y ago
      Well it is already done in JSweet: checkout these APIs http://www.jsweet.org/candies-snapshots/ http://www.jsweet.org/candies-snapshots/ It is all compiled and deployed as Maven artifacts on our repo. And we even give access to all the JavaDocs if you follow the links to the end... checkout this Angular JavaDoc for instance: https://jsweet.org/apidocs/snapshots/org/jsweet/candies/angular/1.4.2-SNAPSHOT/ https://jsweet.org/apidocs/snapshots/org/jsweet/candies/angu... Let us know if you are interested in collaborating on this (never hurts asking).
  - solomatov 11y ago
    Why anybody wants to run node.js instead of Java. Java is much better suitable for the server side than node.
    - nothrabannosir 11y ago
      Nobody has commented yet. I can only guess this is because all agree: it goes without saying that this sweeping generalisation is patently untrue. Still, allow me to humor you and give just one (of the many) reason(s) why: async I/O. Yes, it's possible in Java. Yes, Java has futures that make it not just possible, but also a reality in this universe. Unfortunately, Java has made the inconvenient decision to retain backwards compatibility and keep all its synchronous I/O operations available. Perhaps not a complete folly. For all of the good that decision has brought, there is one downside: any code (any lib) can still lock up an entire OS thread. Result: all libs actually do this. No matter how Future-istic your codebase; use any lib and you're back to sync I/O.[1] This is absolutely killing for high concurrency, I/O bound servers, who now lock up not just an FD or two per conn, but also an entire OS thread. Javascript's threading model, on the other hand, is so shit that it came out the other side. By being inherently single threaded, all blocking I/O must be done through callbacks. Result: you can't block an OS level thread in javascript! So all libraries are inherently async (from the OS level). There are, of course, many more reasons why Java is not "much better suitable for the server side than node", but this is just one of them (libraries, existing knowledge in your org, community, ...). In reality, both have their uses. Node has proven itself by now. Disclaimer: I actually hate Javascript. And Java. Including Java 8 (for all the shit it, wisely, keeps around). [1] E.g. Amazon's official AWS SDK, which is sync IO. Want async IO for S3 (or anything there)? Write it yourself. Which you won't. Because there's already a lib. "But it's not async!" // TODO.
- renaudpawlak 11y ago
  It is different. The focus is different. JSweet focuses on TypeScript/JavaScript while GWT focuses on Java and see JavaScript as just an execution engine. Now GWT is obviously adding bridges to JavaScript, but still, it is not the main purpose. As I understand GWT, it still relies mostly on the GWT SDK and on Java semantics at runtime. If I may add some hopefully-constructive criticism, it feels that GWT (like some other well-known Google frameworks) is trying to address too many issues at the same time... But that's my own opinion and it does not mean I don't appreciate it.
ggonweb 11y ago
What are the good options to convert from Javascript to Java or to other high level languages?
- renaudpawlak 11y ago
  Transpiling from an untyped language to a typed one would give you horrid results in most cases. The practical way would be to use TypeScript to compile your program (JavaScript programs compile fine with TypeScript) and start to manually transform your JavaScript code to add objects and types. That said, that would be a really cool tool to have...
  - ggonweb 11y ago
    Has anybody tried Mozilla Rhino https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/JavaScript_Compiler https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rh...
warfangle 11y ago
Why ES5 instead of ES6/2015?
- renaudpawlak 11y ago
  I am not sure to what your question is referring to, but FYI, JSweet follows the same pace as TypeScript in terms of JavaScript generation. So it already supports most of ES6 AFAIK.
  - warfangle 11y ago
    None of the sample code exposes a) es6 module format b) amd module format c) commonjs module format.... It's all closure-based jquery plugin module format....... If you're gonna compile to "javascript" either target a version of node that's been released in the past year or target webassembly. Otherwise you're just another coffeescript.
- EvanPlaice 11y ago
  ES6 is only partially implemented in Node.js and requires transpilation to ES5 for client-side code. ES5 will be continue to be the target to until either/both platforms are feature-complete.
hardlystriclyjs 11y ago
possibly related: can some news hacker please create an internet crawling worm that untranspiles all the javascripts that it crawls and turns them into wars for everyone who wants to go the other way? I guess we also need mozilla developer network to create a browser plugin to run the war files for a given site, perhaps npm would host the wars, so we can use node to get the wars from npm for the plugin. thanks
cromwellian 11y ago
The GWT team has been working on a next-gen compiler that transpiles directly to readable, JsDoc typed ES6, designed for high levels of optimization by the Closure Compiler. Because of the new JsInterop system was designed for GWT 2.8, that is shared by both GWT and this new compiler, low impedance interop between Java and JS will be possible, as well as a tool that reads WebIDL and typescript libraries, and generates Java types. As an example if the level of low impedance between the languages, consider the @JsFunction annotation, @JsType(isNative = true) interface EventTarget { void addEventListener(String event, EventListener listener); } @JsFunction interface EventListener { void onEvent(Event event); } Using Java8, you can write code like: document.createElement("button").addEventListener("click", x -> Console.log("Hello World")); The difference between GWT running this, and the new compiler, is that the output of the new compiler is a standard ES6 module. The JSweet claims about GWT are out of date. First of all, in-browser Java debugging has been available for years. GWT was in fact, the very first transpiler to leverage Chrome source maps. I demoed this three years ago (https://www.youtube.com/watch?v=-xJl22Kvgjg https://www.youtube.com/watch?v=-xJl22Kvgjg) Secondly, GWT has a "reversible and compatible" JsInterop system that provides full two way low-impedance bidirectional interop, you can even do things like subclass JS objects from Java, or define "fields" via @JsProperty which invoke methods ala Object.defineProperty() Third, the JSweet stuff looks like it doesn't obey standard JLS semantics. Does it even compile the JRE or Guava? This is absolutely vital for code sharing between platforms (e.g. server, Android, j2objc). If you can't run standard JLS semantics, there's little point to writing the code in Java in the first place.
- amican 11y ago
  How can you tell it's disobeying standard JLS semantics?
  - cromwellian 11y ago
    I looked at the source. Doesn't seem to support class initialization properly. It models lambdas as just arrow functions, which won't work if you try to pass them as Objects to other Java functions (where is Object.getClass()/hashCode()/equals() ?) It doesn't handle runtime checks of Java interfaces at all, for example: interface Foo {} class FooImpl implements Foo {} Object o = new FooImpl(); if (o instanceof Foo) -> compile error The inability to even handle Java interfaces should be a clue right off the bat that this won't compile any non-trivial Java code base.
monocasa 11y ago
<soapbox>I really dislike the term 'transpile'. It's just a compiler. There's nothing really different in theory or implementation of a "source"->"source" vs a "source"->"binary" compiler. If I were to write a CPU in HDL that natively executed JavaScript, would this change from a 'transpiler' to a 'compiler'. The distinction made is simply what the end user is going to do with the result.</soapbox>
- cromwellian 11y ago
  I like the distinction in the sense that transpilers generally don't do optimization. GWT, Dart2JS, and Closure Compiler aren't transpilers in this sense. They are full blown optimizing compilers. Putting GWT or Closure in the same category as JSweet, TypeScript, or CoffeeScript obfuscates what these tools do.
  - monocasa 11y ago
    So if I run gcc with -O0, it's a transpiler? Remember that gcc outputs a human readable language that another program (the assembler) converts into machine code.
    - cromwellian 11y ago
      In one sense yes, but GCC the utility is an optimizing compiler. Would you call a sed script which converted Java to ES6 via regexes a compiler, even though not an ounce of compiler theory was used? I would define transpilers as a subset of compilers that are are only interested in high level language conversion. It's the difference between say, translating books between foreign languages, and being an editor who rewrites a book to be better.
      - monocasa 11y ago
        I mean... sed is Turing complete. Yeah, it's in the Turing tarpit, but if you were able to successfully translate Java to ES6 in a sed script, yes I would call that a compiler. In a lot of ways, much of compiler theory is concerned with the best way to write a compiler (for many different optimization functions of "best"), not the only ways to do so. Just being a crappy compiler doesn't make it any less of a compiler.
crudbug 11y ago
I would rather make TS to JVM & CLR Bytecode, to have a unified ecosystem from the opposite side.
TheAceOfHearts 11y ago
A few weeks back I was looking though some java code and I was hopeful I'd be able to transpile it in order to run it in the browser. I'm very experienced with JS and its ecosystem, and I figured that java was so popular that it should be straightforward to achieve this. But unfortunately, after 2 days of screwing around, I didn't have any luck. I'm not sure if it's due to my unfamiliarity with the java ecosystem or if the tooling or documentation were just poor. In any case, this tool looks friendlier than GWT, so perhaps I'll give it another try at some point.

54 points by renaudpawlak 11y ago

solomatov 11y ago

I don't get why this library is better than GWT.

pipeep 11y ago
There's a "Features and comparison" section on the linked page that addresses exactly this.
- solomatov 11y ago
  They didn't persuade me in anything. Even worse, I don't understand some of them. What're well typed Java libraries. BTW, GWT, support in browser java debug via sourcemaps for a long time.
  - chii 11y ago
    Source maps doesn't compare to actual debugging that GWT used to be able to do (via a browser plugin). GWT died the day they decided that they will no longer support that.
    - cromwellian 11y ago
      It wasn't the GWT team that made this decision, it was the browser vendors. They killed the NPAPI. For good reason too, it was a major source of insecurity. PPAPI (NaCL) could not replace what was lost, because modeling JVM -> JSVM -> JVM calls requires synchronous re-entrant execution. BTW, you don't have to debug in Chrome. If you attach IntelliJ to the JSVM, you can debug right inside your IDE, stepping over breakpoints in Java, etc. SDBG for Eclipse does the same things. (https://www.youtube.com/watch?v=icJEa5lcJaQ https://www.youtube.com/watch?v=icJEa5lcJaQ)
      - chii 11y ago
        As far as I can tell, you cannot eval arbitrary expressions. I used to use it like a REPL back then. That's what I would miss now with source map
        cromwellian 11y ago
        It might be possible to pull this off with the new compiler because it's draft mode is a true incremental unoptimized draft, and translating an expression to call the JS is a relatively straightforward ABI.
    - solomatov 11y ago
      Actually, source maps and browser based debugging are quite good. They aren't as good as Java debugger, but good enough. I am working on a large scale project which uses GWT, and we are absolutely ok with source map debugging.
timv 11y ago
The essential argument seems to be 2 things: 1. It can generate node.js compatible JavaScript so you can run Java code in node. I'm not sure how many people have felt the need to do that, but it's not something GWT can do. 2. It understands TypeScript, so it can make use of the work people have done to (essentially) create type annotations over various JavaScript libraries, and automatically (? or at least painlessly) build Java wrappers for them.
- cromwellian 11y ago
  GWT in Node JS https://github.com/cretz/gwt-node https://github.com/cretz/gwt-node Generating Java interfaces from TypeScript is coming soon. We have done this in the past from WebIDL in the Elemental library provided by GWT. A new tool which can do it from WebIDL, Closure JsDoc, or Typescript (all three) is being developed.
  - renaudpawlak 11y ago
    Well it is already done in JSweet: checkout these APIs http://www.jsweet.org/candies-snapshots/ http://www.jsweet.org/candies-snapshots/ It is all compiled and deployed as Maven artifacts on our repo. And we even give access to all the JavaDocs if you follow the links to the end... checkout this Angular JavaDoc for instance: https://jsweet.org/apidocs/snapshots/org/jsweet/candies/angular/1.4.2-SNAPSHOT/ https://jsweet.org/apidocs/snapshots/org/jsweet/candies/angu... Let us know if you are interested in collaborating on this (never hurts asking).
- solomatov 11y ago
  Why anybody wants to run node.js instead of Java. Java is much better suitable for the server side than node.
  - nothrabannosir 11y ago
    Nobody has commented yet. I can only guess this is because all agree: it goes without saying that this sweeping generalisation is patently untrue. Still, allow me to humor you and give just one (of the many) reason(s) why: async I/O. Yes, it's possible in Java. Yes, Java has futures that make it not just possible, but also a reality in this universe. Unfortunately, Java has made the inconvenient decision to retain backwards compatibility and keep all its synchronous I/O operations available. Perhaps not a complete folly. For all of the good that decision has brought, there is one downside: any code (any lib) can still lock up an entire OS thread. Result: all libs actually do this. No matter how Future-istic your codebase; use any lib and you're back to sync I/O.[1] This is absolutely killing for high concurrency, I/O bound servers, who now lock up not just an FD or two per conn, but also an entire OS thread. Javascript's threading model, on the other hand, is so shit that it came out the other side. By being inherently single threaded, all blocking I/O must be done through callbacks. Result: you can't block an OS level thread in javascript! So all libraries are inherently async (from the OS level). There are, of course, many more reasons why Java is not "much better suitable for the server side than node", but this is just one of them (libraries, existing knowledge in your org, community, ...). In reality, both have their uses. Node has proven itself by now. Disclaimer: I actually hate Javascript. And Java. Including Java 8 (for all the shit it, wisely, keeps around). [1] E.g. Amazon's official AWS SDK, which is sync IO. Want async IO for S3 (or anything there)? Write it yourself. Which you won't. Because there's already a lib. "But it's not async!" // TODO.
renaudpawlak 11y ago
It is different. The focus is different. JSweet focuses on TypeScript/JavaScript while GWT focuses on Java and see JavaScript as just an execution engine. Now GWT is obviously adding bridges to JavaScript, but still, it is not the main purpose. As I understand GWT, it still relies mostly on the GWT SDK and on Java semantics at runtime. If I may add some hopefully-constructive criticism, it feels that GWT (like some other well-known Google frameworks) is trying to address too many issues at the same time... But that's my own opinion and it does not mean I don't appreciate it.

ggonweb 11y ago

What are the good options to convert from Javascript to Java or to other high level languages?

renaudpawlak 11y ago
Transpiling from an untyped language to a typed one would give you horrid results in most cases. The practical way would be to use TypeScript to compile your program (JavaScript programs compile fine with TypeScript) and start to manually transform your JavaScript code to add objects and types. That said, that would be a really cool tool to have...
- ggonweb 11y ago
  Has anybody tried Mozilla Rhino https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/JavaScript_Compiler https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rh...

warfangle 11y ago

Why ES5 instead of ES6/2015?

renaudpawlak 11y ago
I am not sure to what your question is referring to, but FYI, JSweet follows the same pace as TypeScript in terms of JavaScript generation. So it already supports most of ES6 AFAIK.
- warfangle 11y ago
  None of the sample code exposes a) es6 module format b) amd module format c) commonjs module format.... It's all closure-based jquery plugin module format....... If you're gonna compile to "javascript" either target a version of node that's been released in the past year or target webassembly. Otherwise you're just another coffeescript.
EvanPlaice 11y ago
ES6 is only partially implemented in Node.js and requires transpilation to ES5 for client-side code. ES5 will be continue to be the target to until either/both platforms are feature-complete.

hardlystriclyjs 11y ago

possibly related: can some news hacker please create an internet crawling worm that untranspiles all the javascripts that it crawls and turns them into wars for everyone who wants to go the other way? I guess we also need mozilla developer network to create a browser plugin to run the war files for a given site, perhaps npm would host the wars, so we can use node to get the wars from npm for the plugin. thanks

cromwellian 11y ago

The GWT team has been working on a next-gen compiler that transpiles directly to readable, JsDoc typed ES6, designed for high levels of optimization by the Closure Compiler. Because of the new JsInterop system was designed for GWT 2.8, that is shared by both GWT and this new compiler, low impedance interop between Java and JS will be possible, as well as a tool that reads WebIDL and typescript libraries, and generates Java types. As an example if the level of low impedance between the languages, consider the @JsFunction annotation, @JsType(isNative = true) interface EventTarget { void addEventListener(String event, EventListener listener); } @JsFunction interface EventListener { void onEvent(Event event); } Using Java8, you can write code like: document.createElement("button").addEventListener("click", x -> Console.log("Hello World")); The difference between GWT running this, and the new compiler, is that the output of the new compiler is a standard ES6 module. The JSweet claims about GWT are out of date. First of all, in-browser Java debugging has been available for years. GWT was in fact, the very first transpiler to leverage Chrome source maps. I demoed this three years ago (https://www.youtube.com/watch?v=-xJl22Kvgjg https://www.youtube.com/watch?v=-xJl22Kvgjg) Secondly, GWT has a "reversible and compatible" JsInterop system that provides full two way low-impedance bidirectional interop, you can even do things like subclass JS objects from Java, or define "fields" via @JsProperty which invoke methods ala Object.defineProperty() Third, the JSweet stuff looks like it doesn't obey standard JLS semantics. Does it even compile the JRE or Guava? This is absolutely vital for code sharing between platforms (e.g. server, Android, j2objc). If you can't run standard JLS semantics, there's little point to writing the code in Java in the first place.

amican 11y ago
How can you tell it's disobeying standard JLS semantics?
- cromwellian 11y ago
  I looked at the source. Doesn't seem to support class initialization properly. It models lambdas as just arrow functions, which won't work if you try to pass them as Objects to other Java functions (where is Object.getClass()/hashCode()/equals() ?) It doesn't handle runtime checks of Java interfaces at all, for example: interface Foo {} class FooImpl implements Foo {} Object o = new FooImpl(); if (o instanceof Foo) -> compile error The inability to even handle Java interfaces should be a clue right off the bat that this won't compile any non-trivial Java code base.

monocasa 11y ago

<soapbox>I really dislike the term 'transpile'. It's just a compiler. There's nothing really different in theory or implementation of a "source"->"source" vs a "source"->"binary" compiler. If I were to write a CPU in HDL that natively executed JavaScript, would this change from a 'transpiler' to a 'compiler'. The distinction made is simply what the end user is going to do with the result.</soapbox>

cromwellian 11y ago
I like the distinction in the sense that transpilers generally don't do optimization. GWT, Dart2JS, and Closure Compiler aren't transpilers in this sense. They are full blown optimizing compilers. Putting GWT or Closure in the same category as JSweet, TypeScript, or CoffeeScript obfuscates what these tools do.
- monocasa 11y ago
  So if I run gcc with -O0, it's a transpiler? Remember that gcc outputs a human readable language that another program (the assembler) converts into machine code.
  - cromwellian 11y ago
    In one sense yes, but GCC the utility is an optimizing compiler. Would you call a sed script which converted Java to ES6 via regexes a compiler, even though not an ounce of compiler theory was used? I would define transpilers as a subset of compilers that are are only interested in high level language conversion. It's the difference between say, translating books between foreign languages, and being an editor who rewrites a book to be better.
    - monocasa 11y ago
      I mean... sed is Turing complete. Yeah, it's in the Turing tarpit, but if you were able to successfully translate Java to ES6 in a sed script, yes I would call that a compiler. In a lot of ways, much of compiler theory is concerned with the best way to write a compiler (for many different optimization functions of "best"), not the only ways to do so. Just being a crappy compiler doesn't make it any less of a compiler.

crudbug 11y ago

I would rather make TS to JVM & CLR Bytecode, to have a unified ecosystem from the opposite side.

TheAceOfHearts 11y ago

A few weeks back I was looking though some java code and I was hopeful I'd be able to transpile it in order to run it in the browser. I'm very experienced with JS and its ecosystem, and I figured that java was so popular that it should be straightforward to achieve this. But unfortunately, after 2 days of screwing around, I didn't have any luck. I'm not sure if it's due to my unfamiliarity with the java ecosystem or if the tooling or documentation were just poor. In any case, this tool looks friendlier than GWT, so perhaps I'll give it another try at some point.