JavaScript: The good and bad parts

March 18, 2010 4:50 PM

The Tale of JavaScript. I Mean ECMAScript. (MP4 version, slides) Yahoo! JavaScript architect Douglas Crockford, the creator of the JSLint JavaScript quality tool and the JSON data-interchange format, talks about what he says is simultaneously the worlds most popular and unpopular programming language. Previous JavaScript (sadly video linked by the FPP is down, try here). Previous Maniac Mansion. More video from MIX Online. A similar, more in depth talk at Google.
posted by Artw (48 comments total)

Oh, JavaScript, that is neither java nor a script,
hallowed be thy name
thy script tags come
they execution contexts be done
in the user's browser
as it is in mine
posted by GuyZero at 4:59 PM on March 18, 2010 [4 favorites]

Sorry, that prayer threw an error in my browser. Perhaps you should have ended every line in a semicolon?
posted by dw at 5:09 PM on March 18, 2010 [5 favorites]

JavaScript is actually really interesting from a pure PL standpoint. You get functions as first class objects, dynamic objects, "duck typing" all kinds of advanced "Stuff" that didn't make it to other mainstream programming languages in ...1995. Only until Python and Ruby came out did we see anything similar in 'mainstream' languages.

Yet, JS was never considered a "serious" language, even though pretty much every programmer knows it, and tons of people use it all the time in real web applications (at least a few snippets)
posted by delmoi at 5:19 PM on March 18, 2010 [1 favorite]

(okay so Python actually came out in '94, technically before JS, but still. It's taken a long time to get popular.)
posted by delmoi at 5:20 PM on March 18, 2010

Well you've got the no math except double precision floating point problem, which always bites the n00bs in the butt when they find out the hard way that the double-precision libraries don't round off for you, and 1/10 is an infinitely repeating binal that gets truncated if you don't explicitly round your results.

Then you've got no way to explicitly type variables so that the stupidly overloaded + operator has to guess whether that 3 + 3 should equal 6 or 33, and no Virginia there really isn't a clean way to force that particular issue.

Then you've got the fact that the language spec is too goddamn lazy (despite settling internally on double precision floating point math) to actually implement any math functions, so anything more complex than 4-function calculator land is relegated to the Math object.

Then you've got the case sensitivity combined with CapitalsAsSpaces which results in some truly hair-pulling case sensitivity bugs. And don't forget to capitalize the 'M' in Math all 10,000 times you use it today.

Then you've got the absolute lack of debugging support, so the typical typo results in a total crash with meaningless error message and no indication as to what part of the program where it happened, and the absolute flakiness of debugging support when it does exist, on all of the platforms where it's commonly used.

Than you've got the braindead and unstandardized DOM (which isn't really JS's fault, but it gets tarred with the same brush) which you have to manipulate via JS to get anything done in the environments where JS is used.

And all that's just off the top of my head, and it's been close to a year since I touched a web app. It's enough to make a person long for the days of 8-bit computers with 2-letter always global single precision variables, which at least reliably did what you told them to do and did it the same on every box.
posted by localroger at 5:34 PM on March 18, 2010 [17 favorites]

That, locarodger, is why we pray.
posted by GuyZero at 5:42 PM on March 18, 2010 [3 favorites]

Does your claim of an absolute lack of debugging support include Firebug and Firebug lite?
posted by honest knave at 5:44 PM on March 18, 2010 [2 favorites]

I once read something that described JavaScript as having incorporated every mistake ever made in programming language design, along with a few new ones. I think that is the perfect description.
posted by tom_r at 5:48 PM on March 18, 2010 [3 favorites]

Javascript? Luxury! We had LiveScript and we liked it. Now get off my lawn.
posted by grimjeer at 5:48 PM on March 18, 2010

FireBug doesn't do breakpoints very well, last time I used it.

