marco@ocr.am

Early 2008, my life was turned upside down: my wife gave birth to our son Ben. And roughly at the same time, I started working for Seesmic. While the former is obviously of much greater significance for me and brings joy to my life every day, the latter is an episode that now, after almost four years, has come to an end. It’s time for me to move on and start a new chapter in my professional career. And this is both a sad as well as a happy moment for me.

Over the last four years, I’ve had the amazing opportunity to work with great people on exciting projects and products. I’ve learned so much, by wearing the hats of a developer, a designer, a product manager, a technical lead and the company’s CTO, and by trying to help steer a startup in one of the most exciting (and sometimes outright crazy) ecosystems - the world of social networking. We’ve seen ups and downs, we’ve made great and totally wrong decisions, we pivoted a few times, we’ve seen success and failure. It’s been mostly a fun ride, but occasionally also frustrating and tough. I probably would do a couple things differently in hindsight - but I don’t want to miss a single week of working on this.

First of all, I want to thank Loic Le Meur for offering me the opportunity to work for and with him at Seesmic. His energy and enthusiasm have always been the driving force behind the company. Even though (or maybe because?) we didn’t always agree, I will miss the frequent discussions we had about our products and strategy. 

But there have been many other people at Seesmic, that not only were great colleagues, but have also become personal friends over the years - to just name a few in no particular order: Johann, Mathieu, Yama, Alex, Bastien, Max, Costin, or George - and I hope our paths will cross again in the future.

Through Seesmic, I’ve also had the chance to travel quite a bit and visit (and become a fan of) San Francisco and Bucharest quite a few times. I’ve attended conferences and meetings in Berlin, Munich, Paris, London, San Francisco, Las Vegas, Seattle, Los Angeles, and Singapore. I worked with great people at other companies, like Microsoft (thanks for all your help, Jaime!), Facebook, or Twitter. There are countless moments that I will remember from those four years.

But now, it’s time for me to start something new. I want to take what I learned at Seesmic, and use it in a different context, in a different environment. After seeing how startups ‘tick’ in Silicon Valley, I want to go back to the roots and work in Germany again, on new ideas and projects. I feel that there is so much more to learn, so much more to see here, that I just can’t pass on this opportunity. It’s too early to speak about what’s next for me - but it’s something that excites and keeps me awake at night already, just by thinking about it. More on this soon.

So, goodbye and thanks for everything, Seesmic. And, hello future!

Let me be clear: I am not the biggest fan of TechCrunch, and haven’t been so over the last few months or even one or two years. I unfollowed them on Twitter and removed them from my feed reader, long before the whole AOL drama started. The signal vs. noise ratio of their articles was just too bad, and I couldn’t stand to see a lot of the crap that was published on the site.

That said, I’ve continued to be a fan of some of their writers, and I couldn’t fully ignore them either. I relied on my social graph to point out the posts that are worth reading, which worked well, more or less. I loved that people like Mike Arrington, MG Siegler, or Paul Carr (just to name a few) never tried to be ‘journalists’, but remained bloggers who didn’t hesitate to write pieces colored by their own opinion. They didn’t try to be objective - and that was what made TC awesome sometimes.

Today, that’s history, and almost all of the authors that made TechCrunch great in the past have moved on now, with Robin and Greg being the latest to jump ship. For me, other sites have taken over, like The Verge, The Next Web, or PandoDaily, and I rarely go back to TC these days. I just don’t feel that I miss anything by not reading their articles. They have lost their magic for me.

Now, there was one article today that caught my interest, though. Alexia Tsotsis (admitted, I am not a big fan of hers normally) wrote a post to say goodbye to Robin and Greg, a post that should have been written by Erick. All kudos to Alexia for writing this, and even linking the article written by former TC columnist Paul Carr over at PandoDaily as the one that ‘we should have written’ (at TC). There’s one little spark of the old magic in that post.

One thing really got my attention in Alexia’s post:

We should be honest about how TechCrunch is different now and what our goals are with regards to our community and readers, in a post.

