Proof-of-concept & fast-prototyping
I use Perl/CGI/Apache2/MySQL for proof-of-concept/fast-prototyping–which usually takes one to two days (or weeks). Once the functionality, testing, and etc. is done, I send the specifications and the URL to another department. Then I wait for one to two months for them to come back with a Windows .NET program (usually written in C# or VB) using MS SQL Server. During that time my co-workers continue to use my web-based stuff. (BTW, this is in a corporate environment with annual revenues of about four billion dollars and 5,000 employees.)
PatPending
SWILL: Simple Web Interface Link Library
If you plan to expose your application’s GUI through a web browser, have a look at SWILL, the Simple Web Interface Link Library. With a couple of function calls you can add a web front-end to any C/C++ application. I’ve used it for adding a front end to the CScout [spinellis.gr] source code analyzer and refactoring browser, and for implementing a wizard-like front-end for a stochastic production line optimization toolkit; I also supervised a student who worked on a SWILL-based gdb front end (unfortunatelly he didn’t finish it).
SWILL is great for adding an interface to legacy code, because its impact on the application can be minimal. I wouldn’t recommend its use if your GUI requirements are above what can be implemented in a dozen web pages.
Diomidis Spinellis
Those who fail to understand GUI apps..
Are doomed to reinvent them, poorly, in a web browser.
The premise of the article is that a local application written to target a local server with web browser client is better, but then goes on to say essentially ‘ok, here are all the pain in the ass things to overcome when trying to scale it down to a single user compared to typical web server environments’. In his article, he is trading one perceived pain in the ass set of things for another. The unstated stuff is you are requiring the unmentioned user to first have a webserver and CGI environment set up correctly before even beginning to run your app (since the aim is to be standalone on a box, the user’s system is the server). He mentions some shortcuts you can take by assuming some network security things and no DB, but in the end the shortcuts are still more work than simple GUI apps for the equivalent task.
Junta
You web developers…
Genuine bona fide web developer, right over here, with a bachelor’s in theoretical computer science.
The fact of the matter is that web applications are a pretty good idea if what you’re trying to do is simple enough that a browser makes sense as a GUI, or is likely to change often enough that you need to constantly update it. And if you’ve got something where users edit information that has to be publicly available right away (read: CMS systems, calendars, various news sites *cough*slashdot*coughcough*), your publishing is just about as simple as it possibly could be.
mstahl
When the web apps are taking over …
A lot of people are replacing client-server apps with browser based apps, with zero install hassles - which this particular example doesn’t really have. But learning to build html apps in CGI mode is easier than re-learning event loops for GTK land (even in perl).
Of course, debugging in-browser apps is getting easier with firebug [getfirebug.com] and other developer oriented firefox bits. Now, whether the app is built using perl-CGI, mod_perl, php, ruby on rails, even servlets doesn’t matter - the UI can actually work very well. For instance my sudoku [dotgnu.info], in fact looks better in HTML than if I (let me repeat, if *I*) had done it with GTK or MFC.
Gopal.V
Ugh
I’ve had to support a lot of web-apps, and I can say a web browser is *never* a better interface than a GUI application.
If they meet the following restrictions, they *might* be considered equal:
1) Does not use Java.
2) Works on multiple browser, including future versions of IE which may have more strict security settings.
3) Does not require any client-side settings to work. (For instance, lowering security settings, turning off the pop-up blocker, etc.)
But every web-app I’ve ever had to maintain in a corporate environment violated every one of these rules. And I’m talking about big companies making these web-apps, like IBM and Siemens.
Blakey Rat
GUI switch to browser: success story
(Last Journal: Saturday January 20, @12:46PM)
You are exactly right. When other business competitors (to us) were developing elaborate GUI based alternatives to our browser portal, our clients (and theirs) migrated to our platform instead. Which Industry? The Insurance companies - Progressive, Infinity, State Farm, etc. It was a perfect match for all their agents distributed across the nation (and who weren’t even located on those companies premises). For heavy form processing, the browser already provided the interface - the backend delivery system we developed was a snap. And this was over a decade ago, long before distribution across the internet - just using their intranets. The biggest bonus from this GUI switch to browser? Maintenance - by far. Feature changes (like menu arrangements or additions) a close second.
skoaldipper
JavaScript Event Problems
I think major compatibility issues always have to do with the very basic ways the different browsers handle javascript and event. A GREAT example is if you ever have to write somecode for when a page unloads. It’ll work fine in IE, Safari, and Firefox, but good luck getting it to work on Opera. I spent hours trying to figure out why onunload didn’t work on Opera… apparently it’s a “feature!”
Anyway, whenever I’ve had problems with script compatibility it’s ALWAYS been with event hooks, and with very basic interpretation differences in javascript between browsers. And let me tell you, getting these scripts to work is a LOT more than 5 minutes per browsers. Sometimes you’ll need to write an extra 200 lines of script just to get the same feature in all browsers.
Bozzio