Pinderkent

Today at Reddit there was a posting about a simple 2D bouncing ball physics simulation written in JavaScript. This is the latest example of a simple JavaScript demo that, for some inexplicable reason, gets many people excited.

Thankfully, there are some other people who see these JavaScript demos for what they truly are: something to not get excited over! One of the best replies to that Reddit posting points out how it ought to be easier to make such demos in JavaScript than in other programming languages. And that poster also correctly points out that there's no need to get excited over such trivial applications.

Another reply pointed out the demo's extreme similarity to Pong, a game from the early 1970s. It's also somewhat similar to Breakout, a game from the mid-1970s. Indeed, many of these JavaScript demos are often no more original than what we had over 30 years ago. Mind you, the equivalents from 25 or 30 years ago ran on computers with a small fraction of the processing power and memory of a typical desktop PC today. The developers back then actually had significant hardware constraints, unlike those behind the JavaScript demos of today.

Several others noted just how poorly this demo performs, even on modern systems when using modern Web browsers. One such user reported that it could animate at most five balls on his laptop with an Intel Atom processor before it became unusable. Although Atom processors aren't the most powerful by any means, they should be more than sufficient for the computation necessary to perform basic 2D collision detection and animation.

One user reported that it lagged in Firefox 3 on Mac OS X. Another reported performance problems while using Firefox on Linux.

As usual, we can't have a discussion about JavaScript demos or games without mentioning the unreasonable memory requirements of these demos. I think that poster's claim of 200 MB of RAM usage is, unfortunately, quite realistic. Using Firefox 3.0.5 on Linux, just starting up Firefox resulted in a process that was using 456 MB of virtual memory (as reported by top), with a resident size of 75 MB. Drawing a slightly downward sloping horizontal line, which allowed for approximately three balls to be on the screen simultaneously at the default drop rate, bumped the virtual memory usage up to 523 MB, with 176 MB resident. And extending that line somewhat longer, to allow about eight simultaneous bouncing balls at the default drop rate, bumped the memory usage up to a whopping 587 MB virtual, with 204 MB resident. After leaving the demo running for several minutes, it had stabilized at that point.

I don't think I'll ever understand how somebody could possibly become excited, even in the slightest, over these sorts of JavaScript demos. What they demonstrate was usually demonstrated better, using a fraction of the resources and processing power, two or three decades ago! The performance is typically terrible, even on higher-end PCs a month or two old, using modern Web browsers. It's not surprising to see 100% CPU usage, as well as hundreds of megabytes of memory being used. So in the end, all they do is exhibit essentially no innovation, poor performance, poor resource usage and prove yet again how awful JavaScript is for such simple applications. In short, there's absolutely nothing to be "amazed" or "excited" about with these JavaScript demos.

It has been over a week now since Apple released a public beta of their Safari 4 Web browser. During this time, much has been written regarding this preview of what will likely become a very widely used Web browser. This article aims to summarize some of this discussion.

Reviews and First Impressions

