Slashdot Mirror
When a CGI Script is the Most Elegant Solution
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."
I don't buy the distribution thing...you have to distribute a link, and you could just as easily distribute a small downloader/installer, and build an auto updater into the app. With a web app, you also download your code with every single page. Graphics. HTML. Javascript. Every single time.
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.
If you have a simple form/submit application, or you don't control the workstations you will be deploying the app on, then a web app makes sense. Otherwise, a high level language running directly against an SQL server is the way to go. It's no harder than writing a web app, and you get much better response time and control.
things like Java Web Start or .NET's ClickOnce solve the distribution issue. The advantages of the web are more lightweight UIs, easier to distribute to -third partys-, and better cross platform compatibility (even compared to Java). Easier update and maintenance, not so much.
Im working for an (extremely large) company that decided on web apps for the deployement thing alone, without needing (or -wanting-) any of the other advantages. 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!
IBM said it best wrt scaling,at least for our specific requirements it did.
I hope, when they die, cartoon characters have to answer for their sins.
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. A few points:
1) These are not rules, these are your own biases.
2) I share bias #2.
3) We're talking specifically about intranet apps here. In an intelligently-managed workplace, having to customize the client shouldn't be particularly onerous (it's not like the IT folks should have to walk to each computer and do everything by hand anymore, if you're managing things correctly). The particular modified settings you list should be no-nos, in my opinion. But, say, requiring JavaScript should not be considered problematic (that does NOT, of course, require client modification; I mention it because of some
A big part of my job is writing custom web apps whose target audience is just my department's coworkers (or, occasionally, members of the wider university community). In most cases, it's being done to replace an existing paper-based system. In addition to a shorter development period, another advantage to web apps is that almost everyone nowadays is familiar with the web interface. Additionally, if done correctly you remove any OS lock-in. I develop and test for Firefox on my Mac; but many/most of my co-workers are running Windows (and usually Internet Explorer) - THAT'S an advantage writing a full-blown GUI app almost never has.
#DeleteChrome
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.
I'm gonna have to agree with Opera on this one. onunload is the source of annoying pages and advertisements that can only be closed by killing your browser process.
"But which bits of java script are fancy and which are not?"
This is actually quite easy. Stuff that relates to the DOM often differ from browser to browser while the core language does not. This is somewhat similar to the fact that you can compile and link ANSI-compliant C on virtually any platform as long as you don't do anything platform specific.
At work I recently developed a JavaScript framework for calculating text length that had to take variable character widths and hyphenation into account. The idea is that the user can type away in a standard TEXTAREA field and know when some predefined text area in a PDF document is full. I think the code ended up as 500+ lines of JavaScript code, but the ONLY browser specific problem I ran into was a subtle difference in the parsing of arrays; Firefox would treat the statement [1,2,3,4,] as an array with the length of 4, while Internet Explorer would say the length was instead 5 (and the last value was "undefined", if I recall). I gather that the reason why browser independence came so painlessly was that 95% of the code was just text processing and number crunching anyway. I doubt I'd have the same luck if I tried to do a WYSIWYG editor since it would have a great more interaction with the DOM.
As another user stated, CGI is a specification. One that PHP uses if it's compiled as a CGI binary or emulates if it's installed as a web server module. $_SERVER, for instance, is populated mostly with CGI Environment variables. $_GET is a processed version of the CGI QUERY_STRING variable. $_COOKIE is a processed version of the the CGI $COOKIE (and possibly $COOKIE2) variables. The $_FILES array is filled with the parts of a multipart/form-data input that have a filename= section. This comes from a POSTed form (which uses STDIN as per the HTML and CGI specs).
Need I go on?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Many servers do not have CGI
Why would a server NOT have CGI? Unless what you really mean is the developer doesn't have CGI access on the server. I'm not sure you're understanding what CGI is. It is NOT perl. It is NOT PHP. Although both can be used. My cgi-bin is full of custom EXEs.
In simple terms, here is how CGI works; dynamic information from the client is passed to a process launched by the web server through environment variables and command line. An application runs natively on the machine, such as a script processor like perl/PHP or any appropriately written executable. The output of the application is sent to stdout and that is redirected to the client.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman