8 ms·

JavaScript developers are incredible at problem solving, unfortunately

213 points by ScottWRobinson 11y ago

drKarl 11y ago
I wish I could upvote it more...
- cube-drone 11y ago
  you and me both, buddy :3
- adam12 11y ago
  Well, you could create another account... (I'm a javascript developer)
andrewchambers 11y ago
The thing I like about clojurescript is the fact that it has a linker and library system which makes sense.
robertfw 11y ago
Problem: browsers are designed for documents, not rich applications Solution: javascript
- collyw 11y ago
  Problem: JavaScript is the only language that runs in all major browsers. So far no solution.
wwweston 11y ago
"Prototypal inheritance is pants-on-head stupid." Well, he's almost merely wrong, if he were to take out the "prototypal" part.
- SomeCallMeTim 11y ago
  Prototypal inheritance works well, if you understand it. It's only "wrong" if you're of the Java/C++ OOP religion.
  - deleted 11y ago
    [deleted]
  - tolmasky 11y ago
    > if you understand it Someday we'll figure out that this is the problem with most features.
  - bwaxxlo 11y ago
    I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Overall, the more I understand JS, the more I'm convinces most issues raised are personal preferences.
    - atinoda-kestrel 11y ago
      > I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
      - lispm 11y ago
        Not really. The idea of protypical object-systems is for a large part coming out of the Lisp community (and the Smalltalk community) and was used long before Self or Javascript. Check the works of Henry Lieberman. The Self developers got the idea of 'delegation' from him. Object Lisp was a prototype-based object system used in LMI's Lisp Machine OS and in Macintosh Common Lisp (until it was replaced by the then developed standard CLOS). Various Lisp-based systems were developed in the 'knowledge representation' domain, which are supporting 'prototypes'. Apple for example developed a system called Sk8 in Macintosh Common Lisp, which made extensive use of prototypes for multimedia UI tool development. With the advent of CLOS those were not used for typical OO programming in Lisp - not because people don't like it, but because another standard system was provided.
felixgallo 11y ago
One wonders how we get out of this mess. You'd have thought that Microsoft/Google/Apple/whomever would have at least tried to include a better alternative language in their browser by now. What stops them besides inertia?
- tim333 11y ago
  They've tried Typescript and Dart. No massive uptake to date. WebAssembly may be a way forward.
  - davnicwil 11y ago
    Typescript transpiles to Javascript - its purpose is to allow static type-checking of regular Javascript code by dev tools, prior to transpilation. AFAIK It has no features which would benefit from being used at runtime and there's never been any intention to run it straight in the browser. (If I'm wrong please correct me)
  - Someone 11y ago
    That takes out Microsoft and Google from that list. Also, ‘whomever’ already had its opportunity with Java. So one could conclude the wait is for Apple with Swift. But would they want that? I think they would rather see people write iOS-specific apps in Swift. Of course there may be another 'whomever'. Facebook with Hack, perhaps? Their advantage may be that they aren’t big in hardware or operating systems, but I still think they are too big and therefore deemed too dangerous by the likes of Apple, Google, and Microsoft. I think the only way is for some small player to come out of nowhere and somehow take the world by storm, probably, as you say, by riding on top of WebAssembly. (by the way, I don’t think WebAssembly will be the leveller that allows everybody to pick his own language to develop in for the web. I think we will see some high-level API in WebAssembly develop that fits one language better than others. Of course, we could again choose to make “C” that language and that way allow almost any language interface with any other language through a crude interface, but I would hope we can do better by now)
  - mightybyte 11y ago
    If WebAssembly doesn't get proper support for tail call optimization, then IMO it's not the way forward. Right now it's listed as a future feature[1] so color me skeptical. [1] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#signature-restricted-proper-tail-calls https://github.com/WebAssembly/design/blob/master/FutureFeat...
