Archive for the ‘browser’ Category.
Performance on the web has always been a hot topic to talk about specially when you talk about page load, but you don’t see as often people talking about perceived load which is related to how fast the interface responds to the user interaction, in this area WebKit based browsers like Safari and Chrome from my point of view have always been ahead.
I’ve just finished chapter 7: Writing Efficient JavaScript by Nicholas Zakas on Steve Souders‘ new book, Even Faster Web Sites, where he presents several string optimization techniques to improve JavaScript performance and wondered which algorithm does String.indexOf method implements on JavaScript engines (aka ECMAScript engines).
A few months ago I’ve asked this question to Yahoo! fellow Douglas Crockford and he said the ECMAScript standard does not require a specific algorithm, so it could vary with each browser. You can check that on section 15.5.4.7 of Standard ECMA-262. I decided then to download the most popular open-source JavaScript engines source codes and found mainly 3 algorithms:
Continue reading ‘String searching algorithms in JavaScript engines’ »
A lot of the power of JavaScript comes from the ability to be an event-driven language. Dealing with event listeners is not a simple task considering different implementations by Internet Explorer and the rest of the world. After some searching on internet you have probably found some cross-browser solutions, although they are not always as efficient as it possibly could.
I’ll present some of them and explain their design pros and cons. All them do exactly the same, attach actions to events, none of them does browser sniffing to determine which event attachment technique to use, they use feature detection instead. For clarity sake, browser sniffing is a common technique on which an application tries to find out the user’s browser, usually by examining the useragent string looking for vendor/version and is a common source of detection problems. On the other hand, feature detection is a much safer technique where the application checks if a certain feature (function, property) exists (is implemented) in the browser and once this feature is defined, use it, otherwise another feature is checked as a fallback.
Some design patterns presented here are well covered in Ross Harmes & Dustin Diaz’s Pro JavaScript Design Patterns book.
Continue reading ‘Cross-browser event listener with design patterns’ »
[UPDATE - july 2nd]
Since my post yesterday, the firebug developers have released another version of the tool (1.4.0b4) it seems more stable, great job!
————
When Mozilla launched Firefox 3.5 a couple days ago, I was forced to upgrade my FB (firebug) to the new 1.4 beta version, although the new FB has been greatly improved it still has a lot bugs as you’d expect on a beta version, but that’s not the bad part, the new FF3.5 is really fast and has really cool new features but FB is making the browser choke and freeze all the time, it’s no news that FB has become more and more slow and buggy each version.
Fellow Yahoo! Nicholas Zakas has blogged about some browsers limitations and recently ran some tests in order to check browsers call stack sizes.
Not surprisingly, different browsers have different call stack sizes. Also not surprisingly, the method that they use to determine the call stack varies as well. The various call stack sizes I could measure are (give or take, might be off by 1 or 2):
- Internet Explorer 7: 1,789
- Firefox 3: 3,000
- Chrome 1: 21,837
- Opera 9.62: 10,000
- Safari 3.2: 500
In each case, the browser will end up stopping your code and (hopefully) display a message about the issue:
- Internet Explorer 7: “Stack overflow at line x”
- Firefox 3:”Too much recursion”
- Chrome 1: n/a
- Opera 9.62: “Abort (control stack overflow)”
- Safari 3.2:”RangeError: Maximum call stack size exceeded.”