Who will win the battle for control of the web?

[ccc31807]

Just finished reading 'Who will win the battle for control of the
web?' It's a worthwhile read, and can be found at:
www.pcpro.co.uk/features/363175/who-will-win-the-battle-for-control-of-the-web

Executive summary: "A series of critical breakthroughs – massively
increased bandwidth, the demand for rich media, cloud computing, the
advent of wireless connectivity and the rise of mobile devices – has
created the foundations for the next generation of rich internet-based
apps." Five contenders: (1) Adobe, (2) Microsoft, (3) Apple, (4)
Google, and (5) HTML5 will vie for the top spot, and each has both
strong points and weak points, and at this point it's a real
melee."The only safe prediction is that there will be plenty more
twists, turns, alliances and battles to come before the war is finally
decided."

Reactions from the Perl community?

My take is this: The core competency of the web is content, not eye-
candy. Perl's strength lies in delivering content -- it's the
Practical Extraction and Reporting Language after all. Perl excels in
connecting data stores to web based interfaces and manipulating the
data to produce information and for delivery to end users, but does
not even compete with the eye-candy apps. I can see the use of Perl to
dynamically spit out HTML, CSS, JavaScript, SVG, ?ML (including Flex),
and occupying a strong position underneath the five contenders (with
the probable exception of Silverlight, which can leverage .NET apps).
I could even see Perl being used to generate eye-candy directly, like
JavaFX, but without the sexiness of Flash, Android, iOS, etc.

Does Perl have a stake in the battle for control of the web? If so,
what is Perl's position?

CC.

 

[ccc31807]

HTML5 is not a company.

What is it doing in this list?

The article to which I referred evaluated five technologies with
respect to delivering RIAs. HTML5 isn't a company, but might prove
itself a competitor to Flash in the future. I didn't write the
article, and I didn't pick the technologies -- I thought that it was a
reasonably good read IF you are interested in the topic, and wondered
how Perl fit into the picture, if at all. Is Perl totally irrelevant
to this discussion?

Why are there quotation marks around that?

Because it's a direct quotation from the article.

Where are you quoting it from?

www.pcpro.co.uk/features/363175/
who-will-win-the-battle-for-control-of-the-web

I'm not trying to pick a fight. I don't like Flash, Silverlight,
Objective C, iOS, Android, JavaFX, or RIAs in general. I think the WWW
is a great way to deliver information, and frequently write HTMLized
interfaces to databases and functionalities. I got my start in IT with
the web, two decades ago, and I'm just trying to figure out how what I
do fits into the world that this article describes.

Do you have anything to say about this? (This isn't intended to be
disrespectful, I would be interested to know your thoughts, if you
care to post them.)

CC.

 

[Bart Van der Donck]

[...]
Does Perl have a stake in the battle for control of the web? If so,
what is Perl's position?

IMHO Perl has already lost that battle years ago. Perl is a USA thing
by and for dinosaurs; it makes me think of George Bush.

PHP is the server scripting language of the web, and has proven it for
ten years now: international, global, community driven, fresh air,
modern.

 

[Dave Saville]

[...]
Does Perl have a stake in the battle for control of the web? If so,
what is Perl's position?

IMHO Perl has already lost that battle years ago. Perl is a USA thing
by and for dinosaurs; it makes me think of George Bush.

PHP is the server scripting language of the web, and has proven it for
ten years now: international, global, community driven, fresh air,
modern.

 

[ccc31807]

IMHO Perl has already lost that battle years ago. Perl is a USA thing
by and for dinosaurs; it makes me think of George Bush.

PHP is the server scripting language of the web, and has proven it for
ten years now: international, global, community driven, fresh air,
modern.

Did you read the article?

WRT Flash, Silverlight, and the others mentioned, PHP is in the same
position as Perl, except PHP is much less capable than Perl.

I raised the possibility of using Perl to generate RIAs, and got a
quick answer from Sherm and Tad: even the thought is off topic for
Perl.

