Filepicker.io's "Don't write off HTML5" contest(blog.filepicker.io)
blog.filepicker.io
Filepicker.io's "Don't write off HTML5" contest
http://blog.filepicker.io/post/32893885058/filepicker-ios-dont-write-off-html5-contest
9 comments
The Zuck is sort of right though. There is no doubt that the iOS / Android FB app is pretty slow and buggy due to their dependence on HTML5. They've gotten grilled by their users in the past -- although props to them for really improving it recently.
I'm not saying that HTML5 is a bad technology or anything, it just isn't quite there yet.
Good article nonetheless.
I'm not saying that HTML5 is a bad technology or anything, it just isn't quite there yet.
Good article nonetheless.
Agree that it isnt currently fluid enough from a UX standpoint. But precisely why all of us should get behind HTML5 and push it harder.
That's why we decided to contribute our resources towards it and wanted to encourage the community to support HTML5 as well.
The last thing we want happening is that folks stop developing for HTML5 since one of the big boys out there feels otherwise.
That's why we decided to contribute our resources towards it and wanted to encourage the community to support HTML5 as well.
The last thing we want happening is that folks stop developing for HTML5 since one of the big boys out there feels otherwise.
about HTML5 on mobile :
+ the problem is at the source. bad language and api design choices make HTML5 what it is now. You cant build great software with bad technologies. Is it here to stay ? yes , Is is over-rated? of course. You want a great UX? then go native.
obj-c is not that hard, and java is easy to learn. why anybody would want to do some javascript instead is a mistery.
[deleted]
There is virtually no browser competition on mobile. On the desktop browser vendors directly compete which led to the innovation we saw the last few years. But on mobile the browser is a feature of the OS, reducing its importance. So we have stagnation. Releasing one browser update per year is seen as acceptable.
Good point. Fortunately Firefox on Android is now competitive with Chrome, so we will hopefully see this start to change (though the rendering engine monopolies on iOS/WinPhone aren't helping).
I have four different browsers on my phone. What would constitute competition?
Market share
What about the LinkedIn app? Don't they use a lot of HTML(5) in their app?
Facebook just happens to be a big company that said HTML5 didn't work for them. For all we know they designed it wrong/optimized in the wrong way.
Saying web apps on mobile are a bad idea based on that doesn't make sense.
Facebook just happens to be a big company that said HTML5 didn't work for them. For all we know they designed it wrong/optimized in the wrong way.
Saying web apps on mobile are a bad idea based on that doesn't make sense.
Even if Mark’s view is correct (debatable), the only way HTML5 will ever ‘get there’ is if the developer community continues to build apps on HTML5 that push the boundaries of performance.
The presumption that the developer community can impact this is also debatable. What proof-points in history are there for technologies that became popular or standard because DEVELOPERS decided to adopt them? In most cases you come up with, I bet you'll find their success was short-lived or medocre. Compared to say Objective-C and iOS or Win32.
Platforms (and related technologies) become popular/de-facto-standards because CUSTOMERS buy the value proposition of the product. Developers then adapt/adopt.
I'm not saying developers have no impact, I just don't think the impact is enough to really move the ball.
The presumption that the developer community can impact this is also debatable. What proof-points in history are there for technologies that became popular or standard because DEVELOPERS decided to adopt them? In most cases you come up with, I bet you'll find their success was short-lived or medocre. Compared to say Objective-C and iOS or Win32.
Platforms (and related technologies) become popular/de-facto-standards because CUSTOMERS buy the value proposition of the product. Developers then adapt/adopt.
I'm not saying developers have no impact, I just don't think the impact is enough to really move the ball.
In what way have customers chosen e.g. Java over other languages and technologies?
Customers set constraints that restrict choice, but they don't choose them, developers do. And while for iOS apps those constraints heavily limit the choice of language, the same is not true for the choice of backend language in web apps, for example. Or for desktop applications, for that matter.
Customers set constraints that restrict choice, but they don't choose them, developers do. And while for iOS apps those constraints heavily limit the choice of language, the same is not true for the choice of backend language in web apps, for example. Or for desktop applications, for that matter.
>Choose any technology or any API you want and build a mobile or mobile-web application that showcases HTML5’s capabilities
>- Both web or mobile web apps are fine.
Is it me or this is quite confusing ? Could someone from Filepicker.io make this clear, please ? :)
>- Both web or mobile web apps are fine.
Is it me or this is quite confusing ? Could someone from Filepicker.io make this clear, please ? :)
I think they mean that you can design your application to be used on a mobile phone as long as it runs in the browser, not directly on the phone.
vhf- sorry about not clarifying
web=laptop/desktop browser based app
mobile web=mobile browser based app
You are technically right.web=browser based. But we decided to distinguish just a bit to encourage mobile focused web applications as well.
Thanks !
Yeah well, I wasn't nitpicking on the technical sense of web. I was just confused because it said first "mobile or mobile-web" and later "web or mobile web".
Yeah well, I wasn't nitpicking on the technical sense of web. I was just confused because it said first "mobile or mobile-web" and later "web or mobile web".
Ben Sandofsky of Twitter wrote a well-reasoned take on the whole HTML5 vs. native apps debate: http://sandofsky.com/blog/shell-apps.html
I've had very similar experiences working on both HTML5 and native apps.
I've had very similar experiences working on both HTML5 and native apps.
Hmm. So the argument that web will eventually over take native mobile apps has been made over and over. Sure an O(n lgn) algorithm is better, but if the constants are bad enough, I'm going with the O(n^2). Even the author admits that native apps were around for nearly 20 years. Accounting for the fact that things move faster now so it might be less, we're still only a couple years into a decade long era of installed mobile applications. Then, we still have to account for the bad network connections on the phone that make web apps harder to work with.
While I'm skeptical of the mobile argument, I'm super excited about html5 dev conf because I do think HTML5 is going to be big on desktop/laptops.
While I'm skeptical of the mobile argument, I'm super excited about html5 dev conf because I do think HTML5 is going to be big on desktop/laptops.
I don't dispute HTML5 can perform well if optimized the right way. What I would dispute though is that it's actually far harder to develop a web app that feels native than it would be to just make native apps. Plus people want access to device sensors, push notifications, background tasks, etc. that are also hard to get at through javascript.
In my recent experience, using Phonegap you can get to the hardware stuff, it was not being able to get to webservices easily that killed it for me. Servers need to be specifically configured to allow cross-origin requests [1] in JavaScript, or you're basically dead in the water, from my understanding.
This is a pretty huge showstopper for HTML5 mobile. I'd love to hear how you're supposed to get around it.
[1] http://stackoverflow.com/questions/3595515/xmlhttprequest-er...
This is a pretty huge showstopper for HTML5 mobile. I'd love to hear how you're supposed to get around it.
[1] http://stackoverflow.com/questions/3595515/xmlhttprequest-er...
You can always proxy it through your own server, although obviously that's less than ideal.
I get a delivery failure sending to that email address.
Who was "giving up" on HTML5 just because some founder of some company said so to begin with? I appreciate that Mark's HTMl5 app was less efficient than his native app. Sucks for him and his team, I guess. My question is: So what? These are just tools. Pick one that is appropriate for your company, given the entire context of the product you are attempting to deliver, and make a practical and well thought out decision. For so very many, HTML5 is the right choice. For many others, it's not.
Soo... Sorry, I get bored with hyperbolic, "The Rise of..." and, "The Death of ..." articles.