wpbasti's shared items in Google Reader

Skandale überall: Schützt uns vor Verbraucherschützern!

2009-07-20T14:29:30Z

Shared by wpbasti
Sehr amüsanter Artikel aus der Sonntagszeitung. Die armen armen Verbraucher. ;)

Verbraucherschützer führen sich als Retter der Menschheit auf. Dabei füttern sie uns mit Pseudoskandalen und Binsenweisheiten. Wenn sich kein Skandal findet, dann wird einer inszeniert.

Microsoft Popfly streckt die Flügel

2009-07-20T08:47:08Z

Shared by wpbasti
Vor zwei Jahren oder so hörte sich das ganz gut an. Microsoft stellt alles ein was Spass macht ;)

How Apple.com Would Have Looked in 1983 [Image Cache]

2009-07-20T08:46:00Z

Shared by wpbasti
Execellent work :)

Do you know what this is, dear Apple fanboys and haters? From the beige to the menu bar items to the Lisa Office or the iPhone, this 1983 take on Apple.com's frontpage is pure genius. That's exactly what this is.

(click on the image for full resolution)

Dave Lawrence, the author, explains:

Little project of mine: imagine Apple.com in 1983. The Apple Lisa is new, the Mac is still a year away. It's imaginary, of course, considering the iPhone and Apple even hinting at the Macintosh publicly. Still... fun to imagine.

Fun to see too. I can't have enough of that "BASIC" in the menu items. [Flickr via Macmagazine—In Brazilian]

Ex-Milliardärin: Die arglose Frau Schickedanz

2009-07-20T08:39:30Z

Shared by wpbasti
Hilfe, wie naiv.

Die einstige Arcandor-Milliardärin Schickedanz lebt von nur noch 600 Euro im Monat und kauft bei Discountern ein. Das mag so manchen erschrecken. Viel schockierender ist allerdings ihre unternehmerische Naivität.

2009-07-19 Trunk builds

2009-07-20T08:31:42Z

Shared by wpbasti
Finally "onhashchange" support in Mozilla.

Fixes:

Fixed: 487949 - Land HTML5 parser, preffed off (in about:config, html5.enable).
Fixed: 385434 - Add support for HTML5 onhashchange (event for named anchor changes).
Fixed: 499538 - Arabic letters are disconnected in edit fields.
Fixed: 500233, 500317 - Make some cycle collector information accessible to memory tools.
Fixed: 503942 - Implement Geolocation Addresses.
Fixed(?): 76053 - Windows mouse integration: "Snap to default button in dialog boxes".
Fixed: 176244 - Fix column resize and reorder issues when direction is rtl.
Fixed: 259199 - Tooltips don't work in the sidebar.
Fixed: 500822 - Importing passwords to mozstorage can fail when signons3.txt is corrupted.
Fixed: 442399 - Remove LiveConnect from the tree.
Fixed: 421351 - Allow styling richlistitems with -moz-appearance:menuitem.
Fixed: 479667 - Firefox should use SetProcessDEPPolicy to enable NX on XP SP3.
Fixed: 329869 - Dynamically loaded scripts don't degrade security state.
Fixed: 457809 - Speculatively load images from preloading.
Fixed: 500846 - Can't create xmlhttprequest from within JS component.
Fixed: 482788 - Lightweight DOM wrappers.
Fixed: 492866 - Nanojit: variable-width LIR.
Fixed: 502374 - Don't call cycle collector so often.
Fixed: 500925 - Don't unload plugins as soon as possible by default.
Fixed: 200505 - Optimization of jsref array_join_sub() function.
Fixed: 456721 - Control GC frequency/a high water mark of Tracemonkey via about:config.

Fixes for recent regressions:

mozilla-central pushlog for 2009-06-28 04:00 to 2009-07-19 04:00

Windows nightly (discussion)

Mac nightly

Linux nightly

Milliardenverluste: Regierung gesteht Opel-Misere ein

2009-07-20T08:28:45Z

Shared by wpbasti
Das Opel nicht rentabel und sinnvoll zu erhalten ist, war ja vorher klar. Hier kommen noch ein paar Details um das zu untermauern.

Es ist die Geschichte eines Niedergangs: Mitten im Bieterrennen um den Rüsselsheimer Autobauer kommt heraus, dass Opel seit 2003 durchgehend Verluste geschrieben hat. Wer den angeschlagenen Hersteller übernehmen wird, will GM noch diesen Monat entscheiden.

Google Says Mobile Web Apps Will Win In The Long Haul

2009-07-17T23:00:28Z

Shared by wpbasti
Quote: "The advantages of web apps, such as instant deployment and simplified cross compatibility, are too great to pass up."

Native Apps, or Web Apps? It’s the great debate of the mobile world right now, essentially fueling the platform wars from behind the scenes. Palm took the Web App route with the Pre and webOS, though with the SDK just now available to all its a bit too early to gauge that decision. The iPhone began its life with Web Apps, only to later open up native support and become the apotheosis of how app development and distribution can be done. Even Google, who will try to jam just about anything into the cloud, is putting a lot of weight behind running things locally on their Android platform.

Still, Google VP of Engineering Vic Gundotra says Web Apps are the way.

During a panel at Mobilebeat 2009, Gundotra put his full support behind the Web:

“We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.”

For developers currently accustomed to developing in Objective-C or J2ME, this might sound like crazy talk; in its current state, the only time we turn to the mobile web for app development is for the most basic of services. Twitter client? Sure. Complex 3D games? Yeah, probably not.

But that could very well change. With the advancement of HTML5 and Web App-centric SDK’s like Palm’s Mojo, the limitations are dwindling. Inch by inch, function by function, handset functionality is becoming web accessible. Already, some handsets are allowing applications to tie into their accelerometers and GPS receivers. As mobile broadband speeds increase and APIs are opened up, what’s really to keep us from piping those complex 3D games from afar?

To think that applications are always going to be completely locally ran is short-sighted; once the functionality of web-based applications is on par with that of native applications, the line blurs. Once the consumer can’t tell the difference between something running on their handset and something coming off the web, they stop caring. If the consumer is no longer resisting, the advantages of web apps, such as instant deployment and simplified cross compatibility, are too great to pass up.

Vic Gundotra acknowledged Apple’s move from Web App to Native, implying that Apple was simply a bit ahead of the times:

“I think Steve [Jobs] really did understand that, over the long term, it would be the web, and I think that’s how things will play out.”

We’d agree with Vic here. It’s not going to happen tomorrow, nor even in the next year - but the short list of reasons to develop natively is growing shorter each day.

[Via FinancialTimes]

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

Nokia sells off Symbian professional services to Accenture

2009-07-17T22:54:35Z

Shared by wpbasti
So with every step they made away from Symbian they might get nearer to Android. Nothing wrong with that.

When Nokia purchased Symbian a year ago, the supersize phone maker’s explicit plan was to open up Symbian’s mobile platform as a partly open-source suite of software, so that application developers would feel comfortable developing for it, as well as contributing their improvements to Symbian’s OS.

Today, Nokia announced the sale of its Symbian professional services group to Accenture, a move meant to further distance Symbian from Nokia or any other handset maker. All 165 of the group’s employees are being transferrred from Nokia to Accenture, a process that Nokia says will be completed by the end of September.

The HTC Hero has landed... in our hands

2009-07-17T22:44:06Z

Shared by wpbasti
First impression seems to be good. Waiting for a full review.

