JavaScript developers are incredible at problem solving, unfortunately

http://cube-drone.com/comics/c/relentless-persistence

by ScottWRobinson • 11 years ago

213 94 11 years ago

cube-drone.com

drKarl• 11 years ago

I wish I could upvote it more...

adam12• 11 years ago

Well, you could create another account... (I'm a javascript developer)

andrewchambers• 11 years ago

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

robertfw2• 11 years ago

Problem: browsers are designed for documents, not rich applications

Solution: javascript

collyw2• 11 years ago

Problem: JavaScript is the only language that runs in all major browsers.

So far no solution.

wwweston3• 11 years ago

"Prototypal inheritance is pants-on-head stupid."

Well, he's almost merely wrong, if he were to take out the "prototypal" part.

SomeCallMeTim2• 11 years ago

Prototypal inheritance works well, if you understand it. It's only "wrong" if you're of the Java/C++ OOP religion.

tolmasky• 11 years ago

if you understand it

Someday we'll figure out that this is the problem with most features.

bwaxxlo• 11 years 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.

wwweston3• 11 years ago

My comment is arguably overelliptical, so I'm going to 'splain:

1) I agree that the author sounds like a lot of developers who have a "What am I going to do without the exact class semantics I'm used to?" moment when they get to JS, and rather than learn to answer that question, they either decide that it's an inherent black mark on the language or go on a long quest trying to get something more like the semantics of another language in JS (often frustrating because it's almost possible).

2) More importantly, though... implementation inheritance itself is something a lot of thoughtful developers look on with a skeptical eye. Hence Gosling's comment about "I'd leave out classes" if he were starting over with Java, or Golang's interfaces. I wouldn't go so far as to call it "pants-on-head stupid" (I'll reserve contempt on that level for JS linters that enforce a no-semicolon policy), because it can be a nice mechanism for re-use, but it has its problems (fragile base class) and really only ever fits ideally to the extent that the portion of your domain you're modeling is actually a class hierarchy.

felixgallo2• 11 years 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• 11 years ago

They've tried Typescript and Dart. No massive uptake to date. WebAssembly may be a way forward.

davnicwil• 11 years 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• 11 years 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)

mightybyte2• 11 years 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/FutureFeat...

natrius• 11 years ago

I think you missed Dart. In any case, everyone agrees at this point that compiling arbitrary languages to Javascript or a Javascript-derived compile target is the way forward. Write ClojureScript.

TeMPOraL• 11 years ago

Funny thing: JavaScript was actually supposed to be Scheme, not once but twice, and both times it was scrubbed because Netscape was in fierce competition with Microsoft.

vezzy-fnord2• 11 years ago

One must wonder whether Netscape greenlighting the addition of a Scheme dialect simply would have caused Microsoft or another party to implement some flavor of ALGOL or BASIC in return and leave the hypothetical SchemeScript going the way of the dodo, much like Netscape's JavaScript Style Sheets that almost no one remembers today.

lkrubner2• 11 years ago

X, Flash, Swing, JavaFX, SilverLight, AWT and more were all attempts to offer a GUI over TCP. The important question is why they all failed. This is a complex issue and many good essays have been written that address parts of the question. Still, I think most of it can be boiled down to 3 things:

1.) some were closed-source and proprietary

2.) some were needlessly verbose, or enforced a workflow that made it difficult to interact with designers

3.) some depended on HTTP for at least the initial handshake

What the world needs is an open-source GUI technology that is fun for designers to work with and which uses a protocol other than HTTP.

My own bet would be that when we finally get such a technology, it will come from the world of gaming, where they already do amazing GUIs, and where they often abandon both HTTP and TCP and use UDP instead.

jacquesm• 11 years ago

Did X fail?

pags• 11 years ago

One was killed by Apple.

PopeOfNope5• 11 years ago

My own bet would be that when we finally get such a technology, it will come from the world of gaming, where they already do amazing GUIs, and where they often abandon both HTTP and TCP and use UDP instead.

