NimbleText: Origins

I started shipping NimbleText at the end of January 2011. That's eight months after NimbleText was *almost* ready for release back in May 2010, when I published this roadmap: 24 things to do, and 100 things *not* to do (yet) for building a MicroISV. Back in May, instead of powering on with the last few tasks, I invested my spare time writing Dos-based web frameworks and 5 different json editors. I guess having a new little baby girl counts as something of a distraction too. ;-) (Very happily).

When I finally starting shipping, Joe Cooney said:

I tip my hat to you - I think in the time I've re-written a few bits of UI you shipped a product.

...in reference to his awesome LogEnvy tool. But it's not a fair comparison, for two reasons.

Firstly, LogEnvy is a much more sophisticated product than NimbleText. LogEnvy does all kinds of powerful manipulation of events logs in a wide range of formats and intersperses it with all the kind of dazzling UI you expect from a WPF ninja. But most of all his statement is incorrect because NimbleText was almost six years in the making.

I wrote the first version in February 2005 and published it as part of a blog post soon after. I wrote it the very same day I came up with the idea for TimeSnapper. It was a stressful week when I desperately needed both of those tools.

Although I was already a .net programmer, I wrote the original code in server-side VBScript for easier deployment. It was just a dozen or so lines. I called it variously 'the data pattern merge tool', 'the merger,' 'the programmer's mate' or the 'text multiplier.' Starting from that day, and continuing right up until the present, I have depended on this tool absolutely daily.

I released a second version in July 2005, and called it 'the world's second simplest code generator'.

The source code is largely a comment block listing all the extra features I wished it had. (And almost all of which, by the way, are implemented in more recent verisons)

A complete rewrite occurred in May 2006 when I started huffing the XSLT pixie dust and thought XSL could solve everything. Its dynamic nature gave it big advantages over the vbscript implementation.

But it soon turned into an exercise in writing a fully fledged compiler and I knew I was headed in the wrong direction.

I wrote an "offline version" around that time, in Windows Forms (VB.net version 1.1) I was never happy with it and didn't release it. If I have the code for it, I don't know where. My clearest memory of it was the way parts of the UI would animate (using a Timer control, of course :-) ).

I re-wrote the tool in August 2007, this time in javascript. Why did I rewrite it in Javasript? Because I was momentarily trapped on a machine that had no development tools, but I still felt like cutting some code. I assumed that browser performance would kill the tool, but I was dead wrong. Javascript was the perfect language for the problem, and the performance of Javascript was just beginning to take off as the browser wars re-ignited.

It was a clear victory for Atwood's Law:

"any application that can be written in JavaScript, will eventually be written in JavaScript."

Or a pre-cursor to Bambrick's Premonition:

"I don't know when skynet will take over. But I know what it will be written in: JavaScript."

I wrote a (playful) WPF version in Oct 2007 (in C#).

I wasn't happy with the tooling for WPF (maybe someone should fix that?), but more-so the dynamic behaviour of javascript trumped C# for this tool, so the WPF version never went anywhere.

Around that time I wrote other undocumented, unreleased versions in powershell and one in ruby (shoes). Powershell was well suited as a language, but lacked the reach of javascript, plus the performance (at that time) was dreadful. The shoes version dissappeared around the same time as _why. (Coincidence? I think not.)

Late last year I decided to release it as a windows app, using a polished and thoroughly bus-tested version of the javascript implementation, wrapped in a browser control inside a skinny winforms shim. Early this year I went live with it, under the new official title of NimbleText. I've hunted down bugs and added features in the months since.

The latest release looks a little more metro than any previous version, as I stripped away a lot of the padding and extraneous lines, simplifying the appearance (and improving a few features as well, of course).

It's kind of amusing that after I chose to shun all of Microsoft's native application development toolkits (wpf, silverlight, and winforms) going with HTML for the UI, it seems like Microsoft have now decided to meet me half way, making HTML a first class citizen in Metro.

Anytime I'm faced with a new platform, I usually implement a version of nimbleText as my own personal hello world, and it looks like Metro will make it easy for me. Porting the heart of this baby to Metro should be a breeze. I'll still have to put in some design effort around how the supporting features are presented (what will happen to the menus, toolbars etc?). But I expect it will be a good ice-breaker.

Meanwhile -- if you ever write code or munge data, save yourself some time and use NimbleText. Both the download and the online version are FREE. There's no time-limit on the application and you only choose to pay if you want the extended features (customizability and commandline integration).

If you have features you want, please leave a comment here or send an email to supportexclude this bit@exclude this bitNimbleText.com

My book "Choose Your First Product" is available now.

It gives you 4 easy steps to find and validate a humble product idea.

Learn more.