blhack 11y ago
This is absolutely a NIGHTMARE for new developers. People come into the language, and there are what seems like an infinite number of "the only right" ways to do something, all of vary degrees of complexity/usefulness, and all claiming that they are god's gift to computer science. That last part is the part that is most frustrating to me, and it isn't unique to javascript. Google, facebook, yahoo, etc. have all gotten along pretty much just fine up until this point using existing web technologies. We should ALWAYS be trying to improve those technologies, and we should ALWAYS being trying to improve the workflows involved in using those technologies, but what comes across as ridiculous is the apple-style "this literally solves everything, and everything before it totally sucks and is useless and you are stupid for using it" marketing behind them. I like javascript. A lot. I use it every single day, and it does a lot of useful things for me. But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense. Javascripters, I get it, you're really excited. I am too. But maybe tone it down just a few notches. Here's a thing I wrote about this topic a few years ago: http://thingist.com/blog.html?id=21434 http://thingist.com/blog.html?id=21434
- joshuapants 11y ago
  > People come into the language, and there are what seems like an infinite number of "the only right" ways to do something, all of vary degrees of complexity/usefulness, and all claiming that they are god's gift to computer science. Maybe we need to start proselytizing and make all the incoming Javascripters repeat: "There is no god but Crockford, and JSLint is his prophet."
- noir_lord 11y ago
  I just use Knockout.js unless there is a really compelling reason not to, I just chose one and learnt it decently well. It supports IE (back to 6 believe it or not), is backwards compatible with itself, is relatively mature, very stable, performs fine, supports modern stuff like component orientated architectures and custom tags (if you want them), interops brilliant with lo-dash/jquery and grows with you, it's also way more of a library rather than a framework so there is very little koolaid, the devs answer on github and are active (if not a huge community). I also rather like it's <button data-bind="click: someFunction">Do The Thing</button> binding syntax (not least because with phpstorm and pycharm you can create custom language injections on XML attributes meaning I can do jump to definition near perfectly).
javajosh 11y ago
"Let's put a weak language on a billion screens and see what happens." The browser is Arrakis, and JS devs are the Fremen, hardened and shaped by an environment that is just barely survivable. Let us hope our own Golden Path is less painful than in Dune.
- thiagowfx 11y ago
  Great analogy!
Xeoncross 11y ago
I learned a while ago that it doesn't matter how broken something is if everyone is using it. Humans are incredibly resourceful, if not also short-sighted. Look at PHP, look at Javascript, look at Wordpress, look at email, look at the original jQuery etc...
- vezzy-fnord 11y ago
  Email is one of the least broken communication protocols we have. Which says something.
  - Xeoncross 11y ago
    Email it's the only free, distributed protocol we have at a large scale. I love that. But email is broken in many ways and adding basic requirements like encryption is still not possible on a large scale do to lock-in.
    - fallat 11y ago
      There is already encryption for email. It's called PGP and it works really well already.
      - Xeoncross 11y ago
        like I said, lock-in
    - thiagowfx 11y ago
      Why do you think e-mail is broken? Could you elaborate please?
- agumonkey 11y ago
  Universities try to convey this. My final year was more about project management, technology was one variable and nothing else (one of few values of UML is that it tries to be agnostic, even though hyper c++/OOP centric). And thanks to Sir Turing and his friends, you know you can always solve the problem with whatever language/system you have.
Nadya 11y ago
I'm not sure how to interpret the last part... "Where I am from, the point of digging is not freedom from digging." Is it a statement that the point of digging is to reach further and learn more (positive)? Is it a statement more along the lines of "We dig because we must dig to survive." (negative)? Or possibly that digging is simply a way of life (negative)?
- vbnmvbnmvbnm 11y ago
  It's a joke, that's the punchline. The corollary being the axiom: "If your problem is that you're stuck in a hole, the first part of fixing that is: do not make the hole deeper by digging, since that makes the problem worse." As opposed to the mindset of developers being akin to a coal miner, where the goal is to dig, and a bottomless pit is not a problem, it's the goal. (in other words you stay employed) Consider the lyrics from the song Trust Your Mechanic by Dead Kennedys. Trust your mechanic to mend your car. Bring it in to his garage. He tightens and loosens a few spare parts. One thing's fixed, another falls apart. Trust your mechanic to make you well. You're seeing an awful lot of him now. The quicker he makes your life fall apart, The more money you put in his pockets.
