Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Prettier Perl websites

by sri (Vicar)
on Nov 03, 2008 at 14:15 UTC ( #721101=perlmeditation: print w/ replies, xml ) Need Help??

One of Perl's biggest problems atm is public perception.


Comment on Prettier Perl websites
Re: Prettier Perl websites
by moritz (Cardinal) on Nov 03, 2008 at 14:33 UTC
    I like the idea of making perl websites prettier (for example looks rather old-fashioned), but most of all they should be usable.



      The animations are just a few seconds long, do you think it's worth using flash just so you can seek and pause?
      Until we have HTML5 and the <video> tag, gif animations are the right choice for this specific problem imo.
        You can use plain HTML + optional javascript.

        You can just provide a log of the session, and if javascript is enabled, turn that into an animation. If not, it stays normal text. Readable and copy&paste-able.

        (update: my first formulation was harsher than intended. I meant no offense, and made it constructive now...)

        I find it extremely annoying to have to wait and watch the animation to see the command I need to type :\

        I do realize that there may be documentation elsewhere and if that is true then is there even a need for the animations?

        The rest looks nice though. (",)

        I'm so adjective, I verb nouns!

        chomp; # nom nom nom

Re: Prettier Perl websites
by Anonymous Monk on Nov 04, 2008 at 03:34 UTC

    What is the purpose? Who is target audience?

Re: Prettier Perl websites
by Sixtease (Friar) on Nov 04, 2008 at 07:38 UTC

    Great effort, brother! Keep it up, so we can see more Perl on web servers.

Re: Prettier Perl websites
by binf-jw (Monk) on Nov 04, 2008 at 16:51 UTC
    I've got to build a web interface for a database in the coming months and will keep this in mind.
    I've used CGI in the past but I can never make it look as nice as I like ( Me being crap not CGI ). I was even tempted to switch to a Java Applet for the coming project but this API may just persuaded me to stay with perl.


      I'm still at the CGI end at the moment. Want to move onto mod_perl soon though

      I've used CGI::FormBuilder combined with TT2 successfully. You could look at HTML::Template as well.

      I attempt to separate content from markup from style from processing and use stylesheets for style, TT2 to display content and markup and CGI::FormBuilder to specify and process the content where applicable.

      Not sure where that is in the MVC world - not sure I have got *there* yet - but I'll agree the mojolicious site has some prettiness to it. However, there is no reason why a site can't be pretty when the processing is done with Perl. After all, the styling is in the CSS not the CGI.

      I think it is more of an attitude about what a site *should* look like and also audience attitude. My first impression of mojolicious is that of dumbing-down - not saying the site does that by any means - just that is my first impression. That is my personal reaction to mojolicious genre of styling out there but then I came to interpret a different style of site as informative.

Re: Prettier Perl websites
by EvanCarroll (Chaplain) on Nov 04, 2008 at 19:32 UTC





    Evan Carroll
    I hack for the ladies.
      Mojo is not about dispatching at all, Mojolicious is just an example of whats possible with Mojo. The web is a moving target, things need to move forward, bi-directional HTTP is happening. What Mojo provides is a replacement for the ancient and RFC ignoring modules Catalyst was built upon, we are ready for Comet and WebSocket for example.

      I actually asked the Catalyst developers to join the Mojo project and be the first framework to use it, they couldn't make a decision. But i needed a good example framework fast, so Mojolicious was born and i'm exploring new techniques with it now...

      Nothing in Mojo will keep you from using Moose, want to build Moose on Rails? Just do it! Mojo is plain old OO Perl, no more no less.

        Evan Carroll
        I hack for the ladies.
Re: Prettier Perl websites
by Erez (Curate) on Nov 05, 2008 at 11:02 UTC

    One thing I always liked to say about Perl-based services/sites, is that they, like Perl (and the Camel) are "Ugly, but efficient". No one could say or slashdot were the "flashiest" around, but it didn't detract from their functionality, or success. In fact,' new coat of paint doesn't disguise the fact that despite an entire site/codebase overhaul, the actual service remains about the same, with very little actually added to it.

    Now, I may claim that RoR-based sites are not that "Flashy" which is in the eyes of the beholder, but I might not be alone in claiming that the more-successful services, like myspace or facebook are there not because of eye candy, but because of other things (not to mention highly-successful, yet visually-atrocious sites).

    These days, I believe "flashy" is being (slowly) replaced by "clean, clear, and cool". Either way, it's nothing to do with the underlying framework. You can do ugly in any language.

    We have nothing to lose but our metaphors.

Re: Prettier Perl websites
by gloryhack (Deacon) on Nov 14, 2008 at 12:42 UTC
    Ruby and PHP are easier for designers to learn and give them their first successes quickly. That's why they have prettier web sites in front of them. Maypole, Catalyst/Catamoose/Cata-what-have-you, Jifty, Mojo, or any other Perl framework you might be building next month are not going to make Perl more accessible to the brains of designers or give them their first successes anywhere near as quickly as Rails or PHP.

    If I were going to try to get Perl into that niche, I'd think more in the direction of pushing something like Template to the point at which it can do everything a designer might want (database connections, sending email, etc.) without any need of serious Perl knowledge. Maybe from there the designers could be lured into learning Perl to do more serious stuff than the extended Template would be capable of. But the extended Template would have to be every bit as simple as Rails to get them that first success quickly.

    It ain't about how pretty a Perl "website" [sic] might be. The pretty comes from the designers, not the language.

Re: Prettier Perl websites
by Iphigenie (Initiate) on Dec 14, 2008 at 17:27 UTC

    Having worked with designers, I can say it doesn't matter which language is easier to learn, because most don't learn it in depth, they just dabble. What matters when building either complex web applications or CMS-based websites is how efficient you can make the workflow between developers (back end) and designers (and front end developers). And that means the interface between the two, which is usually the view, the templating system. How easy it is for a confident designer to get to grips with it to achieve what he wants, to look at an existing template and modify it for a new design, a new section, or some ajax interactions.

    And perl is let down on that front by hugely powerful but hugely cryptic languages.

    I have written several frameworks, CMSes and ecommerce systems, and have come in as team leader, division head, CTO in several companies. I am no super expert but I consider myself pretty savvy in about 5 or 6 languages, and because I have an interest I dabble in a lot of frameworks, CMSes and app engines. And I have as a result built things (or made people build things) in dozens of different templating languages.

    But I still remember in 2004 looking at the code for RT2 (we were using RT1 at the time, heavily reskinned to look like we wanted to), looking at the templates to evaluate how easy it would be for our designers to reskin. It was a shock, since I couldnt figure out how I would start to reskin it myself, let alone get even my most tolerant-of-in-development-trial-and-error designer to get to grips with it (and this would be the guy that managed to make plone not look like plone!).

    Get the right kind of templating (both the code itself and the architecture) and your designer can do a lot of work and logic on their own, without needing a developer's involvement. This means that your designer and developer can sit down, play with wireframes, agree on data structures and parameter names, and start working in parallel.

    Most often when I came in a company which used perl, I would find that most front end changes were done by the developers. The designer(s) would create mockups and HTML, and the developers would then plug the code in, and make templates. They would also do all changes to the templates. This is hugely inefficient, it makes the devs into double bottlenecks, and is frustrating to everyone involved.

    Why does it happen? Because the most powerful and common templating options on Perl are meant for developers, and the result is developers doing the templates. Yes, it allows for all sorts of shortcuts and efficiencies from a developer's point of view, but it also doesn't help really good separation of concerns.

    And I am afraid that means that a designer downloading a perl based app, cms, or framework and trying to get to grips with it might get put off right away when they look at the templates (and yes, they look at the first, because once the basics are in place that is where they expect to spend all their time, on an admin screen and in templates). To get some of these people to come and play with us we must not worry about the language itself or the modules and frameworks - we need to start with the templates.

    Iphigenie aka Joelle Nebbe-Mornod




      Cheers Rolf

Re: Prettier Perl websites
by james2vegas (Chaplain) on Aug 03, 2009 at 16:28 UTC
    Not sure what the advantage this has over CGI::Application + (Mojolicious has over) CGI::Application::Dispatch, but then I don't see what advantage Catalyst has over that either (Catalyst is getting all the 'Modern Perl' hype, along with Moose). Mojo does seem to have the advantage over Catalyst in terms of weight and speed, though (though apparently dependencies aren't bad, they say).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://721101]
Approved by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (10)
As of 2014-12-27 16:49 GMT
Find Nodes?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?

    Results (177 votes), past polls