Back in 2010 we put together our first list of the 30 best and worst Web tech tattoos. Here's our latest compilation, including an augmented reality tattoo, HTML tags, Javascript and C++, Debian, Wordpress, Google, Microsoft, RFID, QR codes, even Bill Gates' face. If you have work that's better, or worse, show it off in the comments.

Unix commands/C++/Javascript

Google

Microsoft

Next page: RFID, Augmented Reality, QR codes and Tux sitting on Windows eating an Apple!

RFID

Augmented Reality

Android

HTML

Networks

Tux

Debian

QR Code/Shotcode

WordPress

Sources: Machine gun Tux: wrightzen; Jobs, left: Cult of Mac; Jobs, right: SODAPOP; RIP toe, Geeky Tattoos; Jobs, arm: Cult of Mac; Stay hungry, wrists: Speak Truth, Breath Love; Stay hungry, arm: Gristle Tattoo; Apple/Jobs icon: gadgetpolice.com; "There is no reason": wease.com; "One more thing": Cult of Mac; Unix commands: Geeky Tattoos; Google It: jessversus; Powered by Google: Geeky Tattoos; Windows XP: traviscostrrr; Windows: bremiclem; Bill Gates: Big Tattoo Planet; RFID: The Loom; Augmented reality: iheartchaos.com; Android: eagyn; Android skateboard: the brand show; HTML body: iamdonte; : interbent; : interbent; CCIE: knuckletattoos.com; Tux: Sabrina Ricci; Debian arm: MicheleM_; Debian back: NiNiaX; QR code: Geeky Tattoos; ShotCode: Ad Lab; Wordpress: Hugo Baeta

Basically, we're looking to highlight tools that are innovative, widely used and/or wildly useful for Web developers.

jQuery and jQuery Mobile

No list of Web developer tools would be complete without jQuery, the ever-popular JavaScript library that we've covered extensively on ReadWriteHack.

Even Microsoft has made the case for jQuery and technology surveys show jQuery well in the lead for 2011, moving from 27% of sites surveyed in December 2010, to 42% in December 2011.

Mobile developers got a boost this year with the introduction of jQuery Mobile 1.0. jQuery mobile is meant to work on "every popular mobile, tablet, e-reader and even desktop" platform. That's a tall order, but the response so far to jQuery Mobile seems to be overwhelmingly positive.

That's not to say that jQuery is free of critics. Some believe that jQuery is in need of a little slimming down. Of course, this is not atypical for any project reaching maturity. I'm not taking a position either way, but I would note that you rarely see a successful project that doesn't generate a backlash of some sort.

Modernize IE with CSS3 PIE

Everbody loves pie, especially frustrated Web developers who need to cope with the shortcomings of older versions of Internet Explorer. You can't fix the market and convince millions of people to upgrade to a more modern browser, but you can try to fix the browser.

CSS3 PIE ("Progressive Internet Explorer") is meant to bring some of the spiffy CSS3 features to Internet Explorer. Want to see how it works? There's a full list of demos and plenty of documentation for getting started. Naturally, the project is on GitHub, and it's available under the GPLv2 and Apache 2 licenses.

PIE is not quite 1.0, but it's getting very close. Jason Johnston announced the fifth beta of 1.0 in September, which added IE9 support and fixed a number of minor issues in IE6 through IE8.

Bootstrap

Twitter released its Bootstrap toolkit for rapid development of Web applications in August, and it's remained one of the trending repos on GitHub ever since.

Bootstrap is pretty simple, it's just CSS that provides a standard set of solutions for things developers need for Web sites and Web apps. Developers can use Bootstrap for prototyping, or organizations can standardize on Bootstrap (as Twitter has) to provide a uniform design across a set of sites/applications.

Bootstrap is easy to use, just drop in the pre-compiled CSS into your project, or use LESS to compile a modified version.

LESS

Speaking of LESS, here's a little more on it. Ahem, sorry about that. Anyway, LESS is a dynamic stylesheet language that extends CSS to be much more expressive and easy to use.

Standard CSS doesn't support variables, functions, operators, and so on. LESS gives you the ability to do things that CSS ought to let you do. For example, LESS lets you define a color once and then use it through your stylesheet with a single variable (like @color instead of #4D6F92). The advantage, of course, is you make changes much more quickly and efficiently.

But LESS also provides the ability to define and re-use classes easily, and even use operators for proportional elements of your page with operators. If you want to check out LESS, the site has plenty of examples and source is available on GitHub under the Apache 2.0 License.

Chrome Developer Tools

Firefox's demise is has been greatly exaggerated, but it's probably no exaggeration to say that Chrome has been gobbling market share because Web developers love Google Chrome. (Or at least they hate Google Chrome less than the other Web browsers.) One of the clear reasons developers dig Chrome is the Chrome Developer Tools.