Guess what the Gadget Stork delivered on our doorstep today? A robot baby? No. Better. An actual, real, ~~in-the-Teflon~~ HTC Hero. Let's just say this -- it's pretty much the sexiest Android device ever created. We're not going to go into too much detail right now, as we're planning on delivering a full review next week, but we do want to say that this thing has our eyes glazed over like Scrooge McDuck checking out a pile of gold... if you know what we mean. HTC has truly outdone themselves here, not only with build quality (the thing kind of feels like a luxurious rock in your hand -- it's a good thing), but so far the software seems truly outstanding as well. Of course, we haven't taken the deep dive yet, so for now, feast your eyes on these photos, and get ready for the main event.

Update: Oh why, HTC? Apparently, this thing ain't covered in Teflon at all. According to the company's PR, only the white models are getting the dirt-resistant treatment. We're guessing the unit we have is just sporting a regular, soft-touch coating. It feels good and all... but now it seems so much less special.

Gallery: HTC Hero lands at Engadget

Filed under: Cellphones

The HTC Hero has landed... in our hands originally appeared on Engadget on Fri, 17 Jul 2009 15:28:00 EST. Please see our terms for use of feeds.

Permalink | Email this | Comments

Twitter Users Agree: IE6 Must Die

2009-07-17T22:34:15Z

Shared by wpbasti
Nice idea :)

Yesterday, we published a story entitled IE6 Must Die for the Web to Move On, which analyzes HTML 5, the future of the web, and the roadblock that Internet Explorer 6 poses to web innovation. While we thought people would agree with us, we couldn’t have ever imagined the overwhelming response of the social web. Apparently a lot of you just can’t stand the 8 year old browser.

Now one Twitter user, James Lynch (@lynchjames) has seized the momentum and taken matters into his own hands. Specifically, he has used Twibbon, a service that overlays a small icon onto your profile picture, to create a Twitter petition to rally support for ending the use of IE6. Now, the Twibbon petition is gaining steam, as nearly a dozen people a minute are adding a “No to IE6″ image to their profile pictures.

We are fans of user activism through social media – it’s widely believed that a Twititon for lowering the price of iPhone 3G S upgrades was central to AT&T caving to consumer and offering $199 iPhone 3G S mobiles to its unhappy userbase.

It’s clear that campaigns like the IE6 Must Die Petition can be effective at rallying support and awareness for a cause, although as we pointed out in our original article, the people that must be convinced aren’t the leadership at Microsoft, but the managers at outdated IT departments and the websites that still put significant resources toward IE6 support (hint to developers: charge more for IE6 support!).

In other words, don’t expect a Twitition to quickly fix this Internet-wide problem, but we definitely hope companies, websites, and media take notice.

Reviews: Internet Explorer, Twitter

Tags: IE6, internet explorer, Microsot, Twibbon, twitition, twitter

an overview of TraceMonkey

2009-07-17T13:06:02Z

Shared by wpbasti
Impressive numbers... and also an interesting read for the C++ and Java guys out there.

This post was written by David Mandelin who works on Mozilla’s JavaScript team.

Firefox 3.5 has a new JavaScript engine, TraceMonkey, that runs many JavaScript programs 3-4x faster than Firefox 3, speeding up existing web apps and enabling new ones. This article gives a peek under the hood at the major parts of TraceMonkey and how they speed up JS. This will also explain what kinds of programs get the best speedup from TraceMonkey and what kinds of things you can do to get your program to run faster.

Why it’s hard to run JS fast: dynamic typing

High-level dynamic languages such as JavaScript and Python make programming more productive, but they have always been slow compared to statically typed languages like Java or C. A typical rule of thumb was that a JS program might be 10x slower than an equivalent Java program.

There are two main reasons JS and other dynamic scripting languages usually run slower than Java or C. The first reason is that in dynamic languages it is generally not possible to determine the types of values ahead of time. Because of this, the language must store all values in a generic format and process values using generic operations.

In Java, by contrast, the programmer declares types for variables and methods, so the compiler can determine the types of values ahead of time. The compiler can then generate code that uses specialized formats and operations that run much faster than generic operations. I will call these type-specialized operations.

The second main reason that dynamic languages run slower is that scripting languages are usually implemented with interpreters, while statically typed languages are compiled to native code. Interpreters are easier to create, but they incur extra runtime overhead for tracking their internal state. Languages like Java compile to machine language, which requires almost no state tracking overhead.

Let’s make this concrete with a picture. Here are the slowdowns in picture form for a simple numeric add operation: a + b, where a and b are integers. For now, ignore the rightmost bar and focus on the comparison of the Firefox 3 JavaScript interpreter vs. a Java JIT. Each column shows the steps that have to be done to complete the add operation in each programming language. Time goes downward, and the height of each box is proportional to the time it takes to finish the steps in the box.

In the middle, Java simply runs one machine language add instruction, which runs in time T (one processor cycle). Because the Java compiler knows that the operands are standard machine integers, it can use a standard integer add machine language instruction. That’s it.

On the left, SpiderMonkey (the JS interpreter in FF3) takes about 40 times as long. The brown boxes are interpreter overhead: the interpreter must read the add operation and jump to the interpreter’s code for a generic add. The orange boxes represent extra work that has to be done because the interpreter doesn’t know the operand types. The interpreter has to unpack the generic representations of a and i, figure out their types, select the specific addition operation, convert the values to the right types, and at the end, convert the result back to a generic format.

The diagram shows that using an interpreter instead of a compiler is slowing things down a little bit, but not having type information is slowing things down a lot. If we want JS to run more than a little faster than in FF3, by Amdahl’s law, we need to do something about types.

Getting types by tracing

Our goal in TraceMonkey is to compile type-specialized code. To do that, TraceMonkey needs to know the types of variables. But JavaScript doesn’t have type declarations, and we also said that it’s practically impossible for a JS engine to figure out the types ahead of time. So if we want to just compile everything ahead of time, we’re stuck.

So let’s turn the problem around. If we let the program run for a bit in an interpreter, the engine can directly observe the types of values. Then, the engine can use those types to compile fast type-specialized code. Finally, the engine can start running the type-specialized code, and it will run much faster.

There are a few key details about this idea. First, when the program runs, even if there are many if statements and other branches, the program always goes only one way. So the engine doesn’t get to observe types for a whole method — the engine observes types through the paths, which we call traces, that the program actually takes. Thus, while standard compilers compile methods, TraceMonkey compiles traces. One side benefit of trace-at-a-time compilation is that function calls that happen on a trace are inlined, making traced function calls very fast.

Second, compiling type-specialized code takes time. If a piece of code is going to run only one or a few times, which is common with web code, it can easily take more time to compile and run the code than it would take to simply run the code in an interpreter. So it only pays to compile hot code (code that is executed many times). In TraceMonkey, we arrange this by tracing only loops. TraceMonkey initially runs everything in the interpreter, and starts recording traces through a loop once it gets hot (runs more than a few times).

Tracing only hot loops has an important consequence: code that runs only a few times won’t speed up in TraceMonkey. Note that this usually doesn’t matter in practice, because code that runs only a few times usually runs too fast to be noticeable. Another consequence is that paths through a loop that are not taken at all never need to be compiled, saving compile time.

Finally, above we said that TraceMonkey figures out the types of values by observing execution, but as we all know, past performance does not guarantee future results: the types might be different the next time the code is run, or the 500th next time. And if we try to run code that was compiled for numbers when the values are actually strings, very bad things will happen. So TraceMonkey must insert type checks into the compiled code. If a check doesn’t pass, TraceMonkey must leave the current trace and compile a new trace for the new types. This means that code with many branches or type changes tends to run a little slower in TraceMonkey, because it takes time to compile the extra traces and jump from one to another.

TraceMonkey in action

Now, we’ll show tracing in action by example on this sample program, which adds the first N whole numbers to a starting value:

 function addTo(a, n) {
   for (var i = 0; i < n; ++i)
     a = a + i;
   return a;
 }
 
 var t0 = new Date();
 var n = addTo(0, 10000000);
 print(n);
 print(new Date() - t0);

TraceMonkey always starts running the program in the interpreter. Every time the program starts a loop iteration, TraceMonkey briefly enters monitoring mode to increment a counter for that loop. In FF3.5, when the counter reaches 2, the loop is considered hot and it’s time to trace.

