phoboslab

Posts tagged with “Web Technology”

MPEG1 Video Decoder in JavaScript

With still no common video format for HTML5 in sight, I decided to implement an MPEG1 decoder in JavaScript. I know there's already an h264 decoder for JavaScript around, but it's huge, compiled with emscripten and quite complicated.

An MPEG1 decoder sounded like a relatively simple and fun weekend project. While the real world use cases for this are of course a bit limited, I still learned a whole lot about video codecs in the process. The size of the source is just around 15kb gzipped and the performance is quite okay-ish - a 320x240 video easily plays with 30fps on the iPhone5.

Read complete post »

Tuesday, May 7th 2013 / Comments (12)
Tags: JavaScript, Web Technology, Canvas

Hate IE with a Passion

There's no denial that HTML5 Gaming is going to be huge. It was a big topic at this year's GDC and there's an arcade machine running an HTML5 game currently at SXSW. I've been at Future of Mobile and onGameStart last year, giving some insight and showing off my Game Engine. HTML5 Gaming is here to stay.

In my talk at onGameStart I had a short section dedicated to Internet Explorer: I apologized to the one guy from Microsoft in the audience - then switched to a slide stating "Hate IE with a Passion" and a next one showing the IE logo with a speech bubble, proclaiming "Please kill me!", disgustingly set in Comic Sans because "IE doesn't deserve a better font".

The part about IE is 26 minutes in.

But wait, didn't I say in an earlier post that IE9 works great with my Game Engine?

IE9's smoothness on the other hand is remarkable. Of all browsers and systems I tested, IE9 subjectively produced the best results.

IE9 was a huge leap forward from IE8 and all the things that are implemented in IE9 work pretty well. There are some problems with <Audio>, but they are not as disastrous as they were with Chrome and Firefox a few month ago. And Microsoft's implementation of the <Canvas> element is one of the fastest around. IE9 is a solid browser.

So where's the problem?

It's all the things that IE9 doesn't do. And I'm not talking about some nice to have features, but Microsoft's general attitude. They pretty much ensure that IE will always stay obsolete and be every developer's last choice. Here's how.

Auto Updates and Release Cycle

This is a big one. IE8 was released in March 2009, IE9 in March 2011 - two years later. There's no release date for IE10 yet, but it will take at least until March next year. Microsoft has finally decided to have some sort of auto update, but it will leave a lot of users behind. It will take years until all IE users have updated.

Compare this with the Chrome and Firefox guys: they release a new version every 6 weeks now. And the best thing - users don't even notice. Chrome's update mechanism is truly invisible to the average user. If you're doing some cutting edge web stuff, you no longer have to say "works in Chrome 17", but just "works in Chrome". Nobody cares about the version number, because everyone is always on the newest version, or at most two versions behind.

From a developers standpoint, this is invaluable. It brings us certainty. We can be sure that any feature that was added 12 weeks ago has now arrived for the vast majority of users.

Not so with IE. Paul Irish recently had a beautiful article about the clusterfuck that is Microsoft's lifecycle policy. It's just sad.

<Video> and <Audio> Codecs

Firefox, Chrome and Opera support the open source WebM and Ogg Theora video codecs and the open source Ogg Vorbis audio codec. IE supports none of these.

I know WebM is controversial, but damn, they are Microsoft. They should be able to come up with a solution that's good for the web: Buy the MPEG-LA and release all h264 patents in the public domain; improve WebM; invent a new, open video codec. Whatever, just do something.

With Ogg Vorbis I can't even think of single reason not to support it. Over the last few month I asked a few guys from Microsoft why they don't support Ogg Vorbis - nobody could give me an answer. Nobody knows. Maybe we are not complaining loud enough?

WebAudio, Fullscreen, Mouselock…

There are ongoing efforts to implement better audio APIs, fullscreen support, mouse lock (all desperately needed for games) and a whole bunch of other stuff. And browser vendors are working together to form a common standard - yet, Microsoft is curiously absent from these discussions.

Of course IE will support those features eventually. Maybe in version 11 or 12, after every other major browser made it clear that these are useful and important. Then it will take another 3-4 years for IE users to update. So we can safely use the fullscreen API for IE in about 6 years. Awesome.

Microsoft should spark those discussions instead of trying to catch up years later.

