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.