11 ms·

Personally found Webpack to be really heavy handed for what most developers need it for. Gulp on the other hand seemed easier to just build exactly what you nee

Personally found Webpack to be really heavy handed for what most developers need it for. Gulp on the other hand seemed easier to just build exactly what you need. Webpack felt like an overly complicated poorly documented black box that seemed to work by sifting through github issues and comments. You spend 2 days getting it into some semblance of a working state, and never touch it for fear of introducing a new issue. Gulp just...worked, and with very little fuss. Sadly React seemed tightly tied to webpack so if you want React you're tied to that toolchain. In general I think tooling needs to improve, and neither Webpack nor Gulp are painless. Neither is maven, I suppose...

codefined 9y ago
I'm not sure, my opinion of Webpack is completely different. We used a ~20 line configuration file found on Gist to replace our ~400 line gulp build. It resulted in better optimisation, less hassle and "Just Worked™". We wanted to add a few more things to our configuration, literally just took running `npm install some_package`, followed by requiring it in the webpack configuration.
- inimino 9y ago
  > a ~20 line configuration file found on Gist Having to find it on gist because the official documentation is so lacking that nobody can figure out how to configure the thing except by following examples is the main problem that leads people to fear webpack configuration and to cargo cult magical config files that they are afraid to touch. Mature tools can be understood in principle and configured without needing to see "how someone else did it."
  - ggregoire 9y ago
    The recent rewrite of the doc seems pretty clear and straightforward to me. Did you take a look at it? I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.
    - porker 9y ago
      > I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again. And that's a valid audience for the tool. Good documentation would support this audience too, with plenty of examples and recipes. Even a repository of documented common use-cases (which must exist for Webpack's automated testing, right?)
    - jazoom 9y ago
      It's much much better, but still not very clear in many places. Just the other day I was struggling to figure out what some magical terms were referring to.
    - bryanrasmussen 9y ago
      I looked at the documentation the last time there was one of these complaints about webpack threads, the usage and benefits of loaders, plugins and modules seemed hard to understand as opposed to gulp where you just have a pipe. I don't care if I can just plop a simple webpack without thinking in and it will handle everything I need, because I will always need more - and besides which I have my own gulp files I can just plop in without thinking too because I wrote them and I know exactly what will happen.
  - shados 9y ago
    Thats surprising to me. Even the originally 1.X documentation wasn't that bad for the common cases. The 2.X documentation is pretty darn good. The only issues I hit back then was complex cases back in the 1.X days. But if all you wanted was an app with prod/development mode that compiled javascript, css, let you import assets, minify in production and hash file names for long term caching, it's pretty simple considering everyone wants these to work slightly differently.
  - MadcapJake 9y ago
    > Mature tools can be understood in principle and configured without needing to see "how someone else did it." I don't know a more "understood in principle" tool than Webpack. There are no magical invocations just `webpack` and you are done. Plugins are usually just a require and adding to your plugins array. I also think the maturity of a tool is in being easily understood just by reviewing someone else's config. To me, that speaks volumes for how simple and easy it is to get up and running in webpack.
- hungerstrike 9y ago
  I’ve been able to do everything I want to with create-react-app which uses webpack internally, giving you a zero configuration experience. With async import I am able to do code splitting. With react-intl-cra I can pull formatted messages out of my code. I had to add a grunt file to compile LESS into src, but it was easy to integrate with my package.json scripts.
  - moltar 9y ago
    The fact that you had to add grunt, the grandfather of webpack, speaks volumes. Why didn’t you just configure wp to compile less?
    - adregan 9y ago
      That has less to do with webpack and more to do with create-react-app which doesn't allow you to modify the webpack config. The gp didn't really need to use gulp, you can compile less with package.json scripts.
    - shados 9y ago
      As mentioned, create-react-app doesnt let you configrue anything (ok, almost anything), and doesn't support LESS/Sass by design. Though you usually don't even need that much. Just using the node-sass or less compilers directly usually work fine. Or use something like Glamor or Styled Components to punt on the problem altogether.
  - epicide 9y ago
    Using this should make WebPack work with LESS files. I'm no expert, but my understanding is that this says "for all files matching *.less, run them through the CSS and LESS loaders, then use the Extract Text Plugin" (which pulls things into their own file; you'll need to configure it in the plugins). {test: /\.less$/i, use: ExtractTextPlugin.extract(['css-loader', 'less-loader'])} Edit: forgot a brace.
    - hungerstrike 9y ago
      Thanks! One thing - I'm not using WebPack directly and indeed, I have no access to the WebPack configuration because Create-React-App hides all of that from me. I can eject the app from Create-React-App and get a normal WebPack project, but I won't do that unless it's absolutely necessary because the huge community of Create-React-App devs are taking care of my config for me.