- mattchamb 11y ago
  I take it to mean that if you keep digging, the hole will just be deeper. I.e. you cant dig yourself out of a hole.
  - Nadya 11y ago
    What are you doing when you "dig into a problem"? :) I have a feeling the intent was supposed to be pessimistic/negative (as you stated). I decided to have some fun with the words. It leaves a few possibilities as to the meaning and speaks well of what the developers are typically doing in their "problem solving": digging deeper (for knowledge) rather than trying to get out of a hole. "People who cannot dig themselves out of a hole have never tried digging sideways." - JS Developer
    - vbnmvbnmvbnm 11y ago
program247365 11y ago
JavaScript is both easy to get into, but difficult to master. There are places on your path to JavaScript mastery where you're literally like, "Did I make the right choices in my life?". Push a little harder, and like anything, the added effort to understand the choices put in front of others, and why something works the way it does, will be rewarding. Illustrations/points like cube-drone has made here are popular because it's partly an over-exaggeration, and partly true. People on either side of the fence (JS mastery, or not), can find some kind of common ground of, "Right?? Isn't it painful??" It's painful if you let it be. With the right mentors, and the right motivation, you can make JavaScript do wonderful things. As a whole I think JavaScript has made the web a more fun and interesting place, no matter how much you want to bitch about the language or the ecosystem. We stand on the shoulders of giants, and I, for one, appreciate it. Thanks Brendan Eich! :)
- coldtea 11y ago
  >JavaScript is both easy to get into, but difficult to master. There's no such thing as "mastering Javascript", because a language includes it's ecosystem, and for JS this changes from day to day...
Cshelton 11y ago
When I write c# code, it's just that, code. When I write Rust code it's just code. When I write JavaScript...I'm making beautiful peices of art. Almost like an old school watchmaker...a million ways to do the same end result.
deleted 11y ago
[deleted]
UUMMUU 11y ago
I'm lost as to why Grunt is a problem. I tried to put all of my build scripts in the package.json but moving to Grunt has been incredibly useful.
- kentor 11y ago
  Because "code over configuration". Personally I'm not a fan of Grunt's API which requires huge json files where keys mean special things. It feels very ad hoc and ugly. Gulp's API is like 5 functions.
wwwtyro 11y ago
"Problem: asm.js is basically unwritable by humans." I have no idea where this is coming from, but it's simply untrue. See [1] for a ton of examples of it being perfectly human read/writable. All I can come up with is that people are looking at code compiled to asm.js, which is of course going to have all semantic meaning stripped from it, no different than code compiled to javascript. [1] http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/
- dbattaglia 11y ago
  I wonder if people just say that now without actually looking. The last time I saw any asm.js code it looked like very boring old c++ code, nothing crazy. Probably more readable to a newcomer than closures or self calling anonymous function wrappers.
ScottWRobinson 11y ago
While there's a lot of truth to this comic, I don't necessarily see it as a bad thing. I think it speaks to the flexibility of JavaScript. Sure, all of the tools and libraries can be hard to keep up with, but I'd rather have lots of community support than none. I have to admit, I was a JavaScript hater for a long time, up until recently when I actually spent time to learn the language. Now its quickly becoming one of my favorite server-side languages. Isomorphic JS was too hard to resist :)
- po 11y ago
  So, you're saying you've become the guy with the hat. :-)
  - ScottWRobinson 11y ago
    Haha yup, pretty much
vectorpush 11y ago
> the ecosystem around Javascript is so densely layered and frequently changing that maintenance of any project over any significant period of time is going to be a nightmare I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving. Oh, but you want to leverage the latest and greatest that the ecosystem has to offer... well, that's your problem, not the ecosystem's and this is true no matter which ecosystem you're referring to. JS developers are just spoiled rotten because JS is so easy to refactor relative to every other part of the system. When the NoSQL hype train came barreling through the developer community a few years back, most of us didn't rush out to rebuild our applications on a NoSQL back-end because the database is too critical to mess around with. If you want the latest and greatest you have to pay for it, but don't imply that there is something wrong with the ecosystem for giving you more options. Choosing the best tool is part of the job, and if you get hypnotized by every shiny new toy that debuts on the front page of HN, that's a professional flaw that only you can fix.
- ozziegt 11y ago
  >I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving. This is a really shortsighted viewpoint. Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries.
  - vectorpush 11y ago
    > Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries. As I already stated, that's your problem, not the ecosystem's. If everything has been working fine for a year, but now you want to introduce a new library into the code, it's up to you to rationalize the necessity of that addition with the technical burden of updating your dependencies. Nobody is forcing you to use this new library and the only reason you can even consider this library as a potential addition to your application is precisely because the fast moving ecosystem has managed to provide you with a must-have library that you didn't need a year prior. That is simply the fundamental nature of dependencies and will be true no matter which ecosystem you're working with, hence the ubiquity of package managers like npm, rubygems, composer etc. Either way, just because something exists, doesn't mean you have to use it.
