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."
Re:Easier than Networking! (Score:2, Informative)
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.
Re:Easier than Networking! (Score:4, Informative)
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!
Re:How about a step simpler? (Score:2, Informative)
IBM said it best wrt scaling,at least for our specific requirements it did.
Re:Ugh (Score:3, Informative)
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.
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.
Have a look at SWILL (Score:3, Informative)
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.
Re:Easier than Networking! (Score:3, Informative)
Re:Ugh (Score:5, Informative)
Re:Easier than Networking! (Score:4, Informative)
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.
Re:What about PHP? (Score:4, Informative)
Need I go on?
Re:What about PHP? (Score:3, Informative)
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.