If you want to develop rich internet applications, you might as well
forget Perl, which is just as well suited to developing RIAs as a cast
iron frying pan ... or so they say. They are probably right, at least,
they won't get an argument from me.

CC.

 

[Peter J. Holzer]

I have no idea why Perl should be a "USA thing". It seems to be alive
and well in Europe, and from people who attend more conferences than me
I hear that the community in East Asia is especially vibrant.

Did you read the article?

WRT Flash, Silverlight, and the others mentioned, PHP is in the same
position as Perl, except PHP is much less capable than Perl.

I raised the possibility of using Perl to generate RIAs, and got a
quick answer from Sherm and Tad: even the thought is off topic for
Perl.

If you want to develop rich internet applications, you might as well
forget Perl, which is just as well suited to developing RIAs as a cast
iron frying pan ... or so they say. They are probably right, at least,
they won't get an argument from me.

You are confused about the difference between server-side and
client-side programming. For "rich internet applications" (make one
cross on the bullshit bingo card) you typically need both.

You need code which runs in the browser. That means that there needs to
be an interpreter for that code in the browser, and that limits you to a
handful of options: JavaScript, Flash, Java, ... unless you can convince
your users that your site is worth installing yet another plugin.

You also need code which runs on the server. Here you can use anything
you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...

Note that the overlap between client-side and server-side languages is
small: Java is about the only language which was popular for both,
but these days Java applets seem to be exceedingly rare (except for
remote management stuff). JavaScript OTOH seems to be quite unpopular on
the server despite a number of implementations. Flash on the server?
Never heard about that.

So for you almost always need two languages: One for the client-side
(typically JavaScript), and one for the server. There is no reason why
one should "forget Perl" on the server: It is just as well suited for
that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
its pros and cons, but I don't see anything in any of them which would
make it unsuitable for the server side of an AJAX application.

hp

 

[ccc31807]

You are confused about the difference between server-side and
client-side programming. For "rich internet applications" (make one
cross on the bullshit bingo card) you typically need both.

No, not confused about server/client side. From the article: "Each of
the big three computing companies – Microsoft, Apple and Google – has
its own radically different vision to promote, as does the world’s
biggest creative software company, Adobe." Yes, Flash and JavaScript
is interpreted in the browser, as is Java, and .NET relies on the MS
runtime, but that isn't the end of the story. You can write Flex using
notepad, run it through the Flex compiler, and produce Flex files. You
can also produce XML files that will run in a browser, not only XHTML
but things like SVG.

Maybe I'm confused about RIAs. Roughly, I see RIAs as something like
an interactive TV, e.g., the iPhone apps. My question was what role,
if any, Perl can play in creating RIAs. I don't have in mind a Perl
module to spit out Flash movies, but leveraging Perl's strengths in
the RIA arena.

You need code which runs in the browser. That means that there needs to
be an interpreter for that code in the browser, and that limits you to a
handful of options: JavaScript, Flash, Java, ... unless you can convince
your users that your site is worth installing yet another plugin.

Which you can't outside of a particular need. (Yesterday I installed
Scorch, the Sibelius music reader, to read some files, but I was
highly motivated to do that.)

You also need code which runs on the server. Here you can use anything
you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...

Note that the overlap between client-side and server-side languages is
small: Java is about the only language which was popular for both,
but these days Java applets seem to be exceedingly rare (except for
remote management stuff). JavaScript OTOH seems to be quite unpopular on
the server despite a number of implementations. Flash on the server?
Never heard about that.

Server side Perl emits files, which can be HTML files, PDF files, GIF
and JPEG files, ASCII text files, and so on. Can Perl generate a file
that will produce a rich internet experience for the user, i.e., in a
browser?

So for you almost always need two languages: One for the client-side
(typically JavaScript), and one for the server. There is no reason why
one should "forget Perl" on the server: It is just as well suited for
that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
its pros and cons, but I don't see anything in any of them which would
make it unsuitable for the server side of an AJAX application.