anotherangrydev 11y ago
Problem: Javascript has almost no standard library. --> Why is this a problem? What does he mean by standard library? Like, "strings", regexes and hashes? Not needed. Problem: Javascript won't run outside the browser. --> Fixed. Problem: The DOM is too slow for video games. --> Fixed. Problem: Javascript is single-thread by design. --> Why is this a bad thing? Problem: Javascript is too slow for video games. --> [Citation needed] Problem: Javascript has no packaging or a linker to tie these packages together. --> Linker's not needed, and there are many package managers that work pretty good. Also, since the beginning of javascript you could always <script src=""> whatever you need, pretty cool actually. Problem: Callback Hell. --> This "problem" only bothers bad/lazy/naive coders. Problem: asm.js is basically unwritable by humans. --> Nope, and also, you may not need to write asm.js at all. Problem: Prototypal inheritance is just pants-on-head stupid. --> Clearly a joke to try to use this as an argument. Problem: Web resources need to be minified and zipped for performance. --> Yeaaaaah right, because Javascript == Web. Problem: Machine generated output is more difficult to debug. --> As compared to... another machine generated output from a compiled language? Yeah right... Problem: Async is still a nightmare, huh? --> Same as callback hell. Problem: Balloning project size and complexity. --> [Citation needed] Problem: Javascript still doesn't do everything. --> Is this guy serious? Does he thinks this is a valid argument for anything? Problem: Output runs very slowly on mobile devices. --> [Citation needed] The guy's just a lazy coder. His favorite language would be one where he could just do: "include <what_my_boss_wants>; run();". Good luck waiting for that one.
- MasterScrat 11y ago
  I... somehow disagree with everything you are saying, sorry.
  - andresmanz 11y ago
    Maybe it's because of that attitude of forcing JavaScript upon everything, instead of simply using the appropriate tools. That's what I expect from people like this comment writer, and that's what causes that digging in the comic.
- collyw 11y ago
erikpukinskis 11y ago
This is a double edged sword. Yes, web technologies are sprawling, but they are also constantly improving, which is not always true of the more tightly controlled platforms. You can build on iOS for example, where there are generally only a few ways to do things. But then you're waiting on Apple to release new stuff. There will always be platforms that are the Wild West, build-your-own-adventure decentralized toolkits and others that have a narrow political agenda and are more stable. Neither is better, it's just a question of what kind of frustration hurts you less.
deleted 11y ago
[deleted]
ciaoben 11y ago
Just a little advice for newcomers ( like me ) that are scared but at the same time fascinated when it comes to use javascript. If you choose a framework to work with, stick to it for the entire project, and if you find an error that makes you struggle, don't immediately invent your own solution to patch it: for all the things that are said in this article, it always easy being attract to the fact that in every framework/code base you can put a simple piece of code that make things simpler for your and let you go ahead when you are stuck. But in my experience, most of the times, it only about being lazy and scared from and understood error. Behaving like this it let you behind, and don't make you improve your skills. And always break the entire logic of the tools you're using. JS is a scripting language, so it easy 'script' your solution and postpone a problem. But it this way, you will never be able to improve, and your life with JS will remain frustrating and hard.
gotofritz 11y ago
I actually think the "blame" is not so much Javascript's - after all it has existed since 1996 and it wasn't like that at all for many years. I wonder how much the rise of Github's / npm have to do with it. In the last 5 years or so it has become so much easier to create and share projects. Not only so - it has become a requirement, people use Github as their CV, we are all _expected_ to have side projects and stuff.

