Distractable

Goodbye Markdown

2012-01-04T00:00:00Z

Over the last couple of years I have used Markdown a lot. Content on this blog is written using it, Github has A-grade support for it, etc, etc. In general, it's a nice unobtrusive way to write prettier than plain-text docs.

Now, though, it's time to move on.

You see, Markdown just doesn't scale. It's absolutely awesome in the small, but when you need to do something that takes more work, it really falls down. Don't believe me? Try writing extensive technical documentation - say anything that requires linked information, potentially reusable snippets, etc.

While there have been some valiant efforts to extend markdown, I believe doing so is probably time wasted. You see, it's already a solved problem.

After just spending a day or two with reStructuredText and Sphinx it's clear that these tools are built to scale. On the flip-side, they do feel daunting to get started with, and perhaps at first don't feel quite as natural to write in. Still, I think it's definitely a case of short term pain, for long term gain.

Combine the power of the tools with great online resources such as Read the Docs and I would say you have a recipe for success. Just have a look at the quality of the documentation for a project like Celery. Wow.

I would also say that Sphinx feels strongly geared towards use with Python. After poking around a bit though, I found it does a bang up job with other languages too.

Over the next few weeks I'm going to make a good effort towards documenting my experience with documenting JS projects with sphinx at sphinx-js-howto.readthedocs.org. If you have already been using Sphinx with JS projects, then if you could drop tips here or hit me up on twitter that would be awesome.

Dear HP

2011-11-09T00:00:00Z

So, HP call a meeting to let everyone know they are still deciding the fate of WebOS. This is excellent news, while also quite comical. Vendors in the mobile space like to do this though, and it does help to keep us mobile developer types amused. Given that coding for the mobile web can at some times be hard, I thank them for that.

As a show of my thanks, I would like to humbly offer some strategic advice regarding WebOS.

On Brand Damage

The HP brand has certainly been damaged through what I now like to call the "Apotholypse", and the way HP needs to carry itself in these post-apotholyptic times is significantly different than before. The great thing is that the HP brand is strong, and as a consumer I'd still happily go out and by a HP printer, server, etc. I feel comfortable using HP in a sentence with regards to hardware.

That said, though you have proven to be poor custodians of the Palm brand. I really don't feel like I could say HP and mobile within 5 words of each other without have to reaffirm both myself and others I am speaking with that you do actually know what they are doing.

So, let's look at these last few months as an opportunity rather than the glorious screw up that it was.

It's an opportunity to relauch / renew the Palm brand. HP, given you seem to be comfortable with spin-offs, why not spin Palm back off into a self-contained entity with more autonomy and power. While trying to say HP and mobile feels difficult, saying Palm together mobile still feels incredibly natural. I genuinely see an opportunity here, and there are some great angles you could explore with regards to a Palm relaunch.

On OpenSource

It's great to see that the WebOS dev team have actively embraced various OpenSource technologies (Node.js, WebKit, etc) in the creation of the platform. First and foremost this is something that must be preserved - many companies today suffer from the Not Invented Here syndrome and are going to suffer as a result. Don't fall into that trap.

I'd love you to also consider opensourcing WebOS under potentially a new OpenSource brand (maybe Palm Foundation, Palm Labs, etc). While a simple argument for this would be that "all the cool kids are doing it" and therefore it would be a win on a marketing front, I believe there are also more compelling arguments:

WebOS has a strong community around it. People who have picked up a WebOS device, love them. Developers who have coded for the platform seem equally passionate. Take an existing strong community and empower them with OpenSource software generally proves to be a recipe for success.
WebOS already exists in an OpenSource ecosystem. In using and embracing existing OpenSource projects you are already hooked into the OpenSource ecosystem. If WebOS was to become an OpenSource product in it's own right, then that ecosystem grows stronger and all parties benefit.
OpenSource and Mobile OSes are not being done well at the moment. Technically, Android is OpenSource. In reality though, it just isn't. As a simple example, pop on over to source.android.com and see what the latest version of the source you can find is. Then compare that with the latest version of the OS you know about. Any questions? With regards to Meego and Tizen, I will leave that for another post, but suffice to say there is a vacuum to fill in Mobile OpenSource operating systems and I think WebOS could really flourish there.

On the Power of the Web

The mobile space is still wide open. Without doubt, iOS is the flagship consumer platform and Android is gaining massive market share through distribution in low-cost devices (Android is the new Symbian folks).