Chrome's Developer Tools are based on WebKit's Web Inspector but include a number of enhancements. The developer tools in Chrome are just a click or keystroke away, and give you the ability to do everything from edit HTML to view breakpoints in your script, perform remote debugging, and much more. The devtools also have an experimental API for those who'd like to extend the developer tools even farther.

Next page: The rest of the best Web developer tools of 2011

Andi Smith has a fantastic post on 25 secrets of the browser development tools you should look over if you spend any time at all with Chrome's developer tools, or any of the browser development tools. This post from Paul Irish is also worth checking out, and the video from Google I/O 2011: Chrome Dev Tools Reloaded.

You might also want to check out this cheat sheet from Boris Smus.

SourceKit and Ace: Top-Notch Browser-Based IDEs

Which text editor is the best for Web developers? (Or anybody editing a lot of text, for that matter.) I'd argue for Vim, hands down.

But what if you're looking for a browser-based IDE for development? Well, when we surveyed ReadWriteHack readers, they voted for Ace and Ace-based SourceKit. Ace is a standalone editor, formerly known as "Bespin" and "Skywriter." SourceKit takes Ace and turns it into a Chrome extension that taps into your Dropbox account.

Though Ace is more flexible, in that it will emulate keybindings for several popular editors (including vi), I like having SourceKit right at my fingertips in Chrome. Plus, the Dropbox connectivity is handy as well, though I do wish it was possible to limit SourceKit to one directory under my Dropbox directory. For one thing, I'd prefer not to give any application more access than strictly necessary. For another, I store a lot of stuff in Dropbox that I won't be editing and don't want to have to sort through.

This is a rapidly growing area, though, so I'd be very curious to hear what IDE or editor ReadWriteHack readers prefer.

PhoneGap

Want to write HTML5 applications, but provide similar features to native applications on mobile devices? PhoneGap seems to be far and away the most popular solution.

PhoneGap lets developers build an app once, then deploy to multiple platforms. PhoneGap supports iOS, Android, Windows Phone, BlackBerry and others. This includes webOS, but I'm not sure how much demand there's going to be for that platform in 2012.

Now we're not just talking about a mobile site that displays nice on your mobile device. PhoneGap actually provides access to hardware and native features on your phone, like the camera, accelerometer, network, geolocation, contacts and notifications. If you're targeting iOS and Android, you're not far behind native applications.

The company behind PhoneGap, Nitobi, was acquired by Adobe earlier this year. But that should be no cause for alarm. PhoneGap has been contributed to the Apache Software Foundation (ASF) and is currently in the Apache Incubator. If you haven't looked at PhoneGap yet, check out the Getting Started Guide and the video tutorial.

Popcorn and Popcorn.js

New, but noteworthy, there's Popcorn.js. Part of the Mozilla Popcorn project, it's a JavaScript library that gives you time-based, interactive media via the Web.

It's not just a way to show video without Flash, Popcorn.js actually lets you create timeline-based Web presentations. This includes HTML5 audio and video, but also rich content presentations that make use of audio, video and other Web elements.

Popcorn.js promises to integrate content from Web services like Wikipedia, Twitter, Facebook, YouTube and Google Maps. Early demos show things like integrating time-based overlays into videos, with links to content. So, for example, you could develop a video presentation that has links to more information at certain times in the video.

Right now, it's in early development and watching some of the demos in Firefox and Chrome is laggy at best. Expect it to be a while before the Web explodes with Popcorn presentations – but the future of Web media looks good.

The Future? Waterbear

No I don't think anybody is going to be putting this into production, but Waterbear is worth looking at because it's a good entry to programming for kids. The idea is that kids can start with a system of "draggable, snappable blocks" built with HTML5, CSS3 and JavaScript.

Developer Dethe Elza says that it's in pre-alpha and in "constant flux" right now, but here's hoping the project continues to move forward and turns into a popular system to start kids on programming. It's free software (under the Apache License 2.0) and anybody can head over to GitHub and dig in.

Your Picks?

Of course, this is a highly subjective list based on my observations from the last year. I'd love to hear from Web developers about the tools that you find most productive, exciting, useful, etc. Feel free to share your favorites in the comments, and if you see something trending that needs writing about in 2012 drop me a note.

Typically, PDFs are rendered in a browser with a plugin - either with Adobe's own PDF reader or with another provider's renderer. These plugins often cannot take full advantage of PDF features. Furthermore, as Gal points out, there is quite a large trusted code base, something that's forced the Google Chrome browser to have sandbox the PDF renderer in order to avoid code injection attacks. An HTML5 version would be make this more secure, as would the open source nature of the project.

