5 ms·

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webp

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending a handful of days reading the docs once a year or whatever is not really a problem. I have a couple of files, one for local one for production. About 50-70 lines each and considering it is compiling typescript, linting, minifying, scss, testing and so on... I find I get a lot of bang for my buck. It's not like the previous tooling was really any easier to deal with. The production build takes about 50 seconds, and the local build takes about 3 seconds. It's honestly the least of my problems.

IshKebab 5y ago
Webpack is definitely a difficult beast because it's sort of an everything tool. It's supposed to be just a bundler but because it supports plugins people use it as a full build system. It doesn't really work that well as a full build system. It's also quite buggy in my experience, e.g. the multi-config feature doesn't really work at all.
morelisp 5y ago
> I have a couple of files, one for local one for production. About 50-70 lines each I don't think you realize how hellish this sounds. I haven't had >100 lines of build configuration in any other environment since my configure.in/Makefile.am days, and even that was more transferable to other tools than Webpack, which is only good for Webpacking.
- Bellend 5y ago
  What would be the alternative in todays projects? Like typescript and scss need compiled, then there are builds which are minified with source maps vs local which isn't, then people want browserlist and scss linting and so on. I don't see how configuration can be escaped but I would be happy to have a path forward to change that if I knew how.
  - morelisp 5y ago
    Oh no, I agree it's absolutely too late for existing projects. Good sense needed to prevail at least 4-5 years ago, but who wanted to deal with being seen as "elitist" or "gatekeeping" for daring to suggest the entire ecosystem made no sense?