I just mentioned two, Flex and SVG. And yes, you can use Perl to emit
JavaScript to enable dynamic functionality for the end user, whether
you call it AJAX or just plain old JavaScript.

Seems to me that, in this brave new world of internet enabled devices
everywhere, that Perl needs to evolve or else become a niche language,
rather than the 'glue of the internet.'

It also seems to me that the Perl community is oblivious to these new
developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
surprise me to see a new PM that will produce something like this, but
I think it will come from a new generation.

CC.

 

[Peter J. Holzer]

[I note that we may have use a different definition for RIAs. For me
these include AJAX-based web-application, indeed I was thinking mostly
of them. But Wikipedia distinguishes between RIAs, which require the
user to install extra software (plugins, runtime environments, etc.) on
their PC and AJAX which uses only browser-builtin facilities. In recent
years there is little which can't be done with Ajax, and I think Ajax
will take an ever-larger piece of the cake and Flash and co will lose
ground]

Server side Perl emits files,

No, it emits HTTP responses. A "file" is something on a disk (or similar
storage device), an HTTP response is a message in a communication
protocol.

which can be HTML files, PDF files, GIF and JPEG files, ASCII text
files, and so on. Can Perl generate a file that will produce a rich
internet experience for the user, i.e., in a browser?

Same as any other language. You get an HTTP request, you process it, you
send an HTTP response. All of this is completely independent of the
language, except that you may find libraries and frameworks which are
more or less suited to the task at hand.

I don't understand what you mean by "a file that will produce a rich
internet experience". You can of course create any file from Perl. But
for some it would be foolish: If you want a .class-file, you use an
existing Java compiler, you don't write a new Java compiler from scratch
in Perl (But you might write a Perl compiler which emits Java byte code
in Perl). If by "a file that will produce a rich internet experience"
you mean a single file which contains the application and can be put on
a server and downloaded by the browser, then that consists mostly of
code (which has to be written), auxiliary data like icons, animations,
sounds, text, (which has to be produced) and a bit of packaging around
that. There's is not much room for a server-side programming language in
producing such a file: When the programmer is finished, its static
(although the programmer may of course use scripts to automate the
creation of some of its parts). The server side programming language
only comes into play, once the browser downloads the file and starts
executing it: Then the application will "phone home" and request data
which may be delivered by a piece of Perl talking to a database, for
example.

I just mentioned two, Flex and SVG.

SVG is just a vector graphics format. You can of course produce SVG from
Perl, there are modules for that (or you could just hand-code it). It
isn't a programming language - for dynamic stuff in the browser it is
usually combined with JavaScript.

Flex is, AFAICS, mostly a development framework for Flash. It is
possible that the applications generated by that framework can only talk
to server-components sold by Adobe (like LiveCycle Data Services). Then
you're locked into your cozy little Adobe world and can only use what
Adobe provides. But if does talk standard protocols, then again it
doesn't matter whether the server side is written in Java, Perl, PHP or
Erlang.

Seems to me that, in this brave new world of internet enabled devices
everywhere, that Perl needs to evolve or else become a niche language,
rather than the 'glue of the internet.'

It also seems to me that the Perl community is oblivious to these new
developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
surprise me to see a new PM that will produce something like this, but
I think it will come from a new generation.

Again, you haven't provided the slightest reason why you think so.

hp

 

[Keith Keller]

Seems to me that, in this brave new world of internet enabled devices
everywhere, that Perl needs to evolve or else become a niche language,
rather than the 'glue of the internet.'

I'd think that the ''glue of the internet'' would be used in many more
places than just serving HTTP requests.

--keith

 

[ccc31807]

No, it emits HTTP responses. A "file" is something on a disk (or similar
storage device), an HTTP response is a message in a communication
protocol.