Apparently, there is a masterplan behind what’s going on at TechCrunch, that probably Arianna and Erick are driving forward. And from what Alexia writes, it seems they aren’t honest about it at this point. 

There, you have it. That’s the big difference between now and then, between the business of a sub-unit of AOL run by Arianna, and the young and reckless techblog that Mike Arrington created back in the days. I’ve always admired them for writing about all their internal dramas, failures, successes in all openness. Nothing of that is left today - all is good, Houston, we don’t have any sort of problem.

Please, don’t think your readers are that dumb. We get that there is a change going on, and we are old enough to decide on our own if we want to stay with you, or if we move on. But if you’re not honest with us, we’ll very likely feel betrayed and move on for sure.

Each blog gets the readers it deserves. Good luck. 

Rarely did such a simple app (in terms of functionality) receive that much buzz and excitement before and as it was launched. Clear is just a To Do list app for iOS, with no ground-breaking new features. It doesn’t even look like what you would an iOS app expect to look like today.

But that’s also what makes it stand out from the crowd. You won’t really find a button to tap on in its UI - it’s all flat and content, and you navigate it with gestures like pinch, zoom, or swipe. The team behind the app has clearly (no pun intended) ignored most of Apple’s UI design guidelines, and came up with a user experience that is simple, reduced, minimal - but still gets the job done.

If you thought that Path’s navigation menu was revolutionary for iOS, think again. Clear takes it to the next level, throwing known UI patterns over board. Once you memorized the basic gestures, it’s simple and easy to use. 

But there’s also some risk they are taking with this - without learning these new gestures, you’re pretty lost in the app, as there is no real visual hint at what you can do. It makes you think ‘how do I do this’, especially at the beginning. And as we know, this is not necessarily the easiest way to success. If mainstream users are either unwilling or unable to get used to this button-less UI, it puts the whole concept at risk.

Also, as intriguing as this approach is, it might only work for apps with limited numbers of features and actions on a view. If you find yourself pinching and zooming in and out all the time to get to new navigation layers, or swiping left and right to trigger some actions, users simply might want to get their buttons back. 

In the end, Clear is a fascinating app and UI concept, but it yet has to prove its real world compatibility.

So, Techmeme finally got a redesign. It’s no longer (one of) the ugliest sites on the Internet. Good job, Gabe!

And while I like the overall direction where this is going, I’m not so sure about two things: using Optima for almost everything as the type-face, and going from one extreme for links (underlined) to the other (almost indistinguishable from regular text).

Here’s a screenshot:

First, Optima: I really like the type-face, I do. Especially when used as a display font, or with small amounts of copy, and not-so-tiny sizes. It has that classy, elegant look that distinguishes it from other sans-serifs.

But what it totally doesn’t stand for (for me, that is), is high-tech, news, real-time, speed. It’s the font used in memorials, in fashion and perfume. It wants you to sit back and remember or enjoy the moment. It doesn’t want you to glance through a long list of items, articles, links.

Also, I think its legibility on the screen at fairly small sizes is far from ideal - it’s been designed long before personal computers with their screens even existed, and unless you are looking at it on a high-DPI display, a lot of its fine nuances are lost and sometimes even make it look a little distorted. 

I guess it could have worked as the display font for headings, or for labels. It doesn’t really convince me as the primary body font, though.

Now, links. Gabe seems to be proud of finally removing the underlining from URLs, and rightfully so. In most cases, those are not adding any value anymore today, and rather clutter the visual appearance of web pages. 

But… then you need to find other ways to make links stand out from regular text, and not make it all look the same. If you look at the screenshot above, that’s not really the case here: I think the links are slightly blue, but at this size, it’s hard to tell (and I am not talking about the article titles - all those blog names after ‘More:’ are actual links. Just mouse-over them - then you’ll get the full package of underlining AND a background color…).

Sometimes less is more - in this case, it’s a bit too much of less. I’d rather see the links highlighted slightly more compared to the article summary text, and then would be happy to not get the background color flicker when hovering over links.

In any case - great to see Techmeme redesigned, really… but a little fine-tuning now would be appreciated.

