Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Programming IT Technology

When a CGI Script is the Most Elegant Solution 256

Posted by CmdrTaco
from the the-answers-is-always dept.
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."
This discussion has been archived. No new comments can be posted.

When a CGI Script is the Most Elegant Solution

Comments Filter:
  • by Anonymous Coward on Sunday March 04, 2007 @11:56AM (#18227236)
    When everything else is not.
    • by caluml (551744)
      If "everything else" comprises of more than 1 element, then it will never equal "the most elegant solution", as the title "most elegant" can only be applied to one thing.

      if ( count($everything_else) > 1 )
      {
      die("Not the most elegant solution");
      }
      Meh. I'm so l33t.
  • by MattPat (852615) <MattPat@maEULERttpat.net minus math_god> on Sunday March 04, 2007 @12:02PM (#18227288) Homepage

    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.

    • Re: (Score:2, Informative)

      by AmazingRuss (555076)
      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 bro
      • by MattPat (852615) <MattPat@maEULERttpat.net minus math_god> on Sunday March 04, 2007 @12:24PM (#18227466) Homepage

        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.

        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. ;)

        • by AmazingRuss (555076) on Sunday March 04, 2007 @01:03PM (#18227836)
          "unless I use a particularly fancy bit of JavaScript, they almost always functionally work the same in multiple browsers. "

          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!
          • by plams (744927) on Sunday March 04, 2007 @04:16PM (#18229470) Homepage
            "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.

        • by nuzak (959558)
          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?

          Perhaps the Javascript they write is, I dunno, particularly fancy? Once you handle events, for example, in your code beyond onClick and onMouseOver, you find they need to be handled differently. And a site that's "effed up" in IE isn't actually acceptable to most web dev
        • Re: (Score:3, Interesting)

          by Bozzio (183974)
          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 bas
          • Re: (Score:3, Informative)

            by Dragonslicer (991472)
            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.
            • by nuzak (959558)
              Then the browser should decide the policy, much like it does with window.open(). Failing to support it at all is simple laziness at everyone else's expense.

              That said, onunload isn't anything you can rely on for running cleanup -- it certainly doesn't run when the user closes their browser entirely.

            • by Bozzio (183974)
              Yes, it is a source of advertisement nuisances, BUT, onunload can be used for MUCH more. I've been asked to develop application (Web Applications specifically) for use on intranets and MANY of these applications require a pop-window to validate information (or modify parent window forms). I can't rely that everybody here (especially management!) is smart enough to click on "update" or "submit," so I have to have the updated values submitted on unload. Works like a CHARM in all browsers but Opera. In Ope
        • by Tim Browse (9263)

          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?

          Well, I only skimmed the article, but:

          You can use image buttons for many purposes, although they do require you to develop images. If you want to bypass this, create an image button with alt text and an invalid URL for its image

          So yes, perhaps they are.

      • by didde (685567) * on Sunday March 04, 2007 @01:18PM (#18227966) Homepage
        First of all, distributing a link seems like a smaller obstacle than distributing an executable file of some sort... A simple office text/plain e-mail would suffice.

        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.
        • Well, if learning a high level language is such a barrier, you should definately stick with your scripting language....but I don't see how you can make an accurate comparison between the two methods if you have only ever used one.

          And always I hear about the "ease of deployment". Deployment happens ONCE per client...while the application will be used thousands of times. Even if it were significantly harder to get an exe onto a machine, it is insignificant effort over the lifecycle of the app.

          When I first l
        • Re: (Score:3, Insightful)

          by ShaunC (203807) *

          I'd also considering using inline CSS and JavaScript instead of linking them in externally as files. Surely this will reduce the network load.

          Actually, the opposite should be true. Client browsers will typically[1] cache the contents of an external .css file, downloading it no more frequently than once per visit (the same holds true for .js files). If you're inlining your CSS or Javascript as part of your pages, the client has to download a copy each and every time they load a new page on your site. Granted

      • Graphics can be cached, as can JavaScript using a .js file. So can CSS, which means all you need to send is the page content.

        Browser testing I agree on, but it's getting better and only really tends to flare up if you're doing something huge with AJAX. For the apps the article is on about (Rought and ready) then browsers can deal with it pretty well.
      • by Fastolfe (1470)
        You only have to distribute a link once and can upgrade/patch to your heart's content without having to worry about re-testing an upgrade/installation process for your user base.

        I do agree that the decision to go with a web app should be made based on the requirements of the project. Use the best tool for the task. Sometimes that can be a web app, but sometimes it should be something else.
        • That very link could be to your installer package....and you could build automatic updating into your app. I push update binaries out via a simple SQL query.

      • by Ash Vince (602485)
        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.

        Nah, it pains me to say but most of the time that is a load of rubbish. You just make sure your app works in IE6 and that covers it.

        I would love to develop more cross browser stuff, but I am never allowed to spend too much time on it. I also work on projects as a part of a team so
        • ...rebuttals is "most of the time" and "with the following restrictions" and "if I target only IE6".

          Which basically means you are tied to a given platform...so cross platform compatibility is out the window. I would argue compatibility with any platform is out the window with those restrictions, given the recent forced IE7 upgrade. Even something as simple as users twiddling their browser setting can break your app.

          "Most of the time" and "we think it should work" aren't phrases you want to hear from someo
          • by Ash Vince (602485)
            Care to explain that to the people who pay my wages? And yes, IE7 was a complete pain the arse for us but it hasn't helped.
    • by Shados (741919) on Sunday March 04, 2007 @12:25PM (#18227484)
      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!
    • I think it's a good idea, and it's easier to manage the software for multiple platforms because web pages can be made platform agnostic.
    • by skoaldipper (752281) <skoalstr8 AT gmail DOT com> on Sunday March 04, 2007 @12:35PM (#18227586)
      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.
    • by misleb (129952) on Sunday March 04, 2007 @01:16PM (#18227940)

      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.


      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.

      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.


      No, developers think in program design. *Programmers* things in program logic. :-)

      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.


      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

       
      • by XO (250276)
        I built the entire POS system for my gf's business over the course of about 4 hours, in PHP. It works great. :)
  • by LS (57954) on Sunday March 04, 2007 @12:03PM (#18227296) Homepage
    Why not just use the command line? I didn't see anything in this article that would exclude its usage...
    • Why not just use the command line? I didn't see anything in this article that would exclude its usage.

      An example he cites but does not provide, is a photo browser. You could use a combination of image magic and curses to do the same thing, but cli input could be tedious for more than simple viewing and the author's approach could save effort.

      I'm doing a lot of cli image manipulation and I'm interested in this technique. I've got an ugly imaging device and a pile of c code to interpret it's output a

      • by XO (250276)
        Also don't forget that probably upwards of 90% of computer users are incapable of operating a command line.
    • Re: (Score:2, Informative)

      by skoaldipper (752281)

      Why not just use the command line? I didn't see anything in this article that would exclude its usage...

      There's nothing necessarily wrong with that approach. However, as a practical example, I worked for Insurance companies and we developed software initially using nothing but DOS. However, even for simple form processing, it was quite a task (especially when each vendor had their own specific designs for their property and casualty policies). Just to rearange those items even from a given template (or u

  • Ugh (Score:4, Insightful)

    by Blakey Rat (99501) on Sunday March 04, 2007 @12:07PM (#18227320)
    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. 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.
    • Re:Ugh (Score:5, Insightful)

      by beavis88 (25983) on Sunday March 04, 2007 @12:19PM (#18227422)
      None of those are problems with web apps, they're problems with the decisions the companies made in developing said web apps.
      • Re: (Score:3, Insightful)

        by Blakey Rat (99501)
        Even if you have the best web-app in the universe, it still can't accept drag&drop files from the desktop, nor can it safely open multiple windows, nor can it interact with any other application on the system (i.e. by using AppleScript on Mac for example), nor can it use any OS widget other than the most basic few, it'll never be as responsive as a desktop app, and will never have any of the graphical capabilities of a desktop app.

        If you think back, way back when Windows 95 was out people were making th
        • Re: (Score:3, Insightful)

          by Shados (741919)

          nor can it safely open multiple windows

          Oh, it can. Maybe not for "real", but there are toolkits that build entire "windows managers" in javascript. Works amazingly well.

          and will never have any of the graphical capabilities of a desktop app

          Now that depends where we stop the line of "web app". If we count it as HTML/CSS/Javascript/Whathaveyou, you're right. But there are things coming out to bridge the gap. For example, WPF/XAML, which is fairly amazing, though nothing a slashdotter would be interested in

          • by misleb (129952)

            Oh, it can. Maybe not for "real", but there are toolkits that build entire "windows managers" in javascript. Works amazingly well.

            People say things like that as if they'd never actually run a native desktop application with a real window manager before. I've used a couple of the "window manager" type browser toolkits, and there is nothing "amazing" about them other than the fact that someone was able to push Javascript and HTML so far beyond their reasonable limits. The only decent browser based, desktop

        • Re:Ugh (Score:5, Informative)

          by pjt33 (739471) on Sunday March 04, 2007 @02:32PM (#18228578)

          The only solution is to write a new internet protocol (not HTTP) designed specifically to run apps from a server...
          You mean like X?
        • Even if you have the best web-app in the universe, it still can't accept drag&drop files from the desktop,

          Not true. There are drag-and-drop Javascript controls for the usual platforms, though I don't know of any that are platform-independent. I've used them on Windows and Linux and they work.

          nor can it safely open multiple windows,

          I'm guessing as to what you mean by "safely" in this context, but it's possible (and I've done it) to open multiple windows, and to then maintain state in such a way that

        • Even if you have the best web-app in the universe, it still can't accept drag&drop files from the desktop, nor can it safely open multiple windows, nor can it interact with any other application on the system (i.e. by using AppleScript on Mac for example), nor can it use any OS widget other than the most basic few...

          None of which most general users care about. Drag 'n drop? I've dealt with very smart people who were completely amazed when I grabbed some cells from Excel and dragged them into Word.

      • by misleb (129952)

        None of those are problems with web apps, they're problems with the decisions the companies made in developing said web apps.


        Seriously, the same company that locks you into a specific version of IE would probably just lock you into a specific version of .NET. The end result would be the same. you need to be running Windows with a specific version of the VM (be it IE or .NET).

        -matthew
    • by heroofhyr (777687)
      Siemens' image database [siemens.com] is a nightmare. I just order components through catalogues now rather than try to swim through what they call a web-application. You didn't make that, did you? By the way, this probably shouldn't happen when someone types in random shit out of frustration that the site has frames but reloads the entire page every click regardless:

      Microsoft OLE DB Provider for SQL Server error '80040e14'

      Line 1: Incorrect syntax near '('.

      /bilddb/content.asp, line 341

      Passing chars for numbers in the GET variable nodeID returns an error like "nvchar cannot be converted to an int." Shouldn't the script be handling tho

    • Re: (Score:3, Informative)

      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.

      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

    • I'd also like to mention the often b0rken back button and refresh button. It's so frustrating that half the web-apps out there don't support those.

      In the (new!---2 months old) timesheet program we use at wr0k, both of those are b0rken (and there's no capability of printing out your timesheet except to print the whole page).

      (note, this is at a -HUGE- corp that spent millions developing this web-app; not something that was coded by a high school student on their own time---or maybe it was!)

      I generally find we
      • by rucs_hack (784150)
        "(note, this is at a -HUGE- corp that spent millions developing this web-app; not something that was coded by a high school student on their own time---or maybe it was!)"

        Given the unbeleivably poor quality of most code sold to companies that I've seen, I am not surprised that they would buy crap. The first time I saw the source to an app that sold for thousands I was pretty stunned how bad it was.

        Thing is, what they are buying is often not the program as such, but the accountability. If it were just the cod
  • by Gopal.V (532678) on Sunday March 04, 2007 @12:14PM (#18227394) Homepage Journal

    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 ...

  • Another issue (Score:5, Insightful)

    by fyngyrz (762201) * on Sunday March 04, 2007 @12:15PM (#18227398) Homepage Journal

    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. :)

    • by istartedi (132515)

      The first thing I think when I run into a morass of Java, etc., is "incompetent." But that's just me. :)

      Well, of course it's not just you. It's amazing how close some "professional" pages come to being Homer Simpson's web page.

    • by XO (250276)
      Perhaps it's time you upgraded the 486 to something a little more reasonable with today's computing needs?

      What the Hell are you talking about? I just flipped through digg, and there's no indication whatsoever of what you were talking about in it.

      Java, PDF, and Flash support depend on the environment just as much as your browser does ..

  • by vtcodger (957785) on Sunday March 04, 2007 @12:26PM (#18227506)
    The article isn't exactly wrong, but ...

    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: (Score:2, Insightful)

      by Anonymous Coward

      First of all, writing a simple GUI application using say Python and TKinter is probably easier than writing a web application.

      Think about scaling that GUI to multiple vendors with countless permutations on GUI requirements. Web apps are far more easier to maintain and implement.

      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.

      Tables? Frame containers? Fixed width browser

  • by SEWilco (27983) on Sunday March 04, 2007 @12:29PM (#18227536) Journal
    A web browser is a GUI.

    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: (Score:2, Interesting)

      by dvice_null (981029)
      > A web browser is a GUI.

      GUI = Graphical User Interface
      Lynx = Text based web browser

      You were saying... ?
    • Re: (Score:3, Interesting)

      by misleb (129952)

      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.

      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

  • by Anonymous Coward on Sunday March 04, 2007 @12:56PM (#18227778)
    I don't understand either the problem space, or the solution. I've read the article twice -- though it is apparent by most of the comments that people have not read the article.

    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.

  • by Junta (36770) on Sunday March 04, 2007 @01:16PM (#18227942)
    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.

    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.

    • by pavera (320634)
      In his defense he specifically mentions writing *SIMPLE* applications this way. I've written quite a few one off perl and php CGI "applications" that are a simple 1 or 2 web pages to do something very simple. One such "app" is for turning on and off the "answering" machine in Asterisk (IE the office is closed outside of their normal open/closed hours and the receptionist needs to make all calls go to voicemail).

      If I wrote this application as a thick client GUI app, it would have taken at least 30-40 hours
      • by Junta (36770)
        Your general description (a quick remote access thing for something) falls very much in the category of what a webapp would work well for, remote resource management for untrained personnel, ubiquitously available.

        I will say your GUI app development time is exagerrated (GUI app, ok, not that big a deal, but an xml-rpc daemon to handle on/off? Just because xml-rpc is a buzzword doesn't mean you have to use it for every little thing, a daemon to this thing would be easy. Querying a database? Why in the wo
    • by ArmorFiend (151674) on Sunday March 04, 2007 @04:18PM (#18229486) Homepage Journal
      Web apps are the way to go for a lot of things.

      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?
      • 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.

        Unless, that is, you have a CGI script generating the form dynamically. Something that you need to do if you want form fields to persist.

        Just because HTML is separate from CGI doesn't mean that CGI didn't generate the HTML for the form.
        • I guess so, though I usually just have the program copy a ".html" file, or html fragments stored in files.

          Actually, for a fair number of programs I output "content-type: text/plain". Might as well be command-line, I know. Some people hate command-line.
  • I wrote a little Ruby on Rails app that does nothing more than help me record and calculate my fuel mileage. It took me about 20 minutes start to finish and it's exactly what I needed. Doing the same thing on a spreadsheet would have taken me the same amount of time, but now I can expand it in the future to let me send text messages to it to record mileage when I'm out and about.

  • by kahei (466208) on Sunday March 04, 2007 @01:23PM (#18228002) Homepage
    And then users say, and they're right to say this:

    "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.

    • by Anonymous Coward on Sunday March 04, 2007 @02:06PM (#18228378)
      ...and then you would be right to say,

      if (you == inHouseProgrammer)

      "Well you cocksuckers should have told me all this shit up front so I didn't waste my weekend writing a useless web app. If you want it fixed, do it yourself"

      else if (you == consultant && you == chargingTimeAndMaterials)

      "I'll be happy to add those new requirements for you, but I'm afraid that's going to impact the schedule."

      else if (you == consultant && you == chargingFixedFee)

      "Thanks for the feedback, bit I'm afraid we will have to address those new requirements in a follow-on contract."

    • by plopez (54068)
      "Looks like YOU have a problem!"

      And the correct reply to that is "How much money do you want to spen and how much time do you want to spend?"
  • It can work (Score:2, Insightful)

    by skroll82 (935998)
    I work for a company who uses almost exclusively web apps inside the company. It works because having a small programming staff means it would be hard to constantly troubleshoot every user's machine. Lets face it, the average user is usually clueless on to how a new application will work, and putting it into a web page means that it's fairly simple for them to pick up. None of the apps use Java or anything besides CSS and HTML, and while CSS can be a bit finicky on different browsers, it's at least still
  • Have a look at SWILL (Score:3, Informative)

    by Diomidis Spinellis (661697) on Sunday March 04, 2007 @01:30PM (#18228064) Homepage
    If you plan to expose your application's GUI through a web browser, have a look at SWILL [sourceforge.net], 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.

  • 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 billio
  • The same arguments can be used for command line apps. Just get rid of the GUI completely. Seriously. If you don't need a GUI, then use a freaking command line tool. But if you DO need a GUI, then use a GUI! A webapp is only going to subject the user to a nasty user interface.
  • I see a hundred posts here flaming the guy because "You can't write an enterprise realtime xyz app in a browser". Luckily that isn't at all what he recommended or said in his article. He stated quite clearly that in certain limited cases, when users need xyz FEATURE (not necessarily a whole app) it is easier, faster, and less error prone to throw up a quick CGI script to do the job.

    I've done this tons of times for clients that just want a feature, not an app. Maybe 1-3 forms with a database backend and a
  • At least, not most of the time. I don't want to have to learn several different toolkits in order to make the program work OK on several different platforms. So a nice CGI fits the bill.

    And in Python, it doesn't really matter that I don't have a web server running. I just use the pure Python web-server that ships as part of Python's standard library. It's not really up to a load of more than a few requests per second, but if things ever get that busy it should be easy to convince someone to give me the

Old programmers never die, they just branch to a new address.

Working...