There is still a lot of opportunity though. I believe the current mobile space will eventually be dominated by the platform that proves to be the most interoperable. And when it comes to interoperability I look to the Web. Despite perceived technical limitations, the Web continues to grow, change and adapt.

I believe the more a ~~mobile~~device platform works with the Web, rather than against it, the greater it's potential reach and therefore success. Eventually, Mozilla's Boot to Gecko project may be this platform, but WebOS has a big head start if it chooses to stretch it's legs.

On Walled Gardens, Social and the Next Big Thing

While some of the existing mobile OS vendors are doing very well, they all have their own hosted services that consumers are encouraged to use. Essentially, the current strategy seems to replacing the previous telco-weeded walled gardens with OS-weeded walled gardens instead.

For the most part this seems to be working, and consumers dancing to the beat of the vendors drum. The fly in the ointment though is that none of the existing vendors do social very well. Consumers therefore look outside the vendor led offerings to things like Facebook and Twitter.

While I'm not really a big Facebook fan, it does demonstrate the power and reach of the web. With web technologies at it's core, WebOS should in theory be one of the most capable social mobile platforms. That's definitely something to be explored, grown and then publicized.

Also, when (not if) the next big web application starts to gain traction, built on the foundation of the web, WebOS will be there first.

In Summary

I believe WebOS is completely salvageable as a product. I think, however, there is little HP can do to regain any kind of consumer / shareholder confidence in mobility where they attempt to maintain direct control.

It's time to make some progressive changes, and at the same time cash in on a celebrated brands past. Will shareholders jump for joy at the news. They might if it were just the Palm relaunch. They may, however, be more skeptical with regards to any OpenSource plans.

I do believe, however, these are two decisions that do at least need to be roadmapped (if not announced) together. Doing either one without the other definitely diminishes the chance of success (OpenSource leads to more developers, leads to more apps, leads to more consumers, etc, etc).

HP, I wish you measured decision making, and I do genuinely believe what I have outlined above represents a decision that can be made right, even if it is not the exactly right decision.

Whatever you decide, I will continue to take an interest in WebOS.

Update: 2011-11-15

Well, it looks like the Android 4.0 source has been published. It's great to see the source code being released sooner than I expected, so I'm happy to eat my words with regards to previous comments around the lag of Android source releases. This doesn't change the fact that I'd love to see something at http://github.com/hp/webos ;)

Nokia back in the game with N9?

2011-11-02T00:00:00Z

Yesterday, I bought a Nokia N9 and I declare it to be awesome. So given its awesomeness, are Nokia now back in the consumer smartphone game?

Short answer, no. Why? Because they messed up - and we helped. The N9 is an absolutely awesome piece of kit. A sturdy, functional, well polished and feature-complete device. Heck the browser even supports multi-touch events.

So if this device is so good, why aren't they back in the game?

Because the N9 does not represent the future of Nokia devices. As far as I'm aware the N9 is the last of the Meego powered devices that Nokia plans to ship. Their future aligns tightly with Microsoft and focuses on shipping devices with the Windows Phone 7 operating system.

We did this

We all thought Nokia was down and out, a company that once dominated the mobile space seemed destined to fade slowly into the night. I suspect some very talented engineers at Nokia, however, felt differently and put an incredible amount of work into creating both Meego and the N9.

I now feel a sadness for those talented engineers and regret everything I have previously said about Nokia being doomed to fail. Why? Because it was all of us doubting Nokia that led Nokia to ditch Meego and partner with MS for a future of Windows Phone riddled devices.

What a tremendous shame. I hold in my hand a truly awesome piece of technology. One that truly gives its iRivals a serious run for their money. A piece of technology that feels better than any Android phone on the market, but has no future roadmap.

An Apology and a Plea

To the team at Nokia (who may well no longer be there) who crafted this device, let me say I'm sorry. You deserved better.

To the Nokia management and decision makers, please reconsider your decision to move away from Meego and focus on the Windows Phone OS. Not only have you shown that what you had with Meego was excellent, I believe you are potentially coupling yourself to a product roadmap in WP7 that does not align well with a mobile technology company. I could write a whole post on this and may at another time, but for now let's just say that MS and WP7 are definitely not the best fit for Nokia.

Spread the Word

If like me, you have bought an N9 and feel the same way that I do. Tell your friends. Tell your fellow developers, and tell your clients who you build mobile apps / websites for. This is a device that deserves respect and serious consideration.