A lot has been written about the new Kindle Fire, Amazon’s strategy and path to success, and also what it means to it’s competitors. Here are my 2 cents…

For me, the Fire seems to be the first real competitor to the iPad. It’s a totally different device, and Amazon is approaching the tablet market from a different angle than Apple, but it still might cut into the iPad’s growth - not so much into its existing user base, though. But people who will consider buying a tablet mainly for media consumption do have a strong alternative now, and might go for the cheaper Fire than spending the extra money on the iPad for stuff they don’t or rarely need.

Well, media. That’s the big thing here, Amazon is set up to compete with Apple on content, with their music, video, books, and magazines offerings, like nobody else can. They primarily sell the Fire as a media device to access and consume content acquired from Amazon services, and hosted by Amazon in the cloud. Combine that with the $79/year Prime offer, and I think Amazon is way ahead of Apple here, in terms of available content, and at least on par at ease of use and access.

What about other Android tablets? It’s going to be much more difficult for them. Before, they only had to compete with one big player in the room - now they will have to face another one as well, which has so many better selling points than them. And while the Kindle Fire is based on Android, I’m not even sure if that was mentioned during the launch keynote - because it doesn’t matter to users in this case. While the other Android manufacturers geek out about what’s better with Android technology-wise, Amazon took all of that away. Instead, they hide Android under their shiny, simple UI, and focus on what matters to mainstream users: content, and ease of use. Or, frankly, on the stuff that Android is traditionally bad at.

Then there’s Microsoft. Or not, given that Windows 8 tablets are still many months away. But not all is lost for them, in my opinion. With its decision to position Windows 8 as an operating system for PCs and tablets, they offer developers an incentive to build apps for their new Metro-style UI that will work on both form factors. So compared to Apple, which positioned the iPad as a super-charged handheld rather than a desktop-derivative, and to Amazon, who go low-end and focus entirely on content, Microsoft takes a third approach here, coming from the desktop to the tablet. Given the size of the Windows desktop user base and dev community, that’s not a bad idea I think, and it also takes into account that when Win 8 tablets finally launch. the hardware used for tablets will be ahead of what we have today. Microsoft also has content, via its Zune platform, and also via its Xbox Live platform, that it could integrate with their tablet offerings. 

So, overall, I think Amazon will be a big player in the market soon, slowing down iPad’s growth. It’s effects on other Android tablets will be worse I guess. It’s also going to be interesting to see where Amazon is headed with the purported 10”-sized Fire tablet - will it just be a large-screen version of the 7” model, or will it be more powerful and “open” to other use cases?

Interesting times ahead.

The message about Windows 8 is out - it’s all new, all touch, all Metro. Let’s take a look what Metro is, how apps built for Metro will look like on Windows 8, what that means for developers, and also what problems Microsoft is facing between now and the final release of the latest (and greatest?) version of its operating system.

Metro - a philosophy, a design language, a model for apps

Metro is Microsoft’s new design language — or you might even call it a new design philosophy. After using earlier versions of it in products like Windows Media Center and the Zune, the Redmond-based software company built the whole operating system and development frameworks for its Windows Phone product line around it. But that wasn’t the end of the story, as we can see now - they’re bringing Metro back to Windows itself, in all its glory. Yet again, it was extended and evolved, to fit the larger screen and new touch gestures.

But in the new world of Windows 8, Metro is not only a name for the reimagined (my Mac’s spell checker complains about that word - maybe it was also invented specifically by Microsoft?) Windows 8 user interface, it’s also used as a metaphor for a new class of application, “Metro-style”. Now, in fact, it basically includes all apps built on top of the new Windows 8 development frameworks, so you could also just call them Windows 8 apps. Probably it’s easier to say what they are not: apps running on previous versions of Windows, or under the “classical” desktop UI known from Windows 7, which is still included in the new version to run non-Metro-style and older apps.

Besides following the Metro design philosophy, what are the key changes for these apps (or, for the developers writing them) compared to known, window-oriented desktop apps?

• Metro-style apps usually run in full-screen mode, and the viewport boundaries are not directly adjustable by users. There is no chrome around the content, no controls to minimize, resize, or even close the app or open a window menu. It’s all or nothing. Or not, because one of the new things Microsoft adds in Windows 8 is a split mode, which allows you to run two apps side-by-side in full-screen mode, even though in a limited way. The ratio between the two apps’ sizes can’t be changed, one is running in a narrow “sidebar-like” mode, the other fills the rest of the screen. The only options for users are swapping the modes for the two apps, or removing one of them so the other takes over the full screen.    
• Metro-style apps are not given control over their lifecycle of execution - the user and the OS is taking over here, and the app has to follow. When the user decides to run another app, the formerly active Metro app gets some grace time to persist its state, but then is suspended. Windows just ignores it for now - it will not get a single CPU cycle to run anything until the user eventually gets back to the app. It’s data in memory isn’t immediately removed when an app gets suspended, so if you’re lucky, resuming from suspensions is very fast, but eventually the OS will fully terminate the app if it needs more memory for starting another app. That’s a very sudden death - the app will not get any notification about this. If the user wants to come back to the app after a while, and it had been killed in the meantime, Windows will just launch it again - and it’s the app’s responsibility to restore its previous state.

Does that sound familiar? If you think “that’s how my iPhone or iPad works”, you are exactly right. Windows 8 took what we know from mobile platforms, and brought it to the desktop, to make the OS more responsive, faster in general, and use less resources (read: increase battery time). We’ll be much more in and out of apps than running them concurrently and switching between them all the time, or even displaying many of them side-by-side. It’s a clever move in my opinion - because it acknowledges how we use computers today, our shift to mobile devices that are not always connected to a power source, and that get smaller and have comparably less resources than big fat desktop PCs. And make no mistake - Windows 8 with Metro will be Microsoft’s big push into the tablet world, where all of this is even more important.  

But there’s more for Metro-style apps than that, which goes beyond what we know from other plaforms:

• Windows provides a number of contracts that a Metro app can support. The two most common ones are “Search” and “Sharing”. With these contracts, Windows can wire apps with other apps, or with OS functionality in a very loose way. Take sharing for example: one app can declare that its current view has data that can be shared. If the user taps on Windows 8’s “Share” button, all apps that have registered themselves as so-called share targets will be listed, and the user can decide which one to use for sharing. Like this, it’s very easy to share something from a news reader to Facebook, for example: the newsreader declares a text and a URL to share, and the Facebook app has registered itself to be able to share links and text. Windows 8 connects them, the target app provides a specific share interface, and everyone’s happy.
• Metro-style apps use the new WinRT framework. While technically it seems to be built as a wrapper on top of existing frameworks like .NET or Win32, it only exposes a subset of the underlying functionality, creating a much simpler application model which is less confusing to new developers, but also takes away a lot of freedom for skilled Windows devs. And it lets apps live in a “sandbox” much more than before, as the OS controls its execution much more. Besides the already mentioned new lifecycle model for apps, the biggest shift for developers will likely be the strong focus on asynchronous execution in WinRT - no function call that is expected to take longer than 50 ms is available in a synchronous way, and can only be called in an asynchronous way. If you are a developer, and you were used to straight-forward synchronous coding, and off-loaded long-taking operations to separate threads, that’s a big shift — WinRT gets a lot more modern here, applying development patterns known in other areas of software development for some time. Once understood and used in a reasonable way, it actually makes applications much simpler and easier to maintain. 
• WinRT has bindings for four development techniques - C#, C++, VisualBasic, and HTML/CSS/JS. While the first three are well-known in the Windows development ecosystem (although usually in different environments), the fourth is the new kid on the block. And — it’s a hot one. WinRT allows developers to write apps by just using web technologies, and not ever writing a single line of C#, C++, or VB. But have no fear - nobody has to use it, if you want to stay with your known skills as a Windows developer, you sure can - all four alternatives are treated equally for creating Metro apps, and they all have their strengths and weaknesses, which makes them good fits for your problem - or not. Microsoft’s push towards HTML is strong, though - it was the first technology they revealed for creating Windows 8 apps, and most of the code samples for developing with WinRT are also using it.

So, to summarize, what do we get in Windows 8?

• a new model for applications, inspired by mobile platforms
• contracts that allows applications to extend other apps and the OS in an easy, decoupled way
• a new development framework that focuses on asynchronous code architectures and offers four different language environments

Is it all new then? Do all Windows developers have to start fresh, forget what they learned before, and acquire new skills? Yes and no. Windows 8 and Metro introduce paradigms that are fundamentally different from how apps are coded today for the platform. This shift starts with business analysts who evaluate the need for new apps, goes on to product managers and product designers who need to follow new design philosophies and behavioral patterns, and to developer who need to learn a new framework, and adapt to asynchronous coding techniques. But at least they get the choice to re-use their existing skills with the programming languages they learned and used before, if they want, and there are certainly a lot of similarities in the WinRT bindings to the languages, compared to the older libraries. 

But not only developers must learn and adapt to new things, users maybe need to do it even more. If you’re coming from a classical Windows desktop, and are suddenly presented with the new Metro UI, that’s quite a change. For those who used a tablet or smartphone before it might be easier, but make no mistake - that’s the minority of Windows users. Metro apps are very different from normal desktop apps, and that transition won’t be easy. 

Now or never?

To me, making this change now makes a lot of sense for Microsoft. Or let’s put it another way - they can’t afford to wait any longer, or they’ll never catch up. The first decision they obviously made was to use the same OS for desktops and tablets, and (for now) use another OS on their phone platform. It’s the opposite of what Apple did, when they extended their phone OS to also run on tablets, and didn’t go with their desktop OS platform. At least that’s what it looks like from the outside, and when you have to decide which screens you want to target as a developer. Under the hood, though, it gets a lot more fuzzy. Windows Phone 7 is supposedly built on top of Windows CE, and Windows 8 has Windows NT as its ancestor. All of them have at least a little bit of Win32 and .NET in them, and there are technologies commonly used on both, like XAML. 

And in Apple’s world, it’s not much different either. iOS runs on the OS X Mach kernel, it supports the same development environments, and many system libraries exist on both “platforms”. And with OS X Lion, Apple also brings a lot of ideas from its mobile platform to the desktop, although in a less radical way than Microsoft does with Windows 8. 

What it comes down to is the decision both companies made when marrying their tablet platform to either their desktop or mobile developer community, and allowing them to distribute their apps to two screens in a (fairly) similar way. For Apple, it was obvious that they needed to take the momentum of iOS for the iPad, and it’s very lively developer ecosystem. Especially the easy distribution channel established with the App Store on iPhones was a huge incentive for developers, given the monetization options they got through it. For Microsoft, it was probably obvious either: their developer community is on Windows (it’s probably the largest around the world beyond the web), and their phone platform is still small and didn’t really take off so far. Betting their fate in the tablet market on that would have been risky at least, but most likely suicidal at this point. And even if Windows tablets won’t set off in a huge way immediately, there will be a target audience for Metro apps - all the Windows 8 PCs and licenses that will ship. And make no mistake - they will outnumber any tablet platform very quickly. That’s just how it goes for Microsoft - they shipped nearly half a billion copies of Windows 7 in just two year (and that’s just the legal copies…).

Issues

But not all is bright in Windows 8 and Metro land. Microsoft will have to deliver on its promises and make Windows 8 run well on ARM-based tablets. And not only the OS must run well, also all the apps developers create for Metro. Only then will they be able to convince software shops to go all-in on Metro, and believe in the platform. The worst thing that can happen for Microsoft now is that only few apps will be built for Metro, while the majority of app creators remain focused on the classical desktop. That would mean that not only would it be confusing for users to see the shiny Metro UI, but then have all their apps run on the old desktop, it also means that there will be a lack of apps for Windows 8 tablets, which in today’s world is one of the biggest issues a new platform can face.

