NyanCat is one of several Easter eggs in BrowserQuest
Mozilla has partnered with developers at Little Workshop to launch BrowserQuest, a Zelda-inspired multiplayer roleplaying game built entirely on the open web stack — HTML5, JavaScript and CSS.
While BrowserQuest is a fun game to play, it was written as much to prove a point as to be a game — namely, that web developers no longer need to rely on Flash to create sophisticated online games. Using today’s web standards, game developers can build impressively complex games that work across devices.
To give BrowserQuest a try, just head on over to the site and pick a username. BrowserQuest will work in most modern web browsers including Firefox, Chrome, Safari, Opera (provided you enable WebSockets), Mobile Safari and Firefox for Android.
In an effort to help game developers looking to build more serious HTML5-based games, the code behind BrowserQuest has been released on GitHub.
BrowserQuest’s backend, which handles the real-time multiplayer aspect of the game, is written in JavaScript and runs on Node.js. As you would expect BrowserQuest uses the HTML5 Canvas element to actually render its 16-bit-style world and hooks into the HTML5 audio APIs for sound effects.
BrowserQuest is responsive as well, using @media queries to adapt to the size of your screen.
WebSockets — which are back, after being rewritten to fix some early flaws — handle the chat feature, which allows players to communicate within BrowserQuest. The final element in BrowserQuest’s HTML5 puzzle is localStorage, which saves your progress as you move through the game.
Although designed as much to showcase the power of WebSockets as to be an actual videogame, BrowserQuest is addictive and can easily suck you into its world for an entire morning if you’re not careful. (Not that we’d know.) There are also quite a few Easter eggs hidden away in its depths.
Expert Labs, the non-profit organization behind ThinkUp, a web-based data-liberation and analytics application, is rebooting into a commercial entity.
No need to panic if you use ThinkUp to back up your social network life; the application will remain open source and freely available.
But Expert Labs is going away and ThinkUp is refocusing on a larger goal — liberating your online social life from the clutches of corporate web entities.
In its own words the new ThinkUp wants to build “an information network that connects to today’s social networks, but isn’t centralized and dependent on a company or investors.”
That’s not an entirely new idea. Diaspora and some other projects are trying to do the same thing, but ThinkUp is taking a different approach — it wants to build an app first and focus on the user experience rather than the underlying technology.
In fact ThinkUp already is an app that’s pretty close to what it’s aiming to do. ThinkUp is a web-based app that pulls your data out of social silos like Facebook or Twitter and stores it on your own server. You control your own data, and have a record of your conversations potentially long after Facebook, Twitter and the rest have become mere footnotes in the history of the web.
For more on how ThinkUp works and how you can use it be sure to check out our earlier coverage and then grab the code and try it for yourself.
So what of ThinkUp’s new, loftier goals? Is any attempt to replace Facebook doomed to failure? Of course not. Everything is replaceable, just ask MySpace. And ThinkUp believes its approach is different. “Prior attempts have tried to solve this problem based on the assumption that it is a technical challenge,” says ThinkUp’s Knight News Challenge application. “We believe it to be a social one.” ThinkUp’s focus going forward will be on the social and the interface:
We will draw people in through a compelling media site that encourages participation via our decentralized platform… a peer-to-peer network that powers a great media property with broad appeal — imagine if Digg or Reddit were open, decentralized and powered by a network instead of votes.
If you’re curious to know what that might look like, head on over to the ThinkUp proposal for the Knight News Challenge and click the heart icon to “like” it (incidentally if the Knight New Challenge sounds familiar, that might be because it’s also the birthplace of EveryBlock). In the meantime, work on the ThinkUp app continues with a new release that improves the charts and graphs and paves the way for the coming Foursquare support. Check out the ThinkUp GitHub page for more details.
Microsoft wants in on the drive to speed up the web. The company plans to submit its proposal for a faster internet protocol to the standards body charged with creating HTTP 2.0.
Not coincidentally, that standards body, the Internet Engineering Task Force (IETF), is meeting this week to discuss the future of the venerable Hypertext Transfer Protocol, better known as HTTP. On the agenda is creating HTTP 2.0, a faster, modern approach to internet communication.
One candidate for HTTP 2.0 is Google’s SPDY protocol. Pronounced “speedy,” Google’s proposal would replace the HTTP protocol — the language currently used when your browser talks to a web server. When you request a webpage or a file from a server, chances are your browser sends that request using HTTP. The server answers using HTTP, too. This is why “http” appears at the beginning of most web addresses.
The SPDY protocol handles all the same tasks as HTTP, but SPDY can do it all about 50 percent faster. Chrome and Firefox both support SPDY and several large sites, including Google and Twitter, are already serving pages over SPDY where possible.
Part of the IETF’s agenda this week is to discuss the SPDY proposal, and the possibility of turning it into a standard.
But now Microsoft is submitting another proposal for the IETF to consider.
Microsoft’s new HTTP Speed+Mobility lacks a catchy name, but otherwise appears to cover much of the same territory SPDY has staked out. Though details on exactly what HTTP Speed+Mobility entails are thin, judging by the blog post announcing it, HTTP Speed+Mobility builds on SPDY but also includes improvements drawn from work on the HTML5 WebSockets API. The emphasis is on not just the web and web browsers, but mobile apps.
“We think that apps — not just browsers — should get faster,” writes Microsoft’s Jean Paoli, General Manager of Interoperability Strategy.
To do that, Microsoft’s HTTP Speed+Mobility “starts from both the Google SPDY protocol and the work the industry has done around WebSockets.” What’s unclear from the initial post is exactly where HTTP Speed+Mobility goes from that hybrid starting point.
But clearly Microsoft isn’t opposed to SPDY. “SPDY has done a great job raising awareness of web performance and taking a ‘clean slate’ approach to improving HTTP,” writes Paoli. “The main departures from SPDY are to address the needs of mobile devices and applications.”
SPDY co-inventor Mike Belshe writes on Google+ that he welcomes Microsoft’s efforts and looks forward to “real-world performance metrics and open source implementations so that we can all evaluate them.”
Belshe also notes that Microsoft’s implication that SPDY is not optimized for mobile “is not true.” Belshe says that the available evidence suggests that developers are generally happy using SPDY in mobile apps, “but it could always be better, of course.”
The process of creating a faster HTTP replacement will not mean simply picking any one vendor’s protocol and standardizing it. Hopefully the IETF will take the best ideas from all sides and combine them into a single protocol that can speed up the web. The exact details — and any potential speed gains — from Microsoft’s HTTP Speed+Mobility contribution remain to be seen, but the more input the IETF gets the better HTTP 2.0 will likely be.
A webpage doesn’t have to look the same in every browser. In fact, a webpage shouldn’t look the same in every browser, according to former Yahoo developer and JavaScript guru, Nicolas Zakas.
Zakas, who spent five years as the front-end tech lead for the Yahoo homepage, recently spoke at the March BayJax Meetup group about what he calls Progressive Enhancement 2.0 — offering users the best possible experience given the capabilities of their device.
Not the same experience, mind you, but the best possible experience. That means progressively enhancing sites according to the device’s (browser’s) capabilities.
Progressive enhancement is perhaps best summed up by the famous Mitch Hedburg quip, “an escalator can never break, it can only become stairs.” In other words, if you’re building websites well they never break, even if you look at them in Lynx. The site may not look the same in Lynx as it does in, say Chrome, it may not function as smoothly, but the core content is still there and can still serve as a stairway that gets people where they want to go even when the enhanced ease of the escalator is absent.
More practically, progressive enhancement means starting with the least capable devices — an older phone, Lynx running on Windows 95 — and then adding more sophisticated features based on screen size, bandwidth and so on.
Zakas also takes on the common assumption that a web “page” is analogous to the printed page. In fact Zakas argues the web is more like television, which has a similar separation of content and device. In that analogy old browsers are like black and white TVs. No one expects a black and white TV to play HD content, but everyone would be disappointed if you served black and white content to an HD TV. Hence the need for progressive enhancement.
If you’re well versed in the history of the web the beginning of the video may be a bit slow, but stick with it. Also be sure to watch the questions at the end where Zakas addresses how to progressively enhance more application-like web pages.
The high-resolution retina display iPad has one downside — normal resolution images look worse than on lower resolution displays. On the web that means that text looks just fine, as does any CSS-based art, but photographs look worse, sometimes even when they’re actually high-resolution images.
Pro photographer Duncan Davidson was experimenting with serving high-resolution images to the iPad 3 when he ran up against what seemed to be a limit to the resolution of JPG images in WebKit. Serving small high-resolution images — in the sub-2000px range — works great, but replacing 1000px wide photographs with 2000px wide photos actually looks worse due to downsampling.
The solution (turns out) is to go back to something you probably haven’t used in quite a while — progressive JPGs. It’s a clever solution to a little quirk in Mobile Safari’s resource limitations. Read Davidson’s follow-up post for more details, and be sure to look at the example image if you’ve got a new iPad because more than just a clever solution, this is what the future of images on web will look like.
As Davidson says:
For the first time, I’m looking at a photograph I’ve made on a screen that has the same sort of visceral appeal as a print. Or maybe a transparency laying on a lightbox. Ok, maybe not quite that good, but it’s pretty incredible. In fact, I really shouldn’t be comparing it to a print or a transparency at all. Really, it’s its own very unique experience.
To show off the sample on his site Davidson uses a bit of JavaScript to toggle the high- and low-res images, highlighting the difference.
But how could you go about serving the higher res image to just those screens with high enough resolution and fast enough connections to warrant it?
You can’t.
So what’s a web developer with high-res images to show off supposed to do? Well, right now you’re going to have to decide between all or nothing. Or you can use a hack like one of the less-than-ideal responsive image solutions we’ve covered before.
The high-res future is coming fast and the web needs to evolve just as fast.
In the long run that means the web is going to need a real responsive image solution; something that’s part of HTML itself. An new HTML element like the proposed <picture> tag is one possible solution. The picture element would work much like the video tag, with code that looks something like this:
The browser uses this code to choose which image to load based on the current screen width.
The picture element would solve one part of the larger problem, namely serving the appropriate image to the appropriate screen resolution. But screen size isn’t the only consideration; we also need a way to measure the bandwidth available.
At home on my Wi-Fi connection I’d love to get Davidson’s high-res images on my iPad. When I’m out and about using a 3G connection it would be better to skip that extra overhead in favor of faster page load times.
Ideally browsers would send more information about the user’s environment along with each HTTP request. Think screen size, pixel density and network connection speed. Developers could then use that information to make a better-informed guess about which images it to serve. Unfortunately, it seems unlikely we’ll get such tools standardized and widely supported before the high-res world overtakes the web. With any server-side solution to the bandwidth problem still far off on the horizon, navigator.connection will become even more valuable in the mean time.
Further complicating the problem are two additional factors, data caps on mobile connections and technologies like Apple’s AirPlay. The former means that even if I have a fast LTE connection and a high-resolution screen I still might not want to use my limited data allotment to download high-res images.
AirPlay means I can browse to a site with my phone — which would likely trigger smaller images and videos since it’s a smaller screen — but then project the result on a huge HD TV screen. This is not even a hypothetical problem, you can experience it today with PBS’s iPhone app and AirPlay.
Want to help figure out how the web needs to evolve and what new tools we’re going to need? Keep an eye on the W3C’s Responsive Images community group, join the mailing list and don’t be shy about contributing. Post your experiments on the web and document your findings like Davidson and countless others are already doing.
It’s not going to happen overnight, but eventually the standards bodies and the browser makers are going to start implementing solutions and the more test cases that are out there, the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code