213 points by ScottWRobinson 11y ago

drKarl 11y ago

I wish I could upvote it more...

cube-drone 11y ago
you and me both, buddy :3
adam12 11y ago
Well, you could create another account... (I'm a javascript developer)

andrewchambers 11y ago

The thing I like about clojurescript is the fact that it has a linker and library system which makes sense.

robertfw 11y ago

Problem: browsers are designed for documents, not rich applications Solution: javascript

collyw 11y ago
Problem: JavaScript is the only language that runs in all major browsers. So far no solution.

wwweston 11y ago

"Prototypal inheritance is pants-on-head stupid." Well, he's almost merely wrong, if he were to take out the "prototypal" part.

SomeCallMeTim 11y ago
Prototypal inheritance works well, if you understand it. It's only "wrong" if you're of the Java/C++ OOP religion.
- deleted 11y ago
  [deleted]
- tolmasky 11y ago
  > if you understand it Someday we'll figure out that this is the problem with most features.
- bwaxxlo 11y ago
  I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Overall, the more I understand JS, the more I'm convinces most issues raised are personal preferences.
  - atinoda-kestrel 11y ago
    > I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
    - lispm 11y ago
      Not really. The idea of protypical object-systems is for a large part coming out of the Lisp community (and the Smalltalk community) and was used long before Self or Javascript. Check the works of Henry Lieberman. The Self developers got the idea of 'delegation' from him. Object Lisp was a prototype-based object system used in LMI's Lisp Machine OS and in Macintosh Common Lisp (until it was replaced by the then developed standard CLOS). Various Lisp-based systems were developed in the 'knowledge representation' domain, which are supporting 'prototypes'. Apple for example developed a system called Sk8 in Macintosh Common Lisp, which made extensive use of prototypes for multimedia UI tool development. With the advent of CLOS those were not used for typical OO programming in Lisp - not because people don't like it, but because another standard system was provided.

felixgallo 11y ago

One wonders how we get out of this mess. You'd have thought that Microsoft/Google/Apple/whomever would have at least tried to include a better alternative language in their browser by now. What stops them besides inertia?

tim333 11y ago
They've tried Typescript and Dart. No massive uptake to date. WebAssembly may be a way forward.
- davnicwil 11y ago
  Typescript transpiles to Javascript - its purpose is to allow static type-checking of regular Javascript code by dev tools, prior to transpilation. AFAIK It has no features which would benefit from being used at runtime and there's never been any intention to run it straight in the browser. (If I'm wrong please correct me)
- Someone 11y ago
  That takes out Microsoft and Google from that list. Also, ‘whomever’ already had its opportunity with Java. So one could conclude the wait is for Apple with Swift. But would they want that? I think they would rather see people write iOS-specific apps in Swift. Of course there may be another 'whomever'. Facebook with Hack, perhaps? Their advantage may be that they aren’t big in hardware or operating systems, but I still think they are too big and therefore deemed too dangerous by the likes of Apple, Google, and Microsoft. I think the only way is for some small player to come out of nowhere and somehow take the world by storm, probably, as you say, by riding on top of WebAssembly. (by the way, I don’t think WebAssembly will be the leveller that allows everybody to pick his own language to develop in for the web. I think we will see some high-level API in WebAssembly develop that fits one language better than others. Of course, we could again choose to make “C” that language and that way allow almost any language interface with any other language through a crude interface, but I would hope we can do better by now)
- mightybyte 11y ago
  If WebAssembly doesn't get proper support for tail call optimization, then IMO it's not the way forward. Right now it's listed as a future feature[1] so color me skeptical. [1] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#signature-restricted-proper-tail-calls https://github.com/WebAssembly/design/blob/master/FutureFeat...

blhack 11y ago

