In January, I interviewed Kyle Simpson on Episode 4 the ATX Web Show. We discussed Web Performance and Google’s plan to “Make the Web Faster”. Since then, Google has announced they will start rewarding your site’s page speed. And in their Webmaster Tools they hint that the bar is set at ~1.4 seconds.

80% of the time users wait for a web page is because of the frontend.

I was sort of thunderstruck with fear. Although we always strive for better, I typically found a 3-5 second page load great and up to 7 seconds acceptable. After recording the show, I stayed up a few hours that night fiddling with The ATX Web Show and increased site performance by ~500%¹.

Since seeing those results, I only think about Web Optimization. I see the web in milliseconds now. If you’re like me and never considered optimization a necessity maybe now is the time to re-evaluate that. And don’t act like this isn’t your problem because 80% of the time users wait for a webpage is because of the frontend². The goal isn’t to fit under some imaginary kilobyte threshold, the goal is to make sure that everything is as small as possible. Reduce Filesizes, Reduce Requests, and Enable Caching.

5 Steps to a Faster Website

I documented the steps I took to increase my YSlow and Page Speed grades without getting into costly CDNs and such. A lot of sites will tell you to just install a cache plugin. And while you should do that (see Step 5), it’s important to do that after you’ve optimized or else you’re just polishing a turd, curing a symptom not the disease, putting lipstick on a pig or whatever analogy you want to use. Very little of this is WordPress specific so even you dweebs on Expression Engine can optimize your sites.

Step 1: Minify & Optimize Your CSS

This is just a 3 step process and it’s here that I saw the majority of the site’s weight drop off. There’s about a 10% chance you’ll break something here. If you’re uncomfortable take it slow, line by line, and refresh a lot.

Minify CSS

Open up Page Speed and click “Analyze Performance”. Find the section titled “Minify CSS”. You will see download links for optimized versions of every CSS file your page calls. Replace your bloated CSS with this.

For WordPress, you’ll have to keep the theme declaration block at the top.

Unfortunately in the case of WordPress, most blogs rely on plugins which load their own assets that are rarely optimized. You may have to overwrite the CSS in some plugins. In a perfect world, WordPress plugins would come with pre-optimized assets.

This is maybe not advisable, but I hack into plugins and comment out the CSS and Javascripts they load. I’d rather write my own CSS. Be prepared to do this after every plugin update.

Learning Point: Don’t Over Qualify. Use Efficient CSS Selectors.

I always assumed it was best practice to be explicit when writing CSS, but I was wrong. It’s called “Over Qualifying” and it’s more work for your browser to sort out. Unique classes and unique elements will win in the speed game.

  #header nav ul li a { ... }
  /* bad. 5 selectors is way too many. */

  ul.commentlist { ... }
  /* bad. too conjoined. */

  #header a { ... }
  /* better. more direct. really nice. */

  .commentlist { ... }
  /* better. just the class selector should be specific enough. more agile too.*/

I covered this briefly, but Chris Coyier of CSS-Tricks has a great write up on Efficiently Rendering CSS.

Step 2: Smush & Optimize Images

Your images are too fat. Photoshop’s “Save for Web” is actually pretty good at optimizing, but there’s room for more. Your images have huge amounts of useless metadata that can be stripped out. This couldn’t be easier to fix. Here are some tools to smush your images.

1. Page Speed gives you a lossless smushed version of each image that can be optimized! Save As… and upload.
2. YSlow > Tools > All Smush.it – this will batch shrink the images on the page and maintain folder structure. It’s unbelievably convenient.
3. ImageOptim is a great offline tool (for Mac) that you can batch run whole directories with. Any image you upload to the internet should go through this before you upload from now on.

Sometimes you’ll see that you’re only saving 400B and you may think “What’s the point?” Pay attention to percentages. If an image can be 9% smaller, that means your users will get that image ~9% faster! Math.

Be sure you make backups before you replace images or smush whole directories, just in case.

If you use Adobe RGB color profiles for your images, some optimizers strip out the profile leaving you with a desaturated image. The Adobe RGB profile adds ~50KB+ and is intended for print. Use sRGB instead.

Serve Properly Scaled Images

