Go native, HTML5 is going to lag for a while

http://blog.suthakamal.com/2012/08/go-native-html5-is-going-to-lag-for.html

by raganwald • 14 years ago

98 94 14 years ago

blog.suthakamal.com

batgaijin• 14 years ago

I can't wait until unlocked bootloaders are the norm and the drivers are open source. The level of artificial stagnation on phones is disgusting and a joke to our profession.

ricardobeat• 14 years ago

    A smartphone today can talk to all sorts of other devices:
    TV remotes over WiFi, watches and headphones over Bluetooth,
    health-sensors and car stereos through dock connectors, and 
    TVs over AirPlay. All this is beyond the reach of HTML apps.

That's almost the entire point of PhoneGap and similar frameworks, exposing these via APIs. He's confusing using HTML/CSS/JS for UI in a "native" app with making a web app.

mcot2• 14 years ago

This. Also look at windows phone 8 and blackberry 10 to see how the web stack can be used for native mobile apps.

focuser• 14 years ago

In a sense, PhoneGap apps are actually NOT Web apps, they are native apps built using Web technologies.

johnx123-up• 14 years ago

No; they're webapps embedded in web browser aka WebView. Refer http://phonegap.com/2012/05/02/phonegap-explained-visually/

tjogin3• 14 years ago

Did you notice the enormous performance improvement in Facebook's app when they moved away from that type of solution to a native one?

kalms• 14 years ago

Some of that was just bad code on their part. Try and compare it to LinkedIn's app instead. As far as I know, that's HTML5.

SunboX4• 14 years ago

That´s really wrong! Facebook still uses a lot of HTML5 in their new App! But they fixed a lot of bugs, mainly removed a lot of concurrent UIWebViews. For more information, take a look at:

http://www.vasantkumar.ca/2012/08/native-vs-html5-why-facebo...

But simply saying "They removed HTML5 and all works a lot better" is very wrong.

bgarbiak2• 14 years ago

Facebook did a lot of harm to the reputation of HTML5 with that app. Sometimes it took a few minutes to render comments for a photo or an user profile or a few items on a news feed. Of course, DOM/CSS/JS is slower than native - but it doesn't have to be THAT slow. Especially for what seems like a relatively simple things. I suspect they overengineered it a bit.

suthakamal3• 14 years ago

(I wrote the original blog post.)

You're right that things like PhoneGap give access to native features. However, the Native-API-implementations in these frameworks are 1) typically significantly behind the native OS (release date) 2) tend to have less-than-feature-parity

So, often you're stuck writing your own native bridge, or tweaking the portability framework's version, which is time wasted (IMO) vs writing to the native framework. As an example, just try and write a PhoneGap app using Bluetooth: The Android implementation is incomplete, and the iOS version is non-existent.

Also, there are a tonne of performance issues you run into with the HTML/CSS/JS + Framework + Native solutions. As a thought experiment, consider how you'd build Instagram in one of these frameworks.

1) Image filters in HTML/CSS/JS land? Slow. 2) Thousands of images in a continuous virtual scrolling window in HTML land? Slow. 3) Fetching a binary blob (the image) from the OS, and throwing the resulting blob back-and-forth to web-land (for example, to use HTML5 offline storage) ... hellish slow.

Compare that to native... it's just one example of where the theory of HTML for UI and native for logic breaks down when you start to push the platform a little outside it's comfort zone.

bad_user• 14 years ago

I don't know the challenges of building a web-based Instagram, however I am a long-time user of Flickr, with which I manage a huge collection of personal photos.

The Flickr web interface definitely needs a modern browser (Chrome or the latest Firefox), otherwise it will choke from time to time, however that's to be expected when you're basically playing around with 10,000 photos. For me it does a spectacular job, more so than some native apps I tried (granted, I never tried Adobe Lightroom).

     Thousands of images in a continuous virtual scrolling 
     window in HTML land? Slow.

You can use the same tricks you'd use in a native app, such as loading only the thumbnails that are currently visible in the user's window.

scriptproof• 14 years ago

I suppose with Node installed, and HTML used for the interface, these speed issues will be resolved. But perhaps (I do not know) iOS prevents installing this tool.

marknutter2• 14 years ago

