Squiggly is the new spell checking component that Adobe recently released on labs. I haven’t had a chance to test it in depth, so I’m not sure yet how it compares to our Spelling Plus Library, but I have to admit that its release frustrated me a bit.

I’m not at all worried to have competition in the space, we’ve had a good run with SPL so far, and competition is always welcome. Rather, I’m concerned about who I’m competing with.

See, one of the things that the Flash world really lacks is a strong commercial component marketplace. We have a thriving OSS culture, which is awesome, but while it is very prolific it rarely creates highly reliable, documented, and well-supported libraries. It’s a weakness of the platform, especially when you look at the hundreds or thousands of enterprise class commercial components available for languages like Java or C#.

That’s why, when Adobe spends a large amount of resources building a spelling component that directly competes with one of the few successful commercial components in the Flash world, it frustrates me. It’s not the potential impact to our revenue from SPL (which was a largely unexpected bonus of building it), competition is an expectation in this industry, and I wouldn’t be writing this post if it was a third party that built Squiggly. Rather, it’s the message it sends to other potential component developers.

Adobe could have used SPL as a customer success story to entice other developers into offering high-quality components. They could have even helped promote SPL, to actively encourage the growth of a commercial eco-system. Instead, they issued a warning to those same developers that if you build something that generates demand, they will compete with you directly (or worse yet, release a competing component for free).

I understand that there is a lot of value in Adobe providing an official spell checking solution, assuming it remains updated and well supported. However, at a minimum they could have given us advance warning of Squiggly’s release, or even had a discussion early on to see if what we had built would work for what they need. It must be close, as they are already using SPL in a number of their own projects. They need to work with their developers, not against them, if they want a strong platform long term.

[Important note: I was provided 3 weeks notice of the release. I originally thought it was only a couple of days notice, and so didn’t feel it was even worth mentioning in this post. The notice basically just informed me that Adobe might be releasing an OSS spelling library at some point in the future. In fact, I believe part of the reason that I was so far off in remembering the amount of notice I got (beyond being ridiculously busy at the time), was that it really wasn’t actionable in any way, so I basically dismissed it. It was better than nothing though, I appreciated it, and it is remiss not to have mentioned it. Sincere apologies to Christian.]

I’d like to chalk this up to pure ineptitude and cluelessness. It wouldn’t even shock me if the team that built Squiggly was completely unaware of SPL, despite that showing a lack of basic web searching ability. I’m certainly hoping it wasn’t a case of Adobe seeing something that worked, that filled a need, and that demonstrated demand, and saying “hey, we should do that too”. Either way, it demonstrates a lack of understanding of developer relations, and how to foster a healthy component ecosystem. This is also something that Adobe / Macromedia has a history of doing, so its not like this is a first offense.

Note that the above doesn’t apply to all of Adobe. There are people who get it, and I thank them for bringing this issue up internally. Unfortunately, I think Adobe needs to embrace a corporate culture of supporting their developers both technically and from a business perspective, not just among their evangelists, but also with their product and executive teams. If we’re successful, Flash (and by extension Adobe) will be successful.

What do you think?

Do you have an idea for encouraging a healthy ecosystem for commercial components? Share it here.

In most projects there are tons of events that are dispatched, but that have no listeners subscribed to them. This shouldn’t be an issue, but it turns out that the Flash Player deals with these events inefficiently. Luckily it’s pretty easy to patch this for specific situations.

The code below will run about 5X faster than a standard dispatchEvent call when there is no event listener for the event type.

override public function dispatchEvent(evt:Event):Boolean {
if (hasEventListener(evt.type) || evt.bubbles) {
return super.dispatchEvent(evt);
}
return true;
}

Note that the actual time difference is fairly minimal (80ms vs 450ms for 100,000 iterations in my tests), so I would only do this in classes that you are going to create a lot of instances of and which will generate a lot of events that may not have listeners.

For example, I used this in GTween, because you could have thousands of tweens active at the same time, each of them dispatch CHANGE events every frame while active, and it’s very common to create tweens without a listener for that event.

While I think this will work for all cases, I haven’t tested extensively with less common event scenarios. Bubbling events should work, but you won’t get a performance increase.

This change also reduces efficiency for events that do have listeners, but it is very minimal (<10%, 505ms vs 545ms for 100k iterations in my tests).

When preparing a Flex project for deployment, always make sure to export a release build. I think most people know about this feature of FlexBuilder, but I’m not sure everyone is aware of just how important it is. The SWF that is generated when you run or debug your project contains a lot of extra byte code used for debugging and profiling your content.

This extra byte code has a very obvious effect on the size of your SWF (adding over 35% in some cases). It also has a less immediately obvious (but no less significant) effect on the performance of your application. In one example here at gskinner.com, a 980kb SWF was reduced to 675kb, and some performance intensive code ran over 2.5x faster in the release build than in the debug version.

Never deploy a project without exporting a release build, and be sure to test a release build if you are experiencing problems with file size, performance, or memory utilization.

We’re currently finishing off version 1.2 of the Spelling Plus Library, which includes a number of enhancements including:

• various minor fixes and improvements, including resolving an issue with AIR context menus

• improvements to the text highlighting engine

• suggestions algorithm has been refactored to be slightly faster and more accurate

• support for multiple languages using the roman character set

That last one is a big one, and one that we could use a little help with, if any multilingual folk have a bit of time to spare. Our office is hopelessly monolingual, and we are looking for some brave folk to spend 5 minutes or so just playing with the engine and seeing if it returns appropriate results. We’re currently testing French, Spanish, and German.

If you’re interested, either drop a comment below, or send us an email (use the contact link at the top of the page). Honestly, there’s no immediate incentive for doing it, but we’ll try to figure something out.

I just uploaded the desktop version of RegExr. It’s just an AIR version of the online application for now, but I’ll add some desktop specific features, and put up a nicer looking page when I have a chance.

With this morning’s announcement of the AIR alpha for Linux, this means RegExr is now the first free tool for editing and testing regular expressions (RegEx) that runs on Mac OSX, Windows, Linux, and online (as far as I can determine). Pretty cool, considering it only took 60 minutes of work to convert the online application to a desktop program and add update notifications.

You can install the desktop version of RegExr here. Or, you can use the online version at regexr.com.

Next up, I plan to add support for testing replace functions, and then a proper lexer.