"It's important to note that we're not trying to promote PDF to a first-class web citizen like HTML5 is," writes Gal. "Instead we hope that a browser-native PDF renderer written on the web platform allows web technologies to subsume PDF." But with the ubiquity of the PDF, it's great news - particularly for the mobile Web - that it may soon be easier to view PDFs natively in the browser.

Mozilla's Rob Sayre:

"We believe that the benchmarks used in Kraken are better in terms of reflecting realistic workloads for pushing the edge of browser performance forward. These are the things that people are saying are too slow to do with open Web technologies today, and we want to have benchmarks that reflect progress against making these near-future apps universally available."

The new benchmark indicates that Firefox 4 (with the new JaegerMonkey JavaScript engine) is more than 2.5x faster than the current stable version of Firefox 3.6. Sadly, the site is currently suffering from a major traffic spike after its launch, but we will update this post later with our own findings.

In his announcement, Sayre notes that synthetic benchmarks tend to be the least useful, while testing real or modified applications will give developers the most realistic view of how fast their browsers really are.

It remains to be seen if Kraken will be able to take the position that Sunspider, Google's V8, and Mozilla's own Dromaeo currently hold. As with all vendor-sponsored benchmarks, there will surely be some concern among Mozilla's competitors that the benchmark is geared towards favoring the organization's own products. Kraken's code will be released under an open-source license, however, so it will likely be easy for the team to counter these arguments.

In our own (unscientific) tests with the help of the SunSpider  and V8 benchmarks, the JaegerMonkey version of Firefox 4 easily outperformed the most recent beta of Firefox 4 (around 370ms vs. 450ms in SunSpider and 2200 points vs. 1200 points in V8). At the same time, though, Google's Chrome is still significantly faster (260ms for the SunSpider benchmark and 6631 points in V8 for the current developer version). These benchmark results show that the JaegerMonkey team clearly managed to speed up the browser's performance, but with regards to pure JavaScript performance Firefox is still far behind Chrome.

That said, though, benchmark performance is not always a good indicator for how fast a browser feels in actual usage and there can be little doubt that the JaegerMonkey-enabled build feels faster than the current Firefox 4 betas, and the difference with Chrome is barely noticeable.

You can download a copy of Firefox with the JaegerMonkey engine here.

According to Mozilla developer David Mandelin, the team spent the last eight months "studying the classic research, reverse engineering the competition, measuring, experimenting, designing, prototyping, analyzing performance, scrutinizing assembly code, redesigning, coding, and lots and lots of debugging." The result of this project is a completely revamped JavaScript engine for Firefox that makes demos like this far more enjoyable. Mandelin also notes that the final version should be "a little bit faster yet by the time Firefox 4 is released."

Given the combination of hardware acceleration, better JavaScript performance, a revamped interface and many other small changes, Firefox 4 is shaping up to be a very interesting release for Mozilla. The final version of Firefox 4 is currently scheduled for the fall.

That same desire to have our data at any time doesn't influence mobile development as much because our phones are portable and are already with us all day. Web apps for mobile will instead have to rely on other ways to attract users away from native applications. To do that they will first need strength in numbers, and that means attracting developers, and as Amirzada explained, there are several reasons developers should be excited about mobile Web development.

Attracting the Mobile App Developers

The first is the simplicity of the coding itself. Experienced Web developers are more likely to pick up mobile Web development than, say, iPhone app development. Developers can use HTML, CSS and JavaScript to create Web apps instead of learning new languages to code native applications. Native app development may not be the hardest of tasks from a developer's point of view, but Web development is a skill they have likely already mastered and are adept at.

Secondly, as Amirzada pointed out, the mobile Web market is much larger than native applications markets. By coding for the mobile Web, app developers can reach a broader audience on multiple devices and platforms in a single stroke. Platforms like iPhone, Android and Windows Mobile (which all use unique languages and techniques to develop applications) only represent a fraction of the overall mobile device market, while the mobile Web is accessible from a much larger number of handsets.

The third and possibly most important reason developers should be attracted to mobile Web apps is that the Web is an open platform. Developers don't have to spend weeks on an application only to see it rejected for increasingly strange reasons. Steve Jobs can't censor the Web like he can the iPhone, and there is no waiting for applications to be approved.

Hurdles to Overcome

Unfortunately for mobile Web app fans, these benefits also come with equal and opposite disadvantages. While coding for the Web may be simpler than creating native apps, the native platforms allow the apps to take advantage of the device's functions and features. From a user perspective, native apps are more appealing because of this. I would rather use an app that felt like it belonged on my phone rather than use a Web app that seems shoehorned onto my device through HTML.

