Several years ago, when I was just learning Javascript, I ran into a situation where I had to convert a string to it's monetary equivalent -

10 = 10.00
or 15.320000 = 15.32

Rather than spend the time searching for a function to do it for me I wrote out a quick little function to solve the problem. A few days later a friend of mine, who at the time was a much better coder than me, saw it, and reacted like I'd just run over his mom.

Friend: (mouth agape) Why are you doing this?
Me: I didn't want to look for a function.
Friend: There has to be something that does what you want.
Me: I'm sure, but, this does it too.
Friend: (look that suggests friend is questioning his friendship) Always use the functions that are already in the language.

He didn't explain why, and I didn't ask him. It wasn't until a few years later that I learned the reason, and it was so obvious, that I couldn't believe it'd taken me that long to realize it.

The language you're using was built using another language, one closer to the machine. This means that for every instruction you're giving the language you're programming in, that language is giving several instructions to the the language it was programmed in, and so on and so forth until the code reaches the machine. Prebuilt functions are one level closer, which can be much much faster.

Besides the speed benefit, there are direct ones as well. I knew beforehand what I'd have to do to write the toFixed method needed above. There was nothing learned in that. Now that wasn't a terrible waste because the code was easy, and small. But say someone gets in the habit of doing it. A friend of mine was recently working on a program that at first glance seemed easy, but as he got deeper and deeper into it, more and more obstacles popped up. He spent a few days on this, with nothing to show for it. He asked me to take a look at it, and I briefly looked online, almost immediately finding a function that did exactly what he wanted, that was part of the language.

By getting in the habit of looking for what you want, you can in the long run save yourself time. Even if something seems like an uncommon operation look for it. You'd be surprised how many times I've found what I've wanted when I was looking for something I thought was going to be unique to my project.

On a related note - say you're working on a project with a bottleneck, and you can't figure out how to make it faster, a lot of languages have a way to write in the language they were built on, although semi hackish. Take PHP for example, if you're willing and able to recompile the core, you can edit it yourself. In C you can write in Assembly, and in XUL you can write in a host of languages (C, Python, and others, though others will require more work). Put some of the code in one of the lower languages, and get your speedboost. Depending on the cause of the bottleneck you can get up to 7 times the speed. (As a warning, don't overdo this. Maintenance will be a pain, and quite often the bottleneck will be related to bad database queries or just user lag time)

Basically, just spend a few minutes checking when faced with something you haven't done before, in the long run it will save you time, but more importantly it can save your users time.

I've seen a lot of blog posts recently about usability in Flash, most of which are very negative, written by people who seem to have used earlier versions of Flash, and decided that nothing has changed. However, there is one thing that has kept me away from doing projects in Flash with a lot of text.

That one thing, is the browsers find function. I use the find function a lot. Often times I'm only looking for a portion of a page, and so I'll do a search on a key term. With Flash (and others, like OpenLaszlo, XUL, etc) the find won't work. Even when an OpenLaszlo program is converted to DHTML, find won't work on some items, because they're converted to images.

However, I think I've got a solution. I'd like to note first though, that this is currently a concept, and I haven't put in the testing legwork yet, though I plan to.

First, when the Flash file is generated, and the non flash version is created for those without Flash, add some javascript, that locates every character, word, etc, and stick it into an object.

Now, add a listener, that checks at a frequent interval for highlighted text.

setInterval(function() { var sel = window.body.getSelection(); if(sel.toString() != null) { window.document.getPageSelection.SetVariable = sel.toString(); } }, 100);

'getPageSelection' being the id of the Object holding the Flash file.

You'd then create a function to send this information to Flash (or have something set up to have Flash pull it in) In Flash you'd then create an object holding the text in the file (which, I believe could be done dynamically for most of the text in a file)

This object would probably need to be set up so that each letter would exist at a different spot in a multidimensional array, in this example, this would hold the information to find - "f-i-n-d" ->

var totalFlashText:Object = new Object(); totalFlashText["f"] = [ ["xs,ys,ws,hs,pages"] ["i", ["xs,ys,ws,hs,pages"], ["n", ["xs,ys,ws,hs,pages"], ["d", ["xs,ys,ws,hs,pages"], ] ] ] ];

Probably not something you'd like to do by hand, but, it seems to me possible to generate dynamically, and in the realm of possibility for Flash. When I get time to give it a shot, I'll flesh this out some more.

This morning, I read a post on the XUL User Group, from someone confused as to why some of CSS properties he was familiar with weren't working with XUL.

This is something I've seen pretty often with the RIA XML based languages, (Flex, XAML, XUL). People have gotten so used to HTML, that they've decided it's the standard to judge other languages against.

The truth is, even with CSS, HTML is terrible. I know, it has a bright past, and it will have a bright future, but compared to what can be done with other markup languages, HTML isn't even in the same ballpark.

I'm not saying that HTML is at fault. If anything, HTML has done pretty well with the hand it's been dealt. Most languages probably would have thrown themselves in front of a train if they had to deal with what HTML has dealt with.

• Originally created to display just text
• Used by millions, has to accept a very wide range of user inputs, and attempt to fix errors, caused by past specifications, or user mistakes
• Due to the errors, different companies are able on some items to set their own rules, seperate from the others
• Has to be lightweight enough to be sent quickly over the internet, to all sorts of connections, but readable enough for anyone to learn

RIA languages don't have these problems (except for in certain instances the last one). Take for example Flex.

• Built to display new media. Video, Vectors, Audo. Someday it will likely not fit what people want, but it's probably a long ways off
• XML has a strict set of rules that are pretty well known by anyone who will be creating a project in one of these languages, they no longer have to account for user error, or worry about code written 10 years ago
• Only one company is developing it, there won't be multiple implementations, except for versioning, and because developers don't need to upgrade, new versions don't require as much backwards compatibility.
• Virtual Machines can contain a lot of the items for you, and with Apollo users don't need to repeatedly download the images or code

HTML and CSS are very useful for the web, and will probably have a place for a long time. But, when it comes to rich applications, they can no longer compare. I understand the desire to have something work the way you're familiar with, but trust me, the future is bright.