You can find things to complain about in any programming language. JavaScript came out very well considering how it was designed in a hurry during the browser wars.
posted by zixyer at 5:50 PM on March 18, 2010

The Crockford on Javascript Series over at YUIBlog is great stuff in the same vein. I suspect a lot of the material is duplicated, but particularly the history of computing from his first talk is great general stuff.
posted by weston at 5:52 PM on March 18, 2010 [2 favorites]

JavaScript is a decent language, which wins many hearts (of people who learn it) because they're otherwise using PHP or VBScript, possibly the bottom two languages ever, for the rest of their work. @localroger, some of your examples are debugged in Crockford's example (and by his JSLint). Although there are certainly still things that annoy me, like how null references can cause V8 to just stop without explanation.
posted by tmcw at 6:07 PM on March 18, 2010

particularly the history of computing from his first talk is great general stuff.

Some of you might be going: woah, 'on mouseUp'? That sounds eerily familiar. This is where all that stuff came from.

This is making me feel a lot older than I am.
posted by grouse at 6:08 PM on March 18, 2010 [1 favorite]

Debugging tools have greatly improved in the past couple years. First Firebug, but now Chrome has a good set of tools and even the IE9 preview has a Firebug-like developer console (haven't played with it much, but it's a serious improvement over IE8 from the 30 min I spent with it). That being said, it's still my least favorite language of the ones I use commonly, but if you're doing anything with a web front-end it's not like there's a real alternative.
posted by wildcrdj at 6:10 PM on March 18, 2010

That, locarodger, is why we pray.

Error: locarodger is not defined
posted by oulipian at 6:13 PM on March 18, 2010 [14 favorites]

EBKAC.
posted by GuyZero at 6:14 PM on March 18, 2010

Javascript suffers from the fact that it's coded in the data stream. How many times has a page bug been related to the Javascript execution context accidentally modifying itself?

Non-techies: imagine if you were baking and the oven was an ingredient in your recipes.

But you know what? I love a challenge.
posted by Riki tiki at 6:20 PM on March 18, 2010 [1 favorite]

localroger: I'd agree having IEEE 754 as your only numeric type and the overloaded + operator are warts, and I could name others that bug me more (say, the results of NaN != NaN or typeof null). But it's never bothered me to have to invoke the Math object for operations, case-sensitivity is hardly unique or even inarguably poor idea, and debugging tools have been pretty good over the last few years (and even as far back as 2003, I was looking at script debuggers and error consoles with meaningful messages). And the first-class functions, dynamic objects, easy literals, the flexibility of the prototype-based object system... they're all lovely enough I find myself happy to write in the language more often than I find myself cursing the warts.

The braindead and unstandardized DOM you have my full agreement on. Maybe someday the DOM Level 5 recommendation will pretty much be jQuery.
posted by weston at 6:21 PM on March 18, 2010 [1 favorite]

weston, I appreciate your perspective; I have done a couple of really cool things in JS thanks to its cooler features. I have gotten an embedded controller with an AnyBus card and 256 bytes up/down shared RAM in an embedded controller to act like an AJAX app. It's not fast but it's smooth and powerful.

But double precision as your only numeric type isn't a wart. It is a huge, obnoxious insult to my intelligence and thorn in my side every time I want to do a rollaround counter calculation or just trust an equivalence test to succeed after a divide and multiply. It makes the platform useless on older equipment and less powerful than it should be on what equipment is available.

The Math object (not math or MATH, mind you) bothers me not just because it's syntactically ugly but because it suggests a total lack of thought on the part of the language designers. It's exactly like some guys I know doing embedded in another field who did exactly the same thing, "Oh we'll just throw double precision at it and then we won't have to worry about accuracy requirements." Only they did this on a 80186 so it crawled and THEN they didn't know about the rounding thing and it created something that would have been kind of like the Toyota acceleration thing if our industry made cars.