Now TraceMonkey continues running in the interpreter but starts recording a trace as the code runs. The trace is simply the code that runs up to the end of the loop, along with the types used. The types are determined by looking at the actual values. In our example, the loop executes this sequence of JavaScript statements, which becomes our trace:

    a = a + i;    // a is an integer number (0 before, 1 after)
    ++i;          // i is an integer number (1 before, 2 after)
    if (!(i < n)) // n is an integer number (10000000)
      break;

That’s what the trace looks like in a JavaScript-like notation. But TraceMonkey needs more information in order to compile the trace. The real trace looks more like this:

  trace_1_start:
    ++i;            // i is an integer number (0 before, 1 after)
    temp = a + i;   // a is an integer number (1 before, 2 after)
    if (lastOperationOverflowed())
      exit_trace(OVERFLOWED);
    a = temp;
    if (!(i < n))   // n is an integer number (10000000)
      exit_trace(BRANCHED);
    goto trace_1_start;

This trace represents a loop, and it should be compiled as a loop, so we express that directly using a goto. Also, integer addition can overflow, which requires special handling (for example, redoing with floating-point addition), which in turn requires exiting the trace. So the trace must include an overflow check. Finally, the trace exits in the same way if the loop condition is false. The exit codes tell TraceMonkey why the trace was exited, so that TraceMonkey can decide what to do next (such as whether to redo the add or exit the loop). Note that traces are recorded in a special internal format that is never exposed to the programmer — the notation used above is just for expository purposes.

After recording, the trace is ready to be compiled to type-specialized machine code. This compilation is performed by a tiny JIT compiler (named, appropriately enough, nanojit) and the results are stored in memory, ready to be executed by the CPU.

The next time the interpreter passes the loop header, TraceMonkey will start executing the compiled trace. The program now runs very fast.

On iteration 65537, the integer addition will overflow. (2147450880 + 65537 = 2147516417, which is greater than 2^31-1 = 2147483647, the largest signed 32-bit integer.) At this point, the trace exits with an OVERFLOWED code. Seeing this, TraceMonkey will return to interpreter mode and redo the addition. Because the interpreter does everything generically, the addition overflow is handled and everything works as normal. TraceMonkey will also start monitoring this exit point, and if the overflow exit point ever becomes hot, a new trace will be started from that point.

But in this particular program, what happens instead is that the program passes the loop header again. TraceMonkey knows it has a trace for this point, but TraceMonkey also knows it can’t use that trace because that trace was for integer values, but a is now in a floating-point format. So TraceMonkey records a new trace:

  trace_2_start:
    ++i;            // i is an integer number
    a = a + i;      // a is a floating-point number
    if (!(i < n))   // n is an integer number (10000000)
      exit_trace(BRANCHED);
    goto trace_2_start;

TraceMonkey then compiles the new trace, and on the next loop iteration, starts executing it. In this way, TraceMonkey keeps the JavaScript running as machine code, even when types change. Eventually the trace will exit with a BRANCHED code. At this point, TraceMonkey will return to the interpreter, which takes over and finishes running the program.

Here are the run times for this program on my laptop (2.2GHz MacBook Pro):

System	Run Time (ms)
SpiderMonkey (FF3)	990
TraceMonkey (FF3.5)	45
Java (using int)	25
Java (using double)	74
C (using int)	5
C (using double)	15

This program gets a huge 22x speedup from tracing and runs about as fast as Java! Functions that do simple arithmetic inside loops usually get big speedups from tracing. Many of the bit operation and math SunSpider benchmarks, such bitops-3bit-bits-in-byte, ctrypto-sha1, and math-spectral-norm get 6x-22x speedups.

Functions that use more complex operations, such as object manipulation, get a smaller speedup, usually 2-5x. This follows mathematically from Amdahl’s law and the fact that complex operations take longer. Looking back at the time diagram, consider a more complex operation that takes time 30T for the green part. The orange and brown parts will still be about 30T together, so eliminating them gives a 2x speedup. The SunSpider benchmark string-fasta is an example of this kind of program: most of the time is taken by string operations that have a relatively long time for the green box.

Here is a version of our example program you can try in the browser:

Run Example

Numerical result:

Run time:

Average run time:

Understanding and fixing performance problems

Our goal is to make TraceMonkey reliably fast enough that you can write your code in the way that best expresses your ideas, without worrying about performance. If TraceMonkey isn’t speeding up your program, we hope you’ll report it as a bug so we can improve the engine. That said, of course, you may need your program to run faster in today’s FF3.5. In this section, we’ll explain some tools and techniques for fixing performance of a program that doesn’t get a good (2x or more) speedup with the tracing JIT enabled. (You can disable the jit by going to about:config and setting the pref javascript.options.jit.content to false.)

The first step is understanding the cause of the problem. The most common cause is a trace abort, which simply means that TraceMonkey was unable to finish recording a trace, and gave up. The usual result is that the loop containing the abort will run in the interpreter, so you won’t get a speedup on that loop. Sometimes, one path through the loop is traced, but there is an abort on another path, which will cause TraceMonkey to switch back and forth between interpreting and running native code. This can leave you with a reduced speedup, no speedup, or even a slowdown: switching modes takes time, so rapid switching can lead to poor performance.

With a debug build of the browser or a JS shell (which I build myself - we don’t publish these builds) you can tell TraceMonkey to print information about aborts by setting the TMFLAGS environment variable. I usually do it like this:

TMFLAGS=minimal,abort
dist/MinefieldDebug.app/Contents/MacOS/firefox

The minimal option prints out all the points where recording starts and where recording successfully finishes. This gives a basic idea of what the tracer is trying to do. The abort option prints out all the points where recording was aborted due to an unsupported construct. (Setting TMFLAGS=help will print the list of other TMFLAGS options and then exit.)

(Note also that TMFLAGS is the new way to print the debug information. If you are using a debug build of the FF3.5 release, the environment variable setting is TRACEMONKEY=abort.)

Here’s an example program that doesn’t get much of a speedup in TraceMonkey.

