JavaScript / ES2015
Community Forums/Monkey2 Talk/JavaScript / ES2015
| ||
| I find it interesting that some MX2 features we discussed could be mapped 1:1 to JavaScript. Maybe such things could also be added to Monkey1, or MX2 could get a JS target (with the exception of pointers?). For example: <!doctype html>
<html>
<body>
<script type="text/javascript">
//
// Anonymous Functions / Lambda's / Function arguments
//
var mul = function(x,y) {
return x * y;
}
var add = function(x,y) {
return x + y;
}
var div = function(x,y) { return x / y; }
function calc(x,y,func) {
return func(x,y);
}
var v1 = calc( 3, 4, add );
var v2 = calc( 7, 3, mul );
var v3 = calc( 9, 2, div );
var v4 = calc( 7, 2, function(x,y) {
return x - y;
} );
alert("results: " + v1 + ", " + v2 + ", " + v3 + ", " + v4);
</script>
</body>
</html><!doctype html>
<html>
<body>
<script type="text/javascript">
//
// Closures
//
function StartAt( x ) {
function IncrementBy( y ) {
return x + y;
}
return IncrementBy;
}
function tst( func ) {
return func( 3 );
}
var f1 = StartAt( 2 );
var f2 = StartAt( 5 );
var v1 = tst( f1 )
var v2 = tst( f2 )
alert("results: " + v1 + ", " + v2 );
</script>
</body>
</html>Those codes look exactly like the things we discussed last week. :) New interesting JS features are coming with ECMAScript 6 / ES2015 soon (June 2015?): - https://github.com/google/traceur-compiler/wiki/LanguageFeatures - https://babeljs.io/docs/learn-es2015/ Traceur and Babel allow the use of ES2015 features today, by compiling ES2015 Javascript into ES5 Javascript. Nice for compatibility with current and older browsers: - https://github.com/google/traceur-compiler - https://babeljs.io/ - https://github.com/babel/babel Found the above tools while reading You Don't Know JS (book series) by Kyle Simpson (Interview). (also available at Amazon: http://www.amazon.com/s/you+don%27t+know+js&keywords=you+don%27t+know+js (Kindle & Paperback)) See also (for browser compatibility): - https://github.com/paulmillr/es6-shim/ - https://github.com/es-shims/es5-shim |
| ||
| It would be nice to keep JS on the radar in some form. Seems like TypeScript is picking up steam right now and Google is now using it for AngularJS 2.0 More about TypeScript. However since the main target of MX2 will initially be C/C++, it seems like you could just take the generated code and run it through Emscripten, More about Emscripten. Maybe even add Emscripten to the build process to target JS? Something to think about... |
| ||
| Maybe it helps to take a look how others are translating specific language features and data types etc. into JS, or built on top of such a tool (f.e. TypeScript): - List of languages that compile to JS |
| ||
| But the target is not JavaScript, it's web applications (HTML5). It's cool to have your Monkey code translated to JS, but this code ultimately has to run somewhere if the game has to be played. HTML5 is the standard language for web content. I think it's more a problem with Mojo and the limited HTML5 feature support if we won't see an HTML5 target in MX2. Of all the languages Monkey is targeting, JS is the most malleable and dynamic. I find languages built on top of it like TypeScript or CoffeeScript to be awesome. The former focuses more on a more structured coding approach, while the latter enables more functional programming features and code expressiveness. I don't think it will be a problem to implement whichever language feature we come up with in JS (except the ones requiring impossible low-level access like pointers, obviously), it will be more of a hassle to map dynamic features in more static languages. |
| ||
| The target is JavaScript. HTML5 is not a programming language, it just provides some tags like <canvas> and <video> to work with. Programming of HTML5 is done via JavaScript, and even HTML5 needs Polyfills like https://github.com/google/canvas-5-polyfill for cross-browser compatibility. Monkey1 does not compile to HTML5 - it compiles to JavaScript and uses HTML5 features like canvas. Just some examples why I would like MX2 JavaScript (*): three.js - JavaScript 3D library... using WebGL Website: Three.js Download: https://github.com/mrdoob/three.js/ Documentation: http://threejs.org/docs/ License: The MIT License Examples: - Examples - More Examples Demos: - TriggerRally - HexGL - They will eat you - Gravity Movie Experience - Racer-S WebGL Demo Canvas 3D JS Library Website: www.c3dl.org/ Download: https://github.com/cathyatseneca/c3dl There are some thousand JS libs waiting to get Imported into MX2... ;) * all examples require a decent browser supporting WebGL. |
| ||
| Sorry but saying the target is JavaScript is like saying the other targets are Java, C++ and Objective-C. You target a specific platform, not a programming language. The programming language alone doesn't do anything for you unless you use the functionalities the platform provides. JavaScript alone won't show you anything at all to interact with on a browser. JS and HTML5/DOM are both necessary to develop web applications. You can't talk about one without mentioning the other. If the target is JavaScript then I could run my Monkey app on NodeJS. Of course the output language is JavaScript (mainly). But without the environment the browser provides you won't be able to see anything nor interact with anything. And for web applications this is even more of a problem because of browsers inconsistencies. The main reason Mark stated HTML5 has been left out is that it pretty much sucks currently. Either feature X isn't yet available to use, or is too slow for prime time. |
| ||
| @itto:You target a specific platform, not a programming language. Technically, trans only cares about the language translation and which post-translation build commands it should run. The only thing that really restricts your target platforms are the implementations of Mojo available. |
| ||
| @Samah whatever is going on technically, there are iOS, Windows, Mac OS and maybe other platforms which all uses C++ as a language. But still, you have different "targets" to tell Monkey to compile the code to. Because the language is only one part of the puzzle. You need to use the platform libraries if you want access to low level stuff. JavaScript is just a language. If you want your game to run in browsers, you need a DOM implementation and global scope (which happens to be the window object in browsers) at the very least. The window object for example is taken for granted in browsers but another environment using JavaScript might provide a different one. JS by itself doesn't render a thing on the screen for you. You need a canvas, which is part of the HTML5 Web API. So what we are really targeting is the HTML5 ecosystem implemented by browsers, consisting of a larger set of technologies that allows more diverse and powerful Web sites and applications. This set is sometimes called HTML5 & friends and often shortened to just HTML5. Whatever, I'm not trying to be picky as much as I wonder how much JavaScript as a language could be a problem to translate Monkey code to, more so than implementing all the Mojo features of MX2. I'm all for having an HTML5 target for MX2 by the way, even if that would mean losing features. I know there's still Monkey for that, but it kinda feels like staying behind. |
| ||
| Of course you are right in that sense. The target languages may be C++ and JavaScript, while each target as a whole also includes APIs/technologies like HTML5, WebGL, OpenGL, DirectX, Direct2D, Cocoa, SpriteKit, SDL, WinAPI, etc... I think it's important to differentiate between the target languages and the libraries like Mojo/BRL. Each target should include a plain template that does not include such libs, so we can easily Import 3rd party libs (GUI, WebGL, etc), and write our own. For example, a plain JS/HTML5 target should not include code to initialize/setup a canvas. Such stuff is included with 3rd party engines already and should not conflict. A plain target code includes the translated language and the required GC functions. You just don't need Mojo when using QT, three.js, Ogre3D, etc. - Mojo is just a lib that you can Import, like any other lib. |
| ||
| @itto: Because the language is only one part of the puzzle. Which is why the language translation should not be strictly tied to the available Mojo or BRL native implementations. @itto: JavaScript is just a language. If you want your game to run in browsers, you need a DOM implementation and global scope (which happens to be the window object in browsers) at the very least. Javascript does not need to be run in a browser. It's quite feasible to write Monkey code that exports to Javascript, then import that into Unity or another target that supports Javascript. @itto: I'm all for having an HTML5 target for MX2 by the way, even if that would mean losing features. Then there needs to be clear documentation on the new Mojo 2 features saying "does not work on html5 target". @itto: ...as I wonder how much JavaScript as a language could be a problem to translate Monkey code to... Javascript isn't the problem, it's about which Mojo 2 features are supported by HTML5. @itto: I know there's still Monkey for that... Exactly. _______________________________________________________________ @Danilo: I think it's important to differentiate between the target languages and the libraries like Mojo/BRL. I agree. @Danilo: Each target should include a plain template that does not include such libs, so we can easily Import 3rd party libs (GUI, WebGL, etc), and write our own. Monkey kind of does already... sort of... The template directories still have a lot of platform-specific code rather than just language translation. @Danilo: For example, a plain JS/HTML5 target should not include code to initialize/setup a canvas. I get what you're saying, but I would separate JS and HTML5 in this. A base JS implementation would not set up a canvas, but an HTML5 target would. @Danilo: Such stuff is included with 3rd party engines already and should not conflict. At the moment the canvas is handled by Mojo and not 3rd party engines, so there should be no problem there. @Danilo: A plain target code includes the translated language and the required GC functions. You just don't need Mojo when using QT, three.js, Ogre3D, etc. - Mojo is just a lib that you can Import, like any other lib. Spot on. |
| ||
| @Samah Javascript isn't the problem, it's about which Mojo 2 features are supported by HTML5. This is what I was trying to say. Since HTML5 doesn't support all of the OpenGL or DirectX features, keeping an HTML5 target would mean lower the bar of possible features Monkey implements. That was the main reason why Mark wanted to leave it out. @Danilo: A plain target code includes the translated language and the required GC functions. You just don't need Mojo when using QT, three.js, Ogre3D, etc. - Mojo is just a lib that you can Import, like any other lib. I see now, you think it should be possible to translate to JS code anyway, even if not all Mojo features can be implemented. But by run it in other environments and by using other libraries/frameworks other than Mojo, we would be able to see our game running anyway. But isn't Monkey supposed to be a fast way to develop games on various platforms? If I can translate my code to JS but it can't run in a browser (because X and Y features work everywhere but in HTML5), then it just becomes a language translator. Or are you saying you would like to see a Unity or Ogre3D target? @Samah Javascript does not need to be run in a browser. It's quite feasible to write Monkey code that exports to Javascript, then import that into Unity or another target that supports Javascript. True, except the point of translating to JS in Monkey right now is to have a game running in a browser. I press the compile button and my game runs in the browser. It's another thing altogether to have to import my generated code to Unity or using framework X, or my code won't do anything by itself. EDIT By the way this is why it would be great to have a more modular build system, with separate steps and the possibility to customise them as needed. For example if I wanted my code to be just translated and nothing more, I would just setup the build to run only the code translation phase and skip the others. No need for copying the media folder, create an executable, and whatsoever... |
   |