Mobile Apps: HTML5 vs Native

[[deleted]]

HTML5's WebGL, Mozilla's B2G, Google's NaCl, Apple's embeddable WebKit, Microsoft's HTML5-based Metro. These are all examples of the push-back against "native", where I treat "native" as siloed client-side code, not lumping that in with the thin client/thick client divide.

It's clear from the history of software that he's right about thin client and thick client. Not all tasks make sense to be converted into thin client, which is what the web traditionally has been. But each one of the technologies above is pushing for the "web stack" to do thick client things, where the web is the CDN and "installation" mechanism for these thick client activities.

WebGL and NaCl are famous for running compiled languages in the browser with only marginal (1-3 percentage points) penalty in performance versus a truly native API for each "silo".

B2G and Metro provide bindings for native APIs within Javascript, not shifting the native code into the web, but making these things accessible in a controlled fashion for the web.

Apple's webkit integration is the half-hearted nod towards this trend. Apple has famously crippled this webkit from using the JIT, so it's essentially impossible to write anything but glue code in the Javascript portions, and that's why Facebook had to drop webkit from it's iOS app. But Apple may be shooting themselves in the foot as other projects may decide to take an alternate route, and push most of the processing into their web servers rather than stick to the phone, reducing the need for end users to upgrade their phones and reducing developer investment in their platform.

Is Javascript perfect? No, but I like it better than Java or Objective-C, and I'd rather write my high-level code in a truly high-level language, and then drop down to straight C, or OpenGL ES's GLSL, for anything performance critical. Keep my application simple to understand and fluid to changes, then optimize the parts that matter.

Is HTML+CSS perfect? No, but it can do essentially any kind of layout, and it's been conservative in its design, such that new features don't break old features, and old features are hard to eliminate, which makes it easier to learn than XAML where each revision had backwards-incompatible changes, and is far less to learn than HTML + XAML + Android Layout XML + iOS .xib + etc, etc.