You are criticizing HTML5 far too broadly. Yes, it may not be the best choice for building a game, or a photo heavy app. But it's good for building mostly text based apps, which represent the vast majority of the (mostly crappy) native apps out there.

simonsarris• 14 years ago

"Early birds get the worm, early adopters get the shaft" to paraphrase my brother.

But we all need early adopters.

Sure HTML5 isn't ideal yet. Writing multiple apps for separate platforms to do the same damn thing on different devices isn't ideal either, though. Unless you want to take one on principle I think its almost too context dependent to bother wage a conversation over it.

I think that the conclusion of this blog post is all too broad and so circumstantial that the title seems a tad silly. It amounts to something that everyone already knows. He gives an NB in the middle of the article that amounts to "of course if your app works well with HTML5 then you should use HTML5," and before that he mentions that native apps have more functionality (sensors/webcam/etc).

If you like the idea of a native web and you can make your app practical today in HTML5 then I think you should. On the principle of it I agree with the actually-pretty-butchered[1] Gandhi quote, "Be the change you want to see in the world."

~~~

For more talk on the topic see Paul Irish's post from the other day. It's not a rebuttal, more of a plea for HTML5 instead of native, but I found it and the comments interesting:

https://plus.google.com/u/0/113127438179392830442/posts/fR3i...

~~~

[1] From a NYT article: The closest verifiable remark we have from Gandhi is this: "If we could change ourselves, the tendencies in the world would also change. As a man changes his own nature, so does the attitude of the world change towards him. ... We need not wait to see what others do." http://goo.gl/S29tx

azakai• 14 years ago

> WebGL is cool, but [..] the kind of graphics performance a developer can get by writing straight OpenGL (taking advantage of sophisticated shader models on more recent devices) is astonishing

Why can't you get the same performance with WebGL shaders? Yes, WebGL GLSL adds some security checks, but apparently they only add about 5%. The article here seems to assume there is a huge difference - I'd be curious to know what that is based on.

Is it new shader models not present in WebGL GLSL? If so, specific examples would be appreciated.

edit: expand the question

daeken• 14 years ago

In current implementations, the shaders running through WebGL are identical to those that are not (outside of ES vs desktop changes). However, there are a couple problems:

1) There's definite overhead on the API itself, e.g. the slow shader compilation times due to the verification, translation, etc. That'll get better over time, but it'll never match the desktop; I personally think a caching approach will be a big win here, but no one has done it yet.

2) You don't have geometry shaders, hardware tessellation, hardware instancing, and a number of other features you get on the desktop with modern hardware. You also don't get the ability to render to multiple targets at once (critical for performant deferred shading).

3) There's significant 'extension lag' as it isn't as simple as just implementing an extension on one chip and coding for that; it has to hit a certain level of penetration before it'll be ratified for inclusion in WebGL, then it has to be made safe and implemented.

Those are the core things holding WebGL performance back (IMO), excluding other browser bits that may get in the way, which aren't relevant to this discussion directly. A lot of this will go away over time, but I honestly have no idea how any of that will happen.

(Disclaimer: I work on graphics stuff for Mozilla, but don't work much on the WebGL side of things; mainly write demo code there)

khuey• 14 years ago

I'm slightly amused by one Mozilla employee responding to a question posed by another Mozilla employee with a disclaimer that they work for Mozilla.

sbooks• 14 years ago

Couldn't agree more. We have seen this recently with the Facebook app switching to native. I think as time goes on, and as phones get more powerful, it will mean less of a difference, but for now it is better to stick with native. We decided this for our iPhone/Droid apps at http://trackmydrive.com and couldn't be happier!

epic9x• 14 years ago

Regardless of whether or not HTML5 is going to "lag", I think this article white-washes the evolution of the web as an open platform vis-a-vis the desktop/OS. Open platforms and protocols are the result of hard work and people taking risks and building value, not a result of stability in the platform.

The Web and technologies have operated in a disruptive manner with respect to an established platform, and the mobile revolution was about the platform moving to serve modern, networked users. The is counter to silo'd interests attempt to constrain and integrate the web into proprietary formats and platforms (See: everything from active-X/flash to the current mobile platform wars).

suthakamal3• 14 years ago

(I wrote the original article.)

You're absolutely right about open platforms and protocols being about lots of people taking risks and building hugely valuable things. My point was that when the core OS is innovating like mad, you need to be close to those OS's to build the best apps... The innovation on the desktop slowed to a crawl years ago, and the majority of innovation has moved to the browser and web-app layer. In mobile, however, there's a LOT of innovation still happening right at the OS level w/ Android and iOS, and so all the frameworks that exist above the native SDK's are going to lag, and not take best advantage of the innovations being released at the OS layer.

The speed of mobile OS innovation will invariably slow (like it did on the desktop), but until then, philosophy about open platforms aside, iOS and Android show no signs of being displaced as the real mobile OS / platform drivers... and so, native's going to lead HTML5 / other "open" platforms for a while.

ericxtang• 14 years ago

What about things like Titanium or RubyMotion? They compile to native and allow you to have a "unified" code base.

prpatel5• 14 years ago

I'm not sure about RubyMotion, but I can speak to Titanium as we use it to build our TripLingo language learning apps.

Appcelerator Titanium does not compile down to anything - rather it bridges a JavaScript runtime to the native layer: either iOS or Android. It's not as fast as coding in ObjC or Android Java, but we see performance which is very close to that of native and have the entire underlying native SDK available for use.

suthakamal3• 14 years ago

(I wrote the original article.)

These frameworks typically just allow you to wrap native methods with JavaScript... so you're not really writing to a single cross-platform code base. Morever, if you can build your app entirely in the HTML/JS/CSS side of things, you're golden... as soon as you start to bridge between the Native and JS layers, things get messy (and often very slow).

prpatel5• 14 years ago

What? You make no sense. In your original article you advocate going native for now and eschewing Web tech. Now you say that "you're golden" if you use Web tech? Then you top it off by saying bridging down to native is slow.....

Are you just talking out of your ass? Have you actually built an application using Ansca Corona, Ruby Motion, or Appcelerator Titanium? Have you built a published native and Phonegap app to the Android or iOS store? Well, I have done all of these - and I even speak about it at conferences[1][2]. I can safely say you have no idea what you're talking about or you are pushing a hidden agenda.

[1] http://lanyrd.com/2012/lone-star-symposium-austin/stbht/ [2] http://lanyrd.com/2012/uberconf/stcdt/

Zigurd3• 14 years ago

These technologies live in a very narrow space:

1. If you are delivering information that wants to be accessed everywhere, write a Web app

2. If your users want the richest interactive experience, write platform-specific apps

3. For everything else, use proprietary multi-platform app SDKs.

What is "everything else?"

ender7• 14 years ago

Sadly, Apple and/or Google have the power to retard the adoption of HTML5 as long as they like.

"But ender7," you say, "both Mobile Safari and Chrome have great support for HTML5."

Yes, they do. Sort of. Except for the crippling bugs in many of their implementations. Some of these bugs render the APIs in question essentially useless on mobile. Or just a giant pain in the ass to work around. Or have performance issues so large that they are impractical for non-toy purposes.

How quickly these bugs (and perfomance issues) get fixed will have a huge effect on HTML5 vs. native adoption. So far, this seems to be happening at a rate of "meh". For example, iOS 6 finally fixed the bugs in its HTML5 History API that prevented anyone from using it in a real product. But they did fix it. It only took...a few years.

callahad• 14 years ago

> Sadly, Apple and/or Google have the power to retard the adoption of HTML5 as long as they like.

I'm hopeful that Firefox OS and Firefox for Android will be able to exert competitive pressure in the HTML5 app space, but it will still be a long, hard slog.

chc• 14 years ago

Realistically, though, Google have always seemed to view HTML5 as being a very good thing, since the Web is their bread and butter. Android seems to be more of a hedge against other vendors' platform dominance than an attempt by Google to lock everything down -- thus why Google actually exerts little control over Android distribution.

And I can see a good argument for blocking the open Web being in Apple's interests, but again, historically they've been going as fast as anyone else. They might not move as fast as I'd like, but they're not lagging.

akldfgj• 14 years ago

Which browser is the shining beacon of light for HTML5?

monsterix• 14 years ago

I kind of like Dolphin browser on iPad; have been playing with it for sometime. It kicks Safari's ass big time, except for the no_file_upload option the web standards' way.

I've seen a couple of posts from people comparing iPad's Safari with IE6 (although, Safari has been improving in past few releases...) so not sure which is the favorite browser for people on iPad.

bgarbiak2• 14 years ago

Personally, I have high hopes for IE10 and its supposedly tight integration with Windows Phone 8.

SunboX4• 14 years ago

It´s mobile safari. I can´t understand, why chrome on android performes this bad compared to mobile safari. :( On desktop it´s the opposite. :?

knitatoms• 14 years ago

The new version of Firefox on Android is fantastic.

josteink4• 14 years ago

On Android, you can install updated browsers like Firefox and Chrome.

Not sure about how well their mobile counter-parts actually support HTML5, but at least you have a choice for a non-system-supplied browser.

On iOS you are, as you say, SOL because Apple has literally crippled the options you have down to one: The one they supply and update, once a year.

recoiledsnake• 14 years ago

>On iOS you are, as you say, SOL because Apple has literally crippled the options you have down to one: The one they supply and update, once a year

Especially egregious given Steve Jobs' memo about not supporting Flash on iOS.

http://www.apple.com/hotnews/thoughts-on-flash/

Some choice quotes:

>Though the operating system for the iPhone, iPod and iPad is proprietary, we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. Apple’s mobile devices all ship with high performance, low power implementations of these open standards. HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member

> If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript

>New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind

It's been two and a half years since that, and still HTML5 has major issues. Given Apple's engineering prowess, I doubt that HTML5 is a priority for them, or else they would've had a great implementation by now.

They know that all the apps in the App Store serve as excellent lock in against Android, Windows Phone and RIM. Why make it easier for people to switch instead of dragging their feet with a small update every year?

SunboX4• 14 years ago

> On Android, you can install updated browsers like Firefox and Chrome.

But these Updates won´t affect UIWebViews :( (hybrid apps)

rimantas3• 14 years ago

  > How quickly these bugs (and perfomance issues) get fixed
  > will have a huge effect on HTML5 vs. native adoption.

Hardly. I say that as a guy who've spent more than a dozen years making web. HTML does not scare me, I like CSS and can do fancy stuff with it, I have no problem with JavaScript.

I am moving however to Objective-C and Cocoa world. It is so clean and tidy compared to the mess the web technologies stack is. And no matter how great support for HTML5 will be, no matter how performant it becomes—it will be well adopted and very performant mess. We can bring in frameworks and libraries, duct-tape things together, but we are long past the point where we could get rid of all the ugly heritage.

My feeling is, that web technologies will be used mostly for the content leaning apps, and for "apply" the native will be a clear choice.

Then there is this "cross-platform development" thing. Well, not sure about this one. I guess we are bound either to have mediocre solution for all, or bite the bullet and do native for each platform if best results are desirable.

mtgx• 14 years ago

Not to mention Apple willingly holding the JIT from being used in the embedded browser.

DigitalSea2• 14 years ago

Lets get this straight, the limitations in performance on Mobile Safari are very much deliberate limitations. Do you seriously think a company like Apple who gets a pretty large chunk of app store sales is going to let something like HTML5, CSS3 and Javascript steal it's profits away? Fat chance.

Although it even rings true for desktop browsers not being able to perform as optimally in regards to some HTML5 features work, Apple can and could do more to improve HTML5 support but won't for the foreseeable future until it works out how it can control and monetise HTML5 (which it can't and never will).

People are quick to point out Facebook ditched web and went native because of HTML5 limitations which I believe is a lie. It's been rumoured that Facebook is going to be deeply embedded into iOS 6 like Twitter got in iOS 5 and one of the requirements would obviously be to have a native application.

The Facebook app I believe was slow because of one key issue: 37 requests, 491kb. That was the problem, of course that many requests and large size is going to be slow for users on congested 3G networks.

Case in point of just how well a web app can run is LinkedIn's iOS app. It works the same way as the Facebook app used too. It has a Node.JS backend and uses a web wrapper to load it in, they even wrote up a blog post about how they squeezed every ounce of performance out of the web UIView and I think it works well.

I'm not one to believe in conspiracy theories without solid facts, but in my opinion the move to native by Facebook was a strategic one on Apple's end. Apple knew Facebook were the poster-child for HTML5 web applications that could run without relying on the almighty iPhone operating system, so throw them an integration bone and ask them to go native in hopes that others do the same and ditch HTML5 as their first choice for an app and many people will follow.

needle0• 14 years ago

"It has a Node.JS backend and uses a web wrapper to load it in, they even wrote up a blog post about how they squeezed every ounce of performance out of the web UIView and I think it works well."

Can you give a link to that blog post? I took a quick look at LinkedIn's corporate and developer blogs but couldn't come across it.

DigitalSea2• 14 years ago

No worries Needle, check out these links.

http://engineering.linkedin.com/testing/continuous-integrati...

http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-1...

The first link is the one I referenced in my comment RE: Node.JS and heavy HTML5 optimisation. Other people who haven't seen them might find them interesting as well.

modernerd• 14 years ago

Related HN discussion here: http://news.ycombinator.com/item?id=4153599

This presentation from LinkedIn's Director of Engineering is worth watching too: http://www.youtube.com/watch?v=hMd45Ij2DYQ

Also see this piece from Venturebeat: http://venturebeat.com/2011/08/16/linkedin-node/

muyuu• 14 years ago

It's also unsurprising that FB would rather not benefit the Android platform more than strictly necessary.

iosdev• 14 years ago

The Facebook integration in iOS 6 (Beta 1 through 3) functioned perfectly well prior to the launch of the (non Web view) native FB application.

cek• 14 years ago

Apple makes almost no money, in relative terms, from app store sales (about 1% in '10)[1].

The business of running the appstore is not the reason they will never fully support cross-platform mobile development.

The real reason is websites that run as apps break Apple’s strangle-hold on their walled garden. Apple's business model is to sell devices via a tightly controlled channel (read few middlemen) at a high-margin; getting paid up-front when the device is purchased. Those high-margins are partially possible because of the value ascribed by customers to the uniqueness of variety & volume in the appstore combined with it's friction-free nature.

WORA is a pipe-dream. Has always been. Always will be. Meanwhile developers continue to suffer because there are enough 'popular' platforms that they have no choice but to do cross-platform development.[2] Sadly, this is just reality; I do not believe there will ever be a silver bullet.

[1] http://news.cnet.com/8301-13579_3-20008540-37.html [2] http://ceklog.kindel.com/2012/07/24/apps-must-be-cross-platf...

TheFuture• 14 years ago

App Store profit for Apple is a rounding error on their balance sheet.

Selling phones (and tablets) that can do amazing and powerful tasks is what makes Apple money. That's why they have invested so much into creating the iOS SDK, to enable developers. It is a fantastic platform, elegant and powerful that leverages their hardware.

If Apple could have gotten that same quality of software with web apps, why wouldn't they have chosen that as the platform and immediately have had millions of web devs ready to build for their mobile OS?

What the HTML5 evangelists fail to admit, is that HTML5+JS+CSS is a damn mess. We've been hearing for 10+ years how web apps are the cross-platform silver bullet. It's not.

EGreg• 14 years ago

The biggest obstacle to using HTML, in my opinion, is horrible scrolling support on Android mobile websites. In general, Android's scrolling is ehh (not sure why they don't make it as good as on the iPhone), but on MOBILE SITES it's just really bad.

And for overflow: scroll areas, even using iScroll or your own implementation runs into simple bugs, such as: quick swipes make the document scroll no matter what you do!

trollforce• 14 years ago

Thought it was about golang at first, got my hopes up for something that actually matters to me.

natmaster• 14 years ago

Or use Firefox.

confluence• 14 years ago

HTML5 isn't ideal yet - but it is getting there (see link):

http://arstechnica.com/science/2012/09/pong-gets-a-physics-b...

Everything is set up for HTML5 to take off. Google doesn't really care about "app markets" so they are strongly incentivised to disintermediate the app stores via a triple threat of native speed JS (V8/Native Client) in Chrome, the Chrome Web store (listing of websites really) and the relatively free and open Android market (this is Microsoft's 80-90s strategy against Apple all over again).

Microsoft wants people to get off Obj-C Apple native app programming and onto HTML5 with Windows 8 - and they, along with Mozilla, have aggressively been pushing into native mobile HTML5.

Apple doesn't want HTML5 to win (flash wars aside). They need to keep apps locked and native since anything else will erode their competitive advantage (which neither Mozilla/Google/Microsoft care much for - since they don't do hardware).

