Client-side Scripting in DesignBais

DesignBais doesn’t have documented support for JavaScript or VBScript for customized client-side behaviors, but that doesn’t mean you can’t do it. Here’s a discussion on the topic.

One of the main purposes of JavaScript and VBScript is to put code into the client to avoid a round trip to the server – specifically to avoid a full page refresh. With Ajax techniques allowing us to use the server fairly painlessly, the need for scripting in average pages is greatly diminished.

I won’t take a firm stance on a position that we don’t need scripting, because there are times when it is much more efficient, or at least it seems elegant, to just put in a little scripting rather than making a round trip to the server.

The Position of DesignBais International

The DBI position is a bit more firm. They don’t support client-side scripting for a few reasons.

Interference with DBI code

There is a possibility that client-side scripting will interfere with the code that DesignBais itself generates and uses to manipulate pages. If a developer’s code conflicts with DesignBais code, DBI will get the support calls. The current stance is that DBI would rather have full control and responsibility for the client-side environment, and if there is anything wrong with their code they will fix it or make enhancements, rather than expending effort on problems caused by someone else’s code.

Why do we need scripting?

Support for client-side scripting implies that pages deployed with DesignBais need such a thing. That might be a faulty assumption.

The goal of DesignBais is to satisfy all needs of a real business application. What might someone truly need to do in a business application that requires client-side scripting? What limitation in DesignBais needs to be overcome? I’ve been hard pressed to answer this question myself. In a real business application where the end-user is doing data lookups and entering transactions we don’t need rotating banners or stock tickers. DesignBais already includes support for menus, dialogs, collapsing sections, hidden and disabled fields, clickable dynamic images and many other behaviors, so custom scripting just doesn’t seem necessary.

The DesignBais target audience doesn’t script

The target audience for DesignBais doesn’t know anything about scripting and an application that uses DesignBais along with custom scripting is un-maintainable by that target audience.

I need to approach this carefully. You as an individual and the decision making authority might be well versed with all forms of client-side browser-specific scripting. You as a developer might be providing solutions for your end-users and you want to take advantage of your extensive knowledge in the field. But next month or next year, who will be maintaining the code you’ve written? Most of my clients want to own their software assets. Many of them want sophisticated user interfaces but don’t have the skills to maintain them. They want me to kick-start their development process but they don’t want to have to call me to make a small change to some page. There’s nothing wrong with this. Remember that one of the original reasons why we all like Pick is that we can quickly make ad-hoc changes. The average programmer who learned about computers through pick BASIC knows nothing about cross-browser compatible JavaScript or VBScript. If I or another developer puts script into their baseline code, they now have another language to learn in order to maintain their software assets. This defeats some of the benefits of the Pick model for quick ad-hoc changes and of DesignBais as a tool for the average Pick developer.

My idea of a successful project is one where the client doesn’t need me when the project is complete. I’m all for anything that minimizes post-project maintenance because I like to work on new projects. By using JavaScript, VBScript, Perl, PHP, VB.NET, or C# in code that is intended to be "owned" by an end-user or someone else, I’m imposing a requirement upon them to learn my tools of choice. That’s not fair. Projects that use these languages must be agreed upon prior to development. It would be very bad if I were to write source code for resale or for someone else’s maintenance using a language that my target audience doesn’t understand – that compels decisions on the part of my clients to learn the language(s) or simply not buy my software. I’d much rather completely avoid this situation and keep everything in pure Pick BASIC.