If more and more software developers are going to be developing browser-based applications using technologies such as JavaScript, Flash, and AJAX, we will need to see the Web browser become a much more capable platform. In short, the browser will need to duplicate much of the work that has been done over the years in the operating systems field.
KDE 4.0 was released several days back, and thanks to the KDE Four Live CD, I was able to give it a try with very little effort. Having used it for about a day and a half now, I’d like to share some of my impressions of this new release of KDE. Specifically, I will be focusing on the Konqueror 4.0 Web browser. But please keep in mind that I have not performed any formal studies or benchmarking, and what follows is merely my opinion.
Today I was reading an article concerning the design of new back and forward buttons for Firefox. While such thought and experimentation has its place, I’m not so sure it’s appropriate considering the current state of the Firefox codebase.
Recently, I read about how, as of the middle of November 2007, there were about 700 blocker bugs against Firefox 3.0. It is anticipated that about 80% of those bugs will not be fixed before Firefox 3.0 is released. And this is for a release that is already a number of months behind schedule.
Several days back, Opera 9.50 Alpha was released. For the time being, you can read more about the new features in Opera 9.5. Some of the notable enhancements include a better ECMAscript engine, improvements to the layout algorithm, faster font rendering, and a more responsive UI.
Today, thanks to this article, I saw a very telling diagram giving an overview of the “Mozilla Platform”. Before you read on, I encourage you to study the diagram for a few moments.
Earlier today I witnessed the wasteful nature of pointless JavaScript effects first-hand at the Blogger main page. The effect in question is visible under the “BLOGS UPDATED AT …” text immediately under the Blogger logo. In short, the effect involves the title of a recently-updated blog fading away every second or so, to be replaced with the title of another blog. So as can clearly be seen, it’s not essential in any way. It’s completely cosmetic, although it doesn’t even look particularly good.
Every so often we hear of technologies being brought together in a way that will mean nothing but performance trouble. After reading an article about IronMonkey, I think we might just be witnessing such a situation.
The article describes the goal of the IronMonkey project as this: IronMonkey is setting out with the goal of mapping Microsoft’s Common Intermediate Language (CIL) to ActionScript Byte Code (ABC), allowing additional language implementations, such as IronPython and IronRuby, to run in the Tamarin Virtual Machine.
We often hear about how JavaScript-based Web applications will be the wave of the future. Some people have gone so far as to say that these applications will completely replace the traditional, desktop-based applications we use today. The advocates will list off supposed benefits, but will rarely listen when serious problems are shown with their favourite technology. Take, for instance, the major problems I noticed with a JavaScript-based Breakout clone.
Last night at the pub, a friend and colleague of mine was telling me of a recent experience he had at a company he was doing some IT work for. I think the lesson learned is a very important one, and thus I wish to share it. But first I’ll describe the situation he encountered.
I was reading today about Pyro Desktop. As the Pyro homepage states: Pyro is a new kind of desktop environment for Linux built on Mozilla Firefox. Its goal is to enable true integration between the Web and modern desktop computing. By merging the Web with the desktop, Pyro offers the first big step toward a new future for the Web and the applications built for it.
