The Artima Developer Community
Sponsored Link

Weblogs Forum
JavaScript Redux (and Closures)

29 replies on 2 pages. Most recent reply: Jul 15, 2011 1:12 PM by Bruce Eckel

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 29 replies on 2 pages [ 1 2 | » ]
Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

JavaScript Redux (and Closures) (View in Weblogs)
Posted: Jul 15, 2011 1:12 PM
Reply to this message Reply
It appears we are stuck with JavaScript, at least in the near-to-mid term. Although the language is an abomination, some things are getting better. I discovered a couple of great lectures and a book that might change your perspective (a little) about the language.

In addition, if you still don't understand closures, these lectures might solve that problem for you. In other languages, closures are presented as "it would be nice to have" without terribly compelling use cases. But in JavaScript, closures are essential in order to rescue the language from complete chaos. Closures are much more compelling and easier to understand within the context of JavaScript.

Why Am I Doing This? (The Decline of Flash)

I would probably be much more of a user interface (UI) guy if the tools didn't cause me to tear out handfuls of my now-precious thinning hair. Every single time I try to find a new and better way to do UI I run into everything from edge cases that the language designers didn't think were important, to downright bad design.

For quite awhile I've felt that programming Flash with Flex was going to be the good solution, because they started from scratch to specifically solve the UI problem, and "adapted" to the browser via a virtual machine (VM). Through one of my conferences, I knew about Flex before Adobe bought the company that created the technology, and it always seemed promising. For a time I was even writing and speaking about Flex.

Now that I examine my feelings a bit more deeply, I realize that my intuition was telling me, "Yes, but." As in, "But it's not going to work out in the long term." (My intuition is very mysterious and there's no logic to how it knows things. If there was logic, I guess I wouldn't need intuition).

This is not the fault of Flex, but rather an accumulation of occurrences (things like those I try to puzzle through in Reinventing Business). Of course a big change happened when Flash didn't keep up with handheld devices and it became clear that Flash was a drain on batteries (if we'd gotten better battery technology then things might have gone a different way, but even then manufacturers would probably just have made smaller devices. On handhelds, code efficiency is going to be an issue for a long time). Worse, Steve Jobs declared "no Flash on iOS." It's hard to ignore the direction of Apple these days. I know that Adobe is working on a solution for this, translating Flex into some kind of HTML5; perhaps this will pull the fat out of the fire but that remains to be seen.

Friends have been reporting stability issues with Flash. I've had it lock up the Chrome browser a couple of times. Basic quality control issues on such a (relatively) old (and essential) piece of software is a troubling development.

One of the big nails in the coffin for me happened when Adobe decided to drop support for Flex on Linux. It's not just the fact that they've backed away from a promise, it's the deeper implication: it means that bean counters rather than technologists are setting the goals for a technology company, and that has never turned out well.

I've declared elsewhere that "Trust is the first law of the Internet," and this is an example of that. If I can't trust that Adobe will support Flash on all platforms, then I can't get boxed into it. Thus I must start moving away from Flash as a general-purpose solution. As heinous as the alternative is (HTML/CSS/JavaScript), it seems we are doomed to it for the near term.

I still do like Flex and see it as a solution when you can control where it's being used, but if I was trying to build a general-purpose application that had the remotest chance of being used on handhelds (and these days, when is that not a possibility?) I'd have to use HTML5.

I do notice Adobe seems to be branching out; there's now a FlashBuilder 4.5 for PHP, although I have no idea what it even means to build Flash for PHP, unless it creates the front end as Flash and automatically connects it to a PHP back end and writes the necessary communication code for you. And FlashBuilder 4.5 is supposed to create apps that run on Flash-hostile handhelds like iOS, so all might not be lost in the Flash world.

