Live data from Hacker News

JavaScript developers are incredible at problem solving, unfortunately

cube-drone.com

51–60 of 100 posts

Re: JavaScript developers are incredible at problem solving, unfortunately

#51
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 :)

Re: JavaScript developers are incredible at problem solving, unfortunately

#52

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 be…

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

Re: JavaScript developers are incredible at problem solving, unfortunately

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

Re: JavaScript developers are incredible at problem solving, unfortunately

#54
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 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 ; run();". Good luck waiting for that one.

Re: JavaScript developers are incredible at problem solving, unfortunately

#55

Earlier quoted context omitted.

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 difficul…

Did X fail?

Yes. It's not in my browser.

Re: JavaScript developers are incredible at problem solving, unfortunately

#56
post #22

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

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.

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

Re: JavaScript developers are incredible at problem solving, unfortunately

#57
post #9

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 gotte…

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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#58
post #43

Earlier quoted context omitted.

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 difficul…

One was killed by Apple.

If you are talking about flash let's be clear. Flash was killed by mobile (and being generally shitty).

It's not like Apple said "Flash is the worst" and everyone said "Hey, you know I never thought about it like that". In fact I'm sure battery was a major reason not allowing flash, IIRC that (plus general indifference) was what was the nail in coffin for even android phones flash.

Re: JavaScript developers are incredible at problem solving, unfortunately

#59
post #7

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

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

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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#60

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?

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 difficul…

> 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

Post reply on HN