What Is Wrong With The General Visual Basic Approach

If we ignore or defer the following issues:

then what is wrong with the VisualBasic/BorlandDelphi-like (VbClassic) approach to software development of interactive applications? The current batch of web tools is excessively complicated in comparison. If web protocols could emulate a component-centric and event-centric VB-like model, many of us web developers would be out on the street because it would be so much less labor-intensive. The web is great for static content and dancing e-brochures, but when it comes to interactive business forms, it is all being done the hard way in my observation.

Characteristics of the VB-like approach:

It is suggested by some that events may have to be split into client-side and server-side events for a web implementation. Ideally, the framework would hide sided-ness, but may not be practical.

Have you used MacromediaDreamweaver? It provides most of the above features for web app GUI development.

It is also suggested by some that this component+event model was what helped Microsoft almost wipe SmallTalk off the earth in the GUI realm in the early-mid 90's. SmallTalk GUI systems were growing pretty popular until VB came. SmallTalk fans may blame evil MS marketing, but I think its mostly due to the simplicity of the VB/Delphi approach.

I agree. Sometimes, writing web apps amounts to doing things the hard way for no good reason. It largely depends on your user community, but "old fashioned" code-running-on-the-client can have its advantages. (See http://homepages.paradise.net.nz/jjrusk/tech/rich_clients.htm) -- JohnRusk

That link seems to be suggest going back to "big local EXE's". It is not about running local EXE's. For, I think a RemoteGuiProtocols is a real possibility. I will agree that a local EXE will usually be snappier in response, but otherwise we can have the best of both worlds without local EXE's. The main things that HTML is missing is:

These were covered under another topic, but I don't remember it at the moment.

Re: "It is not about running local EXE's." 

 Why not?
Well, because it does not have to be. We don't need app-specific executables on the local machine to get a better GUI feel. My experience with Java applets over a modem left a bad taste in my mouth, even ignoring the security issues with "fat client" approaches. Maybe a compromise would be to use the applet as merely a light-footprint front end and put most of the business logic on the server.

There is a reason many companies are dumping their client-server applications for web applications. I don't necessarily agree with a lot of it, but it shows that simpler distribution and deployment is very important to software decision makers. They have apparently decided that simple deployment is more important than a rich GUI.

"The current batch of web tools is excessively complicated in comparison."

Do you have an idea for making simpler web application development tools? What complexity would you remove? How would you do it?

By putting the rules and widgets described above into a standard protocol.

The opening statement contains an unspoken assumption that web applications aren't inherently more complex than stand alone VB applications.

Oh, but that assumption is obvious. It's all about PutTheDamnDataOnTheDamnScreen?. Well, to be true there's an extra concern about security and input validation, but such things are solved once and for all by a good framework without burdening the developer of any particular application, just like the VB framework solves once and for all problems like creating buttons, tables and other gadgets, binding fields on the screen to database tables or results of queries, etc. There's nothing substantially different between a three-tier architecture and a classic two-tier architecture.

A case needs to be made as to why web applications should require such a mess of complexity as there are in the frameworks of today. (J2EE anyone?).

How about a thousand simultaneous users, to start with? I agree that writing a single user web app is only slightly more complicated than writing a single user VB app, but the demand for single user web apps is microscopic.

Thousands of simultaneous users can be handled by a VB client server application, no problem. Tons of business VB apps are written for enterprise system in client server mode, and expected to support more than 1 user. Disclaimer: I never participated in writing even one professional VB software system, my resume does not contain VB in the keywords section, hence I can claim to have no bias.

Are we talking about any large scale client/server systems or just web apps? If you've seen web apps written in VB with less complexity than equivalent J2EE web apps, I'd love to hear about them. If you're just saying that a large scale client/server system can be less complex than a web app then we agree. (Also, my resume has VB and Java in it, so I can't claim to be unbiased.)

