4 ms·

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 ha

by 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.
  - EvanPlaice 11y ago
    Easy on the 'rage' 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). This statement is patently false. I/O requests are fired off asynchronously in the main context but fetch data via background threads. In addition, in a multi-core/processor system you can use the 'cluster' module to fire off multiple instances (ideally 1 per core) of the HTTPD. As for libraries. Node doesn't provide much in terms of 'batteries included' but the NPM registry has eclipsed the library ecosystem of every other language. If anything, the issue is too much choice as there are usually 3-5 alternatives for everything you can imagine. The minimalist nature of the Node core is a 'double edge sword'. The downside is, it requires a lot more cognitive load and research to choose the libraries to use in a dev stack. The upside is, since most of the functionality is developed independent of Node the core devs can focus the entirety of their effort improving the platform/language/packaging. The effort of building all additional functionality is the responsibility of the community. I have used Java some and C# a lot so I can understand why devs love the ecosystem and tooling. The tooling for JS is getting better over time but there's something to be said for IDEs that come prepackaged with all the tools necesssary to be productive. Personally, I shifted over time embracing the flexibility of dynamic languages and shifted to a mindset that favors composition over structure.
  - solomatov 11y ago
    >I actually hate Javascript. And Java. Including Java 8 (for all the shit it, wisely, keeps around). Could you give me an example of any technology which you don't hate?
    - nothrabannosir 11y ago
      Yes, but let's keep that talk for over a drink some time :) I put that in to clarify that Im not coming at this from fanboyism. It wasnt about me, but to contextualize the comment.
  - carterehsmith 11y ago
- deleted 11y ago
  [deleted]

by timv 11y ago

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.
- EvanPlaice 11y ago
  Easy on the 'rage' 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). This statement is patently false. I/O requests are fired off asynchronously in the main context but fetch data via background threads. In addition, in a multi-core/processor system you can use the 'cluster' module to fire off multiple instances (ideally 1 per core) of the HTTPD. As for libraries. Node doesn't provide much in terms of 'batteries included' but the NPM registry has eclipsed the library ecosystem of every other language. If anything, the issue is too much choice as there are usually 3-5 alternatives for everything you can imagine. The minimalist nature of the Node core is a 'double edge sword'. The downside is, it requires a lot more cognitive load and research to choose the libraries to use in a dev stack. The upside is, since most of the functionality is developed independent of Node the core devs can focus the entirety of their effort improving the platform/language/packaging. The effort of building all additional functionality is the responsibility of the community. I have used Java some and C# a lot so I can understand why devs love the ecosystem and tooling. The tooling for JS is getting better over time but there's something to be said for IDEs that come prepackaged with all the tools necesssary to be productive. Personally, I shifted over time embracing the flexibility of dynamic languages and shifted to a mindset that favors composition over structure.
- solomatov 11y ago
  >I actually hate Javascript. And Java. Including Java 8 (for all the shit it, wisely, keeps around). Could you give me an example of any technology which you don't hate?
  - nothrabannosir 11y ago
    Yes, but let's keep that talk for over a drink some time :) I put that in to clarify that Im not coming at this from fanboyism. It wasnt about me, but to contextualize the comment.
- carterehsmith 11y ago
deleted 11y ago
[deleted]