Funding Open Source: How Webpack Reached $400k+/year(medium.com)
medium.com
Funding Open Source: How Webpack Reached $400k+/year
https://medium.com/open-collective/funding-open-source-how-webpack-reached-400k-year-dfb6d8384e19
64 comments
I don't think it's acceptable in any situation to express your frustration this way in a public forum, especially for OSS. Thoughtful critical pieces are fine and necessary, but I don't think blatant vitriolic "cathartic" outlets should be encouraged at all -- in this case, it is being encouraged by the maintainer, but I don't think that helps anything.
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...
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...
I agree that screaming something like this on Twitter when you're in temporary rage is nothing but childish. But it's also hard to ignore that someone who represents webpack was able to resolve the situation calmly and civilly only to call the person a hater and a troll later on. This, in my eyes, is a breath away from screaming obscenities on Twitter.
Lol you absolve frustrated users of all blame. Even if you're frustrated, it's not difficult to be civil.
I don't consider it uncivil for someone else to say "fuck [my project]" after having trouble with it. I would consider it uncivil to write me messages saying "fuck you, you are an asshole for writing [my project]".
Maybe that's just me.
Maybe that's just me.
I personally feel that's just you. I'm genuinely happy for you that you can be unfazed, but many many people can't -- it costs them and taxes them. Someone not sticking up for those latter folks makes for a world where only folks with your brand of relating can cut it. That's kinda needlessly limiting, when the cost of things being better is just setting our collective arbitrary bar a little higher :)
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?
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?
Whatever you want to call it, it’s a temper tantrum. It’s what children do in supermarkets.
Sean Larkin's favorite game is to respond to every single Tweet containing the word "Webpack" and not help them in any way
Hey maybe you are victim of this and I missed out!
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 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
It's more then nice words. It's showing you listen, it's empathizing, it's putting yourself in that persons shoes. To fix things like usability we have a lot of long work ahead of us and we want to do so.
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.
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.
Anyway, thanks @thelarkinn for great write up, it's just good success story to learn from. Keep rocking!
The difficulty I have with Webpack is that there does not seem to be any unifying principle of how things work.
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.
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.
Completely agreed. Webpack faces the exact issue that Grunt ran into which is these huge 'config files of doom' that end up as snowflakes which are hard to understand.
Rather, defining the build process entirely in code lets you step through the whole thing logically.
Rather, defining the build process entirely in code lets you step through the whole thing logically.
I don't find that to be true at all. In fact I would guess that across all my projects the configs are 80-90% identical. The only thing that changes are different loaders depending in the tech stack and maybe the addition of a few bells and whistles such as i18n.
What exactly are you referring to? Webpack has an incredibly simple model -- do everything with a loader.
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.
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.
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.
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.
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.
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.
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.
The tool aims to be agnostic to work flow it's a trade-off to be generic in our case. We realize it too.
Brunch.io maybe?
No, brunch is a major step backwards. So are Browserify, gulp, and grunt. We need something new.
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.
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.
... 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.
"Ever since we were able to grow the budget large enough for Tobias to work on Webpack full time..."
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.
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.
Nice to hear there's some hope... I managed to get some small grants and donations and things for WireGuard over part of this last year -- https://www.wireguard.com/donations/ -- but I don't have much lined up for next year, and I'm hoping I can figure it out in time to do WireGuard things full time. The thing is just getting funding lined up for [part of] this last year was a pretty time consuming hustle, and I'd rather spend that time writing code. This leads me to think I should find somebody to handle "fund raising" or "community mumblemumble" or something, but as WireGuard is a security-oriented project, communicating correctly is important, and I could imagine that somehow backfiring. The other thing is that I'd feel really uncomfortable putting up one of those thermometer overlays on the wireguard.com website; just adding the "donate" link in the corner was a bit much for me. So, hm. Nice to see the Webpack guys figure it out. Maybe I'll take some clues from there.
Here is one more success story nowadays about Vue.js and Evan You (creator)
- 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...
- 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's a great project but I don't understand why they need so much money for the future. It's a bundling tool. Wasn't it supposed to be a transition project? Won't Webpack get replaced by simpler things like ES6 module import and HTTP2 push?
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.
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.
No, HTTP2 doesn't just replace bundling, and definitely not what Webpack does.
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...
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...
So TL;DR: tshirts, ads embedded in their docs, and corporate sponsorships. Makes sense for an open source project with a fairly large community at least.
This is really encouraging to hear, I run an Open Source community that is a fifth the size of Webpack. And in the back of my mind I'm trying to figure out how to help fund/pay/reward the community, without then making it awkward, political, or money driven.
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?
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?
Maybe they could employ a programmer who knows how to turn unbelievably complex software into incredibly simple software that doesn't include constant relentless breaking changes.
People leave nonsense comments like this just to spread FUD are so irritating. I upgraded 1–>2 a while back and it took a few changes based on informative error messages. People like this made me dread the upgrade thinking it would be complicated. It was basically painless. I’m on version 3–something now and have encountered no other breaking changes. It’s a great tool.
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.
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.
Great it worked out for you, but if it wasn't such a pain to upgrade (I know this from personal experience), wouldn't there be lesser FUD?
Is this your first time on HN? People will complain about anything and everything. They'll incessantly dismiss anything that they think they could have done better in a weekend.
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.
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.
I’m saying explicitly he or she is making up problems that don’t exist. My presumption is they never used webpack or tried for a second and gave up. My theory is this user likes to parrot things about the JS scene. Upgrading webpack involved changing some things from an array to a keyed object or something. It was nothing. I’m not particularly smart or JS savvy.
Which breaking changes are you referring too? I remember updating some configs in the jump from 1 -> 2, but none since then
Webpack 1 -> 2 had several breaking changes, primarily around loader configuration syntax. The migration guide at https://webpack.js.org/guides/migrating/ covers the changes. 2 -> 3 was primarily internal changes, with little to no migration steps needed other than bumping the installed version.
Yes, I’m well aware - im asking the basis for the belief that these constitute “constant relentless breaking changes”
How do you hire programmers like that?
Hire someone who has worked on legacy systems and practices TDD, then once hired give him the time he needs to break apart the codebase into testable units.
<stereotype joke>
By not hiring a JavaScript developer.
</stereotype joke>
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.
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.
It just sounds like you found a quality C++ library, there's thousands that are horrific messes. Compiling some of them is unbelievable amounts of frustration, which npm mostly avoids.
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.
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.
Webpack is terrible to use. Very inconsistent and results in a mess of code for your configuration. I suppose part of that comes from the 10+ loader interfaces it uses under the hood. But most of it comes from organic growth (I assume) and the fact that there are no JavaScript standards (e.g. no filesystem or pipe like interfaces, the competing module systems and no standard library)
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.
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.
Webpack standardizes JS build process. It is a massive improvement from Grunt - plugin dumpster, Gulp spaghetti code and makefile - DIY everything.
Issues you might have are related to broken web frameworks (angular4) than webpack itself.
Issues you might have are related to broken web frameworks (angular4) than webpack itself.
The task that requires JavaScript/React/Redux/WebPack/Babel is enormously complex. On the other hand writing a server side process in Node is a delight and in my experience an order of magnitude easier than writing the equivalent code C++ or C. Or than writing it in the language that-must-not-be-named but also starts with a "Java". My conclusion is that the language is less of an issue than the task.
> <stereotype joke> By not hiring a JavaScript developer. </stereotype joke>
aka "the lisp curse": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
You posting this link and giving me a chance to read it has been a highlight of my day. The fundamental lispishness of JavaScript by way of scheme explains everything I hate about working with JavaScript after reading that essay.
I had a similar issue very recently with webpack.
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.
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.
Does this not work?
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
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
Having to use two loaders (one being loaded by totally non-standard syntax inside the other loader), a plugin (that specifies the output filename nowhere near where the others are specified) and then using a JavaScript require() function to include a CSS file is utterly demented.
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.
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.
Maybe, but it's understandable after five minutes and you literally have code you can copy and paste. I've seen much worse in basically every other language. We had a 5k line project, after the first day of setup, we've had to touch the webpack config once or twice.
Also, feel free to disagree about the CSS, I think it's a very intuitive way of including assets.
Also, feel free to disagree about the CSS, I think it's a very intuitive way of including assets.
You can copy and paste Webpack config to your heart's content, but actually understanding them is something else.
I thought the breaking API changes with 2.0 would at least accommodate this incredibly common use of a bundler, but no.
I thought the breaking API changes with 2.0 would at least accommodate this incredibly common use of a bundler, but no.
I've seen those docs. I tried implementing webpack to replace our gulp bundler (which was initially an ASP.NET Core Bundler) for an ASP.NET Core project.
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' ?
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' ?
JS needs a standard library that ships in all the browsers. "There, you're all using the same tools. They're not perfect for any of you but they're good enough for all of you."
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 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.
Native modules are still pretty slow. So much that we as an oss org are working with browsers to help them find ways to make them faster. Although native modules will be nice, we still believe that bundlers are still needed to ship the fastest most optimized code
I stopped using Ember because they broke my side project four times in as many months.
I don’t think you should hold that one up as a paragon.
I don’t think you should hold that one up as a paragon.
Thanks for making and continuing to improve WebPack. I use poi.js which uses WebPack internally for low/no config dev.
https://poi.js.org/
https://poi.js.org/
[deleted]
Why is it so slow with that kind of funding?
>> 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.