Mailing List Archive

Perl and ASP.Net
Hello people
Trying to look for the *best* perl web framework out there and looking for suggestions. I've looked at Catalyst, Jifty and bunch of other frameworks. My biggest gripe about these web frameworks is the lack of reusable UI controls aka ASP.Net. One reason ASP.Net has caught on so quickly is the availability of inexpensive and slick third party UI controls. Most geeks make lousy web designers and would rather fiddle with the back end server code than CSS and javascript. Is there a LAMP framework offering even close to what ASP.Net offers in terms of UI development? Look at
http://www.telerik.com/demos/aspnet/Controls/Examples/Default/DefaultCS.aspx for inspiration.

In my opinion, lack of rich controls is the biggest drawback of LAMP frameworks. We as geeks might not like to hear about it but average manager at a big corporation is still sold by slick presentation and not cool back-end technology.
Maybe it's time for mod-perl geeks to get together and come up with an uniform API for web controls that can then be used by others to develop reusable controls.
-Praveen
Re: Perl and ASP.Net [ In reply to ]
On 4/23/07, Praveen Ray <praveenray@yahoo.com> wrote:
> t
> Hello people
> Trying to look for the *best* perl web framework out there and looking for
> suggestions. I've looked at Catalyst, Jifty and bunch of other frameworks.
> My biggest gripe about these web frameworks is the lack of reusable UI
> controls aka ASP.Net. One reason ASP.Net has caught on so quickly is the
> availability of inexpensive and slick third party UI controls. Most geeks
> make lousy web designers and would rather fiddle with the back end server
> code than CSS and javascript. Is there a LAMP framework offering even close
> to what ASP.Net offers in terms of UI development? Look at
> http://www.telerik.com/demos/aspnet/Controls/Examples/Default/DefaultCS.aspx
> for inspiration.

I think that a lot of the reason is because the frameworks that you
see are mostly based around perl and don't focus too much on the
actual View but mostly on the Model and Controller. There are plenty
of javascript frameworks (Dojo, YUI, OpenRico, MooFx, Script.aculo.us)
that provide many and all of the same things that you are pointing to
as available in ASP.Net. The problem/advantage with PERL based
frameworks is that, of course, they give you MTOWTDI which means that
you have to decide which one is best and most appropriate for what you
need.

> In my opinion, lack of rich controls is the biggest drawback of LAMP
> frameworks. We as geeks might not like to hear about it but average manager
> at a big corporation is still sold by slick presentation and not cool
> back-end technology.
> Maybe it's time for mod-perl geeks to get together and come up with an
> uniform API for web controls that can then be used by others to develop
> reusable controls.

Again, you are talking about client-side UI controls that belong in
only one small subset of any given framework. You should be able to
use any one of them that you want without problems.

> -Praveen
>
>

Cheers,

--
~Tyler
Re: Perl and ASP.Net [ In reply to ]
Praveen Ray wrote:
> My biggest gripe about these web frameworks is the lack of
> reusable UI controls aka ASP.Net. One reason ASP.Net has caught on so
> quickly is the availability of inexpensive and slick third party UI
> controls.

ASP.Net tries to do both the server and client side (sometimes the programmer
doesn't even know if his C# code is actually going to be run on the server or
the client). Perl (and on this list mod_perl) takes care of the server side but
leaves the client side up to you.

> Most geeks make lousy web designers and would rather fiddle
> with the back end server code than CSS and javascript.

I agree that I'm a lousy designer, but in this day Javascript (and CSS to some
extent) are becoming more and more important. Javascript is a real programming
language relegating it to be the work of web designers is why there's so much
crappy Javascript code out there today. I feel that you're really doing yourself
a disservice to not learn it and learn it well.

> Is there a LAMP
> framework offering even close to what ASP.Net offers in terms of UI
> development?

LAMP is all about server side technology, not client side. But there are several
open source client side frameworks out there. I'm a fan of Prototype myself and
have been eyeing Ext (a widget framework that can use YUI, JQuery or Prototype
as a backend) with interest.

I think the OSS community is actually ahead of .Net in this regard since you
aren't tied to a particular back-end system. Choice does mean you need more
knowledge though. Start looking around and evaluate and pick one that suits your
needs.