HTML5 will come.

Question is will OnLive-esque video streaming win out in the end. I'll bet it'll be a mixture - with streaming for really hard core things and HTML5 for basic casual games/CRUD apps/low latency stuff. We might even go all video - I don't really know.

But it's gonna be awesome!

D_Guidi• 14 years ago

the author doesn't think about the fact that small companies simply can't "go native". there isn't only facebook and google, out there.

jmitcheson• 14 years ago

Saying HTML5 won't be 'production ready' for a while, and saying that HTML5 will never be production ready are two very different things, but I feel people conflate the arguments all the time.

If you do believe that HTML5 will eventually be production ready, even if not for another 2 years, ask yourself this: when that time comes, do you want to be the guy with 2 years experience or the guy with none? When the industry is ready, 'HTML5 developers' are going to be all anybody wants and they'll want them all right now. If you want to jump on a moving train carriage then you have to start running towards it very early...

goggles992• 14 years ago

When the time comes? Do you think that this would be a well defined time? Will someone declare it 'Production Ready' one day? It is going to be a very slow transition (painfully slow). Once most thing are transitioned, other technologies will be so far ahead that 'web applications' will no longer exists. Content web sites will always exist, but not applications.

rimantas3• 14 years ago

I am guy with more than 10 years experience, I am on WHATWG list since prehistoric times, when HTML5 was still called "Web Applications 1.0" and I will gladly use it for web content, but for mobile applications I choose native.

