Apple released Safari 5 on June 9th, the fastest and most advanced browser from Apple yet. It’s loaded with new features and enhancements, and from a cursory look, this is an intriguing release indeed.
Thing is though, if your a non-techie all this talk of HTML 5 probably makes you say “Wah?” — While those of us in the development community are left wondering when we’ll get to implement this cool stuff as the giant elephant in the room sits docilely in the corner.
It’s a confusing release really, filled with more promise and hope than tangible benefit–or is it?
As a guy who runs a web software company I thought I’d share my quick thoughts on Safari 5 and provide some links to learn more.
HTML 5
HTML5 AJAX History
This is an interesting one in that it’s a feature in need of a web infrastructure to support it–or at least if I understand the feature correctly. I assume this is a system for storing application state, but I haven’t had much luck finding out for sure. Regardless, it’s interesting to me as someone who wrote a full AJAX based web site that utilizes AJAX history state saving. It was done using a script called Real Simple History, and was as you would expect, a direct answer to the annoyances of losing your save state if the user hit the back, reload, or forward button. It works well enough, but just as with HTML Draggables, would be nice to have built in.
HTML5 forms validation
Sorry, not too informative, but I did find this link which describes more on this topic.
WebSocket
I like to think of this as a extension of the HTTP Request object introduced in IE 5 way back in ’99. The basic idea is that we can open a direct link to a server on what’s called a Full Duplex channel (e.g. your telephone), which allows simultaneous two-way communication.
http://code.google.com/p/phpwebsocket/
What is this good for? Chat logs I suppose, but it may lead to more advanced types of form validation…
Web workers
I’ve actually covered these guys in another post on this blog, but the basic idea is that web can run concurrent JavaScript code to speed up execution. Now Safari 4 already supported Web Workers, though with a reduced feature-set as compared to FireFox. So the real question is, have they been enhanced in any appreciable way? I’ll have to test the feature set in a future post, but for now, here’s a quick look at performance between FireFox 3.6.3 and Safari 5:
Firefox 3.6.3:
Fibonacci Set 1 Time Taken: 1.16
Safari 5 (initial release)
Fibonacci Set 1 Time Taken: 0.2
Of course this is the horrible inefficient stack smashing way, the optimised iterative version favors FireFox slightly:
Firefox 3.6.3:
Fibonacci Set 1 Time Taken: 1.08
Safari 5:
Fibonacci Set 1 Time Taken: 1.52
HTML5 draggable attribute
This is an interesting one, if for no other reason than here we have another Microsoft originated API from IE 5!
http://html5doctor.com/native-drag-and-drop/
As far as it’s integration into web applications–I think the greatest benefit of a native API to handle drag and drop will be from a performance perspective. Right now in FormBoss, for example, dragging multiple items isn’t as precise as I would like it to be. This is not necessarily a performance problem, but a native method should mean we can sample more efficiently during the drag operation, which should help smooth things out and improve precision.
Their is more to it of course, to which I simply defer to: http://html5doctor.com
Developer Tools and Closing Comments
The last thing I want to look at is the all-important subject of Safari 5 as a developer friendly release.
FireBug simply rules them all–this has been, and most likely will continue to be, the clarion call for all serious web developers. Yet in the recent years it seems as if inline JavaScript debugging is becoming the norm, not the exception. IE8 has a debugger, Chrome, and of course Safari.
Problem is, they’ve always fallen well short of Firebug for one simple reason: FireBug is about more than just debugging, it’s about the DOM too. Without a good way of viewing the DOM a debugger is nearly useless for complex work. To be clear, by DOM I mean the entire DOM starting from the window element, not just the visible page bits from the HTML element on down. FormBoss, like most web applications, makes extensive use of the root DOM object to store objects and arrays.
The strange thing is Safari will gladly show you the window element if you open the Console and type:
-
eval (window)
…but not from the comfort of the main debugger, or even from a separate DOM tab.
Unfortunately, while the developer tools in Safari 5 seem very slick, they do not address the DOM viewing issue, and they also seem to be a touch unstable. While viewing the property of a paused debugging session the entire browser crashed. I’ve had FireFox get twitchy, but not outright crash.
That said, the tools are slick, as I said. Syntax coloring is very nice to see, as is the clean and intuitive user interface. Now if they could only add a proper DOM inspector!