I don't want to encourage people to think "oh double precision then I don't have to worry about precision." I want them to fucking figure out how the math works. I want the language to make them figure it out. I don't want it to try to do it for them because it's a computer language, not a person, and it absolutely will do the figuring out wrong some day.
posted by localroger at 7:03 PM on March 18, 2010 [4 favorites]

Okay, I just got home from mix (*cough*EX04*cough*), and that talk sounded interesting... but I haven't been a front-end guy in ages. Still, I should have gone! I'm glad they're all videoed...
posted by flaterik at 7:24 PM on March 18, 2010

JavaScript always seemed like the old saying about mermaids, it is a woman when you want a fish and a fish when you want a woman.

I am a simple person and between jLinq and Soy Compiler I can do all that I need to do. I would love to see how a site like Mint.com is organized, for some reason the biggest obstacle for me is organization.
posted by geoff. at 7:34 PM on March 18, 2010 [2 favorites]

Wait a second, that NES Maniac Mansion guy and the Yahoo Javascript architect are the same person?

Some people seem to have gotten more than their fair share of awesome.
posted by JHarris at 8:17 PM on March 18, 2010 [2 favorites]

Some people seem to have gotten more than their fair share of awesome.

http://crockfordfacts.com
posted by device55 at 9:02 PM on March 18, 2010 [6 favorites]

everything locarodger was true in like 2002. also most of his complaints are about why javascript doesn't do some things it wasn't ever really designed to do.. like mathematics more complex than some rounding or basic geometry. Also one of those was just a gripe about camelcasing, and another was a gripe about lazy syntax in general. sounds like sour javagrapes, to me.
posted by judge.mentok.the.mindtaker at 9:19 PM on March 18, 2010 [2 favorites]

I don't want to encourage people to think "oh double precision then I don't have to worry about precision." I want them to fucking figure out how the math works. I want the language to make them figure it out. I don't want it to try to do it for them because it's a computer language, not a person, and it absolutely will do the figuring out wrong some day.

OMG that's definitely a reasonable requirement for SCRIPTING WEB PAGES.

. It's exactly like some guys I know doing embedded in another field who did exactly the same thing, "Oh we'll just throw double precision at it and then we won't have to worry about accuracy requirements." Only they did this on a 80186 so it crawled and THEN they didn't know about the rounding thing and it created something that would have been kind of like the Toyota acceleration thing if our industry made cars.

What's the "Toyota acceleration thing" of CLIENT SIDE WEB SCRIPTING?
posted by delmoi at 9:21 PM on March 18, 2010 [1 favorite]

Douglas Crockford uses IEEE 754 to calculate tips in his head.
posted by metaplectic at 9:53 PM on March 18, 2010

Neat! Thanks for posting this!
posted by ph00dz at 10:13 PM on March 18, 2010

JavaScript itself is actually a neat little language. It is the DOM that is a gaping maw into the madness of hell that is the problem.
posted by PenDevil at 12:00 AM on March 19, 2010

I'd like to see Lua in the browser. Very tight, very fast, and much better support for asynchronous requests. Although I'd like to sock Roberto in the eye for those 1-based arrays. It's ugly to see source code with +1 sprinkled everywhere.
posted by seanmpuckett at 5:10 AM on March 19, 2010 [1 favorite]

No love for jQuery?
posted by blue_beetle at 6:34 AM on March 19, 2010

I was requested to write up logistic regression in javascript once so that a html document count analyze a particular result while offline. That was a great time.
posted by a robot made out of meat at 7:24 AM on March 19, 2010

OMG that's definitely a reasonable requirement for SCRIPTING WEB PAGES.

And if that's all that JavaScript was used for, I'd agree completely. That's all LiveScript was intended for - the Netscape guys had no idea it would end up being used in so many other places: server-side web programming (in Netscape's own product and "classic" ASP), system/batch programming (Windows wscript/cscript), Flash programming (ActionScript), etc.

