Macintosh
In reply to
Feb 4th
Radley Marx wrote a short piece on ‘myths’ about HTML5; I read his post, and what struck me about it was that, despite a few salient points, it seemed mostly FUD. Particular gems stuck out, such as his assertion that HTML5 will create unblockable banner ads, that we’ll see a resurgence of unwelcome ’splash pages’, or that HTML5 will be just as crashy as Flash. It reeked of the kneejerk reaction I would expect from someone whose information comes entirely from the pro-Flash camp. Most of the assertions he makes are either wildly inaccurate or misrepresent the truth badly.
Myth 1 – HTML5 Video is only for the iPhone
On the iPhone, YouTube pops up Quicktime to play the video, because that’s what plays h.264 video on the iPhone. On Safari on Windows and Mac, it uses Quicktime for decoding as well. On Chrome, it uses Chrome’s built-in video rendering.
Also, if you visit www.youtube.com/html5 on any browser, it gives you a page asking if you want to enter the HTML5 beta – not any actual video. You should have checked the link first.
Myth 2 (section 1 – penetration)
HTML5 isn’t here yet? No, it’s not. Support for HTML5, however, is growing. Chrome, Firefox, and Safari all support HTML5 and CSS3 to varying degrees; Safari and Chrome both support h.264 video, and Firefox supports Ogg Theora video.
The point is not ‘everyone should switch to HTML5 immediately for everything’, but rather ‘Now’s the time to start thinking seriously about what HTML5 can offer you’. For example, in the case of Vimeo, I can turn on HTML5 instead of Flash (at my option). As a result, videos on Vimeo use far less CPU – On the Mac, a typical Vimeo video uses 100% of one CPU and 20% of another to play Flash video, vs. only 20% of one to play HTML5 video. If you don’t want it, change it back.
Myth 2 (section 2 – flexibility)
This one was a doozy, but I’ll try to address some of the points.
- Customizing the video player – see SublimeVideo for an example of the customizations you can do to an HTML5 video player. Works in Safari and Chrome.
- Movie clips – we just covered this, the <video> tag does this.
- Native apps – I assume you mean Adobe AIR? Personally, I can’t stand it. Every single app I’ve used that was written in AIR didn’t behave like a native application, was slow, and used up far more memory than an app should. It’s great for banging out a quick, cross-platform app, but no one I know uses it if they have a choice.
As for the rest – no, HTML5 doesn’t do all of that. It wasn’t meant to. That’s the sort of thing Flash is (maybe) good for.
Myth 3 – Canvas is inflexible, and nigh-useless for real work
- Canvas doesn’t support fonts – except those supported by browsers. True, but browsers like Safari and Chrome are also adding support for downloadable fonts, meaning that you, as a designer, can make a font available to the browser to use.
- Canvas only supports limited interactivity, so games are a no-go – I’m not sure what you mean by ‘limited interactivity’. You can capture mouse and keyboard events. Did you want more? You can certainly create games, and people are starting to do so. As a primitive example, check out this Wolfenstein 3D-esque 3D engine using Canvas.
Sure, it’s not the most advanced example, but it only took a few seconds of googling to find. There are much more complex and innovative examples out there.
- Tools – Ironically, the very company you seem to be trying to defend, Adobe, has tools that will do this. Check out this demo from October of someone using Illustrator and Dreamweaver to create Canvas-based content.
Myth 4 – HTML5 has all the problems of Flash, and will bring back splash pages
- CPU hogging. Well, of all the things I’ve seen in HTML5, none of them are cpu-intensive, except the one thing you linked (which looks like it’s doing some very inefficient things very often). Meanwhile, in my experience, without Flash blocking the entire web is geared towards draining laptop batteries as much as possible. Not ideal.
- Banner ads – Flash blockers aren’t the best way to get rid of ads, they’re just the best way to get rid of annoying flash that gets past your ad blocking filters. If you want to get rid of ads, use an ad-blocker that will stop your browser from downloading the Javascript that puts the ads there in the first place. This will work for HTML5 just as well.
- Splash pages – HTML5 means a return of splash pages? No. People who know how to build a good user experience won’t suddenly forget when they stop using Flash.
- Crashes. You start talking about crashes, then talk about CPU use. There’s no correlation. Regardless, Flash on Mac especially is horrendously buggy. Safari is far, far more stable now that I block the Flash plugin from doing anything unless I tell it to. This isn’t going to change, because Adobe doesn’t care about the Mac market. If they ever start to care, then maybe we’ll start seeing some improvements.
Conclusion
I’m not entirely sure what the point of your blog post was. You seem to spend it all spouting off knee-jerk reactions, of the kind that implies you’re a Flash developer, and you’re afraid that you’re going to become irrelevant. Maybe it’s just me, but that’s how it comes across.
But it doesn’t make any sense. Adobe is not afraid of Flash being killed off by HTML5; you’ve pointed out several reasons yourself why it won’t – things like throwaway browser games, or voice/video apps. The fact is that the design goals of Flash and the design goals of HTML5 overlap in some areas, but definitely not all of them. Flash isn’t going away any time soon (though I’d be thrilled if it did). What we will start to see is compatibility. Let Flash do what only Flash can do well, but let the browsers do the rest, and let them do it better. Instead of Adobe trying to optimize for every case, let Adobe focus Flash on what it needs to do best.
What it comes down to is Adobe execs making this about ‘us or them’. They keep talking about how they have this awesome version of Flash for the iPhone waiting in the wings, but Apple is cruelly depriving its users of the joys of Flash. In reality, Adobe hasn’t bothered to give Mac users a working, stable version of Flash. For that matter, even the Mozilla Maemo team is having problems with Flash performance; Stuart Parmenter announced today that they have RC3 of Firefox for Maemo ready, but they had to turn off plugins because Flash slowed things down too much.
So let’s stop this fighting. Adobe used to be a great company, maybe it will be again. They can continue to make tools, whether Flash survives or not, whether HTML5 becomes commonplace or not. That’s where their money is, and that’s fine. What we need to stop is this misdirection, the fear, uncertainty and doubt that people are spreading about ‘Flash vs. iPad’ and so on. It doesn’t help anyone if you force them to take sides.
Snow Leopard Automatic Text Correction
Sep 1st
I’ve noticed this today and I figured it was worth mentioning: Snow Leopard supports automatic inline correction of words in some applications designed to utilize it, such as Mail and TextEdit. This is kind of neat except that it can make corrections you don’t want.
As an example, I’m doing a lot of domain stuff today, and dealing with our registrar of choice, eNom – except that if I type their name in lowercase (‘enom’) SL automatically corrects it to ‘enema’, which means I’ve been inches away from sending horrendously confusing and potentially inappropriate e-mails to people.
Maybe it’s something to watch out for. It’s nearly screwed me a few times.
Fido and Rogers Tethering on iPhoneOS 3.0
Jun 17th
Update: As of iPhoneOS 3.1, the iPhone will not accept unsigned config files (unless you have jailbroken); as such, this file will no longer work. If you have installed it (or any similar file for other carriers, like AT&T, T-Mobile, etc.) and upgraded to iPhoneOS 3.1 or 3.1.2, you will need to remove it. Open Settings > General > Profiles (at the bottom). Tap, then remove the profile you see there. Tethering should hopefully show up for you afterwards. I’ve preserved the rest of the entry for historical purposes, but it will no longer work on iPhone OS 3.1 or higher. More >
Memcached, gems, and Macports
Jun 10th
I actually really like Macports; it’s got a lot of software, it’s well-maintained, it works really well. Kudos to the Macports guys.
We have been having a problem with ruby though, or specifically with the memcached gem for Ruby. The problem is that it won’t compile with the latest versions of libmemcached. The latest, you see is 0.30, but it won’t compile with 0.26 or higher. In fact, if you’re using version 0.14 of the memcached gem, it won’t compile with 0.24 or lower. Oh, and it won’t compile with 0.25 either.
In fact, it won’t compile at all with any version of libmemcached for most people, and if it does it rarely works.
Unfortunately, the version of libmemcached required, 0.25.14, is only available (as far as I can find) on Evan Weaver’s blog post mentioning it. For people like me who like to keep everything package-managed when possible, this is a hassle. There’s no one-line command to make everything work, set it all up, and get it going. Kind of ugly, imho.
Fortunately, the ports system is as flexible as it is powerful, and you can easily hack the ports file to know about this new, better version. For you, I have done this, and you can find it in my github repo if you so desire, though I’ll include it here for reference. Behold!
Notice the ‘variant’ section at the bottom; that’s all I had to add to add support for this edge-case to Macports. Hopefully, as a result, the Macports maintainer will be willing to add this change into the official portfile. I suppose we’ll see. In the meantime, if you want to add this functionality, you need only replace your current portfile with the one in my GitHub repo. Instructions, paths, and commands are all at that URL. Enjoy!
Twitter client requirements
Feb 12th
I want a good Twitter client. Here are the features I would like it to have. App names in parentheses are examples of how I want the feature to work, where necessary. More >