They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter how skilled I am.
I for one am hoping for a replacement for JS (that isn't Dart, which feels like JS Patched). I have more than just a hairy experience with JS lately.
If Javascript were limited to The Good Parts alone, it has the potential to be a beautiful well thought out language. It would be quite close to a beautiful well thought out language
All things considered, it could have been way worse than it is, and the truth is JavaScript lets you get in there and do good stuff. Not sure why we are still hating on this environment.
Testing is another point... having JS tests can help a lot, though my opinions of TDD aren't as strong as many.
[1] See here for more discussion and links to Crockford explaining the reasons: http://stackoverflow.com/questions/971312/why-avoid-incremen...
Abuses and problems precisely show Javascript's defects. The more easily abusable a language is, the more defective it is.
A lot can be said about familiarity with the language. Many examples in wtfjs.com boils down to (mis)understanding the language itself. Let's call this the cognitive overhead of a language - the amount of corner cases you have to store in your head about a language.
Surely a language with high cognitive overheads is more abusable than languages that have low cognitive overheads.
Incompetent python, C, or even scheme programmers wouldn't be able to shoot themselves in the foot (by shooting themselves in the foot, I mean having unexpected results - even with Undefined behaviours) as much as incompetent javascript programmers. That's my beef. I currently have no way of empirically proving that, but my gut is leaning that way.
No pointers, no memory allocation. Yeah JS isn't typed but the problems that you get into with that are nothing by comparison.
And again, I'm not saying JS doesn't have problems, it does. But the problems this presentation is complaining about are not results of flaws in JS they are results of incompetent developers.
So he's complaining about the wrong thing by complaining about JS.
It should be titled "I wish incompetent people wouldn't try to do things." And we'd all agree but then consultants like him would be out of a job.
There are definitely both of those things, they just aren't explicit in the same way.[1]
[1]: http://point.davidglasser.net/2013/06/27/surprising-javascri...
You mean no manual pointer management, no manual memory al location, right? Right?
> Yeah JS isn't typed but the problems that you get into with that are nothing by comparison.
Js is typed. Every language is typed. Is just isn't statically typed. Big difference.
>You are 100% wrong.
Strong words for someone who gets a lot of basic stuff wrong in a single paragraph.
In this case, a poor craftsman uses his tools to do the things that the browser already does for you.
I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.
If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.
So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM.
Let a compiler take care of all the numerous rough edges raw JS has.
No, it's not.
> ... and with asm.js, a pretty fast one.
And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a strictly defined ASCII-encoded bytecode that happens to be representable using a subset of valid JavaScript.
At which point, one must ask, what bizzaro-world engineering justification do we have for using a JavaScript subset as a first-order bytecode format? Why couldn't the silly JS bytecode format be a second-tier target for legacy browsers that don't support a proper format?
On top of which, why are we willing to throw away 2x+ performance (in the best case)? Is the iOS/Mac App Store not successful enough for us, such that we absolutely refuse to try something other than adding more JavaScript to every problem we face with web app deployment?
The 2x performance numbers for OdinMonkey are not "best case": they include compilation time and will certainly improve (they are better now already).
Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.
No, it's a strictly defined text-encoded bytecode that happens to be representable using a subset of valid JavaScript. If you deviate from the standard using valid JavaScript, you lose the gains.
Calling it "JavaScript" is just a semantic game. You can't output arbitrary but fully 100% standards-compliant JavaScript from a compiler and expect asm.js to do anything meaningful.
> Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.
The irony is that these things fail because of the people who wish to maintain the status quo, and then those same people point to the failure as justification for maintaining the status quo.
It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.
That's true for lots of JavaScript optimizations. JS optimization is all about speculation that the more dynamic features won't be used. Try adding calls to "eval" within a JavaScript function in any modern JS engine and watch its performance drop by an order of magnitude. Does that make functions that don't use "eval" no longer JavaScript? After all, adding a call to the standardized function "eval" negates the performance benefits of "eval"-less JS.
asm.js is just this principle writ large.
> Calling it "JavaScript" is just a semantic game.
No, it means that asm.js is backwards compatible. That is not a game; that is the entire point. That is why asm.js worked in Chrome (with good performance even!) from day one.
> It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.
Because PNaCl is not a good idea for Web content. People have this idea that Mozilla knows PNaCl is "better" than asm.js, but Mozilla wants to stick to JS out of some sort of pride or NIH syndrome. This is not the case. Backwards compatibility is the main advantage of asm.js, of course. But there are also many others: LLVM IR is a compiler IR and was not designed for this; asm.js is smaller when gzipped than LLVM bitcode; asm.js compiles faster than PNaCl; asm.js can reuse the JavaScript infrastructure, leading to a smaller, simpler browser; asm.js does not have the Pepper API which reimplements all of the Web APIs in underspecified ways.
OK, to be fair, the browser itself doesn't really need to be written in Java. But other than Javascript, (and maybe Flash, I suppose) Java bytecode probably has the most penetration as a mechanism for delivering "programs" over the web. Maybe we should just embrace it...
This complaining that JS is unusable is just BS and whining by people who are simply shying away from something they don't know.
There are bigger things that can bite even experienced developers like memory leaks and bloat but that has little to do with JS since you can fall into those pitfalls in any language.
I'm not attached to JS and have pretty much switched to CoffeeScript. I like CS better but that doesn't mean JS is anywhere near as bad as you make it out to be.
It's a bit ridiculous to say that anyone who complains about JS doesn't know it.
http://www.docstoc.com/docs/87338746/CIRCULAR-SAW-SAFETY-AND...
http://carpenterbooks.com/userFiles/556/frame_table_mw_pdf_2...
Even still, as the safety guide states, "Be careful, making one small mistake with a circular saw could be the last thing you ever do in your life"
JS is more a workshop that happens to contain, amongst its stations, a less-than-safe circular saw. And you can absolutely, productively use the shop without using the saw, or by using the saw, if necessary, with additional safety precautions.
And because some people use the saw willy-nilly, you're saying we should throw out the whole shop?
The fact that it's still insanely easier to write desktop apps, using one or two languages and a layout manager vs. dealing with two decades of WTF! web programming makes me sad.
You have component options around, mostly pretty new for building modular JS and building them for use in the browser as a single download. RequireJS in particular goes a long way towards helping with browser development. AMD lends itself more towards the browser, but there are build tools for CommonJS style modules as well.
If I were starting today, I'd probably have a reduced subset of what HTML is, with extension points for form inputs. The issue is that extensible/modular, skinnable and a centralized authority are points of contention for application building. I really liked Silverlight as a concept, I thought the package system was well thought out.
What I really didn't care as much for is how verbose XAML is. I can say most of the same about Flex+ActionScript. The problem is neither of these formats were open enough for browser vendors to simply have built-in support for them as a specification.
I think in a few years time, we'll look back on the current trend of client-side-all-the-things just as we now look back at Flash intro pages, pop-up ads and all that shit.
Why can't sites be like StackOverflow, it only uses JS where necessary.