function runExample2() {
  var t0 = new Date;
 
  var sum = 0;
  for (var i = 0; i < 100000; ++i) {
    sum += i;
  }
 
  var prod = 1;
  for (var i = 1; i < 100000; ++i) {
    eval("prod *= i");
  }
  var dt = new Date - t0;
  document.getElementById(example2_time').innerHTML = dt + ' ms';
}

Run Example 2
Run time:

If we set TMFLAGS=minimal,abort, we’ll get this:

Recording starting from ab.js:5@23
recording completed at  ab.js:5@23 via closeLoop
 
Recording starting from ab.js:5@23
recording completed at  ab.js:5@23 via closeLoop
 
Recording starting from ab.js:10@63
Abort recording of tree ab.js:10@63 at ab.js:11@70: eval.
 
Recording starting from ab.js:10@63
Abort recording of tree ab.js:10@63 at ab.js:11@70: eval.
 
Recording starting from ab.js:10@63
Abort recording of tree ab.js:10@63 at ab.js:11@70: eval.

The first two pairs of lines show that the first loop, starting at line 5, traced fine. The following lines showed that TraceMonkey started tracing the loop on line 10, but failed each time because of an eval.

An important note about this debug output is that you will typically see some messages referring to inner trees growing, stabilizing, and so on. These really aren’t problems: they usually just indicate a delay in finishing tracing a loop because of the way TraceMonkey links inner and outer loops. And in fact, if you look further down the output after such aborts, you will usually see that the loops eventually do trace.

Otherwise, aborts are mainly caused by JavaScript constructs that are not yet supported by tracing. The trace recording process is easier to implement for a basic operation like + than it is for an advanced feature like arguments. We didn’t have time to do robust, secure tracing of every last JavaScript feature in time for the FF3.5 release, so some of the more advanced ones, like arguments, aren’t traced in FF3.5.0. Other advanced features that are not traced include getters and setters, with, and eval. There is partial support for closures, depending on exactly how they are used. Refactoring to avoid these constructs can help performance.

Two particularly important JavaScript features that are not traced are:

Recursion. TraceMonkey doesn’t see repetition that occurs through recursion as a loop, so it doesn’t try to trace it. Refactoring to use explicit for or while loops will generally give better performance.
Getting or setting a DOM property. (DOM method calls are fine.) Avoiding these constructs is generally impossible, but refactoring the code to move DOM property access out of hot loops and performance-critical segments should help.

We are actively working on tracing all the features named above. For example, support for tracing arguments is already available in nightly builds.

Here is the slow example program refactored to avoid eval. Of course, I could have simply done the multiplication inline. Instead, I used a function created by eval because that’s a more general way of refactoring an eval. Note that the eval still can’t be traced, but it only runs once so it doesn’t matter.

function runExample3() {
  var t0 = new Date;
 
  var sum = 0;
  for (var i = 0; i < 100000; ++i) {
    sum += i;
  }
 
  var prod = 1;
  var mul = eval("(function(i) { return prod * i; })");
 
  for (var i = 1; i < 100000; ++i) {
    prod = mul(i);
  }
  var dt = new Date - t0;
  document.getElementById('example3_time').innerHTML = dt + ' ms';
}

Run Example 3
Run time:

There are a few more esoteric situations that can also hurt tracing performance. One of them is trace explosion, which happens when a loop has many paths through it. Consider a loop with 10 if statements in a row: the loop has 1024 paths, potentially causing 1024 traces to be recorded. That would use up too much memory, so TraceMonkey caps each loop at 32 traces. If the loop has fewer than 32 hot traces, it will perform well. But if each path occurs with equal frequency, then only 3% of the paths are traced, and performance will suffer.

This kind of problem is best analyzed with TraceVis, which creates visualizations of TraceMonkey performance. Currently, the build system only supports enabling TraceVis for shell builds, but the basic system can also run in the browser, and there is ongoing work to enable TraceVis in a convenient form in the browser.

The blog post on TraceVis is currently the most detailed explanation of what the diagrams mean and how to use them to diagnose performance problems. The post also contains a detailed analysis of a diagram that is helpful in understanding how TraceMonkey works in general.

Comparative JITerature

Here I will give a few comparisons to other JavaScript JIT designs. I’ll focus more on hypothetical designs than competing engines, because I don’t know details about them — I’ve read the release information and skimmed a few bits of code. Another big caveat is that real-world performance depends at least as much on engineering details as it does on engine architecture.

One design option could be a called a per-method non-specializing JIT. By this, I mean a JIT compiler that compiles a method at a time and generates generic code, just like what the interpreter does. Thus, the brown boxes from our diagrams are cut out. This kind of JIT doesn’t need to take time to record and compile traces, but it also does not type-specialize, so the orange boxes remain. Such an engine can still be made pretty fast by carefully designing and optimizing the orange box code. But the orange box can’t be completely eliminated in this design, so the maximum performance on numeric programs won’t be as good as a type-specializing engine.

As far as I can tell, as of this writing Nitro and V8 are both lightweight non-specializing JITs. (I’m told that V8 does try to guess a few types by looking at the source code (such as guessing that a is an integer in a >> 2) in order to do a bit of type specialization.) It seem that TraceMonkey is generally faster on numeric benchmarks, as predicted above. But TraceMonkey suffers a bit on benchmarks that use more objects, because our object operations and memory management haven’t been optimized as heavily.

A further development of the basic JIT is the per-method type-specializing JIT. This kind of a JIT tries to type-specialize a method based on the argument types the method is called with. Like TraceMonkey, this requires some runtime observation: the basic design checks the argument types each time a method is called, and if those types have not been seen before, compiles a new version of the method. Also like TraceMonkey, this design can heavily specialize code and remove both the brown and orange boxes.

I’m not aware that anyone has deployed a per-method type-specializing JIT for JavaScript, but I wouldn’t be surprised if people are working on it.

The main disadvantage of a per-method type-specializing JIT compared to a tracing JIT is that the basic per-method JIT only directly observes the input types to a method. It must try to infer types for variables inside the method algorithmically, which is difficult for JavaScript, especially if the method reads object properties. Thus, I would expect that a per-method type-specializing JIT would have to use generic operations for some parts of the method. The main advantage of the per-method design is that the method needs to be compiled exactly once per set of input types, so it’s not vulnerable to trace explosion. In turn, I think a per-method JIT would tend to be faster on methods that have many paths, and a tracing JIT would tend to be faster on highly type-specializable methods, especially if the method also reads a lot of values from properties.

Conclusion

By now, hopefully you have a good idea of what makes JavaScript engines fast, how TraceMonkey works, and how to analyze and fix some performance issues that may occur running JavaScript under TraceMonkey. Please report bugs if you run into any significant performance problems. Bug reports are also a good place for us to give additional tuning advice. Finally, we’re trying to improve constantly, so check out nightly TraceMonkey builds if you’re into the bleeding edge.

Google: Browser is the Platform of the Future, Even on Mobiles

2009-07-17T13:01:54Z

Shared by wpbasti
Chrome for BlackBerry anyone? Or for S60? Yeah!

Every company that’s built a major mobile platform is trying to make their platform attractive for developers and a great experience for users. Since Apple started their hugely popular iPhone App Store (recently they’ve reached a milestone of 1.5 billion downloaded apps), RIM, Google, Nokia, Palm, and Microsoft have followed suit. But Google thinks that – similar to what is happening in the world of desktops – in the future, the actual platform won’t matter much, because the web browser will become the dominant mobile platform.

As Google’s Vic Gundotra, Engineering vice president and developer evangelist, said at the Mobilebeat conference in San Francisco on Thursday, “We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.”

Google has certainly put their money where their mouth is when it comes to mobile versions of their web applications, such as Gmail, Google Calendar and others, most of which are available on all significant mobile platforms, and many have mobile browser-based versions. They also have their own mobile platform, Android; however, what Gundotra is saying means that having the best mobile browser will also play a significant part in the future of mobile computing.

Surprisingly, it seems that everyone besides Opera, which puts a great effort into development of Opera Mobile and Opera Mini and Apple with their open sourced WebKit was late to this game. Mozilla’s Fennec is still in very early stages of development, while Microsoft’s Internet Explorer was there from the very beginning, but it was – and still is – a bad mobile browser. Nokia’s Symbian and Google’s android use WebKit-powered browsers, but Gundotra’s statement might mean that Google is finally preparing to launch Chrome for mobiles, and in this space, competition is more than welcome.

Most importantly, if Gundotra is right, it means that many developers might be wasting time trying to port their application to various mobile platforms out there. Build for the mobile browser; it might not look like a very good idea now, but it might pay off in the future.

Reviews: Android, Chrome, Gmail, Google, Internet Explorer, Opera

Tags: browser, Google, Mobile 2.0

Reports say iPhone could be coming to British T-Mobile

2009-07-17T08:32:41Z

Shared by wpbasti
That would be a cool deal for T-Mobile UK.

Multiple sources are reporting that that T-Mobile U.K. is in talks with Apple to bring the iPhone 3G – last year’s model – to its mobile service, taking away the phone’s exclusivity from competing carrier O2.

ZEW-Studie: Tiefpunkt bei Hightech-Startups

2009-07-17T08:27:44Z

Shared by wpbasti
Armes Deutschland. So ein wenig Silicon Valley like Startup-Szene wäre schon cool.

Deutschland ist im europäischen Vergleich kein Gründerland. Jetzt erreicht die Statistik einen neuen Tiefpunkt: Im Vergleich zum Vorjahr haben Gründungen im Hightech-Sektor um elf Prozent abgenommen.

Google Voice: Die Revolution der Telefonie

2009-07-17T08:21:48Z

Shared by wpbasti
Neben Wave ist Voice sicher das aktuell spannendste "upcoming" Google Produkt.

Google Voice ist ein kostenloser, webbasierte Telefonmanager. Unter dem Motto “Eine Nummer für alle deine Telefone, für immer” hat der bisher nur in den USA verfügbare Dienst das Zeug, die Telefonie zu revolutionieren – und könnte eines Tages Skype gefährlich werden.

In der Folge der Wirtschaftkrise scheint es, als ob sich junge Webdienste immer seltener den Luxus eines ausgiebigen “Stealth mode” oder einer langen, geschlossenen Beta-Phase gönnen und stattdessen schnellstmöglich einer großen Benutzerzahl Zugang gewähren wollen. Die Konsequenz für Web-Enthusiasten wie uns ist, dass es nur noch wenige Services gibt, auf die wir sehnsüchtig warten und bei denen wir uns auf den Tag freuen, an dem wir eine Einladung zur Testphase erhalten.

Aber zum Glück gibt es Google. Nicht nur das Chrome OS und die neuartige Kommunikations- und Kollaborationsplattform Wave stehen dort in der Pipeline, sondern auch der Telefonmanager Google Voice. Wenn es einen Onlinedienst gibt, auf dessen Launch ich persönlich ungeduldig warte, dann ist es dieser. Bisher ist Google Voice lediglich auf Einladung und nur in den USA verfügbar.

Google Voice basiert auf dem im Sommer 2007 für kolportierte 50 Millionen Dollar übernommenen Telefondienstleister GrandCentral.

Im März diesen Jahres schloss der kalifornische Internetriese die Integration von GrandCentral in das eigene Produktportfolio ab und gab den offiziellen Startschuss für Google Voice.

Nutzer von Google Voice erhalten eine einzige Telefonnummer, die sie mit Hilfe von Regeln je nach Anrufer an das private, dienstliche oder mobile Telefon weiterleiten und über eine Google Mail ähnliche Weboberfläche verwalten können. Neben zahlreichen Funktionen zum bequemen Steuern und Feinabstimmen des persönlichen Gesprächsmanagements bietet Google Voice einen Anrufbeantworter, der hinterlassene Nachrichten nicht nur in Ton- sondern auch in Textform darstellt.

Gespräche werden über das Webinterface eingeleitet. Google ruft dann eines der persönlichen Telefone an und verbindet es mit dem gewünschten Gesprächspartner. Telefonate lassen sich auf Wunsch aufzeichnen. Auch Konferenzen und SMS-Versand sowie -Empfang werden unterstützt. Google Voice ist nicht nur kostenlos, sondern bietet in der USA außerdem kostenfreie Anrufe einheimischer Nummern. Für internationale Telefonate fallen geringe Gebühren an, die denen von Skype, JAJAH oder Truphone ähneln.

Einen großen Schritt macht Google Voice mit der anstehenden Veröffentlichung von Applikationen für Android-Smartphones und Blackberry. Besitzer dieser Geräte können über die Anwendung direkt auf die wichtigsten Google Voice-Funktionen zugreifen und bei ausgehenden Telefonaten ihre Google Voice-Nummer anzeigen lassen. Eine iPhone-App ist in Planung.

Um Nutzern, die einen Invite ergattern konnten, den Einstieg so leicht wie möglich zu machen, arbeitet Google derzeit an Lösungen, existierende Nummern von anderen Providern zu transferieren. Erste Tests dazu laufen zwar bereits, aber bis auf weiteres müssen sich User damit abfinden, von Google eine neue Nummer zugeteilt zu bekommen.

Auch wenn mit dem Einsatz von Google Voice einmal mehr ein Batzen persönlicher Informationen an den Webgiganten aus Mountain View ausgeliefert wird und die Notwendigkeit, allen Kontakten die persönliche Google Voice-Nummer kommunizieren zu müssen, zusätzlichen Aufwand bedeutet, handelt es sich bei dem webbasierten Telefonmanager um ein ein beeindruckendes Produkt, welches endlich Ordnung, Struktur und Effizienz in den Gesprächsalltag bringt.

Entgegen anderslautender Gerüchte plant Google offenbar, Voice vorerst weiterhin nur auf Einladung zugänglich zu machen. VoIP-Anbieter wie Skype müssen sich somit im Moment keine Sorgen machen, von Google in Bedrängnis gebracht zu werden. Langfristig aber ist Voice definitiv eine Bedrohung für alle Unternehmen, die im Markt der digitalen Telefonie tätig sind. Skype beispielsweise wäre daher gut beraten, sein Angebot noch stärker in die Richtung des “Unified Messagings” zu bewegen. Eine Browservariante könnte ein Anfang sein.

Ab wann Europäer Zugang zu Google Voice erhalten, ist bisher unklar.

Verwandte Artikel (Beta-Test)

	Microsoft Office 2010: Das Imperium schlägt zurück Microsoft greift Google an: Office 2010 wird kostenlose, webbasierte Versionen von Word, Excel, PowerPoint und OneNote beinhalten. (13. Juli 2009)
	Google Chrome Operating System: Betriebssystem für die Cloud Google wird mit dem Chrome OS ein eigenes, eng mit dem Web verbundenes Betriebssystem entwickeln. (8. Juli 2009)
	Google Squared ist live Google Squared ist live und kann unter http://www.google.com/squared/ benutzt werden. Die Ergebnisse sind oft erstaunlich zutreffend. (3. Juni 2009)

3D Transforms

2009-07-17T08:05:31Z

Shared by wpbasti
Impressive stuff.

WebKit on Mac OS X now has support for CSS 3D transforms, which allow you to position elements on the page in three-dimensional space using CSS. This is a natural extension of 2D transforms, which we described in an earlier blog post. 3D transforms have been supported on iPhone since 2.0, and now we’re please to announce that we have currently added support for Leopard and later.

If you want to jump right in and see a demo, make sure you’re running recent WebKit nightly build on Leopard or later, and load this example:

Poster Circle

Here’s a screenshot for those not running a recent-enough WebKit (if you are, hover over it for a treat!):

#flip-container { position: relative; margin: 10px auto; width: 250px; height: 261px; z-index: 1; } .face.back { display: none; } @media all and (-webkit-transform-3d) { /* Use the media query to determine if 3D transforms are supported */ #flip-container { -webkit-perspective: 800; } #flip-card { width: 100%; height: 100%; -webkit-transform-style: preserve-3d; -webkit-transition: -webkit-transform 1s; } #flip-container:hover #flip-card { -webkit-transform: rotateY(180deg); } .face { position: absolute; width: 100%; height: 100%; -webkit-backface-visibility: hidden; } .face.back { display: block; -webkit-transform: rotateY(180deg); -webkit-box-sizing: border-box; padding: 10px; font-size: 12pt; color: white; text-align: center; background-color: #835A99; -webkit-border-radius: 10px; } }

This flip effect is done entirely with 3D transforms and transitions—no JavaScript required!

Like many of the examples you’ll see here, this one combines CSS transforms with CSS transitions and animations to great effect.

3D transforms are applied via the same -webkit-transform property as 2D transforms. For example, here’s how to rotate an element about the Y (vertical) axis:

-webkit-transform: rotateY(45deg);

There are several new transform functions available for use in the -webkit-transform property:

translate3d(x, y, z), translateZ(z): Move the element in x, y and z, and just move the element in z. Positive z is towards the viewer. Unlike x and y, the z value cannot be a percentage.
scale3d(sx, sy, sz), scaleZ(sz): Scale the element in x, y and z. The z scale affects the scaling along the z axis in transformed children.
rotateX(angle), rotateY(angle), rotate3d(x, y, z, angle),: The first two forms simply rotate the element about the horizontal and vertical axes. Angle units can be degrees (deg) radians (rad) or gradians (grad). The last form allows you to rotate the element around an arbitrary vector in 3D space; x, y and z should specify the unit vector you wish to rotate around (we’ll normalize it for you).
perspective(p): This function allows you to put some perspective into the transformation matrix. For an explanation of p, see below. Normally perspective is applied via the -webkit-perspective property, but this function allows you to get a perspective effect for a single element, with something like:

-webkit-transform: perspective(500px) rotateY(20deg);

matrix3d(…)

This function allows you to specify the raw 4×4 homogeneous transformation matrix of 16 values in column-major order. Have fun with that!

We’ve also extended one other CSS transform property, and implemented the four other 3D-related properties described in the spec:

-webkit-transform-origin now accepts three values, allowing you to specify a z offset for the transform origin.

-webkit-perspective is used to give an illusion of depth; it determines how things change size based on their z-offset from the z=0 plane. You can think of it as though you’re looking at the page from a distance p away. Objects on the z=0 plane appear in their normal size. Something at a z offset of p/2 (halfway between the viewer and the z=0 plane) will look twice as big, and something at a z offset of -p will look half as big. Thus, large values give a little foreshortening effect, and small values lots of foreshortening. Values between 500px and 1000px give a reasonable-looking result for most content.

The default origin for the perspective effect is the center of the element’s border box, but you can control this with -webkit-perspective-origin.

Here’s an example that shows how perspective works:

Perspective

The interesting thing about -webkit-perspective is that it does not affect the element directly. Instead, it affects the appearance of the 3D transforms on the transformed descendants of that element; you can think of it as a adding a transform that gets multiplied into the descendant transforms. This allows those descendants to all share the same perspective as they move around.

Now that we’ve described how you can assign 3D transforms to elements and make them look three-dimensional with some perspective. However, so far, all the effects are really just painting effects. Those transformed children are still rendering into the plane of their parent; in other words, they are flattened.

When you start to build hierarchies of objects with 3D transforms, flattening is not what you want. You want parents and children to live in a shared three-dimensional space, and to all share the same perspective which propagates up from some container. This is where -webkit-transform-style comes in.

-webkit-transform-style has two values:

flat: This is the default value, and gives the behavior described above; transformed children are flattened into the plane of their parent (think of the 3D transform as simply a painting effect).
preserves-3d: This value states that the element to which it is assigned does not flatten its children into it; instead, those children live in a shared 3D space with the element.

Here’s an example that shows transform-style in action:

Transform Style

A common pattern, therefore, is to have content that looks like this:

<div class="container" style="-webkit-perspective: 600px">
  <div class="box" style="-webkit-transform-style: preserve-3d; -webkit-transform: rotateY(10deg)">
    <div class="leaf" style="-webkit-transform: rotateX(10deg)"></div>
  </div>
</div>

Here both ‘leaf’ and ‘box’ share the same 3D space, so both appear with the perspective specified on the container. ‘box’ can also be rotated with a transition or animation, and ‘leaf’ will move around as ‘box’ moves, in perspective.

One thing you may have noticed in these demos is that it’s quite common to have a 3D transform that flips an element around so that you can see its reverse side. In some cases you don’t want the element to appear at all in this situation (say, for example, you want to position two elements back-to-back, so you need to hide the one that’s facing away from the viewer). This is the reason for the last 3d-related property, -webkit-backface-visibility. Its two values—visible (the default), and hidden—specify whether the element is visible or not when that element is transformed such that its back face is towards the viewer.

Here’s a final example that shows backface-visibility in action, along with more 3D goodness, animations and transitions:

Morphing Power Cubes

For more information, see the CSS working drafts on 2D transforms, 3D transforms, transitions and animations. There is also documentation in the Safari Reference Library.

We hope you have a blast with these new features, and share your creations with us. If you find bugs, please report them at bugs.webkit.org.

HTML5 and The Future of the Web

2009-07-17T07:54:17Z

Shared by wpbasti
Good overview to HTML 5 and what it's all about.

Some have embraced it, some have discarded it as too far in the future, and some have abandoned a misused friend in favor of an old flame in preparation. Whatever side of the debate you’re on, you’ve most likely heard all the blogging chatter surrounding the “new hotness” that is HTML5. It’s everywhere, it’s coming, and you want to know everything you can before it’s old news.

Things like jQuery plugins, formatting techniques, and design trends change very quickly throughout the Web community. And for the most part we’ve all accepted that some of the things we learn today can be obsolete tomorrow, but that’s the nature of our industry.

When looking for some stability, we can usually turn to the code itself as it tends to stay unchanged for a long time (relatively speaking). So when something comes along and changes our code, it’s a big deal; and there are going to be some growing pains we’ll have to work through. Luckily, rumor has it, that we have one less change to worry about.

In this article, I’m hoping to give you some tips and insight into HTML5 to help ease the inevitable pain that comes with transitioning to a slightly different syntax.

Welcome to HTML5.

What are the basics?

The DOCTYPE

When I first started researching HTML5 a few months ago, one of the main things I struggled to find was the doctype. A simple thing, you’d think it would be everywhere, but after much frustration, I finally found it buried within w3.org and here it is:

<!DOCTYPE html>

I was also curious why they chose to “html” rather than “html5″, it seemed like the logical way to tell a browser that the current document was written in HTML5, and offered a good template for the future. But I found that <!DOCTYPE html5> triggers Quirks Mode in IE6, and when taking backwards compatibility into consideration <!DOCTYPE html> is a pretty good choice (in my opinion).

Overall, I really like the new DOCTYPE; it’s small, meaningful, and maybe we’ll actually be able to remember this one by heart and not have to paste it from site to site.

New Elements you should know

At first glance, with HTML5, the new elements immediately jump out and command attention. The W3C really listened to the community and planned for the future when architecting the abundance of new elements available. We have everything from basic structural elements like <header> and <footer> to others like <canvas> and <audio> that tap into, what seems to be, a very powerful API which allows us the freedom to create more user-friendly applications while further distancing ourselves from reliance on Flash for saving data and intense animation.

The new structural elements

<header>
The header element contains introductory information to a section or page. This can involve anything from our normal documents headers (branding information) to an entire table of contents.
<nav>
The nav element is reserved for a section of a document that contains links to other pages or links to sections of the same page. Not all link groups need to be contained within the <nav> element, just primary navigation.
<section>
The section element represents a generic document or application section. It acts much the same way a <div> does by separating off a portion of the document.
<article>
The article element represents a portion of a page which can stand alone such as: a blog post, a forum entry, user submitted comments or any independent item of content.
<aside>
Aside, represents content related to the main area of the document. This is usually expressed in sidebars that contain elements like related posts, tag clouds, etc. They can also be used for pull quotes.
<footer>
The footer element is for marking up the footer of, not only the current page, but each section contained in the page. So, it’s very likely that you’ll be using the <footer> element multiple times within one page.

When you take a look at these new elements, it looks like they’re just replacing our common DIV IDs; and in a way, it’s true. But, the diagram below shows that elements like <header> and <footer> can be used more than once on a single page where they behave more like classes and normal HTML elements that you can use over and over again to retain a semantic structure.

Elements like <header> and <footer> are not just meant to represent the top and bottom of the current document, but they also represent the <header> and <footer> of each document section, much the way we use <thead> and <tfoot> in data tables.

The benefits of using these structural elements is mainly due to the fact that they are extremely well defined and provide a great way to semantically structure your document. However, these elements do need to be used with some careful thought because they can, very easily be overused.

Easing the transition from XHTML

Even though HTML 4.01, XHTML 1.0, & HTML5 are all very similar there are some small syntax differences that can, very easily, slip past anyone and invalidate code. Keeping this in mind, HTML5 has some built-in “slack” to make the transition a little easier.

For example, when marking up a form in HTML5, this is the proper syntax for an input text element:

<input type="text" id="name">

But this is also accepted as valid code in an attempt to ease the pain for avid XHTML coders (like myself) who are used to self-closing elements:

<input type="text" id="name"/>

The same rules apply to <meta> and other self closing elements. Legacy elements like <b> and <i> were also left in to help those coming over from HTML 4.01.l

What are the benefits?

With any new technology there has to be benefit; why else would you use it? If your old code works just as well and efficient as the new code there’s no reason to upgrade. No reason at all, trust me, I checked.

Luckily HTML5 is packed with cool new features, code slimming techniques and a lot of stuff I would call very large benefits. Most of which circle around the new APIs and the DOM tree.

Extending the API

The most obvious benefit built into HTML5 is the numerous APIs and the opportunities it opens up for the future of web apps with Holy Grail of application cache and offline capabilities. Google Gears gave us offline data storage and Flash introduced us to the power of application cache (Pandora uses it to save your log in information). With HTML5, these capabilities are now available to use right in the language and can easily be expanded with JavaScript.

HTML5 relies on light scripting to flex its muscles on the Web; this is very possibly the first time, other than jQuery, that one (front-end) technology has fully acknowledged another. Sure, we connect them with classes and IDs but up until now, they have been perceived as separate layers by the principles of progressive enhancement. But as the Web grows we need unity like this across the Web.

Offline Data Storage

The coolest part about HTML5 is definitely its offline capabilities. Programs like Thunderbird and Outlook (and now GMail to an extent) let you browse through your old data while staying offline. With HTML5, you’ll have this same functionality, but in the browser. This is the first serious step towards bridging the gap between the desktop and the Web, and opens all sorts of doors for the future of Web apps.

The W3C has taken the best parts from the various Web technologies and rolled them into, what is being dubbed the most powerful markup language to date.

Some other of the HTML5 APIs

Drag & Drop
The drag and drop API defines an event-based drag and drop system. However, it never defines what “drag and drop” is. This API requires JavaScript to fully work as normal think drag and drop functionality.
Video & Audio
The audio & video APIs are massive upgrades in media embedding. Although support is limited right now, something like video embedding has never been easier:
```
<video width="400" height="360" src="vid.mp4">
```
Geolocation
Geolocation is a very cool API available within HTML5. Its object can be used to programmatically determine location information through a device’s user agent (hint hint: mobile devices).

Where can I use it?

Even with the very limited support for HTML5, the Web is far too progressive to not create a testing environment for us to play around. Currently, Safari is our best testing platform, as it supports most of the new elements and APIs. Of course, that may change at anytime so keep and eye on Opera, Chrome and Firefox as well.

Normally you might think since Safari is a Webkit browser, by default, all Webkit browsers would support the same elements, unfortunately, this isn’t the case. While many of the HTML5 features are supported across the board in Webkit browsers, there are some, like <video>, that are not.

Mobile devices

To effectively use HTML5 right now, we need to be able to control the environment in which it is used. Since support is not as widespread as we’d like it doesn’t make real sense for it to be heavily used unless, of course, we can lock down the usage to certain platforms which have HTML5 support. With Webkit leading the way for HTML5, we can safely focus on devices powered by Webkit.

The 3 hottest mobile devices right now: The Palm Pre, iPhone 3Gs and the new Google Android phone all have browsers that are based off the Webkit rendering engine.

Safari is even leading the way on the mobile HTML5 front; The iPhone (with the latest software upgrade) is the only device I could get to properly render the <audio> element. Because these devices are so young and all use the same rendering engine, the likelihood of them pushing a rapid software upgrade is pretty high.

Right now, you can confidently use many of the HTML5 features in iPhone Web app development and mostly likely expect Pre and Android to follow in suit.

How can we move forward?

Even with all the recent hype surrounding HTML5 and how we all want to use it, it is still going to be a very slow transition away from HTML4.01 & XHTML1.0. It will take time to get developers up to speed, test all the features, waiting for all the :ahem: browsers to catch up, and it will take an especially long time for users to transition out of those old browsers. With all that in mind, we know who we are, we’re all reading this article (I’ve read it about 30 times so far) and we know we have to find a legitimate way to move forward without damaging the past.

We can’t make the full switch yet and there’s no use at this point pointing out who is holding up the show. We all know that any responsible developer would not drop support for a browser that is still heavily used. So rather than yell at a brick wall, here are some things I’ve found that might help us move forward in a positive way:

Semantic DIV naming

Semantically aligning your DIV names with that of the new HTML5 elements will help you get used to the names themselves and also the new functionality and nesting that they want you to do with the <header> and <footer> elements. These are akin to learning the intro the Enter Sandman (for the guitarist out there); it’s not very difficult, but it takes a little practice to get it to feel natural.

Before jumping in full-force to HTML5 production sites, I recommend trying the soft transition with changing your DIV names slightly. There’s no downside that I’ve found to doing this, you can even use the new DOCTYPE with very little consequence.

Faking it with JavaScript

First off, I’d like to say: Please don’t do this in production. If the client side scripting fails, it will completely collapse the site in browsers that won’t take CSS applied to the new elements. This is simply not a good option. It is, however, an option and I’m all about knowing your options no matter what they are.

Creating the new elements with JavaScript

Working in jQuery is cool and all, but as it turns out, there is a built in function to JavaScript to deal with creating new elements:

document.createElement('header');
document.createElement('footer');
document.createElement('section');
document.createElement('aside');
document.createElement('nav');
document.createElement('article');
document.createElement('figure');
document.createElement('time');

…and so on in that fashion.

This will allow you to style these elements in Internet Explorer. Again, the downside of using this technique is that, without the all-important JavaScript, the site will not only be unstyled, all the unrecognized elements will default to inline. So your site will literally collapse on itself.

Client side JavaScript is not the answer for using HTML5. Server side javascript, now that’s a completely different story…

Building browser-specific apps

I’ve always promoted building sites for your audience, so depending on your audience, building browser-specific applications may be a real option. As I mentioned above, it’s all about controlling the environment, if we can control the environment we can control features delivered to the user much better. Google is currently attempting to do this with Google Wave.

The idea behind Google’s new monster product is to revolutionize communication, and do so with the newest technology. Google Wave is built in HTML5 and isn’t usable in all browsers yet. But that’s alright since they’re controlling the audience by only releasing it to select developers for testing.

With Wave, Google is pushing HTML5 as far as it will go (and even a little further). They are taking blogs, wikis, instant messaging, e-mail and synchronous communication to the next level by combining them into place.

Here is what the Wave inbox looks like.

Below is a sort of wiki/chat area with all sorts of real-time communication treats for you to check out (once they release it).

Google Wave being powered by HTML5 is definitely the biggest step forward we have seen in this area. They have done a phenomenal job putting together a creative and innovative product.

Focusing on the mobile

Just like Google is currently doing with Wave by selectively releasing it to developers, we can control the viewing environment when working with mobile devices. By grabbing the user agent, we can design specific applications that use HTML5 for supported devices.

Targeting the user agent of a device is not an ideal method in designing for the general mobile web, but when we need to specifically target a device, like the iPhone, Pre or Google’s Android it’s a pretty solid option.

Right now, the best mobile testing platform we have is the iPhone. With the recent software upgrade, it is very close to having full support. But, if you just want to use the new elements, most any of the big 3 mobile platforms will work fine. If you’re looking for API support I suggest testing on the iPhone with the new upgraded software.

Conclusion

With the strong foundations set up by previous versions of (X)HTML and large community activity surrounding Web standards, we’re coming into a new age with a wealth of knowledge and the ability to learn from our past mistakes (and make some new ones). HTML5 is being set up with the expectations of a very powerful markup language and it’s up to us to utilize it in a way that can benefit us all.

There are so many great features to look forward to from new elements to tons of killer APIs. We can make data available offline, easily combine technologies and create very intricate animations all within a familiar landscape. If you have the time, I encourage you to browse through the entire spec and familiarize yourself even further with all the bells and whistles (there are a lot) so we can use HTML5 to build stronger, richer Web applications for years to come.

Here’s to HTML5, let’s hope it lives up to the hype.

Resources

23 Essential HTML 5 Resources
A comprehensive list of articles and resources related to HTML 5.
HTML5 Demos
HTML5 Demos is a great resource for checking out the HTML5 APIs such as: geolocation, drag and drop, offline detection, and storage. This is a very good and unique resources to test out and see exactly with we can do with HTML5.
HTML5 Gallery
The HTML5 Gallery, like any gallery, is a web site showcase where you can see how others are using HTML5 in every day development. I’ve looked round though this site quite a bit and did some cross browser testing on some of the entries. Many are broken in older browsers, but there are some that hold up very well.
HTML5 Doctor
A resource that catered for the people who wished to find out more about implementing HTML5 and how to go about it. This blog publishes articles relating to HTML5 and it’s semantics and how to use them, here and now.
HTML5 Cheat Sheet
A handy printable HTML 5 Cheat Sheet that lists all currently supported tags, their descriptions, their attributes and their support in HTML 4. Released here, at Smashing Magazine.
W3C HTML5 Spec Overview
Whenever you want to know
about something that no one has written about on the Web, the W3C is your answer. I spent hours scouring this site in researching HTML5. It’s a great resource and I highly recommend reading through whatever you can.
HTML5 Validator
Even with such little support, we still want to make sure our code is valid. Validating your code is a great way to learn and ease yourself into developing with HTML5.
WHATWG Wiki
The HTML Working Group has put together some great documentation for tracking what exactly is going on in the world of HTML5.

References

About the Author

Tim Wright is a web designer/developer and blogger. He has been an advocate for Web standards and accessibility since 2004. You can find more of his writing at CSSKarma or follow Tim on Twitter.

Xing's New Features Not Worth Shelling Out For

2009-07-17T07:51:33Z

Shared by wpbasti
Putting Xing's feature set into perspective with other services. It may sound hard, but often it's a good ideas to open the eyes to see what the competitors on international market offer.

Xing is one of the top business social networks in the market today, especially in Europe. But the new features they're touting for the paid Premium users are grossly underwhelming.

In general terms, the platform is solid. The free functionality is more than adequate for the kind of networking you'd do on LinkedIn or any other professional site. But we have a hard time imagining anyone eagerly laying down cash for the ability to upload their resume and get birthday reminders.

Sponsor

Xing is a serious contender among business social networks. This international public company, based in Germany, has more than 7 million users in 16 languages. 600,000 of those are already paying for Premium membership.

But even at the relatively cheap price of €6 a month, we can't imagine many new customers being interested in a paid service whose most-recently advertised feature enhancements are file uploading (limited to three) and Facebook-style birthday reminders. While it's certainly nice to be able to add your resume or CV to a business networking account or not forget the bosses' birthday, it's far from cutting edge.

If Xing wants to move in to more international markets outside Europe or make a play against LinkedIn, they're going to have to do better.

Discuss

Tipp bei T-Mobile-Drosselung: Auf EDGE umsteigen

2009-07-17T07:47:03Z

Shared by wpbasti
Interessantes Fundstück. :)