• Safari 4 Beta Released: Focuses on the Mac OS X version, giving a good synopsis of the major changes and new features. Sees the speed gains as the most impressive improvement.
• Safari 4 Beta is Worth a Look: Points out the ideas drawn from Google Chrome. Doesn't seem overwhelmed by the browser, but doesn't sound displeased, either.
• Safari 4 First Impressions: Also points out the inspiration drawn from Chrome and Opera. Mentions how the Windows version feels and behaves more like a Windows app, but also very supportive of the UI updates in the Mac OS X version.
• Safari 4 a big step up, but not as far as rivals: Not really a negative review, but suggests that while improvements have been made, there's nothing really exceptional about Safari relative to Firefox, Opera and Chrome. Does seem to support the UI changes.
• Safari 4 Beta - Nice and Speedy: A generally positive review, with focus on the better performance, the UI updates, and Top Sites.
• Safari 4: A positive review with emphasis on Top Sites, the new tab placement, the other UI updates, and the performance improvements. Includes video commentary.
• Safari 4 Beta: UI Disaster: Points out the problems with Safari's tab placement, with comparisons to Chrome. Suggests that he won't use Safari on his Mac if the tabs remain where they are.
• Defending Safari 4 tabs: Does acknowledge the problems with Safari 4 Beta's tab placement, but hopes that "this is the first experiment to bringing system-provided tabs to applications."
• Safari 4: First Impressions: Describes Safari 4 Beta as a "big step forward." Also points out the heavy influence of Chrome on Safari 4, but suggests that it's more advanced than Chrome when it comes to, for example, bookmark management.
• Safari 4 Beta: Impressed by the speed of Safari, but thinks he will remain a Firefox user.
• Safari 4 UI breakdown: A review of the Safari 4 public beta that focuses almost entirely on the various UI changes. Mentions some of the less-obvious UI updates and changes that other reviews may have missed or glossed over.
• Safari 4 Review: A general review of the new and updated functionality, but also mentions bugs and problems relating to Mail.app and 1Password.
• Safari 4 Beta: the best browser for Windows?: A review by a Windows user who is quite impressed with the Safari 4 beta, including Top Sites. Noted some bugs, but mentions that it "shows a lot of promise and once it is ready, I will likely make it my primary browser on my Windows machine."
• First Look: Safari 4 Beta: A relatively detailed summary of the changes and new features of this beta. Generally impressed with the browser.
• First impressions: Apple Safari 4 beta: A review that focuses on the Windows version. Includes a number of screenshots, including visual comparisons with Chrome and Firefox. Suggests that Safari 4 "bridges the gap between Firefox and Google Chrome."
• Safari 4 Beta - First Look: A detailed review of Safari 4 Beta, including numerous screenshots of both the Windows and Mac OS X version. After using it, however, the author says that "Firefox is still my browser of choice."
• Safari 4: Thoughts and Comparisons: Emphasis on the Windows version, with a generally negative opinion of the UI changes on Windows at first. Was impressed with the speed improvements.
• Safari 4 wows web with speed: Emphasis on the speed improvements, but also mentions Top Sites and the tab placement changes.
• Safari 4: Webkit gets dressed up: The author of the review says that his "biggest pet peeves with Safari have been addressed with this release." However, also mentions that it's "just a pretty toy to play with."
• Headed towards the finish line, Safari 4 takes the lead!: Says that Safari 4 Beta is "easily the best browser for the Mac." Is impressed with the functionality that appeals to Web developers.
• Safari 4 Public Beta first impressions: Some comparisons between the Mac OS X and Windows versions, with it being suggested that the Windows version is slower.
• Safari 4 First Thoughts: Happy about the JavaScript performance gains and location bar improvements. Describes the Top Sites UI as feeling "overly glitzy." Somewhat conflicted about Cover Flow.
• Safari 4 beta, a closer look: One of the more detailed reviews. Pleased with the speed improvements, and unconcerned about the new tab bar placement. Warns about possible Mail.app problems.
• Reader Reports: Safari 4: Many short reviews and summaries from a number of users.
• Safari 4 Review: Sees putting the tabs at the top of the window as a good idea. Describes Cover Flow as "useless".
• Safari 4 Beta's new tabs are particularly bad on Windows.: My own review, pointing out the problems I noticed with the new tab placement on Windows.

Benchmarks, Multi-browser Comparisons and Speed Tests

• Safari 4 - This is one fast browser!: A very positive review of the Safari 4 beta. Focuses on the similarity to Chrome, and points out the new features, with much emphasis on its performance. Includes performance comparisons against the other mainstream browsers.
• Safari 4 benchmarked: 42x faster than IE 7, 3.5x faster than Firefox 3: Includes some benchmarks of the Windows and Mac OS X versions of Safari against the other popular browsers. Suggests that the beta of Safari 4 is "the fastest browser on the planet."
• Browser Speed Tests: How Safari 4 Stacks Up: Speed and memory usage benchmarks against other popular browsers.
• Hype Check: Safari 4 can't beat Google Chrome: Includes some benchmarks that suggest that Safari 4 Beta is not as fast as Chrome 2.
• Safari 4 Beta looking good but...: Likes the Top Sites functionality, but thinks the tab-related updates could use some changes.

Tips, Tricks, and HOWTOs

• Safari 4 Hidden Preferences: Points out some of the Safari 4 configuration options, and what changing them will do.
• Foxmarks for Safari 4 Beta: Discusses the compatibility of Foxmarks with the beta.
• Give Safari 4 the GUI It Deserves: Provides instruction regarding how to make changes to the appearance of the UI of Safari 4.
• How to run Safari 4 beta and Safari 3 on the same mac: As the title indicates, this describes the steps necessary to run both Safari 3 and Safari 4 on the same system.
• 14 Tips for Safari 4 Beta: As the title of the article says, it gives 14 tips regarding Safari 4 Beta. Points out potential problems with Xcode, GrowlMail and various plugins.
• Want to enable 1password in the Safari 4 Beta? Here's how.: Describes the steps necessary to enable 1Password with Safari 4 Beta.
• A collection of additional Safari 4 Beta hidden settings: Another list of the adjustable preferences for Safari 4 Beta.

In general, people seem quite impressed with Safari 4 Beta. Almost everyone noticed the significant speed improvements it brought. A number of the reviewers mentioned how obvious it is that Safari 4 has been influenced by Google's Chrome. With respect to the new tab placement, Mac OS X users seem to be more accepting, while Windows users tend to have mixed feelings, or be against it completely. Overall, my impression is that it won't be as revolutionary of a browser as some people maybe think it should be, but it will likely be a browser that many people are pleased with, and an increased market share does seem likely.

Douglas Crockford's recent article suggesting the creation of a project to develop a so-called "HTML 4.2" specification makes some very good points. He is quite correct when he points out that when developing standards, "It is easy to pile features on top of features, but that ultimately produces systems that are far too complex, insecure, and unreliable." This is indeed what we have seen with HTML 5, and what we have also seen with the ES4 efforts.

It's quite good to see somebody who is so well-known and respected within the Web development community pointing out such harsh truths. But I suspect what the Web needs is more than just more sensible standards. The entire platform as a whole is badly in need of a "reset".

The Web is truly starting to show its age. After all, it has been around for nearly 20 years now. It's remarkable how well it has handled the growth and change it has experienced. But after nearly two decades, it likely is time for some serious changes.

Web browsers themselves are one area where a "reset" is needed the most. A few days back, Ian McKellar made some pointed observations about the state of the Mozilla platform. Namely, he pointed out how the current codebase is extremely complex, lacks even remotely acceptable documentation, and isn't as appealing to developers as WebKit is.

The need for browsers today to maintain so much backwards compatibility no doubt has a significant cost in terms of browser implementation complexity. Even at a very basic level, there are numerous standards of HTTP, HTML, CSS, and JavaScript that need to be supported in order to provide just an adequate browsing experience. Add into this mix the need to accept blatantly incorrect HTML markup and JavaScript code, and it's not a recipe for software that's easy to implement and test.

At some point, it will become beneficial to all to stop trying to build upon so many years of cruft, experimentation and legacy. Instead of focusing so much energy on extending what already exists, the core concepts and functionality of what makes up the Web could be consolidated and a more reasonable platform developed. In essence, the entire Web platform needs a "reset" at all levels. Trimmed-down versions of tomorrow's standards only serve to procrastinate with respect to the effort that will eventually be needed to clean this mess up.

Apple recently released a beta of their Safari 4 Web browser. This release brings with it some relatively significant UI changes. The change that is perhaps most obvious, especially in the Windows version of Safari, is the placement of the browser tabs. By default, they are now within the title bar of the main Safari window: This is a most unfortunate place to put the browser tabs, with this location causing a number of usability problems.

The first problem is that it's unexpected. Although there has been some UI consistency loss within the Windows world over the past decade, I don't recall us ever seeing behavior like this in such a well-known application. The window title bar has solely been for identifying the window, selecting the window, and performing other manipulations of the window itself. It has always been "outside" of the application, physically and in terms of functionality.

A related problem is that of selecting the window. The mere act of giving it focus by clicking on the title bar can inadvertently cause the displayed tab to change. This can be pretty annoying, and now requires the user to be more careful where the click in the title bar when giving focus to Safari.

This is perhaps the most subjective of the problems, but I just find the title bar to now be distracting. It's much too "busy" now. Aside from the application icon in the top-left corner, we now have a mix of tab borders, close buttons, browser title text, the button for creating new tabs, and the typical three minimize-maximize-close buttons at the top-right corner.

Another significant problem occurs when running Safari fullscreen under a RDP session, or under a virtual machine like VMware. Such software can optionally put some command buttons centered at the top of the screen, to allow for the parent window to be minimized, maximized, closed, options adjusted, and so forth. While such a panel can usually hide itself, I've always found it useful to leave it expanded. Traditionally, such panels have slightly overlapped the title bar of any maximized windows, but have otherwise been unobtrusive. Unfortunately, they now obstruct a core feature of Safari. In the best case, the tab is only partially hidden, or totally hidden in the worst case. One must reduce the size of the Safari window just to switch tabs, and then maximize it again.

This idea should be considered a failure. It's a complete mistake to put such core application functionality into the window title bar like that. It doesn't work well for the user, other applications too easily interfere with it, and it's much more distracting. Worst of all, there's really no added benefit. Whatever small amount of area is gained within the browser window does not make up for the inconvenience and problems the new tab position brings.

I read through an article today that shows the struggles Web developers go through to perform basic layouts using CSS. In the article's particular example, it's simply some images and some associated textual content displayed in a grid-like manner, with the amount of text being variable.

In short, it's a practical, real-world data display that should, one would think, be very easily accomplished using CSS. As is often the case when using semantic markup and CSS, what should take only a few minutes balloons out into a battle against unexpected behavior, browser incompatibilities, browser bugs, and so on.

Whatever benefits CSS might have brought are quickly eliminated by the time and effort necessary to get the content displaying even remotely correctly. But we must also consider that the end result becomes nearly unmaintainable. Other Web developers working with the code later on will likely not appreciate or understand the struggles that went into getting everything working in the first place. Making even minor changes might not be possible, or might be extremely time consuming, with much care needed to avoid rendering incorrectly in various browsers.

I'm not suggesting that HTML tables would necessarily be a better solution. I just find it extremely bothersome that such a simple task so quickly becomes such a huge hassle when using CSS, with the end result being quite fragile. This is what we'd expect to see from an immature technology, yet CSS has been in the works for roughly 15 years, and has been implemented by a number of different groups. It's pretty pathetic, really.