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.
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.
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.
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.
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.
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 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)
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.
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.
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 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.
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.
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.
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' ?
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.
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