- merrywhether 5y ago
  Modern webpack is also much simpler than when it started, as they’ve followed their zero-config northstar (#0CJS) for a while now. Many simple projects can literally run without a config file at all. The config file only grows in relation to the complexity you want to take on, like adding Typescript or wanting to run WebWorkers, but that seems fair? It’s not like you can just start adding Kotlin or Scala to a Java project without changing your setup. And there are plenty of higher-level tools than webpack that are pre-configured to handle most of your variations anyway (eg CRA) and are a much better starting point if you don’t need to fine tune your build or do complicated/exotic things (which isn’t a breeze in any language I’ve experienced).
hsn915 5y ago
The problem with webpack, beside being very slow, is it's based on config files. Config files are brittle and very hard to understand. Spending several days sifting through the webpack docs and maintaining 70 lines of config files sounds like a nightmare. Now, for esbuild, I have more lines than that for the build script, but the thing is, it's just code. The configuration part is about 10 lines. The other stuff is just programming logic. Navigating documentation to understand what parameters something accepts is ok. Spending time editing code is ok. It's what I do most of the time anyway. It's tractable. A web of configuration files is not tractable.
- Bellend 5y ago
  The reason I moved away from gulp (v3?) at the time was because I considered configuration (especially an intellisense configuration) really simple as opposed to the god awful pipable javascript files gulp went for. Not sure how much that plays to my strengths though because everything I have ever used has json file configurations or object file configurations. Anyway I am definitely going to kick some tires on ESBuild, but I will just wait a while so thanks for some additional insight.
  - hsn915 5y ago
    I never understood the point of gulp and other libraries that claim to help you write "commands". I just never used them and instead just wrote the code directly. Back in the day I was using amd.js and they had a scriptable command line utility so I just wrote a javascript file that collected all the required inputs for it and then built up the build command. (or something like that .. I don't remember the details).
drenvuk 5y ago
“Ah you think darkness is your ally? You merely adopted the dark. I was born in it, molded by it. I didn't see the light until I was already a man" Sorry for this, but I find the parallels a bit funny.
llimllib 5y ago
> Is webpack really considered such a difficult beast For whatever it's worth, I'm the sort of person who writes makefiles for fun, and I regularly work with the build systems of go, C, rust, java, ruby, python, and javascript. webpack is easily the most complicated, slow, frightening build system I have ever encountered and I will go far out of my way to avoid it.
- Bellend 5y ago
  TIL as it's not really something I can say I am an expert on although I am really surprised by the bar height being set by others. Hopefully I will be pleasantly surprised when I try some new tooling in the future!
  - llimllib 5y ago
    It's also completely possible that I had my brain warped in weird ways by old software, and you'll have your brain warped in your own weird ways that work better in the future. Anyway, I know I'm always glad to have somebody who knows their way around webpack on the team :)
throwaway894345 5y ago
At two places I’ve worked, we had performance issues with webpack where builds would take tens of minutes. Every frontend guru would come in with their “oh, it’s probably X”, spend half a day debugging, and then give up. Moreover, webpack does all sorts of things I don’t care about: support for a dozen different module systems, javascript versions, polyfills, scss, JSX, etc etc. I just want to issue a few requests and update the DOM. I guess I’m spoiled by Go and Rust where I can basically just throw a list of dependencies at the build tool and it spits out an executable (almost immediately in the case of go).
jrochkind1 5y ago
> It's not like the previous tooling was really any easier to deal with. If you really understood the previous tooling, that probably explains why you have the mental models in place to understand what webpacker is doing with increasing automation. Say, if you were using babel without webpacker already. For people who skipped that or came to JS in webpacker era (myself included), it's hard to understand what is going on. the universe of what webpacker does seems inconsistent and random and involves concepts underlying concepts underlying concepts where it seems like you need to understand the mysterious base to understand what the top-level tool is doing before forgetting it and letting the tool do it for you. But webpacker isn't just insane, it is what it is for a reason, involving solving specific problems that were in existence in previous ways of doing things. If you had those problems personally... it's a lot easier to make sense of it. I assume/sense. I don't know this from personal experience with webpacker... but it's a familiar sort of situation with software development technology.
- bredren 5y ago
  > But webpacker isn't just insane, it is what it is for a reason, involving solving specific problems that were in existence in previous ways of doing things. If you had those problems personally... it's a lot easier to make sense of it. I think this a big issue for non-js / frontend people, particularly in the python webdev community. People don't know the story of front end and the user demand for refined interfaces. The demand has been high even though browsers just recently offered consistent support for modern js / css features. I suspect this will come back to bite backend people, to some extent because the dust is settling on frontend. So the anti-everything on frontend attitude might blind people to the rapid advance of JS and node.
  - jrochkind1 5y ago
    Hm, I didn't mean to be talking about an "anti-everything on frontend attitude"!
conradfr 5y ago
At some point in my life I contemplated giving up on frontend because of Webpack. I guess it's better since version 4, but when you need to change/update your build script, you brace yourself. To be fair I use esbuild on a Phoenix project right now and some things are not really that much clear on how to do them. Like yesterday I wanted to put eslint in the "watched" build process, and I'm still not sure how I would do that. At least it's fast...

IshKebab 5y ago

Webpack is definitely a difficult beast because it's sort of an everything tool. It's supposed to be just a bundler but because it supports plugins people use it as a full build system. It doesn't really work that well as a full build system. It's also quite buggy in my experience, e.g. the multi-config feature doesn't really work at all.

morelisp 5y ago

> I have a couple of files, one for local one for production. About 50-70 lines each I don't think you realize how hellish this sounds. I haven't had >100 lines of build configuration in any other environment since my configure.in/Makefile.am days, and even that was more transferable to other tools than Webpack, which is only good for Webpacking.

Bellend 5y ago
What would be the alternative in todays projects? Like typescript and scss need compiled, then there are builds which are minified with source maps vs local which isn't, then people want browserlist and scss linting and so on. I don't see how configuration can be escaped but I would be happy to have a path forward to change that if I knew how.
- morelisp 5y ago
  Oh no, I agree it's absolutely too late for existing projects. Good sense needed to prevail at least 4-5 years ago, but who wanted to deal with being seen as "elitist" or "gatekeeping" for daring to suggest the entire ecosystem made no sense?
merrywhether 5y ago
Modern webpack is also much simpler than when it started, as they’ve followed their zero-config northstar (#0CJS) for a while now. Many simple projects can literally run without a config file at all. The config file only grows in relation to the complexity you want to take on, like adding Typescript or wanting to run WebWorkers, but that seems fair? It’s not like you can just start adding Kotlin or Scala to a Java project without changing your setup. And there are plenty of higher-level tools than webpack that are pre-configured to handle most of your variations anyway (eg CRA) and are a much better starting point if you don’t need to fine tune your build or do complicated/exotic things (which isn’t a breeze in any language I’ve experienced).

hsn915 5y ago

The problem with webpack, beside being very slow, is it's based on config files. Config files are brittle and very hard to understand. Spending several days sifting through the webpack docs and maintaining 70 lines of config files sounds like a nightmare. Now, for esbuild, I have more lines than that for the build script, but the thing is, it's just code. The configuration part is about 10 lines. The other stuff is just programming logic. Navigating documentation to understand what parameters something accepts is ok. Spending time editing code is ok. It's what I do most of the time anyway. It's tractable. A web of configuration files is not tractable.

Bellend 5y ago
The reason I moved away from gulp (v3?) at the time was because I considered configuration (especially an intellisense configuration) really simple as opposed to the god awful pipable javascript files gulp went for. Not sure how much that plays to my strengths though because everything I have ever used has json file configurations or object file configurations. Anyway I am definitely going to kick some tires on ESBuild, but I will just wait a while so thanks for some additional insight.
- hsn915 5y ago
  I never understood the point of gulp and other libraries that claim to help you write "commands". I just never used them and instead just wrote the code directly. Back in the day I was using amd.js and they had a scriptable command line utility so I just wrote a javascript file that collected all the required inputs for it and then built up the build command. (or something like that .. I don't remember the details).

drenvuk 5y ago

“Ah you think darkness is your ally? You merely adopted the dark. I was born in it, molded by it. I didn't see the light until I was already a man" Sorry for this, but I find the parallels a bit funny.

llimllib 5y ago

> Is webpack really considered such a difficult beast For whatever it's worth, I'm the sort of person who writes makefiles for fun, and I regularly work with the build systems of go, C, rust, java, ruby, python, and javascript. webpack is easily the most complicated, slow, frightening build system I have ever encountered and I will go far out of my way to avoid it.

Bellend 5y ago
TIL as it's not really something I can say I am an expert on although I am really surprised by the bar height being set by others. Hopefully I will be pleasantly surprised when I try some new tooling in the future!
- llimllib 5y ago
  It's also completely possible that I had my brain warped in weird ways by old software, and you'll have your brain warped in your own weird ways that work better in the future. Anyway, I know I'm always glad to have somebody who knows their way around webpack on the team :)

throwaway894345 5y ago

At two places I’ve worked, we had performance issues with webpack where builds would take tens of minutes. Every frontend guru would come in with their “oh, it’s probably X”, spend half a day debugging, and then give up. Moreover, webpack does all sorts of things I don’t care about: support for a dozen different module systems, javascript versions, polyfills, scss, JSX, etc etc. I just want to issue a few requests and update the DOM. I guess I’m spoiled by Go and Rust where I can basically just throw a list of dependencies at the build tool and it spits out an executable (almost immediately in the case of go).

jrochkind1 5y ago

> It's not like the previous tooling was really any easier to deal with. If you really understood the previous tooling, that probably explains why you have the mental models in place to understand what webpacker is doing with increasing automation. Say, if you were using babel without webpacker already. For people who skipped that or came to JS in webpacker era (myself included), it's hard to understand what is going on. the universe of what webpacker does seems inconsistent and random and involves concepts underlying concepts underlying concepts where it seems like you need to understand the mysterious base to understand what the top-level tool is doing before forgetting it and letting the tool do it for you. But webpacker isn't just insane, it is what it is for a reason, involving solving specific problems that were in existence in previous ways of doing things. If you had those problems personally... it's a lot easier to make sense of it. I assume/sense. I don't know this from personal experience with webpacker... but it's a familiar sort of situation with software development technology.

bredren 5y ago
> But webpacker isn't just insane, it is what it is for a reason, involving solving specific problems that were in existence in previous ways of doing things. If you had those problems personally... it's a lot easier to make sense of it. I think this a big issue for non-js / frontend people, particularly in the python webdev community. People don't know the story of front end and the user demand for refined interfaces. The demand has been high even though browsers just recently offered consistent support for modern js / css features. I suspect this will come back to bite backend people, to some extent because the dust is settling on frontend. So the anti-everything on frontend attitude might blind people to the rapid advance of JS and node.
- jrochkind1 5y ago
  Hm, I didn't mean to be talking about an "anti-everything on frontend attitude"!

conradfr 5y ago

At some point in my life I contemplated giving up on frontend because of Webpack. I guess it's better since version 4, but when you need to change/update your build script, you brace yourself. To be fair I use esbuild on a Phoenix project right now and some things are not really that much clear on how to do them. Like yesterday I wanted to put eslint in the "watched" build process, and I'm still not sure how I would do that. At least it's fast...