kiat has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

Let's say you want to write an application that runs on the user's computer and your choice language is perl. I would like to hear from you the merits and demerits of writing a Tk-based interface vs a browser-based interface. Roughly here's what is required for the app:

1) connection to a database system (likely to be MySQL)

2) stand-alone

3) perform some basic accounting stuff (like computing the profit figure)

4) display images dynamically

Would appreciate your sharing.

Thanks!

Update

Just did a quick experimentation of Perl + Tk with MySQL. Was relieved to find out that the code to access MySQL from the Ptk script is the same as the one from a web-based script. This Tk thing is totally new to me so there're lot of unknowns...

Read somewhere that it's harder to display tabular data in a Tk window than on a web page because with the webpage, you can easily output the rows of data on a table. Any thoughts on that?

Replies are listed 'Best First'.
Re: Tk vs browser-based applications
by Elijah (Hermit) on Jul 05, 2005 at 03:53 UTC
    Tk Application:
    Pros:
    Truly stand-alone.
    More professional (IMO).
    Less system intensive.
    Platform independant.
    No worry about passing parameters.

    Cons:
    More in depth programming required.
    No real cross-platform printing capabilities.
    Less ability to be creative in appearance

    Web Based Application:
    Pros:
    No need for perl to be installed on all client machines.
    Avoidance of missing module issues on client machines.
    Allows for greater creativity in appearance.
    Accessible from anywhere.
    Ability to use browser print feature

    Cons:
    Not stand-alone.
    Requires web server configuration operation and maintenance.
    Less secure due to greater accessibility.
    Can be resource intensive (depending on user load).
    Could run into permission issues.

    www.perlskripts.com
[reply]
Re: Tk vs browser-based applications
by Errto (Vicar) on Jul 05, 2005 at 03:45 UTC
    When you say browser-based, do you mean the app runs on a web server and the user accesses it from a browser? Or do you mean something like GUI with HTTP::Daemon, where the app runs on the client but works through an embedded web server? The server method gives you control over the platform, relieves you from worrying about people stealing your database password, and eliminates the effort of code distribution, but requires you to have a web server. If you mean the embedded app, then the difference between web and Tk is only in the interface, and frankly I'd go with whichever you're more comfortable building interfaces in. For me it's probably web.
[reply]
      Thanks, Errto!
      When you say browser-based, do you mean the app runs on a web server and the user accesses it from a browser
      That's what I have in mind, which means apache would need to be installed on user's computer.

      How is it different from GUI with HTTP::Daemon?

[reply]
        I don't recommend distributing Apache for use in an end user desktop app, basically because it's overkill. The node I linked above describes a way to build the web server into your Perl program so that when the user runs it, the embedded web server starts and then the user's browser simply points to it. It's a pretty elegant solution in my view, which is why I used it in the app mentioned in my home node.
[reply]
Re: Tk vs browser-based applications
by zentara (Cardinal) on Jul 05, 2005 at 11:34 UTC
    The first thing that comes to mind, as to the difference, is that Tk will maintain "state" in a socket connection. A browser running cgi is a stateless, "one-shot-transaction". In your particular example, it probably wouldn't matter.

    Also you have the overhead of all the apache software, but if it already is there, that is no problem, except that when apache is overloaded, your cgi app's speed will suffer.

    The biggest thing to consider is whether you want to allow people to access this thru the internet(or intranet). If it is to be run only at your place of business, you would likely get more speed with Tk. Why, because all Tk would have to do is get the data, build an image, and display it. With a browser, you need to connect, then the cgi connects to Mysql, then the graphic needs to be built, then the "possible big graphic" has to be sent over the network. With Tk, the only thing needed to be sent over the network is the relatively small mysql data.

    If your Mysql server allows remote connections, a Tk app could connect directly to it thru the internet, and that may be you bottleneck, where your Mysql server will only accept connections from pre-desiginated ips, and almost force you to use apache, but you havn't given the details of your Mysql setup.

    I would go with Tk , you will have more "programming fun" ( but I'm biased :-) ).

    I'm not really a human, but I play one on earth. flash japh
[reply]
Re: Tk vs browser-based applications
by Anonymous Monk on Jul 05, 2005 at 22:16 UTC
    Well, depending on how much fun you want to have (or work you want to do), you might think about making the presentation independent of the underlying implementation details. In essence, you'd make a library to abstract away the user interface details. This would allow you to have different concrete implementations of the library: one that targets Tk, the other targets HTML. Then, the problem changes from *you* deciding which situation is best, to one where the *user* gets to decide (maybe even at runtime, based on his mood).
[reply]
Re: Tk vs browser-based applications
by noslenj123 (Scribe) on Jul 30, 2005 at 22:48 UTC
    I came across this thread while searching for an article I read a while back that explained how to package up a portable perl web based app.

    I recall that when it was started, it would launch a perl based web server that was small but still handled cgi. I think it then launched a browser with the url for the app's files. Seems like it was a Micro$oft windows solution but I may need to do just that.

    Does anyone recall an article like that out there anywhere?

[reply]

Back to Seekers of Perl Wisdom