Hacker News Reader

Comment by pandemi | Hacker News Reader

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.

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)

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.

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.

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

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.

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'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

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.

Reply on news.ycombinator.com