5 ms·

Journey From RequireJS to Browserify

37 points by edtechdev 14y ago

cmwelsh 14y ago
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.
- jQueryIsAwesome 14y ago
  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.
- domenicd 14y ago
  > 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.
  - randomguy7788 14y ago
    you can actually use the same config file for the runtime and the build
    - pseudobry 14y ago
      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.
  - Bockit 14y ago
    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.
- spion 14y ago
  Actually, "always bundling" isn't even true - https://github.com/domenic/browserify-deoptimizer 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.
  - nilliams 14y ago
    >> 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 http://requirejs.org/docs/optimization.html#turbo
deleted 14y ago
[deleted]
Glyptodon 14y ago
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.
- niggler 14y ago
  What I ended up doing is writing a fake 'require' that replicates the nodejs require semantics (e.g. http://hastebin.com/nipaburipe.js http://hastebin.com/nipaburipe.js)
niggler 14y ago
I really wish the community would standardize on one module format (AMD or commonjs or one of the other lesser-known formats).
olegp 14y ago
I had similar experiences with Require and wrote http://github.com/olegp/joinjs http://github.com/olegp/joinjs instead of using Browserify since I found it unnecessarily complicated.

37 points by edtechdev 14y ago

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.

jQueryIsAwesome 14y ago
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.
domenicd 14y ago
> 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.
- randomguy7788 14y ago
  you can actually use the same config file for the runtime and the build
  - pseudobry 14y ago
    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.
- Bockit 14y ago
  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.
spion 14y ago
Actually, "always bundling" isn't even true - https://github.com/domenic/browserify-deoptimizer 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.
- nilliams 14y ago
  >> 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 http://requirejs.org/docs/optimization.html#turbo

deleted 14y ago

[deleted]

Glyptodon 14y ago

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.

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

niggler 14y ago

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

olegp 14y ago

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