This is absolutely a NIGHTMARE for new developers. People come into the language, and there are what seems like an infinite number of "the only right" ways to do something, all of vary degrees of complexity/usefulness, and all claiming that they are god's gift to computer science. That last part is the part that is most frustrating to me, and it isn't unique to javascript. Google, facebook, yahoo, etc. have all gotten along pretty much just fine up until this point using existing web technologies. We should ALWAYS be trying to improve those technologies, and we should ALWAYS being trying to improve the workflows involved in using those technologies, but what comes across as ridiculous is the apple-style "this literally solves everything, and everything before it totally sucks and is useless and you are stupid for using it" marketing behind them. I like javascript. A lot. I use it every single day, and it does a lot of useful things for me. But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense. Javascripters, I get it, you're really excited. I am too. But maybe tone it down just a few notches. Here's a thing I wrote about this topic a few years ago: http://thingist.com/blog.html?id=21434 http://thingist.com/blog.html?id=21434

joshuapants 11y ago
> People come into the language, and there are what seems like an infinite number of "the only right" ways to do something, all of vary degrees of complexity/usefulness, and all claiming that they are god's gift to computer science. Maybe we need to start proselytizing and make all the incoming Javascripters repeat: "There is no god but Crockford, and JSLint is his prophet."
noir_lord 11y ago
I just use Knockout.js unless there is a really compelling reason not to, I just chose one and learnt it decently well. It supports IE (back to 6 believe it or not), is backwards compatible with itself, is relatively mature, very stable, performs fine, supports modern stuff like component orientated architectures and custom tags (if you want them), interops brilliant with lo-dash/jquery and grows with you, it's also way more of a library rather than a framework so there is very little koolaid, the devs answer on github and are active (if not a huge community). I also rather like it's <button data-bind="click: someFunction">Do The Thing</button> binding syntax (not least because with phpstorm and pycharm you can create custom language injections on XML attributes meaning I can do jump to definition near perfectly).

javajosh 11y ago

"Let's put a weak language on a billion screens and see what happens." The browser is Arrakis, and JS devs are the Fremen, hardened and shaped by an environment that is just barely survivable. Let us hope our own Golden Path is less painful than in Dune.

thiagowfx 11y ago
Great analogy!

Xeoncross 11y ago

I learned a while ago that it doesn't matter how broken something is if everyone is using it. Humans are incredibly resourceful, if not also short-sighted. Look at PHP, look at Javascript, look at Wordpress, look at email, look at the original jQuery etc...

vezzy-fnord 11y ago
Email is one of the least broken communication protocols we have. Which says something.
- Xeoncross 11y ago
  Email it's the only free, distributed protocol we have at a large scale. I love that. But email is broken in many ways and adding basic requirements like encryption is still not possible on a large scale do to lock-in.
  - fallat 11y ago
    There is already encryption for email. It's called PGP and it works really well already.
    - Xeoncross 11y ago
      like I said, lock-in
  - thiagowfx 11y ago
    Why do you think e-mail is broken? Could you elaborate please?
agumonkey 11y ago
Universities try to convey this. My final year was more about project management, technology was one variable and nothing else (one of few values of UML is that it tries to be agnostic, even though hyper c++/OOP centric). And thanks to Sir Turing and his friends, you know you can always solve the problem with whatever language/system you have.

Nadya 11y ago

I'm not sure how to interpret the last part... "Where I am from, the point of digging is not freedom from digging." Is it a statement that the point of digging is to reach further and learn more (positive)? Is it a statement more along the lines of "We dig because we must dig to survive." (negative)? Or possibly that digging is simply a way of life (negative)?

vbnmvbnmvbnm 11y ago
It's a joke, that's the punchline. The corollary being the axiom: "If your problem is that you're stuck in a hole, the first part of fixing that is: do not make the hole deeper by digging, since that makes the problem worse." As opposed to the mindset of developers being akin to a coal miner, where the goal is to dig, and a bottomless pit is not a problem, it's the goal. (in other words you stay employed) Consider the lyrics from the song Trust Your Mechanic by Dead Kennedys. Trust your mechanic to mend your car. Bring it in to his garage. He tightens and loosens a few spare parts. One thing's fixed, another falls apart. Trust your mechanic to make you well. You're seeing an awful lot of him now. The quicker he makes your life fall apart, The more money you put in his pockets.
mattchamb 11y ago
I take it to mean that if you keep digging, the hole will just be deeper. I.e. you cant dig yourself out of a hole.
- Nadya 11y ago
  What are you doing when you "dig into a problem"? :) I have a feeling the intent was supposed to be pessimistic/negative (as you stated). I decided to have some fun with the words. It leaves a few possibilities as to the meaning and speaks well of what the developers are typically doing in their "problem solving": digging deeper (for knowledge) rather than trying to get out of a hole. "People who cannot dig themselves out of a hole have never tried digging sideways." - JS Developer
  - vbnmvbnmvbnm 11y ago

