Truer Words - A Journal

A New JS Mode for Emacs, and Why I Wrote a JS module for BBEdit

seth@macrobyte.net — Mon, 31 Mar 2008 17:02:51 GMT

Stevey's Blog Rants: js2-mode: a new JavaScript mode for Emacs

For the OOD-loving and API-minded among you, the "beautiful" way to do syntax coloring would have been to finish parsing, then walk the AST using a Visitor interface, applying the coloring in a second pass. I tried it, and it was, as they say, "butt slow". In fact (perhaps not surprisingly) walking the AST takes exactly as long as parsing, so it was twice as slow as doing it inline.

So I bit the bullet and moved my syntax-coloring to happen inline with parsing. Fortunately it only introduced about 30 lines of code to the 4000-line parser/scanner, because most of the coloring happens in the scanner, at the token level. Go figure.

Steve Yegge describes (at length) his new JavaScript mode for Emacs. For much of the article he's talking about (trying to) parse the JavaScript file at the same time that he's applying syntax coloring. It's absolutely NOT a simple task, not by a long shot. He had the benefit of direct access to Brendan Eich (the author and maintainer of JavaScript itself) at least twice so far, but still describes how difficult it was. And this is someone many people consider a superstar programmer who has been working at Google for years.

Well, next to Conversant, my favorite-ever project is/was the JavaScript module in BBEdit. I won't go into all the technical details like Steve does, but I will say, "I feel his pain."

Thinking about this, I realized that I never wrote the story of how I came to be contracted with Bare Bones. With all the explosives experts, martial artists, photographers, and "connected" individuals at BB I need to be careful not to cross the lines of my NDA, but I think I can tell this story safely. ;-)

How It All Started

In early Spring of 2006 — almost exactly two years ago — I was doing a lot of work with JavaScript. Prototype was my new favorite toy, but 1.0 hadn't yet been released. My editor of choice was BBEdit, but I was frustrated that it didn't list the functions in Prototype.js (follow that link for more details, including pictures). I wrote to Bare Bones tech support to ask if they knew of any third-party, BBEdit, language modules for JavaScript.

The answer was "no," but I was told that a couple other people had asked about improvements to their JavaScript support. I wrote back to say that I'd like to take a crack at it, if I could only see "the source to the current syntax module." Hah. Yeah, like that was ever going to happen. "Could you send me some of the source to your app, so I can write something better?" (That's NOT what I said, but that's probably what it sounded like.)

After lots of email back and forth, on May 10th we had only reached the point where Bare Bones was "planning to update it in a future release." I'm a developer, I know what that means. So I wrote again, and said I was going to start my own language module (based on BBEdit's public SDK for language modules), and could they just send me their current list of language keywords?

A month later, Rich himself finally sent them to me. That was June 12th. I wrote back with a better list of keywords, and told him I was going to start working on my own module unless they told me I shouldn't bother because they already had one under development. They didn't, but Rich seemed to be trying to call my bluff: you go ahead and start working on it, and if you come up with something good maybe we'll work something out. (I've been on both sides of this discussion, and I know that usually nothing happens.)

Three days later, I sent them a copy of a fully functional JavaScript language module, written in C++. (Looking back, I'm all impressed with myself!) When I'm telling this story in person, especially if Rich is nearby, I like to say that they tried to call my bluff but found I wasn't bluffing. I still think there was a little of that, but mostly I think they just dealt with this nagging, mostly-unknown customer the best way they could: "go ahead and do your thing, and yes, maybe we'll work something out."

A few days after that I sent them another one, with some more features and some bugs fixed.

A few days later, I went to RailsConf in Chicago, and found out that lots of Rails developers were using TextMate. I'd barely heard of it! (Probably because I don't go looking for new toys very often when I have work to do.)

While at the conference, I talked to other JavaScript devs about their editors, and showed them what I'd done for BBEdit. I even showed Sam Stephenson, Prototype's author, at the same time that I was showing him what I'd done for custom events in javascript. Everybody liked it, and it was definitely better than anything else out there. I also asked people why they were using whatever editor they were using. Most of the Rails folks who were using TextMate were using it because that's what the top Rails guys recommended, and because it had really good integration with Rails itself.

I wrote up all this "research" and sent it to Bare Bones when I returned home.

