6 ms·

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

by solomatov 11y ago

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.

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.