I like:
http://prototypejs.org/
http://wiki.script.aculo.us/scriptaculous/
http://extjs.com/

Other good and popular choices are
http://jquery.com/
http://developer.yahoo.com/yui/
http://mootools.net/
http://dojotoolkit.org/

--
Michael Peters
Developer
Plus Three, LP
Re: Perl and ASP.Net [ In reply to ]
If you want a lamp framework with reusable UI controls, maybe you should
look at http://www.activegrid.com/ . I don't believe it supports modperl
though. As far as I know, there isn't an easy high-level web design
framework that lets designers achieve some of the better features you see
today. There has been a lot of work to build javascript toolkits, but the
problem I see with that is that 8% of browsers have javascript disabled.
Well-designed websites have something to fall back on when javascript
fails (see gmail for example).

Rhett

On Mon, 23 Apr 2007, Praveen Ray wrote:

> Hello people Trying to look for the *best* perl web framework out there
> and looking for suggestions. I've looked at Catalyst, Jifty and bunch of
> other frameworks. My biggest gripe about these web frameworks is the
> lack of reusable UI controls aka ASP.Net. One reason ASP.Net has caught
> on so quickly is the availability of inexpensive and slick third party
> UI controls. Most geeks make lousy web designers and would rather fiddle
> with the back end server code than CSS and javascript. Is there a LAMP
> framework offering even close to what ASP.Net offers in terms of UI
> development? Look at
> http://www.telerik.com/demos/aspnet/Controls/Examples/Default/DefaultCS.aspx
> for inspiration.
>
> In my opinion, lack of rich controls is the biggest drawback of LAMP
> frameworks. We as geeks might not like to hear about it but average
> manager at a big corporation is still sold by slick presentation and not
> cool back-end technology. Maybe it's time for mod-perl geeks to get
> together and come up with an uniform API for web controls that can then
> be used by others to develop reusable controls. -Praveen
>
>
Re: Perl and ASP.Net [ In reply to ]
>> Most geeks make lousy web designers and would rather fiddle
>> with the back end server code than CSS and javascript.

>I agree that I'm a lousy designer, but in this day Javascript (and CSS to some
>extent) are becoming more and more important. Javascript is a real programming
>language relegating it to be the work of web designers is why there's so much
>crappy Javascript code out there today. I feel that you're really doing yourself
>a disservice to not learn it and learn it well.

all the more reasons for UI controls to exist. These hide javascript and even handlers from the designers altogether. The real value is in delivering one chunk of code which contains all it needs - javascript, C# , CSS, images. Drop this chunk in right place and you're instantly creating a sortable, pageable, selectable grid. Why build the wheel when you can buy it for less than $500.00 ?
Re: Perl and ASP.Net [ In reply to ]
Praveen Ray wrote:
>>> Most geeks make lousy web designers and would rather fiddle
>>> with the back end server code than CSS and javascript.
>
>>I agree that I'm a lousy designer, but in this day Javascript (and CSS
> to some
>>extent) are becoming more and more important. Javascript is a real
> programming
>>language relegating it to be the work of web designers is why there's
> so much
>>crappy Javascript code out there today. I feel that you're really doing
> yourself
>>a disservice to not learn it and learn it well.
>
> all the more reasons for UI controls to exist. These hide javascript and
> even handlers from the designers altogether. The real value is in
> delivering one chunk of code which contains all it needs - javascript,
> C# , CSS, images. Drop this chunk in right place and you're instantly
> creating a sortable, pageable, selectable grid. Why build the wheel when
> you can buy it for less than $500.00 ?

This is a viable option when you have more money than time. But the minute you
want to do something that your widget retailer hasn't already done before then
you're in trouble. GWT (Google's Java toolkit for AJAX apps) tried to completely
hide all Javascript from the programmer but they got a lot of complaints because
of the things people were trying to do but couldn't. So they now added a way so
that the server side can add literal Javascript to the outgoing request.
Basically putting the JS into a string that GWT spit out on the other side.
Reminds me of the old days of people sprinkling their HTML in strings throughout
the CGI programs. It was bad then and it's bad now.

Anytime you try to wrap something complex and featureful (like Javascript) so
that developers don't see it you have to do 1 of 2 things:

