OneJS lets coders convert NodeJS projects into single, stand-alone files | Hacker News Reader

OneJS lets coders convert NodeJS projects into single, stand-alone files

github.com

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

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"

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?

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. :)

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.

A bundle file OneJS generates contains only a tiny CommonJS implementation and a simple "process" object ( use "--noprocess" option if not needed). You can browse them here; https://github.com/azer/onejs/tree/master/templates

It doesn't contain the standard library of NodeJS by default but you can install the available modules like assert, path, url etc.. by doing:

$ onejs install assert

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".

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!

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...

Reply on news.ycombinator.com