Tag Archives: browsers

The web without HTML

On Twitter, Alex Fajkowski responded to my blog post about tvOS with this:

“They have access to the open web—NSURLSession exists. HTML rendering is inappropriate for the watch and tv.”

I disagree with both of those sentences. Maybe Alex didn’t read my full post, because I wrote that web services are not enough. HTML and links and URLs are equally important parts of the open web. NSURLSession gets you web services but nothing else.

(As an aside, HTML turns out to be a pretty useful format for styling text, too. Why wouldn’t you want to use it for iTunes movie descriptions on the TV, for example? That seems completely appropriate.)

Think about the full scope of the internet. What percentage of content is available via web services — that is, structured data that can be parsed and displayed with a custom, native UI — compared to all the traditional, HTML-based web sites? You’ll find that there is an almost unimaginably large number of that latter kind of web site, and the only way to access and display that content is with an HTML renderer.

Now imagine a world with only native apps. You’d need custom apps and web services for different kinds of content, just as we have native Twitter or Instagram apps today, but we’d need these for many thousands of categories: tvOS with TVML, recipe or cooking apps with FOODML, and so on. Eventually, having so many formats would get unmanageable. We’d need to invent a general purpose format that could accommodate many app formats, and (surprise!) that general format would look a lot like HTML. Why break old content and essentially reboot the web, when we already have a capable format in HTML?

Of course, there’s no immediate risk of getting to that hypothetical native-only future. But when a company with the size and influence of Apple has 4 major platforms and only 2 of them have access to the open web, that should give us pause. Let’s reflect on how this plays out, so we can get back on track if the web does become marginalized.

John Gruber commented that these new devices don’t need the web at all, comparing it to the original Mac shipping without a command line interface. I realized while reading his closing paragraph that my own blog post had been poorly titled, and so the whole point too easily misunderstood. John wrote:

“Or it could be that Apple has decided never to open WebKit to developers on Apple TV. Either way, it won’t affect Apple TV’s success, and everything will be OK.”

Apple TV’s success doesn’t change my argument. My Apple TV dev kit arrives on Friday, I’m going to build an app for it, and I can’t wait to watch Apple’s latest platform take off. When I wrote that the Apple TV “needs” the web I didn’t mean that it would be crippled and unsuccessful without it. I simply meant that the web should be there in some form, even if limited.

(It doesn’t even have to be Safari. There just needs to be enough web technologies to make some part of the open web possible. Again, that means web services, HTML, and links.)

Yesterday, John Gruber also wrote about web apps and native apps, and what each should focus on:

“Native apps can’t out-web the web, and web apps should embrace that.”

That’s good advice. There are plenty of important tasks for the web community that should be top priorities, such as encouraging a return to independent publishing and trying to fix the lack of redundancy. The web will always be playing catch-up with native apps for user experience, but the web will always be ahead as a distributed, open publishing platform. And that is such an important feature, it should be available on as many devices as possible.

Mediocrity is the new application platform

Today marks the 4-year anniversary of this weblog. What better way to celebrate than with a discussion of web applications.

Willie Abrams said in a recent Campfire chat: “Web applications automatically have sync.” He hits on the fundamental principle of web applications popularity, and of course that has always been true. But the difference now is that some web apps are actually fast and usable too. (Gasp!)

The rise of rich web applications that seamlessly mix Flash or Ajax while still staying true to the roots of web architecture (REST design, open standards) has upset the traditional desktop market. I first wrote about this in “To-do lists and embracing the network”, which was in a sense a subtle wake-up call to Mac developers: adapt to the always-on internet or any college drop-out with a shared server will obsolete your app after a few late nights of Rails hacking.

But it frustrates me to see such praise given to web applications that, were they traditional, native apps, they’d be laughed away to obscurity or ignored. Ajax is a huge advancement, but that doesn’t mean that every application works well for the web. I’m sure Google engineers spent an incredible amount of work on Google Pages, but compare it to Apple’s iWeb and it becomes obvious how weak web application interfaces still are.

Luckily some people are working through the really tough problems. Ray Ozzie’s Live Clipboard may be the start of a whole new shift in web app functionality, allowing data to move between web sites and even out of the browser. But true drag-and-drop of structured data between a native app and a web site is still a long way off.

Let’s make some lists, starting with the good.

  • Good web applications are data-driven, multiuser, and use URLs everywhere.
  • There is some key component that is about the browsing experience. That might be sifting through large amounts of data, viewing old logs, finding people.
  • The kind of data requires an adaptable user interface, not something with a strict set of traditional widgets. HTML is perfect for this.

On the other side are web applications that might be built by a team of smart people and with a great technology backend, but the application concepts are confused. They don’t know if they belong in a web browser or on the desktop.

  • Mediocre web applications think that a single web browser window is an entire windowing system with movable child windows.
  • No features that actually have anything to do with the web. The result is that it adds no value to the web as a whole.
  • Trying to replace the whole Microsoft Office suite.

Something else is changing in the HTML/CSS/JavaScript platform. In 2004, Joel Spolsky wrote about how instead of picking Mac, Windows, or Linux APIs, developers are building for the web platform and can deploy to any user’s desktop. Cutting-edge web applications push that claim to its breaking point, as differences between Safari, Mozilla, and Internet Explorer often cause headaches for developers. It’s no surprise when Microsoft’s set of Office Live applications require Internet Explorer, but it is note-worthy when Google’s chat interface does not work in Safari. There is now a whole set of web applications that require the latest version of Mozilla and won’t work in anything less.

Five years ago we accepted that web applications were going to be useful but ultimately unfulfilling, joyless experiences. Now most web apps have risen from bad to simply mediocre. The truly great ones have a foundation and design that would still be unrivaled in a desktop app. These amazing apps are not content to reimplement an old application as a web app just to allow use from any machine, but they take it to the next step: rethink the problem, stay agile, and redesign so that it’s not just web-based, but it’s actually better.