My bad, I spoke informally and take your point. Maybe I should have
said 'stream' which when written to a filehandle becomes a file, and
when written as a response to an HTTP request gets sent out to the
requester.

I don't understand what you mean by "a file that will produce a rich
internet experience". You can of course create any file from Perl.  But
for some it would be foolish: If you want a .class-file, you use an
existing Java compiler, you don't write a new Java compiler from scratch
in Perl (But you might write a Perl compiler which emits Java byte code
in Perl). If by "a file that will produce a rich internet experience"
you mean a single file which contains the application and can be put on
a server and downloaded by the browser, then that consists mostly of
code (which has to be written), auxiliary data like icons, animations,
sounds, text, (which has to be produced) and a bit of packaging around
that. There's is not much room for a server-side programming language in
producing such a file: When the programmer is finished, its static
(although the programmer may of course use scripts to automate the
creation of some of its parts). The server side programming language
only comes into play, once the browser downloads the file and starts
executing it: Then the application will "phone home" and request data
which may be delivered by a piece of Perl talking to a database, for
example.

Yes. You will have to read the article -- I was responding to it, and
my context was that of the article. Quoting therefrom: "A series of
critical breakthroughs – massively increased bandwidth, the demand for
rich media, cloud computing, the advent of wireless connectivity and
the rise of mobile devices – has created the foundations for the next
generation of rich internet-based apps." Notice the words NEXT
GENERATION.

The technologies considered are very different:
*Flash - "Today, more than 75% of web video is delivered via Flash and
more than 99% of internet-connected desktop computers can view Flash
content, according to Adobe."
*Silverlight - "Crucially, Microsoft has also created a lightweight
subset of the full WPF specification called Silverlight and a cross-
platform, cross-browser Silverlight player that developers can target
primarily using C# or Visual Basic."
*Apple - Targets internet enabled devices, like phones and tablets, on
top of iOS, and really constitutes a category apart from our usual
concept of Wintels running browsers.
*Google - "But the strongest performer of all in terms of rising
market share – with a staggering 886% year-on-year growth in Q2 2010 –
and the new US smartphone market leader with 34%, is Google Android."
*HTML5 - ... and all the rest of the open universe, including CSS and
JavaScript.

Obviously, these are very different technologies, using a variety of
tools: proprietary frameworks, C#, VB, Objective C, iOS and Android,
targeting different types of devices: computers, phones, pads, and who
knows what else. Not to mention that a number of these rely on Java
and even C and C++.

Again, you haven't provided the slightest reason why you think so.

What's missing in the discussion? A decade ago, I was writing dynamic
web pages tied to databases using Perl and CGI, basically rolling my
own, building my own 'framework.' Today, I'm still doing the same
thing, in another context, building graphical front ends to databases
that run on users' browsers. A good friend of mine, working for a
large employer, writes web apps using Flex (and swears by it) that I
can't touch with Perl, unless I hand roll my own with AJAX type stuff.

What's missing from this discussion is the role of Perl, and according
to Tad, has so little to do with Perl that the entire discussion is OT
in c.l.p.m. I don't suggest that anything written in Perl can rival
Flash, or iOS, or Android, or the like. I also don't suggest that Perl
has a place on the client (remember client side PerlScript?).

You can produce a lot of good stuff using MySQL, R, and Perl, and I
don't think this stack can be beat for statistical operations. What I
am thinking is some sort of stack involving a database, Perl, and some
other technology, might be able to compete head to head with some (if
not all) of the technologies considered in the article.

Quite frankly, I'm surprised that no one is talking about it.

CC.

 

[Peter J. Holzer]

[...]

Yes. You will have to read the article -- I was responding to it, and
my context was that of the article.

That article is exclusively about the client side. It doesn't talk about
the server side at all. So it is almost completely irrelevant for perl,
except that some proprietary technologies (Flash, Silverlight) may be
more comfortable talking to a server side from the same vendor. However,
the article is very clear that HTML5 is to be considered one of the
major platforms, probably even the most important one:

| There’s a surprising degree of agreement between all the experts we
| spoke to that the best option for delivering a project is HTML5,
| wherever possible.
[...]
| However, with enthusiastic browser support from Apple, Google, Adobe and
| Microsoft, it looks safe to say that the HTML-based web will remain the
| dominant internet platform, and that HTML5 will take it into new
| territory.

And Perl (on the server side) plays nicely with HTML5 (on the client
side), so the answer for Perl programmers is to learn JavaScript (if
they don't know it already) and write hybrid Perl/JavaScript
applications. Probably nothing new for most web programmers, since - as
I pointed out earlier - there were always different languages on the
client and server side.

What's missing in the discussion?

A sense of how things fit together. You are throwing operating systems,
programming languages, SDKs, content formats, client- and server-side,
etc. all together, and the result is just a big mess with strange
conclusions.

A decade ago, I was writing dynamic
web pages tied to databases using Perl and CGI, basically rolling my
own, building my own 'framework.' Today, I'm still doing the same
thing, in another context, building graphical front ends to databases
that run on users' browsers. A good friend of mine, working for a
large employer, writes web apps using Flex (and swears by it) that I
can't touch with Perl, unless I hand roll my own with AJAX type stuff.

Well, why don't you? Or use one of the gazillions of existing Ajax
frameworks? If you refuse to do any client-side programming you can't
complain that your apps don't look as nifty as those by people who do
client-side programming (and with a tool which is specifically intended
to produce eye-candy to boot).

What's missing from this discussion is the role of Perl, and according
to Tad, has so little to do with Perl that the entire discussion is OT
in c.l.p.m. I don't suggest that anything written in Perl can rival
Flash, or iOS, or Android, or the like.

Nobody would write a browser plugin or an operating system in Perl. Perl
isn't a systems programming language. Although I think Flash would hang
my browser less frequently if it was written in Perl .

I also don't suggest that Perl has a place on the client (remember
client side PerlScript?).

All the stuff the article is about is on the client. If Perl doesn't
have a place on the client (I agree with that) then there simply isn't
any competition between Perl and these technologies.

Perl has a role on the server. And by server I also mean cloud
computing. Perl has had frameworks for distributing tasks across the
network for a long time, maybe with cloud computing these will see more
use.

You can produce a lot of good stuff using MySQL, R, and Perl, and I
don't think this stack can be beat for statistical operations. What I
am thinking is some sort of stack involving a database, Perl, and some
other technology, might be able to compete head to head with some (if
not all) of the technologies considered in the article.

Doesn't make sense since none of the technologies considered in the
article include a server or database part.

What you would do is combine one of the technologies considered in the
article (HTML5, most likely) with Perl and a database and build an
application framework. Actually, I think quite a few people have already
done that - at least always hear the web programmers I know (those that
use Perl) about using Catalyst together with this or that Ajax
framework.

Quite frankly, I'm surprised that no one is talking about it.

Go to a Perl workshop and you will hear people talking about it.

I think there are just too few web developers in this group. But then
this group is about Perl, not about web development, and the questions
relevant to web development are mostly not Perl-specific, so they
wouldn't be on-topic here, anyway.


hp

 

[ccc31807]

I agree with almost everything you say. I think the POV of the article
was not server side vs. client side, or open vs proprietary, or
applications vs operating systems, or traditional computers vs
internet appliances. I think the POV of the article was providing
users (what has been called) a 'rich internet experience.' Whatever
that means, and I agree with you that it's more of a concept than a
clearly defined term.

That article is exclusively about the client side.

In a sense, but it also considers iOS and Andriod, which are operating
systems, and the .NET platform, which allows development of
applications in the traditional manner. It also doesn't mention Java,
or the Adobe AIR, which I thought a little curious.