Writing the language module, peppering them with lots of email, and sending in the research I did at RailsConf were enough to really get their attention. In early July (can't remember... July 3rd or 5th), Rich came down here and we had lunch at Costello's Clam Shack, right on the water. I got an early look at BBEdit 8.5, we talked about my 1,001 feature requests, and I signed an NDA with a handshake (and later with pen and ink).

Perhaps as import as the business that was done that day, Rich and I became friends (and have had a casual breakfast almost every Tuesday morning since then).

How well do you know Prototype?

seth@macrobyte.net — Mon, 13 Aug 2007 01:35:14 GMT

thinkweb2.com posted a great set of examples of better ways to take advantage of Prototype in your own javascript code.

Here, I've collected most common use cases that do NOT use all of prototype's capabilities and their simple solutions. I hope this will be a basic checklist to go through when developing for your next project.

Excellent list. If you don't work with Prototype on a regular basis, or you do but you haven't paid attention to everything it can do, read this. It could save you a lot of typing, headaches, and time.

Resignation?

seth@macrobyte.net — Mon, 23 Jul 2007 19:32:10 GMT

I've already mentioned how "over committed" I am right now. It's so bad that I decided to resign, at least temporarily, from the Prototype core team.

Then I felt so guilty about it that I attended this morning's all-hands chat room meeting.

On the other hand, I've actually finished a few items on my to-do list lately.

Who knows... someday soon I may even be able to start the PMC Software Auctions. Hope so, since the PMC itself is less than two weeks away.

Apple, On Custom JavaScript Events

seth@macrobyte.net — Wed, 04 Jul 2007 16:45:40 GMT

This morning when I checked my Gmail account, I read a message (from someone named "Filippelli Christophe") that said Apple seemed to be using my Custom JavaScript Events code on the iPhone page. (In case anyone misunderstands: this is a very good thing in my opinion.)

"Yeah right," I thought.

But it's true, at least at the moment. You can see it for yourself:

Go to the iPhone home page
View the source.
About 20 lines down (in the source) there's an indented bundle of <script> tags, the first of which points to “/global/scripts/lib/event_mixins.js”. Copy that path, and load it up in your browser.
See? Third line down says, “(c) 2006 Seth Dillingham …”. How cool is that?

Boring Mac Programmer Stuff

The irony is that my custom events code is based on Apple's own work.

Huh?

Well, in the early 90's, Apple pushed the Mac application developers to make their applications scriptable and recordable.

Scriptable meant you could automate (control) the application with AppleScript scripts.
Recordable meant you could tell your script editor to start recording, then do something in the application and your actions would be translated to a re-usable applescript in the script editor.

The way it worked was that a button click or menu selection (to name just two examples) in the application would cause the application to send an AppleEvent (the tech on which AppleScript was built) to itself. So it was like you had two applications in one: the one the user interacts with, and the "engine room" where all the real work was done, and the UI communicated with the engine room by sending AppleEvents.

Many well-written applications already “decoupled” the UI from the rest of the code anyway. If the application was also going to be scriptable, then also making it recordable (with the above approach) was at least a realistic consideration (though it was still a lot of work.)

My "Custom Events for JavaScript" article uses the word ‘decoupling’ in the title for exactly that reason: the intent is to allow you to decouple the UI of a web application from the data processing you do in JavaScript, and/or on the server side. It's not identical to Apple's recordability model, but it's inspired by it.

Blah blah blah... most people don't care about that stuff, I know.

Anyway, I told Rich about this and he said Apple owes me an iPhone. Hah.

“Dear Apple: my friend Rich Siegel — you've heard of him, right? — says you owe me an iPhone. Love, Seth”

(Of course, they don't actually owe me anything. I did release the code for free, after all...)

Rich had a funny response to the above (in the form of a faux letter back from Apple), but I'll leave it to him to post (or not). ;-)

I told Flip about it, too (hey, I was excited!), and he said he's going to tell his friends that he knows someone who made the iPhone possible. Hear that popping sound? That was my ego. ;-)

Update: forgot to mention that the custom events stuff is what landed me on the Prototype Core team in the first place... and they (the rest of the team) expect me to roll some form of the custom events code into Prototype itself. Have to do it soon, or Sam is going to send me a Howler...

Geek Lunch

seth@macrobyte.net — Sun, 20 May 2007 17:35:46 GMT

Three of us, maybe four, are going to lunch today. Sam Stephenson, Thomas Fuchs, myself, and Dan Webb if I can talk him into it.

Gee, what do you suppose we'll be talking about? ;-)

Creating Custom Events with, uh... me?

seth@macrobyte.net — Wed, 28 Feb 2007 14:08:05 GMT

Last year I was working on a Conversant-based RSS aggregator. It was very AJAXy, with a responsive UI which acted as much like a traditional desktop aggregator as I could manage in the limited time I had to work on this project.

In the process, I created the Custom Events mix-in (extension) classes for Prototype. Then, a little later, I attended RubyConf '06 and met Sam, who was impressed enough with my work that he asked me to join the Prototype Core team a few months later when it was formed. (Which is something I've neglected to mention here.)

Those custom events classes have received some attention... except from me. My write-up that described my approach is one of the most-frequently-hit pages on the site, and a number of people have linked to it (including A List Apart, which generated a lot of traffic).

Most of the links, though, were in passing. Comments like, "this looks interesting," or, "here's an alternative approach to doing custom events," etc., etc., etc. That was fine... I'd heard from people who I know are using it, and some have even reported bugs (which I've fixed) that they ran into while implementing custom events in their own projects.