- bryanrasmussen 9y ago
  Any ambitious project is sooner or later going to have to delve into their tooling, and not depend on examples they found of things that work. I admit it's nice you found something that worked exactly as you wanted, and my experience is I can often find what I want exactly when I start but sooner or later you need to add to it. And then things start to get less pleasant.
chrisco255 9y ago
People use Webpack because it gives you easy access to NPM, understands module dependency graph and through various plugins, can optimize your code with features like lazy loading, tree shaking, etc. These are things you don't get with Gulp.
nerdwaller 9y ago
Have you tried webpack since the 2.0 launch? I felt the exact same way as you, but recently went through their tutorial/docs and was able to get a pretty good (and simple) setup without much fuss at all - a dev build, webpack dev server, and prod build. I’m only a short bit into actually proving it out for myself, but so far I was surprised since my first experience being quite negative too.
13years 9y ago
I started with Webpack, but just recently I'm trying Fusebox and so far liking it much better as well.
fenomas 9y ago
Webpack is a dependency-wrangler. If you're using it as a task-runner like Gulp, you may not need it at all. Personally I use then together - Gulp runs the tasks, one of which is bundling, which gets done by webpack. Of the two gulp was way harder to get working, for me at least.
- jessaustin 9y ago
  ...you may not need it at all. Yeah npm can run tasks by itself just fine.
  - lexicality 9y ago
    Sure, as long as you can express your entire pipeline as a single shell statement and don't care about Windows.
    - bmarkovic 9y ago
      Does anyone? Doing web dev on Windows means exposing yourself to a world of pain, which is why most are on MacOs or Linux anyway.
      - lexicality 9y ago
        Sure. I do, and I'm sure most people in big corps do too. All modern high level languages have very good cross-platform system libraries and build tools for those languages usually use that language to run. Occasionally you'll run into someone that's still using Makefiles and have to break out msys but other than that it's generally fine.
      - moron4hire 9y ago
        A world of pain? I've had much more painful experiences trying to get Ruby on Rails setup on a new MacBook.
        nobleach 9y ago