Another problem with Web apps is their performance when compared to native apps, which are streamlined to run as efficiently as they can on the device they are designed for. Amirzada said that this is changing, however, as HTML5 improves on the infrastructure of the Web and makes applications faster and more functional.

He also demonstrated how using open-source JavaScript frameworks, like Cappuccino, on Qualcomm's Brew mobile platform can give developers access to various device sensors to create richer Web-based mobile apps. The World Wide Web Consortium (W3C) is also working on bringing mobile Web apps up to speed by creating a standard for Web-based push notifications.

But the question still remains - will mobile Web apps one day outpace native applications? The largest push in this direction seems to be the openness of the Web, as closed platforms have turned many developers away from popular native platforms like the iPhone and iPad. But those developers could just switch to Android or Windows Mobile. Once we reach a point where mobile devices have the computing power of our desktop machines, mobile Web apps could make a run on native apps, but that is still likely a few years out.

Let us know what you think about mobile apps versus native apps in the comments below!

Disclosure: Qualcomm covered the author's travel costs to attend Uplinq 2010.

Although sudoSocial would be suitable for curating any stream of content, explains the introductory blog post, in its early, still rather sparse format, it's better for personal homepages that aggregate your various feeds, like Flickr photos and blog posts, for example.

To create your own personal homepage using sudoSocial, you'll need to have an OpenID account and, the page reminds you, that's probably something you already have - even if you didn't know it. A link to OpenID's "Get an OpenID" page displays a collection of OpenID enabled services like Google, Yahoo, Blogger, flickr, MySpace, WordPress, AOL and others. For our own testing purposes, we used a Google Profile URL. Yours can be found here: http://google.com/profiles/me.

After signing in and filling out a little profile info (if it's the first time you've used an OpenID), you're taken to the Stream Editor where you can begin to add sources. Any URL, Atom or RSS feed is supported.

In the next tab, you can edit the design using CSS, JavaScript and Processing.js. (Oh, yes, did we forget to mention this tool isn't for the mainstream user?)

When you've finished your configurations, you could end up with a webpage that looks something like this: http://sudosocial.me/u/pattyokdemo, if you choose a more basic setup, or like this: http://ozten.com/homepage-demo.html if you design something a bit more advanced.

If you're interested, you can also contribute to the project by hacking the source code, found here: http://github.com/ozten/sudosocial.

A Better Option for Everyday Users: Flavors.me

However, if you were hoping that sudoSocial would provide a simple way to quickly set up a personal homepage, you're going to walk away feeling disappointed. A better option for that purpose, or really any stream aggregation of your choosing, is Flavors.me.

This lovely, user-friendly web service lets you customize everything design-wise, including typefaces, layouts and color schemes while also aggregating the feeds of your choice. And for most of the supported services (Twitter, Facebook, YouTube, flickr, etc.), you don't even need to know the RSS's feed URL - you simply click "add service" and authorize the app.

That said, sudoSocial isn't designed with the mainstream user in mind. It's intended as a more advanced platform for designers and developers who know what they want and how to make it happen via code. For them, sudoSocial may be a good starting point, but it still needs quite a bit of polish and bug-quashing before it's fully ready for a wider audience.

]]> Discuss]]> http://www.readwriteweb.com/archives/mozilla_launches_sudosocial_an_experimental_lifestream_platform.php http://www.readwriteweb.com/archives/mozilla_launches_sudosocial_an_experimental_lifestream_platform.php Lifestreaming Wed, 02 Jun 2010 07:04:06 -0800 Sarah Perez Last month was Javascript season in Europe, with two conferences dedicated to the language that powers interactive web applications, and a third, which featured it heavily. If a common theme emerged, it was the buzz about Javascript leaping out of the browser to serve other domains, and the noise has only become louder in the aftermath.

Of all the applications outside the browser, server-side Javascript is the most alluring for reasons described in this post. An idea that would have had you laughed out of the room a few years ago is edging towards reality.

This guest post was written by Michael Mahemoff, who works at Osmosoft as lead web developer and blogs regularly for Ajaxian and on his his personal blog, Software As She's Developed. You can follow him on Twitter.

The Perfect Storm

Server-side Javascript isn't a new phenomenon; Netscape stuck Javascript in the server way back in 1996, right after they introduced it to the world as a browser technology. Interest soon waned, and the language was confined to the browser for the most part. Even there, it didn't get a whole lot of respect and was frequently dismissed as a hack language capable of no more than annoying alert boxes and gratuitous ticker tape animations.