{I don't think the author was talking about VB web apps, but rather VB client/server apps. ASP.Net does not yet approach the simplicity of "classic" VB, at least not without marrying MS proprietary protocols.}

Re: "Perhaps I'm confused because I don't understand how the "general Visual Basic approach" differs from the general web application approach."

Perhaps some examples. Suppose you wanted a Delete button on a form to delete the record being viewed, but only after confirmation. A VB-style would be coded like this (using dummy syntax): 

  function delete_but_click() {
    if (popUpConfirm("Do you really want to delete this record?")) {
      delete_record(....);
      thisform.refresh();
    }
  }
Doing this in HTML+JS requires putting JavaScript all over the page.

Or suppose there is some server-side form validation. The Submit button could be coded like this: 

  function submit_but_click() {
     status = thisform.validate();
     if (status.errorCount > 0) {
        popUpDisplayErrorMessages(status.errorList);
     } else {
        thisForm.statusLine.setText("Record Saved");
        thisForm.clear();
     }
  }
HTML+JS would spread this logic all over the place.

Field validation would also be associated with the field. JavaScript does not provide enough events to do this properly. Ideally we would want the validation to be closely associated with the screen widget, for example, but JavaScript tends to make one have to do this: 

  // JavaScript validation
  function validateForm(...) {
    ....
    if (form.field1.value > foo) {
      addError("Value out of range");
    } else if (form.field2.value == '') {
      addError("Value 2 Required");
    } else if (form.field3 ....
  }

Note that ClarionLanguage and PowerBuilder were known to be better with data-centric development than VB. They had frameworks that simplified query and RDBMS interaction. The point is that the good ideas of client server are not being reused for web stuff for some reason. Current Web stuff spends too much time dealing with HTTP oddities and/or dealing with the outdated MVC patterns.

Please explain how we can spend less time dealing with HTTP oddities and share more appropriate patterns with us. It's one thing to say my car uses too much gasoline. It's quite another to build one which uses less.

Again, browse around RemoteGuiProtocols. The biggest "trick" is to view HTTP as a message transferring system instead of a page/form delivery system. Past network-based protocols assumed faster response times. One just has to design such protocols for slower turn-around times, such as not requiring every character typed make a round trip to and from the server before the client sees it. Some events, such as switching form focus and closing forms, can (optionally) be handled by the client. Others, such as validation against business logic, should be done by the server. The client does not even need to be TuringComplete.

We already do all of this in web apps. How can we spend less time dealing with HTTP oddities? Which HTTP oddities are you talking about? What patterns are more appropriate than MVC?

If you think the existing batch of web tools and techniques are fine, then I guess you would not be interested in this topic.

If I thought the existing batch of web tools and techniques was fine, I wouldn't ask for your ideas about simplifying them. Do you have some?

My impression is that web apps are popular because of the simplicity of deployment, not because they didn't like the GUI's. But customers keep requesting GUI-like behavior in web apps.

Users want everything. They want simple deployment, universal access, smart clients, scalability, reliability, security, etc. The best way I've found to deliver all of those things so far is web apps with DHTML GUIs. Do you have any suggestions for practical alternatives?

Yes, make it more like VB so that I don't have to deal with ugly misfit protocols like DHMTL and tons of client-side JavaScript.

[Microsoft.NET does this already, you can just throw up a form, drop some controls on it, put some code in the event handlers and away you go... just like classic VB, so what exactly are you complaining about?]

OK, how would you do that? Do you have an idea, or just a desire?

Related: MicrosoftWebForm

MvcIsNotObjectOriented might have isolated part of the frustration. The VB approach tends to associate each event with the widget itself rather than spread its behavior around. The VB approach may be better encapsulation. The widget knows how to handle its own actions and the framework is designed around this concept. For example, you call a "validate" method on a form, and each widget fires it's validation event.

Are you talking about the server side or the client side?

Partitioning between them is probably the trickiest part. Some events probably make sense on the server side and some on the client side. For example, closing a window or changing focus can easily happen on the client side. However, validation against business rules is probably best on the server side. Hopefully the framework would hide as much of this as possible from the developer. It could "compile" the events and include the client-side interpretations at the client and the rest on the server. Or, maybe have predefined slots or attributes for actions that can happen on the client side. The server side could still issue commands such as "close window Foo", but it would perform the server-side actions before sending the Close command in the return results. Thus, a distinction probably needs to be made about "pre-server-side" processing versus "post-server-side".

VB has "property boxes" associated with each widget. To have this in VB style, two of the properties could be "client_side_close_window" and "client_side_change_focus". The value for changing focus would be either a form name or a form and widget ID pair. If we use dot notation, then we type into the property box something like "formFoo.textboxBlab". In our server side code we could still have an API call such as "setFocus('formFoo.textboxBlab')", but it would not take place until after the server side is processed and a standard HTTP Get or Post returns the new messages to the client. This would be useful if the closing or focus change is conditional, such as passing validation. If a form does not pass validation, then by tradition we leave it open. It makes sense for a Close button to act on the client side, however. The client side close and focus attributes would be converted into something the client understands when the page is generated. For example, it might be machine-generated JavaScript if it is implemented using existing web standards.

We already do this. I'm working on a web app using J2EE, Struts and JavaScript. I have client side widgets that perform what validation they can in a hierarchical manner as described above, and I have server side widgets that do the same. Every event is associated with a widget on the client side and the form on the server side (a form is the only widget that sends events to the server.)

Why treat widgets as being only client side and forms as only server side? That seems like an artificial distinction. To some extent the tool should hide away which side something takes place because it may change, or at least minimize the impact of moving where the handling takes place. Because it might change, our abstractions should not be unnecessarily coupled to sidedness. The point is to deal with each widget in one (perceived) spot and not let other issues cloud this viewpoint if possible. The "spot" is a set of properties and a set of events per each widget. If Struts etc. does this, that is great. However, my general observation is that they drag one through details of MVC cruft and other cruft. Maybe they are finally getting it right and I am just looking at the old documentation and examples.

Maybe it will have such events as "server_side_on_click" and "client_side_on_click" where the server side is written in say PHP or Java and the client side in JavaScript. I can live with that. For security and reliability reasons, I find it best to avoid JavaScript if possible, but the option for it should be there. It might also be prudent to wrap common client-side idioms in case the client language or framework changes or if the developers don't want to know JavaScript. But, that is just icing on the cake.

Re: "Why treat widgets as being only client side and forms as only server side?" Because (as I said) forms are the only HTML widgets that send events to the server. Clicking a button (that doesn't submit a form), checking a checkbox or changing a selection option doesn't send anything to the server by default. You can put code (JavaScript is the only widely supported language for that code) in the client side event handlers for those widgets to submit a form or redirect the browser, but the server just sees that as an HTTP request. It isn't an artificial distinction. It's the protocol we have to support.

I don't know about others, but there have been multiple times that I had to switch handling from the client side to the server side when it was discovered that the client side could not or was not permitted to handle something. In fact, that would make a good example: you start out with a JavaScript-centric approach, but after a security problem it is decided to switch to a server-based approach. Further, JavaScript lacks lots of events that a real GUI often needs, and one often ends up iterating through collections of widget pointers or a bunch of CASE statements to do what otherwise should be an event. We may have to toss or overhaul JavaScript and/or HTML to get toward the ideal. That is what this topic is about: finding out what is in the way of having better web UI tools. If JS+DOM+HTML are the problem, lets put the spotlight on them.

Huh? I thought this page was talking about improving web app development tools, not introducing new protocols and standards for browsers. JavaScript, DOM, HTML and HTTP aren't going to be replaced to make developers' lives easier. Is this just pure fantasy? If so, IwantaPony.

In case you haven't noticed the discussion was about abstracting the hodge-podge that you referred to, behind well-designed components. Where we do talk about ComponentBasedDevelopment as pioneered by PowerBuilder, VisualBasic, DelphiLanguage and not the hodge-podge currently known as J2EE. Well, Java finally reinvented some wheels as JavaServerFaces, but they moved extremely sloooow so far.

Huh? You just said you may have to toss or overhaul JavaScript and/or HTML. That isn't "abstracting" them.

I don't know if existing web standards can serve the purpose or not. You cannot abstract a color interface over a black-and-white printer (at least not without losing information such as color). Anyhow, it is still an open question. It may take a ton of JavaScript to emulate some favorite client/server GUI features, and in my experience the more JavaScript you use, the more problems and crashes you have. JavaScript and DOM are not meant to be a lower-level systems building tool. They are not robustly implemented and tested for such purposes by the vendors.

Does .NET have it?

[You guys need to pay attention to the industry... everything you're sitting here wishing for is what the .NET framework postback model is all about. It removes the web crap and let's you program just like old style vb, you drop a widget on a page, double click it, and put code in the event handler just like VB. It's not perfect, but it goes a long way in making web development look just like classic VB development for those simple form bases business apps. Nothing worse that listening to someone complain about something not existing when it does.]

I am suspicious of your use of "simple form". They often grow fairly convoluted or customer asks for features that are possible but difficult and one has to bend over backward to get the tool to do what the customer wants. Real life rarely ends up working like the box demos. Anyhow, there is a question of how much .NET relies on MS-specific technologies. There are also things like Flash Forms if you want to open the proprietary door.

[I say simple form to mean the same as in VB. You can just pop code into the event handlers and be done with it. This approach however, doesn't scale very well and at some point complexity forces you to organize your code better by moving it out of the form and into objects or modules or functions. But that also applies to VB. The .NET approach for webforms is virtually identical to the classic VB approach.]

I hear differently through the grapevine. However, they do seem to suggest that Microsoft is moving in that direction on each release. So, maybe after a few years they will have it pretty close. I just prefer not to depend on MS for the best tools.

A case of IwantaPony?

So? Some of us want to know if, why, how, or why not. If the pony is not obtainable, we will learn something about web technology and UI design. The Wright brothers probably wanted a flying pony as kids, and that got them thinking.

The person who started this page claimed that the "current batch of web tools is excessively complicated in comparison" to VB. I'm still waiting to hear how he would simplify them.

Simple. Make them more like VB. The open issue is whether or not it is possible on the web with existing standards. Is there somebody who has used both VB-classic and .NET extensively enough to comment on the differences with regard to GUI handling?

Steps or tips to VB-atize (improve) web application development

I have been kicking around the idea of making a general GUI browser with BorlandDelphi and making it open-source. Delphi is probably one of the most robust GUI tools around. We would just need to select and agree on one of the RemoteGuiProtocols. But, Delphi is still a bit Windows-centric. They are porting it to Linux, but I hear it is going a bit slow. Since most office workers use Windows, the Window-centricity may be a plus. One of the reasons Java GUI's didn't spread well was poor or slow Windows support. Another possible choice is Tk/Tcl.

Delphi on Linux is dead and will probably never come back. Good riddance :P. I prefer wxWidgets/C++ or wxPython for my cross-platform GUI needs.

I did try to use HTML and write a 'web-app', but quite honestly it was impossible. Most people could write a web-app to do basic CRUD work (Create/Read/Update/Delete), but when you're doing it for 30+ tables, many with 20+ columns, and FK constraints etc etc it becomes a nightmare. What's the solution .... Easy, use applets. Design each of the screens as an Applet, and pass the data as APPLET parameters. The applet can be programmed to pick out the parameters, and put them into the basic JTextField/JList etc components. The applet is also programmed with the constraints for each field, and a Save/Edit button to 'push' the contents back to a basic servlet which does the SPROC/RDBMS work.

Not only does this work, it also looks neat (ie VB like). When I have the time, I'll use Swing's JDesktopPane to get the MDI look. I'm also using the JMenu stuff to great effect.

Basic question is "Why use HTML when Applets are much better?"

How much neater would eBay look if it was an MDI application with applets/panels?

{I have found applets extremely slow to load. If you don't have high-speed connections, you can take a nap until load. Part of the problem seems to be that applets have to load a bunch of low-level stuff that a decent GUI engine should come with when installed. Another is that they appear by default to load every screen at once rather than as-needed. Further is that they somehow end up being fat-client anyhow. Other than more attention to security, it is not much different than downloading a file called "my_VB_app.exe". At least VB had a separate run-time engine option so that the libraries are already on the hard-drive (unless you change VB version). I am surprised MS didn't add an automatic web-based app update install engine to VB, negating the "sneakernet" installation complaints. Java is also not necessarily one's favorite language. MS's fight with Sun over Java in browsers didn't help version issues either.}

Well, it's arguable that Applet's are "so much better." With modern javascript techniques and web development technologies (i.e., RubyOnRails which uses Prototype.js, a multi-platform shell over many of the best Ajax features), many of the interface advantages of an Applet become less pronounced. Now, web applications can handle actions without page reloads, dynamically updating page content as the go. Compounding that is the agility of even the worst web solutions. Rapid and easy UI development means a faster time to market and more iterations over the product, compared to the relatively slow process of GUI development.

Another issue with Applet-based interfaces is that they generally destroy all web interaction. Your back button stops working, you can't save state (without keeping user cookies), it's very challenging to make hyperlinks that lead to specific points in your applications. Beyond that, many people use RESTful APIs to build services on top of each other.

Consider Google Maps (http://maps.google.com) as a good example. What, exactly, would it gain by being an Applet, and what would it lose? You'd lose linkability, printability, and the ability to replicate the back button if you went with an applet. What would you gain? Certainly not speed, javascript engines are extremely fast these days (thanks to the pioneer work done by Sun with their Self Language implementation), and can use the WebBrowser's caching scheme to preserve image and query data. You could reimplement printability, linkability, and maybe even make it all a SOAP backend, but this is reimplementation of already existing functionality if you just implement it inside your web browser.

{I don't think the 'Back' button is a good idea for most GUI's anyhow. It is meant for static documents. For dynamic stuff it can be confusing, inconsistent, risk data integrity problems, etc. Somewhere there is already a discussion about that if I recall.}

I suppose you could argue that web development is moving more towards thick-client paradigms these days, and I'd agree, but these are cleanly melded with the previous thin-client paradigm that still dominates most of the web, making it a superior choice to Java Applets in nearly any imaginable respect.

OK. Good points well made, but is there ACTUALLY anything wrong with applets? Just because RubyOnRails uses lots of clever JavaScripting? to look like a VB GUI, doesn't mean it's any better/worse than applets. Just different. Surely Ruby et all will always be catching up with Swing in terms of presentation. And in terms of rapid UI development, I wrote a tool for basic GUI design, so I can churn the screens out in minutes, and they link to the RDBMS tables so all the type checking etc etc is built in (which is what I gather RubyOnRails does).

You're right that Applets mess up web interaction, but things like Back Buttons are surely only on web browsers because historically browsers were pretty dumb HTML interpretors. Generally, the back button is pretty broken on many HTML/DHTML web-pages, so it's not a problem unique to Applets by any means.

Nothing wrong with googlemaps. However, have a look at the route finder on www.rac.co.uk. Now that's what an applet can do.... Horses for courses. I'm not saying everything should be applets, it's just some things are much better as applets.

Personally I hate writing HTML pages, all that mixing of display tags with data, style sheets, .js files etc etc, and doing it from JSP/ASP is no better as you are now mixing VB/Java with display tags and data. Applets work for me, as the display is pre-defined in a proper coding language, and can be tested away from the browser. Then all you have to do is plug data into it.

Thin client is a myth anyway. Next time you're on ebay, do a 'view source'. 99% formatting, 1% data. Not thin by my book. That's a whole load of interpreted layout. Plus, it's reloaded every time you refresh, which makes it slow. If it were an Applet, the refresh would just get the data, not all the HTML tags. Much simpler.

In Ebay's case, this is what Ajax and Javascript DOM are supposed to do. Another possibility is XSLT, which really is a terrific solution if you're willing to take the time to write the translation. I used to hate doing web work, myself. But these days, we have sexy tools on the backend (RubyOnRails) and very powerful and useful tools to help separate presentation and data (i.e., DOM3, XSLT, CSS1-2, Javascript, XPath). I actually enjoy webdev these days. I think this kind of system is the future of application development, and I like the idea of blurring the line between a user's computer and the internet. Check out Apple's Dashboard feature for a very interesting take on how web development can blur the line.

Ebay and Amazon are good examples of Legacy Applications. They're messy and ugly. As we move forward towards a BraveNewWeb?, complete with ironclad standards compliance, significantly better software developers making the right choices (as opposed to the flood of talentless hack wannabe "PHP is t3h m0n3y$!" people who should stick to designing, since it's what they're good at).

My aversion to a world of Applet-based webapps is not just an extension of my hatred of Java (a language I consider to be one of the biggest mistakes in the history of computer languages), though. Part of the benefit of the in-browser system is a weird, almost paradoxical, consistency between apps. Sure, all kinds of things change from site to site, but the security model and general appearances and capabilities stay the same. The global "rules" stay consistent. It also means that a site's presentation can be consistent with its application layer, which is an important feature. Pretty much every presentation format to date can be seen as a richer or poorer type of hypertext; windowed interfaces seem to be rather bad at it by comparison, usually just dumping you into a hypertext-ish presentation in the window space.

DOM with a client-side JavaScript engine is already a kind of "fat client". If Microsoft would have made a VB "client" easily downloadable as a kind of browser plug-in, similar to the way Flash is, then they could have kept a lot of their market share. They would just have to devise protocols to transfer database queries and other server-side info.

For me, nothing is wrong with the WhatIsWrongWithTheGeneralVisualBasicApproach, in fact, it is becoming very popular... and contrary to expectations, the best example is not ASP.NET, but the GoogleWebToolkit, (and other frameworks like Echo2, ZK, or OpenLaszlo... and if you dont "have to have" an HTML/JScript based UI, and don't care about depending on a plugin, there is also AdobeFlex).

I believe, that now, the industry is demonstrating that there is nothing wrong with the general visual basic approach because RichInternetApplicationsAreTheRevivalOfTheGeneralVisualBasicApproach?, all that all those frameworks are trying to achieve is a way to fit a VisualBasic like programming model into the WebBrowers?... and the funniest thing is that everybody thinks RichInternetApplications (RIAs) are such a great innovation... IMHO RIAs were invented a long ago (when JavaApplets? were created), the problem I think, is that Sun didn't realize that the reason for the big success of web presentation technologies was going to be... VeryPrettyDesign?, and Swing applications are an example of VeryUglyDesign?. Sun should have included a fully fledged ui design application, right from the start, something like Dreamweaver, or FlashProfessional?, or like MicrosoftExpression?, something any GraphicsDesignerThatDoesntKnowAThingAboutProgramming could use to create stunning looks... applets always looked ugly... or at least always looked worse than HTML or Flash based sites...

Mmmm... well, maybe not everything is lost, maybe OpenJavaFX will save java based RIAs... if Sun doesn't take a lot of time in integrating OpenJavaFX with a good designer application...

Or... maybe, we should ask ourselves.. WhatIsRightAboutTheRichInternetApplicationsApproach

The creation of GoogleGears is more evidence to probe this point... everthing that was possible in old heavy clients, will be possible inside the webrowser... even databases... until someone realizes that the webbrowser is just "that thing around my application" and finds the way to make it as "invisible" as MicrosoftWindows is for any WindowsApplication?... and the circle will be closed... and we will be back on a trend to build "heavy clients"... in other words... IsThereReallyADifferenceBetweenRIAsAndHeavyClients

Yes, there is. We generally expect the RIA standards to be open. There are already plenty of proprietary "solutions". In addition to helping the licensing issues, it would reduce the need to install special stuff for each app.

As far as I can tell RIA means Rich Internet Application, there is nothing that implies "openness" there. Or are you telling me that Silverlight or Flash applications are not RIAs?

The result would be a Rich-UI Applications that just happen to use some of the Internet. The UI is not based on Internet standards. (Although, I imagine we could do a LaynesLaw dance about what an "Internet standard" is.)

See also:

CategoryComponentObjectModel CategoryVisualBasic CategoryWebDesign CategoryInternet CategoryUserInterface CategoryComponents CategoryDiscussion

EditText of this page (last edited November 29, 2013) or FindPage with title or text search