I just finished doing some talks on geo hacking (slides are available here) and how to use some of the Geo technologies Yahoo and Google provide as part of a University gig in Atlanta.
As a lot of the students liked the idea of APIs like GeoPlanet and Placemaker but had a hard time getting their head around them I thought it a good idea to build a small JavaScript library that does the job for them.
This finds the visitor's location (on W3C geo API enabled browsers it asks them to share it - otherwise it detects the IP and locates this one on the planet)
Kangax has forked John Resig's HTML parser which parses the HTML and sends that into the Minifier. This has rules that do things like whitespace optimization, comment removal, and collapsing boolean attributes (e.g. disabled="true" -> disabled).
He also has a linter going:
While working on minifier, I realized that oftentimes the most wasteful part of the markup is not white space, comments or boolean attributes, but inline styles, scripts, presentational or deprecated elements and attributes. None of these can be simply stripped, as that could affect state of the document and is just too obtrusive. What can be done, however, is reporting of these occurences to the user. HTMLLint is even a smaller script, whose job is exactly that—to log any deprecated or presentational elements/attributes encountered during parsing. Additionally, it detects event attributes (e.g. onclick, onmouseover, etc.). The rationale for this is that moving contents of event attributes to external script allows to take advantage of resource caching.
Harmony is a new drawing tool, a HTML5/Canvas experiment with great potential. It provides some unique brush styles, and can produce some great-looking charcoal pencil style sketches, among other things. Better to try it out than explain it in words.
Creator Mr. Doob (Richard Cabello) explains how he used Canvas to make it darker the more you draw over it:
The whole thing is quite modular so I can keep adding more brush styles whenever I get inspired. During the process I found out that, for some reason (apparently lack of hardware acceleration), Firefox and Opera do not support context.globalCompositeOperation = 'darker'. This was on the HTML5 spec before but got removed. Just so you know what I'm talking about, this is like the "multiply" blending in Photoshop. Webkit does support it tho. I hope they put it back on the specs and all browsers support it.
You can also save images using data URI encoding.
As it works on webkit, he made sure it worked on the mobile Android and iPhone browsers. No multi-touch as yet, but the touch UI still makes a nice input mechanism.
modulr is a CommonJS module implementation in Ruby for client-side JavaScript
Ruby? what does that have anything to do with it? Ah, its from one of those Prototype guys isn't it.... Yup, Tobie is at it again, this time with modulr:
modulr accepts a singular file as input (the program) on which is does static analysis to recursively resolve its dependencies.
The program, its dependencies and a small, namespaced JavaScript library are concatenated into a single js file.
The bundled JavaScript library provides each module with the necessary require function and exports and module free variables.
This can also help sharing that CommonJS code. I recently did just that and had some:
In case you want to use YUI3 but really really like jQuery syntax :) OK, it breaks the whole sandboxing idea of YUI3, but that's a small price to pay, right?
Andrew Hoyer shows his canvas Fu with Cloth, a great experiment using nice physics.
What makes this simulation special is the speed at which everything is computed. Javascript (the language this is written in) is not exactly the most efficient language for this type of computation. This being said, much time was spent squeezing out every little detail that slows things down.
The most computationally expensive part is trying to satisfy the constraints. To do this requires the calculation of distance between two points. This is easy to do with a little math, but that often involves an expensive square root. This is something that cannot simply be thrown out either, so what do you do? You approximate it. There are lots of mathematical tools for approximating functions, in this case I chose the first couple terms of a taylor expansion.
Marcus Westin has created a new templating language called fin. It is an interesting beast, and he gave us a run down:
Since this past November I've been working on a realtime templating system I call "fin". I'd love to get some eyes on it, and hope that you'll find it exciting. There is no demo, but quite a bit of information and if you're on OS X it's trivial to get the system set up on your own machine.
The basic idea is this... Rather than describing your data, you describe how you want your data to be viewed. Fin takes it from there in terms of persisting new data as it gets created. In addition, all views of any piece of data is globally synchronized. If one computer makes changes to a user's name for example, then those edits are reflected for anyone viewing that user's name as well, keystroke by keystroke. The way you create value views and input views goes like
You can also chain references to items, for example (( Value user.friend.name )). Now, if user.friend.name changes, then the Value view is instantly updated. Even cooler, if the user's friend reference changes to a new friend, then the value view will accurately reflect the new friend's name.
To get started on OS X 10.6 is as easy as
git clone git://github.com/marcuswestin/fin.git
cd fin
sudo make install-node
make deps
make run-couchdbx
And voila! Just navigate to localhost/path/to/fin/examples/from-html.html and you're good to go.
Would we all like Steve to sit down with us on our project and do a performance case study? Well, we may not get that, but we are getting to at least sit in on others.
Steve has kicked off his long awaited series that runs performance case studies on third party content. I have been talking to Steve about this for a couple of years, so it is great to see it. It is a sensitive topic as you never want to show up a team when you are just trying to help and educate.
Steve goes into detail and finds a lot of short comings. You could probably guess some of the bad actors. Mr. document.write() appears for example. We get the problems, and proposed solutions to the issue. Steve also tries to note what a user of third party content can do regardless of if the third party guys fix their issues (put in iframe!).
Here are the most important performance issues along with recommended solutions.
9 HTTP requests, 52 kB transferred over the wire, and 107 kB of JavaScript (uncompressed) is a lot of content for a single widget.
Recommendations:
Concatenate these three scripts: JS_Libraries, widgetjsvars, and omnidiggthis. (eliminates 2 HTTP requests)
Run Page Speed’s “Defer loading JavaScript” feature and see how much of the JavaScript is not used. If it’s sizable, delete it. (This feature is currently broken in the latest version of Page Speed, but a fix is imminent.) (eliminates ?? kB)
Optimize the images – widget-logo.png and get-widget.png can both be reduced by ~3 kB. (eliminates ~6 kB)
Sprite widget-logo.png and shade-com.png. (eliminates 1 HTTP request)
The widget’s scripts block the main page’s content from downloading. Looking at the waterfall chart, the main page includes the image “digg-waterfall.png” (row 10). Notice how this image doesn’t start downloading until after all the scripts for the Digg widget are received. Recommendations:
Instead of loading the scripts using document.write, load them without blocking other downloads. The scripts are already suffering from race condition behavior, as evidenced by this comment from widgetjsvars:
1:
if (!digg || !digg.$) setTimeout(function() { diggwb(obj); }, 200); //hack for IE not loading scripts that are included via document.write until it decides too
So it probably isn’t too much work to avoid race conditions when making all the scripts load asynchronously.
The widget’s stylesheet blocks the main page from rendering in IE.
Recommendations:
Instead of loading the stylesheet using document.write, load it via JavaScript as described in 5d dynamic stylesheets.
Four of the resources aren’t cached long enough. Recommendations:
Two scripts aren’t cacheable because they have an expiration date in the past. widgetjs is part of the snippet, so it can’t have a long expiration date, but something like an hour or a day would be better than a date in the past. widgetjsvars could have a far future expiration date since its URL is specified in widgetjs.
The three images are only cacheable for a day. They should have a far future expires header since the image filename can be change if it’s modified.
There are approximately 30 inefficient CSS selectors. Because this stylesheet is part of the main page, the selectors will cause the overall page to render more slowly when these selectors are applied to the elements in the main page. Recommendations:
The Opera team has released 10.50 for Mac and along with it some impressive performance numbers:
Stabilization Improvements: You will find that this build is much more stable than the pre-alpha build.
More polished user interface: The whole UI is more polished now. We're still not done yet, and expect more polishes and improvements in the builds to come.
Opera Unite: Opera Unite now works with this release. You can browse through and download unite apps through the Unite Apps Repository.
HTML5 <video>: This beta now supports the html5 <video> tag.
Widgets as standlone apps: We've already talked about widgets as standalone apps, but this functionality was till now, only available in windows builds. Now even in this build of 10.50 beta for mac, you can use widgets as standalone apps. Check out this ODIN post by Patrick Lauke on standalone widgets for more information.
New Developer Tools Menu: You can go to 'View->Developer Tools' Menu to access common and usefull tools for developers, such as Opera Dragonfly, cache information, the error console, the source code of the page, and more.
According to tests run by Computerworld, Opera 10.5 was nearly 15% faster than Safari for Windows and almost 20% faster than Google's Chrome, the previous No. 1 and No. 2 browsers. Opera's preview was more than twice as fast as Mozilla's Firefox 3.6, over eight times faster than Opera 10.10, and 10 times faster than Microsoft's Internet Explorer 8 (IE8).
We tend to talk a lot about WebKit, Moz, and IE.... congrats to the Opera team on their impressive work.