Ever hear of scaleform[0]?

[0] http://gameware.autodesk.com/scaleform

Latty• 11 years ago

It's fun you say that, Valve just ditched Scaleform (industry-standard, based on Flash) for their own GUI stuff called 'Panorama' in DOTA2, which is XML, CSS and JS.

mightybyte2• 11 years ago

I want browsers to support a bytecode language designed from the ground up specifically for this purpose instead of just being a quick hack that by a fluke of history happened to get wide adoption. It would be more like .NET and the JVM in the sense that it would be designed for a specific purpose (a language suitable as a target language for compilers from a wide variety of high level languages). But we should not confuse that last sentence to mean that it should be similar to .NET or the JVM. I think two main design goals should be efficiency and good support for high level languages. This means proper support for tail call optimization so that functional languages like Haskell, Clojure, etc can generate efficient code. It might also mean some special considerations for garbage collection that I'm not knowledgable enough to comment on...amongst other things. WebAssembly sounds like the right idea but if they miss important things like TCO, then it's still not acceptable.

icebraining• 11 years ago

Regarding TCO on WebAssembly: "Yes, proper tail calls will be supported, but likely not in MVP."

https://github.com/WebAssembly/design/issues/189

https://github.com/WebAssembly/design/blob/master/FutureFeat...

freyr• 11 years ago

At the end of the day, you'll still be tied to the DOM, tied to poorly specified and poorly implemented HTML specifications (e.g, ContentEditable), tied to browser incompatibilities, and tied to CSS.

So the problem isn't just the lack of a viable JavaScript alternative. The problem is building on top of a weak, fractured foundation that was designed for an entirely different application than we now want.

PopeOfNope5• 11 years ago

I'd like a distributed app VM that's completely separated from the browser. Every time I think about this, I'm brought back around to this thought: why not java? Minecraft was a good proof of concept and it shows you can make a complex distributed application using java. So why are we tethering ourselves needlessly to the browser?

blhack• 11 years 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

joshuapants• 11 years 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• 11 years 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).

another• 11 years ago

Yeah, Knockout has also served us well: has been flexible as our architecture has shifted, and has progressed steadily without forcing us to pay a "framework churn" tax. It's become a mature, stable, pragmatic option, IMO.

daenz• 11 years ago

But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.

The problem with javascript libraries and frameworks is that, since the language itself has so many warts and quirks, it's easy to make a lot of "progress" patching over them with your unique library. So you come out on the other side, having won all these tiny victories, making things more sane, and I imagine most authors will believe their library literally "saves the day", when in reality, it just makes the language suck less.

PopeOfNope5• 11 years ago

I don't think the "javascripters" (whoever they are) are behind all the fragmentation. What we're seeing is caused by a low barrier to entry combined with a larger number of people who want to profit from a lucrative business pattern. That pattern is to create a technology that addresses a grievance (real or imagined), create a community around that technology to help promote it, then sell consulting fees once companies adopt it. This has worked brilliantly in the past (Enterprise Java in the 90s, Scrum, Ruby on Rails) and continues to make the companies behind it a lot of money in consulting fees.

sanderjd• 11 years ago

I don't think this is a good enough business model to explain so many tools popping up. Firstly, it's hard and expensive to make a tool good enough to become popular. But more importantly (and increasingly), it's extremely hard and very risky to build a community to a critical mass where it can sustain itself, precisely because there are so many tools competing for attention. I think tools pop up despite this difficulty and risk, because people have real itches they're scratching.

Introspectively, despite having many frustrations with my tools, and periodically coming up with ideas for tools that seem at the time like they might improve upon things, I know that my gut sense is not, "wow, I could just code this up, get a community going, and make tons of consulting cash!", but rather, "ugh that seems super hard and likely to result in many hours of unpaid labor, I'll just work around these issues and get back to work".

wwweston3• 11 years ago

But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.

