4 ms·

The state of Webpack does not reflect a 400k/year budget. The docs, API, source code, ecosystem... so happy to hear people making software engineering money ge

The state of Webpack does not reflect a 400k/year budget. The docs, API, source code, ecosystem... so happy to hear people making software engineering money get a second salary to keep doing this. We're all waiting for the thing that will replace Webpack so we don't have to keep using it. Maybe we should just go and make it.

naspeh 9y ago
I think it does. This area where webpack is trying to shine is just over-complex, so the tool can't be simple, that's it. And most importantly as for me, developers who works full-time on such projects can sustain the higher quality and improve it over time and if you chose it for now it may been relevant year later or 2-3... I hope at least.
- thelarkinn 9y ago
  The tool aims to be agnostic to work flow it's a trade-off to be generic in our case. We realize it too.
acemarke 9y ago
Tobias Koppers isn't making a "second salary". He was working on Webpack in his spare time, and can now work on it full-time thanks to the funding that's come in.
solidr53 9y ago
Brunch.io maybe?
- stevebmark 9y ago
  No, brunch is a major step backwards. So are Browserify, gulp, and grunt. We need something new.
  - makmanalp 9y ago
    ... and so the cycle continues :-) Seriously though, this is how the JS community ends up changing tools every 2-3 years. What about joining in and improving what exists? A non-trivial amount of work must have gone into webpack. As an outside observer, I see so much wasted effort.
  - always_good 9y ago
    Then walk the talk and propose some example config file APIs (or however your ideal tool would work). It's easy to complain about something without offering an alternative. You just shot down every tool, so let's see this impressive tool that you surely must have in your head. As a tool becomes sufficiently generalized, it always picks up what looks like cruft in the simple cases. But the simple cases cannot tell you how good or versatile a tool is because you can solve a simple problem with virtually anything. That's why people who need to concat 2 files think you can replace all of Webpack with `cat`. The cycle continues when someone creates a new tool with a simple API because it doesn't generalize, but then they realize they need to extend it such that it generalizes over the real-world problems that people have when bundling, like hot reloading (different than live reloading) and code splitting and arbitrary transformations.

naspeh 9y ago

I think it does. This area where webpack is trying to shine is just over-complex, so the tool can't be simple, that's it. And most importantly as for me, developers who works full-time on such projects can sustain the higher quality and improve it over time and if you chose it for now it may been relevant year later or 2-3... I hope at least.

thelarkinn 9y ago
The tool aims to be agnostic to work flow it's a trade-off to be generic in our case. We realize it too.

acemarke 9y ago

Tobias Koppers isn't making a "second salary". He was working on Webpack in his spare time, and can now work on it full-time thanks to the funding that's come in.

solidr53 9y ago

Brunch.io maybe?

stevebmark 9y ago
No, brunch is a major step backwards. So are Browserify, gulp, and grunt. We need something new.
- makmanalp 9y ago
  ... and so the cycle continues :-) Seriously though, this is how the JS community ends up changing tools every 2-3 years. What about joining in and improving what exists? A non-trivial amount of work must have gone into webpack. As an outside observer, I see so much wasted effort.
- always_good 9y ago
  Then walk the talk and propose some example config file APIs (or however your ideal tool would work). It's easy to complain about something without offering an alternative. You just shot down every tool, so let's see this impressive tool that you surely must have in your head. As a tool becomes sufficiently generalized, it always picks up what looks like cruft in the simple cases. But the simple cases cannot tell you how good or versatile a tool is because you can solve a simple problem with virtually anything. That's why people who need to concat 2 files think you can replace all of Webpack with `cat`. The cycle continues when someone creates a new tool with a simple API because it doesn't generalize, but then they realize they need to extend it such that it generalizes over the real-world problems that people have when bundling, like hot reloading (different than live reloading) and code splitting and arbitrary transformations.