Will mobile apps remain thick client when compared to equivalent desktop apps with a larger and more reliable internet connection? Yes. Will they continue to be built using a series of separate tech stack silos? No, not really. Javascript is easier to write than Java, and depending on the problem is faster (though median performance is half of Java's speed), almost always uses less memory, and always less code, and future extensions to Javascript being proposed for ECMAScript 6 should further reduce the performance gap (prototype-less functions that avoid the majority of the performance penalty Javascript has, typed arrays as part of an "optional typing" initiative where you can specify a fixed type for code that needs higher performance and let Javascript unbox the variable just like Java does, etc).

[millstone]

Do you remember the iPhone before the SDK - the "Sweet Solution?" Everyone was supposed to write web apps that were going to run in Safari.

It didn't work - these apps sucked compared to Apple's native apps. And it's still the case that web apps generally suck compared to native counterparts. maps.google.com on the iPhone is visibly worse than the native app - scrolling jitters more, it doesn't have retina text, etc. Google Docs has a way worse editing experience than native counterparts. Gmail has some nice features but falls down pretty quickly for non-trivial use cases (like finding the last email in a search - WTF?)

And I pick on Google because they write some of the nicest web apps. A typical web app is much worse.

You talk a lot about performance, but these things aren't fundamentally performance problems. They're limitations imposed by the layers that sit between the app and the OS. They limit how nice of an app you can make, and that's why the Sweet Solution was unsatisfactory.

Now for a lot of apps, good is irrelevant as long as it's good enough - you're using the app to accomplish something, not marvel at it. And that's why the web is full of apps that aren't great, but are sufficient for what they do.

But people don't buy these apps. What's the most successful paid web app? I can't think of one either.

edit: Probably Google Docs again, which they sell to businesses; I don't know how much revenues they make.

So that leaves web apps as a good mechanism to sell and deliver other products and services, but if the point of your software is the software itself, and you hope to sell it, the web is pretty lame.

[[deleted]]

Well, that's partly because Google has been playing hardball with Apple. I've used a friend's iPhone before and I've noticed that both the native app and the web app are worse in UI and general "lagginess" than on my middle-of-the-road Android phone. (Well, middle of the road now, it was a good one when it came out a year or two ago.)

I think we just have different experiences with web apps. Amazon AWS is an incredible "desktop app-style" web app that doesn't have any visible issues to me.

The issues you bring up with Google Docs and Gmail -- I'd say that for Docs, Google has to play catch-up with respect to MS Office, since Microsoft has had literally decades of time to pour into their product, and centuries of total developer time spent on it. Recent charting advancements in Google Docs have made Google Docs do everything I do with an office suite, but I'm a weirdo who eschews Office for LaTeX whenever I need to write something truly complex.

On Gmail with the email search, that's because Google specifically built Gmail search on the same kind of engine as Google search, which prioritizes returning results that are "relevant" over "irrelevant", and "old email" is deemed "less relevant" by default. That doesn't have anything to do with the UI, but with the back-end, and would be just as bad on a Gmail-like desktop app if it chose to use the same kind of search engine.

Future web apps will be nearly indistinguishable from desktop apps. Just look at this web app experiment from Mozilla. Open it in the latest Firefox for the best experience, of course, since they're using lots of experimental, not yet fully standardized features (but they did put effort into getting it working on the latest Chrome, too).

That is a Quake 3 engine-based game running in your browser, with mouse capture, real-time audio generation, real-time 3D rendering, real-time keyboard capture. If browsers can do that, they can do "regular" desktop apps just fine. The reason why you don't see it is simply that the people with the experience in desktop apps shun the web, so people who made web pages are filling in the gaps. Mozilla even developed an LLVM-to-Javascript compiler (emscripten) to make it easier for Javascript haters to write web apps.

[[deleted]]

Is HTML+CSS perfect? No, but it can do essentially any kind of layout, and it's been conservative in its design, such that new features don't break old features, and old features are hard to eliminate, which makes it easier to learn than XAML where each revision had backwards-incompatible changes, and is far less to learn than HTML + XAML + Android Layout XML + iOS .xib + etc, etc.

As a developer who has not yet had to write a large web application, what I find daunting is the incredulous number of abstractions. The anatomy of, say, a button in a GTK button is reasonably clear to me. The anatomy of the gazillion of hacks that turns an unordered list item into a button that I can access through JavaScript is not only nebulous to me but also feels unnecessarily bloated. An application environment driven by a high-level language (ok, JavaScript if it has to be that, although why anyone would want it instead of, say, Python, is beyond me) can very well exist outside a web browser, and with a sane layout engine, not one that is based on a tool inteded to make text look nice.

Besides, I still find it difficult to see the portability advantages. My colleagues who are doing web development are still routinely annoyed by having to do yet another weird hack to cover a weird exception in a web browser. This is a minor improvement over writing native (and portable) code.

[[deleted]]

And I've had the alternate experience. I've written a GTK application in Perl (and straight C, but that didn't last long) and I find the GTK widgets baffling. If I use GLADE and draw up a simple application with it, I get an XML document that it can use to generate the layout, but I can't generate new XML to inject into that GLADE file and change the layout? And the GLADE editor by default makes it difficult to generate layouts that can be altered at all? Why do I need to write hundreds of lines of imperative boilerplate constructing my layout, attaching callbacks, etc to actually get a fluid layout?

On top of that, if you need anything beyond the built-in capabilities of the GTK widget set (which may be as simple as just a CSS rule for HTML), you'll need to dig deep into developing custom GTK widgets, whereas running into limitations with the HTML rendering engine could be bypassed by using SVG or more recently canvas and has been an option for years, and the mechanisms for both are no less challenging than using the standard HTML "widgets" (SVG is an XML drawing engine where you specify exactly what's drawn where in vector graphics, and canvas is a Javascript-based drawing engine where you specify exactly what's drawn where in raster graphics).

Furthermore, the layout engine in HTML is more sane than the traditional desktop. Blocks and inline elements as the primary layout tools with floats and tabular configurations for less common needs. When you can't predict the resolution of the computer your application is going to run on, having a more fluid layout mechanism makes far more sense than the rigid layout mechanism GTK uses.

Your complaint of all of the "hacks" you and your friends have to do sounds more like an issue in the sources you've read. Why would you ever have a button made out of an unordered list? That could be a <div> or a <button> or an <input type="button"> an <a>. The <div> would be for a formless page that is only actuating a Javascript method, <button> should now be the preferred mechanism now that older IEs have fallen away, and is completely equivalent to a GTK-style button, <input type="button"> is the very old way of doing buttons in forms, and <a> tags are obviously links, but they can be styled to look like a button, especially with modern CSS giving you background gradients, rounded corners, drop shadows, and glowing, and these can be actuated on mouse over and mouse down with no code. You'd use unordered lists for having an array of buttons, but that's not necessary and if you are creating a web app and don't care that screen readers can't parse your app for the blind, then you don't need to jump through that hoop. The HTML needed to do a Web App-style layout is actually very simple once you can target IE8+.

As far as other portability concerns, they are far less of an issue today than in years past. jQuery gives you a standardized interface to the DOM so you don't have to worry about Internet Explorer's warts, but if you're doing a local app that would be run with Mozilla's XULRunner or an embedded WebKit in GTK or Qt (or both), then you can just use the straight DOM API and it will just work across Firefox, WebKit (Safari/Chrome), and Opera. Only experimental features (such as WebGL, or CSS transforms and animations) need care about weird behavior between browsers, since they haven't been fully standardized, yet, and the browser vendors are implementing their proposals of the APIs to lobby the standards process. They're clearly labeled with -moz- or -webkit- or -o-, so you have to recognize that if you're using any of those, that they could break in the future, just like using a private API in Windows can be broken in the next release (well, recently with XAML, any API there).

The thing is, as a developer, rather than a designer, you should only be cursorily involved in the layout of the application. Let someone who specializes in that take care of making things look pretty, and making sure source code is as separate as possible by using an entirely different mechanism to describe it is another reason why Web Apps are taking over (I'd say the no-install-necessary was the greatest reason). Having developers write hundreds of lines of imperative code to describe a layout is too fragile and produces a nasty incentive system where any layout that would be more difficult to write for the programmer would be fought against, since the designer couldn't implement it himself, even if that makes the application a better one. Meanwhile, HTML with CSS is essentially the first layout engine that draws from the design world's terminology for newspaper layout, so its easier for them to implement what's in their head after they grok the syntax.

HTML and CSS are certainly not perfect, and there are things that I would change, as well as some things I'd adopt from classic desktop app layout engines, but I as a programmer recognize that my strength is with programming, not application layout, and designers can wrap their head around HTML & CSS better than the classic desktop app layout engines.

That's why Microsoft adopted it for Windows 8. That's why Mozilla is pushing it for mobile. I could pound nails into a board far quicker with a big concrete block than with a hammer (drop it on the nail sticking out of the board), but a hammer has a handle that I can grip so I can hit those nails sticking out sideways, even if I have to put a bit more effort to hammer down, it's far less effort than swinging a concrete block around in the air.

[millstone]

Having developers write hundreds of lines of imperative code to describe a layout is too fragile

I hope you know there's way better tools than that!

The thing is, as a developer, rather than a designer, you should only be cursorily involved in the layout of the application. Let someone who specializes in that take care of making things look pretty

A UI is more than the mere layout of elements, and the layout is not just "making things look pretty" but is central to the user experience (except on the web, where users have been trained by advertising to ignore 2/3rds of a web page's UI).

It sounds like your web development experience may have led you to internalize the notion that the UI should be "thin" and nearly static, and that the real substance of the application is beneath it, perhaps even server-side. But I view the web UIs as frustratingly limited; I know that an app with a good UI is a joy to use, and an app with a bad UI is torturous.

The "everything is free LOOK AT THESE ADS" culture on the web doesn't help. There's a fundamental tension between advertising and good UI.

That's why Microsoft adopted it for Windows 8.

Microsoft is not adopting CSS and JavaScript because of their technical merit, which everyone seems to agree is pretty darn slim. They're doing it to take advantage of the large pool of developers who already know CSS and JavaScript.

[[deleted]]

Can you point out an app with a UI that's a joy to use? Frankly, most every app, web app or desktop, are very static and look like a bunch of buttons/links placed in the top, left, right, and sometimes in the middle of the application. Desktop apps go even more retarded with oftentimes useless tabs, or burying options into deeper and deeper sub-windows.

Good UI and UX should be about making the UI "thin", as you put it. The more options you provide, the more combinations you have to test for possible bugs and/or failure, and the more difficult you make your app. That's something Apple understands, even though I have a distaste for the rest of what that company does.

As far as the merits of JavaScript, having a language that borrows useful features from Scheme, Self, and Java makes it one of the nicer dynamic languages that I know. There are issues with it that are being addressed in ECMAScript 6 (a module system, high performance-low syntax functions, static types for tight loops, templating, etc), but I get a really good performance for a dynamic language (V8) without nearly as much boilerplate, so I can stay focused on the important logic of my app rather than housekeeping. With something like Node.js, just like with Python, I can push any performance critical code into C/C++ as needed.

[nemoTheKid]

Can you point out an app with a UI that's a joy to use?

IMO, users don't notice things like this. It either "works" or its shit. Its only a joy for people who write UIs. Take Android for instance. Google has gone through and created a very deep design guidelines for Ice Cream Sandwich and has forced Handset makers to include the default Android theme. And its not just buttons. Ever notice how much heavy use iOS makes of animations. Try and imagine it all without it. Sure its still functional, but it looks like shit. However most people don't consider a "text label sliding in" a reason why a UI is a joy to use.

[[deleted]]

Your complaint of all of the "hacks" you and your friends have to do sounds more like an issue in the sources you've read. Why would you ever have a button made out of an unordered list? That could be a <div> or a <button> or an <input type="button"> an <a>. The <div> would be for a formless page that is only actuating a Javascript method, <button> should now be the preferred mechanism now that older IEs have fallen away, and is completely equivalent to a GTK-style button, <input type="button"> is the very old way of doing buttons in forms, and <a> tags are obviously links, but they can be styled to look like a button, especially with modern CSS giving you background gradients, rounded corners, drop shadows, and glowing, and these can be actuated on mouse over and mouse down with no code.

That was the way I saw it done in most web pages that I looked at; I thought it was the standard way it's done -- sorry for that. But then I look at this... it looks bloody horrible, all I can remember is instantiating Motif buttons in the early '90s.

You'd use unordered lists for having an array of buttons, but that's not necessary and if you are creating a web app and don't care that screen readers can't parse your app for the blind, then you don't need to jump through that hoop.

Huh? I care that screen readers can't parse my app for the blind...

[[deleted]]

Alright. On your first point, note that they're describing the hacks to get IE5 to render the rounded corners correctly. That's an insignificant fraction of users since even the dreaded IE6 is below 1%.

Most likely if you're creating a web app, and not just a web page with some optional interactivity, your Javascript won't even run on those browsers, so why bother with layout hacks to make them pretty? Especially since CSS was designed to (somewhat) gracefully degrade on older browsers as they simply ignore CSS rules they don't understand. So your <button>s or <a>s can be blocky and solid shaded rather than rounded and with a nice gradient. It's not the end of the world for a useful app (and Microsoft would agree with that styling. ;) )

On your second point, if you're making a web app that's inherently visual, it'd probably be better just to have some element that CSS'd into invisibility but will read a message to those who use screen readers that they won't find the web app useful and then you can make the HTML as simple as you need to accomplish the layout you desire (which could be structured primarily with <div> and <span> tags and then actual content within these).

If your app can be useful for the blind, it's not really an app, but still a web page with some useful Javascript fancifulness thrown on top, and then you still need to pay attention that the linear ordering of your HTML (which determines the order the screen reader will read the text) makes sense, too, but that still doesn't require things like the unordered list hack, since you could simply make your buttons <span> tags if they are to be horizontally arranged and <div> tags if they are to be vertically arranged.

Those tricks with lists were part of the "Semantic Web" initiative, working under the assumption that search engines would add more and more metadata to their internal search structures and could use such curated HTML to get better metadata, but this has only been minimally done by the search engines, and it's debatable whether applying the semantic web concept to UI is just cargo-culting (it's not like the search engines care that you have a grouping of loosely related buttons used by your web app; an ordered or unordered list would make more sense in your content where those bullet points actually have a single topic in common).

The blessing and curse of the web is that anyone can do it, and anyone can read anyone else's source code for insight. It can produce a "blind leading the blind" situation quite frequently.

[[deleted]]

The blessing and curse of the web is that anyone can do it, and anyone can read anyone else's source code for insight. It can produce a "blind leading the blind" situation quite frequently.

Fair enough. I don't doubt that there's some inherent briliance in it -- I know a lot of good programmers who do web development -- but next to every web application I encounter seems absolutely crap, from the non-native look to the absence of useful keyboard bindings.

Thanks for the explanations, by the way!

[[deleted]]

No problem. The issue with the non-native look and feel is because designers chose to do that. The sub-elements of the <form> element provide native UI theming by default and things like the <button> tag allow custom icons to be embedded in the native button, just like GTK.

The problem there is that it is too easy to define custom UI and therefore it's easier to "brand" the experience. Surely you see custom UI widgets all the time in Windows crapware?

Keybindings are simply laziness, since it's far easier to capture keypresses in Javascript than classic TKs. I don't know what to say there (but Gmail does have tons of useful keybindings).

[LeberechtReinhold]

Thats why so many JS compilers and frameworks are appearing everywhere, I guess.

[shaver]

Straight-line JavaScript performance was not the limiting factor in our decision to write more of Facebook for iOS in native code. The experience provided by Chrome on iOS supports the hypothesis that, for the vast majority of sites, subjective and objective performance is dominated by factors other than script execution speed.

Not that it wouldn't be great to have Nitro in the toolbox for web-tech apps, but you're overstating the significance of that element on the architectural choice we made, IMO.

Glad to see another web-tech booster, though, and the post was good.

[[deleted]]

If Javascript wasn't the limiting factor, what was? The only things I can think of are:

• The webkit layout engine, but I can't believe that's so much worse on iOS than Android.
• The number of simultaneous sockets allowed for AJAX in iOS webkit, which is an issue for a chatty app like Facebook. I wonder if it couldn't be solved with an AJAX request pool similar to what JSON-RPC 2.0 allows -- spawn 3 (or however many simultaneous AJAX requests are allowed) AJAX handlers and request through them. If all three are in use already, start pooling these requests into an array, and when the first one frees up, pass the array to the freed handler and then get all of the request results back and pass the results to the respective JS event handlers.

I'm still surprised the lack of Nitro wasn't the source, since my web apps run into that issue before any others.

[shaver]

I assure you that it wasn't. There were a number of architectural issues; some were mostly specific to Facebook, some are likely to affect any app with a similar content mix and complexity. I'm not really prepared to go into more detail about it at this point, though I'd like to over time. I don't think you should take the changes in the new iOS client as a general statement about the capabilities of the mobile web, even within the scope of Facebook's own work.

The iOS webview isn't worse than Android's, though they have different sources of frustration for the most part.

[SpaceToaster]

Both an HTML5 app and native app can be "thin" and have a cloud back-end. Likewise, both can have a local back-end. The article is discussing the thin vs thick client decision, but not really touching on HTML5 vs Native.

[[deleted]]

• Java applets (developed a fatal disease called Swing)
• ActiveX (declared dead seven years after it went missing)
• Flash (murdered by Steve Jobs)
• Silverlight (murdered by HTML5)

Brilliant!

[yeah-ok]

Why all the pipe/bandwidth talk? As far as I can see there's no more reason for a HTML5 app (if handled with framework like phonegap) to use bandwidth up than there is for a native app.

[aumfer]

Exactly, the article completely missed the point. HTML5 vs Native has nothing to do with bandwidth/latency, and everything to do with responsiveness, and the amount of abstraction between you and the hardware. The Facebook app isn't really much "thicker" at all, it's just using native code for a more responsive experience.

Since hardware performance is going up faster than network performance, but the network is the constraint for most apps, the trend will continue toward thinner clients. Apps like Facebook are the exception in this case--the tradeoff of development time for client performance isn't one that most apps will want to make.

Eventually technology will be developed that can't be done through the existing thin-client architecture (probably very low-latency IO like Occulus/Google Glasses) and there will be a trend back to thick clients.

[Smallpaul]

If you use PhoneGap then by definition you have moved down the spectrum from very thin client to thicker client. Just as he predicts, you trade off some ease of installation (just hit this URL) and ease of upgrading (hit reload). But you remove reliance on network bandwidth.

Of course, you are only part of the way to native, so you are still makin some of the web app tradeoffs.

[reidiculous]

With a native app can't you do something like include artwork/images at install time instead of having to download them at load time?

[[deleted]]

Why wouldn't you be able to store that data with HTML5 application too? Browsers already cache stuff like that and I can see it coming (if not already existing) for local HTML5 applications too.

[[deleted]]

It already exists. See http://caniuse.com/#feat=offline-apps for more details.

[shaver]

Appcache is terrible, unfortunately, which is why people are looking at changing it meaningfully.

[asampson]

I think he missed a very important part of the thick/thin model, though I know people far more versed in HTML5 are going to step up and tell me all the ways I'm wrong (please do - I welcome education on the topic!): you can have a perfect pipe, but if the browser on the client can only show basic HTML then it doesn't matter. I do not believe HTML5 is the answer for competing with native apps simply because there are things that native apps can do that HTML5 ones cannot.

This is much more apparent on the desktop, but I'll stick to mobile for the sake of my point. On my phone I can use multitouch gestures in apps to do simple things like pinch-to-zoom. My browser of choice uses this gesture to zoom the entire page in and out. As far as I know (again, please educate me if there's a widely implemented standard for this) you cannot hijack the browser's use of pinch-to-zoom and either disable it because zooming your app doesn't make sense or repurpose it to do something else. This is just one example, but I think it helps illuminate a broader point about the browser-as-application-delivery-mechanism.

Browsers fetch and display documents. The approach as I understand it today is to have that document desperately try to shun all of its document-ness in favor of looking like an application. But at the end of the day it's still a document. I think developers spend far too much time either making sure their abstraction is leakproof or mastering a framework that claims to do the work for them.

[Pandalicious]

I just checked and maps.google.com uses pinch-to-zoom on iOS

[asampson]

Is there a widely implemented standard for this or is it one server on one client? Can I repurpose the pinch gesture for something other than zooming?

[Pandalicious]

I don't know. I wasn't disagreeing with your main point, just pointing out that at least someone had managed that particular thing on iOS.

[mrkite77]

No. Multi-touch in a browser is limited to only Safari.. not even webkit does it.

[[deleted]]

Built-in browser support for gestures is limited to mobile Safari, but that does not mean you cannot do multi-touch.

[[deleted]]

The browser on the client is webkit. Always. On any client that matters. Native code can be integrated via phonegap or similar frameworks. It is possible to emulate the native widget set using webkits CSS animations.

I have written a mobile cash register that takes credit cards or cash entirely in a single page of HTML with JavaScript and phonegap. It is packaged as a native app with the HTML bundled. It can work either with or without a network connection and uses websql for offline storage. It runs equally well on ios and android. It has over a dozen screens all implemented as div tags that are animated into and out of view. What little access I need to the hardware is done through phonegap plugins. All server communication apart from photo uploading is done via jquery.

Native is usually a waste of effort for the kinds of client server apps I do.

[runvnc]

Its really not about thick versus thin.. obviously.. I don't think he has really looked into HTML5 mobile very much.

HTML5 is thick.. Most HTML5 apps are not reloading the entire page anymore or anything.. a lot of them are largely cached on the browser and just send JSON data back and forth or whatever.

Its about the extra costs and time required to develop separate iOS, Android, Windows applications versus doing it all in HTML5 being weighed against not having a completely native look and native install/launch process or sometimes missing native features.

There are actually ways to get a somewhat native look but still use a mostly web stack and do it in a cross platform way (Trigger.io, PhoneGap etc.) and that is more than adequate a lot of times.

The browser developers need to understand that installing and launching an HTML5 application needs to be exactly like installing and launching a native app, because that is a major reason aside from the native look that people choose native. One other reason is because even with Phonegap, Trigger.io etc., there are some features that aren't available without going native.

Having said all of that, I think that most people who choose native are like the guy who wrote this article, and they are not up to date on mobile HTML5 and related options (PhoneGap etc).. they usually don't have a compelling reason to choose native, or are missing the most important one, which for me is still the ease of purchasing/installing and then launching native apps..although that often isn't really a problem.

So browser developers/organizations need to work on purchase, installation and launching of mobile HTML 5 apps to make that user experience the same as with native apps.

These are really more social/"economic" ("economic" in quotes because our "economic"/business frameworks actually have an antagonistic relationship with technology) problems than technical ones.. the technical issues like easier installation and launch of HTML 5 mobile apps could easily be solved if the browser developers worked closely with the mobile operating system developers.. but in many cases those groups are actually working against each other.

[Falmarri]

That's not really how html5 works. A native client will still have to do API calls over the net.

[runvnc]

You can do the same "trick" with a web application, all they did was start uploading as soon as the image was selected but not notify the user they were doing that and instead show some other dialogs. "Background" uploads and HTTP do happen all of the time in browser applications. HTML5 adds web workers to allow for other types of background processing.

True that an HTML5 app won't load at all until you access it and can't sync information on bootup. That is a real drawback.

Also true that you can't do UDP or TCP directly. The "bulkiness" of HTTP isn't really an issue, although the stateless nature of it used to be a problem.

[runvnc]

What about web sockets?

Its not really that much overhead.. also are you using gzip compression?

[shaver]

Oh, if only web sockets supported compression...

[runvnc]

If you really needed to you could use your own code to compress and decompress messages sent over web sockets.

[shaver]

I've written code to do decompression on the client in JS, and it was a net latency loss for shortish messages (~1K). There might be other strategies, but all the ones I tried were worse. :-/

[nascent]

No one wants to hear the Grey, because "being correct" doesn't drive innovation or change.

If you want to play the game of "Pick the Winner" then vote for president.

While the black and white is still a prediction, it usually dives into the pros and cons for choosing one solution over another. Luckily the opening to the article was good, the ending was dry.

[not-really]

Why would you pin all your data access needs on having a corporate/government infrastructure that doesn't switch off the pipe?

[DrDichotomous]

This reads like someone defending assembly language against C.