HTMList.com, A Web Development Blog by Synapse Studios

Developing a “web 2.0″ application brings with it a host of new challenges previously unfelt or easily ignored with older, single-page-load-per-action apps. The browser has evolved from a simple page renderer to an application platform that busily executes JavaScript and receives, parses, and displays loads of new data without ever leaving the page. Developers are now struck with the challenge of ensuring their applications manage memory properly and efficiently—your JavaScript can leak memory, killing the user experience on your site, but also impacting the user’s complete experience with their system across the board.

To date, it’s been a bit of a struggle to manage memory, since developers are essentially forced to rely on their operating system’s memory managers to even monitor the memory usage of their browser. Even then, testing can be frustrating, as Firefox, for instance, stores all tabs in the same process. Google Chrome is multi-threaded; each tab is its own process. Chrome also features its own built in task manager, so you can identify which page is using exactly how much memory, CPU, and bandwidth. Even at its most detailed, the stats available only show aggregate memory and virtual memory usage—these abstract figures make troubleshooting individual pieces of your code difficult to say the least.

The folks over at Mozilla’s Developer Tools Lab are looking to change that by building a memory analysis tool that helps devs understand exactly how their application is using memory, and the behavior of the cycle (garbage) collector:

We plan on the initial implementation of this tool to be simple. For memory usage, we want to introduce the ability to visualize the current set of non-collectible JavaScript objects at any point in time (i.e., the heap) and give you the ability to understand why those objects aren’t collectible (i.e., trace any object to a GC root). For the cycle collector, we want to give you a way to understand when a collection starts and when it finishes and thus understand how long it took.

Ben Galbraith and the team are soliciting help and feedback, so if this is an issue you’ve had to deal with in the past, make sure you comment.

A New Memory Tool for the Web | Ben Galbraith’s Blog via Ajaxian

Tagged with: browsers, firefox, Google Chrome, javascript, memory usage, mozilla, Mozilla Foundation

Posted in: Cool Stuff, Development

Lunascape is a new browser that allows you to switch rendering engines on-the-fly. Internet Explorer, Firefox, and Google Chrome/Apple Safari all use different rendering engines and JavaScript engines to display your pretty web pages to you. This is the root cause of browser incompatibility issues—different engines interpret things (like web “standards”) differently and so you see pages display differently. This is the bane of a lot of developers, as we have to fight the many, many quirks that abound when we use certain parts of the DOM or certain JavaScript or CSS tricks. For a lot more on these issues, QuirksMode is a great resource.

Lunascape presents an interesting product, though one that’s only in the Alpha stage, so I’m sure we’ll be seeing a lot of things evolve from them. As a developer, I have Firefox, Internet Explorer and Google Chrome all installed and at the ready. It’s pretty simple, though a bit annoying, to boot up IE to make sure a page renders properly, even though we develop under Firefox.  (There are FF extensions that make this a simple right-click affair, however.) Lunascape simplifies the process a bit by allowing you to switch a tab’s rendering engine just with a right-click. And it works, for sure.

But I begin to question the utility of a browser that lets me switch rendering engines, but provides me with very few debugging tools or console access. We develop under Firefox because of things like the Web Developer extension and Firebug. These superb debugging tools let us delve into the DOM and help us identify our many AJAX transgressions. Without these tools, though, the workflow isn’t improved enough to justify a switch from just running the browsers separately.

Now, Lunascape currently supports IE extensions, so perhaps Firefox extension support is on the horizon… but this seems like something that could be very difficult to accomplish, given that XUL (which powers Firefox and the window chrome surrounding it) is a part of Gecko that exists a bit existentially to the site being rendered: Though, if Lunascape itself is XUL-powered, then that would help considerably.

Even still, the appeal just isn’t there for me. Lunascape clearly is betting on its three-trick-pony concept, but that only appeals to developers who know what a rendering engine is. Firefox is a considerably better browsing option for regular end users, so they’re left needing to improve the value proposition for developers and to give us a reason to switch. And they haven’t done that yet. One way they could start is by offering advanced debugging tools, better if they’re rendering engine-specific. Another might be to allow for regression testing in IE: Allowing us to render in older IE engines, like how IETester works.

For now, I plan on leaving this in the Alpha bin it came in and working with FF 3, Chrome/Safari and IE, side-by-side.

See also: TechCrunch & Lifehacker‘s coverage. (The latter, whose screenshot we borrowed.)

Tagged with: browsers, chrome, developers, firefox, gecko, ie, lunascape, rendering, rendering engines, Reviews, safari, trident, workflow

Posted in: Development, Reviews

HTML 5 is coming our way. So goes the theory, anyway. (Recent chatter puts widespread adoption by user agents at close to a decade out from now… or more.) It is still a moment that many of us are eagerly anticipating. I remember drooling over my keyboard while reading through the HTML 5 Specifications the first time. We have been stuck with HTML 4.01/XHTML 1.0 for a long time and it is time to see some changes.

(In fact, HTML 4.01 has presented us with the longest gap in HTML revisions—it’s been 10 years since it was released; HTML 3.2 only lasted about a year, from 1997 to 1998.) There are some great things we have to look forward to that will make life a lot easier for us developers and designers. We’ll take a look at a few of them after the jump.

Read More »

Tagged with: attributes, browsers, css, dom, html, html 5, javascript, tags, w3c, websites, xhtml

Posted in: Design, Development, Tech News

Favicons started as a helpful icon identifier for websites back when you’d peruse your bookmarks and track down your favorites. Nowadays, they serve a much more useful purpose: they help brand your site both in browser tabs and in the address bar. Further, if you make use of Firefox’s Bookmarks Toolbar folder like I do, (called the “Links” folder on IE; it usually appears beneath the address bar) you can reduce each of the bookmarks to display just the favicon, allowing you to cram a bunch up there.

Favicon is short for “favorites icon”. A favicon is essentially a resource file in the Windows icon (.ico) format that is associated with a website. Even though the ICO filetype is Windows-based, Linux and Mac systems can still edit and serve them. Favicons are displayed by your browser as a 16×16 pixel image, but should be rendered as a 32×32 image that is then scaled down, as ICOs are scalable to 32×32 in some cases.

[It should be noted that 16x16 is an incredibly small canvas to work with. Chances are, you're going to need to abandon whatever supercool idea you have for a favicon—you're not going to be able to have a mythical dragon slaying a knight guided by a fairie. You might be able to get the dragon's eye. I'm just sayin'.—Ed]

The Windows icon format allows you to embed multiple files into one, so your favicon file should contain both sizes. Fortunately, there are great tools available to create these favicons, and they don’t cost a thing. Take a look at exactly how to make your favicon and links to the necessary tools after the jump.

Read More »

Tagged with: browsers, favicon, html, icon, urlicons

Posted in: Design, How To