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 example.com with a screen width of 480px -- you can suggest (and remember, don't keep asking) they switch to example.mobi or m.expample.com 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.

Thanks.




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

I see that many websites offer the "classical" site for the usual PC/laptop/netbook browsers at say "www.XYZ.com" and mobile devices optimized versions at "m.XYZ.com" or "mob.XYZ.com" 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".

I see that many websites offer the "classical" site for the usual PC/laptop/netbook browsers at say "www.XYZ.com" and mobile devices optimized versions at "m.XYZ.com" or "mob.XYZ.com" 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.

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.

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.