Blog
May 7th, 2008
The guys over at Ajaxian asked me to do answer a couple questions for them (on video) so I set about forming it into a mini-presentation. I discuss a couple things:
- What's happening in jQuery Core, jQuery UI, and the jQuery Project.
- What upcoming browser features I'm excited about.
- Some of what's coming in JavaScript 1.9.
- Some things that should change about Open Web development.
Video: What's Next in jQuery and JavaScript?
View Flash Version (on Vimeo.com) - Download .mp4 (80mb, Must be Logged In to Vimeo.com)
Update: I also have a small 320x240 video: Download .mov (16mb)
Let me know if you have any follow-up questions, I'll be happy to answer them. Additionally, this is the first time recording a presentation in my new office. I'm pleased with the result (even though the quality of the camera is quite poor). It was quite easy to get set up and perform, which is exciting - I may do some more, short, presentations if there's interest.
Tags: standards, jquery, javascript, browsers
28 Comments on 'What's Next in jQuery and JavaScript?'
April 11th, 2008
Dromaeo is the name that I've given to the JavaScript performance test suite that I've been working on over the past couple months.
I was hoping to hold off on this release for another week or two, while I finished up some final details, but since it's been discovered, and about to hit the Digg front page, there isn't a whole lot that I can do to stop it.
There's a ton of details concerning how it works, and how to use it, on the Dromaeo wiki page. I won't go through too much of it here, but it should clarify most question there.
Probably the most pressing question that'll be encountered (outside of what is answered on the wiki page) is "What is the relation of Dromaeo to SunSpider?" (SunSpider being the WebKit team's JavaScript testing suite).
Right now I'm working very closely with all the browser vendors to make sure that we have a common-ground test suite that is both highly usable and statistically sound (not to mention providing results that are universally interesting). There are a number of outstanding concerns that've been raised by users of the suite, along with a number of concerns that've already been rectified - again, all of this is clarified on the Dromaeo wiki page. It's of the utmost concern that this suite be as applicable as possible. It's very likely that the core suite will be moving to a common working ground where all browser vendors can work on it.
I especially want to thank Allan Branch of LessEverything who provided the awesome design for the site. It's like he tapped into my brain and produced exactly what I wanted - without knowing even it. I highly recommend them, if you have design work that needs to be done.
Tags: testing, performance, javascript, browsers, mozilla
23 Comments on 'Dromaeo: JavaScript Performance Testing'
April 10th, 2008
I just had an epic phone call. I leave my cell phone number on my about me page since I tend to believe in the innate goodness of humans. It has yet to be proven true, thus far, but I'm willing to play the long game.
It started with an email from one 'Dennis Baer', followed immediately by a direct call to me (which didn't afford me any time to read it until after the call). The contents of the email are pretty much spot-on to what what he communicated to me:
Hello
I have endured enough of Firefox and have abandoned it along with K-Meleon and even Opera. For over 2 years the makers of Firefox would not acknowledge that FireFox used huge amounts of memory, would load pages slow and used so much cpu cycles that other programs slowed down. The makers of Firefox in my view just hoped people like me would not bother them with experiences of huge memory use and slowing down of the entire machine! and just go away.
This has come to an end as of today.
I suggest Windows users abandon Firefox for now and get a browser named Enigma.
You can download it for FREE at http://store.democratz.org in which you will find the link just right above the products section.
I have 35 tabs open right now and it does not slow down the machine. The page loading appears much faster than Firefox and when you use it, you will laugh at Firefox slowness. This browser works better than Opera and Safari and Internet Exploder too.
Enjoy.
I realize that you work for Mozilla. You will not like finding this out when droves of people will abandon the Firefox Behemoth. I'm spreading the word far and wide about Enigma. Noone should have to put up with Firefox any longer until Mozilla gets their act together.
I just found enigma on the web yesterday and I now consider myself free free free from this Firefox problem.
Ironically, the link that he provided doesn't seem to actually work. While I was on the call with him I googled for the phrase 'Enigma browser' and found two, nearly-identical, pages that both provide this 'browser':
- http://www.suttondesigns.com/
- http://www.advancedbrowser.com/
(I don't recommend downloading them, they may contain virii or spyware.)
So while I listened to his enraged ranting I read up on this browser. Apparently it's a skin on top of Internet Explorer 6.0 - in sort of an MDI:
He repeatedly stated phrases like "Firefox use to be good, but it's gone downhill - it sucks!" and "It's even better than Opera and Internet Exploder [sic]!". I asked him if had had a chance to try Firefox 3 to which he stated "Yeah... it BLOWS!"
I could only assume that he didn't know that I worked for Mozilla - until he mentioned that I was "the only Mozilla employee that he could find on the Internet." Of course, during all of this it was all I could do but keep from laughing out loud. I was also on IRC, updating my co-workers in the Evangelism team as the call progressed - much to their surprise and amusement. I was sure to ask him plenty of questions - I figured that I'll only be sold this browser once, might as well make it worth my time.
After he was done enumerating the benefits of the Enigma browser, over Firefox in particular, I thanked him for his time and explanation. I'm still about 70/30 thinking that this was serious vs. being a huge prank. Regardless, my hat is tipped to one Dennis Baer: That took some serious balls - astroturfing on a scale never before seen.
Update: This quote from their FAQ is fascinating on so many levels: "Is Enigma Browser a secure browser?
Yes, Enigma Browser is secure. Since it's based on Internet Explorer, Enigma Browser is as secure as Internet Explorer."
Tags: mozilla, firefox, browsers
42 Comments on 'Attack of the Enigma Browser'
March 26th, 2008
There's an important compatibility regression coming up with the releases of Firefox 3 and Safari 3.1 (and any other browser that will natively implement getElementsByClassName) concerning old releases of Prototype (pre 1.6).
In talking with Tobie Langel, of the Prototype team, he recommends the following:
We've already deprecated document.getElementsByClassName and Element#getElementsByClassName [in Prototype 1.6].
The easiest workaround, which does not require upgrading, is to replace calls to document.getElementsByClassName('foo') with $$('.foo') and calls to Element#getElementsByClassName('foo') with Element#getElementsBySelector('.foo') or Element#select('.foo') (version >= 1.6.0) depending on which version of Prototype you are running.
A number of users noticed this problem during the Firefox 3 betas and after the release of Safari 3.1:
If you have a site that's using an old version of Prototype, and getElementsByClassName, then it's recommended that you either upgrade or perform the above steps (probably sooner, rather than later, so you don't hit compatibility problems).
How This Issue Came About
It's important to realize how a problem like this can come about so that you can prepare for it within your development. This core issue arises from the fact that Prototype was implementing a property on the global document variable which was, eventually, codified into the HTML 5 standard and implemented in some browsers.
Looking at their code we can see something like this:
if (!document.getElementsByClassName)
document.getElementsByClassName = function(instanceMethods){
// ...
};
This code in, and of, itself isn't necessarily the problem. If you implement a JavaScript library that completely, 100%, implements a specification then it's probably safe to do the above in that manner (base2 is a good example of a library that does this well).
A problem occurred because, in their implementation of the method, they were adding new methods to the returned array (such as .each). This meant that users began to use the method in this manner:
document.getElementsByClassName("monkey").each(Element.hide);
Which subsequently broke when an actual getElementsByClassName implementation came on the scene (since the result returned from the method wasn't 'enhanced' with the each functionality - amongst other methods).
Attempting to implement any sort of future specification can be a real fools game. Since standards are often imperfect (such as not providing an .each mechanism) or frequently change - attempting to match that functionality with a library can be incredibly difficult. More often than not it's simply a better idea to implement brand new methods that can never conflict with upcoming functionality (as the Prototype team has done in the 1.6 release).
Tags: javascript, browsers, prototype
22 Comments on 'getElementsByClassName pre Prototype 1.6'
March 18th, 2008
getBoundingClientRect is a method, first introduced by Internet Explorer 5 (and now included in Firefox 3), which provides the top, right, bottom, and left offset coordinates of an element. After PPK mentioned this method in a recent post of his, poo-poo-ing its applicability, I thought I'd take some time to show how useful it can be. What makes this method so especially handy is that the alternative means of computing an element's offset position is so horribly slow and buggy that it borders on the comical.
The general purpose of this method, or of similar implementations, is to allow the user to get the visual top/left position of an element (such that if they absolutely position an element from the document it would be on top of the desired element - making things like tooltips possible, to name a single application). This means that you have to take into account a huge number of quirks. In no particular order here are some choice bugs which make this very difficult:
- Handling table border offsets.
- Fixed positioned elements.
- Scroll offsets within another element.
- Borders of overflowed parent elements.
- Miscalculation of absolutely positioned elements.
For example, looking at jQuery's implementation of .offset() (which provides the top/left offset of an element) we can see a number of these quirks worked around. A phenomenal amount of work has gone into the method, by the excellent Brandon Aaron, in order to "get it right" in a cross-browser manner. Check out the extensive suite of tests that are backing it up, as well.
This is where getBoundingClientRect comes into play. For a visual comparison look at the green boxes (representing the getBoundClientRect-based implementation) versus the red boxes (representing the normal cross-browser implementation).
The reason why the getBoundingClientRect implementation is more than 1 line is due to two facts:
- It doesn't include the document scroll offset (which is a simple addition).
- Internet Explorer's handling of <html/> element border widths is completely whack.
In comparison to the default technique, however, this is a veritable walk-in-the-park.
Now, not only, is this method simpler to use it's also insanely faster. Stupifyingly so. Considering that you no longer have to perform all sorts of hacks, or walk the tree to rectify miscalculations, the result is quite impressive.
View the following jQuery UI drag-and-drop sorting demo page in Firefox 2 (drag the items in the grid, at the bottom) and then view it in Firefox 3, doing this same:
http://dev.jquery.com/view/trunk/ui/tests/sortable.html
Night and day. I've also uploaded a simple movie demonstrating the difference.
I absolutely encourage everyone to check this method out. It can serve as a near-drop-in replacement for your offset needs - and will gracefully work in new browsers that support the method.
Tags: dom, javascript, browsers
11 Comments on 'getBoundingClientRect is Awesome'
March 13th, 2008
Mozilla developer 'Pavlov' wrote up some extensive details on memory use in Firefox 3. I highly recommend that you check it out.
I borrowed some of his data and created another view of the results. For example, here's the results from Windows Vista of a number of browsers:
Note that both Safari 3 and IE 8 crashed during the test (which was a page runner which automatically opened and closed groups of web pages) so accurate numbers weren't able to be achieved for them. Some preliminary numbers show Safari 3 on a similar path to IE 7 (Stuart mentioned that IE 8 showed a similar path, as well).
It's great to see the massively-improved memory use of Firefox 3. It far excels anything that we offered, previously, and seems to best all other browsers on the platform.
Now, obviously, Windows Vista isn't the only platform available. I, personally, use OS X and am interested to see the memory numbers there as well. One portion of Stuart's blog post that I found to be particularly interesting was the discussion of measuring cross-platform browser memory use - and how difficult it can be. Here's how he explains it:
The short summary is Windows Vista (Commit Size) and Linux (RSS) provide pretty accurate memory measurement numbers while Windows XP and MacOS X do not.
...
On Mac, If you look at Activity Monitor it will look like we’re using more memory than we actually are. Mac OS X has a similar, but different, problem to Windows XP. After extensive testing and confirmation from Apple employees we realized that there was no way for an allocator to give unused pages of memory back while keeping the address range reserved.. (You can unmap them and remap them, but that causes some race conditions and isn’t as performant.) There are APIs that claim to do it (both madvise() and msync()) but they don’t actually do anything. It does appear that pages mapped in that haven’t been written to won’t be accounted for in memory stats, but you’ve written to them they’re going to show as taking up space until you unmap them. Since allocators will reuse space, you generally won’t have that many pages mapped in that haven’t been written to. Our application can and will reuse the free pages, so you should see Firefox hit a peak number and generally not grow a lot higher than that.
I think it's great to see these numbers come in. In many ways Firefox 3 is going to be a very different browser from its previous instantiations. I've, personally, been using it as my primary browser for a while now and have enjoyed the increased performance. It really does feel - and really even look - like a whole new browser.
If you'd like to try Firefox 3, especially without disturbing your current setup, it's really easy - and I've even written up instructions to help you out.
Tags: firefox, performance, browsers, memory
27 Comments on 'Firefox 3 Memory Use'
March 6th, 2008
Our day has finally come. CSS coders got some love with Internet Explorer 7 - us JavaScript folk got absolutely nothing. In fact, at last count, all we got were a couple new bugs to deal with (file:// requests not working via XMLHttpRequest and <object>.getElementsByTagName("*") always returning no elements).
Internet Explorer 8 is our release.
The first beta was pushed out today and it shows huge promise. It's already achieved way more than I would've expected and it's made me hungry for more. If you had bet me that Microsoft would be mentioning the phrases "ARIA", "SVG", and "MathML" in their release notes I would've lost.
Here are my thoughts on a bunch of the browser features:
W3C: querySelector
A super-fast way of finding elements based upon a CSS selector. The second browser to implement the selectors API has hit the market (behind a WebKit nightly release).
It's important to realize that any selectors here are completely reliant upon the browser's native selector implementation. IE8 is only shooting for CSS 2.1 support - which means that you really shouldn't be holding your breath for CSS 3 selectors. As I mentioned previously these blackbox APIs are going to be a source of never-ending hair-pulling and struggle going into the future.
HTML 5 Party!
I was hoping for some HTML 5-compliant features to land - well, hoping isn't the right term, perhaps 'feverishly expecting the worst' is more correct. However we can see that we've been graced with 4 full feature implementations from the spec - fantastic!
HTML 5: window.location.hash
Already supported fairly well by most browsers. Modifying window.location.hash changes the page URL and adds the page to the history (allowing for back-button simulation in Ajax applications). IE went a step further and broadcasts the hashchanged event (the first browser to do so, as far as I know).
HTML 5: DOM Storage
A feature that I discussed previously in which data can be persisted in a way that supersedes the use of primitive cookies storage. This has been in Firefox since version 2 but is absent from Opera and Safari.
HTML 5: postMessage
As I discussed previously postMessage serves as a way of communication across frames with simple text strings. IE 8, Opera 9, Firefox 3, and WebKit nightlies all support this feature - making it the only one with complete browser support.
HTML 5: Offline Events
As I've written about previously this is an easy way of detecting connectivity within the confines of JavaScript. With it we can write graceful offline Ajax applications. Firefox 3 and IE 8 appear to be the only browsers to support this feature.
XDomainRequest
This is an interesting feature for doing cross-domain requests but doesn't appear to conform to the existing Cross-site XMLHttpRequest work which is in Firefox 3. Even at that it appears to be quite crude - forfeiting any form of filtering or security controls for a simple boolean "yes/no" header.
Seeing this new API concerns me. The Cross-site XMLHttpRequest work may be in some flux, as some API points are still being hammered down, but it's doubtful that the resolution will end with something identical to what's being described by Microsoft.
DOM bug fix love
getAttribute/setAttribute have seen a major overhaul - in short: They now behave like they should and as they do in every other browser. The notorious issue of accessing relative/absolute href/src attributes is also resolved - which is just great. They also saw fit to add hasAttribute.
Also newly fixed/added:
.ownerElement and .ownerDocument - Finally we have a unified way of dealing with iFrames.getElementById returns elements by id - ONLY. Been such a long time coming, thank goodness.- Doing
getAttribute("checked") now returns "checked" instead of true.
- <button/> values are actually submitted now, instead of their inner text values.
- Dynamically created (or modified) radio buttons are now checkable.
I simultaneously feel both joy and anger in seeing these fixed. Happy that they're being released and anger for the fact that I had to struggle through them and that they now consume some portion of my brain.
W3C: Events
This is one area that is completely absent from this beta. We are still stuck with IE's attachEvent system - no addEventListener in sight. I don't know how serious they are about supporting Acid3 but it includes a test for addEventListener so they may want to consider it extra strongly.
I can partially understand their desire to keep their existing API but I don't understand why they have no interest in, also, adding addEventListener, etc. to complement what's there. I assume it's because they would now have to support concepts like event capturing.
I'm really disappointed with this. This should've been a top priority fix before implementing new psuedo-XHR systems like XDomainRequest.
JavaScript Language
The IE team has made some big improvements in improving garbage collection issues, memory management, and performance - all of which will be greatly appreciated in everyday applications.
Although, I mis-spoke slightly earlier: While IE8 is been great for JavaScript developers I was implying "JavaScript + DOM" developers. For pure JavaScript it's completely frustrating: There doesn't appear to be any new pure-JavaScript features in this release. I can only hope that we'll see more in a future beta release.
ARIA Support
This one completely blew me away. ARIA is a fantastic specification for empowering web applications with the ability to clearly communicate their intentions to a screen reader. The biggest hurdle with the effort, up until this point, has been the lack of IE support - obviously this will no longer be the case. Firefox, IE, and Opera all support ARIA now. The WebKit team doesn't appear to have interest in implementing this feature, which is a real shame.
Embedded SVG
Support for embedding namespaced elements within XHTML is now possible. This means that you can now do inline markup for SVG and MathML, amongst others, and have it "just work" (as long as you have their associated plugins installed). It's probably a bit much hoping for native SVG support, but I'll take what I can get.
Firebug for Internet Explorer
We finally have a heavily-Firebug-inspired tool inside Internet Explorer. To quote Joe Hewitt (creator of Firebug): "I couldn't be happier that Microsoft completely copied Firebug for IE8." I have to agree - a tool like this has been a long time coming and it's greatly appreciated. Only the Internet Explorer team would've ever been the ones to build this tool - there's simply too much information here that's unavailable to typical IE extensions.
Browser mode toggling
At first glance this feature makes the most sense for seeing if your IE 7 page will work ok in IE 8. In actuality, however, this will end up being very useful for developing a standards-compliant page (in IE 8, FF, Safari, Opera) and then toggling to see what the result is like in IE 7. This is so much better than the IE 6 to IE 7 jump where you have to keep your browser in a virtual machine in order for it to run side-by-side (according to Microsoft, at least - even though there were standalone solutions).
Bug Feedback
The Internet Explorer team is collecting feedback from select beta testers and publishing the bugs on a publicly-accessible site. This a huge step in the right direction (going from no communication to some is great). "Common" users are forced to vote for their "favorite" bugs to try and catch the eye of an IE developer. It's a strange situation but one that shows progress, at least.
Conclusion
In all I'm positive about this release, even with all the ups-and-downs. Seeing features like querySelector, ARIA, and postMessage helps to warm my frosty, bitter, heart. While there's still some major faux-paus in this release (no new JS langauge features?, no W3C events?, no CSS3 selectors?) I think we can, at least, be excited to see what happens in the next beta.
If nothing else the Internet Explorer team has done a great job of tackling many of the expectations of the development community - if they continue this trend I don't think anyone will be left disappointed.
Tags: ie, browsers, html5, dom, javascript
58 Comments on 'JavaScript in Internet Explorer 8'
March 4th, 2008
I'm really excited about Microsoft's switch today to make standards mode rendering the default rendering style, going forward - even at the cost of "breaking the web." I think this is going to have serious positive ramifications for the whole web ecosystem, which is just fantastic. I can't imagine this decision coming lightly and I greatly respect them for making it, even turning about after plenty of criticism.
There's one little jewel tucked away in Microsoft's press release, that helps to shed some light on why this massive change of heart may have come about:
“While we do not believe there are currently any legal requirements that would dictate which rendering mode must be chosen as the default for a given browser, this step clearly removes this question as a potential legal and regulatory issue,” said Brad Smith, Microsoft senior vice president and general counsel.
Ah ha! It all becomes clear, now:
The straw that broke the camel's back? Even if that's not the case, whatever the final reasoning was, I'm just glad that this conclusion has been come to. The web will soon be a much better place for everyone.
Tags: ie, microsoft, browsers
19 Comments on 'Unbreaking the Web'
·
« Previous entries