shriek 9y ago
The document seems to have gotten a little better, lot better than Webpack 1, however the plugin ecosystem is the most frustrating part imo. Webpack gives plugin creator some form of freedom and because of that, and the lack of types in JS, you're at the mercy of proper docs on the plugins you're relying on. Either that or go through the source code to find out what the heck is even accepted as options.
- thelarkinn 9y ago
  We heard this feedback infact and we wrote the entire plugin system for webpack 4! (https://github.com/webpack/tapable https://github.com/webpack/tapable). Take a look at the only PR open which is us working to provide the best Type system possible for our new API (which was infact designed to support it). Even better is that you can find all the "hooks" on an instance by doing `compiler.hooks` so now you get a far better authoring experience :-D
  - jblg 9y ago
    Would be better if Webpack had defaults that just worked out of the box without configuration.
  - shriek 9y ago
    That's awesome. I haven't played with webpack 4 yet. Just recently started playing with webpack 3. I'd be keeping an eye on it.
md224 9y ago
Curious what people think of Neutrino as a solution for Webpack's complexity: https://neutrino.js.org https://neutrino.js.org
- jorblumesea 9y ago
  That is fantastic, on first glance it seems exactly what is needed. I just think it's unfortunate that the tool needed someone to develop another tool to make it truly usable. Good software should be simple to use and configure, not dense and opaque.
  - marksomnian 9y ago
    I don't think it's unfortunate, I think it's a good abstraction. Webpack being a lower-level tool wrapped by Neutrino. Similarly to git's plumbing and porcelain separation.
jacobwg 9y ago
There has been some recent buzz around https://parceljs.org/ https://parceljs.org/, which aims to also "just work" with minimal configuration.
- thelarkinn 9y ago
  At what cost :-D
thelarkinn 9y ago
Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe it's been awhile since you have taken a look at our documentation! (webpack.js.org)! I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does. In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible. Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack). Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3. So if you have great ideas, please let me know. :-D
- shados 9y ago
  > In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download Man I wish it was easier to convince people of this. I'm fighting with some teams at work who are shipping 2mb+ compressed with several seconds just for parse time...and all of the webpack tooling and features are needed just to keep it there (when it should be used to bring it down within that 200kbish threshold). And they feel its normal.
hesarenu 9y ago
I have active projects using browersify with reactjs. It's not tightly tied to webpack.
manigandham 9y ago
It's really not difficult, it just looks more complicated than it is. If you want a good start, try the Webpack book by SurviveJS. You can read most of it in an hour or two and not only create a config but actually understand how webpack works: https://survivejs.com/webpack/introduction/ https://survivejs.com/webpack/introduction/ There are also slimmer/newer/zero config alternatives like: https://poi.js.org/ https://poi.js.org/ https://neutrino.js.org/ https://neutrino.js.org/ https://parceljs.org https://parceljs.org
bmarkovic 9y ago
I haven't used Webpack prior to 2.x and Gulp was my preferred option previously as Grunt really was a clusterfuck, but Webpack setups come with batteries included and small extensions to it you need to add are often easy. That's my limited experience anyhow. The only tool I rooted for (but is still behind the curve) is Brunch.
hazza1 9y ago
My webpack configs are a magnitude smaller than the equivalent gulp ones. React really isn't tied to webpack - babel maybe. If you're just using webpack for the basic functionally of babel automation and es6 import resolution it's trivial to setup but probably not the best tool for the job.
frik 9y ago
Good that plain JavaScript 5/6 with no framework is still in the top 2 in all related charts. Looking back how many frameworks came and went dodo, I am using only small libraries and stay with plain vanilla JS 5/6. Writing modern JS is a peace of cake, it's better to understand 100% of the codebase than to use way too much magic APIs. (well I understand the whole computer, all layers, from hardware to operating system, to software - so there is no magic for me, that helps a lot)
lucideer 9y ago
React is definitely in no way tied to Webpack. Slightly tied to babel presuming you're using JSX, as everyone is, but otherwise it's extremely easy to use any other tool. I've built pipelines with rollup and browserify, both which have problems and I'm not entirely happy with but I found an improvement over webpack.
tjholowaychuk 9y ago
https://neutrino.js.org/ https://neutrino.js.org/ is my go-to, I have no gripes with Webpack as a technology, but I don't think it's what people should use on a daily basis abstraction-wise.
mnutt 9y ago
I evaluated webpack recently and found that it worked fine for straightforward projects but the more customized I wanted it the more issues I ran into.[0] I think it’s a matter of configuration as json vs configuration as code. Webpack had all of the component pieces I needed, but they were glued together in ways that I couldn’t compose them. I ended up using rollup, which was a bit better but I still yearn for the composability of Broccoli. [0] My project allowed users to have a single JS file that would be able to `import` npm modules and the have the bundler compile all of the dependencies into a single tree-shaken vendor.js, while modifying the main file’s imports to be human-readable es5. Webpack’s es6 import code was tightly coupled to the format of its output.
epicide 9y ago
I definitely went through the pain of trying to set up Webpack 1.x on a large project. The documentation was probably the worst part (it was adequate as a reference, but really assumed you already knew some of the fairly complex topics). I also recently went through the process of refactoring our build to use Webpack 3.8. The documentation is a LOT better. Their introductory docs especially. I feel like I finally understand parts of WP 1.x after reading the 2.x/3.x docs. Gulp and Webpack really are two separate things. Gulp is basically like Ant had a baby with NPM scripts. Webpack is closer to Maven, but Maven really tries to do a LOT more. For any project, start with NPM scripts for your task running, then include gulp if/when you actually need them. Same goes with Webpack: don't include it in every project just because you think you might need it eventually.
deleted 9y ago
[deleted]

codefined 9y ago

I'm not sure, my opinion of Webpack is completely different. We used a ~20 line configuration file found on Gist to replace our ~400 line gulp build. It resulted in better optimisation, less hassle and "Just Worked™". We wanted to add a few more things to our configuration, literally just took running `npm install some_package`, followed by requiring it in the webpack configuration.

inimino 9y ago
> a ~20 line configuration file found on Gist Having to find it on gist because the official documentation is so lacking that nobody can figure out how to configure the thing except by following examples is the main problem that leads people to fear webpack configuration and to cargo cult magical config files that they are afraid to touch. Mature tools can be understood in principle and configured without needing to see "how someone else did it."
- ggregoire 9y ago
  The recent rewrite of the doc seems pretty clear and straightforward to me. Did you take a look at it? I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.
  - porker 9y ago
    > I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again. And that's a valid audience for the tool. Good documentation would support this audience too, with plenty of examples and recipes. Even a repository of documented common use-cases (which must exist for Webpack's automated testing, right?)
  - jazoom 9y ago
    It's much much better, but still not very clear in many places. Just the other day I was struggling to figure out what some magical terms were referring to.
  - bryanrasmussen 9y ago
    I looked at the documentation the last time there was one of these complaints about webpack threads, the usage and benefits of loaders, plugins and modules seemed hard to understand as opposed to gulp where you just have a pipe. I don't care if I can just plop a simple webpack without thinking in and it will handle everything I need, because I will always need more - and besides which I have my own gulp files I can just plop in without thinking too because I wrote them and I know exactly what will happen.
