Reminders of Hex past
While all the TV programmes have been looking back over the past year and pondering the future, I’ve been sitting here considering the future of web development, and contemplating how far we’ve come in creating websites. There’s no way I’m going to show you screenshots of my first website in this magazine (the production staff have feelings too), but I’m so glad we’ve moved on. Or have we? I was following an online discussion the other day about a new web design environment, and the old argument came around that this tool offers no more than what we had with Visual Basic 3(VB3). Now while looking back is usually done through rose-tinted glasses, it’s important to remember what exactly we’re now achieving using current technology to build web applications, compared to the sort of applications we were with building in the days of VB3.
Back then, the VB3 design environment enabled almost anyone to build a Windows application by dragging and dropping controls onto a form, a task that had previously been the preserve of a few hard-core C++ programmers. I remember being shown some work in progress by a very competent programmer who’d decided to look into this “Windows thing” and tried some coding. After two weeks of intensive study, he’d got his head around the concepts sufficiently to write a program that opened a window, then on user input opened another window and allowed the user to move, resize and close them. A VB programmer could have achieved this task in a couple of hours, such was the power of that environment. It led many people with no formal training into programming and developing applications, and some of these found themselves key parts of a company’s development strategy. Of course, there’s nothing to say that someone self-taught isn’t capable of writing working code: I’m self-taught myself and have in my time written some truly appalling but workable code.
However, many of us in the RWC section of PC Pro have since been at the sharp end of sorting out problems caused by some of these applications. Such applications would be installed onto a single desktop machine – often manually, because Visual Basic’s installer was broken for many versions and we all invested in third-party installation tools like InstallShield – from where it often would connect to an Access database that was shared in the true client/server mode we were all told was the way to go. This application would creak and strain whenever more than ten users were using it, and record locking was a pain, the locking mechanism often having to be written by hand to make sure it worked the way the developer wanted it. Such rickety applications often had lifetimes measured in years, and would be developed and added to as the company’s needs changed.
Compare this with a present-day web application, which will work on any computer the user happens to use, via a variety of browsers, and its number of users is measured not in tens but in tens of thousands. This web application has to work 24/7, with no downtime for database maintenance. Updates to the application have to be seamless and mustn’t conflict with previous versions or data. All this has a development time measured in months or even weeks in some cases, with changes and developments happening on an almost weekly basis to keep ahead of competitors.
The task of creating this new generation of web applications is no mean feat, and it’s moved on so far from the HTML Hairdresser days that such a term would now be considered insulting to the people who are achieving such amazing stuff on a day-by-day basis. Web applications are now not only critical to a company’s working strategy, but often to the lifestyle of millions of people, such is the demand put upon them. Comparing the development requirements of a modern-day web application to that of an old-style desktop application, then claiming we haven’t moved on in the development tools arena is just way off the mark.