Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

When a CGI Script is the Most Elegant Solution

CmdrTaco posted more than 7 years ago | from the the-answers-is-always dept.

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

Sorry! There are no comments related to the filter you selected.

When is a CGI script the most elegant solution? (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18227236)

When everything else is not.

Re:When is a CGI script the most elegant solution? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18227594)

lol i luv to rubi on rayls too perhaps we cn meet and rub our greasy cocks together???!!

eat poo (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18227240)

cgibin is poo on you

Hey seebs! (-1, Offtopic)

greg_barton (5551) | more than 7 years ago | (#18227264)

I hope you're wearing shoes in the winter these days. :P

Fram, fram, and all that...

descover? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18227276)

I mean seriously, descover? Aren't the editors paid around here?

Re:descover? (1)

Goaway (82658) | more than 7 years ago | (#18227358)

The "editors" do not "edit" articles. This make Slashdot "more real", according to CmdrTaco.

Re:descover? (0)

Anonymous Coward | more than 7 years ago | (#18227448)

The "editors" do not "edit" articles.

Ok, then...

from the the-answers-is-always dept.

Answers is?

Re:descover? (1)

Goaway (82658) | more than 7 years ago | (#18227472)

Maybe there is some kind of reason for them not editing, I dunno!

Re:descover? (1)

LiquidCoooled (634315) | more than 7 years ago | (#18227450)

Sorry, there must be an error in the script.
Taco had everyone replaced with very short scripts sometime in 1999.

The file cowboyneal.sh takes up 47.3 TB!

Re:descover? (-1, Offtopic)

Kamineko (851857) | more than 7 years ago | (#18227894)

I DESLIKE YOU! [n00bstories.com] :)

Re:descover? (4, Funny)

1u3hr (530656) | more than 7 years ago | (#18228080)

Their main function is to think of the "from the ... dept." line. Doing a spellcheck or other mundane editing tasks would distract them from that.

Re:descover? (0)

Anonymous Coward | more than 7 years ago | (#18228136)

Their main function is to think of the "from the ... dept." line. Doing a spellcheck or other mundane editing tasks would distract them from that.

...and yet they still screwed it up, and wrote "answers is".

Re:descover? (1)

ebuck (585470) | more than 7 years ago | (#18228156)

Perhaps it's the new all-covering encryption.

Easier than Networking! (5, Insightful)

MattPat (852615) | more than 7 years ago | (#18227288)

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.

I've been wondering... (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18227300)

Hey Slashdot, why are PC users such ugly dweebs [imageshack.us] in comparison to Mac users [imageshack.us] ? Is it because nobody has the time or patience to put up with Windows/Linux except for friendless, sexless nerds like you?

Re:I've been wondering... (0)

Anonymous Coward | more than 7 years ago | (#18227562)

I hate to feed the trolls, but you are seriously on-topic for this article: Look at the picture: Peter Seebach [ibm.com] : male? female? I don't know.

Re:Easier than Networking! (1, Informative)

AmazingRuss (555076) | more than 7 years ago | (#18227402)

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.

Re:Easier than Networking! (5, Insightful)

MattPat (852615) | more than 7 years ago | (#18227466)

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

Re:Easier than Networking! (4, Insightful)

AmazingRuss (555076) | more than 7 years ago | (#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!

Re:Easier than Networking! (1)

nuzak (959558) | more than 7 years ago | (#18227860)

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 developers who want to get paid. When you start creating boxes and moving them around with JS, that box model problem is magnified.

That said, cross-platform libraries exist that work across all major browsers, so indeed I've never sweated the difference.

Re:Easier than Networking! (3, Interesting)

Bozzio (183974) | more than 7 years ago | (#18228004)

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 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:Easier than Networking! (3, Informative)

Dragonslicer (991472) | more than 7 years ago | (#18228458)

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.

Re:Easier than Networking! (0)

Anonymous Coward | more than 7 years ago | (#18227816)

With a web app, you also download your code with every single page. Graphics. HTML. Javascript. Every single time.


Only if the user's browser has no cache or they have disabled it, or if you have disabled caching of the content server side and your application has absolutely zero static content.

Re:Easier than Networking! (3, Insightful)

didde (685567) | more than 7 years ago | (#18227966)

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.

Re:Easier than Networking! (1)

AmazingRuss (555076) | more than 7 years ago | (#18228154)

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 learned how to write web apps, I agreed with your arguments. Multiple projects later, I learned otherwise, the hard way. The modern browser is a hack of a hack of a hack of a hack...and your application ends up being the top hack on the hack stack. Sometimes you need to do it that way, but I think browser apps are over used because people won't take the time to learn to write a thin client app. It really isn't any more difficult, it just requires a bit of willingness to learn, and the results are far superior.

Re:Easier than Networking! (1)

jacksonj04 (800021) | more than 7 years ago | (#18228330)

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.

Re:Easier than Networking! (1)

Fastolfe (1470) | more than 7 years ago | (#18228402)

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.

Re:Easier than Networking! (3, Informative)

Shados (741919) | more than 7 years ago | (#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!

Re:Easier than Networking! (0)

achacha (139424) | more than 7 years ago | (#18227952)

We have run into a lot of problems with WebStart (haven't tried NET yet so don't know). But versions are a big problem with java, something that works on jre 1.4 may not work on jre 1.5 and to code for jre 1.3.1 just to be compatible is often limiting. This doesn't even address the issues of a problems in 1.4.6 (for example) that do not occur in 1.4.7 and you may need to avoid or write your own way to doing it to avoid this. .NET got the version handling down much better, so I would be interested in seeing it work.

Re:Easier than Networking! (1)

Shados (741919) | more than 7 years ago | (#18228236)

Well, the main thing with .NET is that its sent through windows update, and you can very easily push it through a windows domain (you can push anything mind you, but its obviously a lot easier to push windows components). Its also a big part of SQL Server's Reporting Services (the user end tools are pushed with ClickOnce), so you know there's a relatively large user base testing it. It "just works".

Re:Easier than Networking! (1)

Jeff DeMaagd (2015) | more than 7 years ago | (#18227584)

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.

Re:Easier than Networking! (4, Insightful)

skoaldipper (752281) | more than 7 years ago | (#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.

Easier than ASP! (0)

Anonymous Coward | more than 7 years ago | (#18227846)

The advantages of the thin-client:server paradigm without going all the way. ASP-lite as it were.

Re:Easier than Networking! (3, Interesting)

misleb (129952) | more than 7 years ago | (#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

 

Re:Easier than Networking! (1)

mini me (132455) | more than 7 years ago | (#18227950)

I say, it's a good way to do things.

I'm a firm believer in doing it the other way around. The GUI design should drive the application's design - the application's design should not drive the GUI design. Not only is it easier building the application around the GUI, the results are almost always better, in my experience at least.

Re:Easier than Networking! (1)

MattPat (852615) | more than 7 years ago | (#18228044)

I see what you're saying, it seems to be the Mac way of development (I'm a Mac developer, that wasn't an insult :P). I was just thinking, while for consumer apps that's best, if you're in need of a very quick application to do a job, user interface might be willing to take a back seat.

How about a step simpler? (2, Insightful)

LS (57954) | more than 7 years ago | (#18227296)

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

photo example (1)

twitter (104583) | more than 7 years ago | (#18227752)

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 and make images of it. Having some simple feedback would be nice. It would be even nicer if I could serve that output to others in my group in a platform independent way.

Re:How about a step simpler? (2, Informative)

skoaldipper (752281) | more than 7 years ago | (#18227856)

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 using a suite of library tools like curses) it was an ordeal at times fitting (for example) UMBI (Uninsured Motorist Bodily Injury) with UMPD (...Property Damage) across a FIXED 80 column screen. And some companies would insist it be that way. It was like squeezing a small child out of a birth canal at times. Even when migrating to a full blown OO GUI, the design requirements and scope was not all that much different (or resource conserving).

IBM said it best wrt scaling,

When you add in the possibility of needing to rework the application for a larger (plural!) audience, it pays off even more.
at least for our specific requirements it did.

Does anyone know... (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18227310)

WTF is up with all the IBM Developer Works for dummies articles recently?

Many of us have probably found useful stuff there in the past but the recent articles are just useless - even for beginners.

Ugh (3, Insightful)

Blakey Rat (99501) | more than 7 years ago | (#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 (4, Insightful)

beavis88 (25983) | more than 7 years ago | (#18227422)

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

Re:Ugh (2, Insightful)

Blakey Rat (99501) | more than 7 years ago | (#18227528)

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

Re:Ugh (2, Insightful)

Shados (741919) | more than 7 years ago | (#18227780)

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 for obvious reasons. I'm sure there are cross platform equivalents in the work or already out.

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:Ugh (1)

misleb (129952) | more than 7 years ago | (#18228336)

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-like GUIs i've ever used are done in Flash. And, well, you might as well just write Java applets at that point.

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 for obvious reasons. I'm sure there are cross platform equivalents in the work or already out.


Unfortunately, cross-platform in browsers means "lowest common denominator" which means "slow and clunky Javascript/HTML." Even outside of browsers, cross-platform usually means Java which, well, sucks on the desktop IMO. Generally speaking, there is no shortage of native applicaitons on my platform of choice (OS X), so i don't really care about the next browser based fad. Go ahead and write an image manipulation tool inside a browser if you think that is cool, it'll never be as good as Photoshop or even Gimp.

-matthew

Re:Ugh (0)

Anonymous Coward | more than 7 years ago | (#18228348)

Can these toolkits allow me to select a different windows from the taskbar, or using expose, or allow me to alt-tab to them?

Re:Ugh (1)

skoaldipper (752281) | more than 7 years ago | (#18227936)

There are a lot of reasons that web-apps suck, I was just barely scratching the surface.
This is not the focus of the article. The article's focus is "when to use" (the very top title) and...

Applications that are built around forms or data manipulation are often excellent candidates for implementation as a trivial Web service.
Using javascript for form processing and database access applications is over engineering. Everything the article cites is all you need. Of course, the article itself is over simplistic and pretty much restating the obvious (for these _specific_ client requirements).

Re:Ugh (1)

frizop (831236) | more than 7 years ago | (#18228298)

it still can't accept drag&drop files from the desktop,
Am I missing something about this? I've seen drag and drop java applets. Also it looks like some of the newer versions of FF are working on getting things like offline gmail. I think web apps are the future, there easy to prototype and some of the frameworks out there today give you just about as much control as a real native app with about the same speed. As long as you're not looking for some sort of 3d engine in a browser, there king of data entry and searching.

Re:Ugh (1)

Dan667 (564390) | more than 7 years ago | (#18227926)

I would have to agree. Anyone designing a web app with client side java should be slapped with a wet noodle. When ever I run into these applications and I am installing whatever version I need to get it to work I always wonder what they were thinking. Just bad decision making to do things like that. If all that complexity is kept on the server, extremely complex web apps can be written and the end user does not have to troubleshoot the application.

Re:Ugh (1)

misleb (129952) | more than 7 years ago | (#18228164)

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

Re:Ugh (1)

ShivanDragon (709754) | more than 7 years ago | (#18227492)

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.

I agree how Lotus Notes is terrible in converting stuff to the web, But I don't really care. It's perfectly possible to make a good webapp, fast in notes, except for the Rich Text rendering which is terribly annoying :P

look at what people at www.codestore.net or www.openntf.org can do...

Re:Ugh (1)

heroofhyr (777687) | more than 7 years ago | (#18227902)

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 those kind of errors instead of trusting Microsoft to do it properly? I can't imagine a huge company like Siemens is printing errors you'd expect to see in some guy's undergrad homework slash PHP messageboard software.

Re:Ugh (2, Informative)

93 Escort Wagon (326346) | more than 7 years ago | (#18227912)

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 problematic (that does NOT, of course, require client modification; I mention it because of some /.'ers biases against anything that won't run on Lynx or Netscape 1.0)

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.

Re:Ugh (1)

Prof.Phreak (584152) | more than 7 years ago | (#18227946)

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 web-apps to be great, but they -do- have to be properly designed. A good design test: if it works in Netscape 3, then it will work for all past/future browsers.

Re:Ugh (1)

rucs_hack (784150) | more than 7 years ago | (#18228406)

"(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 code then most people would go open source for their needs. Nope, they want to have someone they are paying who can come and fix it.

Yup, this is also available via open source from some places, but there is a huge marketting monster that tries to stand between companies and these alternatives.

Re:Ugh (0)

Anonymous Coward | more than 7 years ago | (#18227980)

You seem to have missed the point.

1. Why have Java when you have the browser and the server? Have the server do the stuff and the browser send to it. You're talking abouot a Java problem...not a CGI problem. The fact that your app was built on non-standard (m$) Java is not CGI's fault.
2. Coding to standards allows things to work in IE (most of the time). Again, you're bringing up Java. Stop using proprietary browser functionality and this won't be a problem.
3. Offtopic. What do popup blockers, especially disabled ones, have to do with CGI? What does a security setting being DISABLED do to prevent CGI? These are both arguing FOR CGI because any limitations you would have had (by coding stupidly) are now allowed.

Even if you had an argument before your example about your web-based ticketing system is specific. The author is talking generally. He is saying that coding an entire application in some full compiled (including to byte-code) language is not often needed if you are writing something quickly. Don't do it. Accept GET/POST variables and spit out text. How much simpler can it be? This also applies to command-line scripts. The command-line (windows excluded without cygwin) is extremely powerful and can do many repetitive tasks as quickly and securely as anything for you. Many of these are easily converted to web-based if needed for others on the Intranet (the logic's the hard part...porting is trivial).

Is spelling important for CGI? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18227336)

Discover correct spelling!

why not use Tk? (0)

Anonymous Coward | more than 7 years ago | (#18227338)

In the author scenario, you are developing GUI utility apps for your own machine and don't plan to allow network access (there are lots of security risks with hosting a web server on a desktop machine, but most of them probably go away if you disallow external connections as the author suggests). Wouldn't it be more straightforward to write the thing in Perl/Tk or similar instead of hassling with transferring state over multiple HTTP requests?

SCRIPT? Do it in C++! (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18227346)

Erm why use a script, there are plenty of text parsing code around in C++, or it's trivial to write your own and you can do a lot more in C++ than PERL.

I wrote a whole search engine with nothing but C++, the GCC compiler and a CGI wrapper on Apache. It was a doddle!

For those of you who don't know, a CGI in Apache (minus any special persistence) is a simple executable that receives it's input in stdin stream as formatted text, and writes it's HTML (or JPEG or whatever) result to stdout. When writing the output, it appends a few extra lines at the start to tell Apache if the result is HTML, JPEG, text or a page redirect or whatever.

Re:SCRIPT? Do it in C++! (1)

eneville (745111) | more than 7 years ago | (#18227548)

...
For those of you who don't know, a CGI in Apache (minus any special persistence) is a simple executable that receives it's input in stdin stream as formatted text, and writes it's HTML (or JPEG or whatever) result to stdout. When writing the output, it appends a few extra lines at the start to tell Apache if the result is HTML, JPEG, text or a page redirect or whatever.
That would be the "Content-Type: text/html\r\n\r\n" output yes. CGI isn't always going to be faster than using a framework. sometimes the framework can achieve better results simply by providing memory resident information. Establishing a DB connection many times in CGI can cause pages to perform worse than using a connection pool provided by a framework.

Re:SCRIPT? Do it in C++! (1)

MemoryDragon (544441) | more than 7 years ago | (#18227812)

I would even to so far that cgi in most cases is way slower, it does not provide advanced caching algorithms for dynamic content, no connection pooling, it relies on a process per request while most app servers rely on a thread per request model etc... there is almost no reason at all to use cgi.

Re:SCRIPT? Do it in C++! (0)

Anonymous Coward | more than 7 years ago | (#18228030)

"I would even to so far that cgi in most cases is way slower, it does not provide advanced caching algorithms for dynamic content, no connection pooling, it relies on a process per request while most app servers rely on a thread per request model etc... there is almost no reason at all to use cgi."

Clean, efficient, small, simple, stable, not restricted to database hence no need to connect to database, hence no need to use connection pool to fix up DB connect problem, hence no need for extra complexity, processes more secure, can be killed separately and independent of one another, all OS caching still works.

There's a lot to be said from bypassing the framework and since it's very trivial to do so, the first question any programmer should ask is if they actually gain anything from the framework.

I didn't mention a DB (0)

Anonymous Coward | more than 7 years ago | (#18227850)

"Establishing a DB connection many times in CGI can cause pages to perform worse than using a connection pool provided by a framework."

True, but a few points.
I didn't mention a DB (generic database indexing is unsuitable for the search task, and the performance is too slow since the index is a generic rather than specifically designed for the task). Hence the script+database was not a viable solution.
In the original article the author was doing light simple stuff, where the dbconnect time is unimportant anyway.
You can of course run your c++ daemon like any other piece of server software, the range of persistence options in C++ is more than those of scripting languages.

The point is clear, CGIs are a doddle, you really don't need to use a scripting language and any c++ programmer would be completely at home writing them.

Re:SCRIPT? Do it in C++! (1)

achacha (139424) | more than 7 years ago | (#18228070)

As a CGI library (freeCGI++) and an app server (AsynchObjectServer) developer, I can tell you that CGIs are extremely inefficent (but rather a quick and dirty way to build server side apps); there is so much you cannot do well with CGIs, like caching the executable/library (although FastCGI fixes this a bit), caching of static/global/app data, database connection pooling, HTTP pipelining (for all except IE), pre-parsing of data, templating, etc. I can write two simple apps (and I have actually) that do nothing but send back to the browser a simple XML doc . Both CGI and app server is in C++ and with CGI the execution takes 70-80ms and with an app server 5-8ms (on the same machine, albeit an old slow one but it's a relative test). There is a lot that needs to be built up with CGI execution (environment hooks, loading on executable, capturing of stdin/stdout, unloading), meanwhile the app servers (frameworks) can have it all pre-built and cached and only connection/request specific info needs to be built up.

The reason I wrote the app server and framework was to overcome the shortcoming of CGI (yet I still support the CGI library the same, it's great for quick app development as a proof of concept or prototype). I would never use CGI for any large scale development (maybe that's just me).

Re:SCRIPT? Do it in C++! (0)

Anonymous Coward | more than 7 years ago | (#18228280)

"Both CGI and app server is in C++ and with CGI the execution takes 70-80ms and with an app server 5-8ms (on the same machine, albeit an old slow one but it's a relative test)."

You may wish to tune your OS file cache if you're getting that performance, the file cache alone fixes the load time for the CGI code itself. I got 500 queries/second from the lowest spec server I could find, which is way beyond any requirement we're talking about here. Thats only about 10 simultaneous processes taking 20ms to do the (very complex) query. Obviously a much simpler process would take a lot less and a lot beefier server would run more simultaneous processes, but 500 is 15 BILLION queries a year so it's not small change.

It's a tradeoff, if you use a database then a dbconnect is expensive and persistence is more useful, but the slowness comes from the database it's not inherent in the CGI. Worse if the database is over the network, you have the network latency ontop of that aswell and persistance starts to become essential.
The down side is that you have shared process space and one thread can bring down the rest. There is a reason that Apache chose to load the CGIs as processes afterall.

When the web apps are taking over ... (4, Interesting)

Gopal.V (532678) | more than 7 years ago | (#18227394)

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

OMG (0)

Anonymous Coward | more than 7 years ago | (#18227546)

I love Firebug.

Another issue (4, Insightful)

fyngyrz (762201) | more than 7 years ago | (#18227398)

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

Well, sort of, Yeah -- maybe (2, Insightful)

vtcodger (957785) | more than 7 years ago | (#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:Well, sort of, Yeah -- maybe (2, Insightful)

Anonymous Coward | more than 7 years ago | (#18228072)

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 dimensions?

The Screen is The Interface (3, Insightful)

SEWilco (27983) | more than 7 years ago | (#18227536)

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:The Screen is The Interface (2, Interesting)

dvice_null (981029) | more than 7 years ago | (#18227712)

> A web browser is a GUI.

GUI = Graphical User Interface
Lynx = Text based web browser

You were saying... ?

Re:The Screen is The Interface (2, Interesting)

misleb (129952) | more than 7 years ago | (#18228106)

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 pain in the ass.... and I'm primarily a web developer! ;-P

-matthew

You web developers... (0, Troll)

pong (18266) | more than 7 years ago | (#18227566)

.. are such a sick and twisted bunch. Unfortunately for you, you never learned real programming, so now you think a hyper-text system on speed (that's what a modern web browser is) is the only true platform for developing applications. Next problem is that you jump on each and every new fad as if it's christs second coming.

Desktop in your browser? OS in your browser? Sad and stupid - makes me angry.

Re:You web developers... (4, Insightful)

mabu (178417) | more than 7 years ago | (#18227744)

Real programming basically died in the mid 1990s.

Re:You web developers... (5, Funny)

skrolle2 (844387) | more than 7 years ago | (#18227864)

You're just jealous because our stuff actually is used by a lot of people, whereas your toaster-controller, written in C, with a user-interface noone understands only got five downloads from Tucows. And one of them was your cat jumping up on your keyboard.

Re:You web developers... (1)

Nicolay77 (258497) | more than 7 years ago | (#18227988)

Where you see problems I see a business opportunity.

I'm sure the Flash/Flex people see things the same way, but they are making stuff to get into the RIA framework industry to tackle that business. May be even creating that industry.

About the OS in your browser, and the excess of XML praise, well those practices will not get that far. So I see no problem there. At all.

Re:You web developers... (1)

mstahl (701501) | more than 7 years ago | (#18228062)

Unfortunately for you, you never learned real programming

Genuine bona fide web developer, right over here, with a bachelor's in theoretical computer science. Judging by the prejudice in your comment, I'd wager that I've learned a lot more *real* programming than you have, and I practice it both in my web applications and also in my side projects.

The fact of the matter is that web applications are a pretty good idea if what you're trying to do is simple enough that a browser makes sense as a GUI, or is likely to change often enough that you need to constantly update it. And if you've got something where users edit information that has to be publicly available right away (read: CMS systems, calendars, various news sites *cough*slashdot*coughcough*), your publishing is just about as simple as it possibly could be.

For things like desktop applications (read: document preparation software—particularly when the documents should be private—and video games) the web interface thing doesn't make a whole lot of sense. Google's spreadsheet apps are pretty neat but I'm not sure I'd use them for anything really involved, but there are advantages too that even someone like yourself should be able to see. The documents I write on Writely don't disappear if my computer crashes, and I can get to them and edit them from my work machine then go home and keep working on them.

Before you go and diss a huge and growing population of the IT community, you should remember that, out there, there are people like me that just do this for a living and we're every bit as elite as you. Some of us are just a lot more polite.

Re:You web developers... (1)

powera (644300) | more than 7 years ago | (#18228444)

... thank goodness there is somebody still on Slashdot who can still write an intelligent comment.

go learn a real GUI framework... (0)

Anonymous Coward | more than 7 years ago | (#18227598)

once a "web developer" sits down and learns a proper GUI framework in a non scripting language then they will appreciate the simple (yet complex when you want to do advanced work) WSIWYG style work.

Distribution is a biggie for Linux (0)

Anonymous Coward | more than 7 years ago | (#18227616)

Distributing applications can be a real pita for Linux. You write something that runs in Ubuntu and then you have to port it to Windows for your cow-irkers, then you take it home to work on and find out that Suse is missing a dependency and when you fix that, it breaks another dependency ... etc. With a web-based program, all it has to do is run on the computer it was written for. As another poster points out it also means you have to fix bugs on only one computer. You don't have to re-distribute copies of the program every time you fix a bug.

perl? (0, Troll)

mabu (178417) | more than 7 years ago | (#18227728)

I agree, a simple cgi script can serve needs well, but it's really ironic IBM uses as an example, a Perl script... no doubt a clever way to encourage sales of their next bigger, faster server, because if you used Perl CGI scripts in a real-time web application that got any significant amount of traffic, you'd need 100 times the processing power of a comparable script written in C or PHP to perform the same task.

I know Slashdot is running in Perl, and their system is cool, but even with mod_perl, there's a lot more overhead in a perl-based application than other languages that are a lot more suitable for the web.

Re:perl? (4, Interesting)

cxreg (44671) | more than 7 years ago | (#18227796)

"even with mod_perl"? as opposed to what? mod_perl is the most flexible web server technology available on *nix, balancing good performance with a good set of functionality (who can beat CPAN?) it's faster and more scalable than Tomcat, and PHP is simply a joke. about the only true downside is that it's a total memory hog.

perl CGI, however, is crap as you said

Re:perl? (0)

Anonymous Coward | more than 7 years ago | (#18227842)

I agree, a simple cgi script can serve needs well, but it's really ironic IBM uses as an example, a Perl script... no doubt a clever way to encourage sales of their next bigger, faster server, because if you used Perl CGI scripts in a real-time web application that got any significant amount of traffic, you'd need 100 times the processing power of a comparable script written in C or PHP to perform the same task.

Frankly your comment about Perl needing 100 times the power of a C or PHP script shows that you know very, very little about Perl or C or PHP for that matter. Heck, the comment is open-ended enough that it could either be a clever troll or indeed, you know little about interpreted, compiled, and in-between languages.

So write your CGI in C. Duh. (1)

deaconB (1014003) | more than 7 years ago | (#18228456)

CGI is NOT a language. It's an interface specification. Thomas Boutell has a wonderful library for writing CGI in C.

I don't understand! Help me? (5, Insightful)

Anonymous Coward | more than 7 years ago | (#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.

Here is a good example. (0)

Anonymous Coward | more than 7 years ago | (#18227790)

Who here really prefers a web based email client over there native client?

Both have there place and time but thin clients just aren't there yet and that is a simple internet based example. Lets try like autocad or something if you want to get serious.

Sleight of hand involved in this article.... (1)

midnighttoadstool (703941) | more than 7 years ago | (#18227802)

"Experienced Web developers sometimes find themselves struggling to learn a GUI toolkit when a simple CGI script would serve their needs perfectly well."

But an experienced GUI developer is another matter. I can't really speak for other GUI frameworks but for Delphi and it seems for .Net (same architect - got filched from Borland by MS) dev time is hugely faster than WEB developement. It is totally out of proportion. Businesses that favour WEB dev for in-house work are strealing from themselves UNLESS they only have a developer experienced in WEB programming and not GUI programming in which case they have less choice in the matter.

It is true that with GUI developement there is a temptation to do a slick and clever interface and then dev time starts to slow significantly, and it is easier to produce a non-standard interface that annoys everyone. Sticking to something simple or within the normal confines of the framework and it beats WEB/CGI/PHP etc hands down in every category that I can think of (ie. time and performance, network traffic, user satisfaction etc). Interestingly a slick web interface however is another matter since unlike GUI's there is only the DOM and javascript so toolkits have standardised nicely and dev time isn't significantly slower for a slicker WEB interface (ie. the Prototype library). But a slick WEB interface doesn't really compare to a slick GUI interface (flash is GUI, in my opinion) since GUI's are only limited by the system not the browser (think of flash as a system in itself).

RAILS and Django (ruby, Python respectively) may be real contenders but not for performance. Both have dire performance, and limited concurrency. However both languages may be moving to VMs and may get proper threading as well, even Ruby. Currently Python uses a giant concurrency-crunching lock - but at least it allows non-blocking IO (I believe), and Ruby doesn't support native threads at all - all IO blocks - yikes!!!!!!!.

Hey, 1999 called (1)

jfz (917930) | more than 7 years ago | (#18227922)

And they want their multi-paradigm shifting, leveraging by XYZJSDHTML web based content management system solutions back

Those who fail to understand GUI apps.. (4, Insightful)

Junta (36770) | more than 7 years ago | (#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.

Web apps: They're not just for business anymore (1)

Paulrothrock (685079) | more than 7 years ago | (#18227982)

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.

Here's what happens a month later... (3, Insightful)

kahei (466208) | more than 7 years ago | (#18228002)

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.

Re:Here's what happens a month later... (0)

Anonymous Coward | more than 7 years ago | (#18228314)


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


And if you write it using IBM's WebSphere Portal, you could answer yes to all those questions.

Re:Here's what happens a month later... (5, Funny)

Anonymous Coward | more than 7 years ago | (#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."

Re:Here's what happens a month later... (0)

Anonymous Coward | more than 7 years ago | (#18228386)

I agree 99.9% with that, just wanted to say that you appear to have misspelled Java.

It can work (2, Insightful)

skroll82 (935998) | more than 7 years ago | (#18228026)

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 usable. However, I spend most of my time on the job fixing back end code that is absolutely horrendous. This is however, a product of 10 year old code, as well as the initial project having almost zero direction when the coding started. That's a problem that happens all across the board, not only on Web Applications.

Have a look at SWILL (2, Informative)

Diomidis Spinellis (661697) | more than 7 years ago | (#18228064)

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.

CGI a la Usotsuki.info (1)

dosius (230542) | more than 7 years ago | (#18228090)

I use CGI for simple dynamically-generated stuff, like want-lists based on numbers (e.g., missing episode lists), Now Playing, and random-image stuff. It's mostly bash/ksh scripts, sometimes with a sprig of C, and the HTML output is very rudimentary (if there is indeed any - some output pngs).

-uso.

VB6 (1)

DogDude (805747) | more than 7 years ago | (#18228100)

I know, I know, it's "unsupported", but if I need a quick and dirty app, I usually end up doing it in VB6. I've never seen a framework that allows for such quick development, and such flexibility. If I need a web browser for displaying info, you just click and drag a web browser into the environment. And of course, you have instant access to all other Win32 objects as well. It's great for tying together disparate systems, and you need a GUI.

Proof-of-concept & fast-prototyping (2, Interesting)

PatPending (953482) | more than 7 years ago | (#18228322)

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 billion dollars and 5,000 employees.)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?