- shados 9y ago
  Thats surprising to me. Even the originally 1.X documentation wasn't that bad for the common cases. The 2.X documentation is pretty darn good. The only issues I hit back then was complex cases back in the 1.X days. But if all you wanted was an app with prod/development mode that compiled javascript, css, let you import assets, minify in production and hash file names for long term caching, it's pretty simple considering everyone wants these to work slightly differently.
- MadcapJake 9y ago
  > Mature tools can be understood in principle and configured without needing to see "how someone else did it." I don't know a more "understood in principle" tool than Webpack. There are no magical invocations just `webpack` and you are done. Plugins are usually just a require and adding to your plugins array. I also think the maturity of a tool is in being easily understood just by reviewing someone else's config. To me, that speaks volumes for how simple and easy it is to get up and running in webpack.
hungerstrike 9y ago
I’ve been able to do everything I want to with create-react-app which uses webpack internally, giving you a zero configuration experience. With async import I am able to do code splitting. With react-intl-cra I can pull formatted messages out of my code. I had to add a grunt file to compile LESS into src, but it was easy to integrate with my package.json scripts.
- moltar 9y ago
  The fact that you had to add grunt, the grandfather of webpack, speaks volumes. Why didn’t you just configure wp to compile less?
  - adregan 9y ago
    That has less to do with webpack and more to do with create-react-app which doesn't allow you to modify the webpack config. The gp didn't really need to use gulp, you can compile less with package.json scripts.
  - shados 9y ago
    As mentioned, create-react-app doesnt let you configrue anything (ok, almost anything), and doesn't support LESS/Sass by design. Though you usually don't even need that much. Just using the node-sass or less compilers directly usually work fine. Or use something like Glamor or Styled Components to punt on the problem altogether.