Also, the Windows 8 release is likely still one year out or so - that’s a long runway to keep the excitement on the developers’ side. It’s also a huge investment for many companies to switch to Metro, because for many things they need to start from scratch and rethink their apps. And what they get in the end is a new software that only runs on an operating system that won’t have sold a single copy in a year from now, not compatible with earlier versions. Wouldn’t there be the opportunity of an easy distribution channel for apps in Windows 8 with i’s Windows Store, many probably wouldn’t take the risk so early. And again - Microsoft needs Metro apps to make Metro a success.

Last, with WinRT Microsoft confronts its developers with a much more restrictive development environment. In the past, there have often been many different ways to do something, and there was a lot of freedom and low-level hacking possible. This definitely had a lot of disadvantages, for everyone, but that’s what developers are used to now. Development in WinRT is much more guided, you have to play by its rules, and there is no low-level access anymore. Personally, I think this is exactly the right way to go for Microsoft, and to unify its fragmented development story, but it might face push-back from developers who don’t like those new rules.   

Conclusion

With Windows 8, Microsoft makes a few big bets, and Metro and WinRT are two of them. My feeling is that the overall reception was good in the developer community, as it ended a time period where fuzzy signals were sent out. Now the message is clear, and the software giant has one year to resolve issues, answer open questions, and (most importantly) ship Windows 8 to customers. 

I’ve been Scobled on Google+. Apparently that’s the new “being slashdotted”.

What happened? Google+ enabled circle sharing today, which means that users of the social network can now allow other users to see and subscribe to a circle they’ve created. Apparently it’s more a copy and paste than true sharing though, as it’s a one-time snapshot, and you have to put the people from the shared circle into one of your own (new or merge with existing).

At around noon CET today, Robert Scoble (aka Scobleizer) shared one of his circles to his 100k+ followers which I happened to be in (it was his tech/developer circle). How did I notice? My iPhone went crazy with subscription push notifications from Google+ every few seconds. After considering a system failure first, I went on my G+ page and found out what was up. Scoble’s followers jumped onto that circle and put the people in it into their own circles, which created a subscription notification for me every time.

And it didn’t stop, for many hours. When it began, I was at about 1,150 followers (or, “people who added me to circles”). Now, 10 hours later, I passed 2,500 followers. And while it’s going slower now, there are still many people adding me all the time. It’s crazy. It’s wild. It’s fun to see the power of social networks at work.

For reference, on Twitter, which I joined many years ago and which supposedly has many more users, I have a little over 1,000 followers. On Google+ I had passed that mark after few weeks only, and I now have 2,5 times as much followers there as on Twitter.

All that said, my follower count (even though that might sound weird, given the article I just write) doesn’t mean much to me. It’s nice to know someone is reading what I write, but as long as it is more than a few hundred, I don’t really care about the numbers. But it’s still really interesting to see how this happened, and be in the middle of it. The absolute numbers might not even be high - but going from 1000 to 2500 in a few hours? Crazy.

The last months (or maybe even last few years) have seen a large interest in using traditional web technologies like HTML, CSS and JavaScript in other areas like client development beyond the browser both on mobile and desktop devices, as well as on the server side. That’s an interesting trend, especially given that the original purpose of these languages were not at all aiming at these targets. Does that mean it’s not a good idea?

The biggest push towards this direction certainly was unveiled last week by Microsoft at their BUILD conference, which introduced Windows 8 (about which I shared a few more thoughts already) and a new development environment that allows creating Metro-style desktop apps entirely by using HTML/CSS/JS, alongside other more traditional languages like C#, VB, or C++. In the Windows 8 world, HTML/JS has arrived as a first-class citizen.

But Microsoft is not alone with this: Palm built its WebOS platform entirely on these technologies, and despite the recent disruptions caused by HP’s decision to abandon its WebOS hardware business, the platform itself received a lot of credit and love by developers. Also, Adobe allows to create cross-platform desktop apps (and now also mobile apps) with their AIR framework in HTML/JS for a few years now, and there are other similar projects as well. Last but not least, there are frameworks like PhoneGap which let you create write once , run anywhere apps across various mobile platforms.