Wird das einem Complete-Vertrag zugewiesene Datenvolumen überschritten, verschickt T-Mobile eine SMS an den iPhone-Kunden und drosselt anschließend dessen Netzverbindung auf GPRS-Geschwindigkeit. Nach dem Verbrauch von 300 Megabyte, einem Gigabyte oder fünf Gigabyte an Daten stehen damit bis zum jeweiligen Monatsende nur noch 64 Kbit/s für den Download und 16 KBit/s für den Upload zur Verfügung. Zwar können einzelne iPhone-Besitzer immer noch ungebremst über ihr eigentlich festgeschriebenes Datenvolumen hinaussurfen, doch wer von der Drosselung erwischt wurde, kann die Einschränkung mit einem kleinen Trick mindern.

Wie teltarif nämlich bemerkte, greift die Drosselung offenbar nur im UMTS-Netz. Zwingt man das iPhone dahingegen über die Einstellungen (Allgemein - Netzwerk) zurück zu EDGE, bleiben einem im T-Mobile-Netz 260 Kbit/s für den Download und 220 Kbit/s für den Upload, das ist im Vergleich zur gedrosselten Geschwindigkeit um rund ein Vierfaches schneller beim Beziehen von Daten und sogar um ein Vierzehnfaches schneller beim Hochladen. Zudem lässt es selige Erinnerungen an alte UMTS-lose iPhone-Zeiten wachwerden, in denen der Akku noch relativ lange durchhielt. In Ermangelung eines übermäßig verbrauchten Complete-Tarifs konnte ich den Tipp allerdings nicht selbst ausprobieren, aber vielleicht haben Leser diese Möglichkeit und berichten von ihren Erfahrungen.

