4 ms·

I think Browserify is an excellent tool. It does the one job I generally need it to, importing dependencies so I can write modular JS code. Running it is a one-

I think Browserify is an excellent tool. It does the one job I generally need it to, importing dependencies so I can write modular JS code. Running it is a one-liner, and running it with Babel is one extra option. Its behaviour is reasonably transparent, so you can look at the actual output and see what is really going on even if source maps aren’t helping for whatever reason. Personally, I’m not such a fan of Webpack. It trips my “too complicated” alarm, like RequireJS before it. I’ve never worked on a project that needed the kind of dynamic behaviour these tools support, and you pay a price for that flexibility in the complexity of the tool and the output it produces. Likewise, while you can include almost anything as part of your bundled JS output with Webpack, I’ve seen few real world cases where this is a significant advantage, and again you get locked into Webpack and its complexity as the downside. Perhaps on some types of project the features Webpack offers represent more compelling benefits. For perspective, I’m also not a fan of tools like Gulp, also on the grounds that their ecosystems tend to be fragile and they add unnecessary complexity to what is usually a pretty simply operation in the first place.

s986s 11y ago
I selfishly want more people like you in the javascript ecosystem. I had a debate with a freind if mine about gulp. My argument is that all of these tools are useless since they can be done without them. If only certian tasks should be run, create a commander script that takes in amount of args and runs each of those tasks. His argument is that these gulp and grunt files standardize build and test scripts. Now its something you can definitively check off a list and when looking at others code have a form of familiarity. I personallt agree, complexity and extra wrappers around what is already working makes little sense. But there are reasons these types of frameworks exist
- Chris_Newton 11y ago
  I guess I just don’t see what benefit is gained by writing a dozen lines of fragile boilerplate to run Browserify via Gulp. If you want to put the build automation in a well-known location, a typical Browserify+Babel build is one line in the scripts section in package.json that says something like "js": "browserify src/index.js -o dist/index.js -t [ babelify --presets [ es2015 ] ]" If you need more complicated configuration, you can use separate sections of package.json to set useful defaults, which is also the common convention for build tools in the Node/NPM ecosystem.
  - s986s 11y ago
    Again, I agree. Picture this: mocha gives testing globals, browser offers the window and dom, node offers process arguments. Coming from a partial teachers perspective (well, I wasnt hired to teach but I did talk to the students alot) gulp seemed to offer comfort and order in a world where "you can do anything" seems to cause imobilization. That problem I believe can be solved through introducing students to a philosophy of "you are in control, machines are dumb, only google can save you" but I can see where seperation makes people much more comfortable
- Can_Not 11y ago
  > My argument is that all of these tools are useless since they can be done without them. My gulpfile.js minifies several application modules and 3rd party libraries into a small set of modular, organized files. A polyfill is included. ES7 is converted to ES5. Bootstrap 2 libraries are upconverted to BS3. BS2 icons and BS3 glyphicons are converted to font awesome. Image URIs are transformed/replaced on disk dynamically and in CSS/JS references to my modular preferences. Public access keys (rollbar, stripe, etc.) are injected into my builds from .env variables. Tiny changes can be injected into libraries until the maintainence cost of a fork becomes less than the cost of a replace. This script can be called with one command, this script's submodules can be called individually. The full command is mulithreaded. Perhaps the issue is not that these actions can technically be done without a build tool, but that you don't use any of the advanced functionality these tools were built to automate?
neoeldex 11y ago
I think when comparing grunt and gulp to webpack, that they solve different issues. grunt gets complicated easily, by including a bunch of plugins and defining their configuration in a declarative manner. Gulp solves those issues by letting the user determine how to configure it himself, so the user can load in the package.json to load constants. While webpack also does that, It imo has a more sensible definition. Instead of the grunt/gulp approach, where you would say, do these actions with this folder, and this with that folder; webpack allows you to say, "if it's a jsx file: do this, and it's extension becomes: .js" There's a lot less configuration needed for projects involving webpack, because it just lets you define transforms. Usually everything is turned into js (including images/css). But it also allows you to expose some files in the output to be loaded externally. So there's no more 'gulp task' to run, now I'm just using npm scripts (npm start, npm run build, enz)

s986s 11y ago

I selfishly want more people like you in the javascript ecosystem. I had a debate with a freind if mine about gulp. My argument is that all of these tools are useless since they can be done without them. If only certian tasks should be run, create a commander script that takes in amount of args and runs each of those tasks. His argument is that these gulp and grunt files standardize build and test scripts. Now its something you can definitively check off a list and when looking at others code have a form of familiarity. I personallt agree, complexity and extra wrappers around what is already working makes little sense. But there are reasons these types of frameworks exist

Chris_Newton 11y ago
I guess I just don’t see what benefit is gained by writing a dozen lines of fragile boilerplate to run Browserify via Gulp. If you want to put the build automation in a well-known location, a typical Browserify+Babel build is one line in the scripts section in package.json that says something like "js": "browserify src/index.js -o dist/index.js -t [ babelify --presets [ es2015 ] ]" If you need more complicated configuration, you can use separate sections of package.json to set useful defaults, which is also the common convention for build tools in the Node/NPM ecosystem.
- s986s 11y ago
  Again, I agree. Picture this: mocha gives testing globals, browser offers the window and dom, node offers process arguments. Coming from a partial teachers perspective (well, I wasnt hired to teach but I did talk to the students alot) gulp seemed to offer comfort and order in a world where "you can do anything" seems to cause imobilization. That problem I believe can be solved through introducing students to a philosophy of "you are in control, machines are dumb, only google can save you" but I can see where seperation makes people much more comfortable
Can_Not 11y ago
> My argument is that all of these tools are useless since they can be done without them. My gulpfile.js minifies several application modules and 3rd party libraries into a small set of modular, organized files. A polyfill is included. ES7 is converted to ES5. Bootstrap 2 libraries are upconverted to BS3. BS2 icons and BS3 glyphicons are converted to font awesome. Image URIs are transformed/replaced on disk dynamically and in CSS/JS references to my modular preferences. Public access keys (rollbar, stripe, etc.) are injected into my builds from .env variables. Tiny changes can be injected into libraries until the maintainence cost of a fork becomes less than the cost of a replace. This script can be called with one command, this script's submodules can be called individually. The full command is mulithreaded. Perhaps the issue is not that these actions can technically be done without a build tool, but that you don't use any of the advanced functionality these tools were built to automate?

neoeldex 11y ago

I think when comparing grunt and gulp to webpack, that they solve different issues. grunt gets complicated easily, by including a bunch of plugins and defining their configuration in a declarative manner. Gulp solves those issues by letting the user determine how to configure it himself, so the user can load in the package.json to load constants. While webpack also does that, It imo has a more sensible definition. Instead of the grunt/gulp approach, where you would say, do these actions with this folder, and this with that folder; webpack allows you to say, "if it's a jsx file: do this, and it's extension becomes: .js" There's a lot less configuration needed for projects involving webpack, because it just lets you define transforms. Usually everything is turned into js (including images/css). But it also allows you to expose some files in the output to be loaded externally. So there's no more 'gulp task' to run, now I'm just using npm scripts (npm start, npm run build, enz)