And JavaScript’s run doesn’t end on the client side - node.js is the hot new tool on the server side as well, allowing you to use it for your backend as well, in a very lightweight, asynchronous, and evented way.

There are many issues one can think of when considering to use HTML and JavaScript for any of these use cases, starting from generally not being mature and professional enough, having performance issues, being hard to maintain and test, or whatever else, and there’s no way to deny all of them exist. The promise of allowing everyone who knows a little bit of HTML and JavaScript now being able to write great apps with it is just a false claim - knowing a little bit of syntax for a programming language doesn’t make you a great developer, let alone a great product developer. There’s more to it than just that - code architecture, visual and user experience design, information architecture, just to name a few. Without all of that, your HTML/JS apps will look poor, be no fun to use, crash a lot, and never be a success.

The thing is - that’s also true for any other programming language you could have used.  It’s easy to write bad apps in C#, C++, Objective-C, Java, or whatever you prefer. That’s not the point. But can you write good apps in HTML and JS? Is it good enough? Or is it an over-hyped phenomenon, just because it is cool at the moment, but not a future-proof technology?

If you look at what happened on the web over the last couple years, there’s been a tremendous evolution of how developers use it to provide users with great apps. Would you have thought that a web email client could be a real alternative to desktop clients like Outlook, Thunderbird or Mail.app? Or a web-based suite of office tools could be used instead of Microsoft Office? Yet it does, for many users. It’s not a solution for everyone, and it also means that some things change in how users work with these tools, but that’s a normal process in my opinion. These apps prove that it’s possible - even in the very restricted environment of a web-browser, across multiple browser vendors and computing platforms. If you have a known, more powerful environment instead, that is not as sandboxed as in the browser, it does work even better.

HTML5 adds a lot of stuff that makes creating rich apps on the web a lot easier, but which also help outside of the browser. With its focus on semantic structure, it allows product designers to think about the user experience of their apps in a different, more abstract way, and not so much on visual aspects from the beginning. If you are able to do that, you can then use a styling layer (provided by CSS, maybe with a little bit of platform-specific JavaScript) to adapt the semantic structure to different platforms, from web to desktop to mobile. So using HTML/JS to create apps does not only change the game for developers, but also to product designers, and obviously also graphics designers.  

JavaScript as a language hasn’t changed that much over the years - but developers much better understand today how it can be used to create rich apps, and not just animate HTML. It’s a very powerful, flexible language, though quite different from other languages. It’s lack of a class system and fairly different interpretation of object-orientation can make it difficult to fully understand for developers coming from more structured languages. It’s very easy to write totally messy code in JS - very few developers don’t fall into that trap when they touch it first - and takes a good amount of time to use it in an elegant way. What’s great though is the availability of third-party libraries for all sorts of things. Most of the time, it’s more difficult to decide which of many options to pick, than finding one at all.

To wrap it up, HTML/JS is one alternative to write applications today, and it is a serious one. It’s proven its maturity on the web already, with apps like GMail or Google Docs, that are full-featured alternatives to their desktop equivalents, giving users a choice. To me, it has two aspects:

• HTML and JS are just another set of development tools. By themselves, they are not better or worse than anything else. They might not be appropriate for everything, but where they are, I don’t see any reason not to use them (and, there’s a lot of desktop app use cases where I do think they are appropriate alternatives). It’s not so much what you use, but how you use it.
• Using these technologies makes you have to rethink how you create and design apps. You can put a much stronger focus on semantics and information architecture, and separate that from the actual user experience and visual design. This is especially important if you target multiple platforms and want to reuse assets across them.

So, should everyone jump ship now and do everything in HTML and JS? Certainly not. But can it be a very valid alternative? Certainly yes. In my opinion, every developer and product designer should keep a close eye on it, play with it, and use it in a project to evaluate it. Don’t be stuck on a technology you have always used, or you risk being left behind. If you come from a Java, C#, C++ or any other background, a lot of what you learned in the past still applies here, from good coding practices to architecture, testing, and maintainable code. The language you use is just a tool, and tools change and evolve over time — what really matters is solving problems for users.