- epicide 9y ago
  Using this should make WebPack work with LESS files. I'm no expert, but my understanding is that this says "for all files matching *.less, run them through the CSS and LESS loaders, then use the Extract Text Plugin" (which pulls things into their own file; you'll need to configure it in the plugins). {test: /\.less$/i, use: ExtractTextPlugin.extract(['css-loader', 'less-loader'])} Edit: forgot a brace.
  - hungerstrike 9y ago
    Thanks! One thing - I'm not using WebPack directly and indeed, I have no access to the WebPack configuration because Create-React-App hides all of that from me. I can eject the app from Create-React-App and get a normal WebPack project, but I won't do that unless it's absolutely necessary because the huge community of Create-React-App devs are taking care of my config for me.
bryanrasmussen 9y ago
Any ambitious project is sooner or later going to have to delve into their tooling, and not depend on examples they found of things that work. I admit it's nice you found something that worked exactly as you wanted, and my experience is I can often find what I want exactly when I start but sooner or later you need to add to it. And then things start to get less pleasant.

chrisco255 9y ago

People use Webpack because it gives you easy access to NPM, understands module dependency graph and through various plugins, can optimize your code with features like lazy loading, tree shaking, etc. These are things you don't get with Gulp.

nerdwaller 9y ago

Have you tried webpack since the 2.0 launch? I felt the exact same way as you, but recently went through their tutorial/docs and was able to get a pretty good (and simple) setup without much fuss at all - a dev build, webpack dev server, and prod build. I’m only a short bit into actually proving it out for myself, but so far I was surprised since my first experience being quite negative too.

13years 9y ago

I started with Webpack, but just recently I'm trying Fusebox and so far liking it much better as well.

fenomas 9y ago

Webpack is a dependency-wrangler. If you're using it as a task-runner like Gulp, you may not need it at all. Personally I use then together - Gulp runs the tasks, one of which is bundling, which gets done by webpack. Of the two gulp was way harder to get working, for me at least.

jessaustin 9y ago
...you may not need it at all. Yeah npm can run tasks by itself just fine.
- lexicality 9y ago
  Sure, as long as you can express your entire pipeline as a single shell statement and don't care about Windows.
  - bmarkovic 9y ago
    Does anyone? Doing web dev on Windows means exposing yourself to a world of pain, which is why most are on MacOs or Linux anyway.
    - lexicality 9y ago
      Sure. I do, and I'm sure most people in big corps do too. All modern high level languages have very good cross-platform system libraries and build tools for those languages usually use that language to run. Occasionally you'll run into someone that's still using Makefiles and have to break out msys but other than that it's generally fine.
    - moron4hire 9y ago
      A world of pain? I've had much more painful experiences trying to get Ruby on Rails setup on a new MacBook.
      - nobleach 9y ago

shriek 9y ago

The document seems to have gotten a little better, lot better than Webpack 1, however the plugin ecosystem is the most frustrating part imo. Webpack gives plugin creator some form of freedom and because of that, and the lack of types in JS, you're at the mercy of proper docs on the plugins you're relying on. Either that or go through the source code to find out what the heck is even accepted as options.