But suddenly, serious web-based applications started sprouting up. GMail, Google Maps, and JotSpot (kind of a Google Docs predecessor) were all running inside the browser. They weren't supported by Flash, nor ActiveX, but Javascript manipulating the browser's Document Object Model (DOM). The term "Ajax" was coined to describe these applications, and a community flourished. A few years on, Javascript has become the world's most popular programming language by some accounts. Not so surprising when you consider its special status as the standard language shipped with all major browsers. It's the web's lingua franca. While most web developers have a favourite, primary, language for server-side work, they converge on Javascript when it comes to the browser. Javascript today can be compared to the English language: it's arguably the most popular language as long as you count basic competency, not just outright fluency.

Given that you're already using it in the browser, why not stick it in the server too? One language all the way down makes it easier for a single programmer to work on either side of the wire; there's less of a mental shift. For project managers, the trend would make it easier to move developer resources between the front end and the back end if a common language is used on both. Many in the developer community now recognize Javascript as a respectable language, with understood patterns for effective use. In fact, many of Javascript's negatives were a case of misdiagnosis: the problem was really the browsers' DOM (Document Object Model) APIs, not the language itself. Take those out of the equation and you're left with a solid language capable of tackling diverse problems.

There's also a promising reuse story for this "dual-side Javascript" scenario. Take form validation for example. Right now, it's common to write the same logic in two different languages. In Javascript, you write a validator to give the user immediate feedback inside the browser, and in a language like PHP, you write a validator to ensure data integrity once the form data has been uploaded to the server. But once you switch to Javascript on the server, you just need to write a single validation routine at both ends. Under some styles of development, you can also arrange for a function in the browser to directly call another function inside the server; the code is smaller and simpler to write, not being bogged down in the technical details of transferring data across the network.

Javascript performance has also moved forward in leaps and bounds, thanks to browser competition. Firefox's Javascript engine, Spidermonkey, increased in speed by a factor of 20-40x. Safari's underlying engine - Squirrelfish, aka Nitro - posted similarly impressive gains (see chart below), and Google Chrome came on the scene last year along with its highly optimized V8 Javascript engine, a very real contender in the "fastest Javasript engine" stakes.

Server-side Javascript also dovetails nicely the new breed of NOSQL databases. Being web-native, these databases tend to communicate in HTTP, and in some cases JSON (JavaScript Object Notation) is the message format. Javascript libraries already include support for exactly that kind of interaction and programmers are familiar with them. Some of these NOSQL systems go beyond data persistence and into the zone of full-fledged Javascript application environments.

Towards A Mature Server-Side Ecology

In the simplest case, all you need to run server-side Javascript is a Javascript engine to plug a web server into. There are plenty of open source options here; the choice will come down to the language its implemented in, which affects the kind of environments it can run in, in addition to the usual factors like performance and level of support. Many Javascript platforms run on the Rhino engine for example, and Rhino is built in Java; this means that they can easily integrate with Java components. Thus, you can build the entire user-interface in Javascript - including a thin UI layer on the server - and still have it backed by a conventional enterprise Java stack. Helma is one prominent example of this architecture.

Once equipped with a Javascript engine, you can write simple CGI scripts as you would with any other language - read the request, write the response. In practice, you'll also want good library support to get anything useful done. Some environments do come with libraries, and you can also make use of existing libraries developed for browser-based Javascript. What will really make the biggest impact, though, is industry-wide standardisation. To that end, there's a strong grassroots movement underway to converge on a complete API: CommonJS is defining an API for file access, networking, unit testing, and so on, as well as declaring how these components should be packaged for easy import. Multiple efforts are implementing the nascent spec in several major Javascript engines (Rhino, Spidermonkey, V8, EjScript). One open-source platform complying with CommonJS is Narwhal. It has considerable momentum and runs on several of the Javascript engines.

CommonJS is raising the level of abstraction for server-side Javascript and allowing developers to use patterns familiar from high-level servers in other environments. Writing a web server no longer means hand-coding the lower-level cruft. Thus, you get a framework like Jack, which is similar to Python's WSGI and Ruby's Rack. Jack's based on the idea of fine-grained "middleware" libraries, able to be composed and reused, and there's a separate project, Nitro, to build such components for Jack. So Nitro builds on Jack, and Jack builds on CommonJS. This is an example of the ecosystem beginning to emerge in server-side Javascript.

Use the Force! Building on Javascript's Strengths

In the previous section, I treated Javascript as just another language with all the usual server-side abstractions and the well-trodden path towards modularity and reuse. That's not a bad thing at all, since we also benefit from the synergies of running the same language in the browser and the server mentioned earlier. Where things get really interesting, though, is with frameworks that exploit Javascript's unique characteristics.

It's easy to get carried away with Javascript's efficacy as a regular scripting language, so let's remind ourselves that its roots are inside the browser. What the browser has, that a generic web framework doesn't, is the Document Object Model (DOM). This is the browser's model of the web page's contents. What if we gave Javascript access to a DOM?

