hymanroth

Sounds obvious now, but I remember advising quite a few people "not build their house on other people's land" several years ago.

It was true then, is true now, and will always be true.

I agree it's all about trade-off. Cleaner, faster, cheaper development vs risk of alienating some percentage of users with older mobile browsers. I was trying to get a feel for what people are currently thinking - but there doesn't seem to be an overriding consensus yet.

As regards focusing on what the stack looks like now rather than making an educated guess as to the not-too-distant future, here I have to disagree. Our business is all about well-reasoned gambles, and it seems pretty clear HTML5 will win the day for all but the most complex / intensive apps, so it really only boils down to timing.

Highly-respected VC Mark Suster made a similar point when he advised people to "skate where the puck is going" http://www.bothsidesofthetable.com/2010/10/17/skate-where-th...

Very interesting. Thanks

Excellent comment, thanks. We would require location and touch functionality. The core use case is really quite simple: users provide both text and numerical feedback based on their location - that's basically it. Nothing fancy. It needs to quick and easy to use, work on as many platforms as possible, and - given the nature of the application - is unlikely to be downloaded prior to when it's needed. People are more likely to use it "on impulse" and that's another reason we like the idea of accessing the service as you would a web site.

Well, we'd basically want to target them all! Given that people change their phones more often than their PCs, one would expect the installed mobile browser base to 'fresher' than the PC one. In other words, over the medium term (say 2 years) the rendering issue should hopefully fade away.

It's just a question of timing - when is it going to be OK to go 100% HTML5? (assuming, of course, the app is not particularly complex)

Yes, but that implies the app is an end to itself.

What if you just wanted to present an existing web service to mobile users in an "app-like" UI?

Sure, cycle intensive use cases will probably use native code for a long time to come.

The idea of adding native wrappers around a pure HTML/JS implementation sounds very interesting - like having your cake and eating it....

Yes, but it implies the user anticipating the use case... Would you download an app which talks you through fixing a car engine before you actually needed it, for example?

Thanks - that is exactly what I'm talking about. But don't you have a problem with older mobile browsers not being able to render the site correctly?

Good point. I should have mentioned monetization is not an issue. In other words, if what we aim to build were in an app store it would be free anyway.

Basically I'm asking whether HTML5 will be mature enough both in terms of functionality and browser market share in around 6 months time.

Yes, but Google's valuation is confirmed by trading volumes.

In the early days of computerized trading it was quite common for even quite liquid stocks to be suspended limit up/down because of programming bugs.

But by Joel's logic, the market has 'spoken' and these companies are now worth 10% more/less than 30 seconds prior, when in fact all that has happened is some faulty code just ripped through the book on minimal volumes.

The point is that 'true' valuations are validated by significant volumes. Hence Google's valuation is real. Depending on your viewpoint, the size of the recent transactions in FB may or may not be material - and I think this is the point that David was making.

Hi Joel, ex stock analyst here. What you say re minority trades is correct in so far as that is the way market valuations are calculated. However, what David says is also correct: just because someone pays X for a tiny fraction of the company doesn't mean someone else will pay the same for all of it.

Wily investors always look for meaningful volumes before taking big jumps/declines in share prices seriously.

One of the easiest ways to ramp a stock (apart from getting your journalist buddy to write a puff piece) is to continually lift the offer for small volumes.

See http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm for an amusing counterpoint to PG's original post

Thank you

Yes, some might find it offensive.

Very diplomatically put..

That's useful feedback, thanks

"apple is refusing to support flash in favor of html5"

I would argue Apple is not allowing Flash because it has the speed and graphics ability to compete with native apps (which Apple are monetizing).

Apple are ambivalent to HTML5 - on the one hand it improves the browser experience, but on they other they have been slow to expose the location, accelerometer and touch functionality to the browser.

http://blog.wolfire.com/2010/01/Web-applications-on-the-iPad

Dunno. That's why I asked. Pretty high?

Losers! Bring it On!

What the fuck is wrong with clapping?

Is you real or is you fake?

applause

Fantastic analysis. But where's the money? The point of Calcanis' piece is that the Borg only gets (buys?) its way into markets which are big or growing.

Whilst there is no doubt Yahoo is strong in some areas, he's saying Yahoo has thrown-in the towel in the big fat one. He argues that Yahoo had more than one chance of being a player in search and each time they fluffed it. All the current focus-on-core-strengths talk doesn't cover up the fact that they blew the big one. That's his point, and I think it's a very valid one.

It all depends on whether you're talking about page-based or no-refresh web apps. For the former, you're right: the framework is less relevant, since the system is just basically responding to page requests. However, for a no-refresh app, the opposite is true, especially if the app is highly complex. The framework must manage the transfer of all code and content, which is where pre-fetching and factoring become particularly important.

This is an excellent approach, and in my view will be common in the future. It can also elegantly solve the problem of offline access, with the local web server syncing with the remote server in the background.

Contrary to most of the comments I've seen I thought the video was very interesting.

I'm quite surprised the kids were so willing to walk away from services like FB in which they have a lot of 'emotional capital' invested. I would have thought FB would have been 'stickier' given the photos, memories of shared events etc.

It would have been interesting to dig deeper and try and work out how much of this free web attitude is learned behavior. It's clear everyone expects to pay for internet access, telephony and cable. Is there not scope for 'teaching' people that a lot of the web just cannot be free over time?

If he won't even invest $100 for a mock-up he's not serious about the project, end of.

I was talking about TC, not the hacker. Also, I made it clear that whilst I didn't agree, the question is a valid one.

So that's what the silicon in 'silicon chip' refers to, neat. All I have to do now is work out what the carbon in 'carbon fiber' means...