IE is slowing everyone down and makes your life as a developer more complicated. It actively prevents progress. Microsoft just looks at what everyone else does, implements the bare minimum they need in order to not be completely ignored and annoys us with a yearly update cycle and millions of users unable or unaware to update. This is not how the web works.

I wrote this post because I still care about IE - I still haven't given up completely.

What can you do? Force Microsoft to fix IE or let it die?

Hate IE with a passion!

Wednesday, March 14th 2012 / Comments (22)
Tags: Random Thoughts, Web Technology, HTML5

Syntax Highlighting in 1023 bytes of JavaScript

My entry for the JS1k contest is a JavaScript Syntax Highlighter implemented in 1023 bytes of JavaScript – just one byte short of the contest limit. I also submitted an uncompressed and somewhat more readable version of the source.

The highlighter recognizes keywords, strings, comments (single and multi line), numbers, regexp and punctuations. And as far as I can tell, it works perfectly. It handles escaped characters as well as /* "strings" in comments */ and "comments // in strings" correctly.

I really doubt that I'm going to win anything with this though, as there are already many other unbelievably awesome demos.

Update: Stripped a few more bytes (1005 now) and formatted the source so it's actually readable. I also made the script a Quine – a program that prints its own source. You can find the new version here.

Monday, August 9th 2010 / Comments (1)
Tags: JavaScript, Web Technology

“Load More” is not the Answer

How do you display a list with a huge number of items? Easy: just paginate – split your list into several pages and let the user click through them one by one. Google does it with their search results, every forum software in existence splits a thread after N posts, my Blog only shows 8 entries at most. It's a solved problem.

Some years ago Microsoft had a different idea with MSN Search (now Bing): Infinite Scroll. If you do an image search on Bing and scroll down far enough, more results will be loaded on the fly and appended to the current page. There's no need to click a Next Page link. I don't know if they were the first to do it, but they certainly were the first I remember.

Today, many sites are using Infinite Scroll or the slightly less ambitious Load More button. And it constantly annoys me. It's not so much that most implementations are done very carelessly, but that the idea is inherently broken and really can't be done right.

Take Twitter for example. Say I'm writing a Blog post about how John Gruber was all the rage about X a few days ago. Naturally, I want to have a link to his tweets from said day in my post, so I visit twitter.com/gruber, click the more button two or three times, till I see those tweets and… now what? How do I link to this page? Do I have to link directly to twitter.com/gruber and tell my readers to click more a couple of times? How often? Well, it of course depends on how chatty he's been since I posted my story.

You might say that this issue could be easily fixed by utilizing the Fragment Part of the URL. So after I click more the URL would change to twitter.com/gruber#20, twitter.com/gruber#40, twitter.com/gruber#60 and so on (or better yet, counting from the first tweet). Now, what if I'd want to link to Grubers first 20 tweets? The URL would be twitter.com/gruber#8900 and the page would load nearly 9000 tweets? I don't think that's a good idea.

The non-link-ability is not the only problem of this technique: How do I jump to the end of the list? Or generally, how do I jump to a specific item (e.g. the first unread post in a forum thread)? What if the page becomes so long that my browser struggles to keep up?

It ultimately boils down to what we gain by using a Load More button instead of Next Page. And the only answer I can think of, is a few milliseconds of time I'd otherwise would've spent waiting for a whole new page to load. I also believe that appending items to a page is even more confusing for the user than going to a new page. After you've clicked more a few times, the list becomes so long that you easily get lost in it.

Pagination might not be as cool as all the AJAX stuff, but for navigating a list of “infinite” size I really can't think of a better approach. It doesn't have to be the old school pagination with a Next Page link though – you could build something that utilizes AJAX, caches the next page in advance, makes use of your mouse' scroll wheel etc. Ultimately it just has to be something that says “you are viewing items 340–380 of 920”: Providing a fixed sized, moving window into a set of items, instead of the fixed position, growing window that is Load More.

Thursday, July 8th 2010 / Comments (7)
Tags: Random Thoughts, AJAX, Web Technology

Google Chrome Frame is Here to Save Us All!

Google introduced Chrome Frame today, which is essentially a plugin for Internet Explorer to use Chrome/Webkit as it's rendering engine. This at first may seem like one of Google's Aprils Fool's jokes or an attempt to make Microsoft even more embarrassed of IE. However, when looked at closely, the Idea to bring Chrome to IE is very clever and might actually work!

