Not long ago, the professional music industry involved a complex but fixed set of players: artists, labels, managers, promoters and the like. Many of these roles have changed, but none have disappeared. They're joined by a new set of participants: tech giants, streaming services, social music startups and, perhaps most crucially, developers.

This weekend, coders and industry representatives gathered in San Francisco for Music Hack Day, a tradition that has spanned continents for the last four years. Like other hack days and hackathons, the event is dedicated to bringing developers together to build new things using the latest technologies and platforms. In this case, the focus is on music, so the toolkit includes everything from mobile hardware and homemade digital instruments to open Web standards and the APIs of services like SoundCloud, Last.fm, Spotify and the Echo Nest.

Noteworthy hacks conjured up in the past have included various software mashups between services, as well as things like invisible, interactive instruments that can be played in the air or on a surface. Some hacks are strictly Web or software-based, while others involve some tinkering with hardware, including LED lights, Nintendo Wii controllers and Kinects.

The most recent Music Hack Day spawned a total of 62 hacks. The list included a music search engine that queries multiple streaming services, as well as a Theramin made from two iPhones. One app succeeded in predicting Sunday's Grammy winners almost as effectively as Billboard did.

Some creations were simpler, such as a Spotify-based clone of the classic MP3 player WinAmp, a mash-up between iTunes and the Echo Nest's recommendation engine and a SoundCloud plugin for Wordpress.

The hacks ranged from the mind-blowing to the simplistic but useful. They dealt with everything from the creation of music to its distribution and promotion.

How Music Hack Day Helps the Music Industry Evolve

Music Hack Day was started in 2008 and hasn't stopped growing since. In the tradition of other hacking events, SoundCloud VP of Business Development David Haynes teamed up with experienced hack day organizer James Darling to create a music-specific event. The proliferation of APIs from various music-related platforms plus some of the other disruption going on in the music industry made the space ripe for some creative hacking.

"Weren't sure what to expect from it at first," said SoundCloud cofounder and CTO Eric Wahlforss. "It got off to such a good start that's now become sort of a tradition for the last few years. Music Hack Day is a big part of our culture."

For startups like SoundCloud, events like Music Hack Day yield creations that could one day find themselves integrated with the company's core product. The vast majority, however, will not. And that's okay. The event's value is of a much deeper nature, in that it fosters a developer community around music and brings a wide range of players into the same, from independent coders to music industry representatives.

A side effect of this type of collaboration is that the entire industry is creeping forward. A few years ago, Wahlforss told us, some record labels had no idea what an API was or how it was relevant to their business. Today, EMI has an API of their own. They, along with Universal Music Group, participate in Music Hack Day and are curious about much of the fruit it bears.

"If you speak to the labels today, they're all about API's and mashability of their content," Wahlforss said. "They're very on board with this trend, which is very exciting to see."

For SoundCloud, this spirit of hacking is something that plays a prominent role in the culture of the company and its growing team of developers. Modeled after Google's "20% time," the company encourages employees to use what it calls Hacker Time to experiment and build new things that may or may have any direct bearing on the official product strategy for SoundCloud.

The company also recently hired its first developer evangelist and is silently preparing a major announcement about its platform.

Pushing Music into the Future

SoundCloud isn't the only company pushing the boundaries of what's possible in online music. Innovation is all over the place, from Spotify's new third party app platform to the long and growing list of apps powered by the APIs from services like The Echo Nest, Last.fm, Bandcamp and several dozen others.

The open architecture of the Web, the proliferation of APIs and hacker culture have already made a notable mark on how people create, discover and share music, yet all of this is still very much in its earliest stages.

Twenty years from now, things will look even more different. The industry and ecosystem will move forward together, probably with a few players becoming obsolete along the way. Artists and sound engineers may lead the creative charge, but if what emerges looks and works radically different from what we have today, we'll have developers to thank as well.

Music Hack Day Photo by Thomas Bonte

Given that there is only one week left until Valentine's Day, we wanted to make shopping for the special developer in your life a little easier. Here is a list of gift ideas for the developer love (or "like") in your life, crowdsourced from our community team.

Star Wars: Episode 1 movie tickets: Who wouldn't want to watch a classic - The Phantom Menace - in 3D!

Magic Wand programmable TV remote: This gadget is as entertaining as it is useful and learns from your existing remote control.

Steve Jobs book: If you have an urge to give a "real" book, this is the one.

Chrome cufflinks: These Chrome logo cufflinks are for the guys in your life, but don't shy away from grabbing an Android T-shirt.

JayBird Bluetooth Earbuds: Bluetooth Stereo Headphones make working and commuting even more enjoyable.

Hard Candy Stylus and Pen: If your valentine isn't a painter, opt for the pen that makes writing on an iPad (and paper) possible.

Jawbone JAMBOX: This buletooth speaker boasting hi-fi audio definitely says "love."

Das Keyboard Model S Ultimate Silent Keyboard: Give the gift of incognito typing. It's silent and doesn't have numbers or letters visible (so you can still work while on the phone with your loved one).

Dave Messinger, chief architect and evangelist for CloudSpokes at Appirio.

Robot photo courtesy of Shutterstock.

Still, a report released by IHS in the wake of Microsoft's earnings announcement last week is worth a closer look.

"Combined with Nokia's efforts to drive the development of the Windows Phone ecosystem, the Lumia 900 and its successors will help Microsoft to reclaim its No. 2 ranking in smartphone operating system market share by 2015." Lam wrote.