DOM access is a key feature of the Jaxer environment. It gives scripts access to an entire server-side Firefox instance. Developers can therefore manipulate content as they would in a client-side application, and output the resulting page. This overcomes one of the objections with Ajax apps, which is "what if the user has turned off Javascript?". The page still comes out as plain old HTML. That's a lot of power, and the patterns for using this kind of thing are not yet fully understood, but it has plenty of potential for exploration. There are also potentially great benefits for testing client-side applications if you can simulate an entire browser instance. jQuery founder has been working on a product called env.js. Where Jaxer is essentially an entire Firefox instance, env.js is an attempt to build a simulation of the browser environment from scratch, under active development. It's too early to say if its scope will stretch beyond testing and into the realm of server-side Javascript.

DOM manipulation may be one characteristic thing about Javascript we can exploit, but there is also another (related) thing: event-handling. The language was more or less designed to respond to user events, so it has a great model for handling them that is familiar to any Javascript programmer worth their salt.

For most server-side programmers, event-handling capability will yield a big fat "who gives a damn?". Server-side scripts don't sit around waiting for events to come in. They usually just look at an incoming request, deal with it, and send out a response. Then they exit as soon as they can. All good stuff, but there's a completely different paradigm possible. It's part of the trend towards the real-time web and the design pattern known as Comet.

With Comet, the server holds on to the connection for a while, and continues to stream out information intermittently to the browser. The typical example is a two-way chat - as soon as one guy says something, the Comet server sends the message to the other guy. This is event-driven programming all over again, and compared to the usual suspects on the server, Javascript is well-placed to support this paradigm.

A framework that's taking advantage of all this is node.js, or just "Node" to its friends. Node is interesting because it requires scripts to explicitly close the connection; if they don't close it, the connection just stays open and the script can handle events as they come in, usually by sending more information down to the browser. Less than a year old, the project already has a strong community and numerous derivative frameworks and applications. A similar model has been used in other frameworks, like Python's twisted, but Javascript may turn out to offer a neater syntax for this kind of thing. By daring to be different and using javascript for what it's best at, Node is shaping up as a framework to watch. The speed of Node apps is likely to give Javascript serious cred among server-side developers.

The Cloud. Of Course, the Cloud!

No article on server trends could ignore the famous cloud. How does javascript work in virtualised computing environments? With a suitable engine, you can certainly set up an environment manually using amazon EC2, google app engine, or similar cloud hosts. However, you can do it easier than that with some of the other solutions around. Joyent took a big bet on Javascript when it acquired Reasonably Smart earlier this year; the host now offers a dead-simple runway to host Javascript scaleably. Aptana, the company behind the Jaxer platform described above, does likewise.

Something's Going on Here

Before we get too excited about this trend, I should make one thing clear. Conspicuous by their absence are the real-world server-side Javascript apps. There don't appear to be many sites running Javascript in the server at this time. Probably the most popular site powered by Javascript is EtherPad, the real-time collaborative notepad from AppJet, the company acquired by Google last week. This is a cautionary example, because AppJet launched as a cloud-based server-side Javascript framework before dropping it to concentrate on Etherpad. Aptana has also announced they are pulling back on Jaxer due to difficulties monetising it. Maybe this is more of a statement about cloud hosting revenue models than server-side Javascript, but it's worth asking how other attempts to propagate server-side Javascript will fare.

One of the critical success factors will be a comprehensive standard API; it's a prerequisite to a vibrant ecosystem of interoperable components, and with a range of engines to run on. We now have the seeds of that with commonJS. Another factor is best practices for using the language; again, we've already discovered much of that as a side benefit of the Ajax revolution. Frameworks like Node, which build on Javascript's unique characteristics, are building on those to establish best practices for server-side Javascript. Reuse of both knowledge and practices will give Javascript its best chance yet to stand up as a viable alternative to the usual server-side suspects.

Although Javascript is a far better language than was previously assumed, its syntax still has plenty of quirks. If we restrict ourselves to the subset of Javascript found in all the major browsers today - and arguably it makes sense to do so - it's arguably lacking certain features of other server-side languages. Those other languages are free to evolve autonomously; in contrast, Javascript's fate is heavily determined by standards bodies, browser manufacturers, and the patterns around how users upgrade their browser.

In this sense, the language's strength - shipping with every browser - is also an Achilles' Heel. That said, the language may well prove "good enough". The benefits of "one language all the way down" may outweigh the cost in many cases. The will is stronger than ever to make server-side Javascript a reality, and it's translating into a visible surge of activity in the web community. There's the promise of code reuse and the possibility of cutting in half the number of programming languages involved in building a typical web application.

