> At Seravo we hold the belief that in the long term, browser based HTML5 apps will be more important than native apps.
What is the "long term"? Has somebody actually managed to build a native HTML5-based UI that isn't a laggy and clumsy piece of shit yet? For example, webOS looked great but even the simplest lists scrolled with less than 30 frames per second. The videos I've seen of FxOS don't show much promise either (although those are running on really low-end hardware).
I'm really skeptical that trying to shoehorn something called "hypertext markup language" and a generic web rendering engine like WebKit into a UI toolkit is ever going to work smoothly. Even on my desktop computer complex sites can work slowly at times. But I'd love to be proven wrong.
FxOS runs at 50+ FPS for pretty much all of the built-in UI, even on lower end phones like the Geeksphone Keon. Higher end phones are actually really fast, like the LG Fireweb (released in Brazil a couple weeks ago) and the GP Peak.
Think long-term. What could you conceivably do on the desktop that you can't do on the browser? Media recording and management? HTML5 is well on the way and someone compiled a functional version of FFMpeg in Javascript just recently. Storage? Security? Dropbox and more of the kind. We already have document management. The only thing I can think of right now is a render farm but we'll do that in the cloud anyway (even if the cloud is a desktop computer right next to you). I scoffed at the idea not too many months ago but I'm starting to see how mobile and desktop are converging, and I think it's going to happen faster than any of us expect due to consumer demand.
Edit: thinking of program like Final Cut: someone will figure out how to do the hardcore processing over-the-wire using Thunderbolt or something. Dumb terminals, welcome back!
It's impossible to predict things long-term. I mean, maybe we'll eventually get web applications that look and feel exactly like native apps. But maybe we'll still be stuck with kludgy, hacky, JS/HTML5-based apps that have rendering problems depending on your browser, that load in ugly chunks, that save your data to some proprietary cloud, that fail at concurrency, that don't integrate with your OS's multitasking workflow (Spaces, Mission Control), that take 5 times as long to run, and that stop working as soon as you go into a tunnel. And that's only from the user perspective; as a developer, I don't look forward to the nightmare of being stuck in a Javascript universe. I love being able to pick and choose from so many different frameworks, libraries, and languages when developing native apps; with Javascript, as soon as I try to do something simple, I inevitably end up with an SO answer that looks like this: http://stackoverflow.com/questions/950087/how-to-include-a-j...
(And no, "use JQuery" is not an answer; it's a symptom.)
Plus, it just feels shitty to not be able to own any of your tools. I don't want to rent my applications from some multinational corporation. I bought them, so they should be mine. (Yeah, yeah, nobody really owns anything anymore, but at least the bloody bits are on my drive!)
In short, if web apps are the future, I hope that a) they're only one of several commonly used paradigms, and b) we have something better than a browser to run them in.
I don't think it's better: I work with heavy media files and it worries me when Apple makes OSX a bit more stupid every release. But I have faith that as developers we'll make it work (maybe the industry moves to Linux, who knows). But I also LOVE the idea that my mobile phone or some tiny gadget I wear around my neck is the key to my data, and I can rock up to any monitor or use any display, glasses, microprojector whatever. I just see the changes coming, where iOS and OSX are merging slowly. It's too early to say what this is going to mean for pro developers/users.
All of your points are completely valid today. I would come back in 5 years and see that probably all of those are achievable by the browser and Javascript.
Eg:
>1) Anything low level hardware (reading data via USB, or pushing data into HDMI, for instance)
I would expect that a Nexus device can do Chromecast from browser screen, if not today then soon.
>2) Interacting with ANY hardware that's not explicitly supported by Javascript. Try creating an HTML5/JS scanner app.
You mean like, taking a photo and processing it? You can do that right now.
>3) Writing super-fast CPU-specific code, think Assembly language. That's the reason there are no HTML5 apps of the Photoshop caliber
Yet, agreed. But soon - only CPU is slowing it down, not the technology.
>4) Disk access. Try creating a Javascript-based antivirus. Or an app that watches for changes in a certain directory.
There won't be a filesystem as we know it. The 'cloud' and browser-accessible storage will be all we need.
>5) Internal network access. Try writing a JS app interacting with your localhost or TCP/IP or UDP.
> I would expect that a Nexus device can do Chromecast from browser screen, if not today then soon.
No, that's not what I meant. Pushing any data into HDMI, controlled by the app, not the screencasting.
> You mean like, taking a photo and processing it? You can do that right now.
No, I mean connecting to a scanner, scanning a document. You can't do it now. And don't tell me taking a snapshot with a built-in camera is the same thing
> There won't be a filesystem as we know it. The 'cloud' and browser-accessible storage will be all we need.
Sorry, I wasn't aware you could predict the future, and I thought we were talking about now.
> Sockets, it's possible now.
No, your JS app can't access the internal network, unless you expose it to the internet with TCP/IP. Sockets only let you connect to public servers. And no UDP (at least not explicitly).
Ah well, I was talking about the future. You're correct about the above you mention, and regarding sockets I was of course referring to TCP/IP. I'm keeping an eye on the Jolla/ChromeOS/FireFox OS types, more than iOS as I think there will be significant changes to allow the above and more.
IMHO that's list what you can't do "with the browser" not "on the browser". If browser is somehow exposed to interfaces of peripherals/devices/etc there is no reason why you can't do that "on browser". Yes, you can't do that with browser alone, but you can do that on browser.
I'm curious about this POV from folks of getting mobile web apps to look and feel like mobile native apps being a prerequisite for success. I just don't think this is true. After all, desktop web apps look and feel nothing like desktop native apps.
I too believe that mobile web will one day overtake mobile native apps for most peoples' daily usage. I just don't think it'll look or act anything like what we're currently doing. Luke Wroblewski gives a great talk about the early days of a new medium being an awkward state where we try to shoehorn what worked in the last medium into it. At some point we'll figure out a design and usage patten for the mobile web that'll make a world of sense in hindsight. We're just not there yet IMO and of course I have no idea what this looks like.
> At Seravo we hold the belief that in the long term, browser based HTML5 apps will be more important than native apps.
People have been saying that for 5 years + , the "future" still has a long way to go. By the way , that's what the iphone was supposed to be, a phone where devs write browser apps... we all know what happened.
"When it [iPhone] first came out in early 2007, there were no apps you could buy from outside developers, and Jobs initially resisted allowing them," writes Isaacson. "He didn't want outsiders to create applications for the iPhone that could mess it up, infect it with viruses, or pollute its integrity."
What is the "long term"? Has somebody actually managed to build a native HTML5-based UI that isn't a laggy and clumsy piece of shit yet? For example, webOS looked great but even the simplest lists scrolled with less than 30 frames per second. The videos I've seen of FxOS don't show much promise either (although those are running on really low-end hardware).
I'm really skeptical that trying to shoehorn something called "hypertext markup language" and a generic web rendering engine like WebKit into a UI toolkit is ever going to work smoothly. Even on my desktop computer complex sites can work slowly at times. But I'd love to be proven wrong.