Hacker News Reader

Comment by drinchev | Hacker News Reader

Node.js and the community behind it are really great. It helped me put bread on my table for several years now.

I remember I passed through all the "trends" around it and I'm super impressed how fast the ecosystem is evolving.

From browserify to webpack, from grunt to gulp, from coffee-script to typescript. It's never been so exciting.

now all we need is a code-over-configuration replacement for webpack (like gulp was for grunt) and the build system will have evolved from a mess of JSON to a programmable compiler ecosystem. That's pretty cool.

haven't you heard of browserify?

I have, but it's not what I'm talking about. See the comment above re. gulp.

I forgot to mention that these days most of the projects that I see use a combination of webpack and npm scripts. I guess gulp will be obsolete in the next years.

I still think Grunt and Gulp have a place outside of npm scripts for build automation, deployment, and automation of one-off tasks. The fact that Gulp is fully concurrent by default makes IO and environment setup lightning fast. With Electron cross-platform builds especially it takes a lot of the headache out of trying to shim every possible platform configuration into a one-liner.

You can write webpack “config” in JavaScript. It’s already programmable.

Not to mention every loader is programmed...

I’m really not sure what you’re getting at here.

have you used gulp? It allows you to code up a processing pipeline in a pretty intuitive way. Webpack, even though its config is written in JS, is basically magic JSON files. Gulp offers near-total control over the build process which also helps with optimising things like build speed.

Perhaps there is a reason webpack has surpassed gulp in terms of popularity.

Build systems have historically favored declarative configuration over programmability. See Makefiles for an example.

I’m not saying that’s necessarily the right approach, but it does seem like declarative configuration is a natural way to define a build system.

That said, I wholeheartedly agree there is much room for improvement with webpack.

I'd argue that Makefiles are a good argument in favour of programmability, compared to something like Maven which is configurable. Gulp doesn't really play in the same league as webpack as it's not really got the ecosystem, nor is it optimised for, web builds. Declarative config definitely seems to be winning out in terms of popularity but the more configurable you need your build to be, the more the config ends up replicating a programming language anyway - or you end up being locked into restrictive rulesets and patterns, like webpack does.

This is an apple to orange comparison.

Gulp is a tool that lets you decide what the build process should look like.

Webpack is a tool where you define entry points, split points etc., and what you finally need. Based on that webpack decides how to go about the build.

Most of what Gulp does, can be replaced with NPM scripts.

it's the streaming/caching side of gulp that I find most useful to be honest. When I have 3-4 build outputs being generated and I can offload intermediate objects into a cache file and back it can lead to really fast builds. In replacing grunt with gulp and setting up gulp correctly I've reduced builds from 10-15 seconds to nearly instant before, and I think the main failing of webpack is how slow a non-watch build can run, or how large its output size can be. I think entrypoints and code splitting could be achieved with a gulp-like system by picking files to be packaged into different builds.

It's also very easy to find build bottlenecks with gulp which is very handy if you have a large project with a slow build. It allows you to scale out efficiently.

Webpack hot reload server solves this problem and provides nearly instant builds.

Yes, production (“non-watch”) builds can take a while. But who cares? You shouldn’t be running a production build after every code change. That’s why the hot reload server is so useful; it only recompiles the code you changed.

webpack has fairly simple plugin interface you can write a plugin that will hook into anything you want you are basically implementing a single function apply(compiler).

It sounds like what you want exists: it's gulp! If it's useful and makes sense to you, there's no reason to stop using it just because webpack is the hip new thing :)

I assume parent had "convention over configuration" in mind. https://en.wikipedia.org/wiki/Convention_over_configuration

not exactly, although my phrasing doesn't help that impression. I more meant that with webpack you're generating a config object which gets fed into the "webpack engine", where I'd rather have the power of numerous smaller plugins that I can glue together how I please.

It seems to tie into the debate around frameworks vs libraries, or the unix philosophy vs enterprise philosophy too, but that's a whole 'nother thing.

Broccoli (https://github.com/broccolijs/broccoli) has a really nice concept of "trees" that can be split or merged and composed together.

What is your current toolchain in the node ecosystem?

Depends on the project, mostly a combination between

    - npm scripts ( mocha, nyc, tsc, etc... )
    - webpack
    - gulp

Reply on news.ycombinator.com