5 ms·

How do you hire programmers like that?

techdragon 9y ago
<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.
- aaron-lebo 9y ago
  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.
  - swsieber 9y ago
    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 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.
    - Chyzwar 9y ago
      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.
- gortok 9y ago
  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.
  - aaron-lebo 9y ago
    Does this not work? https://github.com/webpack/webpack/blob/master/examples/css-bundle/webpack.config.js https://github.com/webpack/webpack/blob/master/examples/css-... https://webpack.js.org/loaders/css-loader/#src/components/Sidebar/Sidebar.js 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
    - untog 9y ago
      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.
      - aaron-lebo 9y ago
        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.
- Waterluvian 9y ago
  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.
  - thelarkinn 9y ago
    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
- arglwarg 9y ago
  > <stereotype joke> By not hiring a JavaScript developer. </stereotype joke> aka "the lisp curse": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
  - techdragon 9y ago
    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.
- fuckjstbqh 9y ago
  Except it’s more like “ha ha only serious”. I work with people who know nothing but boot camp JavaScript and it’s a goddamn nightmare.
- v4tab 9y ago
  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.
- hinkley 9y ago
  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.
hacker_9 9y ago
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.
fuckjstbqh 9y ago
Simple: don’t hire JavaScript programmers.
srslyfuckjs 9y ago
Seriously, don’t hire JavaScript programmers. Why is this so difficult? There’s a goddamn one-liner in npm that determines an array’s length, and like a billion packages depend on it. Anyone who has JS on their resume and is proud of it will soon find their resume as part of a child’s birthday confetti.
throwawayxo9z 9y ago
See if they can fog a mirror, apparently.

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

aaron-lebo 9y ago
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.
- swsieber 9y ago
  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 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.
  - Chyzwar 9y ago
    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.
gortok 9y ago
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.
- aaron-lebo 9y ago
  Does this not work? https://github.com/webpack/webpack/blob/master/examples/css-bundle/webpack.config.js https://github.com/webpack/webpack/blob/master/examples/css-... https://webpack.js.org/loaders/css-loader/#src/components/Sidebar/Sidebar.js 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
  - untog 9y ago
    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.
    - aaron-lebo 9y ago
      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.
Waterluvian 9y ago
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.
- thelarkinn 9y ago
  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
arglwarg 9y ago
> <stereotype joke> By not hiring a JavaScript developer. </stereotype joke> aka "the lisp curse": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
- techdragon 9y ago
  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.
fuckjstbqh 9y ago
Except it’s more like “ha ha only serious”. I work with people who know nothing but boot camp JavaScript and it’s a goddamn nightmare.
v4tab 9y ago
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.
hinkley 9y ago
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.

hacker_9 9y ago

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.

fuckjstbqh 9y ago

Simple: don’t hire JavaScript programmers.

srslyfuckjs 9y ago

Seriously, don’t hire JavaScript programmers. Why is this so difficult? There’s a goddamn one-liner in npm that determines an array’s length, and like a billion packages depend on it. Anyone who has JS on their resume and is proud of it will soon find their resume as part of a child’s birthday confetti.

throwawayxo9z 9y ago

See if they can fog a mirror, apparently.