Bundle pump.js with Browserify #1539
Conversation
See #301, but there's still more work to do.
| path = require("path"); | ||
|
|
||
| var addRoutes = function(app) { | ||
| app.get("/javascript/pump.js", browserify(path.join(__dirname, "../public/javascript/pump.js"))); |
There was a problem hiding this comment.
I think is good idea minified and make a bundle, but is not a good idea for performance make this from the server, you can make the bundle from CLI (with browserify and watchify) in build scripts, also we don's use the commonJs on the client side (dependencies, imports etc) so Browserify adds unnecessary extra code for that.
If the idea is to convert the client side to a commonJs structure I think webpack is more powerful because you can make lazyLoad and other advantages.
Also, you can make the bundle only with UglifyJS2 from CLI without extra code and add some watch task for the development process.
Also, I think is better keep independent the frontEnd process like create bundles, for that reason I closed #1350 also for performance reasons and is similar to browserify-middleware
There was a problem hiding this comment.
also we don's use the commonJs on the client side (dependencies, imports etc) so Browserify adds unnecessary extra code for that
Right, the plan was to switch to using CommonJS since it just makes it so much easier to structure the code. Really not even "easier", but "possible at all".
Re: WebPack, I thought about it, but I like Browserify better for its flexibility and I tend to agree with this assessment by @substack (the author):
I think that longer-term, separability has more benefits from a maintenance and experimentation perspective, but that doesn't mean that you can't do pretty much everything webpack can do in the browserify ecosystem. It just means that there might be several different ways of doing that task to serve different use-cases. Diversity is good!. Diversity means that you can choose an approach that more closely matches the trade-offs that you need, but you might need to put in more work to evaluate the different options.
Also WebPack is famous for having complicated, hard-to-debug/patch/etc. config files.
Also, I think is better keep independent the frontEnd process like create bundles, for that reason I closed #1350 also for performance reasons and is similar to browserify-middleware
That's funny, since that was opened I actually have changed my mind on it and I think caching in memory is probably better, both for contributor experience and for production. Serving from memory is faster and you don't have to rebuild in development. FWIW that's what Express does with compiled templates.
There was a problem hiding this comment.
I was working with Browserify and is pretty cool, the last year work more with webpack and is powerful to manage alias, split by components, lazy load, minified styles, copy fonts/files, configuration by environment etc and webpack is more used right now and is like browserify + gulp.
but a think the browserify-middleware is unnecessary because you only need to make one bundle and you can make this from a CLI simple like:
"build:js": "browserify -g uglifyify public/javascript/pump.js -o public/javascript/dist/pump.min.js",
"watch:js": "watchify public/javascript/pump.js -o public/javascript/dist/pump.js",
also if you will minify styles you should use gulp, webpack or scripts in package.json, so should be a unified solution.
Also with browserify-middleware if you precompile on startup you'll add some delay in the startup (for this reason I closed #1350) or from the response the first time would be slow and more when you add the external libs/modules as dependencies
See #301, but there's still more work to do.