Journey From RequireJS to Browserify | Hacker News Reader

Journey From RequireJS to Browserify

esa-matti.suuronen.org

37 pointsedtechdev14 comments

I did the opposite and I have no regrets. RequireJS is wonderful because you only need to refresh your browser to see your latest changes. Browserify has probably come a long way (I switched from Browserify to RequireJS about a year ago) but every time I try to give it another chance, I experience some serious downsides that turn me off.

>Always bundling. No running into build problems later on.

That's not something I would list in the "pro" column. RequireJS can build into a single file for production - it's dead simple to set up.

Require triggered twice the ini file last time I used it (one month ago), I had to add code to check if it has already been executed before. Apparently it haves something to do with jQuery being already loaded before require; also I could not make it work on old browsers despite their claims that it does.

> RequireJS can build into a single file for production - it's dead simple to set up.

Really? My experience was that it was a nightmare. Now you have to maintain yet another massive JavaScript config file (in addition to your original runtime require config file---don't get me started on that thing).

Plus, having different code run in development versus production led to constant issues.

you can actually use the same config file for the runtime and the build

That's right! And even use a query hook in your urls to switch between minified/bundled, un-minified/bundled, and un-minified/un-bundled versions of your code base! All with one config file. Just refresh.

I've had the opposite experience to you. It took a little while to understand what was going on but once I did, I set up a project template that I've been able to use in all projects with little in the way of changes. Dev with asynchronous loading and production with built file.

The best thing about it is I use jade for my template language and it can be configured to precompile the jade in the bill step, allowing me to use jade in the browser on older browsers. Also as mentioned in a sibling comment I use the same config file for building and development.

This isn't specific to requirejs but it was also possible to work it into the asset pipeline of my backend system so that in production it compiles, caches and serves the built file and in dev it uses the asynchronous loader.

The only issue I've run into is the same as the flotr2 issue described in the post, which it sounds like there is an easy fix for ski look forward to trying it out.

Actually, "always bundling" isn't even true - https://github.com/domenic/browserify-deoptimizer

Its not yet possible to write a transform that brings back eval and //@sourceURL which is compaibile with a lot more browsers, but if you use the separate parts that browserify is made of (module-deps, insert-module-globals and browser-pack) you can add it, like so:

    module-deps main.js | insert-module-globals main.js 
    | sourceurl-transform | browser-pack > bundle.js

I'll add some r.js cons and browserify pros:

r.js has an inflexible build process. It tries to do everything and assumes you want it to be your only build tool, which fails with things like LESS files, custom image generation etc.

browserify does its bundling and lets you do the rest in your own build system of choice (even minifying is separate). Much better.

Also, browserify gives you access to npm, one of the best package managers today. You can publish modules in the npm registry or in your own private git repositories and quickly add them to any project using npm install. The best thing about this? Practically all modules that don't do server-specific I/O are browserify-compatible. You have a huge chunk of the npm registry available at your disposal.

>> r.js has an inflexible build process. It tries to do everything and assumes you want it to be your only build tool, which fails with things like LESS files, custom image generation etc.

I'm not sure I agree with that. I use r.js just for building my JavaScript. I just point it at my main.js and voila I get a main-built.js.

I'm not sure how it stops you from using other tools like LESS to deal with stylesheets and pulling these steps together however you want. For instance my build.sh script is 4 lines, a call to r.js for my JS, a call to handlebars to precompile my templates, a call to uglifycss for my styles, and then a call to a tiny Node script which generates my index.html in either dev or production mode. I don't feel like r.js is dictating by build process at all. (PS, I am aware I should probably check out Grunt!).

>> browserify does its bundling and lets you do the rest in your own build system of choice (even minifying is separate). Much better.

With r.js you can set optimize: "none" [1] (in build config or on the command line) and then it won't minify it for you. You can then minify as a separate step if you wish.

[1] http://requirejs.org/docs/optimization.html#turbo

r.js tries to pull all the files in the base path and copy them to the build path by default. It also pulls the less files, non-built images - pretty much everything, and mirrors it exactly at the build path.

How to turn this off? I suppose its the appDir option - or is it? With require.js's documentation and the confusing option names, who knows...

If its appDir, why isn't it called something saner like copyPaths that actually indicates what its going to do rather than assuming I'm familiar with its notion of "appDir"?

It all probably comes down to these two points:

* require.js options are confusingly named, and

* the documentation is convoluted and conflates explanations of multiple options at once

Oh, now I'm with you. I guess I've never tried that kind of build, in fact maybe I found a lucky vector into the optimizer the first time I came across it, as I now see if you read the optimizer docs from top to bottom it does initially guide you towards the whole dir approach.

Maybe the optimizer/r.js docs could do with splitting up into "how do I do X..." pages, so if you're purely after optimizing your JS, for example, the path is clearer.

I really wish the community would standardize on one module format (AMD or commonjs or one of the other lesser-known formats).

My biggest gripe with Require is having to wrap every single node.js library you want to use client side in boilerplate.

It's obnoxious for all kinds of reasons.

That said, I have yet to run across a solution that I actually like a whole lot for helping to make server and client side JS cooperate.

What I ended up doing is writing a fake 'require' that replicates the nodejs require semantics (e.g. http://hastebin.com/nipaburipe.js)

I had similar experiences with Require and wrote http://github.com/olegp/joinjs instead of using Browserify since I found it unnecessarily complicated.

Reply on news.ycombinator.com