I'd sure love to see Adobe use its formidable talents to create the ultimate HTML5 development environment. With their ability and reputation for tools, they could charge well for it and make a lot of money (after this article was written, Adobe announced an HTML5 tool for animation). I'm not holding my breath, but I'd strongly suggest they consider it. (The only recommendation I've gotten so far for an HTML5 IDE is Aptana so I don't yet know this space very well).

JavaScript is an Abomination

The first time I had to do something in JavaScript the experience made me recoil in horror. The syntax of the language varied across browsers! That was some years ago and things have improved (as long as you can assume more modern browsers), but it left a bad taste in my mouth.

I recently came across the lecture Javascript: The Good Parts by Douglas Crockford. He has studied JavaScript long and hard from a language scholar's perspective. He invented the JavaScript Object Notation (JSON) which has become an often-nicer-than-XML alternative for passing data around (there's even JSON-RPC for remote procedure calls; the Go language has this in their standard library whereas they have yet to implement XML-RPC). Crockford also created the very useful JSLint tool that checks your JavaScript for the legion of possible bad coding practices. Everyone should be using this.

Based on his lecture, I went out and bought his book of the same name. If you must work with JavaScript, this book is required reading -- it's not an introduction to the language, but it's necessary in order to understand the countless pitfalls and idiocies of the language.

If you have any doubts (or outrage) about my use of the word "abomination," Crockford's book will eliminate these. As you go through the book (which will probably require repeated readings if you are a serious JavaScript developer), your forehead will become red and splotchy from all the facepalming you do.

Seriously, it's incredible how bad this language is. And the deep irony is that there are now legions of programmers whose first experience has been writing JavaScript, typically copied from equally terrible "view source" examples they've seen on the web.

Crockford's book teaches you deeper ideas in the language and ways to (barely) bring it under control, but he shows you again and again how troubled and flawed this language is. And I love his arrogance; in the lecture he says that you can learn the wrong way to do things by reading "any other book on JavaScript."

The lecture Learning to Love Javascript by Alex Russell is a little more hopeful and gives you additional perspective on the language. Russell is on the committee and tells you how they're trying to improve things. He also works for Google, who seem to be adopting some variant of JavaScript to be used for scripting.

Closures and Why They're Essential in JavaScript

Closures appear to be the most misunderstood language feature I've ever seen. I cannot count the number of times I've seen writers equate closures to anonymous functions. This confused me for the longest time when I was trying to figure them out, and the propagation of this idea has confused many others as well (I suspect that a huge number of people in the Java community have been actually asking for anonymous functions when they've been saying closures).

Closure means that a block of code "closes over" variables defined outside that block. More importantly, those variables persist even after they would ordinarily have gone out of scope and disappeared. The closure captures and retains surrounding variables.

Javascript has no linker and this means there must be global variables. This is one of the worst things about the language. If you're creating small toy examples or simple scripts, this is tolerable. But JavaScript is used within your browser, which is an accumulative environment which assembles lots of code from lots of servers to present a page. And each piece of code makes its own global variables and functions which can collide -- at the time you load the page, so there's virtually no way to predict it -- with all the other code that's been loaded. Loading a page becomes a fantastic, spectacular war.

The solution is to use closures to create variables that are essentially private. Once those variables have gone out of scope (a tricky term in JavaScript, which has a different idea of scoping), they become unavailable and invisible except to the closure that captured them (often this closure happens to be an anonymous function, which contributes to the confusion about the term).

This is just one of the problems that you must solve in order to turn JavaScript into a tolerably controllable language. Crockford's book is all about these things, and once you read it you begin to understand why it's taken so long for AJAX libraries to appear -- first, enough people had to understand both the problems and the solutions and the need to standardize those solutions.

It also becomes clear that the only reasonable way to develop pages using JavaScript is to find and use the best AJAX libraries (at this point, I'm a novice and don't know what those are). Using JavaScript with AJAX seems to be much like programming in a slightly different language.

The Lack of Leadership

One thing that's very frustrating is how long we've been doing this, and how many opportunities that the various committees have had to try to fix things. I'm going to guess that there's been too much at stake and pressures from corporations have prevented anything useful from happening.

I don't know who to blame for the way that this has all happened. W3C, I suppose. It doesn't really matter. I can't imagine how we've managed to collect and save all these worst-possible decisions, but it looks like we're totally stuck with this mass of mess.

Really, after all this time there's no way to include standard headers and footers on a web page? And CSS -- who thought that was a good idea? (They couldn't even make a uniformly-adopted standard). It doesn't seem like complaining is going to do any good, either. These standards, as far as I can tell, are created in some kind of weird vacuum.

