Where are the New Client-Side Development Environments?

By chromatic
August 6, 2008 | Comments: 3

Where are the New Client-Side Development Environments?

History repeats itself, first as tragedy, second as farce.

—Karl Marx

Clients and Servers

My first professional job was as a system administrator in HP in the '90s. The Internet was popular enough that even Microsoft had noticed, and Outlook viruses were about to shut down our site for a couple of days. (How fortunate that we had just migrated from HP OpenMail to Exchange.)

Two technical facts surprised me when I started. First, the administrative assistants in my group had to log into an HP 9000-based terminal application to reserve conference rooms and catering. Second, the logistics team collaborated by mailing around a multi-megabyte Excel file with ferocious amounts of VBA performing calculations and updating projections and prices.

Our IT group had two opportunities to provide applications to users. One was through our internal application installation console, by which users could request licences for specific pieces of software and we could push patches. (After ghosting a new Windows-based PC, the first thing I did was update the installation console, and then update new versions of applications.) Think of a slow, bulky aptitude which tracked licenses and received pushed updates, rather than polling. The second option was writing a small web application, or occasionally a Java applet.

The first serious program I ever wrote for an employer was a Java application (not an applet) installed on a recycled Debian box for the laser printer support group to log the printer class of all advanced customer support questions. Another developer wrote a Perl program to report the results every day.

The DarkNET

The Perl world has a term for all code not available on the CPAN: the DarkPAN. Though there are 15768 distributions and 59062 modules from 6803 uploaders available publicly (as of 12:24 pm on 06 August 2008), there's immeasurable private code in thousands of businesses around the world. It's possible to check the CPAN for uses of a Perl core API, or to test that a core change doesn't break existing and well-behaved code, but it's impossible to know if a change affects any or every part of the DarkPAN.

book cover book cover book cover
For a complete list of all things JavaScript,
visit javascript.oreilly.com

It's easy to postulate the existence of the DarkNET as well. This isn't gigamiles of dark fiber that Google purchased for own nefarious purposes. It's all of the Intranet applications someone wrote and deployed to a forgotten "server" under a desk somewhere. If HP still relied on those ancient '70s mainframe apps in 2000 when I left, what are the chances that some of my code from the '90s is still running?

While almost every Rails-based startup with magazine-cover perfect pointy-haired founders and rounded corners (the app, not the founders) eventually gets press and praise and attention, especially in the Silly Con Valley echo chamber, my rough guess is that there are orders of magnitude more little apps created on the DarkNET. It may be one order of magnitude, but two wouldn't surprise me and three is possible.

Why?

People want to solve their problems, and they're happy to work around what they perceive to be the most difficult problem. Often, that's deployment. As much as we might like to believe that Google Apps are inappropriate for business secrets, that PHP is insecure and unmaintainable, that CGI programs are unbearably slow and unscalable, or that mailing around multi-megabyte spreadsheets is sign of evil number four out of seven, sometimes they're the paths of least friction.

Apps for Non Programmers

The multi-megabyte Excel planning file made little sense to me at the time, but now I see several advantages:

  • Everyone who needed the information already had Excel with VBA
  • Anyone could update the data in place
  • No one needed a server, a PC always on, or a VPN

The only real problem was distribution, and my group had already solved this by using an Internet-available shared network drive. As far as they cared, sharing this application was the same as sharing a document -- because that's all it was.

If they'd asked central IT, I'm sure they would have been happy to open a support ticket and prioritize development and eventually produce some sort of server-based application, then eventually giving contractors and a couple of vendors limited VPN access to the application, and before you know it, months would have gone by.

I couldn't have written it much faster myself as a web application, and I still would have had to find a place to host it.

Mailing around new versions of the document wasn't ideal, but every form of deployment had its drawbacks. That's still true today.

One persistent debate lately revived by Ajax is whether shiny enough web applications will displace thick client applications, or whether Web 2.0 is a return to the bad old days of sharecropping in the gated community of grouchy mainframes.

Better than Worse, For Once

I wonder, though. I've worked on projects where the entire front end was a web site. That worked, as long as we controlled the servers. I've worked on other projects where the front end was a small client application written in Python which connected to a web service backend. That worked (at least, after we replaced SOAP with something that actually worked). Yet I'm a programmer, and I worked with programmers and system administrators. We had the power of source control and deployment and staging servers and production servers.

The huge Excel application I saw didn't come from programmers. Central IT had no small fit when they realized what my group was doing. Of course, that tantrum deflated somewhat when they also realized that they could offer nothing better.

A non-programmer in my group (a smart businessman, but very much not a technie) took a two-day VBA class and spent a couple of weekends honing his skills to be able to modify that spreadsheet. He'll probably never be a programmer, and that's fine. He had motivation and intelligence and he made things happen.

If the new paradigms for application development are either beg/borrow/rent time on a server and write your mainframe-style client-server application for anyone with a browser to use or learn how to write client applications and figure out how to distribute them and synchronize data, we're missing a piece.

Sure, users can still grab Excel and write a little bit of VBA and mail around their spreadsheets (or, worse, I hear Access still exists) -- but that's hardly portable, is it? It seems like a big step backwards from allowing anyone with a web browser to create and manipulate information.

Where You Come In

My friend Rael sidled up to me at Foo Camp a couple of weeks ago and said "You know, you can store a lot of data in the DOM and manipulate it there." All JavaScript apps need is a way to save their modified versions locally, and we may be able to provide serverless applications in-a-page.

Maybe it's insecure, maybe it's slow, and maybe it's stupid to pass around through email. Yet I wonder if it's sufficiently easier to deploy that it just might have a real ecological advantage. It might not make me a JavaScript fan, but you can write a very small virtual machine or interpreter in JavaScript so people don't even have to learn JavaScript....

(Attention potential startup founders: I'll take a mere 2.5%.)


You might also be interested in:


3 Comments

Thanks for pointing out how good Excel is at this sort of thing - it's really underrated (in our circles, at least) as a way of knocking together shared data applications with little or no programming work required. You can even allow several users to edit the same file on a shared drive simultaneously, with no special server setup required.

As for your final idea about client-side JS apps, take a look at TiddlyWiki.

DarkNET, sweet name! I get the deployment stuff being very difficult. Seems you also are mixing in the sharing being a difficult problem. What about maintenance? I've also been in a company where not one but many Excel files shared via a network mount where used to track important things such as products and customers. It certainly worked, for a time. Eventually these sheets caused enormous grief for our whole organization (we got big). There were small problems like changes being impossible to track (we couldn't revert back or diff two versions). Then there were really big issues, the worst being we had been working in this ad-hoc system so long that no one still working at the company understood the underlying mechanics of what we were doing. We had over ten price related fields for each product! No one really understood what they all meant. We had hundreds of other fields, and we understood very little. It was a nightmare!

@Rob, I agree, though with two caveats.

First, novice programmers rarely worry about maintenance. They're too busy getting things to work in any sense that the long-term isn't an interesting or useful concern. Their biggest problem is deployment.

Second, as Kurt Williams explained recently in A Little Reminder (or, why we did web apps in the first place), the point of web-based applications is to solve the deployment problem.

Popular Topics

Archives

Or, visit our complete archives.

Recommended for You

Got a Question?