As far as I can tell, this isn't a JavaScript problem -- it's a general problem, and it comes from the fact that creating specific & modest solutions to day-to-day problems often seems to be a worse way to advance your career than creating a tool or library that becomes part of How We Do Things Now™.

aburan28• 11 years ago

Exactly. You articulate my thoughts regarding JavaScript excellently

rrss1122• 11 years ago

I use Javascript every day. The cognitive load you're talking about doesn't exist with me.

On the browser, all I need is a library that handles DOM manipulation easily and has good browser support. When I find one, I stick with it for a long time and only change when something really exceptional comes along. Exceptional doesn't mean "literally saves THE WORLD", it means either comes up with better ways of accomplishing what my current library does, or does the same thing but with a huge decrease in file size.

I'm not interested in the flood of people trying to become the next John Resig. I'm just interested in getting stuff done.

javajosh• 11 years 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.

thiagowfx2• 11 years ago

Great analogy!

Xeoncross3• 11 years 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-fnord2• 11 years ago

Email is one of the least broken communication protocols we have. Which says something.

Xeoncross3• 11 years 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.

agumonkey2• 11 years 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.

copperx2• 11 years ago

And thanks to Sir Turing and his friends, you know you can always solve the problem with whatever language/system you have.

I'm tired of hearing this. Theoretically true, but infeasible in practice. Try to build an OS in JavaScript and see how long it takes you.

vlunkr• 11 years ago

Well, part of the problem in this case is that JS or something that compiles to JS is the only option for running in the browser, unlike PHP or Wordpress, which have many alternatives.

joshstrange2• 11 years ago

unlike PHP or Wordpress, which have many alternatives.

Except that's not really true. While other languages exist that CAN run on servers cheap shared hosting and the ease of dropping in PHP and having it "Just Work (tm)" is nothing to scoff at.

chuckcode• 11 years ago

qwerty keyboard is my favorite example. Designed to solve the key sticking problem when typing too fast but now we're all stuck with a layout designed to be inefficient.

https://www.addedbytes.com/blog/dvorak-vs-qwerty/

svisser• 11 years ago

By preventing the key sticking problem, it was more efficient than earlier designs - it wasn't designed to be inefficient.

PebblesHD• 11 years ago

For all the hype I hear about dvorak and other alternate keyboard layouts, I've never met anyone who could type significantly faster on it than I could on qwerty. This isn't objective in any way but from experience I can't say its any 'better'. As for ergonomics and other peripheral effects, I can't comment as I haven't looked into them.

thaumaturgy• 11 years ago

FYI, the "key sticking" origin of qwerty is probably a myth: http://www.smithsonianmag.com/arts-culture/fact-of-fiction-t...

Nadya2• 11 years 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)?

vbnmvbnmvbnm2• 11 years 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• 11 years 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.

Nadya2• 11 years 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

dazhbog• 11 years ago

I took it as a positive meaning.. The point of digging (suffering as a dev from all these new shiny things) is to reach a purity/elegance when writing code not only to just create/finish the project.

Another way of seeing it is when we fix bugs. Instead of fixing one thing and finishing it, we like to touch and try to fix all the things (mostly when we own the code).. Essentially digging your own grave.. sometimes.. :)

program247365• 11 years 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• 11 years 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• 11 years 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.

UUMMUU• 11 years 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• 11 years 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• 11 years 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/

dbattaglia• 11 years 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.

ScottWRobinson2• 11 years 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• 11 years ago

So, you're saying you've become the guy with the hat. :-)

ScottWRobinson2• 11 years ago

Haha yup, pretty much

vectorpush2• 11 years 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• 11 years 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.

vectorpush2• 11 years 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• 11 years 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• 11 years ago

I... somehow disagree with everything you are saying, sorry.

andresmanz• 11 years 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.

collyw2• 11 years ago

Indeed, if you could do:

"include <what_my_boss_wants>; run();"

why the hell would you not do that?

erikpukinskis• 11 years 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.

ciaoben• 11 years 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• 11 years 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.

JavaScript developers are incredible at problem solving, unfortunately

Related Stories