Funding Open Source: How Webpack Reached $400k+/year
medium.com
medium.com
>> sorry to hear you feel this way! [..]
>> [..]
When I first read the quote, I thought "that's nice of webpack". Then I saw this:
> The greatest power you have for haters or trolls is love.
I would not call someone saying "fuck webpack" a hater or a troll, I would call them a frustrated user. OTOH, you can turn a frustrated user into a hater or a troll by dismissing their concerns or by trying to shift the blame onto them by calling them rude.
Venting your frustration is an absolutely understandable behaviour when faced with unintuitive software, especially for users who don't understand what they're using (including software developers!) - they're in a position of lesser power, feel helpless, and need an outlet to express this. No developer should be taking these expressions as a personal attack, nor belittling it as rude or trolling.
Because of this, I saw the original quoted interaction in a new light - upon a second look, it is a bit unsubstantial, bordering on virtue-signalling. A proper quote that actually indicates caring about your users, would include responding to a specific problem from a very frustrated user, by actually fixing the issue. Not just saying nice words.
I get the frustration...I've said "Fuck XYZ" a thousand times for a thousand different software XYZs but to take that to a public forum is suitable behavior for a toddler, and does harm.
How many nights & weekends were spent building Webpack? How many nights & weekends coming up with "fuck webpack"? Show some respect and at least spend a few hours in thoughtful critique. Civility must still have a place, even online.
Tangentially, Rich Hickey recently responded (I think appropriately) to a similar outlet re Clojure [1].
[1] https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...
Maybe that's just me.
Holding people to a higher standard doesn't make the world any worse -- it just means those people have to adapt, but that makes for a world that more and more of us (even those without your sorta soft skills) can navigate. That seems healthy?
I don't consider this a game, I take it pretty seriously to help others. However, I am human like many others and as of late I've been a bit caught up with family. If this happened to you then by all means I can own it and apologize. Otherwise shoot me a DM if you really need help and if I can't help I'll find someone who can
I don't consider that person a hater etc. I think maybe the transcript of my talk didn't really mean to couple that statement with that slide etc.
The stream model of gulp and the resulting highly structured code that most often results means that I can generally find and fix bugs quickly, this is even possible in the horribly convoluted gulp file that we use at my current working place. In my experience when you have even a bit of webpack and there is a problem somewhere it can be difficult to figure out the cause because it seems every capability of the system works in its own way.
Rather, defining the build process entirely in code lets you step through the whole thing logically.
I've only had to really wrestle with webpack twice: once to get it working with a huge corpus of legacy code, the other to get it building a node backend and ES6 frontend with lots of shared code. Other than that my config has always been pretty simple.
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.
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.
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.
This is what the open source community needs. Steal the maintainers of the top 1% of open source projects from the "free market". The projects not already sponsored by corporations that is.
Or, why not work toward pairing these maintainers w/ companies who will let them spend most of their time working on said project. Might make it easier as far as fund raising is concerned.
I bet there's a niche for this second idea. It's not always obvious to the people cutting the checks just how valuable these side projects are to the world.
- https://medium.com/the-vue-point/vue-in-2016-8df71d98bfb3#9a...
> Going Independent
> In early March I decided to work on Vue full-time independently and started a Patreon campaign, which has been (to my surprise) quite successful so far. It is my first time working independently without having to report to a manager, and it has been a very liberating experience.
They also use OpenCollective: https://medium.com/the-vue-point/vue-is-now-on-opencollectiv...
It was the same thing with CoffeeScript; it inspired some neat features in JavaScript but it has made itself obsolete; the ecosystem caught up. It fulfilled its purpose nonetheless.
Webpack would probably have benefited more from this funding a few years ago.
Based on what I've read, sending a few bundled chunks instead of many individual module files will still generally have less overhead. In addition, Webpack's ability to load and transform other file formats like images and styles is something that simply requesting ES modules over HTTP2 can't deal with. Webpack's ability to code-split an application is also important.
Tobias Koppers, the main Webpack developer, wrote an article last year on how Webpack and HTTP2 relate: https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 .
It's also worth noting that Tobias had only been able to work on Webpack intermittently for the last couple years, until this recent funding allowed him to work on it full-time. Tobias has been writing reports on what he's been doing [0]. Also, grants and full-time development is enabling the team to work on projects like integrating WebAssembly support directly into Webpack [1].
[0] https://medium.com/webpack/the-chunk-graph-algorithm-week-26...
[1] https://medium.com/webpack/webpack-freelancing-log-book-week...
How did you get the companies to sponsor? It seems like once you are above a certain threshold/community level, it makes sense for a company, but did you just reach out or was it people you already knew? Or people you bumped into while talking at a conference? But how do you know if they are the ones at a company that can sign off on sponsorship? This very much seems like "sales", how does an Open Source-loving engineer get good at sales?
I guess people who leave comments like this have literally 0 threshold for any kind of error message and just want all the interfaces they ever use to be static and permanent. I’m not a webpack fanboy. I don’t like JavaScript. But I don’t go around posting nonsense FUD about “relentless changes” that don’t exist. Sorry buddy, you’re full of it.
There's this whole FUD around Javascript in general. If you didn't know better, you'd think there were client-side tools in other ecosystems where you didn't have to learn or credentialize in anything to build a full-featured client.
More seriously... I've just today finished updating some C++ code that integrates the Chromium Embedded Framework into Unreal Engine 4 to work with current versions of both CEF and UE4 and even building all this, Separate CEF sub process binaries without a strait forward make && make install, and debug builds of the entire unreal engine editor to track down CEF initialisation errors. Was simpler than React, Redux, WebPack, Babel, et.al. ... and I'm not a professional C++ dev using it every day either!
I'm also not going to blame the language either. I sat down and worked through the entire EmberJS documentation in a couple of afternoons worth of spare time. It was clear, concise and orderly. It was easy and now I'm even looking forward to EmberJS 3.0 with Glimmer and full support for building stand alone web components using just the EmberJS ecosystem. So clearly it's not some fundamental failure of my ability to learn/understand JavaScript.
So at the end of this joke/rant I guess I have to point my criticism at the subset of JavaScript developers who have allowed the crazy parts of the JavaScript ecosystem that they maintain, to get out of hand. I suspect because they never stop working with it and consequently are able to hang on to the rollercoaster and productively make use of it while being blind to outside criticism because as far as they can see it's all simple and logical and it's everyone else that doesn't understand it.
Webpack works fine and is easy to use, part of the issue is that people criticizing JS don't know what they are talking about because they don't actually use JS that much and they don't understand why that makes their criticism not that useful (not you, just in general).
JS has a magnitude more devs than some languages and a lot of them are new users, with that being the case, it isn't shocking that it makes for a large number of bad libraries. But if you know your tools, it's not that big of an issue.
This is a nice guide to starting with webpack that I think describes it very well: https://what-problem-does-it-solve.com/webpack/index.html I'd recommend this guide to anyone who is trying to get started with webpack.
I wish there was an intuitive way to chain JavaScript file transformations together, but it doesn't seem like there is one yet. Webpack is close, but I think it has too much baggage to get there.
Issues you might have are related to broken web frameworks (angular4) than webpack itself.
I was attempting to use its bundling capabilities to bundle css and js files for a web application. Believe it or not, the very simple end-user use case of bundling css is not a part of the core library, nor is it well demonstrated or explained in the docs. After a few hours, I simply gave up and continued to use gulp.
We don’t treat user time as precious because our audience is developers; yet startup developers are the people who can ill-afford to lose an afternoon to try to figure out something as demonstrably simple as bundling CSS.
https://github.com/webpack/webpack/blob/master/examples/css-...
https://webpack.js.org/loaders/css-loader/#src/components/Si...
Note: examples at bottom of second link, found it by searching "css" in the doc site
I get that's how Webpack users are used to doing it, but when you're new to it (or just coming back to it from a different build system) it's the very definition of insanity.
Also, feel free to disagree about the CSS, I think it's a very intuitive way of including assets.
I thought the breaking API changes with 2.0 would at least accommodate this incredibly common use of a bundler, but no.
Unanswered questions that I left the project with (I time-boxed myself to 4 hours; as that was the initial length of time it took me to get gulp up and running in totality):
- Why do I need a require for my CSS? I literally want to replace the css with its minified form. Maybe even bundle it together (I'd settle for the former).
- How the heck is web-pack doing all this; and why is the package called 'extract-css-loader'? I don't want to extract CSS; I want to minify it.
- If I want a source folder and a dist/ folder for my CSS; how would I get Webpack to update the URLs in the .html files?
- Am I crazy for still doing this through HTML? Is there a 'better way' ?
I noticed recently that module support is now in chrome. When module support lands for all the browsers, it's going to be a huge step toward getting rid of a lot of build complexity.
I've been writing vanillajs toys the past month and wow have things improved greatly in the last four years.
I don’t think you should hold that one up as a paragon.