Yesterday, Daniel wrote “Creating Custom Events with Seth”, wherein he documented not only the struggles that led his team to using Custom Events in the first place, but also the benefits they've seen as a result.

So toggling is screaming to be refactored since the wiring is painful to behold. It’s far too interwingled with the other stuff on the page and we know it. I had looked at Seth’s work a while back, and shoved it into my back pocket… and today it worked out perfectly. We did a little spike, got the basic code working, and then applied our new found knowledge to the problem. Now we have excellent separation of concerns. The toggle dispatches a custom event, and various things listen for it via a broker. Nice. Any other widgets or tools can tie in just as easily. Since we were already using Prototype.js and our own classes, it took only about 15 minutes to mixin the Event classes and set up a broker. Most excellent Seth!

Very cool, Daniel, I'm really glad this worked out for you.

He also mentioned a documentation bug, which doesn't surprise me at all. I should really rewrite and reconfigure that page into a small collection of more approachable pages, and review it all for accuracy. Just one more thing for the to-do list.

Events, Listeners, and MSIE: A Big Surprise

seth@macrobyte.net — Thu, 08 Feb 2007 00:32:21 GMT

I've been doing event-based JavaScripting for approximately as long as there has been such a thing.

One of the foundations of this programming is that MSIE puts its event object at window.event, and most everybody else passes the event object to the listener (the method that is called when the event is triggered).

I moved past my frustration with that difference in behavior many years ago, so I could get some real work done. Know what I mean?

Turns out it's not true anyway.

Someone (can't say who) contacted me today in a fit of confusion. HIs events listeners in MSIE 6 were receiving events objects as parameters.

He was using Prototype to set up his listeners, so I assumed it had something to do with that. I looked into it...

First, I tried my own test, of course. Yep, there's the event object.

Second, I traced the code in Prototype. Function.bindAsEventListener() would explain it... except that's not what we were using in this case.

Nothing else in Prototype explained it, so I went out to the web to see what others had to say.

David Flanagan — The Man Himself, author of my favorite book on JavaScript — had this to say: back on October 23 of last year (just 3 1/2 months ago):

I don't know how I know this: it is just one of those things I've always known about IE. But a reader (Tom Stambaugh of zeetix.com) just emailed me with a trivially simple counter example. It turns out that if you use attachEvent() (at least in IE 6) then the event handler you specify is passed an event object as an argument.

I don't think I'm the only one who believed that handlers registered with attachEvent() don't get passed an event object. For example, the documentation on attachEvent() at about.com says:

Also unlike the standard DOM method, the event is not passed to the function as a parameter. Instead IE supplies a standard window.event object to hold the details relating to the latest event.

And the documentation for the YUI event library advertises, as a feature of the library, that:

The first parameter your callback receives when the event fires is always the actual event object. There is no need to look at window.event.

[SNIP]

Update: Thanks to the commenters who have pointed out the interesting fact that the event object passed to a handler is not the same object (not == to) window.event. I've written a trivial test that demonstrates that 1) an object is passed to a handler registered with attachEvent(), 2) that this object is not == to window.event, and that 3) the properties of this object are the same as the properties of window.event (except that they both have a property that refers to different empty arrays).

[SNIP]

Update 2: In comments, Alistair Potts presents test results that indicate that attachEvent has always passed a copy of the window.event object to event handlers. His test code is at: http://www.partyark.co.uk/html/ieeventtest.htm

(I seriously wonder if everybody else based their assumptions on David's own writing. I think the original version of his book was published by Gutenberg himself, and almost every serious JavaScripter has a copy of it.)

Long story, short: MSIE has (almost) always passed the event object to the listeners, as long as you registered the listener with attachEvent instead of just "assigning" the listener.

Live Reviewer

seth@macrobyte.net — Tue, 06 Feb 2007 21:09:16 GMT

One of the other members of the Prototype Core team just asked me to be his only English-speaking "Live Reviewer" for a forthcoming book on Prototype / Scriptaculous.

I'm not sure if I should be happy about this, or just sorry for the other English-speaking reviewers (as it implies they're not 'live'... come on guys, stay with me...). ;-)