And Perl (on the server side) plays nicely with HTML5 (on the client
side), so the answer for Perl programmers is to learn JavaScript (if
they don't know it already) and write hybrid Perl/JavaScript
applications.

Where does this leave Perl for the iPhone, iPad, etc.? I read another
article in the last couple of days that speculated that the era of the
'personal computer' was over. I think that rather than consolidating,
the technologies are fragmenting. After all, we still have mainframes,
and people still write COBOL, along with Objective-C, and all the
Android apps. I'm not taking a position, and I certainly don't know
the answer ... I'm really just musing (to call it thinking out loud
would be too much.)

Nobody would write a browser plugin or an operating system in Perl. Perl
isn't a systems programming language. Although I think Flash would hang
my browser less frequently if it was written in Perl .

Perl brings things to the table that other languages lack.
Specifically, I think Flash is over used and over abused. People who
know Flash think in can do anything and everything, and I know some
owners/stakeholders who insist on using Flash for everything.
Considering all the different kinds of jobs, I believe that Perl has a
lot more capability than Flash, but Flash gets a lot more press.

All the stuff the article is about is on the client. If Perl doesn't
have a place on the client (I agree with that) then there simply isn't
any competition between Perl and these technologies.

Perl doesn't have a place on the client, but the work product of Perl
surely does. For example, I have produced work using a combination of
Perl and R which should be the envy of every Flash/.NET developer. If
you need to dynamically analyze a mass of data and produce a PDF plot
or graph, I honestly don't think you can beat Perl. The point is that
the PRODUCT of Perl has a place on the client, not Perl itself (which
agrees with your point.)

Doesn't make sense since none of the technologies considered in the
article include a server or database part.

Part of the Rich Internet Applications consist content, think Amazon,
eBay, Facebook, even Target, WalMart, and L.L.Bean. You are right,
except all the eye candy without content is meaningless.

What you would do is combine one of the technologies considered in the
article (HTML5, most likely) with Perl and a database and build an
application framework. Actually, I think quite a few people have already
done that - at least always hear the web programmers I know (those that
use Perl) about using Catalyst together with this or that Ajax
framework.

I hope that the number of those belligerents fighting the battle for
the control of the web will expand. I would hate to see a monoculture
of technology in this area. I also think that the capabilities of Perl
can be used to advantage.

Thanks for the discussion, CC.

 

[Xho Jingleheimerschmidt]

Quite frankly, I'm surprised that no one is talking about it.

If you want lots of pointless and confused bloviation, maybe Perl isn't
for you.

Xho

 

[David Canzi]

I just mentioned two, Flex and SVG. And yes, you can use Perl to emit
JavaScript to enable dynamic functionality for the end user, whether
you call it AJAX or just plain old JavaScript.

Seems to me that, in this brave new world of internet enabled devices
everywhere, that Perl needs to evolve or else become a niche language,
rather than the 'glue of the internet.'

Everywhere except the web browser is not a niche.

 

[Peter J. Holzer]

I agree with almost everything you say. I think the POV of the article
was not server side vs. client side, or open vs proprietary, or
applications vs operating systems, or traditional computers vs
internet appliances. I think the POV of the article was providing
users (what has been called) a 'rich internet experience.'

Users see only the client. For them the browser is the internet.

In a sense, but it also considers iOS and Andriod, which are operating
systems,

They are operating systems for a specific class of client devices. You
may or may not be able to run Perl on them (probably not on iOS, which
is very much a "walled garden"; possibly on Android, which is much more
open, although porting perl to Android might be a challenge; I do have
perl on my phone, BTW, but I admit that I don't quite know what to do
with it).

and the .NET platform, which allows development of
applications in the traditional manner.

Yes, but the focus was on Silverlight. Reusability of components of and
for "native" Windows applications was mentioned as an additional bonus
(an important one, though - the Windows software market is huge).

I do expect HTML5/JavaScript to break into the "native application"
market.