1) Allow only a subset of functionality
2) Make your wrapper just as complex as the thing it's wrapping.

#1 is ok if you only care about that subset (I will almost never care about
register details that compilers hide from me). #2 is just all around bad since
you have to learn the complexity of the thing anyway, just with some bad wrapper
interface instead of the real one.

--
Michael Peters
Developer
Plus Three, LP
Re: Perl and ASP.Net [ In reply to ]
> ASP.Net tries to do both the server and client side (sometimes the programmer
> doesn't even know if his C# code is actually going to be run on the server or
> the client). Perl (and on this list mod_perl) takes care of the server side but
> leaves the client side up to you.
>
I believe that's the grand strategy for C# developers. If they can write
code that can easily be ported from the web to (for example) a mobile
platform, it is a very good business strategy.


> I think the OSS community is actually ahead of .Net in this regard since you
> aren't tied to a particular back-end system. Choice does mean you need more
> knowledge though. Start looking around and evaluate and pick one that suits your
> needs.
I'm actually quite glad that we have two options (or more, in favour of
the Perl TIMTOWTDI mantra) of implementation a web-based application.
The ASP.NET way makes putting together an application quick and easy,
abstracting the details of client-server communication as much as
possible. This is aligned to the real-world scenario where too many
businesses expect 'instant applications' to respond to their new-fangled
ventures.

The we-do-purely-backend-stuff alternative that is modperl concentrates
on making the web app agile yet robust. To put it objectively, it is the
tradditional approach to writing web applications. It works, it's
proven, and there is good community and professional support for this
kind of framework.

Looking forward, I personally believe in the pervasiveness of the
dynamic and asynchronous interactivity between the client and the
browser. Module(s) that enable such features will be a milestone in
making modperl (and Perl itself) relavant in the ever changing web
landscape.
Re: Perl and ASP.Net [ In reply to ]
One of the draw back that seems to be evident to me as I've looked
into the client side frameworks is changes in the code are ought
of your control. WIth a purely server side solution it would seem
to give the coder the choice to upgrade when there is time, etc.
With the 3rd party frameworks they choose when you upgrade.
For the more stable solutions this is less of a problem. For the
newer technologies I've heard a lot of grumbling about having
to recode every time there is an upgrade...

-bop


On Apr 25, 2007, at 2:08 AM, Foo JH wrote:

>
>> ASP.Net tries to do both the server and client side (sometimes the
>> programmer
>> doesn't even know if his C# code is actually going to be run on
>> the server or
>> the client). Perl (and on this list mod_perl) takes care of the
>> server side but
>> leaves the client side up to you.
>>
> I believe that's the grand strategy for C# developers. If they can
> write code that can easily be ported from the web to (for example)
> a mobile platform, it is a very good business strategy.
>
>
>> I think the OSS community is actually ahead of .Net in this regard
>> since you
>> aren't tied to a particular back-end system. Choice does mean you
>> need more
>> knowledge though. Start looking around and evaluate and pick one
>> that suits your
>> needs.
> I'm actually quite glad that we have two options (or more, in
> favour of the Perl TIMTOWTDI mantra) of implementation a web-based
> application. The ASP.NET way makes putting together an application
> quick and easy, abstracting the details of client-server
> communication as much as possible. This is aligned to the real-
> world scenario where too many businesses expect 'instant
> applications' to respond to their new-fangled ventures.
>
> The we-do-purely-backend-stuff alternative that is modperl
> concentrates on making the web app agile yet robust. To put it
> objectively, it is the tradditional approach to writing web
> applications. It works, it's proven, and there is good community
> and professional support for this kind of framework.
>
> Looking forward, I personally believe in the pervasiveness of the
> dynamic and asynchronous interactivity between the client and the
> browser. Module(s) that enable such features will be a milestone in
> making modperl (and Perl itself) relavant in the ever changing web
> landscape.
Re: Perl and ASP.Net [ In reply to ]
Boysenberry Payne wrote:
> One of the draw back that seems to be evident to me as I've looked
> into the client side frameworks is changes in the code are ought
> of your control. WIth a purely server side solution it would seem
> to give the coder the choice to upgrade when there is time, etc.
> With the 3rd party frameworks they choose when you upgrade.
> For the more stable solutions this is less of a problem. For the
> newer technologies I've heard a lot of grumbling about having
> to recode every time there is an upgrade...

Huh? The JS in your project is always under your control. It's just like any 3rd
party component (like CPAN modules). You only upgrade it when you want to. The
only case that I know of where people pull in 3rd party JS components that
aren't locally controlled are those that use YUI and pull in their publicly
hosted files. (And this is only to boost download time since if every site using
the YUI libraries uses the same URL, a browser should just be able to use a
cached version). But even then you can specify specific versions.

--
Michael Peters
Developer
Plus Three, LP
Re: Perl and ASP.Net [ In reply to ]
The bigger issue is not of client or server side controls. What's sorely missing is a recommended best practice pattern that mod-perl people should follow to package and deliver chunks of functionality. I'm sure everyone here has his/her own little framework of serving javascript, css, and html. I might release a super cool grid control to CPAN but it'll come with it's own perl code, it's own javascript code, it's own CSS , it's own images! There should be a well established usage pattern so someone just downloads the grid module, run the installer and it puts all the files in 'right' places.
Of course, it's not possible currently since everyone has a different framework and different concept of 'right' place.

This is the biggest advantage of ASP.Net - not server or client side. One can be productively using a complex Charting control just by dropping a DLL in the right place. Choice is good but so is some order. It's about time mod-perl geeks start publishing at least suggested patterns to make this work. If anything, it's probably simpler to do in mod-perl world.

- Praveen

----- Original Message ----
From: Michael Peters <mpeters@plusthree.com>
To: Boysenberry Payne <boysenberry@humaniteque.com>
Cc: Modperl Mailing List <modperl@perl.apache.org>
Sent: Wednesday, April 25, 2007 12:52:36 PM
Subject: Re: Perl and ASP.Net

Boysenberry Payne wrote:
> One of the draw back that seems to be evident to me as I've looked
> into the client side frameworks is changes in the code are ought
> of your control. WIth a purely server side solution it would seem
> to give the coder the choice to upgrade when there is time, etc.
> With the 3rd party frameworks they choose when you upgrade.
> For the more stable solutions this is less of a problem. For the
> newer technologies I've heard a lot of grumbling about having
> to recode every time there is an upgrade...

Huh? The JS in your project is always under your control. It's just like any 3rd
party component (like CPAN modules). You only upgrade it when you want to. The
only case that I know of where people pull in 3rd party JS components that
aren't locally controlled are those that use YUI and pull in their publicly
hosted files. (And this is only to boost download time since if every site using
the YUI libraries uses the same URL, a browser should just be able to use a
cached version). But even then you can specify specific versions.

--
Michael Peters
Developer
Plus Three, LP
Re: Perl and ASP.Net [ In reply to ]
> code, it's own CSS , it's own images! There should be a well
> established usage pattern so someone just downloads the grid module,
> run the installer and it puts all the files in 'right' places.
> Of course, it's not possible currently since everyone has a different
> framework and different concept of 'right' place.

Doing this at the mod_perl level is probably one level too low. ASP.Net
is not the equivalent of mod_perl. It is more like any one of the
frameworks such as Catalyst, CGI::Application etc.

These frameworks have defined plugin systems, so doing what you're
talking about at that level makes sense.

The Perl modules that exist give us great power and flexibility, but
they come at the cost of integration. There is very little out there
that is plug and play. Unlike PHP, where people release (eg) a bulletin
board, or a webmail service etc.

But my experience of the PHP side is that people take these stand alone
pieces of functionality and stick them together with chewing gum. "We
want a bulletin board AND a webmail client, both of which have their own
user management system - well, we'll just build a bridge between them" -
ends up as nasty nasty code.

Because ASP.Net is centrally controlled, any new functionality MUST be
integrated into The Framework before it is released.

But with Perl, would we have anywhere near the level of creativity in
available code if everybody had to conform to The One True Way? I doubt
it.

Build a good X module, and the Catalyst guys will build a wrapper to
make it easy to integrate, as will the CGI::Application guys. And 100
people on this list will build their own wrappers so that it integrates
with their own framework, which they've painstakingly designed to work
in exactly the way that they want it to.

And 98 of those frameworks will fall into neglect, but 2 of them will
end up being released and used by others, who like the way that it does
things.

I think that's good. I like the way that works.

Clint
>
Re: Perl and ASP.Net [ In reply to ]
Clinton Gormley wrote:
>> code, it's own CSS , it's own images! There should be a well
>> established usage pattern so someone just downloads the grid module,
>> run the installer and it puts all the files in 'right' places.
>> Of course, it's not possible currently since everyone has a different
>> framework and different concept of 'right' place.
>
> Doing this at the mod_perl level is probably one level too low. ASP.Net
> is not the equivalent of mod_perl. It is more like any one of the
> frameworks such as Catalyst, CGI::Application etc.

++

--
Michael Peters
Developer
Plus Three, LP
Re: Perl and ASP.Net [ In reply to ]
On Apr 25, 2007, at 11:52 AM, Michael Peters wrote:

> Boysenberry Payne wrote:
>> One of the draw back that seems to be evident to me as I've looked
>> into the client side frameworks is changes in the code are ought
>> of your control. WIth a purely server side solution it would seem
>> to give the coder the choice to upgrade when there is time, etc.
>> With the 3rd party frameworks they choose when you upgrade.
>> For the more stable solutions this is less of a problem. For the
>> newer technologies I've heard a lot of grumbling about having
>> to recode every time there is an upgrade...
>
> Huh? The JS in your project is always under your control. It's just
> like any 3rd
> party component (like CPAN modules). You only upgrade it when you
> want to. The
> only case that I know of where people pull in 3rd party JS
> components that
> aren't locally controlled are those that use YUI and pull in their
> publicly
> hosted files. (And this is only to boost download time since if
> every site using
> the YUI libraries uses the same URL, a browser should just be able
> to use a
> cached version). But even then you can specify specific versions.
>

It was Yahoo's yui-ext library aka extjs that I was told this could
really be a problem
with. So I guess all JS frameworks aren't created equal.

Can you recommend a site or resource for comparison of the differing
frameworks?

It would seem like there is definitely a place for this in our
product, saving me lots of development
time and all.

PS Sorry for the non mod_perl noise. I'm hoping its well tolerated,
in that I use mod_perl
extensively and need to learn integrate it with other non-mod_perl
tech, e.g. it
serves up my JS, etc...


Boysenberry Payne
boysenberry@habitatlife.com
Re: Perl and ASP.Net [ In reply to ]
From: Praveen Ray


The bigger issue is not of client or server side controls. What's sorely
missing is a recommended best practice pattern that mod-perl people should
follow to package and deliver chunks of functionality.

"There is more than one way to do it" is an advantage, not a disadvantage.

Yes, there is no a single recommended way of creating web apps with
mod_perl, but there are more.

If you feel better to use a simple templating system like HTML::Template,
you might also want to use a somehow simpler framework like
CGI::Application.
If you like Mason templating system, you might like using Jifty framework,
and if you like Template-Toolkit and DBIx::Class ORM, you might like using
Catalyst.

Of course, all of these frameworks and others allow using more than one
templating system, Catalyst lets you access databases in more ways, you can
also choose if you want to run the applications using mod_perl, CGI, Fast
CGI or their own server, so you can choose anything you like.

Do you want a "recommended way"?

I recommend you to use Catalyst, with Template-Toolkit templating system,
with DBIx::Class ORM for accessing any kind of database from SQLite and
MySQL to PostgreSQL, Oracle and others, and I could also recommend some
modules for doing authentications, session management, form
creation/validation, and other things.

If you will feel that you don't like some of them, you can choose to use
something else, and the application will work very nice.

Do you like that .net doesn't offer you any alternative?
Then try to think that in perl there is no alternative than what I've
recommended you above.

And don't compare mod_perl with .net. Compare mod_perl with ISAPI, and
VS.net environment for the web with a framework like Catalyst, and see how
many choices you have in Catalyst, and how few in VS.net (not to mention
about the big number of CPAN perl modules that are not available for .net).

What is missing in perl?
A development environment which is very user friendly?
Sorry, I am blind, so for me VS .net environment is very unfriendly.

Octavian
Re: Perl and ASP.Net [ In reply to ]
On Apr 25, 2007, at 3:21 PM, Michael Peters wrote:

> Clinton Gormley wrote:
>>> code, it's own CSS , it's own images! There should be a well
>>> established usage pattern so someone just downloads the grid module,
>>> run the installer and it puts all the files in 'right' places.
>>> Of course, it's not possible currently since everyone has a
>>> different
>>> framework and different concept of 'right' place.
>>
>> Doing this at the mod_perl level is probably one level too low.
>> ASP.Net
>> is not the equivalent of mod_perl. It is more like any one of the
>> frameworks such as Catalyst, CGI::Application etc.
>
> ++

++ to that too.

But I'd also add that the WORST system functionality and javascript
comes from automated js. Its often bloated and only very 'simple',
and attacks a user side issue from a backend developer perspective.
thats just stupid.

keep your js and css in the control of your user interface designers
-- they know whats best. give them the tools and API to handle it
within templates and be able to talk to the backend in a manner that
they understand. anything else is just asking for 250k download
pages of pure text with javascript that barely works.

i don't see how any of this relates to mobile computing. when
people choose a language to run something on web + mobile + embedded
systems a platform is often chosen because the code runs on the
device and needs that sort of support. when you're talking about
making a WAP enabled website, all you need is an alternate template
tree .
Re: Perl and ASP.Net [ In reply to ]
Boysenberry Payne wrote:

> It was Yahoo's yui-ext library aka extjs that I was told this could
> really be a problem
> with. So I guess all JS frameworks aren't created equal.

It actually shouldn't be a problem as long as you don't use their hosted version
of files and use local copies instead.

> Can you recommend a site or resource for comparison of the differing
> frameworks?

I don't really know of a good one that has a nice matrix like view for a
comparison. And any that do are way out of date. Like any framework, it really
depends on what you want. Do you want it to smooth over some of Javascript's
rougher edges? Do you want lots of pre-built widgets? Do you want commercial
support/backing? In reality most of the big ones (Prototype, Dojo, YUI, jQuery,
Mootools) are all pretty good and will probably do what you're looking for. From
my experience though, Prototype, jQuery and Mootools feel more Perlish (see, I
brought it back to Perl!) and Dojo and YUI feel more Javaish.

I do like http://ajaxian.com/. It mentions various tools, projects and
frameworks all the time.

--
Michael Peters
Developer
Plus Three, LP
Re: Perl and ASP.Net [ In reply to ]
On Apr 26, 2007, at 6:05 PM, Michael Peters wrote:

> I don't really know of a good one that has a nice matrix like view
> for a
> comparison. And any that do are way out of date. Like any
> framework, it really
> depends on what you want. Do you want it to smooth over some of
> Javascript's
> rougher edges? Do you want lots of pre-built widgets? Do you want
> commercial
> support/backing? In reality most of the big ones (Prototype, Dojo,
> YUI, jQuery,
> Mootools) are all pretty good and will probably do what you're
> looking for. From
> my experience though, Prototype, jQuery and Mootools feel more
> Perlish (see, I
> brought it back to Perl!) and Dojo and YUI feel more Javaish.
>
> I do like http://ajaxian.com/. It mentions various tools, projects and
> frameworks all the time.

To add to that list:

MochiKit is also out there, and while not perlish its very very
Pythonic. Its my js toolkit of choice, in part because I used to
work with the maintainer, and in part because its just really
intuitive. It has less of a 'fancy fading boxes for users' feel to
it, and more of a 'lets make more efficient programming'. a lot of
the famous big tech/web companies use it for internal projects.
Re: Perl and ASP.Net [ In reply to ]
Boysenberry Payne wrote:
> One of the draw back that seems to be evident to me as I've looked
> into the client side frameworks is changes in the code are ought
> of your control. WIth a purely server side solution it would seem
> to give the coder the choice to upgrade when there is time, etc.
> With the 3rd party frameworks they choose when you upgrade.
> For the more stable solutions this is less of a problem. For the
> newer technologies I've heard a lot of grumbling about having
> to recode every time there is an upgrade...
My take on the current situation on client-side frameworks
(AJAX-styled?) is that it's a bit wild. We have scriptaculous,
prototype, yui, rico and more. Each of them do parts of a framework (eg.
drag-n-drop, controls), but even the concept of a client-side framework
is kinda hazy. What constitutes a client-side framework exactly?