This is pretty elementary. Where you can, serve a 200x200px wide image instead of scaling down a 400x400px wide image to 200x200px. Larger images take longer to download and resizing takes longer to render in browser.

Specify Image Dimensions

I had grown accustom being non-committal about image dimensions, but Page Speed recommends that you specify image height and width because it’s less for the browser to sort out. It gives you the rendered dimensions and you add that to your <img> tags. Total time spent completing task: 2 minutes.

SpriteMe

Use sprites. Spend some time and figure it out. It can reduce tons on HTTP Requests and make your site even faster. Google performance guru, Steve Souders, created a tool called SpriteMe that does this for you. Install the bookmarklet, and click it on your homepage, then it’ll do the rest of the work. It will pack up your sprited images, and give you some CSS to replace in your stylesheet. Skills Required: Math.

Step 3: Minify & Optimize JS

Just like CSS, Page Speed gives download links for minified versions of your javascript right there in the window. Grab the minified versions and drop them in your site. There’s, again, a 10% chance you’ll break something, but just take it slow and refresh often. And again, you might have break into plugins and comment out their swill.

One JS Library to Rule Them All.

If you’re loading in jQuery, Mootools, and Prototype, you’re doing something wrong. These libraries have a lot of functional overlap so you’re basically repeating yourself over and over and wasting tons of bandwidth. Have a good hard look at your plugin stack. Find out which plugins are loading what library (use paper if you have to) and try to target a single library (*ahem* jQuery *ahem*). Search for alternative plugins that use the your library of choice.

Step 4: Enable Browser Cache & GZIP in Apache with .htaccess

This took me a long time to master. I was ignorant to its proper implementation, I googled around and found a few good resources.³ If you’re on Apache (you probably are), add the following to your .htaccess file after your WordPress rules. If it’s all gibberish to you, that’s fine. Basically it does the following:

1. Detects mod_deflate and GZIPs various mime types.
2. Detects mod_expires and sets an expiration date for each type of asset.
3. Detects mod_headers and sets Browser Cache age limits for your assets.

I’ve used this on about a dozen sites on a handful of hosts and had no problem. It will simply ignore what it can’t support. If you see improvements, please comment over at GitHub.

Step 5: WordPress Plugins for Performance

Here are some plugins to install on our final step on the way to Web Performant WordPress. Like I said at the top of the article, don’t rely on plugins to fix your sloppy code and your poor craftsmanship. Your site needs good bones. And your client deserves at least that.

WP Minify

WP Minify is a great plugin that will combine and minify all your javascript files or all your CSS files. Basically, everything I told you to do in Steps 1 and 3. If you’re lazy and skipped that section and just came here, I’m sad for your clients.

I’ve found this great for serving minified CSS that I had to keep human readable in the theme. As far as Javascript goes, it could be my problem but, I’ve never had a plugin successfully combine scripts and have them all still working in the end. Try it! If you’re able to squeeze all your javascript into one file successfully, I applaud you.

WP Super Cache

Now that your site is optimized, you’ll notice on your page load waterfall one of the longest part of your load is probably the first blue line, your HTML. This is because your site is taking a huge roundtrip:

Client Request → WordPress Server → Database → WordPress Server → Client

Turning on caching will take out that trip to the database.

Client Request → WordPress Server → Client

FASTER! It actually does quite a bit more but this is the simplified explanation.

I’ve found WP Super Cache to be wonderful for this and I highly recommend it. It’s a bit of a pain to install as you have to grant temporary permission to some directories to write, add a line to your wp-config.php, and then add some more to your .htaccess. There’s a 30% chance you’ll whitescreen your WordPress install, but just follow the directions and the end result is once you turn it on your visitors will be served HTML in milliseconds.

Disclaimer: Most of these stats are from Luke Wroblewski http://www.lukew.com/ff/entry.asp?933

Design & Development on the Mobile Web

I usually don’t usually sit around and ponder “The Mobile Web”, but about two weeks ago I accidentally inundated myself with multiple talks about it from two separate podcasts. Because of that, the Mobile Web has a growing market share in my brain space.