Inline-Block, Coming Soon to a Firefox Near You

seth@macrobyte.net — Wed, 13 Dec 2006 16:21:47 GMT

I'm surprised and happy to see that dbaron (one of the most experienced and "lowest level" (as in plumbing, not importance) Mozilla contributors) is finally working on an implementation of CSS 'display: inline-block'. I've been subscribed to the Bugzilla bug for inline-block for years and years, so I was amazed to see it finally get some official attention a couple days ago.

Apparently he's also implementing inline-table.

How to Serve Compressed Data with mod_gzip and Apache 1.3 on Mac OS X

seth@macrobyte.net — Fri, 17 Nov 2006 01:04:09 GMT

Some of us have recently been discussing the size of the Prototype library, my preferred library for DHTML/AJAX). Proponents of some of the other libraries play up their smaller file sizes, and it's true that this is a real issue for some people.

This little essay/how-to explains the basic ideas (the what, how, and why), and then walks you through setting up Apache on Mac OS X, to enable mod_gzip and serve compressed content. If you skip the editorial content and just follow the steps I've outlined, you should have everything up and running in fifteen minutes or less.

Prototype: A Call For Documentation

seth@macrobyte.net — Wed, 01 Nov 2006 15:02:50 GMT

Prototype (a super-popular DHTML/AJAX library for JavaScript) is finally going to have a full-fledged, dedicated documentation site. Justin Palmer is one of the guys working on it, and has just posted A Call For Documentation.

We’re hard at working getting the Prototype documentation site ready for launch. However, we know there is already a lot of great documentation scattered throughout the web. Instead of us rewriting a lot of this documentation, we’d like to ask that the community lend us a helping hand.

If you’ve documented parts of Prototype, we’d be tickled pink if you’d be willing to share that with us. We’re looking for all types of documentation, everything from examples, tutorials, to general api docs.