The problem is clear: While Microsoft certainly fixed many issues of the now infamous IE 6 in their newer versions, IE 8 still has many many problems and is far behind in terms of standard compatibility, features and speed. This has hindered many sites from using new technologies and ideas and oftentimes forces developers to backpedal in order to still support IE. So how do we get people to switch to a different browser?

Imagine you're visiting a website and are greeted with a message like “Your browser is not supported by this website. Please download one of the following browsers...”. Would you do it?

For the average user, the answer is of course no. There are way to many hurdles to overcome. Many people don't even know what a browser is. For them, IE is the Internet. They won't understand why they need to install a new software and they won't know what to do if they wanted to switch. Even if a user exactly knows what a browser is and how to install software, he'd still have to trust the browser vendor that this new software won't do any harm to his PC and he'd also have to invest some time to get familiar with it. It's just not worth the effort.

Now imagine you're visiting this website and you get the message “You need the plugin XYZ to view this site”. Imagine this plugin was created by Google – a company you know and can be sure of that they won't harm your PC. Installation of this plugin is just one click away. You don't have to download or install anything manually and your browser will look and behave exactly the way it used to.

Google Chrome Frame is just that. It's only a plugin, but for web developers it has the same benefits as if the user switched to another browser. If you're working on a high-end website that you can't possibly get working in IE (like Google itself does with Wave), or that just would work better with a standard compliant rendering engine, then Chrome Frame seems like a very good answer.

Wednesday, September 23rd 2009 / Comments (0)
Tags: Random Thoughts, Web Technology

Instant Avatars

Avatars are important. They are everywhere and there is virtually no community driven website out there, where you can’t upload an image of yourself or what you want to be associated with. These images help us to immediately recognize our friends without even having to look at their names.

We don’t care too much about what is depicted, but how it looks: the overall color and shapes. Yet, all the default avatars of our beloved Web 2.0 sites look exactly the same. And while Twitter’s default Avatar can at least be considered cute, most others are dull and unimaginative.

Why not create a unique image, based on the users name, on the fly? This avatar could be temporarily used till the user can be bothered with uploading one by himself. This would give even the laziest user a chance to be instantly recognized by his friends.

My InstantAvatar PHP class does exactly this: it generates (more or less) unique avatars on the fly. Here are some examples of what it can do: InstantAvatar Samples

Read complete post »

Tuesday, December 23rd 2008 / Comments (6)
Tags: PHP, Graphics, Web Technology

QuickSearch.js – Shortwave for the Paranoid

Shaun Inman just released Shortwave, an “extensible quick-search and shortcut system”. It is quiet similar to YubNub or my PL Cmdline in that you use keywords to trigger different search engines.

The problem with all of these tools is the lack of an anonymity. As soon as you want to define your own commands, you’ll have to create an account (YubNub or PL Cmdline), or even upload a file somewhere on your webspace and tell the app the location of this file every time you search for something (Shortwave). So in theory, every search you do through one of these tools can be logged by the website and traced back to you.

I never put a second thought in how to fix this privacy issue, until I realized that Shortwave makes use of a Javascript bookmarklet. So why not move all the functionality on the client sides bookmarklet, instead of passing all commands and search terms through a website? Shaun Inman thought he knew why not:

All searches pass through the Shortwave domain for one very simple, evil-free reason: if all the triggers and destination urls were embedded in the JavaScript bookmark that bookmark would need to be updated every time a new trigger was added–in every browser and on every computer that uses it. That would be an absolute syncing nightmare.

However, you don’t need to put all commnads into the bookmarklet – instead, just let the bookmarklet load an external Javascript file that you put on your website – just like a waves.txt for Shortwave. Sadly my comment in Shaun’s blog stating this idea was quickly deleted (along with my other comment about an XSS vulnerability on the Shortwave site). So here’s my implementation of a Client Side Shortwave I will just call quicksearch.js for the lack of creativity.

Read complete post »

Monday, July 7th 2008 / Comments (3)
Tags: JavaScript, Web Technology

How I hacked Digg

Two weeks ago I filed a bug report on Digg.com, explaining several XSS vulnerabilities and bugs I found. Some of these were (and some still are!) very critical. A day later, I got an automated response to my report:

We’ve contacted our development team who are investigating the issue, and will fix it as soon as possible.

All well and good I thought, but when a few days ago all vulnerabilities were still there, I decided to exploit one of them.

Read complete post »

Wednesday, June 4th 2008 / Comments (34)
Tags: JavaScript, Security, Web Technology