http://www.perlmonks.org?node_id=721101

One of Perl's biggest problems atm is public perception.
Ruby seems to have exclusive rights for flashy websites, so for Mojo we've tried to break the cycle.
Maybe it inspires other Perl projects too and we can start a new trend of prettier Perl websites.

http://mojolicious.org

Update: Note that this a marketing website, it serves no documentation purposes. (some commenters might have misunderstood this)
Update2: Don't explain what you think would look better, just make a mockup and show us!

Replies are listed 'Best First'.
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 http://perl.org/ looks rather old-fashioned), but most of all they should be usable.

    While I do appreciate your effort, I don't think that the way to go are animations that stop and reset as soon as the mouse leaves the area. It's not what I call usable. (When the animation isn't fast enough for me, I scroll a bit down to see what else is on the page, and immediately regret it as it is now).

    <general_rant>IMHO far too many designers (and programmers) sacrifice usability for fancy designs and animations. I believe that it's not impossible to have a site that's both usable and fancy, and so I post variations of this rant in every place where somebody might care </general_rant>

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

    use strict; use warnings; print "Just Another Perl Hacker\n";
Re: Prettier Perl websites
by Erez (Priest) 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 del.icio.us or slashdot were the "flashiest" around, but it didn't detract from their functionality, or success. In fact, del.icio.us' 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.

    Stop saying 'script'. Stop saying 'line-noise'.
    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

    (PS: people diss HTML::Template because it is not as powerful, but HTML::Template with custom expressions is more empowering of a normal designer than the Mason / TT can be. Although the best option for me remains Petal. I wish someone would port Kid to perl)

      (PS: people diss HTML::Template because it is not as powerful, but HTML::Template with custom expressions is more empowering of a normal designer than the Mason / TT can be. Although the best option for me remains Petal. I wish someone would port Kid to perl)

      I'm curious, what do you think about HTML::Template::Compiled ? 8)

      Cheers Rolf

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

    I'd probably be the most easy to convince that Catalyst should be replaced with Mojolicious so long as you can provide the valid argument for it. I have yet to see why your method of dispatch is better -- than say chained-dispatch. Or, where your design diverges from Catalyst other than dispatch component. I'd love to see you and the more zealous maintainers of Catalyst hash out ideas on paper. I think what you're really doing is brining in the hype component to Catalyst, which is arguably what it needs most. But, why alienate people that are currently using Catalyst?

    Catalyst already has the basic generators, which I don't use, that seem to be the center of your argument on simplicity.. I've always preferred to just cp rather than using generators.

    I have a tendency to think Moose is *always* good. I'd love to see why you're making a new modular framework without using it... I think when Cat 6 comes out and finally uses Moose internally many good Moosey things will come.

    Mojo::Manual::CodingGuidelines are kind of vague, and certainly aren't unique. Maybe the core of my argument rests in not seeing the problem with Catalyst that you're trying to address. Please convince me -- my ears are open.


    Evan Carroll
    I hack for the ladies.
    www.EvanCarroll.com
      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.
        I don't know anything about Comet or WebSocket, and the mojolicious homepage doesn't target these sales points at all. In conclusion mojolicious.org is not targeting me -- the early adopter type who *already* uses an mvc framework that he is fairly happy with, not to say I couldn't be more happy with Mojolicious. Instead you're doing what everyone is still doing by trying to target the dwindling audience of PHP users. That's what I see as the fault here. Your homepage is not noticeably different from any other mvc framework with generators.
        No offense, lets examine my thought process as I traverse through your features:
        * Full stack HTTP 1.1 client/server implementation (nothing new. s +ales point in 2003). * Builtin async io and prefork servers (cough?? explain.). * CGI and FastCGI support (nothing new. Catalyst too). * Code generators (Catalyst too. expired sales point in 2003). * Very clean object oriented API (Catalyst too. subjective). * Pure Perl (at best a moot point) without any hidden magic (which + is what everyone claims). * Example MVC web framework (Catalst, Maypole, Jifty et al?) named + Mojolicious (the name has no bearing) (aka. Perl on Rails).


        Evan Carroll
        I hack for the ladies.
        www.EvanCarroll.com
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.

    ++
    John,

      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 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).
Re: Prettier Perl websites
by Anonymous Monk on Nov 04, 2008 at 03:34 UTC
    Update2: Don't explain what you think would look better, just make a mockup and show us!

    What is the purpose? Who is target audience?