program247365 11y ago

JavaScript is both easy to get into, but difficult to master. There are places on your path to JavaScript mastery where you're literally like, "Did I make the right choices in my life?". Push a little harder, and like anything, the added effort to understand the choices put in front of others, and why something works the way it does, will be rewarding. Illustrations/points like cube-drone has made here are popular because it's partly an over-exaggeration, and partly true. People on either side of the fence (JS mastery, or not), can find some kind of common ground of, "Right?? Isn't it painful??" It's painful if you let it be. With the right mentors, and the right motivation, you can make JavaScript do wonderful things. As a whole I think JavaScript has made the web a more fun and interesting place, no matter how much you want to bitch about the language or the ecosystem. We stand on the shoulders of giants, and I, for one, appreciate it. Thanks Brendan Eich! :)

coldtea 11y ago
>JavaScript is both easy to get into, but difficult to master. There's no such thing as "mastering Javascript", because a language includes it's ecosystem, and for JS this changes from day to day...

Cshelton 11y ago

When I write c# code, it's just that, code. When I write Rust code it's just code. When I write JavaScript...I'm making beautiful peices of art. Almost like an old school watchmaker...a million ways to do the same end result.

deleted 11y ago

[deleted]

UUMMUU 11y ago

I'm lost as to why Grunt is a problem. I tried to put all of my build scripts in the package.json but moving to Grunt has been incredibly useful.

kentor 11y ago
Because "code over configuration". Personally I'm not a fan of Grunt's API which requires huge json files where keys mean special things. It feels very ad hoc and ugly. Gulp's API is like 5 functions.

wwwtyro 11y ago

"Problem: asm.js is basically unwritable by humans." I have no idea where this is coming from, but it's simply untrue. See [1] for a ton of examples of it being perfectly human read/writable. All I can come up with is that people are looking at code compiled to asm.js, which is of course going to have all semantic meaning stripped from it, no different than code compiled to javascript. [1] http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/

dbattaglia 11y ago
I wonder if people just say that now without actually looking. The last time I saw any asm.js code it looked like very boring old c++ code, nothing crazy. Probably more readable to a newcomer than closures or self calling anonymous function wrappers.

ScottWRobinson 11y ago

While there's a lot of truth to this comic, I don't necessarily see it as a bad thing. I think it speaks to the flexibility of JavaScript. Sure, all of the tools and libraries can be hard to keep up with, but I'd rather have lots of community support than none. I have to admit, I was a JavaScript hater for a long time, up until recently when I actually spent time to learn the language. Now its quickly becoming one of my favorite server-side languages. Isomorphic JS was too hard to resist :)

po 11y ago
So, you're saying you've become the guy with the hat. :-)
- ScottWRobinson 11y ago
  Haha yup, pretty much

vectorpush 11y ago

> the ecosystem around Javascript is so densely layered and frequently changing that maintenance of any project over any significant period of time is going to be a nightmare I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving. Oh, but you want to leverage the latest and greatest that the ecosystem has to offer... well, that's your problem, not the ecosystem's and this is true no matter which ecosystem you're referring to. JS developers are just spoiled rotten because JS is so easy to refactor relative to every other part of the system. When the NoSQL hype train came barreling through the developer community a few years back, most of us didn't rush out to rebuild our applications on a NoSQL back-end because the database is too critical to mess around with. If you want the latest and greatest you have to pay for it, but don't imply that there is something wrong with the ecosystem for giving you more options. Choosing the best tool is part of the job, and if you get hypnotized by every shiny new toy that debuts on the front page of HN, that's a professional flaw that only you can fix.