So until some organisation big enough comes along to offer a defacto
implementation that everybody will take reference from, expect changes
and more changes. This of course is good news for web ui developers -
more jobs stability for everybody! On the flip side, IE7-8-9 will
continue to make a nuisance of themselves.

Are you FireFoxed yet?
Re: Perl and ASP.Net [ In reply to ]
On Apr 27, 2007, at 12:19 AM, Foo JH wrote:

> Boysenberry Payne wrote:
>> One of the draw back that seems to be evident to me as I've looked
>> into the client side frameworks is changes in the code are ought
>> of your control. WIth a purely server side solution it would seem
>> to give the coder the choice to upgrade when there is time, etc.
>> With the 3rd party frameworks they choose when you upgrade.
>> For the more stable solutions this is less of a problem. For the
>> newer technologies I've heard a lot of grumbling about having
>> to recode every time there is an upgrade...
> My take on the current situation on client-side frameworks (AJAX-
> styled?) is that it's a bit wild. We have scriptaculous, prototype,
> yui, rico and more. Each of them do parts of a framework (eg. drag-
> n-drop, controls), but even the concept of a client-side framework
> is kinda hazy. What constitutes a client-side framework exactly?
>
> So until some organisation big enough comes along to offer a
> defacto implementation that everybody will take reference from,
> expect changes and more changes. This of course is good news for
> web ui developers - more jobs stability for everybody! On the flip
> side, IE7-8-9 will continue to make a nuisance of themselves.
>
> Are you FireFoxed yet?

I use FireFox quite a bit now a days, it's the only "cross platform"
browser I can
use that shows up on both PCs and Macs pretty reliably, besides all
of the nifty
debugging tools.

Up until now I've written all of my own JS, to avoid bloat or
unnecessary code
as well as keep my learning curve of new APIs to a minimum.

Until a couple of months ago our product only published to Flash swf
files
so it wasn't even an issue. Just recently, I updated our publisher
to publish to
html also, now JS is a bigger deal.

The reason I haven't just jumped right into using JS frameworks is
partially
bloat, partially issues of propriety, and finally not knowing which
one is
going to offer me what I need.

Its hard enough trying to stay on top of using the right perl module for
the task at hand, and they're all easy to find and study.

Currently, without something like cpan for JS and with most of our
administration
tasks being handled via Actionscript in the client browser I'm
probably going
to take my time and continue writing most of my JS; most of it is
pretty specific
to our publisher's needs anyway, e.g. formatting a page around
predefined
look and feel, JS menu behaviors, cookie warnings, etc...

I don't know what I would do without cpan. I'm surprised other
languages don't
offer the same tech. Perl certainly is a one of a kind phenomena....

Thanks for all of the pointers and feedback. If nothing else I'm
sure I can learn from
technology available in the frameworks already mentioned.


Boysenberry Payne
boysenberry@habitatlife.com
Re: Perl and ASP.Net [ In reply to ]
On Apr 30, 2007, at 2:47 PM, Boysenberry Payne wrote:
>

> Currently, without something like cpan for JS and with most of our
> administration
> tasks being handled via Actionscript in the client browser I'm
> probably going
> to take my time and continue writing most of my JS; most of it is
> pretty specific
> to our publisher's needs anyway, e.g. formatting a page around
> predefined
> look and feel, JS menu behaviors, cookie warnings, etc...
>
> I don't know what I would do without cpan. I'm surprised other
> languages don't
> offer the same tech. Perl certainly is a one of a kind phenomena....
>
> Thanks for all of the pointers and feedback. If nothing else I'm
> sure I can learn from
> technology available in the frameworks already mentioned.


well JS has JSAN

http://www.openjsan.org/

it was getting a lot of momentum about a year ago, then just kinda
dropped off.

php has pecl & pear. python has cheeseshop. i think ruby has one
now too.
Perl and ASP.Net [ In reply to ]
Thanks everyone for their inputs. I still think we can learn a few things from .Net design - not everything Microsoft produces is junk :)

That said, has anyone on this list ever tried PerlNet (http://aspn.activestate.com/ASPN/docs/PerlDevKit) from ActiveState? Good/Bad ?
Fine Prints?



- Praveen