announcing browserify v2

[substack]

browserify v2 was just released! browserify lets you write node-style require() calls for browser code so that you can package up your scripts and npm modules into a single bundle to serve to browsers. browserify implements exactly the node_modules lookup algorithm so you can use many libraries written for node and published to npm in the browser without any modifications.

Here's the full writeup of the new changes: http://browserify.org/announcing_browserify_v2

* static module resolution for tinier bundles. Just ~250 bytes of prelude now.

* support for multi-file bundles for multi-page apps and better caching of infrequently-updating assets

* streaming bundle pipeline

* new "browsers" field support by https://github.com/shtylman

* less features

The core library itself is just 180 sloc now with the bulk of the functionality now handled by completely separate, reusable libraries that you can use to build your own browserify if you want. Most of what browserify provides can now be provided by this shell pipeline:

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

Just `npm install -g module-deps insert-module-globals browser-pack` to play around with those streaming components.

tldr; less features, more unix!

[Mark Hahn]

Ouch.  I guess I will have to live with the old version until new add-ons support --watch and coffee-script.  Can't live without them and don't have time to write my own.

Sorry to be one the complainers you predicted.

[Nathan Rajlich]

Is Buffer automatically bundled when it's use is detected in your code now?

On Fri, Feb 22, 2013 at 5:10 PM, Mark Hahn <ma...@hahnca.com> wrote:

Ouch.  I guess I will have to live with the old version until new add-ons support --watch and coffee-script.  Can't live without them and don't have time to write my own.

Sorry to be one the complainers you predicted.

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[substack]

On Friday, February 22, 2013 6:44:45 PM UTC-8, Nathan Rajlich wrote:

Is Buffer automatically bundled when it's use is detected in your code now?

Not yet but this would be fairly simple to add to the insert-module-globals module. Expect this soon.

[Jake Verbaten]

--watch is simple. Use any watching tool in combination with browserify

Like `npm i wr -D && wr "browserify index.js > bundle.js" .`

As for coffee-script `coffee src -o lib && browserify lib/index.js > bundle.js`

On Fri, Feb 22, 2013 at 5:10 PM, Mark Hahn <ma...@hahnca.com> wrote:

Ouch.  I guess I will have to live with the old version until new add-ons support --watch and coffee-script.  Can't live without them and don't have time to write my own.

Sorry to be one the complainers you predicted.

--

[Alexey Petrushin]

> Ouch.  I guess I will have to live with the old version until new add-ons support --watch and coffee-script.

+1

> Custom require extensions are gone.

Sad news, I liked the way how require *.coffee or *.mustache files works seamlesly as if ti's just *.js files.

[Alexey Petrushin]

Any plans to support custom require in future? It works in node.js - why make browser version of `requre` different from its original?

[Bradley Meck]

We are doing some dark magic upcoming using https://github.com/bmeck/node-module-system +1 if we can get a standardized require shim. Does not need to be ours.

[Bradley Meck]

Generally I abstract out my implementations and my interfaces. This means a more verbose code base, but allows me to have the renderer inserted via dependency injection. It is independent of bundling tech and I have used it with browserify as well as with AMD to great success. Decoupling those allows you to reuse interfaces on server side, but implementations will always need rewriting. If you do dep injection though only the renderer generally needs a rewrite though which is a huge win.

[Alexey Petrushin]

> How do you handle dependencies in purely client-side code?

I use it exactly in the same way it would be used in node.js. From my point of view it's the point of browserify - environment is exaclty the same in both browser and server.

File app.js

NavigationView = require('./app/views/navigation')

OtherView          = require('./app/views/login')

....

File NavigationView.js

...

   // By using require hooks it requires `template.mustache` file and compiles it to js.

   require('./template').render(someVariables)

...

So, basically there's no any build or package specific scripts - it just works (except for tiny script packaging some vendor dependencies like jquery and backbone).

[substack]

On Friday, February 22, 2013 5:10:34 PM UTC-8, Mark Hahn wrote:

Ouch.  I guess I will have to live with the old version until new add-ons support --watch and coffee-script.  Can't live without them and don't have time to write my own.

Sorry to be one the complainers you predicted.

Now in v2.3 there's a `.transform()` api for all those who missed coffee-script from the <v2 days.

https://github.com/substack/node-browserify#btransformtr

From the command-line compiling coffee-script is now as simple as:

browserify -c 'coffee -sc' main.coffee > bundle.js

Transforms are a much more general-purpose solution that will let people build a lot of really interesting user-space experiments. For an example here's a plugin I wrote that inlines `fs.readFileSync()` calls with file contents: https://github.com/substack/brfs To use a transform plugin like brfs, you just do:

browserify -t brfs main.js > bundle.js

The best part of the new transform functionality is how transforms are module-scoped: the transforms you load aren't applied to modules from node_modules you require() and when modules from node_modules use transforms, those transforms won't affect your code. This isolation means that module consumers won't need to care and mostly won't even notice that packages they use are using transforms to do fancy things like loading static assets or other tricks. Packages can just set a `"browserify": { "transform": [ "plugin1", "plugin2", ... ] }` in their package.json to specify the transforms they want to use.

[TJ Koury]

Thanks for replying.  I should have been more specific in my question:  how do you get all the correct scripts in the right order and compress everything into a single request and send it to the client?  I don't want to use require.js or any other AMD since performance is spotty over mobile networks; I'd rather just patch it all together on the server, compress it, and send it.

[TJ Koury]

Good advice; I've used dependency injection when building shared backbone views that need to initialize different client-side libraries.

I'm not a fan of AMD in general; I think the app should be delivered complete in one request, so that over high-bandwidth/high-latency networks like 3g/4g/lte mobile the experience remains fluid (no waiting for that last library to load).  I guess it depends on your environment.

[tjholowaychuk]

I have to say v2 is quite nice! good job

On Feb 22, 5:43 pm, substack <subst...@gmail.com> wrote:
> browserify v2 was just released! browserify lets you write node-style
> require() calls for browser code so that you can package up your scripts
> and npm modules into a single bundle to serve to browsers. browserify
> implements exactly the node_modules lookup algorithm so you can use many
> libraries written for node and published to npm in the browser without any
> modifications.
>
> Here's the full writeup of the new changes:http://browserify.org/announcing_browserify_v2
> * static module resolution for tinier bundles. Just ~250 bytes of prelude
> now.
> * support for multi-file bundles for multi-page apps and better caching of
> infrequently-updating assets
> * streaming bundle pipeline

> * new "browsers" field support byhttps://github.com/shtylman

[Mikeal Rogers]

we turned on sourcemaps in development mode the other day, so great!

[Aria Stewart]

On April 2, 2013 4:03:23 PM TJ Koury <tjk...@gmail.com> wrote:
> Good advice; I've used dependency injection when building shared backbone
> views that need to initialize different client-side libraries.
> I'm not a fan of AMD in general; I think the app should be delivered
> complete in one request, so that over high-bandwidth/high-latency networks
> like 3g/4g/lte mobile the experience remains fluid (no waiting for that
> last library to load). I guess it depends on your environment.
>

We use AMD modules to make this easier.

[Alexey Petrushin]

I take back my critique of v2, after examining it in details I'm agreed that API became better.

Also, my concern was false, actually it's quite easy to add support for coffee-script and client side templates.

On Saturday, February 23, 2013 4:43:34 AM UTC+4, substack wrote: