Right now, Blogs all over the world are reporting about the great new browser Google has and I too decided to take a look. After all, it's Google we're talking about here, so it has to be good.

And it is, kinda. Google is trying to create a browser for the "casual" crowd. People who spend less than an hour a day using the internet, people who don't have a lot of tabs open and who freak out when a program crashes. People who don't have friends who can help them set up their computer and are therefore stuck with Microsoft's slow and buggy Internet Explorer. And for that purpose, Chrome is actually quite good.

Let's start with the installation. Run, say whether you want to import your Internet Explorer favorites (it didn't even give me an option to import my Firefox bookmarks). Done. It's really that simple and straightforward. Of course I'd like to have more options, but I'm not really the one Google is trying to win over, so that's OK.

Then it starts. And my first thoughts are "Man, this is ugly". Where other browsers try to look like native applications, Google has chosen the opposite route. The buttons on the top look a bit like Vista's, but that's about it (besides, I'm not using Vista, so it would be the wrong OS anyway). Everything else is in a Google typical gray/blue theme that looks more like a webpage than an application. The fact that it integrates poorly with the OS alone is almost a dealbreaker for me, but once again, it might actually appeal to people who do little enough with their PC that they value glamour over consistency. However, it seems like usability was not really that interesting to the Google folks either: The grey/light blue color combination provides little contrast and my first few clicks where actually attempts to click on the nearly invisible scrollbar.

Next step. The welcome page has opened and greats me with what to expect the next time I come here (a list of most used pages). I already know that, but decide to take a look at the help anyway, which turns out to be a little page with a few UI tips. Sadly, the navigation breaks and pressng "back" doesn't work as expected as it only changes the title of the page to "Untitled". I have to admit, I expected a bit more polish here and while it isn't really a dramatic bug, it's not a good thing to present the user with it on his first launch.

The basic browsing functions work fine, after all WebKit has been used a few times before and by now is pretty good. The Javascript engine also is almost as fast as promised and generally does a good job. Nothing to complain about here.

So I decide to take a look at the taskmanager to see how Google's idea to seperate the tabs into individual processes has worked out. Not to well for me as it turns out. Chrome is using 267MB of memory right now, while Firefox with the same pages open uses 186MB. Again, Chrome turned out to be very bad for my habbits... I can't even see any of my tab's titles anymore, because there's no tabbar scrolling. But would your typical "casual" surfer open 30+ tabs at once? Probably not. Again, a major issue for me turned out to be just fine for the target audience.

And so it goes on and on. No addons, no error console, no developer tools, nothing that a casual user won't miss. And that's really all there is to it. If you want just a simple browser, then this is fine.

The only question that remains for me: Why then not use Safari itelf, instead of Google's version?

Oh and one last thing. Whoever wrote that comic didn't do Google a favour. Because to me, this "that's how we do it and that's the only right way to do it" talking sounds just terrible. Mockery doesn't really inspire sympathy and when a friend asks me "which browser should I install?" it might be this bit that keeps me from saying "Try Google Chrome".

Labels: browsers, google

When you look around on security mailing lists you'll probably an increase in security warnings relating to web applications... many of them based on JS code injected into a webpage.

This has lead to the uncomfortable situation where pages that are based on usercontent can not trust their users to provide JS as part of their submitted content. So now we can share video, audio and other passive media but anything interactive is out of the question.

What to do about it? The JS security system is entirely based on domain names and some providers have resorted to running all user js code on a seperate domain... but this again limits the usefulness of JS because it can only operate within the assigned iFrame. Others are trying to run the JS code through code analysis tools to find out if it is doing anything "forbidden".

But who are we kidding? Blacklist attempts have never worked so far and the thing about web security is that even a single attack can leave data from dozens of apps exposed.

The alternative is quite simple, but to my best knowledge has never been tried: Implementing a second language in JS, running protected in a seperate sandbox, allowing only whitelisted calls and if necessary filtering the results. Is this possible? Certainly? Is it hard? Not as hard as one would imagine? Is it slow? Definately slower than true JS but still fast enough to be of use.

Let's tackle these questions one by one:

Is it possible? Every language that can implement basic text parsing can implement it's own parser... it's really as simple as that. And it JS it's even easier because we have a bunch of text processing tools like RegularExpressions that make parsing quite straight-forward and simple.

Is it hard? Not really... many of the requirements for the interpreted language can be mapped to native behaviour. For example: the garbage collector can work for the interpreted language as well if we map stacks and variables in the interpreted language back to native objects.

Is it slow? In order to answer this question we have to remember how code is usually stored in high level languages: The CodeDOM. The codedom is a simple, object-based tree structure where any number of atoms make up expressions. Once we have parsed the expressions into this DOM and inserted all implicit behaviour, executing code is really just a matter of walking this tree. So each interpreted operation means running the atom handler and following the tree. The atom handlers usually don't change and can therefore be compiled by the JS handler and the jump to the next atom is just following a single reference. Combine that with the fact that we can replace known atom combinations with optimized functions and you'll see that this is fast enough for the majority of simple web apps.

Just think about it what people could do if their apps were not restricted to their iFrames... youTubeOS? mySpace dynamic layouts? The sky would be the limit (That and the rules inserted into the interpreter... mySpace could opt to give users full access over the page's elements, but not their ads and not the document and window elements).

Labels: ajax, browsers, javascript

xmlTree is a tiny, little XML processor for PHP that doesn't even offer 10% of what the XML spec has to offer, but still manages to do almost everything a normal developer needs (and besides, it's easy to extend). It's meant for all those people that

• Hate to use code that they cannot possibly understand
• Prefer small libraries
• Don't expect the XML Library to validate their data
• Don't need the XML library to handle data that's not trustworthy
• Don't need automatic character conversion, like " to \" or <>

So, it's really quite minimalistic. It was initially written to store configuration data for another program, but ended but managing quite a bit of the HTML code too.
Essentially, it provides the following features:

• An XMLElement class that provides parentNode, childNodes, tagName and attributes. It also provides a value for text nodes
• A Javascript like DOM manipulation system, featuring such gems as appendChild, setAttribute, getAttribute, removeChild, getElementsByTagName, getElementsByName,getElementById, toXML and toFile, all of which (with the exception of the last two methods) behave almost exactly like their Javascript counterparts.
• An XMLDocument class with html, head, title and body (nothing special, but it makes life easier)
• An XMLParser class that turns an XML string into a XMLElement tree.

You can find the source, along with some more notes here. Oh, and it's GPL too.

Labels: ajax, browsers, php

I've updates the Canvas 3D Renderer with new sample data, a few performance tweaks, background image support, support for colored polygons and a few tweaks here and there.
Note however that the car you see is not a sprite, it's simply an image put in front of the canvas for my amusement. So don't get confused if it doesn't behave the way you expect it to do.
Right now the sample data has around 200 faces and while the code is almost ready for shared vertices (which means that one vertex belongs to many faces, resulting in a much lower number of vertices in memory and therefore a lot less calculations) right now a face still consists of 3 vertices, meaning that it does about 500-600 rotations, projections,clipping and collision tests per frame update, with very few optimizations so far and for that the speed is (at least in my opinion) amazing.
What's interesting to me are the test results... I didn't time them, so I can't give you any numbers, but
Opera 9.1 is definitely the slowest one, but with a very steady framerate, which probably means that drawing and garbage collection are very fast (as these tend to take up a variable amount of time), but arithmetic is slow.
Firefox 2 is pretty steady as well, and a lot faster than Opera.
Firefox 3 Alpha is certainly the fastest browser, but with a very unsteady framerate. I guess the new garbage collector is causing this while drawing speed is increasing thanks to Cairo.
You can still find it at http://tapper-ware.net/canvas3d/ (Note that the background gets drawn during the first screen update after the image has loaded, so it will probably take a second or two to appear the first time you load the page. Screen updates happen whenever you move around).
P.S. I'd appreciate it if you could send me mail if you want me to answer your comments. hansschmucker at gmail dot com

Labels: ajax, browsers, games, javascript, mozilla

OK, so yesterday evening I started working on a new Javascript minigame: Sudoku.
I know what you're going to say: there already are way too many Sudoku games around. And you're absolutely right.
Problem is, there are very few good games around, and even less that run in your browser and almost none that require no plugins.

There's already a first Alpha version available here (but with just a single puzzle):
Here!

The feature list is already longer than for most other Sudoku games:

1. Use the buttons at the bottom to add notes to the selected field.
2. Use the buttons at the right to confirm a number.
3. Use the "?" to get all notes automatically.
4. You can't confirm numbers that collie with other numbers in the field, however you can enter numbers that are simply wrong.
   

So what's still missing (aside from a new UI):

• Automatic Solver
• Generator
• Tabs for different versions of the same puzzle
• True handwritten notes
• Menu to enable/disable solvers.

Did I forget anything? Tell me!

Update:
Now there are 1000 new puzzles available. While there is still no generator in this, I have instead opted to instead create a converter for the files generated by QQwing, A free Sudoku generator published as OpenSource. Now, on launch the game will select a random number between 0 and 1000 and load the level with that number. However there are no difficulty levels yet: While QQwing supports this, it is not being used yet. All levels are difficulty "Expert".

Labels: ajax, browsers, games, javascript

I'm a bit of a Javascript fan and since I don't have anything better to do right now I though I could tell you about a few typical errors that even the guys over at Google, along with 99% of all pages I know, make.

The problem is that people learn Javascript as well, a Script language, not a proper programming language... which is a shame because Javascript itself is probably one of the most comfortable languages I know. And because they don't see it as a proper programming language they just hack their code until it works... for now.

The worst abomination onto JS is probably browser sniffing: It's a pretty simple technique that's easy to understand which is probably why beginners tend to use it, however it's also a technique that a) requires a lot of testing, b) requires a lot of updates and c) goes completely bonkers when new browsers are released.

What browser sniffing (a.k.a. useragant sniffing) does is "ask" the browser about itself and then taking appropriate measures. Seems simple, right?

Well if it is so simple, then what would happen if you ask a browser if it is a "Mozilla"... Surprise! Pretty much all major browsers (including Internet Explorer) claim to be Mozilla. So let's ask about MSIE to make sure which Mozillas are actually Internet Explorer. Oops, Opera and a few others report that too. OK, then how about finding out which ones are really Mozilla by looking for "Gecko". Oh, Safari says it's "like Gecko". If you want an almost complete list, have a a look here.

You see: it doesn't work and it's really a shame that people still use this first-grader technique if there's a much easier alternative: Method sniffing.

In Javascript, every function or method that does not exist has the value "undefined". So if you want to use something that you are afraid isn't available everywhere, you just ask if the browser supports it directly, instead of asking for the browser and then assuming that a certain browser supports this or that.

For example, lets say we want to use the addEventListener method and as a fallback the attachEvent method, then we simply create a wrapper function:

function wrapperAddEventListener(obj,type,callback){
if(obj.addEventListener!=undefined) obj.addEventListener(type,callback,false);
else if(obj.attachEvent!=undefined) obj.attachEvent("on"+type,callback);
else alert("Sorry, your browser is not supported");
}

And that's it. And it works for pretty much everything, except for some strange HTML behaviours. Now my minions: Spread the word.

The next time I'll be looking at the scope of Variables in JS... a topic that isn't understood by more than a handfull of people, eventhough it's not that difficult. See you next time.

Labels: ajax, browsers, javascript, mozilla

Previous Posts

• Google Chrome? Good for some people, not good enou...
• Accelerating per-pixel collisions in Canvas
• Secure web applications - using JS to create a new...
• If I had a Hammer OR Why RFID in passports is a re...
• CSI moves to Origo
• You've gotta love some quotes
• CSI - Client Side Includes
• Smoothly fading slideshows and hover buttons
• Sam and Max
• Spore - It's not that scary!

Archives

• November 2006
• December 2006
• January 2007
• February 2007
• March 2007
• August 2007
• January 2008
• August 2008
• September 2008