First was John Resig on yayQuery and second was Luke Wroblewski on The Big Web Show. I encourage you to tune in and listen to each of these episodes, although each episode leans towards a different end of the Design/Development spectrum they combine to help paint a larger picture of the challenges and limitations of the mobile web.

I should state upfront that I’m not going to propose any solutions or announce a new biz-dev-mobile-social-strategy on behalf of Paravel. If we had it my way, the whole world would convert to Webkit and we’d be mostly done with all the cross browser crap, but that’s not reality. I just want to share a mini-roundup of what my mindgrapes are soaking in.

The Design Point of View

Episode 6 of The Big Web Show is a must listen. Luke Wroblewski shares his “Mobile First” mantra, which is the idea that if you design for the mobile platform first, you can end up with a superior product.

In terms of design, the mobile web presents us with some challenging limitations:

Size Matters

Designing a website on 1024×768 is completely different than designing on 320×480. And now with the iPhone 4 in the mix, there’s a rogue 960×640 resolution floating around… and that’s just iPhones. Devices vary in dimensions and although devices are squeezing more and more pixels in the screen there’s still limited real estate.

Touch

Touch brings about a few design challenges. Most importantly is the lack of :hover. Avoid relying heavily on :hover. Fat fingers are less accurate than 1px mouse pointers so things that are clickable need to be big, occupying more precious real estate. While touch-interfaces are gaining popularity, the majority of smartphones are non-touch.

Gestures and Multitouch

In terms of interface design, there’s the added issue of multitouch versus non-multitouch. Gestures for each touch-enabled platform are different. On iPhone you tap and squeeze and swipe, on WebOS you fling, on Android you have some menu buttons in the mix. For more information, read Luke Wroblewski’s report on Multitouch Gestures.

Limited Bandwidth

If a mobile user waits too long, they will hit the BACK button and you lose them forever. Limited mobile bandwidth sends us back to the days where every kilobyte counts. Any website, especially a mobile version, needs to be lightweight and heavily optimized. Be fast by default.

Limited Battery Life

Almost a development concern, but it should be noted HTTP Requests are the biggest cause for battery drain. And since caching on mobile is minimal at best, you will likely load assets each page load. Designs should bear this in mind and be lightweight.

When you design for mobile, you are immediately faced with the challenges of ripping out all the stuff that doesn’t matter and forced to provide the most basic actions. Although a daunting task, there’s an optimistic side. As mentioned in the podcast, the mobile versions of some big websites (Facebook for iPhone, Flickr, GoDaddy) are actually better than their giant counterparts because they offer a simplified user experience. So in someways, it’s a designer’s dream to be able to put their foot down and say “No, I will not make the logo bigger” because it can’t possibly be done.

There’s a financial incentive, too. As shown by the facts at the top of this article, there’s an ever increasing demand for mobile-compatible interfaces. This means that you have legitimate reasons to charge for such services. Mobile sites and native mobile apps are fast becoming a separate portal to businesses worldwide.

I am of the optimistic mindset that any good designer likes to design. And good designers can design well even if given limitations like that of the mobile web. The mobile web gives designers an exciting new horizon and potentially lucrative field to begin targeting their pixels with.

The Developer Point of View

When John Resig, creator of jQuery, stopped by the yayQuery podcast I thought it was going to be better than freebasing crushed Fruit Loops. Although it was a great show, my delight was turned into a the world’s saddest sadface as Resig shared the ruthless, cold-hard facts about mobile development. You need to watch and listen yourself, and have your own private FML moment.

The Mobile Web IS NOT just the iPhone. Depending on who you talk to, there are around 15-21 browsers that are in need of active support. In its simplified form there are 8 major browser platforms with each of them having multiple browser versions with differing capabilities, differing Javascript support, and different caching methods or no caching at all. This is so much worse than the IE6 problem, it’s like having 15 IEs.

Information about these browsers is difficult to gather. Peter-Paul Koch ran some comprehensive tests on CSS and Javascript support. Resig wrote a nice summary of PPK’s behavior research over at his blog, this is the best place on the internet to start learning about the various mobile browsers.

It’s sobering to know your future enemy: twice as many major browsers, fractured browser share, unknown/poorly documented support, and the list goes on. Not to mention, the most important part of developing for a mobile device is actually holding it in your hands and seeing how it feels, interacts and responds.

There is some hope. There are native application compilers like PhoneGap and Appcelerator Titanium which will take your HTML/CSS/JS and build native apps for most of the major platforms. I’ve heard nothing but good things and much excitement from developers using those platforms. Also, the yet-to-be-released jQuery Mobile will help solve some of the browser inconsistencies. So although there’s a light at the end of the tunnel, it’s a hard uphill road up ahead.

Facepalm, Mobile Web.

Like I said at the top of the article, I wish the whole world was Webkit, it would solve a lot of problems. I’d even suggest setting a new standard for the word “smartphone” using the 2G iPhone as the base standard since it was the original game changer. All other phones would be “dumbphones”. But I dream a dream.

As far as the mobile web is concerned here in the now, I unbiasedly do believe that developing towards the Webkit (iOS, Android, and future Blackberry) platform is the safest bet as it’s one of the fastest growing markets and possesses the least amount of HTML/CSS support headaches. It’s important to note, however, that webkit browsers are not the dominant browser so be prepared for your mobile site to degrade and still have to function on your boss’ old Blackberry.

The Code

The theme was built from Starkers HTML5 by Elliot Jay Stocks. I love this theme. It’s so semantic and so simple. I went with HTML5 not because it possesses some HTML super powers, but because it’s fun. And I’ll let javascript wizards like Remy Sharp and Paul Irish solve older browser compatibility problems for me.

The CSS is based on The 960 Grid. 30+ sites or so later and it hasn’t let me down yet. That was a no-brainer.

My cohort, Trent Walton, has a really nice blog and is also insatiable when it comes to making things perfect. Trent was over and over encouraging me to keep maintenance mode ON and tweak it more. If something didn’t feel right or wasn’t working, Trent’s keen eye had something to say about it. So thanks, Trent for putting up with me and all the long hours of me asking “How about this?… Refresh now…. How ’bout Now?… Now?”

Optimization

Expect a longer (already written!) blog post on this later. But ever since an episode on my podcast, I’ve been obsessed with web performance. So using a lot of Page Speed and Sprite.me and some caching, I crushed this site down to a less than 1s.

I get nosebleeds with how exciting this stuff is. Subscribe to the RSS Feed or follow me to know when that post drops.

Thanks to everyone for the help and feedback. Now off to write more posts. Keep reading, Dear Reader! And whatever you do, don’t get lost. I repeat. Don’t Get Lost

Features

Updated Version 1.0.1

• Now with less deprecated functions!
• Fixed issue with needless expand($args) call.
• Added border-bottom to shots CSS with no-shadow.
• Fixed issue where RSS feed/site rendered invalid because of extra whitespace.

Rebound it!

Naturally, I posted a shot of this on Dribbble. If you use the plugin, why not rebound it with a screenshot and a link to your site. I really enjoy checking out people’s portfolios. Or post a link in the comments. Or both! You decide how much social media wizardry you want to perform.

My biggest lament – no matter how good the video or how impressive the animation – is when I pull up a site with animation and I see my 2 processors max out. My fans kick on. My mouse pointer suddenly disappears. My machine begins to chug and seize.¹

It’s generally understood that assaulting a site visitor with an audio clip when the page loads is a bad user experience practice, but couldn’t the same be said for overloading a processor? If your site demands too much from the client-side, you’re directly affecting the client’s experience. In my own experience, there have been times where I’ve had to turn up my speakers to drown out the sounds of my processor fans just to hear a video.

Flash, Javascript and now CSS animations (even HTML5 web workers) are all client-side technologies that we must use wisely. As a rule of thumb, it’s probably smart to follow the old adage: “Just because you can, doesn’t mean you should.”²

[1] I have a pretty good computer, an early 2009 MacBook Pro / 2.4GHz Intel Core2 Duo / 4GB RAM. It’s no 8 core system with 10GB of RAM though. Make sure you test your fancy new site on an older less-1337 machine.

[2] i.e. Don’t hack together your own video player if you’re not as smart as the YouTube team.

I couldn’t be bothered to track down and fix the bug or even another audio plugin. In a brief “A-Ha!” moment, I thought, “Why not just use HTML5?” So I threw in the brand new HTML5 <audio> tag and…

Instant success! Sure, it’s not the prettiest thing in the world but if the browser is working the magic it’ll never break again and I’m satisfied. I was pretty elated and began thinking about how this would positively impact and speed up a music blog I help run. I was drunk on simplicity.

Firefox #Fail

I remembered that some of my friends still use Firefox as their primary browser so I thought I’d just check the site in Firefox and take a peek at the design of their HTML5 audio player. Unfortunately, all I saw was a big ol’ “X”.

Some quick googling led me to the answer. Firefox’s <audio> tag implementation only supports Ogg Vorbis and WAV. I was shocked and astonished at the fact that a browser as great as Firefox doesn’t support MP3.

The <video> Wars

It appears the problem connected to the same issue the <video> tag is facing: codec licensing issues. This lack of standards issue is raised a lot in the HTML5 vs. Flash debate. I personally don’t care what standard is decided – I only use H.264 because that’s what ships on my Mac – I just want a standard. Although it would be nice if H.264 was the standard and the majority of the web didn’t have to re-encode their videos, I understand that licensing it from Apple could potentially bankrupt Firefox. As inconsequential as this codec thing may seem, this quibble is making HTML5 impotent.

How does the <video> tag make my life better if I have to create 3 different versions of the same video for cross browser support? Answer: none better. It renders it useless.

Unfortunately for Firefox, in reality there’s never going to be a massive shift in the web towards Ogg. Especially if at YouTube, every minute there’s 20 hours of video being uploaded that’s immediately encoded in H.264.

No one uses Ogg Vorbis. The web uses MP3.

The Open Source Utopian Dream is great: a world without restrictive licensing. But when the rubber meets the road, no one is going to spend the time to specially convert audio files to Ogg just so they works in Firefox. In the case of Austin Town Hall, it has (to-date) 1,196 songs on it – all MP3. It would take seconds to create a plugin that would change the current shortcode tag to output HTML5 instead of Flash. However, it would take hours or even days to hunt down, convert, and re-upload to each post in an Ogg format.

I could understand if Firefox chose not to support AAC or M4A, but MP3 however is non-negotiable when it comes to audio. It’s ubiquitous. It’s the established slang term for “digital audio file”. It’s an inseparable part of the web’s history.

The Bottom Line

If Firefox cannot support MP3 in their <audio> tag, it’s as useless as a CD player. If Firefox will not support MP3, one of 2 things will happen. One: HTML5 will remain dead in the water or Two: Firefox will lose browser share bit by bit and eventually go belly up in this episode of the Browser Wars. In the meanwhile, if Firefox cannot license MP3 they should at least be cognizant of the fact the web uses MP3 as its standard and degrade their <audio> tag if the source file is unsupported.

So what can you do? Not much really. It’s a total stalemate. Web developers have to sit around and wait for the working groups to get over themselves and come to consensus. Someone needs to make a website called Write Your WHATWGressman. Then we can let them know that this needs issue to be solved… and FAST!

I’m pretty excited about it. It started as a late night idea then turned into a code binge. Less than 24 hours later it was designed by myself and live. It’s coded in heaps of HTML5 and CSS3. Powerhouse. Once this project gets off the ground I’m certain I’ll be back with my regularly scheduled posts as well as those manifestos I hinted about.

I’ve got a plethora of show ideas, and am now beginning the process of wrangling guests. Pretty difficult for a passive guy like myself.

If you’re interested in being on the show, please contact me! Thanks.

In this, the Dawn of the E-reader, few news agencies are taking action to balance this shift and will be stomped by the upcoming change or at the very least will be painfully out of date. NPR and the New York Times are two “old world” news agencies that are embracing the “new world” distribution method and doing well at it.

The Future of Distribution: NPR

National Public Radio, created in 1970, brings news to the airwaves. Though it may seem futile to look at a radio station as a beacon to guide us into the future, NPR is superseding larger privately funded news organizations in the digital space race. NPR latched on to 2005’s “Year of the Podcast”[1] buzz, and it appears has revolutionized the way they distribute content.