It also doesn't mention Java, or the Adobe AIR, which I thought a
little curious.

I'm not much surprised about Java. After the hype of the 1990s, Java
applets have mostly vanished. There are a few niches where it is still
very common (e.g. configuration and remote management interfaces), but
apart from that it is mostly server-side now.

Adobe AIR "enables ... to build web applications that run as standalone
client applications without the constraints of a browser". As such it
probably wasn't on the topic of the article which concentrated on web
clients (with the somewhat curious exception of iOS/Android apps, but
those share some characteristics of web apps, especially the easy
access).

Where does this leave Perl for the iPhone, iPad, etc.?

In the cloud. You run your Perl programs in the cloud (well, for most
services a single server will be enough, but it might even be cheaper to
rent 0.02 CPUs) and provide a web interface or an App as the UI.

I read another article in the last couple of days that speculated that
the era of the 'personal computer' was over. I think that rather than
consolidating, the technologies are fragmenting. After all, we still
have mainframes, and people still write COBOL, along with Objective-C,
and all the Android apps.

Yes. And that's one reason why I'm not particularly worried about the
future of Perl. It won't ever be the one language that binds them all
(it never was, all the talk about the "glue of the internet"
notwithstanding), but neither will it vanish. The very fragmentation and
heterogeneity of the landscape will provide places where it is the best
solution. And if you are only talking to the rest of your environment
via TCP anyway, the language has little impact on compatibility (I'm
writing my part of a major application in Perl, my colleague is writing
his in Java. Somebody else is writing a component in C# ...)

Perl brings things to the table that other languages lack.

True. And other languages have features which Perl lacks. It depends on
the problem (and the programmer) which language is best suited for the
task. Perl is well suited for an awfully wide range and I admit I've
become lazy and implemented almost everything in Perl in recent years.

Specifically, I think Flash is over used and over abused.

I see Flash almost exclusively used for movies (because it's the only
movie player that 99% of the clients have installed) and for advertisements
(including annoying "intros" for websites). Sometimes for games. Very
rarely for whole websites where HTML/JavaScript would have been more
appropriate. But I can't think of a single example which I would call an
application.

People who know Flash think in can do anything and everything, and I
know some owners/stakeholders who insist on using Flash for
everything. Considering all the different kinds of jobs, I believe
that Perl has a lot more capability than Flash, but Flash gets a lot
more press.

That's because Flash is flashy (pun intended). Perl does its job quietly
on the server side and you don't see it. Can you tell that
http://www.delicious.com/ or http://www.lacunaexpanse.com/ are written
in Perl? Can you tell that http://gmail.com isn't written in Perl?
Unless that stuff crashes and you see an error message, you can't. Also,
Adobe has a PR budget and pays the press to write about their products.
Perl doesn't (neither does PHP or Python or Ruby, BTW).

Perl doesn't have a place on the client, but the work product of Perl
surely does.

That's what I'm saying. There isn't any competition between client-side
technologies and Perl. You can combine both.

Part of the Rich Internet Applications consist content, think Amazon,
eBay, Facebook, even Target, WalMart, and L.L.Bean. You are right,
except all the eye candy without content is meaningless.

Why "except". Exactly *because* eye candy without content is
meaningless, you still need something on the server side. And that can
be perl (or one of a hundred other languages).

I hope that the number of those belligerents fighting the battle for
the control of the web will expand. I would hate to see a monoculture
of technology in this area.

For the client side I hope that there will be some very few standards
(like HTML5) with lots of different implementations. Currently there are
3 major platforms (IE, Gecko, Webkit) and a few minor players (like
Opera). This is better than a few years ago. It probably won't get
better: HTML5 is hugely complex and the days where a small company could
write a browser within a few months are definitely over.

I also think that the capabilities of Perl can be used to advantage.

We agree absolutely here.

hp

 

[KellyBryan]

What I have noticed is that the article only talks about client. Where is the server's side ?