BabylonJS in Java using JSweet

[satguru]

So recently JSweet created the BabylonJS Java library http://www.jsweet.org/candies-snapshots/

 

I took that and coded a small BabylonJS project in Java.

 

See code  and resources at

https://github.com/ssatguru/Vishva

 

 

See demo at:

http://ssatguru.appspot.com/BabylonJS-Vishva/intro.html

 

Use WASD keys to move avatar, shift+W to run, click and drag mouse to look  around, mouse wheel to zoom in out and click button "Vincent" / "Joan" to switch avatar between male/female.

 

 

With Java this is becoming fun

 

[jerome]

you just succeeded to put "java" and "fun" in the same sentence : congratulations for this !   

 

 

[EDIT] btw, I can't find the java code in your github repo

[Temechon]

Java IS fun actually  Java Entreprise is NOT fun though...

[renaud]

@Jerome: it's there: https://github.com/ssatguru/Vishva/blob/master/src/main/java/org/ssatguru/babylonjs/Vishva.java

[Dal]

That's pretty cool. Every layer introduces more issues and bugs though - why not just code in Typescript directly? I think the headache of the jsweet libraries always being outdated and needing to be updated will be more trouble than just learning typescript for most people.

What *would* be awesome, is if it could port a Java game engine like jmonkeyengine to typescript/javascript... that way it would be possible to build for the web but also build a java version that should run faster and could use threads etc.

[satguru]

Temechon is right, Java is fun, Java Enterprise not

@Dal, Before I knew about JSweet, I was coding in Typescript. I actually started with Javascript but that was a struggle, so switched to Typescript. Typescript is nice but Java is, imho, much better. It has a much better and richer ecosystem. Just take Javadocs for instance - so much better documentation than what you get with Typescript.

Also I spent most of my working life coding in Java, so Java is like my "native / mother tongue"  

You do bring up a good point about libraries getting outdated and needing to be updated. But that is where JSweet stands out , They have nearly automated the process of  generating these libraries  If  you can provide a typescript type definition file  for a framework, they can provide a Java library for that framework.  Submit a typedef file to DefinitelyTyped site and within a few days, if not overnight, your libraries are ready.  They already  have Java libraries  for more than 1000 JavaScript frameworks, For us Java programmers that is Godsend !

 

 

[jerome]

Please don't mind, this was just a joke 

[renaud]

@Dal: JSweet librairies are generated every night from TSD... so most of them are "only" one day older than TypeScript definitions. Also, it is true that JSweet adds a layer, but by experience, it sometimes fix problems rather than creating new ones. Java being a more constrained language than TypeScript, I find it usually easier to program, especially when coming from a Java background (in TypeScript, the "any" type allows a lot of bad things and the use of lambda and global variables/functions can be misleading). Of course, at the end of the day, it is mainly a matter of tooling, taste and habits, because both are quite "similar" languages anyway  

[Dal]

I trained in Java originally too, and it is a pretty decent language. I personally feel that with Typescript and a good IDE you get most of the benefits of coding in Java anyway, but it's still just a superset of javascript so you can pretty much copy and paste javascript code in. If you work with javascript libraries from java you're going to have a lot more work porting the examples to java syntax.

Also, keep in mind that the TSDs are not always available or complete for all javascript libraries and sometimes they are just plain wrong. Babylon has very good TypeScript definitions because the core devs work in TypeScript, but a lot of other libraries you may want to use in the javascript ecosystem will have type definitions that are not quite right, or not current. In those cases, when working in TypeScript you can simply write your own definitions for those parts, or fall back to the "any" type. With jsweet I can imagine you will get stuck. 

Are the tools available to build the jsweet libraries from the tsds yourself if you need to?

[renaud]

Quote

 

In those cases, when working in TypeScript you can simply write your own definitions for those parts, or fall back to the "any" type. With jsweet I can imagine you will get stuck. Are the tools available to build the jsweet libraries from the tsds yourself if you need to?

 

With JSweet, you can just embed new typing definitions within your program if you find out that the TSD one is lacking something. These extra typing definitions are just classes and interfaces annotated with @Ambiant. That's similar to a declaration in TypeScript. Then you can declare or cast to this type to ensure (local) type safety on a given variable.

Also, JSweet provides simplified reflective access to object properties with $get, $set functions, with are defined on all JSweet objects. So, if you know that your object "o" defines a "p" property (could be a function), which is not defined in the definitions, then you can just write:

o.$get("p");

Which is basically equivalent in TypeScript to:

(<any>o).p;

Or:

o["p"];

You can argue that the JSweet syntax is not as good and less nice looking as the TypeScript version, but actually it is almost "on purpose". The idea behind it is that untyped code being dangerous, we prefer that it looks bad in order to encourage programmers to use and write well-typed programs. This design choice is a good thing when writing complex programs and wanting to refactor things, which is something Java is good at.

Currently, to get a JSweet library from a d.ts, you need to push the d.ts to DefinitelyTyped, and it will be available in the JSweet repo the day after (if everything goes well). We are working on an online tool to allow the transformation of any d.ts file so that users don't need to go through that process. 

[Dal]

Sounds good. I think this is something I'll certainly consider using in the future myself... I think the release of an open-source tool would be critical to any serious long-term adoption though.

[satguru]

On 1/12/2016 at 11:37 PM, jerome said:

Please don't mind, this was just a joke 

Didn't mind at all