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 the web apps are taking over ... (Score:5, Interesting)
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.
And CGI still hasn't lost its edge totally. There are places when you *have* to use CGI to do what you want. I ran into one case when I couldn't use php when I wanted to server pushes [dotgnu.info] on a live connection. Instead of firing multiple requests to the server, I hold the connection and push data when it comes available - sort of stateful connections reinvented for HTTP. Which has definite promise when you're building mashups, which fetch data from elsewhere without cross-user leakage (heh, if he can hijack TCP, I don't know what...) - flockr [dotgnu.info] for instance uses such a script in the backend to feed it data (except I'll be an idiot to post a live CGI script to slashdot).
CGI ain't quite dead yet ...
Re:The Screen is The Interface (Score:2, Interesting)
GUI = Graphical User Interface
Lynx = Text based web browser
You were saying... ?
Re:perl? (Score:4, Interesting)
perl CGI, however, is crap as you said
Re:Easier than Networking! (Score:4, Interesting)
What's funny though is that the example in the article was neither networked nor multiuser. Why not skip the CGI part even and just have commandline scripts to do certain things? I can't say I've ever really consider writing a simple, single-user one-off GUI application. Nor can I think of a time where I'd want a personal web server listening on a local IP/port.
No, developers think in program design. *Programmers* things in program logic.
But if it doesn't do a or b (as in the article), Perl/Tk is probably simpler than even bothering with a web server. That is assuming that a GUI is even important at all.
-matthew
Re:Easier than Networking! (Score:3, Interesting)
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.
It's not as simple as you made it seem.
Re:The Screen is The Interface (Score:3, Interesting)
If it is only a few lines, it probably isn't 'pretty.' It is probably just a plain, small form centered in an oversized browser window. Personally I find things like PerlTk to be much "prettier" if only because the window is taylored to the app. And also the box model of Tk is MUCH easier to work with than HTML/CSS. I find reliably placing elements on the screen with HTML/CSS to be a huge pain in the ass.... and I'm primarily a web developer!
-matthew
Proof-of-concept & fast-prototyping (Score:2, Interesting)
What about PHP? (Score:1, Interesting)
Re:Easier than Networking! (Score:1, Interesting)
So we have slow, bloated, IE6-only web apps. Hey, its easy to deploy. Has the users cursing non-stop and wanting us dead. But its easy to deploy!
So you're expressing a preference for non-web apps based on the fact that the people who wrote your company's web app are incompetent? What the hell makes you think they'd have done a better job with whatever other toolkit they used, especially keeping in mind that both of those you mentioned would simply give them vastly more opportunity to seriously screw things up?
If you've never used a properly designed and written web app (and from the tone of your comment, I'd guess not) you have no idea just how well they can work. Not everybody loves using them, but my experience with replacing non-web internal apps with web-based ones has been that the majority of people much prefer the web-based app. And if the developers of the software are clueless... well, no toolkit in the world is going to save them.
Re:SCRIPT? Do it in C++! (Score:2, Interesting)
If you're going C++ for performance reasons, take a look at tntnet [tntnet.org]. It's a web application framework in C++, and provides sessions, thread-safe operations, and things like database connection pooling. You can even create web pages with C++ embedded right in, similar to e.g. PHP or ASP. And it's fast.
Re:Preach it, brutha (Score:4, Interesting)
Remember, if you have a feature that people can't figure out how to use, for all practical purposes that feature does not exist.
If you want to make X popular, first of all give it a decent name. Secondly, write an extension to Firefox so that a specially-tagged HTML page can call an X application over the Internet to run it. Add in all the bells and whistles I described in the grandparent post, and bam, you have a winner... assuming you can make it work without requiring gobs of Linux knowledge like it does now. Now when I visit Gmail, Google can put up a highly interactive email client which lets me drag&drop a file into the email window to add an attachment, and I'm happier and Google's happier and Firefox has a huge selling point.
From what I understand, though, X isn't suited for this for a couple reasons:
1) It's designed to run an entire desktop over the network link, not just one single application. i.e. you define a rectangle as "the desktop" and all windows/etc that X opened would have to be contained in it... that's not ideal.
2) It's bandwidth-heavy. Maybe not when competing with Citrix, but if Google started using it they would see their bandwidth bill skyrocket.
3) X doesn't solve the problem of native widgets. X applications run in OS X look like crap because the widgets are simple greyscale things that look like they were rejected from Windows 95, and not the nice-looking OS X buttons and widgets. Additionally, X applications in OS X still can't accept drag&drop, or use the OS X spell checker, or communicate with other apps, etc etc.
If it's going to happen, I think a new protocol needs to come forth. Perhaps something that transmits VB-like "forms" to the client on demand, and the "forms" can contain scripting in Python to accomplish the task, with a network protocol to stream-in new "forms" as needed and to interface with a remote ODBC connection through this psuedo-app. You could design the "forms" to take up minimal bandwidth and use native widgets by giving instructions like "draw a pushbutton with a label 'hello' at this coords" instead of sending bitmaps (like X does.) You'd also be able to script a form to modify itself to some extent, so you wouldn't need to make a round-trip to the server every time you hit a disclosure triangle.
If anybody builds this, put my name in the credits.