The rest of his post explains how to submit material for the site, and how to be 'officially' involved in regular site maintenance (they're looking for some volunteers).

BBEdit 8.5.1's JavaScript Support

seth@macrobyte.net — Thu, 12 Oct 2006 18:21:36 GMT

Bare Bones just announced the release of BBEdit 8.5.1. This is basically a release of "bug fixes and feature tweaks," but there's some cool stuff in there that some people will certainly enjoy playing with (myself included).

Comparison of the function popup for the same JavaScript file in 8.2.6, 8.5, and 8.5.1:

BBEdit 8.2.6

BBEdit 8.5

BBEdit 8.5.1

(Ahem. See my BBEdit Disclaimer, please.)

As I've mentioned, I did some work for Bare Bones on the 8.5 release, and the same is true for 8.5.1 (just a small part of the total work, in both cases, but it feels significant to me). What I "didn't yet get around to" is that my favorite part of this project has been the new JavaScript support! I totally rewrote it from scratch for 8.5, and then enhanced it a bit for 8.5.1. (The story of how this came about is pretty cool, but there's no room for it here. For now, let it suffice to say that it involved food and a bit of personal challenge.)

The significant, JavaScript-related changes that a user would notice, between 8.2.6 and 8.5, include the following:

More keywords are recognized and colored.
Much better detection of functions for the function popup menu.
Recognition of "anonymous" functions (again, for the function popup menu.)
Folding. (I didn't write BBEdit's folding feature, I just hooked it up in the JavaScript support.)

Even before 8.5 had shipped, I was working on some improvements. I had this crazy idea that I could make BBEdit's JavaScript support as complete as possible, to the point that I would actually feel like it was "done." (Is software ever done?)

Here's what was added for 8.5.1:

Function names in the function popup are now complete. That is, it doesn't just grab the last word of the name. (See the third picture on the right.)
Folding improvements. Rather than adding automatic "fold points" only at the start/end of functions, they're added to all matched sets of {curly braces} that contain at least N lines (N defaults to 4, but can be set via a hidden preference from the command line).
Object literals are listed in the function popup, if they have names. The names are found in the same way as function names, so long.dotted().names work, too. Plus, nested objects and functions are listed "hierarchically" in the function popup, and objects are marked with a special character so you can scan the menu quickly to find the objects you need.
Since Prototype is so wildly popular these days, we added support for Prototype's "Object.extend" as another way to 'name' an object.

Not clear on that one? Here's an example:
```
Object.extend( foo.prototype, { ... } )
```
... produces an entry in the function popup menu called "foo.prototype"
You can add arbitrary strings ("place markers") to your JavaScripts, in comments, and they're added to the function popup. For example, this comment:
```
// #mark Hello World
```
... causes a "Hello World" entry to be added to the function popup. I personally find this very useful for breaking a long file up into "labeled" parts. Plus, if the mark is just a single hyphen (so, "#mark -") then a standard menu-separator is added to the popup menu.

There are tons of other little improvements in 8.5.1, unrelated to JavaScript. A few of them I worked on, most of them I had nothing to do with. (Meaning, of course, Bare Bones did it themselves.) For me, this is "the JavaScript release," as I think this makes BBEdit a really great JavaScript editor. (But then, I *would* think that!)

New API Docs for Custom JavaScript Events

seth@macrobyte.net — Wed, 06 Sep 2006 18:31:59 GMT

With some major new interest (more about that later) in the Custom JavaScript Events stuff I wrote a couple months ago, I've been prompted to write some simple API docs for my Custom Events code (which is an addition to Prototype.js). (What, you don't have time to read 3500 words on why you should be using custom events in your JavaScript apps to save your own time? Come on! ;-)

Updated the Custom Events Essay and Code

seth@macrobyte.net — Tue, 04 Jul 2006 05:49:37 GMT

I've updated the custom events in javascript essay, and all of the reference code.

A couple of bugs in the code have been squished, the Event.Broker mix-in (that was described in the essay but not originally provided) is there now, and the essay text has been slightly tweaked.

Creating Custom Events with JavaScript: Decoupling

seth@macrobyte.net — Fri, 30 Jun 2006 19:50:36 GMT

Many "Web 2.0" applications suffer from too-tight-coupling between the various javascript objects used to model the data and control the interface. This has always been seen as a necessary evil because there seemed to be no good alternative.

One common solution in desktop applications is called "event driven programming." Not just user-supplied events like mouse clicks, hovers, and window scrolls (obviously, we do all of that in our javascript apps already), but actual data-driven or state-driven events such as "message selected" or "preference changed".

Truly custom events, when used correctly, allow you to decouple many of the JS objects in your application. This leads to better self-containment and much better maintainability.

It has generally been considered impossible — or at least too difficult — to create truly custom events in our applications. There is a W3C spec for custom events, but it's not supported by most of the browsers so is really of no use to us.

Read the full essay and together we'll examine the problem a little more closely, and consider my solution. (There may be others, but all I found was attempt after attempt to duplicate the features already provided by the browser.)

RailsConf 2006: Highs and Lows

seth@macrobyte.net — Tue, 27 Jun 2006 15:49:31 GMT

RailsConf (the first 'official' Ruby on Rails conference) ended Sunday afternoon. I'm very glad I went.

Highlights:

