Tim Caswell has been doing awesome work, and his latest project is Connect, a high performance middleware framework for node.js. Ruby has Rack. Python has WSGI. Java has Servlets. Now, JavaScript has Node/Connect.
I was able to set it up in minutes and took the following screencast of a sample application in action:
Take a peak at the examples as they show you how easy it is to rack up the middleware. In the Raphael circle multi-touch collaborative dragging example shown, you get a nice set of filters:
var toDist = canvasW / 1.15; var stirDist = canvasW / 8; var blowDist = canvasW / 2;
var Mrnd = Math.random; var Mabs = Math.abs; var Msqrt = Math.sqrt; var Mcos = Math.cos; var Msin = Math.sin; var Matan2 = Math.atan2; var Mmax = Math.max; var Mmin = Math.min;
var i = numMovers; while( i-- ) { var m = movers[i]; var x = m.x; var y = m.y; var vX = m.vX; var vY = m.vY;
var dX = x - mouseX; var dY = y - mouseY; var d = Msqrt( dX * dX + dY * dY ); var a = Matan2( dY , dX ); var cosA = Mcos( a ); var sinA = Msin( a );
if( isMouseDown ) { if( d <blowDist ) { var blowAcc = (1 - ( d / blowDist )) * 14;
vX += cosA * blowAcc + .5 - Mrnd();
vY += sinA * blowAcc + .5 - Mrnd(); } }
if( d <toDist ) { var toAcc = (1 - ( d / toDist )) * canvasW * .0014;
vX -= cosA * toAcc;
vY -= sinA * toAcc; }
if( d <stirDist ) { var mAcc = (1 - ( d / stirDist )) * canvasW * .00022;
vX += mouseVX * mAcc;
vY += mouseVY * mAcc; }
vX *= friction;
vY *= friction;
var avgVX = Mabs( vX ); var avgVY = Mabs( vY ); var avgV = ( avgVX + avgVY ) * .5;
A lot of JavaScript is about to get nuked. It would be cool to have a pre-processor that generates JS code for browsers that won't support the syntax so we can use this not in 5 years.
Remember a time when you would make fun of Facebook for having such poor performance? You would see 400 scripts that would be loading, some of which that would have code for no reason. That was in the distant past now.
Makinde Adeagbo gave that great talk at JSConf about the copious amount of code they were able to delete while speeding up the site. With folks like him and Tom Occhino on the case, you know good things are happening.
If you do a view source on the Facebook home page these days, you see a lot of this:
To exploit the parallelism between web server and browser, BigPipe first breaks web pages into multiple chunks called pagelets. Just as a pipelining microprocessor divides an instruction’s life cycle into multiple stages (such as “instruction fetch”, “instruction decode”, “execution”, “register write back” etc.), BigPipe breaks the page generation process into several stages:
Request parsing: web server parses and sanity checks the HTTP request.
Data fetching: web server fetches data from storage tier.
Markup generation: web server generates HTML markup for the response.
Network transport: the response is transferred from web server to browser.
CSS downloading: browser downloads CSS required by the page.
DOM tree construction and CSS styling: browser constructs DOM tree of the document, and then applies CSS rules on it.
JavaScript downloading: browser downloads JavaScript resources referenced by the page.
JavaScript execution: browser executes JavaScript code of the page.
The first three stages are executed by the web server, and the last four stages are executed by the browser. Each pagelet must go through all these stages sequentially, but BigPipe enables several pagelets to be executed simultaneously in different stages.
The picture above uses Facebook’s home page as an example to demonstrate how web pages are decomposed into pagelets. The home page consists of several pagelets: “composer pagelet”, “navigation pagelet”, “news feed pagelet”, “request box pagelet”, “ads pagelet”, “friend suggestion box” and “connection box”, etc. Each of them is independent of each. When the "navigation pagelet" is displayed to the user, the "news feed pagelet" can still be being generated at the server.
In BigPipe, the life cycle of a user request is the following: The browser sends an HTTP request to web server. After receiving the HTTP request and performing some sanity check on it, web server immediately sends back an unclosed HTML document that includes an HTML
tag and the first part of the tag. The tag includes BigPipe’s JavaScript library to interpret pagelet responses to be received later. In the tag, there is a template that specifies the logical structure of page and the placeholders for pagelets.
Performance results
The graph below shows the performance data comparing the 75th percentile user perceived latency for seeing the most important content in a page (e.g. news feed is considered the most important content on Facebook home page) on traditional model and BigPipe. The data is collected by loading Facebook home page 50 times using browsers with cold browser cache. The graph shows that BigPipe reduces user perceived latency by half in most browsers.
The main concept works on using CSS3 for the radius, making a round circle view point. This contains an iframe which is the exact same content. Using CSS3 again I scale the content in the iframe so that it is x2 larger, allowing smaller content to be read. The magnifying glass is also controlled by simple keyboard combinations which allow for show / hide and zooming in and out. Future plans will include Chrome and Firefox add-ons meaning that an iframe will no longer be used and can then use canvas to get the page content, which can then be updated as the page content updates.
Remember those discussions? We had the arguments ... the purists who would shout and scream if you said something was Ajax and didn't use XHR with async mode + XML as the format. Ajax beat our AJAX and became the new term for DHTML and the term that meant "all of the cool shizzle that browsers and JS library authors are now doing!"
The new king on the hill is "HTML5" which has taken that exact mantle. One extreme view is that the term is marketing drivel. The other is that it should ONLY be used to mean the W3C version of the HTML5 core specification.
I really like how Brad goes deeper on HTML5. It is far too confusing to know what capabilities are in browsers, what specs they are in, and what really matters... what can I use as a Web developer.
Brad takes apart the various specs and APIs:
Going deeper, I've broken these down into separate areas:
"HTML5 Strict"- Things that are strictly inside the W3C's HTML5 spec.
"Referenced by HTML5" - Things that are referenced by the HTML5 spec and which can optionally be parsed into the DOM and displayed.
"Broken out of HTML5" - Things that used to be part of HTML5 or its older iterations, called Web Applications and Web Forms.
"HTML5 Family of Technologies" - Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5.
"HTML5++" - More experimental technologies pushing the web forward that are not part of the HTML5 spec at all; may or may not see broader adoption.
You need to understand that HTML5 began as a revolution to the established order, initiated by the WhatWG. A peace of sorts developed over the years, with the upstart "Web Applications" and "Web Forms" specs brought in-house to the W3C under the moniker HTML5. Over time I'm assuming that the W3C spec, when Final Call has happened, will be the canonical spec.
To simplify things below, I'm only referencing the W3C HTML5 spec for now. Here's how I would break things down based on what I said above; if you think something should be somewhere else or things get moved around email me and I'll update this (Last Updated: June 7th, 2010). If you want to know the state of where these technologies are implemented see caniuse.com; if you want your code to detect what is available see Mark Pilgrim's book for details.
"HTML5 Strict": Strictly Inside the W3C's HTML5 Spec
HTML5 Doctype: <!doctype html>
HTML5 parsing
XHTML5 serialization
Cleaning up edge cases of existing web content for greater compatibility
New semantic, behavior, and application tags: section, nav, article, aside, hgroup, header, footer, address, figure, figcaption, time, code, var, samp, kbd, output, progress, meter, details, summary, command, menu
Being able to nest H1, H2, etc. arbitrarily
Sandbox attribute on iframes
Video tag, API and events
Audio tag, API, and events
New form input types: telephone, search, url, e-mail, date, time, month, week, number, range, color
New form abilities: multiple file upload; placeholder text; directing focus on initial page load; constraint validation by input type and properties
New link rel types: alternate, archives, author, bookmark, external, help, icon, license, nofollow, noreferrer, pingback, prefetch, search, sidebar, tag, index, up, first, last, next, prev
data-* attributes for SCRIPT tags
Offline Web applications
contenteditable for editing
Drag and Drop
UndoManager for consistent undos
Parsing empty and unknown tags into the DOM: <foobar />
async attribute on SCRIPT tags
PUT and DELETE methods for form submission
Deprecated elements: acronym, applet, basefont, big, center, dir, font, frame, frameset, isindex, noframes, s, strike, tt, u
"Referenced by HTML5": Referenced from W3C HTML5 spec, including how to parse into an HTML5 DOM; HTML5 parsing engines can optionally include these in DOM and display them
MathML
SVG
"Broken Out of HTML5": Used to be inside of HTML5, Web Applications, or Web Forms specifications
Web Sockets
Local Persistent Storage (localStorage and sessionStorage)
SQL Storage (in contention versus IndexDB)
DataGrid
Specific HTML5 Video codec: H.264, Ogg/Theora, WebM (contention between video codecs)
Specific HTML5 Audio codec
Device element
Ping attribute
Timed track model for media elements
Canvas
Microdata and Microdata Vocabularies (some level of contention versus RDFa and Microformats)
Cross-document messaging
Channel messaging
W3C XMLHttpRequest specification
Server-Sent Events
Ajax Session History
MIME type and Protocol handler registration
P2P connections
"HTML5 Family of Technologies": Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5
CSS3
Flex Box Layout
Multi-Column Layout
Animations
Transforms (2D and 3D)
Transitions
Masking and Effects (rounded corners, shadows, etc.)
Gradients
CSS3 Selectors
Media Queries
Web Fonts - CSS 2.1 @font-face + OpenType/WOFF (slight contention for OpenType vs. WOFF)
W3C Geolocation
Metadata - RDFa, Microformats (Some level of contention vs. Microdata)
Web workers
ARIA
EcmaScript 5
Faster JavaScript
CSS styling of new HTML5 input types (color, range, etc.)
IndexDB (in contention versus SQL Storage)
querySelector/querySelectorAll
getElementsByClassName
GPU acceleration of HTML, Canvas, SVG, and CSS3 Animations/Transitions/Transforms
"HTML5++": More experimental technologies pushing the web forward; may or may not see broader adoption
WebGL
O3D
Firefox Audio APIs
XBL 2.0
We can argue about which term to use when, but I am much more excited about is explaining the capabilities and working together on nice stacks so we can build killer applications on the Web platform in a productive manner.
*thump*. That is the sound of Google Chrome Frame getting a beta tag on it with a new version that comes up to Chrome 5 levels:
Instead of adding new bells and whistles, we've fixed more than 200 bugs to make integration with Internet Explorer seamless while improving security, stability, and performance. For example, we’ve improved our handling of Internet Explorer’s InPrivate browsing, cache clearing, and cookie blocking. All of the enhancements and features of Google Chrome 5.0 are available in Google Chrome Frame too, including HTML5 audio and video, canvas, geolocation, workers, and databases.
As we've worked on these improvements, we’ve been excited to see sites adopting Google Chrome Frame, including Meebo and all the blogs hosted by WordPress. In addition to our launch partner Google Wave, some other Google properties, including Orkut and YouTube are also relying on Google Chrome Frame to deliver HTML5 experiences to millions of users.
For those of you who want to develop HTML5 applications and deploy them broadly, we encourage you to give Google Chrome Frame a try. Existing users will be auto-updated to the beta, so if you downloaded Google Chrome Frame before, you’ll automatically get the new version. We’re also creating a new dev channel release, where you can try out the cutting-edge features we’re developing. For information on getting started with Google Chrome Frame, our project documentation is the place to start.
Alex gave a talk on how you can sprinkle in the Chrome Frame love, and start using the HTML5 goodness of video, svg, canvas, etc today!
We hear cries of the end is near!, and now you have a new push. Take a breath and spend the IE6 cycles on building amazing Web applications. So, CFInstall.check({..}) away! :)
In some ways it’s a strange product; it’s working best when you notice it least. As a developer, you shouldn’t have to think much harder about it than either to include the header or meta tag or to include a couple of lines of script to prompt users to install the plugin — a process which notably doesn’t require a restart and doesn’t even take users off of your site. There’s no new tool to learn, no new language you have to wrap your head around…in fact, the hardest part might just be putting down all the habits we’ve collected for catering to legacy browsers.
As I’ve begun to build exclusively to modern browsers, the experience of concerted un-learning of hacks and the ability to write directly to the platform again, sans toolkit, has been eye opening. Yes, there’s still a lot that can be improved in DOM, CSS, and HTML, but things are moving, and the tools we need now aren’t the tools we have today. Better yet, there’s every indication that things are progressing fast enough that instead of building tools to bring up the rear, we’ll be building them to shield ourselves from the ferocious pace of improvement should we need them at all.
If you’re starting a new project today, I encourage you to prototype to HTML5 and modern features and then think hard about what you’re building and for whom. Do these apps really need to run on legacy browsers? Why not just use GCF to make that pain and expense go away. Once you’ve experienced how good modern web development can be — how rich and fast the apps you can deliver are — I’m convinced that you’ll find it hard to go back. The rich, open, interoperable web is the platform of the future, and I couldn’t be happier that GCF is going to help deliver that future.
var header_test = new Cohorts.Test({ name: 'big_vs_small_header',
sample: 1, // we want to include all visitors in the test
cohorts: {
big: {
onChosen: function(){
$('#big').show(); } },
small: {
onChosen: function(){
$('#small').show(); } } } });
$('#big').click(function(){
header_test.event('Clicked on Header'); });
$('#small').click(function(){
header_test.event('Clicked on Header'); });
The code above shows you exactly how you could run a test that shows either a large, or small clickable header... and gives you A/B results on how many were clicked.
This is all view a new library called Cohorts by James Yu:
Cohorts is a simple, purely javascript, multivariate testing framework.
It allows you to easily run split tests for visitors on your site, showing them different designs, layouts, or whatever you want. Cohorts also allows you to track interesting events that occur for each of the cohorts. By default, it uses Google Analytics event tracking to store data, but you can customize it to use your own or another.
Safari 5 got out of the gate a touch early as the PR team shot their new release out before anything else was out there:
“Safari continues to lead the pack in performance, innovation and standards support,” said Philip Schiller, Apple’s senior vice president of Worldwide Product Marketing. “Safari now runs on over 200 million devices worldwide and its open source WebKit engine runs on over 500 million devices.”
Safari Reader makes it easy to read single and multipage articles on the web by presenting them in a new, scrollable view without any additional content or clutter. When Safari 5 detects an article, users can click on the Reader icon in the Smart Address Field to display the entire article for clear, uninterrupted reading with options to enlarge, print or send via email.
Powered by the Nitro JavaScript engine, Safari 5 on the Mac runs JavaScript 30 percent faster than Safari 4, three percent faster than Chrome 5.0, and over twice as fast as Firefox 3.6.* Safari 5 loads new webpages faster using Domain Name System (DNS) prefetching, and improves the caching of previously viewed pages to return to them more quickly.
Safari 5 adds more than a dozen powerful HTML5 features that allow web developers to create media-rich experiences, including full screen playback and closed captions for HTML5 video. Other new HTML5 features in Safari 5 include HTML5 Geolocation, HTML5 sectioning elements, HTML5 draggable attribute, HTML5 forms validation, HTML5 Ruby, HTML5 AJAX History, EventSource and WebSocket.
The new, free Safari Developer Program allows developers to customize and enhance Safari 5 with extensions based on standard web technologies like HTML5, CSS3 and JavaScript. The Extension Builder, new in Safari 5, simplifies the development, installation and packaging of extensions. For enhanced security and stability, Safari Extensions are sandboxed, signed with a digital certificate from Apple and run solely in the browser.
Some great features in there. Let's get into some details:
Performance
Sam Pullara quickly ran Sun Spider on Chrome 6.0.422.0 and Safari 5 and the result is very close to a dead heat:
Now, lets look at how they size up in BrowserScope:
Topic
Chrome
Safari
Security
12/13
10/13
Rich Text
129/149
129/149
Selectors API
99.3%
99.3%
Network
9/16
10/16
Acid3
100/100
100/100
Incredibly close. Not that it should be a shock, since both parties are using WebKit under the hood (although the JS engines are totally different, and many other differences!)
Extensions
Panic were up on stage showing off Code Notes, a nice example of extensions for Safari:
The Coda Notes extension is built entirely in JavaScript, HTML, and CSS; the extension bar is basically an HTML file, and the page-flip effect is accomplished using a CSS transform. We draw on a transparent canvas element injected over the target page. Live text editing is done by setting the contentEditable attribute on the body of the page, thus turning Safari into an editor.
Great to see the new extension mechanisms on the Web are all of the Web (Chrome, Safari, Jetpack). Very cool indeed.
The Google I/O sessions are now live. I/O was a big event this year, and the press liked to focus on the splashy double headed keynotes (day 1: go web!, day 2: go Android :/).
The bulk of the real content from Google engineers was very solid indeed, and there are gems for Web developers out there.
Remember the GWT Quake goodness from April 1st? The crew behind it are back giving a talk about the tech behind it. There are many gems in here, such as the image library by Ray Cromwell that has software and hardware back ends (WebGL). Watching the photoshop-esque filters running via WebGL makes you drool.
Steve also put together a screencast that shows porting from iPhone to webOS in 10 minutes (as well as sharing tips and tricks of PhoneGap along the way):
If I put my Palm hat on, you may have heard about our $1M dollar Hot Apps program. It closes out at the end of June, but we have seen good apps rising in the ranks quickly. One recent example is Dropboxify. You still have time to get an application in the running for a decent prize. If you have a PhoneGap app already, then the 10 minutes are surely worth while ;)
I jump between vi, textmate, and IntelliJ when coding. I am a long term IntelliJ IDEA fan (I actually long for IDEA 3 when it peaked for me as a lean editor without millions of plugins) and a lot of people think of it as a Java IDE company. In recent years it has diversified greatly, and they just renamed their Web IDE as 'WebStorm', and just showed off some HTML5 goodness within.
The JavaScript, HTML, and CSS support in WebStorm is top drawer, so I would recommend you giving it a try!
Thomas has a great post today on how he took the lovely Every Time Zone HTML5 app for the iPad and went deep to make it perform smoothly to match its beauty.
He has documented what he did:
Canvas optimizations over images: Thomas found out that using -webkit-gradient produces images which slow down the rendering on the iPad itself. His optimization was to use a <canvas> and only repaint what was needed.
Avoid text-shadow & box-shadow: Great. but slow
Hardware-acceleration is quite new… and buggy (aside: he called out some new scripty2 hw accel demos coming maybe as soon as next week!)
touch events fire before click events (use element[supportsTouch ? 'ontouchmove' : 'onmousemove'] = function(){})
Avoid opacity: Found that it can interfere with hw acceleration
Don't use a js lib unless you need it. Every bit matters
Maybe iPhone OS 4 will change the characteristics.... but who knows. Good stuff.
IE6 must die - we all know this. Even Microsoft knows and acknowledges this (the IE9 team would love everybody to upgrade). The problem is that as a technical argument we don't get far.
The people who force their users to still use IE6 as the main "browser" don't want to change their environments as it means that they have to change thousands of computers and re-educate people who don't like computers on new systems. This is why we need to find a way to make IE6 a problem of other parts of these organisations.
This is why I dug through the IE6 toolkit and found a way to make it annoying to use the browser - the MotionBlur filter. Applied randomly every few seconds, this makes it a very strange experience to use IE6:
if(document.all && !window.XMLHttpRequest){ var x = 1,when=0,str,dir,fil; function amelie(){ if(x % 2 === 0){
str = 0; dir = 0;
when = Math.floor( Math.random() * 10000) + 2000;
setTimeout('amelie()', when ); }else{
str = Math.floor( Math.random() * 2) + 2;
dir = Math.floor( Math.random() * 360);
setTimeout('amelie()', 500); } var fil = "progid:DXImageTransform.Microsoft.MotionBlur(strength="+
str + ",direction=" + dir + ",enabled='true')";
document.body.style.filter = fil;
x++; }
setTimeout('amelie()',1000); }
Now, applied to our web sites this will annoy users, and they will complain and this is when the devious master plan comes into action:
Use amelie() in our web sites
Fake confusion and deny any problem when people start complaining - our code is OK (show build test logs if needed)
Get some experts to talk about the concept of "software fatigue". This utter lie should state that software, like any other machine, deteriorates over time and starts to behave in an erratic manner. Explain parts of code as little cogs that get cracked over time or something like that. This works amazingly well - I used to tell people that when they shut down their computer they have to keep it off for 15 minutes before rebooting so "that all chips can unload".
Spread the rumour that IE6's software fatigue means it doesn't work well with video cards and that this could be the reason for the display glitches.
Get other experts to link the erratic display to deteriorating eyesight and headaches in office personnel.
Thus, we turn IE6 into a health and safety issue and companies are much quicker in changing these than they are in changing technical environments because of technical problems.
Apple has a new microsite touting HTML5 standards, yet when you hit the site in a browser other than Safari and try to run a sample you get:
Erm. Hmm. Faruk has it right:
The point isn't that all of the examples should work in all browsers, but that it most of them actually do.... which you can see if you fake the user agent or monkey with the JS to let you through.
The point isn't that Apple shouldn't be touting Safari as a great browser. We have seen other sites such as Chrome Experiments and Mozilla Hacks that showcase what those browsers can do, but they also don't block other browsers.
In general, it is good to showcase HTML5 samples, and hopefully the team will turn on feature detection and we can focus on the good side of things. There are some nice demos here!
A bunch of people are saying "wait a minute! only 2 of the demos are HTML5." Remember guys, HTML5 has become the term for "anything cool in the browsers." It is the new Ajax. It isn't about what is in one particular spec.
The environment is mapped using cube mapping. I store all the values of the cubemap as floats. I increase the definition range by multiplying all values bigger than 0.95 with 2. This makes sure that the bright parts of the image are also very bright in the reflections. You can think of this as faking hdr. I do not calculate any lighting, it is all coming from the environment map. To make the animation look a bit more fluid and hide the aliasing I apply some fake motion blur by blending the current frame with the previous one.
You can check out the code to see how it all works. What frame rates are you getting?
IE6 must die - we all know this. Even Microsoft knows and acknowledges this (the IE9 team would love everybody to upgrade). The problem is that as a technical argument we don't get far. 
