5 ms·

The biggest problem for me with any JS framework I've tried in the past is that it doesn't give an easy way to divide code into multiple code files. For me per

The biggest problem for me with any JS framework I've tried in the past is that it doesn't give an easy way to divide code into multiple code files. For me personally, I find any single file/module/class that is more than a few hundred LOC to be difficult to read. For this reason I've usually rolled my own frameworks. Does Amber.js address this?

maratd 15y ago
Take a look at MooTools. It's built around a module/class based philosophy that makes it easy to not only configure the framework itself into what you need (the framework is built around several dozen small files), but to do the same thing to your code as well.
davej 15y ago
Spine uses HEM which allows you to develop your apps using separate files (in JS or CS), it basically uses the CommonJS spec AFAIK. Then when you want to move from development to production it concatenates and minifies all the files for improved network performance.
rxcfc 15y ago
We're definitely aware of this issue and are working on some solutions that should be relatively painless.
ccapndave 15y ago
bpm (http://www.getbpm.org/ http://www.getbpm.org/) works with Amber and compiles multiple Javascript, SCSS and Coffeescript into a single JS and CSS file. It also has a mode where it does it in realtime for development use.
ebryn 15y ago
Amber's object model is very powerful. It has mixins and easy-to-use inheritance. You can reopen classes too.
bmuon 15y ago
You could also look at YUI. YUI3 is built from the bottom up with that mentality: keep a file for each class, merge them in the build stage into one module file and serve all modules combined automatically.
tolmasky 15y ago
Cappuccino's @import does this really well: it is both asynchronous and blocking. In other words, having three @imports one after the other will all load in parallel (without having to explicitly request it, even if they are separated by other lines of code), but the code itself will not execute until the imports are done: @import "one.js" // loaded in parallel to the other two @import "two.js" // loaded in parallel to the other two code code code // this is run only after one.js and two.js (but not three.js) have been loaded and run @import "three.js" // loaded in parallel to the other two
- cousin_it 15y ago
  Very nice! Just a note: that seems to break some things that Ruby developers take for granted, like importing stuff conditionally, or importing a bunch of files in a loop. Or is there some other way to do that?
  - tlrobinson 15y ago
    There are JavaScript APIs in the loader you can call directly, but they will be asynchronously loaded and executed (so you'll need to pass in a callback) Basically the only way to get this asynchronously loading / synchronously executing behavior is to statically analyze your "root" module for dependencies and load them (and their dependencies, etc). Once they're all loaded you can begin execution and synchronously execute every module as they're imported. FYI CommonJS (not AMD) loaders for the browser do the same thing to avoid synchronous XHRs that will cause the UI to hang.
  - tolmasky 15y ago
    You can still import things conditionally (its treated as a statement), the only real restriction is that the filename is expected to be a static string, so the for loop thing wouldn't work. However, the "guts" of the import statement are also provided to you as a function that you can just call with anything, so you could still have for (;blah;) objj_import(filenames[i], callback) for these kinds of cases.
randall 15y ago
Browserify lets you require stuff if you're used to node paradigms. https://github.com/substack/node-browserify https://github.com/substack/node-browserify
erichocean 15y ago
SproutCore has supported this since 2007.
ef4 15y ago
Actually I'd rather not see the JS framework itself trying to solve this problem. The Rails asset pipeline (based on Sprockets) is an example of a good solution to this problem that is completely agnostic to your JS framework. I'm serving a substantial Amber app this way and it works great. I'm taking it a step further by writing most of my code in Coffeescript, and I keep all my Handlebars templates in separate files as well. Sprockets just magically combines it all.
korny 15y ago
brunch (http://brunch.io http://brunch.io) provides this for backbone.js / eco / stylus - it merges multiple source files into a single deployable js (and css) file. Or you could use spine, which has this out of the box.

maratd 15y ago

Take a look at MooTools. It's built around a module/class based philosophy that makes it easy to not only configure the framework itself into what you need (the framework is built around several dozen small files), but to do the same thing to your code as well.

davej 15y ago

Spine uses HEM which allows you to develop your apps using separate files (in JS or CS), it basically uses the CommonJS spec AFAIK. Then when you want to move from development to production it concatenates and minifies all the files for improved network performance.

rxcfc 15y ago

We're definitely aware of this issue and are working on some solutions that should be relatively painless.

ccapndave 15y ago

bpm (http://www.getbpm.org/ http://www.getbpm.org/) works with Amber and compiles multiple Javascript, SCSS and Coffeescript into a single JS and CSS file. It also has a mode where it does it in realtime for development use.

ebryn 15y ago

Amber's object model is very powerful. It has mixins and easy-to-use inheritance. You can reopen classes too.

bmuon 15y ago

You could also look at YUI. YUI3 is built from the bottom up with that mentality: keep a file for each class, merge them in the build stage into one module file and serve all modules combined automatically.

tolmasky 15y ago

Cappuccino's @import does this really well: it is both asynchronous and blocking. In other words, having three @imports one after the other will all load in parallel (without having to explicitly request it, even if they are separated by other lines of code), but the code itself will not execute until the imports are done: @import "one.js" // loaded in parallel to the other two @import "two.js" // loaded in parallel to the other two code code code // this is run only after one.js and two.js (but not three.js) have been loaded and run @import "three.js" // loaded in parallel to the other two

cousin_it 15y ago
Very nice! Just a note: that seems to break some things that Ruby developers take for granted, like importing stuff conditionally, or importing a bunch of files in a loop. Or is there some other way to do that?
- tlrobinson 15y ago
  There are JavaScript APIs in the loader you can call directly, but they will be asynchronously loaded and executed (so you'll need to pass in a callback) Basically the only way to get this asynchronously loading / synchronously executing behavior is to statically analyze your "root" module for dependencies and load them (and their dependencies, etc). Once they're all loaded you can begin execution and synchronously execute every module as they're imported. FYI CommonJS (not AMD) loaders for the browser do the same thing to avoid synchronous XHRs that will cause the UI to hang.
- tolmasky 15y ago
  You can still import things conditionally (its treated as a statement), the only real restriction is that the filename is expected to be a static string, so the for loop thing wouldn't work. However, the "guts" of the import statement are also provided to you as a function that you can just call with anything, so you could still have for (;blah;) objj_import(filenames[i], callback) for these kinds of cases.

randall 15y ago

Browserify lets you require stuff if you're used to node paradigms. https://github.com/substack/node-browserify https://github.com/substack/node-browserify

erichocean 15y ago

SproutCore has supported this since 2007.

ef4 15y ago

Actually I'd rather not see the JS framework itself trying to solve this problem. The Rails asset pipeline (based on Sprockets) is an example of a good solution to this problem that is completely agnostic to your JS framework. I'm serving a substantial Amber app this way and it works great. I'm taking it a step further by writing most of my code in Coffeescript, and I keep all my Handlebars templates in separate files as well. Sprockets just magically combines it all.

korny 15y ago

brunch (http://brunch.io http://brunch.io) provides this for backbone.js / eco / stylus - it merges multiple source files into a single deployable js (and css) file. Or you could use spine, which has this out of the box.