

OneJS lets coders convert NodeJS projects into single, stand-alone files - combataircraft
https://github.com/azer/onejs

======
dkastner
I've been using a very similar tool, browserify to do the same thing. The
great thing about browserify is it already comes with core node.js library
support, as well as an http module wrapper.

With tools like this, I love being able to modularize my client-side code
using CommonJS modules and running JS test from the command line using tools
like Vows and Buster.js. I also love being able to declare dependencies on npm
modules. It's just as easy as testing and writing Ruby code with rubygems and
rspec.

The only issue that still bothers me is that nearly every DOM
querying/manipulating library out there assumes there's a global window or
document object. This means I have to stub it out in any CLI tests I run and
then make sure jquery or whatever is referencing a virtual window I create
with jsdom instead of the global stub.

I have a few project using vows/npm/browserify for reference if anyone is
interested. A FF/Chrome/Safari plugin:
<https://github.com/brighterplanet/careplane> A simple SPI app:
<https://github.com/brighterplanet/hootroot1>

~~~
combataircraft
although onejs and browserify tries to accomplish similar tasks, onejs has
some noticeable implementation and concept differences (e.g browserify
pollutes global scope a lot and it expects you to provide it a main module
instead of a package manifest)

here is the output comparison of onejs and browserify:

onejs: <https://gist.github.com/2398843> browserify:
<https://gist.github.com/2398824>

and here is a real world example of onejs;

<http://multiplayerchess.com/mpc.js>

The second thing is, onejs lets us use the core NodeJS library, too. It
doesn't contain it by default but you can install the available modules by
typing; "one install assert path util url"

------
RossM
I've been looking at Node recently and I'm struggling to get my head around
the run both on server and client methodology. I understand why it's useful to
define model classes and include the file in both places, however I don't
really see how this extends to the rest of the app. This tool seems to imply
that you join all the modules of the app together into one file, which you can
then include on the client - but surely there'd be code that you don't want
included in this (like the server-side of websocket communication)?

Does anyone have any articles that can help me to fill the gaps?

~~~
Lazare
There's two separate issues here.

1) "Hey, how can I use the same code on the server and the client?" Hard
problem, but you can look at Meteor or Derby for people working hard to solve
it. It's unrelated to this project though.

2) "Hey, I've been using npm and require and coffeescript to write some cool
code, but I want to run the _entire_ thing in the browser. How can I somehow
"bake" this all down to a single JS file I can deliver to the client where
everything just works? This is a pretty easy problem, and it's been solved by
Stitch (my favourite), Hem, Browserify, and probably a few more. And now,
OneJS. :)

If it helps to see an example, I'm working on an app with a really big
complicated source code tree; it's split into lots of files, plus a bunch of
libraries, some of which are "traditional" JS libraries like jQuery, and some
of which are "modern" CommonJS modules installed by npm. I use Stitch to
bundle the whole thing into a single application.js file which contains every
bit of my client-side code (only). My HTML file only contains two script
blocks.

    
    
      <script src="application.js"></script>
      <script>
        app = require('app');
        $(function(){
          app.run();
        });
      </script>
    

That's all it takes to load all my client side code - including all libraries
- and then kick off the initialization code once the DOM is ready.

I'm using Stitch, but I believe OneJS is designed to do the same thing. I'm
afraid I find the documentation on the project really hard to follow though,
so I might be wrong. :)

~~~
combataircraft
FOA, "using same code" means "sharing same source code in all JS environments"
in this context. "Proxying some server-side JS code to client-side" is totally
irrelevant to this topic, as you pointed.

And here are the differences of OneJS:

    
    
      - it produces unobtrusive code
      - it bundles any level of dependency properly
      - it's not only for web browsers, but also all JS environments including Node itself
      - it's a command-line tool that doesn't require you to code.

------
sudhirj
Interesting. From what I can see, it just tricks any CommonJS style module
into thinking that the module and exports variables are available; and that
it's running in a node like environment. Things like accessing the file system
and http wont' work, but that doesn't seem to be what it's meant for - it's
more "write your client side js in a testable common js format, declare
dependencies like backbone and underscore, and you'll get a neat little
browser runnable package at the end".

------
btown
_sigh_ If I had known about this a week ago, I could have avoided a whole lot
of hardship dealing with Require.js + node_jasmine + NPM... three complex
things that were never really meant to work together. But I can see this as
being really groundbreaking, kind of sidestepping the whole AMD vs. CommonJS
protocol fragmentation and offering NPM as a way to distribute code meant to
be bundled for clients!

------
olalonde
I wish I had known about this earlier. In a recent project, I had to come up
with a pretty ugly hack to make my script both Node.js and browser compatible:
[https://github.com/olalonde/kmeans.js/blob/master/lib/kmeans...](https://github.com/olalonde/kmeans.js/blob/master/lib/kmeans.js#L154)

