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 :)
JavaScript developers are incredible at problem solving, unfortunately
51–60 of 100 posts
Re: JavaScript developers are incredible at problem solving, unfortunately
#52JavaScript 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…
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
#53I 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
#54Problem: 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
#55Earlier 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?
Re: JavaScript developers are incredible at problem solving, unfortunately
#56I 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.
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
#57This 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…
Re: JavaScript developers are incredible at problem solving, unfortunately
#58Earlier 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.
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"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.
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
#60One 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…
Ever hear of scaleform[0]?