Forums » Impact Engine » Feature request: use RequireJS or browserify for module loading

It came up in this other thread so I thought I'd post it here as an "official" feature request.

I'll just quote what I wrote over there:

I just wanted to jump into this thread to cast a vote for not re-implementing the wheel: how about the next major version of ImpactJS uses a separate, major module system like RequireJS or, better yet, browserify?

This complicates things in a few ways: it would be backward incompatible with existing 1.x code; it might require a separate build step (browserify doesn't load things dynamically); neither of these tools provide built-in progress events to provide feedback to the user.

It would provide some benefits: both of these tools can load static files and make them available as JS variables; an entire community devoted to solving loading problems in ingenious ways; more standard, modern JS way of doing things.

Both of these tools provide for "baking" and optimizing steps as well.

There are some ancillary benefits: the loaded modules are isolated from each other instead of being JS globals; RequireJS also allows for passing in config information to the module so you could do things like config a module based on what platform it is being built for, web or iOS; etc.

This would also make available nearly every major JS library to our games in an elegant, sustainable way: underscore/lodash, jQuery (although I bet our games don't need much of it), socket.io, etc.

Just something for Dominic to think about, I guess. ( =

RequireJS can easily provide user feedback if you use it to dynamically load items. So it can do everything the ImpactJS system does and more. See here for details http://stackoverflow.com/questions/17446844/dynamic-require-in-requirejs-getting-module-name-has-not-been-loaded-yet-for-c

I'd love to see ImpactJS built on Browserify. So much so I've even toyed with trying to do it myself. With such great tools out there now (gulp, grunt, etc), having proprietary module and baking system is a bit of a hindrance.

100% agree. I've fantasized in the past about re-working it in a repo and presenting it to Dominic as finished and saying, "Look how much better this is!"

But I wonder if the current solution works well for Apache-and-PHP webdevs and shouldn&039;t change for everyone? Weltmeister's server-side API is PHP, the bake script is PHP, etc. Maybe those tools are more widespread and already known by most webdevs vs. Node and npm and #package.json and npm install and browserify and all its plugins and source maps... Anyway.

I&039;m more of a Node guy, hence the <1> and how my plugins are #package.json-ified.

This is all a long-winded way of saying if you do it let me know and if I do it I'll let you know. Maybe maintain as a set of patch files for when new minor versions of Impact come out?

Seeing browserify instead of the self baked modules would be wonderful. I'd even be willing to help. I'd prefer to have browserify because it will be easier for me to then reuse modules between the front end part of the game and the server (node).

I just finished writing my own node server for impact, attempting to switch it over to browserify may be next. I always end up enjoying this stuff more than working on the game :-)