The secret to NPR’s new strategy is tucked into the footer of it’s brand new (and dead sexy) website. Near the bottom, there’s a list of their on demand “broadcasts”:

They have fully understood themselves as a “broadcast” agency. Rather than sticking to their former pre-Internet glory days where they were the “Kings of Talk Radio”, NPR has changed directions. They’ve positioned themselves to say, “We will be in your email, your iPod, your phone, your RSS News Reader, your iGoogle and Blogs, your Facebook applications, and even on your Radio waves.”

They have a distribution model that fits the future. To be on every device that you may possible own. They’re on your iPod, your computer, and in your car. And with strong APIs, they will continue to be on the next big device. You cannot escape them. And they are dependable.

The Future of Distribution: Times Reader from NYTimes



The New York Times has an elegant Adobe Air application available right now for download at http://timesreader.nytimes.com. Once installed, you’re introduced to a drop dead gorgeous facsimile of the NYTimes paper version. The layout is beautiful, resolution-adaptive and interactive.

Times Reader has taken all the new digital inventions of the web and put them in to what will no doubt be the future of newspapers. A Latest News section, brings you breaking up-to-date news. Zoomable photos and micro-galleries can be embedded into every article. A whole section for News in Pictures. News in Video which is a medium impossible for print. As well as access to the previous six editions of the paper, which means no more trips to the garage!

The application is only in its infancy and you may not agree with the Times’ more liberal point of view, but if you are in the web or print design business, this is definitely a Must Download. It’s one of the forerunners that is beginning to bridge (repair?) the gap between web and print.

The Future of Income: Subscriptions

On the Times Reader you can see by the screenshot that some sections are “locked”, as denoted by an icon. You can catch a glimpse the sections, but are unable to click through to read more articles. A subscription of $3.45/week (less than 50¢/day) grants you access. If you were to ask me to spend $179.40/year on a website or newspaper, I would laugh and scoff in your face. Repackage that and turn it into $3.45/week for dependable news that I can read on my iPhone or iTablet (or whatever Apple calls it), then we have a conversational starting point.

This is not a new model of revenue. But it’s a turn from the “Freemium” ad-based business model that has exploded over the web. “Everything is free!” is ultimately a flawed business philosophy. Out of necessity, you either begin to overburden your users with advertising or you charge for things that otherwise used to be free, and that will eventually lose users[2].

These subscription based services for unlocking content (am I talking about XBOX?) will eventually be the norm. And it just might work. Loyalists who want the brand to continue, will support it, because they’ve extended themselves to be on the devices you love, and to do it well. Whether it’s Amazon’s Kindle or the upcoming iTablet, the NYTimes, like NPR, wants to be in your hands and being first to the gate with a method of digital distribution that appears sustainable is a huge gain.

The Future of Income: User-Supported

NPR takes a different approach to subscriptions. As listeners well know, NPR holds pledge drives every few months and strikes fear into its listeners that “Without your support, we can’t operate.” This fear, loyalty, ransom, or whatever you want to call it works. People will pay for what they love.

Though NPR is government funded, that only accounts for about 2% of its budget[3]. NPR is listener supported. It’s actual budget is determined by radio listeners, foundations, and handful corporate sponsors.

What NPR has done by its distribution method is that its now on every device, and you subconsciously need it there. They’ve beat your local TV news station to your phone.

And Finally…