There is one way out that I can imagine. As the saying goes, the solution to all programming problems is to add another layer of abstraction. In this case, that means that we need a virtual machine for languages as part of the foundation for all browsers. Obviously, the default language distributed with browsers would be JavaScript with all its bad parts, but the virtual machine would allow the addition of many other options -- initially, as downloads but eventually as standard browser distributions. This way we could evolve to much more civilized and powerful languages.

The other layer of abstraction we need is a pluggable DOM. Again, this would allow much better DOMs to replace the crippled one that we must cope with now. Both the VM and pluggable DOM would be tricky to design and implement because of both backward compatibility and the need for cooperation within a single page. But it's important, because the browser is arguably the single most important piece of software in the world -- it's becoming the OS for the user -- and this problem needs to be solved.

The Rise of Alternatives

If I had to program in JavaScript for web apps, I would take a serious look at CoffeeScript (also recommended by Alex Russel). I hope we'll see more of these near-term alternative solutions to the problem.

Interestingly, the Google Apps Scripting language appears to be a (civilized) form of JavaScript, and it looks very powerful, so following my intuition and learning this could actually pay off in the short term. But I also suspect that I will (eventually) have no choice but to roll up my sleeves and wade into the muddy, messy morass that is HTML/CSS/JavaScript. I'm only hoping that, by finding the right tools, I can keep the mess below my knees. Well, below the waist, maybe.

Joaquin Garrido

Posts: 1
Nickname: jgarrido
Registered: Jun, 2008

Re: JavaScript Redux (and Closures) Posted: Jul 15, 2011 7:05 PM
Reply to this message Reply
Java and JavaScript are diametrically opposed (in-terms of the way one approaches typing, scoping, and... well pretty much everything but a big portion of shared syntax similarities), so I would caution an expert in one not to underestimate the challenges in attempting to delve into the depths of the other. It really does require an entirely different mindset.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Discipline in programming Posted: Jul 17, 2011 4:09 AM
Reply to this message Reply
Thanks for the link to the video: "Javascript, the good parts". Crockford basically says that Javascript is basically crap (which I and you agree with), so it is very important that you have be disciplined when programming in Javascript. For example you do not have to put semicolon at the end of the statements, but you should, because otherwise the compiler will do, and this can lead to hard-to-find errors. Another advice is: Terminate every case in switch with break, or don't use ++ or -- operator.

Michael Berkowitz

Posts: 1
Nickname: mberkowitz
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 17, 2011 5:41 AM
Reply to this message Reply
I'm wondering why you've cut Java applets out of the running. If it's because Swing is inferior to Flex (I have very little experience with either, myself), then have you looked at JavaFX 2.0 yet? It's being touted as -- among other things -- an easier-to-develop-with revamp of Swing.

All things being equal, there are lots of advantages to using Java on the client side, such as seamless use of the same classes on client and server and the advantages of the language itself over JS and AS, so I figure the problem has to be either the current GUI frameworks, the seamlessness of Java Web Start, accidental problems with integration of the JVM into various browsers or essential problems with the model of the integration.

I'm not lobbying, mind you, but it seems like a matter that should be investigated.

Nimrod Mesika

