What happened to Dojo in 2008? This question was asked on StackOverflow. This is my personal take on the matter: on Dojo, jQuery, history, mistakes, marketing, social vs. technical, and communities.

This month I continued my presentation at ClubAJAX. Last time I did a survey of what is available in JavaScript, and concentrated on object-oriented (OOP) and aspect-oriented (AOP) techniques. This time I continued the survey, and talked about functional programming (FP), and domain-specific languages (DSL). And as promised I touched the code generation facilities too.

Today at dojo.connect I did a presentation "RAD CRUD": rapid development of form-based applications. It continues my other presentation "CRUD with Dojo", but it is more in depth, targets Dojo developers, and contains some advanced material.

I was asked to talk about advanced JavaScript techniques at the last monthly meeting of ClubAJAX — monthly get-together of Dallas-area JavaScript programmers. Instead I ended up talking about leveraging cool JavaScript features to implement well-known programming techniques and paradigms: OOP, AOP, FP, and so on.

Wolfram Kriesing asked:

Somehow I have the feeling that you can bend dojox's charting module to look and feel like http://highcharts.com/ — will be for free.

Yes, it is relatively simple. To prove a point I wrote a quick-and-dirty demo available here: Tribute to Highcharts. Obviously not everything matches 100%. Go and judge for yourself.

Update: related post on dojo-dev mailing list, which explains some details of the demo.

My presentation at ClubAJAX got off to a rocky start: I was let in the building 40 minutes after I was supposed to start the presentation. Everybody waited patiently. Thank you guys! As promised I publish slides along with relevant links (I had to skip most of planned demos).

Time to time I sync my blog software to the Django trunk and introduce small enhancements. Some of them visible to my readers, some of them are just for me. This time after reading Simon Willison's post on rev=canonical I decided to add short URLs to my blog as well. This is a convention to provide custom short URLs managing the mapping on your own web site. In my opinion the idea is very cool.

Steve Yegge is one of the bloggers I read almost religiously. His posts are full of insights on the software development topics and in general, and he is always ready with an amusing anecdote from his rich life. His last post Have you ever legalized marijuana? didn't disappoint either. The author explains "Shit's Easy Syndrome" (a difficult topic even for seasoned bloggers) in a gay romp that takes a reader from a light-hearted review of a book on "bugs in our mental software" to hapless VPs to many technical difficulties of legalizing a psychoactive drug extracted from the plant Cannabis sativa. But the most entertaining and educating part is the incredible story of the author's life.

Explaining some dark corners of JavaScript, browsers, or Dojo for the 100th time I realized that I already did it on numerous occasions, and some of my answers are published on public web sites. So I decided to round up the most general ones I posted on StackOverflow and publish links to them here for a future reference.

As you may know today Google released Friend Connect. I decided to give it a try. It took about 20 minutes to set up my blog with 4 gadgets: Members, Sign In, Rate/Review, and Wall/Comments. It took about 30 minutes to separate the skin from all these widgets, and set up the Canvas so users can see gadgets in a separate window, if they want to.

In the previous post we explored “array extras” and how they can help us to write concise yet performant and clean code. In this post we take a look at generalizing recursive algorithms with recursion combinators — high-level functions that encapsulate all boilerplate code needed to set up the recursion. These functions were added to dojox.lang.functional and will be officially released with Dojo 1.2.

In general the recursion is a form of iterative problem solving in the same category as loops. There are two major natural sources of recursive algorithms: recursive data structures (lists, trees, and so on), and recursive definitions (factorial, Fibonacci numbers, the GCD algorithm, etc.). The recursion plays a prominent role in the functional programming (FP), and one of the best articles on this topic is “Recursion Theory and Joy” by Manfred von Thun, the creator of Joy (a purely functional programming language with Forth-like syntax). Manfred's article explains intricacies of recursion including the venerable Y combinator, recursion combinators in general, and introduces a practical set of recursion combinators, which will guide us in this post.

If we look at the history of computer programming languages, we can see that practically all new programming methodologies were about one thing: taming complexity. The anarchy of earlier days of procedural programming (example: Fortran) gave way to structured programming (Pascal), which was refined with modular programming (Modula), and was reformulated when object-oriented programing went mainstream (C++, and much later Java). And it stopped there. The focus shifted to different branches of computer programming, namely to functional programming, and, to a lesser degree, logical programming. The only major development in this branch was the rise of aspect-oriented programming (AOP) paradigm. Let's take a look at AOP in our favorite language: JavaScript, and how Dojo helps the language with dojox.lang.aspect package.

Yesterday Google announced its new offering: Google App Engine. These are my random notes I did yesterday when I studied the new service.

As you all know by now Dojo 1.1 was released in the wild. You can get a lot of useful links and info from James Burke's post on Dojo 1.1, but let me tell you why you should be excited:

1. Dojo 1.1 is the first official release, which contains dojox.lang.functional. It was available in the trunk for awhile, but now you can use it without deploying Dojo courtesy of AOL CDN. I am psyched about it!
   
2. Improvements in animation, animation helpers for dojox.gfx. A good examples of animation in action is dojo.moj.oe by Pete Higgins (internals were detailed in the blog post, and in the great Dojo Campus article), an example for dojox.gfx animation is the career test. Finally we are getting to the point when we create attractive GUI cross-platform without plugins.
   
3. The Dojo API tool. As you know Dojo is essentially a federation of JavaScript modules. Every module can be a library on its own. Now we have a simple way to navigate them, read developer's documentation without diving into the source, and understand the API. When comments will be added to it shortly, you can add your own notes, and ask pointed questions. Developers are getting an essential tool to see how their modules are documented, what questions are raised most frequently, and so on. This tool will help us to document Dojo even better. All in all Neil Roberts and Tom Trenka did a great job!
4. Numerous improvements and bug fixes — this is always good. The API is mainly unchanged, so the migration to Dojo 1.1 should be a no-brainer for most users.

I am pleased to see that social aspects of Dojo are getting attention: the redesigned Dojo web site, the Dojo API tool, Dojo Campus is always fun, Dojo forums are active, even the Dojo archive is now easy to navigate!

What's next? The next target is Dojo 1.2, which will see a lot of enhancements. In my crystal ball I can see myself diligently working on Charting with other volunteers. New graphics improvements and  new dojox.lang modules are planned too. While we are busy pushing for 1.2, the maintenance release (Dojo 1.1.1) is planned as well.

What makes JavaScript so different from other languages? Is it its dynamic nature? Its prototype-based funky inheritance? No. The most unusual thing for newcomers is how JavaScript programs handle the workflow. The program looks like a bowl of spaghetti. There is no start or end of the program. What we have here is a bunch of functions, which are called in response to some external events. In most cases we have no way to predict the order of these events. And we know that all callbacks are called from a single thread. Of course we know that it is not a nature of JavaScript but rather a limitation imposed by a specific container of JavaScript programs — web browsers. Majority of JavaScript code is written for browsers and now we have a perception problem. But let's dig deeper to understand the problem better.