It seems harsh and obvious and I’m repeating myself over and over. But this is happening. The internet has revolutionized the way we do everything and it’s just a adolescent teen. As Gary Vaynerchuck (currently #2 on the New York Times Bestseller list) would say, “The internet as we know it. The one where AOL would mail discs to your house, is only 14 years old.”

Ultimately, some will defend newspapers like they do cassette tapes. They’ll look on them with nostalgia and shout “I love it when they melt in my car!” But news doesn’t enter our houses via the doorstep anymore, it comes through the cable modem.

[1] http://www.slate.com/id/2133626/
[2] http://37signals.com/svn/posts/1964-37signals-in-the-news-discussing-free-vs-pay
[3] http://en.wikipedia.org/wiki/National_Public_Radio

And to keep myself upbeat about the whole situation I like to pretend there was a board room meeting where Larry Masters raised his arms and said “Go forth @gwoo and @nateabele! and continue with us -not as enemies, but as friends- to bring the good news of PHP to the world! We are all lions! There can be many prides!”… and then Mark Story did some kind of run-up-the-wall backflip because he is amazing…

Nate’s Question

Backstory complete, Nate posed the question on Twitter about what people would like to see from Lithium. I knew my answer wouldn’t fit into 140 characters so I thought I’d post it here.

File Uploader Class

My first dream utility would be some kind of built in File Upload mechanism (component, behavior, I don’t really care). I have had a long sordid story with uploading:

• First it was a custom jobby that got exploited pretty quick.
• Even when I did patch it, I was always stressed out about it.
• Then I used one of the upload components from CakeForge.
• Then about a year ago I switched to MeioUpload which rules, but after a year of use I’m starting to see the imperfections in it.

The general attitude in the CakePHP community seemed to be sort of “we don’t have that” and “figure it out for yourself”. But let’s be honest, we live in the #lazyweb and most real world applications involve some kind of uploading. Usually it’s creating a method for some computer illiterate person to upload a CSV or a PDF. But in the era of audio/video and media rich apps, the need for any framework to possess a standardized uploading class+handler is inherent. A canonized Uploading Class makes perfect sense. I have high hopes for something like this to come to Lithium because it appears that the creator of CakePHP’s Media Plugin, David Persson, has also defected. But so far his Twitter stream has given few clues to anything like this, just cryptic messages about pyramids, sunsets, and bicycles.

Image Editing Class

Another idea would be some kind of Image Manipulation/Editing class. This idea I got from this tweet. Just like uploading the chances that your modern day app is going to run into images and/or image editing is HUGE. I suppose this runs into a “Which javascript framework do we use!?!?” dilemma, but we all know that jQuery is the right answer here.

Other Ideas

Any other ideas would be toward making useful applications, because I’m a more User Experience oriented person. If I were to put myself on an MVC spectrum, I’d be here:

[DATA] Model ------------------------ Controllers --------|------------- Views [UX]

Just a tip for the Lithium Team, the secret to becoming an awesome framework is to make yourself completely accessible to n00bs. Have little bits that give your framework some “killer feature” eye candy. Extract mundane tasks like comment systems, rating/digg counters, geolocation, event calendars, et cetera into pre-packaged add-ons. I realize the developers of Lithium probably want to keep things lightweight and generic -and they should because it makes the framework more nimble- but some kind of cabinet of “Almost-Core” add-ons would be killer. Sort of like CakeForge Snippets and the Bakery intended to be before they got all super confusing.

Meeting Biggs Darklighter* at Subway

As for my decision whether or not to “Join the Rebellion” who knows. I really like CakePHP and having used it everyday for over the last 3 years I feel like I’m just hitting my stride. I feel like I can do anything with it. And probably more importantly, as long as I have production servers that are PHP4.3.9 (gasp!) and PHP5.2.6 with over 40 live sites I won’t be leaving CakePHP anytime soon.

On the other hand, some of my most memorable help on the IRC has been from Lithium’s Gwoo and Nate (as well as Mark Story who is already an established bad ass). So based on loose *never actually met* e-relationships Lithium seems like a more natural choice.

It will ultimately come down to the new programming cliche “Choose the framework that’s most suitable for the project” (CTFTMSFTP, for short). It’s like Subway**. There’s no rule that you can only order one sandwich for the rest of your life. It’s simple: choose the one you want to devour at the moment, pay the lady, and move on. Sometimes it’s CakePHP, sometimes it’s Lithium, and sometimes (gasp!) it’s Ruby on Rails.

Hopefully that metaphor changed your life like it did mine. Otherwise, I’m excited for Monday when my Ponies Class for Lithium is unveiled to the whole world. And although my hands are tied to lower PHP versions for awhile, I’m excited to see what comes of the whole Lithium project.

* This is a reference to a scene cut from Star Wars IV: A New Hope http://www.starwarsholidayspecial.com/swcs/episode4/Biggs.html

** Full disclosure: I want Subway to sponsor my life. If you can make this happen, email me.