Posts: 1
Nickname: nimrodm
Registered: Feb, 2008

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 1:02 AM
Reply to this message Reply
You might want to check out "Eloquent JavaScript" by Marijn Haverbeke ( for a more optimistic view of Javascript.

In the right hands, Javascript can be a beautiful little language.

Tim Down

Posts: 1
Nickname: timdown
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 3:41 AM
Reply to this message Reply
I have some issues with this blog post:

- You say "The syntax of the language varied across browsers!" but this has never been the case to a serious degree. There are small syntactical variations (many of which are now gone since the release of IE 9) but these are not typically apparent to a novice. You're probably referring to differences in browsers' document object model (DOM), which is not the same thing.

- "Using JavaScript with AJAX seems to be much like programming in a slightly different language" is an odd statement, and I think untrue: Ajax (note capitalization) has absolutely nothing to do with the problems you see in the language. It is true that the rise of Ajax did bring about the rise of the big JavaScript libraries but that was because Ajax popularized JavaScript and led to greater appreciation of the issues involved in browser scripting, not because Ajax itself requires big libraries in order to be usable. Ajax is a relatively small concern in a general purpose library such as jQuery.

- Douglas Crockford has done a lot of good in the JavaScript community, particularly in education, and you're absolutely right as a self-confessed JavaScript novice to listen to him. However, the community has now caught up with him somewhat and the arrogance you mentioned is starting to look a little misplaced. His way is not the only way.

- You fire off aimless shots about the lack of leadership and specification decisions "created in some kind of weird vacuum", but the quickest web search would find you potted histories of how CSS, HTML and JavaScript got to this point, what is happening now to fix the situation, who is responsible for it now and how to contribute. Also, you admit to being a novice in the field yet apparently believe you know enough to sweepingly dismiss HTML, CSS and JavaScript as a collection of "worst-possible decisions". I don't think you have shown you have enough knowledge of the Web to make such a statement and be taken seriously, regardless of your expertise in other platforms.

In conclusion, I agree with you that there are certainly problems with the Web as a platform but your post does nothing to improve the situation.

Jochen Breuer

Posts: 1
Nickname: brejoc
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 3:43 AM
Reply to this message Reply
I would like to see something like the Mono CLR as a replacement for the JS engines. Then we would have the freedom to choose and even reuse code or libs no matter which language they are programmed in.

Dan Sickles

Posts: 9
Nickname: dsickles
Registered: Mar, 2007

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 4:32 AM
Reply to this message Reply
In addition to reading Crockford, you may want to check out Brendan Eich's blog. You'll find why Javascript is the way it is and where it's going (including fixing many of the problems).

The next version of Ecmascript will be a huge improvement

Targets for Scala include .NET (revived), LLVM and Javascript.

Bob Dobalina

Posts: 16
Nickname: hiredgoon
Registered: Apr, 2005

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 4:40 AM
Reply to this message Reply
> we need a virtual machine for languages as part of
> the foundation for all browsers.

Brilliant idea. So how do you go about making that happen?

Kevin Dangoor

Posts: 1101
Nickname: tazzzzz
Registered: Jul, 2003

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 5:35 AM
Reply to this message Reply
While a VM could happen, Brendan has told me a couple of times that some sort of VM is unlikely. That said, features like this one:

will help JavaScript become a better compilation target.

Also, as pointed out earlier, the inconsistent part is not generally JavaScript - it's the DOM and associated objects. Modern browsers are *way* better than what we had in the past, though!

Finally, I'll just note that a module system has reached "harmony" status. This means that the next version of JavaScript will offer modules, and those modules do not work with global variables. We will likely see them implemented in SpiderMonkey soon. (I don't know what v8's plans are there...)

BTW, Firefox already supports array comprehensions and generators, much like Python's (and not by coincidence!)

Do take a look at CoffeeScript, because it is quite pleasant.

Trond Olsen

Posts: 14
Nickname: tolsen
Registered: Mar, 2007

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 6:07 AM
Reply to this message Reply
>> we need a virtual machine for languages as part of
>> the foundation for all browsers.
>Brilliant idea. So how do you go about making that happen?
Native Client if things pan out.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 10:44 AM
Reply to this message Reply
Thanks for all the great links, everyone. I should point out that I'm not a complete novice -- I have developed with Javascript and CSS and periodically struggle with it enough to get some things done. Emphasis on "struggle."

I meant to say that Ajax libraries improve the experience of programming and in that way are like programming in another language. I look forward to experiencing the improvements once I can begin to understand which libraries are necessary and/or best.

It does seem like there has been lack of leadership in the committees, and some things like CSS seem to have been created in a vacuum. I do think the whole thing is a huge mess. The thought experiment is this: If we were to start from scratch, knowing what we know now, how different would the system and languages look? Of course this is impossible but it's a valuable metric to see how far we've diverged. I'd say that some things would look very similar but some things would be completely different.

This post was really meant as an an eyes-wide-open evaluation. The promise of HTML5 is a great improvement over what we've had, but there is remarkable suckage left in our tools. A significant portion of programmer time is going to be lost in navigating the suckage rather than being productive.

And yet, we seem to have no alternative. Flash looks to be veering off track, and maybe it will recover (but these things have a bad history -- by the time we the public can see the results, the underlying machinations have been broken for awhile and are typically encrusted in the organizational structure). Java Applets have long ago been relegated to the scrap heap, mostly because Sun never fixed the user experience. Admittedly, I only keep up on Java developments these days by listening to the Java Posse news during my infrequent long drives, but I was surprised to see that Oracle seems to have re-committed to Java FX (see so who knows what possibilities that might eventually produce. However, that still requires a VM and so cannot run on iOS devices.

So to me, right now, it looks like HTML5 is the horse to bet on to reach the largest number of devices. It will require a fair investment of time to learn how to avoid the hassles, and significant extra effort when programming. It also requires you to insist that the users upgrade their browsers to HTML5 which might not always be feasible (I've heard of some amazing libraries that fall back when older browsers are used). But I don't see any alternative right now.

MangalaSadhuSangeetSingh Khalsa

Posts: 1
Nickname: mssskhalsa
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 11:39 AM
Reply to this message Reply
Bruce - by "Ajax libraries" do you mean jQuery, Dojo, ExtJS?

If so, I think you're causing some confusion and should just say "Javascript libraries." jQuery is a Javascript library with a focus on simplifying DOM manipulation - Ajax is an important, but relatively small feature provided by jQuery.

Dojo and ExtJS are application frameworks with their own libraries for DOM manipulation and Ajax operations.

Programming with jQuery is indeed somewhat akin to programming in another language.

Amnon David

Posts: 1
Nickname: amnon8
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 3:16 PM
Reply to this message Reply
My two cents regarding "bad" languages:
I've written lots of code in more languages than I care to remember and over more years than I care to admit, and have to say that I never understood the bashing of any language. It's not that I'm oblivious to a specific language's faults- its just that they are never relevant. If I choose to implement something in a specific language (including JavaScript), it is because it is the best tool for the specific job I wish to perform. It doesn't mean it has no faults. What it does mean is that I just need adjust my programming to avoid those faults and to leverage the good parts. In time, as the language evolves, the good parts overweigh the bad anyway.

Hopeless optimist here... :-)

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 5:46 PM
Reply to this message Reply
> If I choose to implement something in a specific language
> (including JavaScript), it is because it is the best tool
> for the specific job I wish to perform.

Well, in my experience, the language chosen is most often the result of FOTM considerations of The Suits. If "best tool" were the criteria, far more SQL would be used. As it is, client code (in various source) is used far more than is warranted.

Flat View: This topic has 29 replies on 2 pages [ 1  2 | » ]
Topic: Big Python Previous Topic   Next Topic Topic: Fractal Duality and the Nature of the Universe

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use