next »

[Klaim]

@st33d: Aren't all those things either irrelevant for optimization, part of the library that comes with the language or consequences of the underlying VM?
And this is where GWT's deferred binding comes into play. It gives you a way to abstract away lowlevel issues and platform differences.

As a standard library is part of the language, AND some of the issues are language issues, not only implementation issues, I would say those are real important differences.

[Chromanoid]

Mmh ok, point taken. However still I think the differences are managable by endavours like HaXe or GWT/PlayN.

[Nix]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

The problem is that without a consistent client/run-time, the same code may not run properly on all platforms. At least the Flash Player is the same thing, more or less, on Linux, Windows, and Mac. The same can't be said about the performance and behavior of Safari, Firefox, Chrome, IE, etc (not to mention all the different versions of these browsers).

[Chromanoid]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

The problem is that without a consistent client/run-time, the same code may not run properly on all platforms. At least the Flash Player is the same thing, more or less, on Linux, Windows, and Mac. The same can't be said about the performance and behavior of Safari, Firefox, Chrome, IE, etc (not to mention all the different versions of these browsers).

Don't you have the same problems with different devices when programming with C++/OpenGL?

[Nix]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

The problem is that without a consistent client/run-time, the same code may not run properly on all platforms. At least the Flash Player is the same thing, more or less, on Linux, Windows, and Mac. The same can't be said about the performance and behavior of Safari, Firefox, Chrome, IE, etc (not to mention all the different versions of these browsers).

Don't you have the same problems with different devices when programming with C++/OpenGL?

Oh yeah. I didn't really read what I was responding to. I was thinking in comparison to Flash or similar platforms.

[Klaim]

Don't you have the same problems with different devices when programming with C++/OpenGL?

It's a bit different : you know that the behaviour will be the same, if it runs on the different targets (meaning not if the target hardware are too differents and the code don't manage thos differences). The main differences between the same C++ code operating on several different targets will be about performance "scale", not language behaviour. Maybe memory access will be a problem on a platform but that will be ovious by profiling or other ways. Compare that by the required knowledge when you have different languages : the platform AND the language can be both sources of problems.

[Chromanoid]

Yeah, I was talking about JavaScript+HTML5 vs C++ or Flash vs C++ on different devices. "Language to language to platform" compilation adds definetly a big layer of complexity. This is why it has to be well made to hide the complexity... At least GWT/Java to javascript works well enough that big companies are using it.
GWT development is IMO really comfortable. Integrating special javascript stuff is pretty easy. I once worked on a chrome addon with GWT, it was really a nice experience.

[Chromanoid]

I am curious about Google's new programming language DART. Since it is a bit like GWT programming in DART for PlayN may be possible in the future...

[st33d]

Yeeeah.

There was an article on Reddit with this guy picking apart Dart...

I would have thought that GWT would have been a better solution as opposed to making a version of Javascript that Javascript programmers will hate.

[Richard Kain]

I'm sticking with HaXe. Despite some of the limitations, I have my haxe applications compiling and running on darn near everything. And what few limitations I have run across are usually more related to SDL.

[mcc]

Yeah, I was talking about JavaScript+HTML5 vs C++ or Flash vs C++ on different devices. "Language to language to platform" compilation adds definetly a big layer of complexity. This is why it has to be well made to hide the complexity... At least GWT/Java to javascript works well enough that big companies are using it.
GWT development is IMO really comfortable. Integrating special javascript stuff is pretty easy. I once worked on a chrome addon with GWT, it was really a nice experience.

One thing that would definitely worry me is, ok, maybe the compile step works, but how likely are you to be able to run in a debugger in any way that makes sense?

[Chromanoid]

Debugging works pretty well. You can more or less debug your application like a normal Java application (server and client at the same time) step by step in Eclipse... This is because you can run the application in "hosted mode". This means the thing doesn't run in javascript but on your jvm that only sends every action to your browser. I wonder if this works for Flash and PlayN too. See http://code.google.com/webtoolkit/doc/latest/tutorial/debug.html and http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#DevGuideDevMode

[Serapth]

One thing about PlayN from my initial exposure is that the documentation is almost non-existent and the installation process is near to brutal, especially if Java is not your primary language.

If you aren't extremely confident in Java/Eclipse/Maven/Git, I put together this installation guide which is extremely detailed and should get you up and running.  I am going to take a deeper look into PlayN and possibly do a series of tutorials, as like I said, the documentation is extremely lacking.

I don't know if PlayN will take off or not, it's an interesting idea, but it does rather feel like Google doesn't know its target audience.  For a game library getting it up and running really gave me flashbacks to enterprise development and working with companies like IBM and EDS.  Given their target market is Indie and small developers, this just seems really silly.

[Mikademus]

Excellent guide! And an astonishing read! I was thinking "how could they?!" and my eyes kept widening as I read! Yeah, that nebulous complexity has to be done away with or there isn't a chance for PlayN to take off. Coupled with poor documentation and an unclear purpose or actual advantage things seems to talk against it atm.

[Chromanoid]

Thank you for this nice guide You are right it seems very complex, Java developers usually have done most of your tutorial already and are used to maven, but if PlayN really wants to target javascript, iOS and Flash developers, stuff like this and dozens of plugin installs are a no-go.
I think the main target groups of PlayN are Java, Android & GWT developers as well as medium-sized game companies and social game developers.