Tag: HTML5

Why U.S. Developers Prefer iOS to Android

This is one of the best cases I’ve seen made for why mobile app developers in the U.S. ought to and do prefer the Apple iOS platform to the Google Android base despite the fact that worldwide, Google has an 85% share. It echoes what I’ve said several times in the past but does it more succinctly and with more current data.

While I remain a firm believer that HTML5 is the true Platform of the Future, for those apps that need OS-level feature access, this advice could make the difference between a successful software company and one that flounders on the rocks of fragmentation.

 

Matt Asay Misses the Boat Entirely on HTML5

Matt Asay just added himself to my List of Tech Columnists Who Shouldn’t Be Allowed to Have Their Own Columns.

HTML5 LogoIn a ridiculous piece on TechRepublic, Asay gets it so totally wrong about HTML5 that I had to shake my head a couple of times and wonder if he was actually conscious. Maybe he’s just a Click Baiter (the headline, after all, was almost as stupid as the piece itself: “HTML5: Doomed to Fail or Just Getting Started?”

Neither, you moron! It is well established, in increasing use every day and the fact that you can’t see that suggests that you are a cave dweller.

Now, maybe — maybe — Asay means to confine his remarks only to the mobile development space. Which begs the question why his piece is slugged “Web Development” and he never once specifically says he’s focused only on mobile. But in the context of the overall theme of his piece, one could conclude that he’s only considering mobile. Even there, his conclusions are outlandishly uninformed.

In two minutes of searching, I found a blog post that lists no fewer than 16 major media, publishing and related sites and services who have jumped on the HTML5 bandwagon:

  • Hearst Publishing
  • New York Times
  • Wall Street Journal
  • Popular Mechanics
  • YouTube
  • Vimeo
  • Viacom
  • Pandora
  • Slideshare
  • Disney
  • HBO
  • Nickolodeon
  • Progressive Insurance
  • Salesforce
  • Amazon
  • W3C

In addition, the auto industry has been adopting HTML5 broadly and deeply, and all of those apps are mobile in nature. So much for Asay’s stance on mobile.

Do a Google search for “HTML5 adoption” and check out the dozens and dozens of articles that have appeared in the past year alone about the subject. All you can conclude is that this is one tech columnist who is just dead wrong on a very important issue. The problem is that by being published by TechRepublic, he gets a big audience to listen to him regardless of his being right or wrong.

Check Out These HTML Tags Just for Picky Formatters and Writers

I haven’t seen a lot of chatter in the HTML5 world about some new tags that are designed for people who are a bit more meticulous than most about how their text is formatted on their Web pages. I found this collection of six tags interesting and not a little weird in some ways. (Note that only two of these — mark and wbr — are new in HTML5. The “s” tag has been undeprecated (is there such a word) and given a new job. The others existed in HTML4 but I never saw them used so I threw them in here anyway.

(Depending on your browser’s support, the examples shown with each tag may or may not work. The links to the W3School site where there is an editor that allows you to try these yourself might be more useful in that case.)

Note, too, that you can use CSS as usual to format the output of these tags any way you want.

  • del

    strikes through (deletes) the text between the tags, as in: I know I said blue, but I meant red!

  • ins

    inserts the text between the tags, underlining it to depict its insertion. Here’s the above sentence, with “red” enclosed in ins tags: I know I said blue, but I meant red!

  • mark

    highlights the text, by default in yellow (but of course you can use CSS to change this). Example: I want to draw attention to the previous two words.

  • q

    instructs the output be placed between quotation marks, as in: I was sure you said, Leave me alone! Perhaps I was wrong?

  • s

    instructs the output to be struck through, or lined out. The third and fourth words of this sentence are lined out.

  • wbr

    is a weird one. It is useful when you have a really long single word as often crops up when you are writing programming language documentation. By inserting the empty wbr tag at appropriate points in the string, you give the browser permission to break the string if necessary when wrapping words. The next line should help you understand this.

    Nowisthetimeforallgoodtocometotheaidoftheparty.Nowisthetimeforallgoodtocometotheaidoftheparty.Nowisthetimeforallgoodtocometotheaidoftheparty.

Auto Industry Leaning Toward HTML5 vs. Native

As the auto industry quickly becomes one of the largest marketplaces for Web-based applications, its development teams are reproducing — and re-fighting — the HTML5 vs. native approach to app development. It appears that HTML5 is trending at the moment.

According to VentureBeat, “For the automotive industry, HTML5 helps automakers meet several goals: draw in potential buyers by delivering the content and capabilities they want now and in the future; keep pace with release of new consumer devices, applications and services; and deliver a quality app experience in their vehicles with the capabilities and content consumers now expect while keeping costs down.”

The article points out some of the drawbacks of HTML5 (though it exaggerates one or two of them a bit), but it concludes that, “For developers creating in-car applications, HTML5 is perfect.”

HTML5 LogoAs this decision is made and re-made hundreds, perhaps thousands, of times daily in a broad range of industries, the fact that it is a use-case situation continues to arise. Most apps lend themselves well to HTML5, write-once-deploy-everywhere, strategies. But where an app involves “sophisticated algorithms, complex data manipulation, or those using heavier graphics,” a native app is probably a better solution for the moment.

But I think the current trends suggest that the approach ought to be to choose HTML5 as the initial default and only switch to native if it can be demonstrated or proven that it’s genuinely too slow. Development managers should require their app development teams to convince them of the necessity of going native before they’re allowed to switch from HTML5. They also ought to require initial prototyping at least in HTML5 so that the decision to move to native is made on the basis of actual code working on an actual system and demonstrating inadequate performance in user tests.

Big News! Amazon Opens App Marketplace to HTML5 Products

html5logoSome big news hit the HTML5 universe yesterday when Amazon.com announced it would begin carrying HTML5 Web apps in the same store where it now sells native Android mobile apps. I predict this will have a major impact on leveling the playing field between native and Web apps and making the latter more likely to achieve the success I think they so richly deserve.

Web apps, once approved by Amazon, will appear in the Amazon AppStore right alongside native apps. Amazon is also offering some tools to support making apps promote well and includes a JavaScript technique for doing in-app sales. This will encourage a lot of Web-based game apps that sell virtual goods inside the games to broaden their distribution.

Before this announcement, marketing a Web app was a hit-or-miss proposition. Most developers promoted and provisioned their own sales. (See here for more.)

As a Web app fanatic, I’m delighted with this turn of events. And I suspect this will force Apple’s hands meaning that we will someday soon seen Web apps sold through its AppStore as well even though there are some brand-protection reasons for them to avoid taking that step. As Web apps outpace in number and other key ways their native counterparts, Apple will either accommodate the trend or be curtailed by it.

You go, Amazon!

HTML5 is Not Inherently Limiting: Blackberry

Blackberry and Sencha have teamed up to upgrade the soon-to-be-upgraded Blackberry 10 theme so that “developers will be able to create HTML 5 apps that are “nearly indistinguishable” from native Cascades apps.” Saying that, “web technologies are not in and of themselves limiting,” the firm is now working on optimizing performance.

While these statements in an article in Dr. Dobbs are clearly self-serving and a little dubious, the core idea that the HTML5 technologies in and of themselves need not be as limiting as they’ve been portrayed rings true. Blackberry refers in its release not only to performance but also to native UX emulation. It says it has managed to make all user controls look indistinguishable in Web apps from their native counterparts, for example.

This is just another reason I continue to believe that it is not impossible to see Web apps becoming at least equally important as native apps as the world of smart mobile devices continues to grow by leaps and bounds, creating more and more demand for apps.

 

If HTML5 Apps Will “Always” Be Slower, Does That Mean They Lose Out?

Scientific reasoning strongly suggests that Web apps will likely always be slower then native apps because of the constraints on hardware and how those limits affecting the performance of smart phones. This article by Jon Evans at Tech Crunch explains the science briefly and links to a more in-depth article.

html5logoBut Evans draws what seems to me to be an erroneous conclusion from that evidence. He retracts an earlier prediction that HTML 5 apps would ultimately be more prevalent than apps written for native platforms. I don’t think that conclusion is at all justified.

Even if it’s true that web apps will be slower for the foreseeable future, decisions about which apps to purchase and use are not made solely or even primarily on the basis of speed. Rather, the issue of utility and usability are typically far more important. So long as web apps can be made as functional and usable as native apps, I see no reason to change my thinking that HTML 5 is the wave of the future for at least mobile apps, if not all networked software.

By the way, I don’t think it’s necessary to resort to esoteric science and quantum calculations to understand that apps running within a contained hardware space are always going to be faster than those that have to communicate across space and time. I just don’t think that’s the primary criterion on which the “contest” between native and web apps is going to be decided.

Once More Into the Breech: Native vs. Web Apps on Mobile Devices

The perennial topic of native apps vs. Web apps on mobile platforms was raised once again by Alex Genadinik on Website Magazine. Alex came down on the side of the view that, as far as I can tell, is in the minority by sharing his reasons for believing that native apps are where the action is and will be.

I posted a response to Mr. Genadinik’s piece, which I hope you’ll take time to read in its entirety. Just in case you don’t, here’s the gist of my argument.html5logo

Alex, while I think your basic fact structure is correct, I disagree with the conclusion you reach.

First, I think the days of something called a “site” and something called an “app” that are different are fast disappearing.

Second, while the centralized market for native apps has some advantages, it also has a huge number of disadvantages.

Finally, and I think most importantly, the Cloud concept is quickly causing users to expect a multi-device, multi-platform user experience that is thoroughly integrated. Native apps fail miserably at this for a number of reasons.

HTML5 Web apps are the wave of the future if not the present. There is certainly still an opportunity for native apps, but long-term bets should be on HTML5 and not proprietary apps.

What do you think? Is Alex right or are my arguments more persuasive?

In HTML5 vs Native Apps War, Anti-HTML Camp Forgets One Big Thing

html5logoI read with dismay another article today explaining why HTML5 isn’t a good strategy for developing mobile apps. This piece, directed to the higher education IT audience, ended up suggesting a hybrid approach rather than multiple native apps to cover all platforms, which makes a little more sense than others I’ve read recently.

But all of these articles have one theme in common. They argue that HTML5 isn’t a suitable platform for constructing these apps because it’s not always possible to access every hardware-specific feature of a given device using HTML5, whereas that is feasible with a native app.

True as that statement is, it makes a fundamental error that I’ve seen fatally repeated over and over again throughout my multi-decade career in this business: it assumes the other guy stops inventing. As of the time a given article is written, it may or may not be accurate to say the technology you’re criticizing lacks a particular capability. But to suggest that developers, who have to think in terms of months of lead time, should target any platform as it is today is a potential death knell. Any decent developer knows s/he has to target the platform where it will be when his app is ready to publish.

While it is true (for now) that HTML5 doesn’t have the capability of supporting mobile device multi-touch interactions or taking full advantage of native fast graphics, these are hardly deal breakers for a huge percentage of apps being delivered today. The article that triggered this piece says that you can’t use geolocation with an HTML5 app but that is not completely accurate. There is a third-party spec for such support and for many other features that often make the list of “unsupported” capabilities.

I remain convinced that in the long term — think 5 years — HTML5 apps will swamp native apps and we’ll look back with no real fondness on the days when we had to even consider developing and maintaining several code bases to be broadly relevant to the world of mobile computing.

 

Qt to the Rescue for XPlat Mobile App Designers? Not So Fast.

The HTML5 scene is a little confused these days. Between Facebook making public noise about the fact that it was unable to accomplish some of its design goals using the new technologies and the continuing argument on the part of those who favor native apps over web apps, those who support the new standards are getting a bit of a defensive attitude.

Qt scripting language logoThe latest incarnation of this phenomenon came when the company responsible for supporting and promoting Qt indicated this week that it saw the HTML5 confusion as a perfect opportunity for its technology to gain a toehold.

Sorry, but I just don’t see that possibility. Qt is somewhat arcane language and development environment, and the number of programmers who understand it well is vanishingly small. One of the oldest of the scripting languages that has been put to omewhat good use in a few desktop applications, Qt is nonetheless unapproachable by the folks who could learn HTML, CSS, and JavaScript readily. It certainly has good cross-platform credentials, and if it were better developed, it might have a chance in the market.

But the fact is, even its supporters admit that it won’t support smartphone application development until the middle of 2013, which is far too late for it make a significant impact fast-evolving market.

Take my advice and stick with HTML5. If you really need speed, then that you might consider developing a native app or just dropping into native code for certain elements of your app using a hybrid kind of structure.