Having Corinne there with me, for a lot of reasons.
Meeting Greg and hanging out like old friends, making plans for future work, and getting help with problems in one of my projects (he has more Rails experience than I do).
Watching one of my clients (M.C.) scurry around with a big backpack, and talk to anybody who would listen about his project. The man really seems to love his work.
The jets taking off right over the hotel, and the huge trains rumbling by on the tracks across the street.
Dave Thomas's keynote on Friday morning, throwing down the gauntlet.
All the keynote speakers bluntly disagreeing with all of the others, without hostility.
DHH's keynote on Saturday night
The Homesteader's Guide, by Nethaniel Talbott
The code-related sections of the "performance" by "Why the Lucky Stiff"
Meeting with Sam Stephenson, author of Prototype, for an hour on Sunday, and being told that he loved what I showed him. It seems I really did figure out something NEW in JavaScript, and wasn't actually deluding myself. (Note: JS-related validation from Sam is a bit like Ruby-related validation from DHH. That is, he didn't write the language, but he is considered one of the elite and there are many, many thousands of people following his lead.)

(Yes, I'll have a LOT more to say about this soon.)
An email I received from a brand new client. I had to work for this one, but in this case that's a very good thing. I can't wait to say more about this!
The macs. It was totally nuts. 550 attendees, and I've seen estimates between 80% and 95% mac coverage. Some joked that "in the future, everyone uses macs." I parried that this wasn't the future, it was the alternate universe where things had worked out like we always knew they were supposed to.

Check out some of the pictures. I'm even in one of them, from the neck down. ;-)
Giving the (other) last remaining mac geeks (about twelve of them) in the bar just off the hotel lobby a whole pizza (our leftovers after we ordered two smalls). They couldn't believe their good fortune! I told them they could have it if they promised not to get any on their MacBooks. They looked at me funny, one guy said that his runs better with pizza. I said, "you don't need to put it on the macbook, the pizza is already cooked." Took them all a second to figure that one out. :-)

Now the lowlights:

My babe being bored out of her mind. The conference kept us so busy that there was no time for us to do much of anything, and who wants to play tourist by oneself? (Not her!) Lesson learned. For future conferences, we'll be able to make a more informed decision about whether or not she goes with me.
Some of the sessions were desperately boring and lacking in any useful technical information. Some were good, many were not.
All the rest of Why's performance. Some people totally loved it. I'm not one of them.
Paul Graham's keynote presentation. He has this awesome rep, and I truly enjoy most of his essays, but all he did was read it! Dude. Look at your audience more often than when you're making a joke. (It was funny, though, that he kept saying, “I’m going to leave THAT part ouf of the essay on the site.”)
That it ended so soon. Sigh.

Back to work!

Aggregator Updated

seth@macrobyte.net — Wed, 07 Jun 2006 01:57:15 GMT

Hey, aggregator testers! I've updated it again. Minor stuff, mostly (I'm busy with another project, so I can only do this in my off hours, now), but still pretty good. The notes are on the secret-secret test site's weblog! ;-)

The fact that Conversant will soon have a nifty, built-in aggregator is no longer a secret. Obviously. That I'm planning to make it work with (and like) my favorite desktop aggregator(s) IS a secret. Mum's the word!

Client-Side Storage in Web 2.0 Applications

seth@macrobyte.net — Wed, 26 Apr 2006 20:21:19 GMT

This looks to be a fantastic breakthrough. I think Brian A. will get a kick out of the storage system he describes... it sounds awfully familiar. ;-)

I'm proud to announce the immediate availability of dojo.storage and a new web-based editor named Moxie.

Imagine if web applications could store megabytes of data on the client-side, in the browser, both persistently and securely. No server needed.

I'm going to have to implement this for Conversant. Soon.

(Thanks for the link, Daniel.)

Google Wants to Be the Web

seth@macrobyte.net — Wed, 08 Mar 2006 16:40:47 GMT

Google is working on an impressive new calendar system that's going to integrate tightly with Gmail.

This really bothers me. I told Greg that Google wants to *be* the web. They're clearly working hard to prove that the web is the next operating system, and they're working in areas that let them slide right under Microsoft's soft underbelly. (With Gmail + a good calendar system, they have very strong competition for Outlook.)