ozziegt 11y ago
>I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving. This is a really shortsighted viewpoint. Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries.
- vectorpush 11y ago
  > Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries. As I already stated, that's your problem, not the ecosystem's. If everything has been working fine for a year, but now you want to introduce a new library into the code, it's up to you to rationalize the necessity of that addition with the technical burden of updating your dependencies. Nobody is forcing you to use this new library and the only reason you can even consider this library as a potential addition to your application is precisely because the fast moving ecosystem has managed to provide you with a must-have library that you didn't need a year prior. That is simply the fundamental nature of dependencies and will be true no matter which ecosystem you're working with, hence the ubiquity of package managers like npm, rubygems, composer etc. Either way, just because something exists, doesn't mean you have to use it.

anotherangrydev 11y ago

Problem: Javascript has almost no standard library. --> Why is this a problem? What does he mean by standard library? Like, "strings", regexes and hashes? Not needed. Problem: Javascript won't run outside the browser. --> Fixed. Problem: The DOM is too slow for video games. --> Fixed. Problem: Javascript is single-thread by design. --> Why is this a bad thing? Problem: Javascript is too slow for video games. --> [Citation needed] Problem: Javascript has no packaging or a linker to tie these packages together. --> Linker's not needed, and there are many package managers that work pretty good. Also, since the beginning of javascript you could always <script src=""> whatever you need, pretty cool actually. Problem: Callback Hell. --> This "problem" only bothers bad/lazy/naive coders. Problem: asm.js is basically unwritable by humans. --> Nope, and also, you may not need to write asm.js at all. Problem: Prototypal inheritance is just pants-on-head stupid. --> Clearly a joke to try to use this as an argument. Problem: Web resources need to be minified and zipped for performance. --> Yeaaaaah right, because Javascript == Web. Problem: Machine generated output is more difficult to debug. --> As compared to... another machine generated output from a compiled language? Yeah right... Problem: Async is still a nightmare, huh? --> Same as callback hell. Problem: Balloning project size and complexity. --> [Citation needed] Problem: Javascript still doesn't do everything. --> Is this guy serious? Does he thinks this is a valid argument for anything? Problem: Output runs very slowly on mobile devices. --> [Citation needed] The guy's just a lazy coder. His favorite language would be one where he could just do: "include <what_my_boss_wants>; run();". Good luck waiting for that one.

MasterScrat 11y ago
I... somehow disagree with everything you are saying, sorry.
- andresmanz 11y ago
  Maybe it's because of that attitude of forcing JavaScript upon everything, instead of simply using the appropriate tools. That's what I expect from people like this comment writer, and that's what causes that digging in the comic.
collyw 11y ago

erikpukinskis 11y ago

This is a double edged sword. Yes, web technologies are sprawling, but they are also constantly improving, which is not always true of the more tightly controlled platforms. You can build on iOS for example, where there are generally only a few ways to do things. But then you're waiting on Apple to release new stuff. There will always be platforms that are the Wild West, build-your-own-adventure decentralized toolkits and others that have a narrow political agenda and are more stable. Neither is better, it's just a question of what kind of frustration hurts you less.

deleted 11y ago

[deleted]

ciaoben 11y ago

Just a little advice for newcomers ( like me ) that are scared but at the same time fascinated when it comes to use javascript. If you choose a framework to work with, stick to it for the entire project, and if you find an error that makes you struggle, don't immediately invent your own solution to patch it: for all the things that are said in this article, it always easy being attract to the fact that in every framework/code base you can put a simple piece of code that make things simpler for your and let you go ahead when you are stuck. But in my experience, most of the times, it only about being lazy and scared from and understood error. Behaving like this it let you behind, and don't make you improve your skills. And always break the entire logic of the tools you're using. JS is a scripting language, so it easy 'script' your solution and postpone a problem. But it this way, you will never be able to improve, and your life with JS will remain frustrating and hard.

gotofritz 11y ago

I actually think the "blame" is not so much Javascript's - after all it has existed since 1996 and it wasn't like that at all for many years. I wonder how much the rise of Github's / npm have to do with it. In the last 5 years or so it has become so much easier to create and share projects. Not only so - it has become a requirement, people use Github as their CV, we are all _expected_ to have side projects and stuff.