11 ms·

Obsolete before it hit 1.0. While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the to

by igl 11y ago

Obsolete before it hit 1.0. While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the tons of dev-dependencies. Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.

chadscira 11y ago
Totally agree, the key was loaders...
scotty79 11y ago
I don't regret learning gulp. Node streams are bizarre, interesting construct and I'd probably had no chance to touch them but gulp made me understand them to the minute detail.
nailer 11y ago
One thing this dissuaded me from webpack is that it markets itself on support for AMD and script tags - if you need JS modules that are only available as AMD or script tags in 2016 it's a worry. That said, I use gulp now and a notice lot of gulp seems to be replicating parts of JS itself - tasks are just functions, I don't see why they need to be special. There's always 'gulp foo' which is a less maintained wrapper around 'foo'. And browserify seems slow to build bundles - is webpack any faster?
- Ciantic 11y ago
  Markets itself with support for AMD and script tags? What are you talking about, it's all about bundling things automatically without script tags, you don't even need to write the damned html file if you use loader for it. Also it may have support for AMD, but it's key usage is to bundle libraries from npm using commonjs. I'm not saying webpack is all roses (even in version 2), but these two things are not the issue.
  - nailer 11y ago
    You misunderstand what I meant. Nobody has written or suggested that webpack outputs script tags or AMD. I simply stated that webpack markets itself as using script tags and AMD as input, which is true: from the meta description on webpack.github.io: "Webpack is a module bundler. It packs CommonJs/AMD modules i. e. for the browser" If you use AMD as input you have to get updates to your libraries separately, and your libraries are bloated since AMD modules tend to use dependencies less. You should also check out https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
    - pcr0 11y ago
      Where does it say it uses script tags for input? The quote you mention says CommonJS/AMD. CommonJS is the de-facto standard these days. Typically, people write in ES6 imports, which then gets transpiled to CommonJS anyway. It accepts AMD as an option, but honestly, I've been using webpack for about a month and I haven't come across a single library that recommends using AMD. It's just there as an option for those who need it. Most of the world has moved on from AMD due to its issues, so I can't really see your point.
      - nailer 11y ago
        You admit most of the world had moved on from AMD, but don't see why advertising AMD support as a main feature - to the point it's mentioned in the sites description - would dissuade people? Being able to shim script tag libraries is mentioned in various places through the docs (and used to be even more prominent than it is now). I'm responding out of charity here: you made an angry response, were shown to have misread the post, and haven't apologised. Be civil.
        Ciantic 11y ago
        Mr. that was not my reply, and I didn't made a angry response... If you thought my characters conveyed angryness I apologize, I just critcized your points.
- deleted 11y ago
  [deleted]
