Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Perl & Templating for a mobile future.

by punch_card_don (Curate)
on Jan 15, 2013 at 19:42 UTC ( #1013450=perlquestion: print w/replies, xml ) Need Help??

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

Mellifluous Monks,

Been gone a while, but back with a green-field website development project:

desktop website design providing future mobile delivery groundwork preparation

We are to define the design framework for a new website from the ground up for delivery on desktops - which currently accounts for 90% of users. But, knowing that mobile users will increase, we want to lay the groundwork for mobile delivery not too far away. That is, design the desktop version so that a mobile version can be built later without havng to start from scratch again.

What's this got to do with Perl?

Our favourite framework is for dynamic websites. LAMP stack, and Template Toolkit. So our first instinct is to strip out content into separate files with semantic markup or a database, detect the browser or device, and dynamically serve the content in a custom template with appropriate css and javascript.


Then you get all caught up in Graceful Degradation and Progressive Enhancement and Responsive Web Design.....and suddenly the place of server-side page assembly seems in doubt. And yet - as an old server-side coder - I find myself suspecting that the reliability of server-side dynamic generation, while not "hip" or sexy anymore, is still our friend.

Note that I am talking about what might be called a "document site" - that is, not a web application - just information delivery. And lots of it - so a fairly complex and deep navigation structure.

So, if there's a question in there, I guess it's: Has Perl, or server-side processing in general, responded to the emerging mobile delivery question? Has browser or device detection through headers become any more reliable than it used to be? Is there a place for such approaches in a RWD world?


Time flies like an arrow. Fruit flies like a banana.

Replies are listed 'Best First'.
Re: Perl & Templating for a mobile future.
by Your Mother (Archbishop) on Jan 16, 2013 at 03:05 UTC

    Semantic, modern mark-up. Text::Xslate is about a bazillion times faster than TT2 and is extensible and speaks TT pretty well if you like that syntax. Small, semantic bites of templates so that content is not required to be in large batches but can included or not in the batch size that's relevant or in the user prefs for that matter. (mem)Caching for output (where they don't contain logged-in/user-specific data). DO NOT detect browsers! It was always a mistake and will always be a mistake because it ties your code to the minor version changes of 4–10 browsers. Detect capabilities (see modernizr for example)--exploit known problems in CSS parsing and such--and suggest options when discovered. Someone comes to with a screen width of 480px -- you can suggest (and remember, don't keep asking) they switch to or or whatever and let them choose.

    It's a mistake to attempt to use client side hacking to fix the site. Phones and pads are fast now yes, but not so fast that they need 1,000 times the download bits to use the 10% of relevant markup and includes and that bandwidth generally costs a lot more on mobile. Run apps on Plack + uWSGI. Because you mentioned LAMP: Not apache, probably nginx. Not MySQL, probably Pg and client side storage/SQLite where relevant. And maybe not even Linux. Just saying, OpenBSD and OpenIndiana and others exist. Think about your particular problem space and what ongoing sysadmin overhead will look like and what the history of support and bugfixing/security has been before you shop for an operating system.

    There was an excellent write-up somewhere about how github does content with object caching and fetching and generation but I can't find it. :\

    Have fun! You're actually in a really lucky, if confusing and maddeningly open, place right now. Tests will save you from your own design mistakes as much as code mistakes too. Get them in as soon as specs are done. Costs 2x up front but will save... who knows? 100x during the life of any app that outlasts its creators.

    Update: PhoneGap and friends will make a full on mobile app (with access to the hardware) pretty easy if you do the content (html/JS) stuff right.

      Very interesting positions, thanks.

      Detect capabilities (see modernizr for example)

      Excellent library - but, then, I'm right back into client-side processing, or "client side hacking to fix the site". Plus, this is meant as a Progressive Enhancement tool to discover device capabilities for CSS3 capability-dependent stylesheets.

      I know, I know - browser detection sucks big time. Was hoping it had gotten better. 'Cause good browser sniffing and a capabilities database would mean we coudl do all that modernizr stuff server-side, which would be the dream.

      But I will definitely investigate Text::Xslate.


      Time flies like an arrow. Fruit flies like a banana.

      Everything you ever say I agree with.

      Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

        Well, that's just because you're so handsome and capable. :P

Re: Perl & Templating for a mobile future.
by CountZero (Bishop) on Jan 15, 2013 at 20:24 UTC
    Just to open the discussion.

    I see that many websites offer the "classical" site for the usual PC/laptop/netbook browsers at say "" and mobile devices optimized versions at "" or "" or such. Is this due to lack of reliable browser recognition? Or is it lack of knowledge from their programmers and web-designers?

    I have also seen sites that have a button saying something like "On a mobile device? Click here" and then you are shown a mobile device optimized web-page at the same URL (they probably store a cookie on your site to make sure to send you the right version). Again this makes me doubt the reliability of recognizing the kind of device you are using to view the website.

    In theory, just switching the CSS might be sufficient to be able to switch between a "normal" and "mobile" version, but alas proper use of CSS is even less common than properly written HTML. CSS 2.1 has rules for different media types, one of which is "handheld".


    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
      I see that many websites offer the "classical" site for the usual PC/laptop/netbook browsers at say "" and mobile devices optimized versions at "" or "" or such. Is this due to lack of reliable browser recognition? Or is it lack of knowledge from their programmers and web-designers?

      This is an old strategy. Rudimentary device/browser detection and two completely separate websites, one for pc and one for mobile. Nightmarish for content management - essentially two parllel sites to maintain. Plus, administrators would strip down the pc site for mobile, meaning mobile users got a crappy, incomplete version of the site.

      Objective today is to provide as close to the same content as possible on both. And to have as little duplication as possible. These were the objectives of approaches like Progressive Enhanvcement and Responsive Design. But those move sooooooo much processing to the client side. I'm already seeing articles announcing the death of Progressive Enhancement.

      I figure a good compromise that optimizes the balance between the solid footing of server-side processing, minimal duplication, and unlimited custom formatting for devices is good old Templating and dynamic generation. Serve it all prep'd and don't rely on the device too much.

      But, then sniffing is key.

      Or - the Perl world has developed a much better idea, and I'd looooove to read about it.

      Time flies like an arrow. Fruit flies like a banana.
Re: Perl & Templating for a mobile future.
by sundialsvc4 (Abbot) on Jan 15, 2013 at 21:22 UTC

    I recommend that you immediately do a search of the existing technology vendors who are already able to produce mobile-apps more or less automatically now.   (Much as there are well-established web site vendors who can produce mobile-friendly web sites, even at zero cost.)   Of course it depends upon the app, but if the purpose of the app is relatively similar to the present-day purpose of a web site, an app sometimes can be generated!   What I am saying is ... don’t jump to any conclusion about anything or any of your choices based on know-how that is even two years old.   Things are evolving that fast.

    Nevertheless ... you need to begin this thing with a truly all-inclusive project plan.   You need to build the whole ball-of-wax scenario and then break that down into manageable steps.   Yes, Perl certainly can do everything that you want on the back-end.   Yes, the templating engine and so-on that you have mentioned are industrial-grade enough to get the job done.   All the plumbing parts you’ll need are there.   But that’s not the pressing design question you now face.

    The things you “knew,” even about web sites?   Fuhgeddaboudit.   Do you think they’re going to just be accessing your web-site through a mobile vs. a standard browser?   Bah.   This is not just a new world ... it’s a new world.   Since you are embarking on a completely new venture, it is now profoundly important that you make the right decisions ... and your past experiences have virtually nothing to do with that.   I don’t think this can be emphasized enough.

Re: Perl & Templating for a mobile future.
by sundialsvc4 (Abbot) on Jan 16, 2013 at 17:08 UTC

    The first thing that I would do is to research both mobile-frameworks and generate-your-own- mobile-app- without-writing- code sites ... which do exist already.   Find out which APIs they use and plan from the start that your site must expose, and should therefore also itself use(!), that API.

    Your project, therefore, is going to initially consist of two loosely-coupled programs.   The first is the API-driven core.   The second is a web-page front end, which also supports browser-detection.   Use an existing framework of some kind to build this part.   In the future, the mobile apps will constitute another front-end.

    The fly in this ointment is that you basically have to design all three parts now ... the core, the web front-end, and the mobile app or apps.   Furthermore, since you can correctly guess that you really can’t afford to plan to write for iOS + Android + who-knows-maybe Windows, you have to find a way to auto-generate that part.   And you’d really like to find a way to auto-generate all of the front-end parts, all at the same time ... which, in fact, you now can.

    Absolutely anything-and-everything that can be commoditized, is being commoditized.   No one can completely commoditize whatever-it-is that the back-end “guts” of your server is doing, of course, but there are dramatic reductions in the costs associated of doing the stuff that front-faces the user.   Since this is a green-field situation, you absolutely must make the most far-reaching decisions now.   Start with pure-research, and set aside the notion that Perl is going to be front-and-center of what you do.   It will, and still should, be the primary host-side tool.   But it might not be the tool that is “driving the bus” of this project as-a-whole.   Your traditional ways of thinking need to be upturned with this new apple-cart, without losing your senses or jumping off the cliff because you haven’t spotted where the bridge just moved-to.   To me, it’s kinda like those ads that Karras Negotiating has been running lately in all those in-flight mags:   Re-examine .. everything.

    I’m very much in the process of helping several clients do that right now, and it’s one heck of a ... o_O ... ride.   “omg, the world is totally-changing all over again.”   What a crazy way we all picked to make a livin’.   I guess we’ve all got a choice between being terrified and being excited.   I pick door number two.

Re: Perl & Templating for a mobile future.
by gnosti (Hermit) on Jan 16, 2013 at 19:02 UTC
    I've heard of CSS/jquery code, such as Twitter Bootstrap, which claim to adjust formatting to suit mobile devices. Perhaps someone with more knowledge can comment if they could help meet the OP's needs.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1013450]
Approved by Corion
Front-paged by CountZero
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2021-01-21 09:05 GMT
Find Nodes?
    Voting Booth?