Many smart developers have gravitated towards Javascript in recent years, as a means of producing world-class front-end apps. The attention has progressed our understanding of the language. Should server-side Javascript go mainstream, a third wave of Javascript developers will be joining the community and enriching the ecosystem.

Why is Google doing this? Because the more powerful web applications become, the more important Google's search, browser and nascent OS become. More relevant to developers than some grand anti-Microsoft conspiracy, though, is that some serious UI sweetness may be forthcoming.

The Closure Compiler will scrunch up your weighty javascript for super-efficient deployment, allowing you to do more in the user's browser with a much smaller code payload to deliver. The compiler is available in binary, as a web app and as an API. Google is also releasing a Firebug extension called Closure Inspector that will translate those compiled bits of code back into their original format.

The Closure Library is a collection of cross-browser, modular, "industrial strength" UI components from across the various Google properties. Rich text editor, DOM inspector, drag and drop ala Google Maps - you want it, you got it.

Also released are a number of high-efficiency Closure Templates.

Google's Amit Agarwal says that all of the above were originally built as "20% time" projects but then became fundamental parts of some of the most popular Google applications. Now these technologies can be used in building your apps, as well.

It will be interesting to see how these Google offerings stack up and get adopted compared to Yahoo's YUI library.

After testing Opera 10 for a while, it quickly becomes clear that it is a perfectly capable browser. It's got everything the majority of users would ever want, ranging from the 'speed dial' homepage to a sidebar for taking notes, which are synced between different machines, just like your bookmarks. There is a 'magic wand' that automatically fills in passwords from Opera 10's built-in password manager, mouse-gestures, real-time fraud protection, a BitTorrent client,  and the tabs now optionally show a rendered version of the page for a more visual experience. The 'visual tabs' can also be put into a sidebar, a nice feature in the age where vertical space is limited as users have moved to wide-screen displays.

Opera 10 is available for Windows, Mac, Linux, FreeBSD, Solaris.

Speed

In our informal tests, Opera 10 couldn't match Firefox, Safari 4, and Chrome in most benchmarks. On a MacBook, Safari finished the SunSpider JavaScript benchmark in 711ms while Opera needed over 5700ms. In daily use, however, these benchmarks tend to mean very little and we barely noticed any difference.

Even though Opera has always been a good browser with a very passionate user base, it never quite caught on with mainstream users. Opera 10 is definitely Opera's best browser to date, but chances are that even this new version won't help Opera to gain a lot of market share as other browsers now have the momentum. However, if you haven't looked at Opera for a while, now is a good time to give it a try again. And if you often find yourself in a situation where you have to deal with a sluggish Internet connection (airports, hotels, etc.), Opera Turbo alone makes this a handy browser to have around, even if you don't make it your default browser.

For developers, TestSwarm currently supports 7 operating systems, ranging from Windows 2000 to OS X 10.5. The project runs its tests on all the major browsers. Whenever an error occurs in a specific browser, TestSwarm will return detailed data about what exactly went wrong.

Currently, TestSwarm is testing a number of popular open-source JavaScript libraries that a lot of developers rely on, including jQuery, YUI, Dojo, MooTools, and Prototype. You can download and install TestSwarm on your own servers if you want to use it for your own project. The code is available here.

Future Plans

In the long run, the team plans to make it easier for developers to test their own code on Mozilla's TestSwarm architecture as well. The team also plans to give developers the option to run manual tests, where user interaction is needed.

How to Participate

If you want to help out, just head over to the TestSwarm site. If your browser is needed, a box with an invitation to join the project will appear. Just keep TestSwarm running in a tab and it will automatically ping the project's servers for new tests every 30 seconds.

You can find more details about how TestSwarm works in this screencast:

Test Swarm Walkthrough from John Resig on Vimeo.

Note: If you want to live on the cutting edge, here are the instructions for enabling the Chrome Beta and Developer channels.

Some Highlights

Here are some of our favorite apps in the current Google Chrome Experiments line-up:

Social Collider

Social Collider might just be one of the coolest Twitter visualization tools we have seen in the recent past. Social Collider shows the connections between different Twitter users. You can use a user name or keyword to initiate Social Collider, but it can also be used to visualize current Twitter trends.

Note: Using Social Collider can be quite CPU intensive, but the results are definitely worth it.

Google Gravity

This is an utterly useless experiment, but it shows off some of the surprising possibilities of using JavaScript together with the Box2D Physics Engine. After you have seen gravity take its toll on the Google homepage, also try to perform some searches.

Smalltalk