My belief is the jury is still out within Nokia on Meego, and adoption and positive feedback on the N9 could definitely influence future decisions. Coupled with the generally poor response that Windows Phone 7 has had (I still don't know anyone who really cares about it) I genuinely believe that Meego has a fighting chance.

But then, what do I know. I thought WebOS could have changed the world...

No more JavaScript Animation

2011-10-22T00:00:00Z

I've written my fair share of JavaScript animation. Though from this day forward, I'm declaring it's time for it to stop...

For the last few years (and perhaps longer) there has been a lot little niceties added to libraries such as jQuery to improve the feel of websites and applications through small animation touches. While these have been wonderful, I think it really is time to start focusing on only using CSS3 to deliver our animations.

Interestingly, as I say this, I find myself in full agreement with John Allsopp's recent post, The Next 6 Billion. So how can I make a statement saying animation should only be done using CSS3 which is only supported in a handful of browsers?

Well, I say it based on the fact that animation (by and large) is something we add to our applications and sites to give them that little something extra. I can say with certainly through the process of writing Tile5 that I spent a lot of time focusing on implementing animation in JavaScript, and... it's a distraction.

Rather than focusing on broadening browser support or thinking about how HTML5 shims / polyfills might be used to work with my library, my brain is obsessing over easing equations and the like. Guess what folks, the problem is already solved and CSS3 does a bloody good job of it.

While I'm not going so far to say that I'm not developing for older browsers (although the fact that I write so much JavaScript does bring about some limitations) I am saying that if the web is for everyone, then we need to look at our products from a cake and icing perspective:

The cake is for all. The icing is for those who choose, or have the privilege of using a modern browser.

So personally, I'm going to try to start spend more time on the cake, and utilize premixed icing where it works.

Classtweak - Terse DOM Element Class Modification

2011-10-18T00:00:00Z

Between the progress of various HTML5 specifications (the Selectors API for instance) and awesome little libraries like Eve I'm starting to see less and less need for jQuery.

I've loved jQuery for a long time, but it is starting to get heavier and heavier as time goes on. This is completely understandable given the broad browser compatibility that is required of it, but when you start to realise you don't actually need all that weight, then you start looking around for smaller component pieces to help solve the problem.

Classtweak is a little experimental JS library that provides an alternative to jQuery (and Zepto) addClass, removeClass and toggleClass functions.

I'm actually really pleased with the result as it feels really light to use. For example, let's say you had a HTML element that you wanted to add a particular class to (and didn't want to clobber the current classes in the elements className property). If you weren't going to use jQuery, then you would have to slice and dice the current classes attached to the elements, and if your new class didn't exist then add it.

This is what classtweak is designed to do, e.g.

// get the element using old school, getElementById
var element = document.getElementById('test');
 
// add the bounce class to the element
classtweak(element, '+bounce');

In the above case, through a call to getElementById we retrieved an element from the DOM. We then used classtweak to add the class bounce to the element. As classtweak has been written to work in conjuction with newer HTML APIs, you can also ask classtweak to make use of the Selectors API for you:

// add the bounce class to the test element
classtweak('#test', '+bounce');

This is exactly the same as the first example, but where classtweak uses the document.querySelector function to locate the element. In actual fact, classtweak is making use of the querySelectorAll function which returns all matching elements so if you wanted to modify all divs on a page you could do the following:

// add the bounce class to the element
classtweak('div', '+bounce');

For the most part, anything you could do with a jQuery selector you can also do using the new Selectors API so it's well worth having a play.

Class Modifier String

The class modifier string (specified in the second parameter) is designed to let you add/remove/toggle mutiple classes of the specified elements in a single call:

// add the bounce class, and remove the slide class
classtweak('div', '+bounce -slide');
 
// toggle the bounce class on the even divs
classtweak('div:nth-child(even)', '!bounce');

An alternative syntax is also currently supported, but I'm not sure if it will stick around:

// add the bounce class, and remove the slide class
classtweak('div', '.bounce slide.');
 
// toggle the bounce class on the even divs
classtweak('div:nth-child(even)', '.bounce.');

A few conveniences

In addition to the core functionality, I've dropped in a few conveniences into classtweak. For instance, if you don't provide a class modifier string (2nd parameter) then classtweak will return you a tweaker function that you can use to modifier classes on the elements that were specified / located in the first parameter:

// get a tweaker that is bound to the divs on the page
var tweaker = classtweak('div');
 
// add the bounce class to the divs
tweaker('+bounce');
 
// toggle the slide class
tweaker('!slide');

I've also added chaining so you can do a whole pile of tweaking all at once:

// deactivate all the sections on the page and then activate the 
// 'home' section
classtweak
  ('section', '-active')
  ('section[data-route="/"]', '+active');

It's important to note that the function that is returned for chaining depends on the way class tweak is called. Basically, if you provide a class modifier string (2nd parameter) you can reselect and tweak again as per above. If you do not provide a modifier string, then a tweaker function is returned which can also be tweaked:

// get a tweaker that is bound to the divs on the page
var tweaker = classtweak('div');
 
// add the bounce class to the divs, and toggle the slide
tweaker('+bounce')('!slide');

Feedback, Suggestions?

If you have any feedback or suggestions, then it would be great to hear them. Particularly interested to know what people's thoughts around around the different modifier string syntaxes as it would be great just to support one for both library size and keeping things simple reasons...

HTML5 API Soup

2011-10-17T00:00:00Z

I've been back from Webdirections South 2011 for a couple of days now (absolutely awesome conference, BTW), so I thought it was high time to get the slides from my HTML5 API Soup up where everyone could have a play around with them.

It's important to note that this deck has been built in deck.js with some additional help from two command line tools I've been working on ( deckem and demogen) that assist with the construction of the deck. It's still early days yet for both of these, but I intend to keep working on both as they make my life significantly easier.

The presentation itself walks through a few of the HTML5 API's that I have had experience with and finishes around highlighting the fact that these APIs are best used together (hence the soup analogy).

The deck itself is something that you can actually try out code samples in yourself, and in time I'll remove the iframed code and replace it with something nicer. It does, however, do the job and allows you to get some experience with the APIs without having to leave the presentation.

If you have any feedback I'd love to hear it. Anyway, here's the link:

HTML5 API Soup (May not work in all browsers...)

Additionally, if you are would like to play with the awesome and silly Geocities.js library, you can find it here:

https://github.com/DamonOehlman/geocities.js

Have fun :)

Dart - Fragmentation, Innovation and Standards

2011-09-13T00:00:00Z

There has been a lot of discussion in the last few days around Google's intention to develop Dart (a new potential client-side language for the web). If you haven't seen the discussion, then I would recommend checking out the jsPerf Dart Summary as it is an excellent summarizing of what has transpired so far.

While it's great to see people passionately defending JavaScript (it really is quite a wonderful language), I believe there is merit in Google's Dart strategy.

On Fragmentation

I have seen quite a few tweets from coders that I respect regarding the fragmentation that introducing Dart will bring to the world of client-side development. The truth is (IMO) that the fragmentation is already there. You see, CoffeeScript is already an example of the fragmentation.

Now, it's important to note that CoffeeScript didn't cause the fragmentation, but rather it is a by-product of the existing fragmentation within the client-side development community (note I didn't say JavaScript).

There are many programmers being drawn (either by choice or necessity) to the wonderful world of client-side dev, many of whom have come from a classical OOP programming background. While I have grown to love JavaScript, I can say that the initial transition from classical OOP to prototypal inheritance was a mind-bending experience. Given my experience, I can definitely understand why people choose CoffeeScript over using JavaScript directly, despite my belief that it is the wrong way to go (in the long run).

With more developers required in the client-side space, many of whom I think will transition from server-side development, this fragmentation isn't going to go away. I think Google recognise this.

On Innovation and Standards

The other main criticism that people have of Google with regards to Dart, is how they appear to be circumventing standards processes. I think this is completely true, and personally I don't have a problem with it. In my opinion and limited experience with collaborative research groups, innovation rarely happens effectively by committee or group-think.

Innovation requires an courageous mindset and one resilient to external criticism. I believe that Google deserve the opportunity to showcase what they believe the "language of the web" would look like, and it should be able to succeeed or fail based on its merits.

This is the opportunity we as developers previously gave to great innovations like jQuery and CoffeeScript (yes, I do consider CS a great innovation). I realise that both of these innovations have been built upon the foundation of JS (which has facilitated their broad adoption), the point is that they were not conceived or driven by a working group, but rather by individuals with vision and drive to improve the way we work with the web.

Dart is obviously something more aggressive again, and while the notion that we need something other than JavaScript to effectively drive the client-side web feels sacreligious at first, I can certainly draw on experiences that validate Google's direction.

JavaScript is an awesomely powerful language - one that definitely takes prowess to wield effectively. I can't help but wonder whether we have enough skilled craftspeople to use JS effectively to build maintainable client-rich applications. Looking ahead, we are going to have boat-loads of apps to build and maintain, and personally I don't know where the developers are going to come from. That, however, is another post entirely.

With regards to Dart, I'm certainly interested to see what the collective value of hindsight of some very smart people can come up with. I do hope that Google invite some other non-Googlers to the table to help foster open communication and discussion, but at the same time hope the group is only as big as it needs to be to achieve an outcome.

JavaScript Builds with Interleave

2011-09-01T00:00:00Z

I've been a little frustrated with current set of JavaScript built tools for a little while now. I don't know whether "I'm just doing it wrong" or whether there is a genuine need for something better, but I've finally caved and written one.

It's called Interleave and you can check it out on Github.

Why Another JavaScript Build Tool

As I outline in the project readme, there are already quite few options available when it "building" your JavaScript app or library. I posted earlier in the year about my thoughts on moving beyond a simple concatenation style approach and my opinion hasn't changed too much since that time.

As outlined in that article, I ended up using Sprockets fairly extensively while building Tile5 and it did the job. I did often find myself questioning why on earth I was using a Ruby tool to build my JS files when Node.js could support such a tool just as easily.

Initially, I thought Stitch would fill the void. While it is very good it seems very geared towards using behind a Node.js application. Even fellow Brisbane coder, Tim Oxley's attempt to create a nice command-line wrapper to Stitch didn't convince me. I did have a tinker with it when building our Node Knockout Entry and it was great in that context, but I'm still not convinced around using require on the browser front.

So with nothing feeling quite right, today (finally), I started writing my own.

General Usage

I won't go into too much detail here, as I've tried to cover things in the repository README as much as possible. At a high-level, Interleave injects (as does Sprockets) include files into your source files rather than adopting a simple concatenation approach. This allows you to compose your JavaScript files in a much more intentional way.

Including a file is done using the same comment format as sprockets (but without the require keyword):

//= lib/test.js

I've added a few additional features too, and I can happily say the library is built in such a way that should allow easy extension. For instance, want to pull in an include from a github repository? Yep, you can do that:

//= github://documentcloud/underscore/underscore

Maybe, you just want to pull jQuery down from the CDN. You can do that too:

//= http://code.jquery.com/jquery-1.6.2.js

Update (02 September 2011)

I've also added a bitbucket loader, for those of you who use Bitbucket. It works pretty much exactly like the github loader.

//= bitbucket://puffnfresh/roy/src/types

A Work in Progress

Interleave is a project that started today, so it's far from a finished, polished product. It does work though, so if you are frustrated with the current JavaScript build tools and want to be more intentional with the way you build JavaScript applications and libraries, then give it a go.

If you have feedback on the concept, then feel free to leave a comment here, ping me on Twitter or report an issue.

Node.js Templating Options

2011-08-23T00:00:00Z

With Node Knockout just a few days away now, combined with some early work I'm doing on a CouchDB + Node.js integration platform, I decided to take another look at the state of templating in Node.js.

Now, if you are looking for a templating solution, then there are quite a few options to choose from in various stages of development. For the purposes of this blog post, I'm going to focus on four options that I think all look pretty interesting.

Additionally, this is a less-is-more post so for template samples go check out the various projects :)

Weld

https://github.com/hij1nx/weld

Weld describes itself as an 'anti-templating' solution which fits nicely. By using appropriate CSS selectors weld can quite capably turn a piece of boilerplate HTML into a nicely filled-out view.

It's both browser and Node.js friendly, but does require the jsdom package to create a functional DOM on the server-side. It's certainly an well-crafted solution and one that should appeal to folks looking for a solution that genuinely encourages separation of design and coding concerns.

On the downside, using a DOM implementation on the server-side feels a little heavy to me, and does mean that Weld is a solution for templating solution that is limited to creating HTML output.

Jade

https://github.com/visionmedia/jade

Jade is a Haml-like templating solution which goes to the opposite end of the templating spectrum to Weld. While Jade isn't going to be a great solution for allowing a designer and coder to work together in any kind of workflow, it is extremely expressive and efficient.

Additionally, in terms of features Jade is very, very impressive. Support for mixins, includes and filters are there. Specifically of interest a markdown filter is provided given that either markdown-js or node-discount is available in your node packages.

Express.js is supported out of the box too, and given my love of Connect this is a bit of a plus.

Mustache / Handlebars

In terms of my favourite client-side web templating solution, Handlebars is a particular favourite. It's worked really well in a current project, and I'm definitely comfortable with the Mustache approach to templating.

With regards to options for Mustache-like templating there are a few options available:

mu
Express View Engine Wrapper for Handlebars
Dust (see below)

I'm not going to go into the strengths of Mustache-like templating here, but suffice to say that it's pretty flexible and it's application isn't constrained to generating HTML documents (which I think is a good thing). In general, the Node.js implementations (mu especially) look to be very faithful implementations of a Mustache templating option.

Dust

http://akdubya.github.com/dustjs/

I like dust. Why do I like dust? Well because it's thought beyond the simple file-based templates + data = output. It uses mustache-like templating syntax but then builds upon that to support partials (includes) and other nice features.
Partials don't necessarily have to reside on the file-system either, and can just as easily be stored in something like CouchDB or another datastore. That's flexible and clever, and exactly what I need at the moment.

Templating Solution of Choice

The best choice will always depend on the circumstances:

In the situation where you want to support a solid designer -> developer workflow, then I think it will be hard to go past Weld. It's still maturing so you will need to be aware of that, but it's a great approach to templating HTML documents.

For something like NodeKO, I reckon Jade is a great choice (depending on the makeup of your team of course). The ability to get more for less keystrokes is always good when time is constrained, and the integration with Express makes it a good choice for the day.

In other situations though (or when you don't know what the situation might be), it is hard to go past a Mustache based solution. Given dust falls into this family and offers some great extensions, flexibility and top-tier asynchronous support, I'll definitely be giving it a try.

A New Home for WebOS?

2011-08-19T00:00:00Z

The world of mobile - crazy one day, insane and upsetting the next. This week in particular has been a real doozy. The whole Google, Motorola Mobility thing was pretty interesting, but today's news of HP making some strategic changes is just downright disappointing.

So while the only thing that's clear at this stage is that nothing is clear, it definitely seems that the Google-Motorola transaction has shaken everything up quite a bit. There are some pretty interesting theories kicking around as to what might eventually transpire. These range from the HP just dropping mobile hardware and continuing to evolve and sub-license WebOS, to selling off everything to someone like HTC, LG given they have been disadvantaged since the Google Motorola deal.

My thoughts are somewhat different. I don't necessarily see HP being terribly successful simply sub-licensing WebOS. I may well be wrong, but it seems that currently their isn't enough money to be made in sub-licensing mobile operating systems for a company as big as HP to be bothered with this. Neither do I think an LG or HTC acquisition of the full WebOS line would be that successful either.

My theory focuses on a company that has a lot of cash and currently knows it isn't as relevant in the mobile space as it should be. Also it's a company that can finance it's investment in an operating system from hardware licensing / sales rather than software. If you haven't already guessed, it's Intel. Yes, I know they've tried this before with the whole Maemo / Meego thing and failed pretty badly. I still think its something they could pull off.

While I thought I was a little off at first, there is evidence to suggest that Intel still feel strongly about the mobile chipset space.

Would WebOS flourish under an Intel acquisition? No, probably not. Intel folks don't have the head for software (sorry guys). It could definitely flourish under someone like Joyent though. Oh, I wonder where most of Joyent's funding so far has come from, check it out folks - Intel Capital. Combine the fact that WebOS services are written using Node.js and you can see that things would really start to sing.

I genuinely think that Intel pushing for this kind of top-and-tail strategy would really work for them. There's obviously a few things that have to be sorted for it to work out, but you have to admit, it would be kinda interesting :)

UPDATE 10:00am AEST: Thoughts on Mozilla

A few people have suggested Mozilla as another company that might be interested in taking on WebOS. While I think they might be interested (especially given the announcement of their Boot 2 Gecko initiative) I'm not sure that Mozilla have the "deep-pockets" required to complete the transaction. And even if they did, would they consider it bang-for-buck?

My thinking (which is probably off) is that Mozilla are a talent-rich company but aren't "brimming with funds". So for my money I would expect Mozilla will opt for the build rather than buy approach for a mobile OS.