Thomaschaaf• 14 years ago

If companies like apple would not restrict non-native apps to only use the slower JS engine I think a lot of performance issues would go away. HTML5 should almost always be enough for most usecases such as chats, shopping apps, award apps etc. If an app is restricted speedwise to an IE 6 type of Javascript engine and HTML5 Apps heavily use Javascript. The problem aren't the Apps but the JS engine powering these apps.

olouv• 14 years ago

The author is wrong, you can build up a HTML5 app and use everything that a native app does (using PhoneGap/Cordova & custom native bridges), so that is not the point at all in the HTML5 vs. native debate.

To me the real issue is will Apple & Google keep holding their browser perf because hybrid mobile dev could hurt their profit & often breaks UI guidelines.

deepGem• 14 years ago

I really hope Firefox Mobile addresses most of the HTML5 pain points and go live on Android and iOS. We badly need a neutral, open browser on mobile.

equark• 14 years ago

A lot of comments suggest that Apple and maybe even Google are deliberately keeping HTML5 performance subpar. I think this misses a key fact: Google has struggled for years to make native Android apps match iOS performance, even for simple things like scrolling a list. The fact is Apple set a standard with iOS that is incredibly hard to meet regardless of the technology.

The conclusion is sound though. Companies that build mobile apps using HTML5 in 2012 will almost certainly face the fate of companies that built web apps using Java applets in 1998.

