August 12th, 2009
- Laugh along as you learn how to wield sharp-edged, higher-order language features like a pro, and make the DOM your slave to do your bidding.
- Study the enemy—the browser—in detail, so you know best how to conquer it.
- Ensure accuracy, no matter the changes in terrain, with unit testing.
- Master the art of speed—squeezing out every last precious second, both serving your code, and executing it.
- Study the ways of the masters with project life cycles, code management, architecture, and tools.
August 10th, 2009
Here’s a little tip that makes the Safari Web Inspector even better (and saves you from remembering the keyboard shortcut!).
Select View → Customize Toolbar… and drag the Web Inspector button to your Safari toolbar (on my Safari the button lives on the far right, next to the search box).
Instant inspecting and debugging goodness!
July 11th, 2009
Amy and I are proud to be judges at the first ONYA awards, which celebrates all things web in New Zealand. It’s organized by the good folk of Webstock, the awesomest web conference ever, where we’ve attended twice– we’re really honoured by this and are looking forward to your entries!
So, if you’re in New Zealand and have a really cool website, web application or mobile app, be sure to submit your entry (deadline is July 24).
July 9th, 2009
For web developers, there’s an obvious choice of which browser to use for developing web applications. Firefox it is, right? Wrong.
Let’s compare the two browsers, more specifically Safari 4 vs. Firefox 3.5. Both browsers pass the Acid2 test with flying colors, but when it comes to Acid3, Firefox only reaches 93% compliance (up from 71% in Firefox 3.0). Safari? 100%.
That’s a pretty good start for Safari. Basically, if some HTML/CSS works on Safari, the chances are very high it will work on Firefox 2 and higher, and on IE 6 and higher (with minor tweaks).
On the plus side, there’s some really great additional plugins like YSlow and Smush.it. I tend to use those independently of the main development cycle, as these tools are more for deployment optimization anyway, so they don’t really play into the development of the web app as such.
The console in Safari has some nifty features, foremost a well-working autocomplete implementation. Firefox has autocomplete too, but doesn’t show you the current option until after you hit .
The user interface is much more streamlined and cleaned up on Safari as well. The only gripe I have is that I’m not in love with the font the console and debugger on Safari uses (but I’m a font nerd).
will be automatically converted into
This change is not internal– if you to a
x.toString() on the function source code actually has changed. I’m not very much in love with this automatic optimization step– I’d rather see this done by some kind of external tool, like the YUI Compressor, which does some of these microoptimizations. Neither Safari, nor Chrome or IE does that.
Quick, fix that bug!
I’ve done several bug reports to the WebKit project over the years, and all of them where eventually adressed (in big projects like this, it can be expected that non-critical issues might take a while to be resolved). On Firefox, there’s been certain bugs that have a long history of developer hairpulling and nailbiting. Here’s my favourite (Quote: “This bug reveals a problem in Mozilla post-release bug fixing. We have been made to wait 6 years for this bug to be fixed.”).
Note that I’m sure that the people working on the Firefox development team are working very hard (I know some of the awesome people who worked there!), and it’s more of a management issue.
I used Firefox since version 1.0 for my web development, but I’ve switched over to Safari for 99% of my development needs. I only go back to Firefox to make sure it works there and for some of the plugins.
Btw, I know that there are operating systems other than OS X out there. But I’m not using them for development, for several reasons, one of them being that OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software (I run IE6/7/8 in VMs), and have a Firefox on Linux VM, too. And the iPhone Simulator that comes with XCode runs only the Mac, of course. If you’re serious about front-end web development, there’s pretty much only one OS choice (Let the flamewars begin!).
July 6th, 2009
Here are the slides from a 3-hour tutorial/presentation I gave at a local university last year. (As it’s an introduction to both Ruby and Rails basics it’s still current!). It shows off some of the nice concepts in Ruby and in Rails, and actually has some code on slides which I’m a big fan of.
You can grab the Ruby sample code here and/or download the slides as PDF (18.8 MB).
BTW, if you’re on the east coast, there’ll be awesome Ruby and Rails courses starting in August tought by our friend Jeff Casimir, so drop by Jumpstart Lab and register for one!
July 3rd, 2009
Here are the slides from the presentation Amy and I gave at Kings of Code ’09 in Amsterdam. Probably not too helpful without the audio, it’s mostly for those of you that attended and asked for the slides, so please enjoy Rich and Snappy Apps (No Scaling Required).
You can also grab a PDF (3.4 MB).
June 26th, 2009
The script.aculo.us 2 alpha is out! Check it out now at scripty2.com. As you would expect, it brings a lot of change and new features.
scripty2: for a more delicious web
As the effects framework forms the base for all the eye candy in any UI elements, it’s the logical first step towards a complete scripty2. But what’s in that, and how will the complete thing look like?
scripty2 will consist of three parts:
- scripty2 fx: the framework for DOM/CSS-based visual effects
- scripty2 ui: user interface behaviours (not in right now)
- scripty2 core: helpers for a more delicious developer experience
In this release, the focus has been on the effects engine, with the UI parts still pending a rewrite (there will be a lot of really cool stuff coming for the UI part, but more about that later).
Even in alpha, the effects engine can now do so much more, with less code to write. Check out the source code to the cards demo to see what a mere screenful or two of code can do now!
And we’re actually using it in our own live projects, like twistori and freckle time tracking, so it’s pretty damn stable already.
Docs, Docs, Docs
If there’s one thing I’ve learned over the years of maintaining an open source software project, than it’s that Wikis just don’t work (except if you’ve millions of users). It’s too much of a hassle to keep the spam out, not synchronized to the software version cycle, full of comments by well-meaning people that sadly don’t understand open source communities or the spirit behind free software, and numerous other problems.
As a bonus, there’s up-to-date offline documentation always at your fingertips, so regardless if you’re on a plane or train you can always browse the docs.
Yes, it’s all new. The old code was just to crufted and packed with workarounds for browsers no one uses any more, so I’ve decided to start anew and write the effects engine from scratch. With all the knowledge gained from years of using the effects
on various projects, it’s now ready for the future (and it looks bright!).
As a bonus, the minified and gzipped version of scripty2 is a mere 5k in size. That’s a lot of animation features in a very, very small package.
The scripty2 download comes with minified versions of Prototype and itself.
Here’s the reasoning behind the rewrite:
- Start from a clean base: remove cruft and have a smaller codebase.
- Features and extensibility: have a more open and flexible code model to allow for some real interesting features (for example, you can swap the whole timing engine with your own).
- It’s fun to do something new: maybe the main reason is that I like to hack. So.
Keep in mind that the old code still works great on thousands of sites all across the web, including some of the biggest and most frequented.
Rename to scripty2
I like the script.aculo.us name and will use it in the future too, but it was time to update the name to make it easier to spell it and lead to less confusion about the domain name (others agree). I’d love to hear feedback on the new name!
scripty2’s development is proudly hosted on Github, there’s a bugtracker at Lighthouse and last but not least, a developer mailing list on Google Groups.
I’d like to invite everyone that’s interested in joining the development efforts by reporting bugs, submitting patches, maintainig tests and writing documentation and demos (if you come up with a really cool demo, I’d like to include it on the scripty2 demo pages).
Have fun building a more delicious web!
June 22nd, 2009
June 19th, 2009
While you can download scripty2 and generate the docs yourself, here’s a sneak preview on how they’re going to look. A very valid criticism concerning the script.aculo.us documentation always was that it was wiki-based and incomplete. While I had a lot of helping hands, wiki vandalism (by either spammers or by folks who wanted to help but didn’t have a clue to the library) was too much to handle.
June 9th, 2009
Years ago it was Netscape vs. Internet Explorer who fought for the throne of being the most popular browser. We all know how it ended, with the latter prevailing through a mixture of then-better technology (Internet Explorer 4 was ahead of its time) and questionable business practises (like too-tight OS integration).
The wind of innovation subdued, and browsers stayed as-is for a long time, despite efforts of various comittees to introduce new stuff to the Web.
Now, with Web-Two-Oh-And-Beyond, there’s a new browser war raging, and this time it’s mostly about real technical innovation, rather than adding proprietary stuff left and right.
And finally, browser user interfaces are taking real steps forward.
What to look for in a browser?
I’m doing a little ranking on these with both user experience and developer-friendliness in mind. Let’s see if we can find a winner here!
I’m looking at several things, which are:
2. User Interface: Subjective beauty and usefulness, that is, does it rock?
3. Developer Tools: Are there developer tools available, on how useful are they?
Safari was first to implement various design and typography-centric features, like support for color profiles, PDF rendering and various CSS3-based layout awesomeness. It passes the Acid3 test with 100%.
Does it rock? Yes, the User Interface is great, with the “Top Sites” view and graphical, screenshot-based history browsing, next to solid tab-based browsing. I’ve experienced a couple of weird crashes, which is a throw back into the Safari 1 era, but I’m sure that will be fixed soon.
Developer tools: Safari 4 now includes a widely Firebug-compatible API, which works great. The resources panel’ visualization of latency is incredibly useful. Plus, it’s stunningly beautiful, not a thing that can be said about most developer tools.
Does it rock? The user interface seems a bit uninspired, compared to the eye candy that’s in Safari and Chrome, but it’s much cleaner than Internet Explorer. The URL bar’s shortcuts are pretty great, and lots of people swear by it.
Developer tools: The top of the pack. Firebug alone revolutionized the way most web developers work today, and there’s a bunch of other plugins available. But foremost, Firebug, which is a plugin, also has a plugin architecture, so there’s plugins for the plugin. And they are very useful (I can recommend YSlow and Firecookie). However, since Firefox 3.0, Firebug is a bit on the buggy side and tends refuse to work sometimes (in that case a fallback strategy is to use Firefox 2 and earlier versions of Firebug).
It almost passes the Acid3 test, with 99%.
Does it rock? The tabs-on-top work great, and the isolation of each tab as a seperate “browser instance” should by envyied by the other contenders, as it makes browsing much more scalable and stable.
Developer tools: Not so good. While it includes WebKit’s console, HTML browser and Resources panel, it’s not as tightly integrated as on Safari (or example, you’ve to reload to get results in the Resources panel, which might distort what actually is going on).
Snappiness: It’s quite fast, especially when compared to previous versions. Though, it’s nowhere near the perceived speed of Chrome. All that doesn’t matter though, because the user is constantly interrupted with requests to help the browser out. I’m sure Joe User knows what “MSXML 3.0 SP11” is and can make an informed decision whether to download it or not.
When running the Acid3 test, there’s a big bold “FAIL” stamped on the screen, and it merely gets 20% of the tests right.
And why is there a “Safety” menu? That doesn’t instill great confidence in me. And, no, please spare me with those surpise dialog boxes, asking me stuff and interrupting my workflow. Plus, what’s that stuff with the mode switching and the download of “compatibility updates”? Is it not compatible by default?
Does Microsoft really think that users will click a “broken page” icon? Get real, please.
And the winner is…
We have a winner! And it is Safari 4. This is the browser I use for casual browsing and most development tasks. The runner-up is Firefox, mostly for the development plugins.
If—and I’m speaking hypothetically—I’d use Windows on my daily work machine, I’d probably pick Google Chrome for my casual browsing activities, and Firefox for development.