When a CGI Script is the Most Elegant Solution 256
An anonymous reader writes "Writing local Web applications can be quick, easy, and efficient for solving specific Intranet problems. Learn why a Web browser is sometimes a better interface than a GUI application and why experienced Web developers find themselves struggling to learn a GUI toolkit, and descover that a simple CGI script would serve their needs perfectly well, if not better."
When is a CGI script the most elegant solution? (Score:5, Insightful)
Easier than Networking! (Score:5, Insightful)
Quick web scripts are way easier than developing an application if only for the fact that you don't need to figure out how to use networking in whatever language you'd be working in. Plus, you don't need to "distribute" the application once it's done, and you don't need to provide updates to every user on your network who's using it: update your script, update the application.
Plus, developers think in program logic, not in program design. A web script let's the developer write their output in HTML, then go back in later and add some CSS for presentation once they've got the program actually working. I say, it's a good way to do things.
Not to mention that a lot of web scripting languages are easier to use than full-blown application languages, and there are many packages that let you attach native GUIs to web scripts. There isn't a compelling argument not to go that route if your application a) uses networking, and b) is distributed over an intranet.
How about a step simpler? (Score:3, Insightful)
Ugh (Score:4, Insightful)
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. The end affect was:
1) Some only used MS Java, some only used Sun Java, meaning that if a browser had one web-app installed you couldn't install the second one because the Java version would be incompatible.
2) They worked on IE only, which only exaggerated the downfall of the previous point. (You can only have 1 IE per computer, and 1 Java per IE, web developers!!) In addition, it meant that the company I worked for had to freeze IE upgrades to prevent breaking web-app features.
3) We had tons of security problems because of web-apps that required the pop-up blocker to be turned off, or security features to be turned off. (You can only have one set of settings per browser, web developers!! And most of the time, trusted sites doesn't cut it, from my experience.)
Even if all these conditions are met, there's still a good chance that the interface of the web-app might plain suck. The web-based ticketing system "feetimpressions" (not naming names because I still have to work with it, but I think you can figure it out) has a terrible interface. It would be equally terrible as a desktop app, but at least it would run quicker so when you made a mistake you could undo it quicker.
* To be fair, one of the web-apps above was basically a Lotus Notes database converted into a web-app, and Lotus Notes has its own enormous GUI blackhole which seems to suck in any good GUI and mutilate it into something frightening.
Another issue (Score:5, Insightful)
One of the issues that concerns me is what essentially amounts to hijacking of my processing resources. One example is animated ads. It takes CPU power to continually flip a large ad's frames; that's *my* CPU power. So I don't let flash or animated GIFs run unless I make an exception. Same thing applies, for instance, to the difference between slashdot and digg. Slashdot provides a static page. I can load it, and the fact that it is loaded costs me nothing in particular. If I flip away from the browser, it doesn't chew CPU time. But if I load a digg page, my CPU is pegged for a while, especially with large pages, because digg is bloated, slow-as-hell pigware that uses *my* CPU to display and organize its content. Guess how much time I spend there. :)
As I generally have other things going in the background, I don't take kindly to profligate use of my resources; animations, pigware, etc. I keep my eyes open, and I tend to spend time on places that more resemble slashdot than digg in this regard. I *will* bite if the site offers something that overcomes my urge to keep my cycles for myself, but that is a conscious value judgement, not an accident.
Generally speaking, there's another advantage for sites that produce HTML and CGI forms, and do not depend upon the user's computing environment, and that is broad compatibility. If you stick to the basics, then the broadest set of browsers will function with your "stuff." No Java, no PDF, no flash... just the basics. You can make beautiful, functional websites (assuming you've the art skills) with the basics. I see no need for more; the value is in the content, and it isn't like you can't make a good presentation. The first thing I think when I run into a morass of Java, etc., is "incompetent."
But that's just me. :)
Re:Ugh (Score:5, Insightful)
Re:Easier than Networking! (Score:5, Insightful)
Honestly, as a web developer, I've never quite understood this. Whenever I design a website, it'll often look different in multiple browsers (read: it'll be effed up in Internet Explorer), but unless I use a particularly fancy bit of JavaScript, they almost always functionally work the same in multiple browsers. I just don't get it... are the people who are writing the web apps really that bad with their concept of standards? Are they relying on browser bugs to do a job? Or are they just getting way too cutesy with their JavaScript? Should someone give them a dictionary open to the word "testing"? It just seems to me to be silly not to spend five extra minutes per browser to open your app up in IE, Firefox, Safari (if Macs will be using the app), and Opera (which is pretty guaranteed to work if Firefox and/or Safari does).
Other than that, though, I agree with what you're saying, in many cases it looks like a full-blown app would be the best solution. I was thinking along the lines of quick fixes that were easily expandable, though, which in my mind is best for web app.
But hey, in computers there's no wrong way to do anything, right? You just need to gauge which method will make your users swear the least. ;)
Well, sort of, Yeah -- maybe (Score:3, Insightful)
First of all, writing a simple GUI application using say Python and TKinter is probably easier than writing a web application. I'm sure the same is true of Ruby, Perl, etc. Or Visual Basic for that matter although VB's database interface (at least in VB3) was so obtuse that I decided to find another language. All of those languages will handle the Event interfaces relatively gracefully.
Second even the localhost (127.0.0.1) interface is likely to be a bit jerky.
Third, No two browsers will render HTML beyond the "hello world" level consistently. Conceptually, that shouldn't matter, but if your input boxes don't appear or line up with inappropriate material in the page display, you can end up tinkering with your application well beyond what you originally envisioned.
Fourth, Browsers cache web pages. They don't always figure out that the page you have requested has changed. It looks to me like NOCACHE statements in HTML pretty much don't work. They may work when used in the HTTP (1.0 or later, right?) header, but getting them there may be non-trivial. This is not a big deal if you are the only user and understand caching since all browsers allow you to force a page reread. But it is not going to work out well with ordinary users.
I'd say that there is a place for simple web applications. But there are a lot of situations where alternative solutions are probably going to be more usable or simpler than a web browser, server, and CGI.
So, CGI is a perfectly OK tool, and maybe it belongs in the toolkit. But it's by no means universally the best solution.
Re:Ugh (Score:3, Insightful)
If you think back, way back when Windows 95 was out people were making the same prediction that web-apps would replace OSes and in the future the only OS would be the web-browser. It didn't happen then, and it won't happen now-- because web-apps suck. The only solution is to write a new internet protocol (not HTTP) designed specifically to run apps from a server... but by that point, you might as well just run the Windows app over a fileshare because it's the same thing.
There are a lot of reasons that web-apps suck, I was just barely scratching the surface.
The Screen is The Interface (Score:4, Insightful)
Yes, I often do use a web browser as a script GUI. A web browser changes a few HTML text strings into a pretty display.
Re:Easier than Networking! (Score:4, Insightful)
Re:You web developers... (Score:5, Insightful)
I don't understand! Help me? (Score:5, Insightful)
It sounds like the author is recommending a single instance web server application running on a local machine that uses a file store instead of a database and CGI as the programming interface. (In other words, this is NOT an intranet application for multiple users!) Doesn't sound that simple at all. In order to do this, you must:
- Know at least one programming language for CGI.
- Know HTML including forms, postback and session.
- Understand the limitations of web browser UI elements. (There are many.)
- Install and maintain a webserver on your local machine.
- Build a robust file store interface. (Even loading / saving / parsing XML files with backups takes time...)
- Install and maintain permissions for the file store.
- And more...
Sounds like all of the disadvantages of the web with none of the advantages.
Why would you not use PERL and CSV IN/OUT files for simple (or complex) command line processing -- and if you needed a really simple UI, then Excel with Visual Basic. (This isn't easy, but it's a lot less technology to learn and maintain.) Anything more complex: Java, the free version of Microsoft VS or xcode. Anything worth doing is worth doing well.
Re:Ugh (Score:3, Insightful)
The rest of your post IS right though, now I wish most analysts/project managers/architects would get that. Right tool for the right job, and its not always the web, no matter how buzzword-compliant it can be....
Re:Easier than Networking! (Score:5, Insightful)
But which bits of java script are fancy and which are not? And how often is almost always? It comes back to pushing stuff out on the server and crossing your fingers...and there is plenty of that inherent in development without your two qualifications. I guess I'm kind of anal, but, dammit, when I write a line of code I want it to do the same thing for everybody that runs it. That way I can focus my attention my own boneheaded mistakes.
" I was thinking along the lines of quick fixes that were easily expandable, though, which in my mind is best for web app."
Quick fixes that are easy expanded tend to grow into gigantic morasses of tacked on code with no toplevel design. In 20 years, the poor churl that has to deal with that monster will be damning you to the fiery depths of hell!
Those who fail to understand GUI apps.. (Score:5, Insightful)
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.
As to his fear of GUI toolkits, it's actually mostly silly. He sums it up by saying web browsers don't make you deal with 'resize events, window expose events, or menu events', but the truth is for a GUI application of the complexity he speaks of, GUI toolkits largely don't *make* you, they *let* you. If your application is as simple as what he prescribes, you can ignore that whole functionality of the toolkit. Sure you have to connect events to widgets of interest (i.e. buttons), but you have to do the exact same thing on webapps, but with different wording. If your application has some reason to start messing with the sort of stuff he fears dealing with and is implemented in a browser, a whole lot of pain is in store for you with obscure, platform specific javascript aplenty. Similarly, he mentions file opening/saving, and font management, but again, the toolkit usually has user-wide settings you can ignore the existence of just like a browser for font and style, and evoking the Toolkit standard filebrowser is usually exceedingly simple (along the lines of filename=Chooser() (not a specific language/toolkit)).
I have dealt with quite a few 'webapp-for-everything' people, generally they make web apps with an exceptionally clunky interface that responds poorly (I actually dislike Gmail's interface, but Zimbra was impressive, but still sluggish). If I find myself using it frequently and I can find out what it is frontending (usually a database for general apps, imap for mail, etc), then I write a quick GUI application or use a standard standalone app to do the same thing. I end up with a smoother interface that lets me be more productive, and often things run faster (webapp deployments are frequently the bottleneck, the backend could service far more than the webapp can push through for whatever reason). Whenever I do that and someone glances me interfacing with a system notoriously annoying in interface, they always want my application. Again, good Webapps can be on par with GUI apps, but for all the reasons the guy mentions, webapp developers mostly think implementing everything as simple forms is the way to go and that sucks for a lot of usage. GUI apps of course can be written piss-poor as well, but the typical GUI toolkit primitives are richer than simple HTML forms.
The only potential thing depending on how the app manages data and how it could be useful is the issue of scaling out/up. With a standalone GUI app, the barrier to running it remotely and having all your data in one place is higher than webapps (if running it remotely, must have X/RDP/VNC client installed on your random client which is less likely than a browser, if just having the data remote, still have to get the data accessible via some means and your client must have your software). This is a hard thing to define concretely, but the implementor should be able to make this determination fairly easily.
Re:Easier than Networking! (Score:4, Insightful)
With a web app, you also download your code with every single page. Graphics. HTML. Javascript. Every single time.
Yeah, or you could try caching stuff locally on the client machine. This can easily be done with expire-tags or similar. I'd also considering using inline CSS and JavaScript instead of linking them in externally as files. Surely this will reduce the network load. One could also use AJAX where applicable in order to keep pages from refreshing too often. This would also make the app quite snappy.
Otherwise, a high level language running directly against an SQL server is the way to go
Again, this traffic across the network would not exist if you used a web application for the purpose. So, perhaps the HTML transferred through the network is in fact equal to the SQL flowing back and forwards? Hmm.
Then there is the joy of browser compatiblility. You start out saying, oh, we will only support browser X...but it never sticks...and your regression testing grows geometrically with each browser and version of browser you support.
Ok, but what happens to your precious application when your company's Windows users are screaming for a functional version? Mac OS X? The web is a great tool if you need to deliver content and functionality across different setups. I'm sorry, but to me your arguments sound silly. I believe this is a matter of relativity; if I know how to create web based applications (internal or external) and do it good, then it'd probably be the wisest choice instead of me trying to learn "a high level language". Of course, this goes both ways.
Here's what happens a month later... (Score:4, Insightful)
"Okay, can we have a basic real-time price chart on that?"
"Can you pick up the settings for my main thick-client work application and use those?"
"This is OK for offline work but now that we're using it seriously it has to respond to clicks right away."
"Ok, when we enter the currency pair, the visual display of the curves should update immediately before we enter the price, just as a sanity check."
Of course you can always reply:
"Well, I decided to do this as a CGI script. That meant a bit of a tradeoff whereby it was easy to develop at the time, but we can't really extend it with rich client-side functionality like that."
To which the correct answer is:
"Looks like YOU have a problem!"
Okay, that doesn't ALWAYS happen. But it certainly happens a lot -- if there's any chance that that the solution will be compared to thick-client apps, it's really not a good idea to start with the web. When everyone's lucky, the result is that work starts on a proper client application. When everyone's NOT lucky, the Java applets and DHTML wizardry come out, and you're left supporting and justifying an increasingly complicated solution that's heavy on scripting and net traffic and that's competing with solid (usually C#) client/server apps. Which is a pain.
It can work (Score:2, Insightful)
Re:Well, sort of, Yeah -- maybe (Score:2, Insightful)
Re:Those who fail to understand GUI apps.. (Score:4, Insightful)
The original post was solely about CGI, and not at all about client side javascript. This being slashdot, however, almost nobody bothered to notice.
Yes, compared to a "real" gui, html forms don't have the same richness of user interaction possible. Guess what? For 90% of applications, that's a GOOD THING. Forms have evolved the way they have because they're reasonable and reasonably secure for networked UIs. There's always temptation to use some shady "experimental" ui technique, but it turns out that developing good UIs is tricksy, and that these are failures most of the time. Stick to Forms unless you know the reason why not.
There are other advantages as well. Is the best language to solve the problem something wierd and non-deployed, ala Common Lisp? CGI lets you use the language of your choice, without having to do security audits on all the machines envolved.
CGI also enforces a fairly strict seperation between application guts and UI. Even in this day and age, many people still manage to mix these, to their sorrow.
Unlike GUI platform of your choice, CGI has not changed specification since, what, 1994? A script written then will still run today. The same can not be said of GTK or KDE or Mac apps, and I'm not so sure about Windows 3.1 to Windows Vista compatiblity either.
I'm mystified as to why Parent thinks enabling CGI is a "pain in the ass". For me it was a 1-line change in apache.conf for the first script, and then a 0-line change for each additional script. What's so hard about that?
Re:What about PHP? (Score:4, Insightful)
Common Gateway Interface [google.co.uk].
PHP is just another language that can be used for a CGI script.
Re:Easier than Networking! (Score:3, Insightful)
[1]Geeks will be the exception here; I always set my browsers to download a fresh copy of files "every time" as opposed to the normal default of "once per session."
Re:Ugh (Score:3, Insightful)
Yes.
Until you can, web-apps will never be of the same quality as regular applications.
PHP-GTK apps are not "web" apps. They are scripts that can be downloaded. They don't need to be compiled - they are scripts. PHP is usually used for server-sided website processing. But it also works very well as a shell or client script, comparable to Java or Python in many ways.
If I'm writing an email in your hypothetical "PHP-GTK" client, and I correct a misspelled word by saying "Add to Dictionary," will it add it to the OS X system-wide dictionary?
Can - but you have to be careful. Is your application going to focus on being cross-platform, or on being tightly integrated? There's a new saw at work: A) cross-platform, B) cheaply developed, or C) tightly integrated with the O/S. Pick any two.
Outlook/Exchange has a nice online webmail client, but do you know anybody who uses it instead of Outlook when sitting at their desk at work? No, because actual Outlook is quicker, more integrated with the OS, can pop up reminders in the system tray when your meeting is coming up, etc... it does more than a web-app does, and it does it faster and easier.
Except that, increasingly, software, especially web-based software, is being used to coordinate the enterprise organization cohesively. In this environment, the advantage gained by this coordination can quickly and easily outweight the advantages of drag and drop or having a dictionary that integrates with the O/S.
And don't think that "enterprise organization" means some megacorp. "Enterprise" today can mean your local school district, fire department, or your local newspaper. All of these have numerous and consistent requirements for coordination, and all of these can benefit from the appropriate use of centralized information technology.
You don't use a hammer to drive screws, and a drill is worthless with nails. Each has their set of advantages and disadvantages. We'll continue to see the evolution of both technologies.
I won't expect a web-based first-person shooter anymore than I expect a client-side auction site.