And, if you look into the likely future of JavaScript, via ECMAScript standards (ActionScript 3 is an interesting implementation following some of those standards), you end up with something a lot more like Java (or even more accurately, C#) than what most of us know today as JavaScript: class-based instead of prototype-based, strongly-typed instead of loosely-typed, etc).
posted by me & my monkey at 7:55 AM on March 19, 2010

PHP or VBScript, possibly the bottom two languages ever

I would disagree on PHP. It may be a Frankenstein language of parts pulled from just about every other language, and it may struggle with scalability and security, but PHP 5 is more robust and extensible than any other server-side scripting language. As well, the barriers to entry on PHP are much lower than JavaScript, which you can see as a blessing or a curse depending on how difficult it should be to build a website.

I lean to the side of "it should be simple." But then, I'm just a web developer/designer who fell into all this over a decade ago, not a programmer. I've dealt with one too many Java programmers who thought he knew how to build a website and proceeded to overwrite a simple web app that spit out crappy HTML.

Web development is to programming as paladins are to wizards. Web developers have to be able to flex between the view and the controller, but they're never going to be geniuses at either. Programmers are all about the magic and they couldn't give a damn about the view. Together they make a great team, but they shouldn't try to do each other's jobs.
posted by dw at 8:55 AM on March 19, 2010 [1 favorite]

class-based instead of prototype-based, strongly-typed instead of loosely-type

Interestingly Crockford seems to see both prototypes and loose typing as features rather than bugs, particularly prototypes.
posted by Artw at 10:02 AM on March 19, 2010

No love for jQuery?

jQuery is an awesome thing, made necessary by bugs and the DOM, neither of which are part of JavaScript. There was actually a LOT of love from jQuery from MIX, with it featuring heavily in the second keynote and some very good sessions, particularly the one by John Resig.
posted by Artw at 10:06 AM on March 19, 2010

(Some of those videos have horrible performance at the moment. Apparently that's going to get better as traffic from people fresh back from MIX dies down and as they get cached on the CDN)
posted by Artw at 10:09 AM on March 19, 2010

Is it too late for me to second Weston's comment? JavaScript became a much more pleasant language to work with when Firebug raised the bar for what an in-browser development environment should be. The debugger support is there, nowadays.
posted by Fraxas at 10:11 AM on March 19, 2010

Previous jQuery
posted by Artw at 10:13 AM on March 19, 2010

There's lots of video of Crockford talking about Javascript.

Only until Python and Ruby came out did we see anything similar in 'mainstream' languages.

Perl 5 was 1995. And it has closures and functions as first class entities and thus almost the full complement of functional programming tricks, like Javascript.

my $f = sub { return 1 + shift }; print $f->(3);

This and its implications were relatively little known or understood until Higher-Order Perl. Now they're a little more known and not much more understood. (Here's someone adapting Higher-Order Perl for Javascript.)

The typical Perl OOP method for many years (blessed hashref) offered duck-typing. But Perl's OOP support was more a toolkit to roll-your-own OOP solution than a specific OOP solution, so you could assert almost anything about Perl 5's OOP, and write code to prove yourself right.

Yes, yes, I know, dollar-signs and at-signs. eek. write-once. blah blah blah. But there can be little doubt Perl's a mainstream language.
posted by Zed at 10:24 AM on March 19, 2010 [2 favorites]

Web development is to programming as paladins are to wizards.

What I've learned from this thread:

Javascript, AKA ECMAScript, is a first-level paladin, who is sometimes a mermaid. She was born during the Browser Wars, which traumatize her to this day. She not the strong type, bad at math, and a little insecure. Her alignment is Chaotic Eval, and her abilities include scriptwriting and CamelHusbandry. She explores DOM, a gaping maw into the madness of hell, with the help of befriended Firefoxes and Firebugs, and her trusty sidekick JSON.
posted by oulipian at 10:57 AM on March 19, 2010 [12 favorites]

A powerful prototype mermaid/paladin who lacks class...
posted by Artw at 11:14 AM on March 19, 2010

http://crockfordfacts.com
posted by device55 at 11:02 PM on March 18 [6 favorites +] [!]

delicious suggested the 'awesome' tag when I saved that link, and I'm not going to argue.
posted by The Lurkers Support Me in Email at 11:33 AM on March 19, 2010

Uh oh...

We are currently experiencing issues with download speeds and buffering. The demand for the sessions videos has been extremely high and has exceeded our ability to serve these videos up with sufficient bandwidth. At this point, we are going to remove the links and the player from the site to allow our engineering team to push the content out to various media caches around the world. When that is completed (current estimate is 8PM PST) the result should be a much better experience and we will re-enable playback and download. Thank for your patience as we deal with this issue.
posted by Artw at 12:16 PM on March 19, 2010

if that's all that JavaScript was used for, I'd agree completely. That's all LiveScript was intended for - the Netscape guys had no idea it would end up being used in so many other places

This is why I'm somewhat sympathetic to complaints about the language. I don't have the depth of the negative reaction localroger does, but I want the bad parts of JavaScript to be better because I like the good parts enough that I actually want to write in it outside of the browser. I had a great time in December messing around with Java's MIDI libraries and Rhino. The amount of code I had to write to get fun musical results was pretty low thanks to some of the better features of JavaScript and the Java Libraries gave me an easy way to make sound. I'd be happy to write backends or desktop applications in JavaScript. Even despite its warts, it's easily my favorite of the curly-bracket-syntax of languages I've used (the others being C, C++, Java, and PHP).

if you look into the likely future of JavaScript... you end up with something a lot more like Java (or even more accurately, C#) than what most of us know today as JavaScript: class-based instead of prototype-based, strongly-typed instead of loosely-typed, etc).

If it really ends up being instead, that'd be a bit tragic; it'd likely kill a lot of the best things about the language. I don't think that's the direction ECMA is going with Harmony, though. From what I understand classes will apparently exist alongside prototypes and you'll have optional type annotations.

Perl 5 was 1995. And it has closures and functions as first class entities and thus almost the full complement of functional programming tricks, like Javascript.

About 10 years ago I was writing a Perl backend for a typing test and ended up using Algorithm::Diff from CPAN. The use I chose involved passing references to subroutines, an idea I was just barely familiar enough with from C. While looking through the Perl manual on references and subroutine, I came across the mention of closures. I read the description, tried to digest it, and couldn't. Probably because I was rigidly attached to the idea of block scoping (up until around this time, Perl's lexical scoping was something I found almost offensive). I sat on the idea for a few days, read the docs again, finally understood, but thought "that's weird, I don't think I'd ever use that." Funny thing, it was probably within a week or two that my boss refactored some of the code I was writing with a lexically scoped variable or two and a closure. I looked at the new code and had to admit it was probably better, and thought... "I'll have to keep that in mind."

Unfortunately, it still took me another 4-5 years to really start thinking using them. Coincidentally, when I did (and when I started being more liberal with object literals), that's when JavaScript stopped being horribly frustrating and started not only being fun but more fun than the other languages I was using.
posted by weston at 3:25 PM on March 19, 2010

delmoi: What's the "Toyota acceleration thing" of CLIENT SIDE WEB SCRIPTING?

Actually I work for an industrial scale company. The kind of applications I'm talking about do process control and data collection in lots of industrial automation systems. I could give lots of examples, but my favorite is the one that weighs 7 million pounds of sugar a day as it enters a local refinery, 30,000 pounds at a time. They had a dispute with a supplier a couple of years ago and they audited the system, flew people in from all over the world, hired a consultant who went over every line of the source code I wrote looking for any evidence that it might have caused the discrepancy. (It passed.)

I also did the recently retired truck scale at that same plant that measured about half that same sugar as it left, and I figured that in its 15 year lifetime the system I built accounted for well over $1 billion in transactions. If you get something like that wrong, you will wish you had only killed someone.

Of course, if you mess up process control well enough you can kill someone; I refigured one system about 6 years ago that occasionally buried trucks in coke (not the cola kind, the coal-like power-plant-fuelling kind). I consider that kind of thing embarrassing and strive to avoid doing it. (The system I built only did that once, when the hydraulics that weren't my responsibility failed. It was a much lower failure rate than the old system which would occasionally leave the fill doors open at random for reasons nobody could fathom.)

So why was I using Javascript? I needed a scale to be remotely controlled by multiple operators, and the easiest way to accomplish that was by making the remote control a web app getting its data from an AnyBus-S card in the scale. The paperwork (which they print from the browser) is still pretty important, most of the business logic is in Javascript because the AnyBus card is not smart enough to much server side processing, and it has to be right or the lawsuit dragon will fly.

I anticipate doing a lot more web apps in the future because I'm sick of trying to keep up with the PC interfacing treadmill and embedded controllers can now do very acceptable ethernet service, if you do the business logic in the browser. (Security is not an issue as nearly all of these systems are on intranets that don't connect to the cloud.) If I can use the browser for the fancy UI everyone expects but have the real controls on a card with no fans, HD motors, or other moving parts, and that card stays in place with all its data should smoke start pouring out of the operator's PC, it's win all around.
posted by localroger at 4:50 PM on March 19, 2010

So why was I using Javascript? I needed a scale to be remotely controlled by multiple operators, and the easiest way to accomplish that was by making the remote control a web app getting its data from an AnyBus-S card in the scale. The paperwork (which they print from the browser) is still pretty important, most of the business logic is in Javascript because the AnyBus card is not smart enough to much server side processing, and it has to be right or the lawsuit dragon will fly.

I remember back when the first Java SDK came out. It said right in the license you couldn't use it for anything where lives were at stake. I'm not sure they still have that in the license any more.

But why not use Java? You can still embed java in web pages, and now you can launch whole applications using java web start. You just put a Jar on your server rather then .JS files. And of course you get all the nice data types, byte arrays, pretty much everything you can do in C or C++ you can do in java (except maybe raw function pointers, but you can create anonymous inner classes... anyway)

Obviously, Swing apps aren't a slick and jQuery based dynamic web apps now, but they can be pretty nice.

How large are these applications anyway? I don't know if there are any JS IDEs that do nice code completion, intelisense, etc, but I can't imagine writing anything huge without all those nice features.
posted by delmoi at 9:27 AM on March 22, 2010

delmoi -- the JS apps I've done have tended to come out at a couple thousand lines. (Some other things, like the coke loading system, are more in the 10,000-20,000 line range, but I haven't tried JS at that level yet.) For development I've used both plain old Notepad and Notepad++, and while N++ has saved my butt a few times (particularly finding hairy mismatched bracket bugs) I usually only fire it up when I need it because I find all the flashy blinky hints more annoying than helpful. Of course I use Firebug but it's not always very helpful, since some of my stuff depends on real-time cooperation with other software at the other end and freezing the app breaks the transfer.

Since these are often deployed on someone else's tightly controlled corporate intranet I wanted them to work with no plugins that require permission to install on a locked-down machine. Some of these companies replace all their machines every X often (they're leased) so anything that has to be installed becomes a big recurring headache, which is another reason we went the web app route instead of writing an app in VB. They also have to work in IE6, though I made sure they work in Mozilla too.

Most of the really annoying work is already done; I've created a library of helper functions that target a subset of the DOM on a very specific template page. Doing a new app now would only require a few hundred lines of new code, and the end result is completely portable to any machine that can ping the anybus card's IP.
posted by localroger at 10:11 AM on March 22, 2010

Doug Crockford: Geek of the Week
posted by Artw at 12:20 PM on March 22, 2010