If we '''ignore''' or defer the following issues: * CoordinateVersusNestedGui * Inconsistent Microsoft syntax * Proprietary engine and protocols * SeparateDomainFromPresentation 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: * GUI Component-based * EventDrivenProgramming * Events are closely associated with and/or grouped with components * Component attributes (a map) with an attribute browser * An IDE or tool relates visual components and their events and attributes together. * Control flow is mostly handled by the event-driven framework so that one does not have to iterate or use case-statements to perform related actions on groups of widgets. 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 highly proprietary and sort of "Java applets done a bit better". It still seems a bit fat-client, although I have not investigated thin-client approaches explored with it yet. ** I think you're thinking of Flash, not Dreamweaver. Dreamweaver is an HTML editor. 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: * Stay-put-ness rather than having to redraw a page after a Get or Post * Control over back button * Widgets, such as: ** A standard "grid" control to provide a spreadsheet-like data grid ** combo boxes (hybrid text and drop-down list) ** menus (menus in JavaScript+DOM with frames are a nightmare) ** tabbed sub-portals. ** Tree browser ** WebBrowserMissingWidgetWorkArounds 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. * {Is performance the only reason? If so, then Moores law will make the screwball J2EE approach obsolete in about 5 years. Plus, why not spread the load across a dozen or so servers if speed is the only reason? It is easy. After the customer logs in, divide up the load to different servers based on the first letter of their last name. A through C goes to server 1, C thru H goes to server 2, etc. It is just a CASE statement. Only the database would still be the bottle-neck (unless maybe you do WebStoresDiscussion kind of stuff), but it is no different than what big client/server apps face. Besides, I don't see any VB-like frameworks for non-enterprise stuff, such as low-use intranet stuff.} * ''No, scalability is the primary issue. Opening one connection or starting one thread per user is fine for 10 or 20 users. You can't do that for a web app. Also, you need to be able to take any server out of the cluster without interrupting processing. If all of my A-C users are on server 1, I can't do that.'' * [Modern database systems scale just fine. Whatever scalability trick you think that an App Server must be doing for you (queuing requests, pooling connections, threads and other resources, etc), all of them are available in a classic client-server environment courtesy of the database connector and improved DBMS software. Just check your friendly database vendor documentation, but do not assume that modern web app is auto-magically more scaleable than classic client/server.] * ''No, databases aren't doing everything app servers do. If they did we could just use a database.'' ** Doesn't follow. What was claimed was that DBMS software performs all scalability tricks that app servers perform, you responded to something else. ** ''I must not have seen these databases. Which ones provide connectionless session state?'' * {Assuming then that the RDBMS is not the bottleneck, then I see no reason why web design should be constrained by hardware limits. The technique describe above should allow nearly infinite users. You just have to replicate any code changes to all the web servers. In other words, it should be relatively easy to throw hardware at the problem rather than complicate the development process to force fit it on just a handful of servers.} * ''Everyone has a cost limit. I can't tell my employer that they will have to buy 1 CPU per user. I can't even tell them they will have to buy 1 CPU per 1,000 users. And I can't tell them their servers will have to manage one connection per user, either.'' ** They will have to regardless of whether you put or you do not put an app server in front of the database. Speaking of which, a more accurate estimate these days is that one modern CPU running DBMS server will support the needs of 10.000 '''concurrent''' users pounding the server with an average of one transaction per minute - this is a very conservative estimate. This is '''a lot'''. Putting an App Server in front of that together with a carefully crafted and deeply architected J2EE/.NET enchilada may reduce transactions rate quite dramatically. ** ''The servers will have to manage one connection per user? What are you talking about? HTTP and web app servers don't. The connection lifetime is limited to one request/response conversation.'' ** Find me a user these days who doesn't use a HTTP 1.1 browser, not to mention the HTTPs side of the issue. So your claim that the connection lifetime is limited to one req/response conversation is not true in general and if implemented would negatively impact usability. In case you wanted to claim that only the web server maintains the 1000s of connections and the processing is pooled/multiplexed over fewer threads/processes, and in that would be the miracle of app server scalability, you just need to pay close attention to DBMS documentation and you'll find out how you can set it up to do exactly the same trick. ** ''Persistent connections are only an optimization. The server is free to close those connections at any point. The underlying protocol doesn't depend on them. You don't really think Google keeps all those connections open for more than a minute or so, do you? The original author hasn't revealed which "HTTP oddities" he thinks should be concealed, but my guess is they are a consequence of managing sessions without persistent connections (which web app servers are required to do).'' ''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.'' * Did this guy just said ignorance equals impartiality? * ''You don't have to build rockets to witness rockets working.'' 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.} * With good reason. If you have any ideas for making web apps and their frameworks simpler, the world is all ears. * ''There are plenty listed under RemoteGuiProtocols. It is just a matter of evaluating them, implementing them up to a usable level, testing them, and making their protocols an accepted standard. Note that some have GUI builders and IDE's and some don't. But, once a standard catches on, the tools will come.'' * RemoteGuiProtocols doesn't seem to be talking about web apps. Again, it's easier to write multi-user enterprise apps than web apps. I've done both. The framework can be much simpler. It's tempting to think that web app frameworks can be simplified, but when I've tried I've become acutely aware of why they are all so complicated. * ''Well, let's explore some of those reasons. What are the hard walls that allegedly keep web apps from being developed more like client-server apps?'' * Web apps are developed like client/server apps. They are client/server apps. What do you mean? * ''If they are, then where are the VB-like tools that work with standard protocols?'' * What do you mean by "VB-like"? All web app development tools work with standard protocols. * ''Isn't it the case that some web-oriented tools require proprietary client-side techniques to achieve certain user interface effects? Perhaps they have modes for non-proprietary protocols, but one is generally faced with a trade-off. The more "tricks" one pulls with the browser, the more likely browser and browser-version-specific problems are to creep in. One of the first questions a good web-based software designer asks is what browser and browser version is being targeted.'' * And the most common answer (in my experience) is: "all of them". So let's ignore browser specific "tricks" and focus on the purpose of this page. How could web application development be made more like VB application development? When the original author imagines developing a web application using the "general Visual Basic approach", what does he have in mind? What complexity can be removed or hidden? (Perhaps I'm confused because I don't understand how the "general Visual Basic approach" differs from the general web application approach.) ---- 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?] * ''I haven't played with .NET yet. Will it create web apps that can work with any browser, or do you have to run Windows on the other end?'' * IIRC, you have options. The defaults generally "encourage" a MS-specific approach, and they purposely keep their fancier abstractions out of the open standards approaches. As far as being like VB, I have heard there are tricky limitations or work-arounds that keep it from coming close (unless you only run their demos). * ''Are these .NET applications usable from Opera running on a Mac?'' * [Irrelevant question. The relevant question is: does Opera running on a Mac support the same DHTML applications as IE?] * ''Opera doesn't support VBScript or ActiveX. If the .NET applications described above rely on those technologies in the browser then they require users to run IE. Do the .NET applications described above rely on those technologies?'' * No, they don't. .NET applications should run on most browsers - they do most of the tricky stuff server-side and send fairly standard HTML back to the client. .NET will push some things on to the client if it knows they are running a browser which can (for example) support DHTML, so .NET apps tend to run more smoothly on these browsers. But you can access a .NET app using Lynx if you want. :D * ''Cool.'' ''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. * I am not a web developer. However if the server application is asked to do the things client widgets are asked, then the post function will need to pass to the server the coordinates as well as user action (e.g. double click), afterwards the webserver would need to decode it and pass the information to the server widget to respond, and so on. If nothing else, the server probably do not have enough power and memory in the processor to run many concurrent instances of widgets. * ''It may indeed be the case that one has to keep a model of some kind of the UI in RAM or a database. But I don't see it taking up more than a few K per user. Also, for high-volume websites, one may have to be more selective about what information is passed back and forth by default. For a high volume system one may need to have more explicit ways to control such. But generally I am of the opinion that it is better to let machines slave away than humans slave away and to throw more boxes at the problem. Let the defaults be developer-friendly and then use profiling to figure out what needs more performance tuning. -- top'' * Why not just use a custom client or XWindows for low volume intranet apps? It isn't practical for a server to keep track of that level of detail for even moderate volume web apps. Perhaps your low opinion of web apps comes from using them when another technology would have been more appropriate? * ''You assume I have sufficient control over such decisions. Companies seem afraid to commit to old-style GUI's these days. They have been LegacyStamp''''''ped. -- top'' * And you think companies won't be afraid to use an entirely new standard? What benefits would your new standard offer over DHTML for web apps or XWindows for custom clients? * ''Nobody here appears to expect an overnight change. There will always be early adopters of promising new ideas, and they will help fine-tune them. Better to wait 5 years than 10 for better approaches to reach mainstream. Let's just get the improvement ball rolling. Maybe new approaches using existing standards can at least spark interest.'' * What new approaches do you have in mind? 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.'' * Nobody said to toss over JavaScript or HTML (or not yet). But there are painful repetitive tasks of handcrafting HTML and JavaScript to put for example multi-tabs look and feel, or Outlook left pane look and feel, mouseover effects, validation, popups for selecting values, calendars, etc. All these are abstracted away and generated automatically by good component frameworks. And good frameworks in order to be successful need to be on a standard platform (either open standards or de-facto standards) that supports components. MS platforms (both old VB for classic GUI, and the current .NET tools for both GUI and web applications) have built-in support and standard API for componentization. And support means everything from the run-time library to the design-time API for interaction between programmer/IDE/component. * ''Someone (top I think) just said "We may have to toss or overhaul JavaScript and/or HTML to get toward the ideal." I'm trying to figure out if he's advocating improving web app development tools or replacing web protocols.'' * {I am only proposing it as a possibility. I don't know if the current standards are good enough to come close. They seem borderline at this point. -- top} * Java on the other hand, has given components a bad name. Witness the difference in the market for ActiveX versus JavaBeans (not to mention EnterpriseJavaBeans - those are both unsuccessful, crappy, and essentially not component oriented). Also witness the fragmentation in lots of home-grown framework this and framework that (should I even try to enumerate them?) for building web apps in java. Does it do you any good that somebody wrote a calendar "component" (actually in Java it will be just a class with no design-time support) that works with "Struts framework", if your current project uses "tapestry framework" and your current IDE does not support either? 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''' * Rid or hide the "page replace" paradigm of HTTP. For example, when you submit a page and there is a validation error, rather than redraw the whole page again (with error markers), simply pop up an error message box and then have it change the existing screen/form if need be to hilight errors (such as putting a red box/background around problem fields). The existing screen would stay in place until a message came back from the server telling it to clear it or close it. This can be emulated with existing protocols using hidden frames, but it is awkward without a framework. * Add the widgets listed above to the standard. * Devise ways to emulate modal screens. This needs some thinking. The JS "alert" box is not very powerful. ** InternetExplorer already has modal screens, showModalDialog method; the MozillaBrowser and MozillaFirefox need to add this. * Devise way to disable the Back button. Client/server applications rarely had a Back button equivalent. If you have a multi-page form, then use something like tabs (resembling physical folder tabs). ** Security violation, it's not your browser, it's the users, you simply can't do this in a web app. Use Microsoft HTML Applications or MozillaXul application style and you can do whatever you want. ** ''The app designer should be able to control how their own app handles or ignores "back". As far as going "back" do *different* applications, that is another story.'' *** I agree that an app designer should have this power and this is why web-based GUIs are insufficient. You cannot reasonably expect to have that level of control over a browser. This is why writing a custom thin client is often the best (and, sadly, usually overlooked) solution to most of these problems. Once you factor out all the cross-browser issues (.NETs postback handling is nice in theory but generates exceptionally messy code and is difficult to override. It also creates a tendency to much tighter lockin than even the old "Only use the IE DOM" way did). Disclaimer: I write web apps for a living. The need to provide rich client functionality in a fundamentally limited platform is one of the most annoying parts of my job, especially when the gains from browser based functionality are generally minimal. ****I write web apps too. So to have a generic 'thin client' (not individual thin clients that you download from each website or company), there needs to be some sort of architecture for this thin client generica. And that's why I think people who feel the same way as I do should help contribute to a ComponentBrowser or ObjectBrowser, aka a general thin client language of some sort which uses objects and components ''instead'' of document(HTML). -- LO **** RemoteGuiProtocols *** ''I agree that there is BrowserAbuseSyndrome going on, but if we have to live with it, then perhaps some way can be devised to "catch" the back button and remind the user not to do it again.'' ****We don't ''have'' to live with anything. Things get better with time, things phase out. Just don't put all your money on HTML because it ''will'' be phased out. It will still be used to write documents like RTF is used. -- LO ****''Yes, but that is probably at least 5 years away. In the meantime...'' ---- 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 think the point has already been made, that web-apps are great for fairly passive content (eCatalogues, Reports, News etc), but are a bit of a pain for applications that require non-trivial user input/verification/RDBMS updates. I have recently been tasked with 'converting' a thick client to be a web-app, and the thick client is a)MDI, b) has lots of user interaction on it, c) most of the field verification is done on the form(s), and then 'passed' to an RDBMS table object for formating into an SPROC call. *** There is already such thing, but cross-platform based on Qt - Vedga/Glan (see RemoteGuiProtocols), so MDI etc. could be easily done. This still just moves GUI logic to the server (separate process for each client), though. -- nuclight 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: * EventDrivenProgramming ---- CategoryComponentObjectModel CategoryVisualBasic CategoryWebDesign CategoryInternet CategoryUserInterface CategoryComponents CategoryDiscussion