When a “Web OS” hits, it will be so much more than a browser launcher!

2009-07-17T07:37:32Z

Shared by wpbasti
Well written. Describes the real idea why putting everything into the cloud.

original by mwboeckmann

Everyone got in a tizzy over the Google very-early-darn-leaks-pre announcement of Chrome OS. There have been many attempts at a “launch into browser” system, and the timing / marketing hasn’t been right. The journalists have by and large shown that they do not understand any nuance and could only think to write about the external battle of the titans (Chrome OS to destroy Windows!) or the internal battle of the titans (Android vs. Chrome OS).

The news is so early, that it is mainly a no-op right now, other than showing that to get to that point, Chrome will probably be extended quite a bit (access to more native services etc). I am a believer that this has to happen (hence Gears fan), but I also do worry that it will be rushed. We don’t want to fork the Web….. but let’s wait and see.

What I find most interesting though, is that I don’t think that the world needs a computer that boots almost-solely into a browser.

Kent Beck was talking about how he is using Chrome Browser OS right now as a social experiment. Yes. We can all delete every application from our machines and maximize a browser and live in it. That isn’t what will be exciting about a true Web platform.

I have been playing with a Windows laptop, and what has interested me is how much I can get done because my world is available through the browser. Back in the day, if I was at a friends house, I would download putty.exe and telnet/ssh into my world, and it would be ugly text. Now, I can jump on a random computer and access my entire social environment (email, twitter, etc). I can get real work done. One of the reasons that we did Bespin was to extend that to coding too.
This brings me to my benchmark for when I think a web OS will be here.

If I can sidle up to a random computer and have access to everything that I can do on my own laptop, then we have made it

Ironically, I almost used to be able to do just that! In university I could login to any machine on campus and see my screen exactly as I left it. I want X back baybee! ;)

We are getting closer, yet still a ways off. I hate the management that I have to do with iTunes. I want to by the license to play music, and have my collection in the cloud, and sync’d in smart ways. I want to be able to set profiles for what is downloaded and offline-available on my laptop versus the media server vs. the ball and chain’s laptop vs. my phone.

I want my settings to follow me around. Another reason why I am so excited about the future of Weave-like services. Let me login to the browser and get my history, passwords, awesomebar setup for me. Go further, and let me “switch user” on the persons machine and have the login be an identity service like Open ID, Facebook, Weave, or what have you.

When we have an open identity system that works, with services that let you take your entire world with you hooked to your identity, then we can talk about how cool the Web platform is as an OS. We will have moved up the services stack from managing the state of windows on the screen, to higher level services.

Marry this to auto syncing of data between all of your devices, and you have a truly new world. Give me that world, not just and autoexec.bat that launches browser.exe :)