Smalltalk is another Chrome Experiment that uses the Twitter API to visualize real-time chatter on the Internet. Specifically, Smalltalk looks at comments about the weather in the US (sunny, foggy, windy, etc.). Besides JavaScript, Smalltalk also makes use of the canvas element in HTML5 and the jQuery framework.

BallDroppings

Josh Nimoy's BallDroppings is a cool little musical toy that has already been implemented in a number of other languages. Here is the JavaScript version. Just draw a few lines on the screen and see what happens.

Creating Codes

Using iCandy is easy. You simply drag and drop a web site link or iTunes track into the iCandy interface to create the QR code. You can also add in photos from either your computer or an online service like Flickr or Snapfish. The iCandy application then creates the barcode which you can then print out or use elsewhere on the web...like in a Zazzle.com store for example, where you could sell your barcode-emblazoned merchandise. The iCandy application supports any URL from the web, but will specifically support media from iTunes, YouTube, flickr, Facebook, MySpace, Scribd, Slideshare, last.fm, Pandora, and imeem.

Scanning Codes

For end users interacting with the barcode, the process is simple, too. All you need is a webcam or a barcode reading application for your smartphone. The company suggests that iCandy could be used to create a digitally enhanced album collection which you could use to play tracks from your iTunes music library. This is demonstrated, quite adorably we might add, by one of the iCandy engineer's 4 1/2 year-old-daughter, who launches music (and dances around) in this YouTube video.

Although this idea of interacting with your music collection appears to be the primary focus of the iCandy application, we think its other uses are just as appealing, if not more so. With the QR codes created by the application, bands and other artists wishing to promote their music could create merchandise - flyers, t-shirts, cards, etc. - which link directly to their homepage on the web or the music itself.

Imagine how this could work: after a long night out at the local bars and clubs, you could simply scan a card or other giveaway item the band had handed out after their last set. That's much easier than entering in a URL or even having to locate the album listing manually. Thanks to iCandy's innovative technology, a code scanned for music you don't already own, would also give you a prompt to purchase it from iTunes, Amazon, or Rhapsody.

iPhone Application in the Works

Even better than having to use your computer would be using your iPhone as the barcode scanner instead. Since the QR codes are just normal barcodes, you can scan them today using any third-party QR code scanning application on your iPhone, or any other smartphone for that matter. However, the company is working on an iPhone application that would auto-play the track if you already owned it and it was in your iPhone's music collection. If it wasn't, you could be shown the track in iTunes so that you preview it or purchase it, if desired.

The auto-play feature is where the company is having problems at the moment because of how Apple has the phone locked down. A company representative told us that they will probably have to meet with Apple in order to get this sorted out properly and play by all the rules.

In the meantime, QR codes that link to other web sites - or even YouTube videos - will work with the iPhone. Other camera-equipped smartphones can also be used to scan the barcodes and direct the users to the appropriate web sites.

Try it Out!

The iCandy application is still in beta, but you can register to try it out now. To get right in, use the code "RWW" when you sign up here. Company feedback can be sent to the company via the feedback form on their homepage (http://icandy.ricohinnovations.com) or via email (feedback@icandy.ricohinnovations.com).

Project participant Rey Bango points out on the blog Ajaxian today, "considering the churn rate for open source projects, [jQuery's 3rd birthday] is a monumental achievement."

What does jQuery do? Its tag line is "the write less, do more Javascript library" and it's a favorite of many developers working on cutting edge and visually dazzling designs. Want to see some examples? Check out our coverage of the crowd pleasing blog comment system Encouraged Commentary and Drew Douglas's The 20 Most Practical and Creative Uses of jQuery.

If you're a developer and you haven't tried out jQuery yet - you probably should. As Jennifer Stuart wrote when she finally did this Spring, "Why I didn't jump on this bandwagon sooner, I'm not sure, but I am kicking myself for it."

With the addition of the jQuery code to the nonprofit Software Freedom Conservancy, companies using the code are far more free from fear of lawsuits for using it. For details on that development and a number of new technical additions to jQuery, see the announcement on the jQuery blog.

For the marketer, this is an quick way to quickly push a message to wide group of people. Tag 20 friends, and through the friend-of-a-friend (FOAF) network, you could easily reach thousands.

According to AdAge, photos are an ideal vehicle for marketers for three reasons. Sam Lessin writes, "First, people love them and tend to click on them all the time. Second, they get incredible real estate in news feed. Third, any message put into photos has a strange automatic relevance because it is attached to the name of a friend. Finally, there is a huge curiosity factor as to why a friend is tagged in an image."

What's worse is that he concludes the article by encouraging people to use this new method of promotion. Yikes! We absolutely hate this idea and hope that Facebook figures out a way to stop this marketing loophole before news feeds get filled with spam.

Photo courtesy of Facebook