To do so, Microsoft would need to jump from its current market share of 2% to 16.7% in four years. Windows Phone has gotten loads of praise from reviewers and tech writers, but the company does face some hurdles, including a lack of apps when compared to the number of apps available for iPhone and Android.

Based on comments after the release of its earnings Thursday (which topped Wall Street analysts' estimates), Microsoft seems to be positioning itself to make Windows Phone more developer friendly. To date, developers have been far more interested in working on applications for iOS or on Web-based platforms.

"I would say one of the things [we] talked about at CES last week was just how important it is for us to work on and with developers to create a really vibrant developer ecosystem," said Bill Koefoed, Microsoft's general manager of investor relations, during the call with analysts.

In the shorter term, Congress should release legislative data to allow third-party programmers to develop apps and better interfaces, according to recommendations made in a report released Tuesday about the first-ever Congressional Hackathon.

Lawmakers want desktop and mobile applications that would better help voters and constituents use Congressional data. They said a system much like the models being used by public transit systems in many systems where schedule data is made available to programmers could keep costs low.

"Increased access, increased connection with our constituents, transparency and openness are not partisan issues," House Majority Leader Eric Cantor, R-Va., who organized the event with House Minority Whip Steny Hoyer, D-Md., said in remarks published in the report. "There are a lot of hearings, discussions, deliberations - not only in the chambers of the Capitol, but in the committee rooms and the subcommittee rooms - that frankly a lot of people may be interested in."

Other proposals in the report included:

• Easier ways to view what portions of a bill a lawmaker wrote or edited.
• Real-time voting updates for Senators and Representatives.
• The use of a Storify-like system to keep updates of ongoing issues.
• Better tracking of casework filed with Congressional offices.
• Social media press conferences.

Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got where it is now and how it will iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?

Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!

What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:

Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.

HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan.

Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.

Changing Mobile Standards Through The Past Five Years

We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.

Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users.

So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5.

So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?

[Crowd] - The iPhone.

The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?

[Crowd] - The Platform.

Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API.

How about 2008? What was the big thing that happened in 2008?

[Crowd] - Ummm ... Android?

I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now.

In 2009, what changed in 2009?

[Crowd] Ummm ... Android?

Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad. So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.

Next page: Fetterman describes how Facebook reconciled M.Sites and Touch

How To Not Write The Same Functionality Four Times

So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web.

That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.

So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.

Progressive Enhancement

Here is what we did.

The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site.

So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement.

So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature.

So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of course, everyone wants and iPhone feature. They want their stuff to look like and iPhone, to perform like an iPhone, to feel like an iPhone, all of that. So, we could write it in Objective-C, which we had to do, or we could think about this. Right, so, what about the Facebook news feed is really iPhone-y? You have the top, you have the fixed header, you have it to render directly from cache, all that great stuff. But really, if you look at the content of the publication, that looks a whole lot like a m.site news feed. There is not really that much that is different, there is nothing that special about any particular stack. So, that means that you have to write it three times to do exactly the same shit.

Crazier Than You Guys Can Imagine

So, what if we put the actual browser inside the app? That is the crazy idea. The way we did this was even crazier than you guys might imagine. So, there are a few phones, what browser is going to be able to work for all these phones? Well, three of them have pretty good WebKit implementations. So, we thought, what if we put a Webkit enabled site inside the app and just straight up make that thing work? Just, forget it, we will figure out how to make that thing work.

So, this is actually pretty crazy. This isn't just building Javascript that runs on the client and uses the back end as a data portal. We are actually straight up injecting the site inside these apps. Not quite as simple as getting a UI Web view or whatever. You have to have some interactivity between that Web view and the container but what if we could just straight up use the site? It is almost the same thing, right? So, this is what we did and it is kind of insane.

So, I want to tell you what we learned from this. Of course, unifying the site into the content containers is difficult and something that we would have to overcome but, betting on the browser is just kind of something that we do at Facebook. It is what we are good at and it is our ultimate opportunity to move fast and we are betting hard on the Web because that is what got us here (f8) today. So, we basically want to put the browser inside the Facebook for iPhone app.

Next page: How Facebook moves fast with browser tech and iterates daily

Iterate Daily

So, what doe this get us? It means that you can ship daily. You do not have to wait for an app store approval, which sucks, and you don't have to wait for every user to download this version on the binary which has to be shipped over into their phone. That sucks. You can ship every day. You can break it every day, but you can ship every day.

You can ship it in easy language too. Your Web development team, you iPhone team and your Android team don't have to be separate. They are all the same people, they are all solving the same problem. And you can ship once instead of having to ship four times.

So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebok in the iPhone. So, you build much smaller native goop instead of having to build over and over again.

The Answer: Wrap Facebook Mobile Inside the Native App

So, how does this technically work? Essentially the user hits the news feed icon on their iPhone. If this thing is enabled for this FaceWeb technology, it won't map to a native Web controller, it will instead map to some end point on our server that literally says serves up m.facebook.com/home.php. It can't just jam that thing in there. It can't just have the Web view. You actually have to know how it is going to be interacting with the Objective-C. So, you have to send back a JS skeleton which specifies the "platform extraction calls layer" required for that frame. Then you make another trip and load the home.php and the Javascript.

It is a bit of extra work and that does affect some things. But, what that means is that we can write a basic m.facebook.com site and use Javascript to make it work on great phones and use this abstraction layer to interpret Javascript when applicable to do native things like say open the camera for something like the iPhone application.

So, what kinds of things have to go across this bridge? Obvious things like sensors and data. If you want to get your GPS, your accelerometer or orientation lock or some of these things, some are available in HTML5 but a lot of them aren't. So, you have to be able to make some of these sensor-esque answer queries. Depending on the display and how aggressive you want to be, you have to be able to render things look like iPhone. Look like Android. And, you can't do those things just with the browser. You could in theory do this with JS but to look exactly the same you are going to have to use a native call. And additionally, there are elements to Facebook for iPhone that we don't really want to move to HTML. For instance, the camera flow. You open up the camera, you take a picture, you put it in your album or you select something from your gallery and caption it and upload it. That is a lot to do in a browser but it is easy to do in native. So, if you want to deep dive into any existing native flows, that is a bridge we are going to have to cross as well.

Next page: The sticky points and problems with designing once and running everywhere

Sticky Points: Web v. Native Design and Design

PhoneGap has already solved this first problem actually pretty well across even more than just the iPhone. The common problems that you will run into if you do this is; one -- objection, it doesn't look native. Second one is that it is not going to feel native and third is that it isn't fast enough. Here is what we found for each of these things.

The initial mandate was, hey, you guys want to do this thing in HTML, fine, I don't want to be able to tell the difference between Objective-C rendered news feed and HTML rendered news feed. This actually didn't end up being a big problem in terms of visuals. The Web and the app actually work pretty well together. When we shipped this to users there wasn't any complaint except for one that I thought was pretty funny.

There was an iPad "app" for Facebook that was friendly for Facebook, It just simply wrapped the m.site. Some users said, hey, Facebook is copying the app that wraps its m.site as part of its Facebook for iPhone application. Which we were because we were actually just using our m.site and that was great. So, the fact that it doesn't look native, we don't actually have a big problem with that one.

Still, there are some things that you have to look out for. Position fix and overflow scroll were obviously a big problem. Android 2.1 and below, no chance. (Android) 2.2, it is starting to work and iOS 5, thank god, has promised to implement all this stuff. So, you guys are in a better position now to start down this road than you would have been 10 months ago. CSS regradients are a problem, images are a problem and [there are a couple of more gotchas].

Web v. Native Feel: Scrolling

Another problem is that it doesn't feel native and almost always this means scrolling. It doesn't really mean, hey, I want to swipe to delete. That is like, pfft, who cares? Almost always it is going to be something about interactivity and scrolling. Something that the native code does really well by using the GPU and like pipelining all that shit but it is something that it really hard to do in HTML. So, when people say that it doesn't feel native, they are going to be talking about scrolling.

Sometimes you do have implement scrolling. iScroll works pretty well, Hewitts is working on a library that is pretty good. So, you kind of have to defer to a good JS scrolling library. And, make sure you do things like resize your images because was once the responsibility of the GPU is now the responsibility of the browser. And, there are all these little things that just aren't documented, like the keyboard showing up and not closing on Android and iPhone. There are just a lot of little things that are baked into the system that are getting fixed.

The Issue Of Speed

The final one and this is the real bad one is that it just isn't fast enough. If you see a slowdown in your Facebook for iPhone application, it means that we are working through just how to make an HTML-based application work for Facebook for iPhone and it has been pretty hard.

So, tactic one is obviously pre-cache the hell out of this thing. If you render a news feed, start and going to get the content for all of those stories because when the user hits that, you want to have the content ready for them. Cache your Web views. If that doesn't work, the best thing that you can do is to just trick your users. At least have content appear to be ready. Fill out the rendered skeleton and then put in that cached content and then beneath, go get your new content. At least users will feel that there is something there because that is usually what their initial response is. A white screen is just not going to cut it.

So, gotchas in PERF means that you are going to use a lot of JS. You are no longer just loading data, you are loading pre-rendered markup, which is a lot more expensive. And things like HTTP cache and the app cache, they say they work within UI Web views but often they don't. So, you have to be really careful about promises that are made here.

Taking The Approach Everywhere

But, this worked well enough that we said we are going to put the Android app on this party train too. So, we were actually able to write something like the m.site news feed once. Any time you change a news feed story or add a news feed story or add commenting and Liking or whatever, that is going to show up on low-end m.site, high-end m.site, Facebook for iPhone and Facebook for Android the very next day, or whenever we push, which is actually pretty awesome.

So, we did do this. Now we have elements of the Facebook experience, the browser running inside everything. Especially the most volatile stuff, the stuff that relies least on a certain type of display, the stuff that is going to be evolving and changing so much, like the news feed or your profile timeline, we are doing this straight in HTML. That is where the maximum benefit is.

Next Page: How HTML5 Is Leading Facebook In A New Direction

How It Has Evolved: Heading to HTML5

So, what is the history of this? So, for iOS 3.4 and 3.5 we actually did this. Your news feed and your profile feed are actually being sourced from the m.site. So, that means if the m.site changes and adds a feature, you guys get it. If the m.site is broken, it breaks everything. There are positives and negatives there. To be launched in iOS 4.0, requests, notifications and search, this list-style content that doesn't require very specific native access, that is going to be based on FaceWeb as well. Android 1.6 and 1.7 follow the same suit. The feedback and the design have been pretty great but the bugs have been pretty crappy though. Because when you version your Javascript and things go wrong, you are tying your future to the actual Web working perfectly all the time which is something that we obviously move fast on very often.

So, the mission is to operate from one code base and adapt to all the browsers in the world. This sounds like something that Facebook would say, this is actually part of the HTML5 battle flag.

HTML5 is probably the way that we should have done it. This is the way we get to do it now because HTML5 has changed so much under our feet. The initial attempt at building a hybrid application, there were certain things in HTML5 that weren't ready yet and we said forget it, we are going to keep moving forward. The initial attempt to defer certain things to native rendering and native handling that really could be better handled by something like HTML5 and with in-browser technology - device access, good native frameworks and application and display code.

What has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?

Device Access

So, device access. Simple things like getting things that are privileged inside the device. Geo-location, network connectivity, obviously very big for caching, things like your camera and your contacts, what has changed? Well, geo-location has actually been pretty good for a while. This could certainly be HTML5 and that is what we use inside out m.facebook.com based Places and Deals stuff. Network connectivity is emerging and that is getting to the point where you can rely on newer browsers to do it via HTML5. Camera and contacts, because those are so wildly different, a lot of those things are still specified. But, if you want to look at a general list and start by asking the system for a response and getting an answer back, PhoneGap.com actually has a lot of this stuff and they have been able to this poly-fill to make a lot of this work. So, this is the easiest problem but it is the furthest along towards getting solved, especially since we have started working on this hybrid application.

History

There are certain development frameworks that are native. Being able to manage your history, it's weird. Because your history inside a native stack is very different from a browser history. Browsers are very idiosyncratic about how they handle history and it is a very different model. History management, client-side storage is obviously the big one and threading. With threading, if you guys have developed in iOS, you know there are certain things that you have to respect. That is true in Javascript as well. So, you need a good way to figure out how to get other threads to do your work and get it in a cross-platform way.

HTML5 is emerging standards to make all of this go away as well. History management, there is some good stuff in HTML5 coming. IndexDB and client-side storage is getting much better as well. Things like WebWorkers, if we did these things again, we would be able to do it in HTML5.

Can An App Be Built Now Using Only Web Technology?

Finally, I think the important thing is, could you build your app building straight up Web technologies? The actual Web technologies they are using, you are using. Scrolling, refresh, fast stuff, these are things that we had to defer to a native handler in an awkward way. But, scrolling, thank you to Apple and iOS 5 for promising that they are going to make scrolling, position fixed overflow scroll, this might be the problem of the past. Fixed position headers and good scrolling is a hallmark of what people have come to think of as a native application but it is a problem that can be solved by good JS now thanks to these new frameworks.

I think the most important takeaway is that the JS rendering engines have just gotten so much better in the past year and a half. V8 and Nitro have shown that you can build full-fledged, client-side JS applications instead of using Objective-C or Android Java and they will run and users will love them. Things like Netflix have done this very productively already.

So, the emergence and the investment of big browser manufacturers that are making really, really good JS stuff, which is finally paying off. And if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have.

Move Things, Break Things, Fix Things Fast

So, we have been following what was available to us along the road for us since 2006 in Facebook mobile. If the best that we can do is XHTML, fine. If we have a really good browser that uses JS and CSS fine. If we can build and iPhone app and an Android app, that is great. But, what is changing beneath us now is actually the emergence of this HTML5 standards and browsers that implement these standards. Especially around device access and the ability to write apps entirely in Javascript. We have seen a lot of benefit to writing something in HTML. All of our developers are good at HTML. Only a few of them are really good at Objective-C and Android. We are able to make our Web developers the same as our client-side developers in some respects.

Being able to write it once today and ship it tomorrow? That is something that Facebook is really good at and that we love doing and that is at the center of being able to move fast. Move fast has an implicit third clause - move fast, break things, and fix things fast. That is very difficult to do if you have already shipped your binary to Apple or Android and they have to download another version of it.

In the mobile realm, the debate rages on: Web or Native? The difference between the two is beginning to blur as HTML5 standards evolve. We examine what happened in HTML5 in this year in our third installment of 2011's top trends. Check out the rest of the series, starting with John Paul Titlow's music trends and Alicia Eler's mobile commerce trends.

Yesterday, we named appMobi as our ReadWriteWeb Most Promising Company of 2012. As a startup, the company is doing interesting work on the fundamental goal of making HTML5 easy to use and ubiquitous with an emphasis on mobile first development. appMobi is carrying the torch for mobile first but it is a trend that is fast sweeping the development community as smartphones and tablet use explodes with data usage projected to increase by orders of magnitude in the next several years.

Fundamentally, the mobile first initiative revolves around the simple yet loaded questions of Webs apps versus Native apps.

This year we saw some large companies go to mobile first initiatives in regards to HTML5 design. The Financial Times pulled its native app iPad from the Apple App Store over its subscription and in-app revenue policies and has done very well with its Web app, designed with HTML5 with mobile devices in mind. Game developers, as discussed below, are leading the charge in creating dynamic mobile Web apps.

The trend of developing for the mobile Web first will continue into the new year with the explosion of smart devices coming to dominate computing, especially on the consumer/consumption side of the equation. To a certain extent, users do not really care what an app is written in, as long as it works like they expect it to. With some of the evolutions of HTML5 described below, the line of capabilities between Web apps and native apps is starting to blur.

2. Game Developers Take The Lead

We noted multiple times throughout the year that some of our favorite developers in the mobile realm were of the gaming variety. To a certain extent, game developers have the most to benefit from taking on HTML5 as a platform to avoid the 30% that Apple scrapes from paid games in the App Store and in-app purchases. Games are some of the hottest selling apps in all of mobile and a one reason that platforms like Android and Apple look so attractive to people looking to buy a smartphone or tablet. It is not just about reading email or making phone calls and texts. If that was so, Research In Motion would be doing a lot better with BlackBerry than it currently is.

A lot of game developers are being pushed along by the likes of Facebook and Zynga. The future of the Facebook app ecosystem is based on HTML5. Game developers, such as those working at MocoSpace or Moblyng are hard at work creating HTML5 versions of their publication library. As Stewart Putney, CEO of Moblyng, told me in August, "do you know how hard it is to make a Texas Hold'em game in HTML5?"

Games are not all about Web apps though. Through the magic of PhoneGap and HTML5 development through appMobi's XDK, Web app mobile games can be wrapped for easy integration into the native app stores. The approach is very similar to what Facebook does with its own mobile app. Based of the Web and browser but wrapped for native functionality.

We wrote about how game developers have taken the mantel of pushing the bounds of technology from the porn industry and it is true. Porn, an industry that once was the bellwether for technological adoption, has now fallen behind the times. We expect this trend to continue in the next couple of years as HTML5 matures as a platform.

3. Responsive Design & Handling Screen Sizes

There are fundamental advancements that need to happen before HTML5 truly changes the way that development is handled across platforms. One big step was taken this year with the evolution of what is called "responsive design." Essentially, responsive design will let content adapt to any screen size that it is on. The brightest example of responsive design this year was when the Boston Globe released BostonGlobe.com, its mobile-first Web application designed to work on any screen size, anywhere. We interviewed Filament Group, the developers behind the Globe's responsive design, in September and learned that responsive design is not actually an easy to figure out. Some basic concepts had to be built from scratch, such as the notion of RespondJS that handles media queries. Learning what to do with photos and ads from third-party sources also proved to be problematic.

"I think some facets of this could have been done in the past. I mean, HTML5 has a lot more APIs available for targeting features. Like, being able to check for touch support is technically part of HTML5 even though it is not HTML5 markup," Filament developer Mat Marquis said at the time. "So, that definitely allows us to do all of that conditional loading and such. In terms of the markup itself, we are doing a lot of HTML5 with additional semantic meaning, it could have been done in HTML4, just not meaningfully in terms of the markup."

Dealing with responsive design has a lot to do with understanding how content is going to react to a particular screen size. ZURB, a Silicon Valley design company, is also working on responsive design implementations. Responsive design is based off the concept of "fluid" design and is complete shift in how content has been handled on websites and mobile devices for much of the last 16 years or so. It is still a work in progress but HTML5 is finally making it possible.

Next page: Tools and standards emerge ...

4. Device Access

One of the biggest barriers of erasing the line between Web apps and native apps is the ability for browser-based applications to have access to some of the most fundamental aspects of mobile devices, like the camera, contacts lists, calendar, accelerometer etc. This is another area where appMobi is a leader in the HTML5 space, especially after it open-sourced all of its APIs the day after Thanksgiving. Mozilla has also been working hard on creating device access through the Fennec mobile browser project.

To mobile developers, device access is the most exciting innovation within the HTML5 set. It means that true Web apps can come to mobile, without the need of doing any PhoneGap-style wrapping. Game developers will be pleased because aspects previously locked to them, such as the accelerometer or the phone's read state, can be integrated into games. This opens a world of possibilities, such as better cloud integration (which can help with in-app purchases, push notifications etc.) and enhanced game play. Depending on the platform, apps are fundamentally built off Javascript, CSS3, HTML and other programming languages and given functionality through APIs, SDKs, cloud functionality and dozens of other moving parts. HTML5 did not allow for many of those functions but until recently. That is beginning to change and will be a development to watch in 2012.

5. Offline Caching

Hold, wait a minute here. You mean that my app can work even when I am not connected to the Internet? Well, I'll be a goat in a canoe on the River Thames. The concept of offline caching is fairly new and still one of the trickier aspects of HTML5 development for Web apps to master. This year, the prime example of offline caching to be deployed on a grand scale is the Kindle Cloud Reader, a Web app from Amazon that is supposed to give the Kindle sync functionality through the browser and remember everything in in a users Kindle library. It works in Firefox 6+, Chrome 11+, Safari 5+ and iOS 4+. There is so much that can be done with offline caching but the prime benefits, combined with device access, are to make Web apps work when not actually connected to the Web. That possibility is what many pundits think will eventually be the doom of native apps because overall deployment of Web apps will be frictionless, of every platform and no platform.

Mozilla is also working on offline caching with Fennec. Actually, name any particular trend in HTML5 development, and Mozilla has a hand in there somewhere. Check out Mozilla's mobile roadmap that we wrote about a few weeks ago to fully understand how the open-source organization plans on integrating HTML5 into its smart devices platform.

6. Maturation Of Developer Tools

In August we wrote that, "HTML5 Can Get the Job, But Can HTML5 Do the Job," a riff on a Pinch/Zoom blog post on the anatomy of an HTML5 Web app. In that post, Brian Fling said this about developers planning on HTML5:

• Allow for time. Assume it will take far longer than any other project you've previously done.
• Budget appropriately. This is not a website, and it will cost you a lot more.
• Make sure you have the right talent in-house. If these problems are hard for the most seasoned experts in the world that do it every day, assume they will be hard for your team, too.
• The "tools" are non-existent. More often than not, you will have to build your own tools.
• Consider all your options. A dogmatic approach to technology is a surefire way to spend money unnecessarily. There are no right or wrong answers in mobile. Keep an open mind and focus on what your customers need.

The fourth bullet point on tools is perhaps the most pertinent of all because it is the aspect that has changed the most from August until now. In addition to the tools that appMobi provides, framework and IDE providers Sencha and Appcelerator have gotten into the HTML5 development game, providing new ways for developers to create apps with the set of standards. At this point those tools are not yet as power or simple as some of the native Android and iOS developer frameworks and tools but in the next 12 months they will continue to evolve. Frameworks, IDEs, emulators, bug detectors and other basic functions that developers have come to rely on will roll out for HTML5 development and become more ingrained into the ecosystem. When developer lives' are easier, the more productive they can be and the more Web apps we will start seeing flood the market.

Conclusion

Other functions of HTML5, such as forms and new standards, continue to evolve. Fairly soon, HTML5 will probably be just HTML as the community and the W3C work to standardize the set. The leaders in HTML5 development will be companies like Sencha, Adobe, Appcelerator, appMobi along with the titans of the industry in Facebook, Amazon and Google.

It is an exciting time to be a developer whether you are working on new forms of video rendering such as Brightcove or trying to figure out the best implementations of HTML5 for audio the way SoundCloud is. From the desktop to the mobile Web, HTML5 is making the Web's one true killer app, the browser, the centerpiece of innovation.

Applications built with tools like Alpha Five will work the same on all your devices. The forms, dialogs and security features, as well as the calendars, video players and image galleries, are backed on the server side. Users won't have to worry about which device to use, and developers won't have to reinvent the wheel for each one.

Alpha Five provides developers with reusable components, from text forms to animations to location data mapping, that they can use without worrying about compatibility. The components are supported by its Codeless Ajax technology from the server side, providing a persistent connection so the user doesn't even have to know about it.

Alpha Software's goal is to reduce the burden on software development teams, so they no longer have to make difficult choices about which platforms to support.

"Mobile and tablet computing are great for users, but they've added cost, complexity, and uncertainty for companies," says Richard Rabins, co-chairman of Alpha Software. "IT has been forced to choose between investing in apps for the desktop or laptop, the web, mobile, and new form factors such as tablets. Development teams are burning out."

With a development tool like Alpha Five, companies can build once and deploy everywhere. Check out this demo of how the Alpha Five image gallery component works across platforms:

The Business of Platforms

Incompatibility across platforms is troubling for developers and users alike. Since the devices and operating systems we use are built by competing companies, it's inevitable, though annoying, that they won't always work together. But it's too easy to assume that the reason major platforms are incompatible with each other is purely due to competition. Sometimes there are good reasons for platforms to drop support for proprietary technologies.

Why Doesn't The iPad Have Flash, Anyway?

For example, Apple's portable devices don't support Adobe Flash, which powers lots of Web content and applications. That causes a headache for Flash developers and users who want to access Flash content. But Apple has made its reasons clear for not supporting Flash. It's proprietary, whereas HTML5 - which Alpha Five uses - is standard. Plus, it performs slowly on mobile devices and drains the battery.

There are selfish reasons for Apple not to support Flash, too - supporting Flash games on the Web would compete with the App Store - but performance and battery life are important for all users, and Apple wants to protect that part of the experience.

For a mixture of good and selfish reasons, platforms are always going to push and pull on each other with the technologies they support. But projects like Alpha Five that can bridge platform divides using common technologies help keep developers sane and users happy.

"Every single user who is on Facebook should have some relationship with some developer that creates distribution," said Lee.

In other words, developers should be focused on creating apps that help people know themselves better, which might have a profound effect on how apps are traditionally developed. In a way, apps are the new brands and developers are the new brand managers.

Lee explained how apps should be talking about "the intention of what the user wants to share." This is completely about the media, like music shared in Spotify, where people find meaning in their lives.

"You are an extension of something they want to already share, but they just want to do it in a more structured and interesting way," said Lee.

Li said that he didn't think it was an "ilegitimate goal" to make sure that all 800 million people on the social network will have a fundamentally human and "healthy" relationship with the work being done by developers.

The app itself is not very useful yet, but it's a start. "Some categories are not meaningful," Mansour says, "and I am trying to optimize it further which is quite difficult." But Mansour's insights after developing for the API are instructive. On the Stream+ website, he says that the API was "very easy" to learn and use, but that it suffers from "extreme slowness" in practice.

"So far, the API looks solid," Mansour says, noting that he built Stream+ without prior knowledge of AppEngine or OAuth. "Props to the AppEngine team, you guys really did something so easy. ... I just used the examples online given by the Google+ team and hacked away with the API. I am really impressed."

Mansour is a committer to Chromium and a Google Qualified Developer for Chrome Extensions, and his experience developing for the Google Plus API seems to parallel that of using the social network. It may not be capable of much yet, but it delivers simply and effectively on the features that have been released.

He did note, however, that the API is not very responsive. "It takes 30+ seconds to query the public stream (not many posts) and another 5+ seconds to classify them in memory!", Mansour says.

Proof of Concept

As far as the Stream+ app itself, I'd have to agree with Mansour. "Some categories are not meaningful." In fact, not very many of them are. The app does take quite a long time to load, and when it does, it presents an overwhelming list of past threads and an inscrutable list of topics. Examples of weird topics in my list are "Think this New," "Hear," "Long Time" and "Little," but others, like "Social Media" and "Web News," make more sense.

But keep in mind that this is not Mansour's forté as a developer. In fact, Stream+ at least tries to solve a crucial problem with Google Plus: organizing the stream. The Google Plus stream is currently this avalanche of multimedia madness, and drilling down by circles doesn't really help make sense of it. At least for public posts, an application like Stream+ could impose some topical order on it. (Side note: Where is Sparks? Isn't this what Sparks is supposed to do?)

Mansour has opened the future of Stream+ to discussion on Google Plus, noting that "it will always remain free," and that he hopes to open-source the technology.

Just The Beginning

Mansour has at least proven that something can be built on the Google Plus API as it exists right now. Even if the app isn't very helpful for end users, Mansour found the process of developing for Plus relatively easy. The long response time is a shame, but the Google Plus team is working to make this API easy and useful.

When Google announced last week that it was opening the first part of the Google Plus API, the public response was lukewarm. The release only gave developers access to public data; any info that is less than totally public, including circles, is still unavailable. Management of circles is one of the most painful parts of using Google Plus, and developers would love to get their hands on it. But alas, that will have to wait for a future release.

What kinds of Google Plus apps do you want to see? Let us know in the comments.

The time has come for outside applications built on the Google Plus platform. With this release, Google has laid out its policies for independent developers, which it summarizes with three simple principles: "put the user first, be transparent, and respect user data." And with that, off to the races.

The Plus team also makes an effort to adhere to open Web standards. "We love the way the programmable web has evolved," the post says, "so we're using existing standards and best practices wherever we can." This is a refreshing message, considering the attention Google has attracted recently for seeming to work against Web-standard technologies and practices.

Since the social network launched in June and put out a call for developers, this API has been hotly anticipated. Our ReadWriteHack poll found that a commanding majority of our developer readers were interested in playing with it. This summer, we laid out some ground rules about what Google would have to do to win developers' hearts with this API, and it looks good so far, though devs only have access to public data at this point.

More Google Plus API news is sure to come following this first announcement, so stay tuned.

What kinds of apps would you like to see built on top of Google Plus? Discuss in the comments.

Dorsey goes on to express enthusiasm for the future of Twitter, especially concerning the upcoming deep integration into iOS 5. "Very soon, anywhere there's an iPhone or an iPad, you'll always find Twitter." Yet, Twitter's relationship with its developer ecosystem has not always been rosy. Is this an olive branch from the service as it prepares to grow?

Not A Good Year For Twitter Developers

This has not been a good year if you are a developer working on a third-party Twitter client (unless you are TweetDeck and just got purchased by Twitter, of course). In March, Twitter more or less said, "Do not try and compete with us or our native clients." TweetDeck was too big for Twitter to push over, so it bought it rather than let it fall into the hands of UberMedia.

Come June, at Apple's World Wide Developers' Conference, it was revealed that Twitter would be ingrained into nearly everything that happens in iOS 5. The deal was probably in the works for a couple of months. With iPhone 5 almost ready to be released, Dorsey and the Twitter team have probably come to realize that it needs to re-enlist its developer community that it had once shunned to help integrate the service into Apple devices. It is a monumental undertaking that Twitter alone is likely not capable of handling.

Hence, the call for help.

"If you're an iOS developer, you can add Twitter to your application to personalize the experience for your users, giving them easier and better ways to login, enrich their experience, share thoughts and content and help boost your distribution," Dorsey wrote. "I believe that our relationships with consumers and developers are a primary measure of our success. Thank you for helping millions of people around the world get more from Twitter."

iOS 5 Release Around The Corner

Apple released iOS 5 beta 7 today, which is likely the last or the next-to-last beta version of the OS to come out before the iPhone 5 (and possibly another cheaper version) come out. A quick note from a developer who has been running the beta versions said, "very few changes, likely near the end of the beta" in regards to what is been updated or fixed with the latest release. So, Twitter has a couple weeks left, at most, before the new wave of iOS 5 applications come out. And here is Jack, waving a white flag and offering whatever support Twitter can muster.

"Our ongoing commitment is to give you the structure, tools, resources, and support you need to build your businesses as you leverage the power of Twitter," Dorsey wrote.

That is a far cry from what came out of Twitter in March.

""We ask all developers in the Twitter ecosystem to abide by a simple set of rules that are in the interests of our users, as well as the health and vitality of the platform as a whole," said a Twitter spokesperson. "We often take actions to enforce these rules; in fact, on an average day we turn off more than one hundred services that violate our API rules of the road. This keeps the ecosystem fair for everyone."

You can join the Twitter developer conversation in the services discussion group here.

So, developers, what do you want to see from Twitter? How can Dorsey and company woo you back into their good graces?

The new coding options could spread Spotify far and wide in the application ecosystem. It is the mobile equivalent of being able to put a radio widget into a website. The service, called libspotify, is available for Spotify Premium users and developers starting today.

Spotify is providing libspotify as a C API and can be used for accessing data about artists, albums, tracks and playlists. See the libspotify documentation and FAQ for further details about implementation. Developers can use an Objective C Wrapper to help integrate libspotify into their applications and make API calls.

Developer note from Spotify: "The example code distributed with libspotify uses the MIT license. All documentation, libspotify itself, and the associated C header file are distributed under the libspotify Terms of Use."

If developers want to use libspotify for commercial purposes, they will need to contact the service's partnership program. As a music service that licenses music from the major music labels, distribution of music (especially for the purpose of monetary gain) is a dicey issue. Make sure to contact Spotify to make sure your application is in compliance with its rules and regulations.

Facebook responded within hours with very public updates to its Games platform. Meanwhile, Twitter is adding features fast and bulking up its developer team with high profile hires of trailblazers who've led developer programs at Facebook, Google and Yahoo in the past. What can Google Plus do to compete for the hearts and focus of platform developers? We asked on Google Plus and the responses we got were quite clear.

Question: Google Plus will be launching its app developer platform soon. What does it need to do to win developers' energy away from Twitter & Facebook? What could those platforms do to maintain the developer engagement they have in the face of that challenge? Please share your thoughts, they will be much appreciated. Feel free to message me privately if you have thoughts you don't want to share publicly.

So far I've received about 50 responses. I would add that these responses come within the context of Facebook being awash in low-quality apps, heavily throttled but still often annoying to users and Twitter angering its developers time and again with changes to its API and public calls to stop building certain popular types of apps (like user clients) that Twitter now wants to own. That said, there's still a whole lot of developer engagement with both those platforms.

More competition should equal more and better developer work, which means more fun and utility for users. This should be good. Google's Joseph Smarr told me on the night Plus launched that the team is "eager to make the social graph a 'two-way street' where you can use your circles to quickly get up-and-running on a new site, but also make new friends on that site and add them to your circles."

How about a little Android integration? The possibilities are many.

Most of the responses to the question above that we've seen so far fall under the following four general concepts.

1. Clear API documentation that is updated when exceptions are responded to. "Don't make changes that remove features without notice, clear [and lasting documentation] and a replacement at the same time," said digital marketer Ted Sindzinski, for example.
2. Good community management. "A nice 'community' in the #socbiz sense of the word - e.g. https://dev.twitter.com/ or @sapmentors," said management consultant Mark Bean.
3. A light hand on banning apps. As Plus user Kevin K put it, "Not having useless restrictions and not banning applications. Given the handling of the pseudonym debacle, I don't know if they're going to do it right."
4. Let everyone know how to make money. Hashim Warren, Interactive Producer of BET's 106 & Park, said " Google should make it clear how devs can make money on the platform." Many others in the conversation agreed.

The excitement and opportunity are tangible. "As a developer, I'm already 100% in," says Eric Skiff of New York's QLabs. "Google's magic sauce of realtime feedback, notifications, re-sharing and general excitement about the platform are keeping engagement super high from my perspective, which means the chance to compete for users' attention where they're already looking."

What do you think readers? Can Google Plus win developers away from today's dominant social platforms? What will it need to avoid or do in order to compete most effectively?

As a user of all these services, I couldn't be more excited to see the competition heat up.

AIR Marketplace for Consumers

The two stores served different purposes for Adobe. The AIR Marketplace was a consumer-facing effort where end users could search for and discover applications built using Adobe AIR technology, like TweetDeck, AccuWeather's alerts app, AOL's Top 100 Videos or a Facebook Photo Uploader, to name a few of the more popular items. Developers were encouraged to list their apps in this store for self-promotional purposes, and it included typical consumer app store features like images, descriptions, ratings, reviews and social sharing options.

InMarket for Developers

Meanwhile, Adobe's InMarket was an app distribution service targeted towards developers. The idea here was that developers could publish once to distribute everywhere.

Adobe launched the store last fall, when it only supported publication to Intel's AppUp center, a Windows app store designed for netbooks and notebooks. At the time, Adobe said that it expected to support 10 stores by the second half of 2011. Unfortunately, that did not happen. According to the InMarket FAQ, only AppUp and Adobe's own AIR Marketplace were supported. This makes it seem as if the store's shutdown had less to do with "developer feedback" and more to do with Adobe's failure to secure app store partners as promised.

Developers have until August 31st to download their app analytics, revenue reports and other data, and update any widgets or links to their app's webpage. Developers who published to AppUp will receive an email from Intel over the next few days with more details about direct publishing.

Until now, credit card accounts and personal information have been stored in centralized, online databases, making them vulnerable to attacks. With the new cloudKey system, which uses standard encryption technology and a "distributed key" topology, appMobi aims to deliver a more secure solution.

With cloudKey, customers' private data is stored using 256-bit AES (Advanced Encryption Standard), which is the NSA-approved data encryption standard. It also uses a "distributed key" topology, which means that the appMobi servers don't house the private data themselves, only decryption keys. These keys on their own are worthless - a hacker would still need to get hold of a user's device in order to obtain the credit card data.

Even then, doing so would be difficult. The data on the device is encrypted, too, and hackers would have to crack a password to get access to that information. Even if a hacker was able to break through all these barriers, the payoff would be minimal - perhaps just one credit card number. For most hackers, that would represent too much work for too little reward.

cloudKey Technology

The new cloudKey e-commerce system easily integrates with payment gateways from PayPal, Authorize.net and even direct carrier billing. It has been tested in all major browsers, including Chrome, Firefox, Opera, IE 6+ and Safari, and works both online or on mobile.

The system's technology does not require specialized hardware, either, which makes it different than point-of-sale focused payment systems that use NFC, for example. With NFC, devices have to come equipped with secure storage - a special on-device hardware storage area where credit card information and other private data is saved. Although appMobi's system is not competitive with NFC, as it's designed for online and mobile purchases, not physical ones taking place at a cash register, it is possible that parts of this system could be used to enable a secure storage area of sorts on NFC-equipped phones that lack the necessary hardware, like Nokia's C7 and N9. These new Nokia devices, it's been discovered, are not capable of supporting mobile payments or mobile wallets, for that very reason.

Where to Get It

The cloudKey technology will be immediately integrated into appMobi's 1Touch payment system, for use by mobile and Web developers. It will be free for 30 days, and afterwards, there will be a flat rate of 10 cents per transaction.