aidos 11y ago
I went through this in the last couple of weeks. After about a week of infuriating behaviour trying to get gulp/grunt working even remotely how I wanted (eg vendor stuff split so builds don't take 10 seconds) I decided to give webpack a shot. For anyone else in this position, sorry to the gulp/grunt guys, but skip them - go straight for webpack. It's still taken a lot of work to get a config that works nicely for my usecase, but all in all the experience was really good and I was 80% of the way there in no time at all.
DiabloD3 11y ago
Grunt was nasty as hell, and clearly didn't learn any of the lessons from, say, proper Makefiles from the UNIX world over the past 30 years. Gulp is a looooot better, especially when I have things like Foundation 6's zurb-template, which is basically configured out of the box how I setup my Foundation 5 era projects. I don't care how big a Gulp file is if I'm not the one having to do major maintenance on it.
- laichzeit0 11y ago
  This is what I don't get. Do authors of these build tools actually sit down for a couple of months looking at things like Makefiles that have been around forever, perhaps even Maven, etc. Take all these things together and go "This is what sucks in all of them, and here's how we can do it better" and still cater for all the use cases that these tools are brilliant at. It's like there's no thought put into these tools and nothing is built on computer science foundations. Like why are you using Json as the syntax? Ant build files were an abomination and Json really isn't offering anything better (actually way less), except a slightly more readable syntax for trivial use cases.
  - oblio 11y ago
    I think not even Node or NPM learned any lessons from older tools. Look at the recent leftpad fiasco. A decent part of it could have been avoided with namespacing (hello Maven groupIds!). npm didn't have it from day 1 and even now it's optional and basically unused.
  - k__ 11y ago
    Haha, yes. When I saw that LiveScript was using Makefiles[0] to build, I was baffled. To me they were ancient and complicated C/C++ stuff. But when I looked into them, everything seemed rather straight forward, even a bit nicer than Gulp, because of the syntax. [0] https://github.com/gkz/LiveScript/blob/master/Makefile
    - wmil 11y ago
      Makefiles have some glaring issues that can't be easily fixed. The big one is that they break if there are spaces in file or directory names. Sure, you can argue spaces are bad practice. But they are common on OS X and windows. It's a little silly to use a build system that doesn't support them.
rkwz 11y ago
The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time. The docs are very basic and there are so many configuration params. If you want to do something that's not covered in tutorials or boilerplates, be prepared to spend a ridiculous amount of time reading Webpack PRs, issues and the codebase. Webpack does a great job and it's a nice concept but it has very bad documentation. [1] Isomorphic apps, or multiple builds for i18n etc
- amelius 11y ago
  > The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time. I really hate systems that are built like that. Nobody should build software like that. I just want simple tools with a clear API that I can combine together and easily replace by other tools, like in the Unix tradition. I guess it is a case of "LEGO versus Playmobil". The former allows modularity, while the latter is just complex crap that allows you to do nothing other than what the instructions say.
  - igl 11y ago
    Webpack does not glob-search against the filesystem like grunt/gulp/brunch/broccoli/make. If you look for that: Sorry, webpack does not "replace" simple tools like that. Think of it as a tool executing require.extensions at build time. It's not operating on files as much as it's looking directly at the source-code AST. That makes it more complex to get into over the glob tools but it's worth it. It's also just as modular as anything else: http://npmsearch.com/?q=loader%20AND%20keywords:webpack http://npmsearch.com/?q=loader%20AND%20keywords:webpack
- johnieeboy 11y ago
  Funny enough, if you look at the comments for pretty much the landing page of web pack you get the same sentiment http://webpack.github.io/docs/what-is-webpack.html http://webpack.github.io/docs/what-is-webpack.html
uhtred 11y ago
Holy crap! I left a company 6 months ago and we were using Gulp there, and it was, as far as I am aware, the hot thing to use (I'm no front-end dev). Now you're telling me it is obsolete?! Javascript world is silly.
- Akkuma 11y ago
  It isn't obsolete. Webpack just reduces task runners even more, since webpack takes care of taking your source, copying your source to your build/dist/whatever directory, minifying everything, creating hashes in filenames, being able to update html with those hash names, etc.. Basically, if you can use `import` on a file in Webpack 2 or `require` in either Webpack 1/2 you don't need Gulp/Grunt to do that work. I personally work on things that still need other aspects of the task runners.
- splintercell 11y ago
  I am sorry but if someone told me that the product which came out yesterday is obsolete then I'd understand that Javascript world is silly, but if at your company a product which was popular 3 years ago cool, then it's your company's fault.
  - biot 11y ago
    Javascript was popular 3 years ago. What new, cool thing have you moved on to?
Cthulhu_ 11y ago
The 800 lines are you or your team's own fault; it's just a file run in NodeJS, it's trivial to separate it in task-specific files and load them with either `require` or one of the `loader` projects. Build tooling (what Grunt is) configuration, maintenance and maintainability is also the responsibility of developers. Of course, the async thing (and such) is something I agree with, newer tooling has iterated and improved on Grunt.
drinchev 11y ago
Not everything is covered by webpack. And also you just replaced huge configuration with another huge configuration. Webpack is amazing tool, but it's not a task runner like gulp.

by igl 11y ago

chadscira 11y ago

Totally agree, the key was loaders...

scotty79 11y ago

I don't regret learning gulp. Node streams are bizarre, interesting construct and I'd probably had no chance to touch them but gulp made me understand them to the minute detail.

nailer 11y ago

One thing this dissuaded me from webpack is that it markets itself on support for AMD and script tags - if you need JS modules that are only available as AMD or script tags in 2016 it's a worry. That said, I use gulp now and a notice lot of gulp seems to be replicating parts of JS itself - tasks are just functions, I don't see why they need to be special. There's always 'gulp foo' which is a less maintained wrapper around 'foo'. And browserify seems slow to build bundles - is webpack any faster?

Ciantic 11y ago
Markets itself with support for AMD and script tags? What are you talking about, it's all about bundling things automatically without script tags, you don't even need to write the damned html file if you use loader for it. Also it may have support for AMD, but it's key usage is to bundle libraries from npm using commonjs. I'm not saying webpack is all roses (even in version 2), but these two things are not the issue.
- nailer 11y ago
  You misunderstand what I meant. Nobody has written or suggested that webpack outputs script tags or AMD. I simply stated that webpack markets itself as using script tags and AMD as input, which is true: from the meta description on webpack.github.io: "Webpack is a module bundler. It packs CommonJs/AMD modules i. e. for the browser" If you use AMD as input you have to get updates to your libraries separately, and your libraries are bloated since AMD modules tend to use dependencies less. You should also check out https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
  - pcr0 11y ago
    Where does it say it uses script tags for input? The quote you mention says CommonJS/AMD. CommonJS is the de-facto standard these days. Typically, people write in ES6 imports, which then gets transpiled to CommonJS anyway. It accepts AMD as an option, but honestly, I've been using webpack for about a month and I haven't come across a single library that recommends using AMD. It's just there as an option for those who need it. Most of the world has moved on from AMD due to its issues, so I can't really see your point.
    - nailer 11y ago
      You admit most of the world had moved on from AMD, but don't see why advertising AMD support as a main feature - to the point it's mentioned in the sites description - would dissuade people? Being able to shim script tag libraries is mentioned in various places through the docs (and used to be even more prominent than it is now). I'm responding out of charity here: you made an angry response, were shown to have misread the post, and haven't apologised. Be civil.
      - Ciantic 11y ago
        Mr. that was not my reply, and I didn't made a angry response... If you thought my characters conveyed angryness I apologize, I just critcized your points.
deleted 11y ago
[deleted]

aidos 11y ago

I went through this in the last couple of weeks. After about a week of infuriating behaviour trying to get gulp/grunt working even remotely how I wanted (eg vendor stuff split so builds don't take 10 seconds) I decided to give webpack a shot. For anyone else in this position, sorry to the gulp/grunt guys, but skip them - go straight for webpack. It's still taken a lot of work to get a config that works nicely for my usecase, but all in all the experience was really good and I was 80% of the way there in no time at all.

DiabloD3 11y ago

Grunt was nasty as hell, and clearly didn't learn any of the lessons from, say, proper Makefiles from the UNIX world over the past 30 years. Gulp is a looooot better, especially when I have things like Foundation 6's zurb-template, which is basically configured out of the box how I setup my Foundation 5 era projects. I don't care how big a Gulp file is if I'm not the one having to do major maintenance on it.

laichzeit0 11y ago
This is what I don't get. Do authors of these build tools actually sit down for a couple of months looking at things like Makefiles that have been around forever, perhaps even Maven, etc. Take all these things together and go "This is what sucks in all of them, and here's how we can do it better" and still cater for all the use cases that these tools are brilliant at. It's like there's no thought put into these tools and nothing is built on computer science foundations. Like why are you using Json as the syntax? Ant build files were an abomination and Json really isn't offering anything better (actually way less), except a slightly more readable syntax for trivial use cases.
- oblio 11y ago
  I think not even Node or NPM learned any lessons from older tools. Look at the recent leftpad fiasco. A decent part of it could have been avoided with namespacing (hello Maven groupIds!). npm didn't have it from day 1 and even now it's optional and basically unused.
- k__ 11y ago
  Haha, yes. When I saw that LiveScript was using Makefiles[0] to build, I was baffled. To me they were ancient and complicated C/C++ stuff. But when I looked into them, everything seemed rather straight forward, even a bit nicer than Gulp, because of the syntax. [0] https://github.com/gkz/LiveScript/blob/master/Makefile
  - wmil 11y ago
    Makefiles have some glaring issues that can't be easily fixed. The big one is that they break if there are spaces in file or directory names. Sure, you can argue spaces are bad practice. But they are common on OS X and windows. It's a little silly to use a build system that doesn't support them.

rkwz 11y ago

The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time. The docs are very basic and there are so many configuration params. If you want to do something that's not covered in tutorials or boilerplates, be prepared to spend a ridiculous amount of time reading Webpack PRs, issues and the codebase. Webpack does a great job and it's a nice concept but it has very bad documentation. [1] Isomorphic apps, or multiple builds for i18n etc

amelius 11y ago
> The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time. I really hate systems that are built like that. Nobody should build software like that. I just want simple tools with a clear API that I can combine together and easily replace by other tools, like in the Unix tradition. I guess it is a case of "LEGO versus Playmobil". The former allows modularity, while the latter is just complex crap that allows you to do nothing other than what the instructions say.
- igl 11y ago
  Webpack does not glob-search against the filesystem like grunt/gulp/brunch/broccoli/make. If you look for that: Sorry, webpack does not "replace" simple tools like that. Think of it as a tool executing require.extensions at build time. It's not operating on files as much as it's looking directly at the source-code AST. That makes it more complex to get into over the glob tools but it's worth it. It's also just as modular as anything else: http://npmsearch.com/?q=loader%20AND%20keywords:webpack http://npmsearch.com/?q=loader%20AND%20keywords:webpack
johnieeboy 11y ago
Funny enough, if you look at the comments for pretty much the landing page of web pack you get the same sentiment http://webpack.github.io/docs/what-is-webpack.html http://webpack.github.io/docs/what-is-webpack.html

uhtred 11y ago

Holy crap! I left a company 6 months ago and we were using Gulp there, and it was, as far as I am aware, the hot thing to use (I'm no front-end dev). Now you're telling me it is obsolete?! Javascript world is silly.

Akkuma 11y ago
It isn't obsolete. Webpack just reduces task runners even more, since webpack takes care of taking your source, copying your source to your build/dist/whatever directory, minifying everything, creating hashes in filenames, being able to update html with those hash names, etc.. Basically, if you can use `import` on a file in Webpack 2 or `require` in either Webpack 1/2 you don't need Gulp/Grunt to do that work. I personally work on things that still need other aspects of the task runners.
splintercell 11y ago
I am sorry but if someone told me that the product which came out yesterday is obsolete then I'd understand that Javascript world is silly, but if at your company a product which was popular 3 years ago cool, then it's your company's fault.
- biot 11y ago
  Javascript was popular 3 years ago. What new, cool thing have you moved on to?

Cthulhu_ 11y ago

The 800 lines are you or your team's own fault; it's just a file run in NodeJS, it's trivial to separate it in task-specific files and load them with either `require` or one of the `loader` projects. Build tooling (what Grunt is) configuration, maintenance and maintainability is also the responsibility of developers. Of course, the async thing (and such) is something I agree with, newer tooling has iterated and improved on Grunt.

drinchev 11y ago

Not everything is covered by webpack. And also you just replaced huge configuration with another huge configuration. Webpack is amazing tool, but it's not a task runner like gulp.