chj• 14 years ago

Let's face the reality. THe HTML5+CSS3+JS is over complicated. It's not going to stop lagging for the same jobs that native apps can handle well. Not even your computer is sped up 2x. Because native apps will always make it look bad.

However it should be fast enough for ebook production, if the typography is done right.

sil3ntmac• 14 years ago

Don't generalize. The reality is that for certain apps (esp. simple, data-driven ones a la ebooks), web is certainly not overcomplicated, and in many times can be nearly indistinguishable from a native app. And it is -- albeit slowly -- getting better.

goggles992• 14 years ago

Overrated they call it in sports, overhyped they call it in economics, overgeeked I call it in the hacker world.

Those of you surprised that HTML5 may not soon (if ever) be the holy grail have been drinking too much cool-aid.

_urga• 14 years ago

One way to help is to ask for lower level OS apis to be exposed by browsers, so that the open source community can do the rest:

1. Ask for UDP to be exposed to trusted web apps installed by the user. This will let the P2P community race ahead without having to wait for WebRTC to get released and then fixed.

2. Ask for TCP to be exposed to trusted web apps installed by the user. This will instantly enable things like SMTP clients running in the browser without the need for WebSocket proxies/proprietary gateway servers.

3. Ask for POSIX to be exposed to trusted web apps installed by the user. This will lead to an explosion of database innovation in the browser. IndexedDB is design-by-committee. Insist on proper POSIX not the FileSystem API. Borrow from the Node API. Impedance mismatch is crippling browser storage.

