Robert Nyman has a new Firebug extension called Firefinder.
The idea is to quickly text CSS selectors/XPath in a document to see what will match, or how many instances of a certain element there are (thinking certain type of heading, for instance).
It offers:
A quick way to filter HTML elements via CSS selector(s) or XPath
Highlight them in the document
List them in the Firebug panel in a collapsable list
There are two types of code. A large pile of crap code, and a small pile of crap code. Favour the small.
The above sentence was explained to Ben and I from a top notch IBM engineer who has written more code than I have had hot dinners.
Less code is good. Less to read, easier to understand, and as Alex mentions, it matters even more for JavaScript client side developers:
JavaScript is different. Unlike nearly every other language, the terseness of JavaScript code is a key determinant in the performance of a web application. The bigger your scripts, the slower your app loads. It’s as simple as that.
He then goes on to discuss the fact that he doesn't want to get into arguments on what lambda means, but rather doing something more simple.... let's just keep it simple:
The best that Erik and I could come up with that is relatively unambiguious for parsers, doesn’t introduce hard-to-type characters on certain keyboard layouts, and doesn’t mess with the semantics of function(){} is this:
The syntax is a tough strange at first, but you can't argue with the terseness. We use $ for document.getElementById-ish stuff, so how about #() for function()? I think I prefer it to other options like (evt)->{}. What would you like?
Micah Snyder of Digg posted on DUI.Stream, an experimental library that implements a multipart XHR technique to bundle resources into one request and then breaks them out at the other end:
One of the ways that high-performance websites like Yahoo suggest speeding up load times is by reducing the number of HTTP requests per page. We started thinking about what we could do to reduce HTTP overhead, and where we could get the biggest benefits from it. Well, one thing led to another and the next thing we knew we were talking about writing a generalized framework for bundling files, sending them through a single request, then separating them for use once they head down the pipe.
We call this technique MXHR (short for Multipart XMLHttpRequests), and we wrote an addition to our Digg User Interface library called DUI.Stream to implement it. Specifically, DUI.Stream opens and reads multipart HTTP responses piece-by-piece through an XHR, passing each chunk to a JavaScript handler as it loads.
Why do this? Well, DUI.Stream will allow developers to drastically improve the speed of uncached page loads by bundling most of their resources into a single HTTP request, with a single time-to-first-byte and no request throttling by the user agent. Additionally, the size of the response has no effect on the rendering time of each chunk, as the client handles each piece of the response on the fly and can inject it into the DOM for rendering immediately, in the exact order you specify. On a high traffic, high-activity site like Digg, we have to display incredible amounts of data on each permalink — typically hundreds of user images within the first 50 comment threads on a page alone, not to mention the UI chrome and actual comment data. (You can see this for yourself: notice the number of HTTP requests that queue up when you expand a page of comments). So our primary use case for DUI.Stream is turning that first long, arduous page load on an empty cache into something nearly indistinguishable from a page of data with fully cached resources.
You can take a look at a demo in action. Reloading the puppy shows how life varies so much on each request. The demos looks like this:
Let’s talk a bit about the architectural benefits of implementing MXHRs with DUI.Stream. Back when the web was based largely on a page metaphor (i.e.: one central document with external references), whenever you loaded the page, the page requested its images, stylesheets, etc, then you were done. These days you’re just as often loading an application; the page progressively enhances into a stateful UI by loading extra stylesheets, scripts and a whole mess of UI chrome after the initial request. Yet, we’re still using the old model flow of get markup –> render markup –> request external resources –> load and display externals.
Take our modal login dialog box for example. In order to reduce requests we bundle its JavaScript in with the rest of the page, we put its CSS up in the header with the rest of the styles, then we request only the markup for the dialog box, render it, and let it fire its own HTTP requests for the images that make up its chrome. In this broken model, HTTP connections and rendering behaviors split our UI architecture up into different parts of the page that all render at different times at the browser’s discretion. Even if we put everything into one cohesive structure and loaded the CSS link, script tag and markup together, they’d still all fire their own HTTP requests and the images would still come in afterwards on the first page load. This just won’t do.
Now, let’s rethink how our login dialog could work using DUI.Stream. We can request a Stream that contains everything needed to render and use the dialog box. As each part comes in, it gets passed through to be built, and renders immediately with no image backfill or delayed JS behavior. The DUI.Stream framework can then pass those resources back into cacheable elements for our next page load, which can happily 302 its way quickly through the rendering process. Pretty sweet right? Right.
Being able to extend the Web to make it your Web is one of the features that makes the Open Web such a fantastic platform. We should all be working on how to lower the bar for users and developers so they can do this with the greatest of ease. Writing browser extensions has been far from easy which makes it more than impressive that we see so many add-ons out there, especially in the Firefox eco-system.
How fantastic would it be if you could also install the functionality without a browser restart? Instant on. That now comes to a Firefox near you thanks to new effort to make it easier for you to super charge your browser. Aza Raskin, Atul Varma, and the Mozilla Labs team have kicked off a new experiment called Jetpack that gives you that and the ability to make extensions as easy to write as a jQuery plugin :)
As this is Mozilla Labs, we are sharing this project very early stage. We want to get feedback and a community to define where this type of thing should go. As such, there will be things missing. That being said, what are the aspirational high level goals?
Web-based
HTML, Javascript, and CSS will be the only tools required to create a Jetpack Feature
Jetpack Features will be streamed & accessible via a URL, just like the rest of the Web.
Jetpack Features will require only the minimum amount of user interaction necessary for security to install: no restarts, and just a click or two and you are good to go.
Jetpack Features will be easily debugged in the browser without restarts using common Web development tools like Firebug
Secure
Jetpack Features will have access to only the privileges they need, and security should always be presented in human-terms, and not technical-terms.
Jetpack Features will be easy to code review — making security problems more shallow, and review times shorter.
Robust
Jetpack Features will use a versioned API so that you won't have to update & revalidate your code for every new version of Firefox.
Jetpack Features will be universal. That means if you develop a Feature for Firefox, it should also run on Fennec, Thunderbird, Songbird, or any other potentially Jetpack-enabled platform.
Jetpack Features can be lightweight but also full featured applications that add to the Web experience, just like Firefox add-ons do today.
Extensible
Jetpack itself will be extensible allowing for the easy inclusion of reviewed & versioned third-party toolkits (e.g. jQuery, Dojo, etc.) and API libraries (e.g. Twitter, Delicious, Google Maps, etc.)
Fly with Jetpacks to Bespin
On the Bespin team we want to make the experience as easy as possible, so we created a jetpack plugin that is installed on the newly minted 0.2 version that we just pushed to bespin.mozilla.com. The new version has a lot of new functionality including integrated VCS support, which was a big push for us as we needed that to dogfood the tool properly!
But, back to Jetpack. With the latest Bespin you get Jetpack support for free. This was incredibly exciting to us as we saw how easy it is to create a new Jetpack feature and install it into the browser in real-time.
Here is a video showing just that. We walk through the creation of a new browser sidebar that looks like this:
var url = "http://mail.google.com/mail/feed/atom";
doc = $(doc);
$.get( url, function(xml){
var el = $(xml).find("fullcount"); // Unread message count
if(el){
var count = el.get(0).textContent;
doc.find("#count").text( count );
}else{
doc.find("#count").text("Login");
}
});
}
}
In the video, when I created a new jetpack via jetpack create it placed this in a jetpacks project in Bespin. This can be version controlled and shared.... just like other Bespin projects.
I am really excited to see where Jetpack can go. Being able to lower the barrier for developers to use simple Web technology that they know (and maybe love?) to extend the browser seems to be a good plan to me. To learn more, check out these resources:
Sofa has been working on a new look, and Aristo has been released to the world via PSD. It is very cool that the look and feel has been open sourced.
All the controls have been updated to use the new style, and we’ve added a few new controls as well, like checkboxes, radio buttons, and segmented controls.
Theming
We didn’t just build one new look for Cappuccino, though. Instead, we built an entirely new theme engine which will let anyone create a theme for Cappuccino. All the properties of the standard controls are fully themeable in all the different “theme states” (like “pushed”, “disabled”, “normal”, etc.). In the coming months, we’ll be sharing new themes with the community, and building a site for users to post their own themes for others to download and use.
Interface Builder
Those of you who come from a Cocoa background are used to using Apple’s Interface Builder tool to layout your Cocoa applications. Thanks to a technology in 0.7 called nib2cib, you can use Interface Builder to layout Cappuccino applications too. All of the classes supported in Cappuccino 0.7 that have Cocoa analogues are included. So, you can drag checkboxes, sliders, text fields, buttons, and lots more. You can even instantiate custom top level objects, or custom view subclasses, which will be converted to the right class in Cappuccino by the nib2cib tool. Once you’re done laying out the UI of your application with Interace Builder, you can use it’s target-action and outlet technology to build up its logic as well.
It is also cool that Narwhal an early implementation of the ServerJS work has made it in there. Great work guys!
Three Googlers, Mark Miller, Waldemar Horwat, and Mike Samuel gave the talk above to discuss how JavaScript is changing, and gets into detail on EcmaScript 5.
Normally when you see a title like jQuery vs. MooTools you get ready for the flame bait. You would expect it even more so if you found out that someone from one of the frameworks wrote the post!
Well, Aaron Newton did just that, and I think he did a very good job at trying to keep as unbiased as possible. He can never be perfect since he has a certain viewpoint, and in fact in some ways when you come from that view you can easily under-share your points.
This isn't a rushed piece. Aaron has been thinking about these things for quite some time, and has really pondered it.
"darkimmortal" has created another really nice visualization of music that uses Canvas and SoundManager2 to do its work.
Do yourself a favour, and hit play to see the funk
The example uses two canvases, one to do the logic wave work, and then it is copied into the main canvas that you see ctxR.drawImage( ctxL.canvas, 0, 0 );.
We are big fans of PhoneGap, the "open source development tool for building fast, easy mobile apps with JavaScript" including apps that run on the iPhone platform.
The PhoneGap team has been winning awards and developers like it.
Upon review of your application, cannot be posted to the
App Store due to the usage of private API. Usage of such non-public
API, as outlined in the iPhone SDK Agreement section 3.3.2 is
prohibited:
" An Application may not itself install or launch other executable
code by any means, including without limitation through use of a plug-
in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple's Published APIs
and built-in interpreter(s).
The PhoneGap API implemented in your application is an external
framework.
This is just wrong. They haven't targeted RegexKitLite or Google Toolbox for Mac, or Joe Hewitt's cool new framework. PhoneGap only uses official APIs, so it isn't doing anything wrong there.
You could assume that this is on purpose, to keep people in the Obj-C sandbox. Or, you could consider the fact that the review process is probably manned by a LOT of people who sit there with check lists. I am hoping that someone at Apple gets to see the outcry from developers and steps in to do the right thing, just like they did when Trent Reznor and many others complained about the hypocrisy of his iPhone app not getting in the store.
The Crap I missed it! crew took on the task of dealing with importing your iTunes XML file, and wanting to give you responsive feedback on the items as they come in. The usual tactic would be to suck in the entire file, and then process it.
Michael Baldwin did more, and here he tells us more:
We wanted to allow users to upload their iTunes library files, so that we could extract artist names (to let users sign up for new album and concert notifications). The problem was that these .xml library files can easily run up to 20MB in size.
Which means 1) long, boring downloads without feedback that it's really working, 2) huge space requirements on our servers to support lots of concurrent uploads, and 3) big memory requirements to process the XML files.
What we did instead was to write a bare-bones custom web server just for this task in PHP (yes, PHP) which analyzes the file as it streams in (storing nothing on disk, and using negligible memory), gradually puts artist statistics into shared memory, and then responds to new AJAX requests every ten seconds which retrieve and remove the artist statistics from shared memory.
The end result for users: as users upload their library file over the course of several minutes, they get to watch their web page fill up with their list of artists at the same time, sorted and even animated. If the connection breaks, they can even choose to continue with just the artists that made it.
The end result for us: we can deal with gigabytes of uploads while using trivial computing resources -- just a couple KB of incoming buffer space and a couple KB of outgoing buffer space.
You can check it out yourself, where it will look a bit like this (but constantly updating!)
Talks about JavaScript are not a rare occasion any more, everybody has something to say about this wonderfully versatile language. Douglas Crockford taught us a lot about the language itself, John Resig and Peter Paul Koch taught us how browsers deal (and fail dealing) with it and there are dozens of screencasts of how to use this or that language.
What most of these talks and videos have in common is application of JavaScript and how to deal with issues that will occur. Information about designing and architecting large JavaScript solutions on the other hand are rare. Satyen Desai now broke the silence and gave a great talk on the architecture and design decisions of the the third generation of the Yahoo User Interface library:
Why choose which Ajax framework you can use, when you can let The Machine tell you! Jim Briggs of Athenz has pointed his decision machine at the age old problem of choosing which darn library to script src!
Here is what Jim told us about the new service:
There has been some discussion lately on Ajaxian about “What is the best framework?” As Dion said in another post, “It is agonizing. It is hard. It isn't pretty.” Both newbies and gurus have weighed in on the subject. As a Ajax programmer, the issue is personally important to me, but rather than cast out another opinion, I’ve created a web site, The Ajax Frameworks Decision Center, that allows anybody to evaluate and select the Ajax or RIA framework that best meets their particular needs. The Decision Center includes a 100-plus requirements model, tools to prioritize, compare, and evaluate frameworks, and a 35 page guide that elaborates on the requirements and the features that you find in frameworks.
In addition, anyone can publish an evaluation of any framework and vendors can publish product information inside the Decision Center. All of this is free.
Objectively, the choice of a framework can be difficult. Subjectively, the choice can be agonizing. The Decision Center doesn’t eliminate all the difficulty, but it provides a way to make a good and justifiable decision and feel confident about it in the end.
This is a brand new service and I’ll respond quickly to any feedback so I can make the site better and so I can help you make better technology decisions now and in the future.
Or see it at work:
You have to signup to check it out, and it may feel like you are filling out a TPS form ;)
After exploring Haskell for some time, I find myself often adopting functional concepts in my daily work. The exposure to functional programming has even affected the set of tools and frameworks I use. For example, having to parse a custom data format I first tend to search for a Parsec clone implemented in the currently used language. This time it was for JavaScript, but a quick Google search did not reveal any relevant projects. Therefore following is the initial attempt to a probably first general purpose parser library for JavaScript, 'p4js'.
For the uninitiated to monadic styles and syntax, the introduction blog post has a short tutorial explaining the basics; the key bits to understand are that:
The function $P() creates a parser object that can be executed on an input using the parse(input) function
Each function on the parser (called combinators) returns an instance of the parser to make invocation chaining easy
Once you define an interesting chain, you can register it with the parser for easy reference, as in p.register(’nat’) and use it from now on as $P().nat()
The current library provides only a dozen combinators, but it is enough to have quite some fun already. Following are few examples:
* a CSV parser,
* a small calculator and
* the tiny math processor that uses the parser not only to parse the input into expression tree, but also to perform expression evaluation and function derivation on the tree, and to draw function graphs (on browsers that support the canvas tag).
Oops! This post got UIzard off the web as the server has 1000 hits a day. It should be back up later. If someone can offer hosting for it, we're happy to forward you to the developers.
The Korean developer community is not that known to people in the west it seems. Language barriers make it hard to communicate and the web design is very different to what we do here. Being lucky enough to work with developers world-wide in the same company I just got reminded of a tool that was built for the Korea Mashup challenge called Uizard.
Uizard allows you to create the UI for a web mashup in a full visual interface. It is like Pipes meets Dreamweaver! The interface of UIzard is fullly created in YUI, you can choose to build either a simple web-app or Google Widgets or Mobile apps. The whole editor is open source and they're looking for more participants.
Simon Stewart is a smart man, and nice chap, that I had the fortune to meet quite awhile back at Google London. He is an active Selenium hacker, and has re-introduced Web Driver that lets you write this Java code:
WebDriver has a simple API designed to be easy to work with and can drive both real browsers, for testing javascript heavy applications, and a pure 'in memory' solution for faster testing of simpler applications.
Interested? Check out the getting started guide where you do a Google Suggest test, and watch Simon from waaaay back in 2007:
Annotate structured data that HTML has no semantics for, and which nobody has annotated before, and may never again, for private use or use in a small self-contained community.
He goes on to detail a number of scenarios such as this subset:
A group of users want to mark up their iguana collections so that they can write a script that collates all their collections and presents them in a uniform fashion.
A scholar and teacher wants other scholars (and potentially students) to be able to easily extract information about what he teaches to add it to their custom applications.
The list of specifications produced by W3C, for example, and various lists of translations, are produced by scraping source pages and outputting the result. This is brittle. It would be easier if the data was unambiguously obtainable from the source pages. This is a custom set of properties, specific to this community.
<p>Hedral is a male american domestic shorthair, with a fluffy black
fur with white paws and belly.</p>
<imgsrc="hedral.jpeg"alt=""title="Hedral, age 18 months"
class="photo"/>
</section>
and extract:
Cat name: "Hedral"
Description: "Hedral is a male american domestic shorthair, with afluffy black fur with white paws and belly."
Image: "http://example.org/hedral.jpeg"
Here is where the fun begins as Ian walks through the issues with the microformat-esque approach, namely the overloaded "class":
there is no way for a parser to know which classes are properties of cats and which are just for styling (e.g. 'photo' used in this example).
I have to admit that I think the baby could be thrown out with the bathwater here. I would hate to see class="cat" type="cat" for example!
<p>I love my cats. My oldest cat is <span property="com.damowmow.name">Silver</span>. <span property="com.damowmow.desc">Silver is <span property="com.damowmow.age">11</span> years old and refuses to eat
alone, always waiting for either Yellow or Blue to eat with
I don't miss the com.* world of Java. I hate the verboseness. It looks so ugly to compare "com.mycompany.foo.cat" to "cat". Is it just me?
Hixie then concludes:
To address this use case and its scenarios, I've added to HTML5 a simple
syntax (three new attributes) based on RDFa. It doesn't have the full
power of RDF, because that didn't seem to be necessary to address the use
cases. It doesn't really have anything in common with Microformats; I
didn't find the Microformats syntax to be very convenient. (This was also
the experience with eRDF.)
I expect the syntax will need adjustments over the coming weeks to address
issues that I overlooked. I look forward to such feedback.
I also found the following Tweets interesting (via @kevinmarks and @diveintomark) as I wrote this :)
@hixie @kidehen URLs are useful, as they resolve. all else is stamp collecting.
@kidehen In practice few people really understand the subtlties of URN vs URI vs IRI vs URL vs Web Address vs Hypertext Reference vs...
All this crap about HTML5 "gatekeepers" is hiLARious. For 6 years, they BEGGED the W3C to work on HTML+1. The W3C said no.
, Firefox