I wrote to someone at my ISP who's doing a big, online calendaring system. He showed it to me a month ago... it's a community events calendar, not really a personal calendaring system at all, but I still thought he should know about what Google's up to.

His reaction? "Google is poised to take over the Internet."

My problem is that they're leaving so little room for everybody else. It seems that no matter what part of the web you specialize in, Google has either announced or is about to announce something significant. That they're doing it all at once is what makes me nuts, though: a small team of developers can compete effectively with Google's equivalent application, but it's almost impossible for anybody to compete with the integration they have planned for all of the tools.

Never thought that someone working on a very cool new web application (that I don't compete with at all) would feed me such a big plate of sour grapes... but it did.

AJAX Toolkit Installed

seth@macrobyte.net — Fri, 03 Mar 2006 19:38:39 GMT

Installing the AJAX Toolkit into Eclipse was a little more work than I expected, but not much. It took about thirty minutes, and most of that time was spent installing the dependencies.

Once it's done, Mozilla really is fully integrated into eclipse. It's good to see that XULRUnner has come so far. There are some glitches (no contextual menus in the browser), but nothing horrible and no crashers so far.

More later...

AJAX Toolkit Framework for Eclipse!

seth@macrobyte.net — Thu, 02 Mar 2006 20:08:33 GMT

Excellent!

IBM's AlphaWorks group has released the AJAX Toolkit Framework. It's an Eclipse plugin that provides DOM browsing, syntax checking during editing, javascript debugging... and an embedded Gecko (Mozilla/Firefox) browser. That's cool!

Requirements: Windows. (Cue audio: Wah wah waaaaaahhhhh.) That's a bummer. Guess I can't blame them. It's not like many of the creative types are on Mac or anything.

It's open source, though, so perhaps someone will put in the time to make it cross-platform.

I'm about to install it on my PC, and will report back later with my opinion and results.

Good Work, Shot Down

seth@macrobyte.net — Fri, 24 Feb 2006 03:55:13 GMT

I did some very cool UI work for a client today, to revamp an old project. Nothing complicated or confusing, just some clever and simple dhtml bling to keep a page clean but still highlight the important elements.

Jed saw what I was doing, and raved about how cool it was, that "more sites should do stuff like that... it was so easy!"

The client shot it down. Said it was "too much like flash", and in his opinion, "flash is the worst thing to ever hit the internet."

I was *very* happy with the approach I used, and it sparked some more ideas for experimentation. Not a total loss.

Is JavaScript the most successful scripting language ever?

seth@macrobyte.net — Mon, 20 Feb 2006 18:34:32 GMT

Daniel repeats a question from Alex: Is JavaScript the most successful scripting language ever?

I would like to know is this: on what axis is JavaScript not the most successful scripting language of all time? [It certainly is successful within its scope.]

Source: Continuing Intermittent Incoherency

I've been telling friends (specific conversations with Flip Martin and Steve Ivy come to mind) for a couple of years that JavaScript is the most important scripting language (or one of them). Neither popularity nor sucess are good measures of importance, but in this case they seem to have gone hand in hand.

In fact, last Fall I bored Steve Davis with my thoughts on the rise of JavaScript and DHTML, even though he's not a web developer of any sort. (What he was, however, was a captive audience. We were on our bikes on a freezing-cold century, by ourselves!)

The Door is AJAR

seth@macrobyte.net — Wed, 04 Jan 2006 12:34:50 GMT

What an excellent coincidence, that Tim Berners-Lee's new toy, called Tabulator, is built on something he's calling AJAR... and to make it work the way he wants, he needs to find a way around Firefox's security constraints (as in, leave the barn door open).

Multilingual Context Switching (ouch)

seth@macrobyte.net — Mon, 26 Dec 2005 03:59:32 GMT

Man it's a pain to switch back and forth between similar languages like PHP and JavaScript.

I spent most of the day in PHP. Get some features working the "traditional HTML way," and then tweak it with AJAX... which means javascript. But I start seeing bugs everywhere in my JavaScript code, because my brain still thinks I'm looking at PHP.

For example: in PHP it's join( $glueString, $someArray ). When I saw someArray.join( glueString ) in JavaScript, I started backing it out to fix the obvious bug... no no no, that's not a bug. That's JavaScript.