thelarkinn 9y ago
We heard this feedback infact and we wrote the entire plugin system for webpack 4! (https://github.com/webpack/tapable https://github.com/webpack/tapable). Take a look at the only PR open which is us working to provide the best Type system possible for our new API (which was infact designed to support it). Even better is that you can find all the "hooks" on an instance by doing `compiler.hooks` so now you get a far better authoring experience :-D
- jblg 9y ago
  Would be better if Webpack had defaults that just worked out of the box without configuration.
- shriek 9y ago
  That's awesome. I haven't played with webpack 4 yet. Just recently started playing with webpack 3. I'd be keeping an eye on it.

md224 9y ago

Curious what people think of Neutrino as a solution for Webpack's complexity: https://neutrino.js.org https://neutrino.js.org

jorblumesea 9y ago
That is fantastic, on first glance it seems exactly what is needed. I just think it's unfortunate that the tool needed someone to develop another tool to make it truly usable. Good software should be simple to use and configure, not dense and opaque.
- marksomnian 9y ago
  I don't think it's unfortunate, I think it's a good abstraction. Webpack being a lower-level tool wrapped by Neutrino. Similarly to git's plumbing and porcelain separation.

jacobwg 9y ago

There has been some recent buzz around https://parceljs.org/ https://parceljs.org/, which aims to also "just work" with minimal configuration.

thelarkinn 9y ago
At what cost :-D

thelarkinn 9y ago

Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe it's been awhile since you have taken a look at our documentation! (webpack.js.org)! I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does. In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible. Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack). Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3. So if you have great ideas, please let me know. :-D

shados 9y ago
> In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download Man I wish it was easier to convince people of this. I'm fighting with some teams at work who are shipping 2mb+ compressed with several seconds just for parse time...and all of the webpack tooling and features are needed just to keep it there (when it should be used to bring it down within that 200kbish threshold). And they feel its normal.

hesarenu 9y ago

I have active projects using browersify with reactjs. It's not tightly tied to webpack.

manigandham 9y ago

It's really not difficult, it just looks more complicated than it is. If you want a good start, try the Webpack book by SurviveJS. You can read most of it in an hour or two and not only create a config but actually understand how webpack works: https://survivejs.com/webpack/introduction/ https://survivejs.com/webpack/introduction/ There are also slimmer/newer/zero config alternatives like: https://poi.js.org/ https://poi.js.org/ https://neutrino.js.org/ https://neutrino.js.org/ https://parceljs.org https://parceljs.org

bmarkovic 9y ago

I haven't used Webpack prior to 2.x and Gulp was my preferred option previously as Grunt really was a clusterfuck, but Webpack setups come with batteries included and small extensions to it you need to add are often easy. That's my limited experience anyhow. The only tool I rooted for (but is still behind the curve) is Brunch.

hazza1 9y ago

My webpack configs are a magnitude smaller than the equivalent gulp ones. React really isn't tied to webpack - babel maybe. If you're just using webpack for the basic functionally of babel automation and es6 import resolution it's trivial to setup but probably not the best tool for the job.

frik 9y ago

Good that plain JavaScript 5/6 with no framework is still in the top 2 in all related charts. Looking back how many frameworks came and went dodo, I am using only small libraries and stay with plain vanilla JS 5/6. Writing modern JS is a peace of cake, it's better to understand 100% of the codebase than to use way too much magic APIs. (well I understand the whole computer, all layers, from hardware to operating system, to software - so there is no magic for me, that helps a lot)

lucideer 9y ago

React is definitely in no way tied to Webpack. Slightly tied to babel presuming you're using JSX, as everyone is, but otherwise it's extremely easy to use any other tool. I've built pipelines with rollup and browserify, both which have problems and I'm not entirely happy with but I found an improvement over webpack.

tjholowaychuk 9y ago

https://neutrino.js.org/ https://neutrino.js.org/ is my go-to, I have no gripes with Webpack as a technology, but I don't think it's what people should use on a daily basis abstraction-wise.

mnutt 9y ago

I evaluated webpack recently and found that it worked fine for straightforward projects but the more customized I wanted it the more issues I ran into.[0] I think it’s a matter of configuration as json vs configuration as code. Webpack had all of the component pieces I needed, but they were glued together in ways that I couldn’t compose them. I ended up using rollup, which was a bit better but I still yearn for the composability of Broccoli. [0] My project allowed users to have a single JS file that would be able to `import` npm modules and the have the bundler compile all of the dependencies into a single tree-shaken vendor.js, while modifying the main file’s imports to be human-readable es5. Webpack’s es6 import code was tightly coupled to the format of its output.

epicide 9y ago

I definitely went through the pain of trying to set up Webpack 1.x on a large project. The documentation was probably the worst part (it was adequate as a reference, but really assumed you already knew some of the fairly complex topics). I also recently went through the process of refactoring our build to use Webpack 3.8. The documentation is a LOT better. Their introductory docs especially. I feel like I finally understand parts of WP 1.x after reading the 2.x/3.x docs. Gulp and Webpack really are two separate things. Gulp is basically like Ant had a baby with NPM scripts. Webpack is closer to Maven, but Maven really tries to do a LOT more. For any project, start with NPM scripts for your task running, then include gulp if/when you actually need them. Same goes with Webpack: don't include it in every project just because you think you might need it eventually.

deleted 9y ago

[deleted]