Refactor Web engine's core to modules

[pandamicro]

The web engine is now managed by a dependency config file (moduleConfig.json) and a poor script insertion mechanism. AMD/CMD module management will be great for the web engine to manage module dependencies.

Essential benefits

1. User and the engine itself can profit from module management feature.
2. It can help user to build up their own web workflow and easily combine cocos with other frameworks.
3. The granularity of modules can be greatly reduced, the result is that a web package can be very small.
4. Avoid global variable pollution, reduce variables in some namespaces.

   Proposed solution

   • [ ] Choose between require.js or CMD solution (like sea.js). AMD is more web friendly with asynchronous feature, but CMD have more compact API and usage.
   • [ ] Create a tool based on gulp or r.js directly to package all js files into one file and obfuscate the js file.
   • [ ] Refactor CCBoot.js to support two ways of dependency management (The old one and the new one).
   • [ ] Keep compatibility with old versions.
   • [ ] Refactor engine's core module with the new module management system.

     IMPORTANT

SHOULDN'T AFFECT API

[pandamicro]

@hyperandroid @Yi @linshun @VisualSJ @Wu-Hao @jwu @jareguo What do you think about this proposition?

[linshun]

Yes, we should do some research on it. We do need the modules feature to make engine maintaining more easier and reducing the package size. Let's put it in v3.8.

[jareguo]

Separating your code in AMD/CMD will lead to a highly organized code structure. And will make it easier to strip unused parts of code. The solution in Fireball's engine-framework is CMD and just inspired by pixi.js.

The benefit of CMD is you don't need to define config file(http://requirejs.org/docs/api.html#config), and therefore reduce conflicts so more git-friendly. However a big disadvantage is, you have to compile codes into one js through browserify everytime before running in the browser.

[hyperandroid]

Sorry, but i am on holidays and had not read the request until now.

I really have second thoughts about modules in the engine's core, as you already know by which i wrote in the cocos2d-html5 document we shared for some time.

Back to modules, a Director instance would probably depend on all the other core classes/modules, from math, to node, to renderer, to everything else. So i really don't the point of modules on the core when after all, just referencing the Director instance would bring all the other core modules to memory.

I agree modularization is essential for other stuff nonetheless. For example physics, image utilities, etc. things that are not needed as the engine's minimal core, but would eventually be needed by my game.

Consider that in the end, a developer does not want the module system in production code. Modules are useful more for development purposes or for environments that require a highly dynamic working environment, like node. What i want In production is my code minimized, containing only the needed runtime code ( not huge 2Mb libraries i don't make use of 50% of its functionality). I definitely need all the core code so that my game can run. So modules will force you to build some code for browserify or equivalent, so that a developer can get a customized version of cocos code which is just the needed code for his game.

just thoughts.

[yi]

Hi guys, I’m sorry for the lag of reply. I had some problem with my gmail access :( and just saw this discussion.

I think "Refactor Web engine's core" might be a heck lot of work to do, and would suggest a thoroughly consideration before implementation

In the past few months, we have been working on a html5 mobile game based on cocos-html5. In order to improve our workflow, we did few modification on cocos-h5, as well as our toolset. I’d like to give a brief description as following, and hope that would be a helpful for your consideration.

P1. A workflow seems to be currently absent in cocos-h5

We first found the usage of project.json is a time waster. As the project grew complex, we had to spend time manually altering the js file list in project.json, that was a bit tiresome. So we wrote a simple bootstrap script to load js files on demand automatically.

P2. Html5 game does need a build system (or script)

Due to the nature of web browser, html5 games are delivered in the form of a single js file rather then a bunch of little files. While little pieces of files is good for development purpose. So we need some kind of tool to “build” a distribution version from the development code.

As we are actually coding in CoffeeScript, the building tool is much simpler then writing directly in js.

P3. The current Cocos2d-html5 lite version could be even smaller

For an example, we don’t need LabelAtlas in our game, but we have to take with it because our code requires LabelBMPFont. I believe a modularized cocos could be better minified. But back to Point 2, a build tool must be created beforehand.

After all, I would suggest to design a proper building tool for cocos-html5 first. After that, choosing a modularization system would be an easier question.

[gamedolphin]

I have re-written the bootstrap cocos2d js app with webpack such that i'm able to require modules. Still relies on project.json to pick up the two source files though.

cocos2dx-webpack-example

[pandamicro]

This issue will be closed because we have a solution in Cocos Creator engine

Currently in Creator engine, we use node.js module API to reorganize, then pack them with browserify.

For Cocos2d-html5 engine, we don't have enough time to clean up everything recently.