4. Low-hanging fruit: ask for LevelDB to be exposed directly (http://code.google.com/p/chromium/issues/detail?id=128865). Most of the browser vendors are using LevelDB underneath IndexedDB, and just exposing LevelDB directly would already be a huge leap forward. No need to wait for the many IndexedDB bugs to get fixed by browser vendors.

Browser vendors are trying to do too much. Innovation needs to move from top-down to bottom-up. Browser vendors need to provide just basic access to bare metal and let OSS do the rest. UDP, TCP, POSIX would be a great start.

mikecane• 14 years ago

I've read all the Comments and at the time I'm writing this, I'm scratching my head because I don't see a single mention of Open webOS. Have all of you written it off or is it just too early to be on anyone's radar?

prpatel5• 14 years ago

IMO there's too much uncertainty over WebOS. There's no real deployment of these devices (dwarfed by even Windows Phone at this point), the helter-skelter handling of killing it and bringing it back has scared people (thanks Apotheker for coming in an destroying WebOS and HP in general!), and a roadmap that hasn't unfolded yet.

sonnenkiste• 14 years ago

Why is Apple's App-Store App build with HTML? I really don't get it. Why did Apple favour HTML instead of Objective-C?

darkstalker• 14 years ago

I would say Go native, HTML5 is going to lag forever, since even on a modern desktops, the performance of HTML5 is way behind native apps. Besides that, HTML5 is an amalgamation of technologies that feels awkward to use for someone who has wrote native apps. I would like to see something like XUL added to HTML5, so you can write web interfaces in a more sane way.

marknutter2• 14 years ago

Are we all forgetting why people build web apps in the first place? It's not about performance.

its_so_on• 14 years ago

going native is like going skinny-dipping. a lot of freedom and exquisite possibilities, but with it comes responsibility - and you can easily get yourself into trouble.

erichocean2• 14 years ago

Go native, HTML5 is going to lag for a while

This is true for most developers. I don't think it's true on the leading edge of HTML 5 development, but it's true that the existing MVC libraries really aren't there yet, and if anything, are asking the wrong questions.

It'll be awhile before HTML5 application development is a viable option for your average dev team just wanting to get a product out the door.

Zigurd3• 14 years ago

I do not believe this debate will ever be fully resolved one way or the other. That is, there will always be things Web sites/apps are better for: Delivering free-form, multimedia information, especially when frequently updated. Or for relatively simple apps that benefit from pervasive access.

There are also things that OS-specific apps are likely to be better at for many years to come: Apps that operate in the background without using a lot of battery power, and interactive apps that manipulate and organize information and benefit from the richest and most responsive user experience that is integrated with OS features for information and device resource sharing.

OS innovation hasn't stopped. App development for iOS, Android, and Windows 8 hasn't even fully probed what those OSs can do for app developers in creating apps that work together. And the OS developers have not stopped improving their app APIs. They all have different approaches to interaction and application architecture, especially inter-app communication and cooperation.

So not only will we see a continuation of platform-specific apps, we will see a lot of innovation in what those apps can do on different platforms, and a richer expression of the differences between platforms.

"Write-once run everywhere" has zero value to the end user. They want the best Facebook/g+/Twitter/whatever experience possible on the platform they use.

kybernetikos• 14 years ago

> "Write-once run everywhere" has zero value to the end user. They want the best Facebook/g+/Twitter/whatever experience possible on the platform they use.

Exactly, and if Mr Enduser X can get it on his weird platform because it runs HTML, that's a massive piece of value to him.

Also, while he wants a good experience, he wants it to be free too and the cost in building and maintaining multiple codebases for client libraries would certainly get passed on to him one way or another.

Zigurd3• 14 years ago

That argument is a little circular. If a platform has significant market share, apps get ported to that platform. If not, it doesn't matter.

Before there were Web apps, all software makers wrote apps for multiple platforms. Porting to a platform has a cost, but, for a successful software company, not a relatively large cost. Even unprofitable platforms are likely to be supported by some software makers as a way of erecting barriers to entry, or to speculate on the future success of that platform.

Users will expect all the features of their platform to be well-supported in their apps.

ucee054• 14 years ago

Mobile apps will be preferred over web apps until mobile internet bandwidth is cheap and abundant.

Go native, HTML5 is going to lag for a while

Related Stories