3 ms·

It's like you've never seen a webpack "config file"...

by franga2000 6y ago

ZephyrBlu 6y ago
Do people not re-use previous configs as a starting point for new projects? Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.
- franga2000 6y ago
  It's not always that easy. Most of the pain around webpack configs comes from dealing with them later, not when starting the project. It might've been written by someone before you and modified by multiple people. Now you have to figure out how to add something new, intended for a different pipeline, into your existing pipeline, which has years of changes you probably don't understand in it.
j-krieger 6y ago
I have. Compared to what most back-end languages have to offer (CMake and the like), it‘s a joy to use, pretty straightforward and well documented.
- franga2000 6y ago
  C/C++ != "most backend languages". Python, Ruby, Go and, Rust are much more commonly used on the backend and none of them have build systems as ugly as C nor as over-engineered and messy as JS.
  - j-krieger 6y ago
    > Python, Ruby, Go and, Rust are much more commonly used on the backend Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager. However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away. I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine. I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.

It's like you've never seen a webpack "config file"...

Do people not re-use previous configs as a starting point for new projects? Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.

franga2000 6y ago
It's not always that easy. Most of the pain around webpack configs comes from dealing with them later, not when starting the project. It might've been written by someone before you and modified by multiple people. Now you have to figure out how to add something new, intended for a different pipeline, into your existing pipeline, which has years of changes you probably don't understand in it.

j-krieger 6y ago

I have. Compared to what most back-end languages have to offer (CMake and the like), it‘s a joy to use, pretty straightforward and well documented.

franga2000 6y ago
C/C++ != "most backend languages". Python, Ruby, Go and, Rust are much more commonly used on the backend and none of them have build systems as ugly as C nor as over-engineered and messy as JS.
- j-krieger 6y ago
  > Python, Ruby, Go and, Rust are much more commonly used on the backend Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager. However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away. I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine. I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.