Hacker News Reader

Comment by melling | Hacker News Reader

The context wasn't really necessary. I think we all believe HTML5 has a great future. Hardware gets better at a rapid rate and HTML5 (CSS, Javascript, etc) is still improving. The point is, and was, that it's probably best to produce native apps at this time, for the majority of apps. Facebook, for example, needs a 5 star app.

View on HN

Not necessarily a majority of apps.

Facebook is a really, really popular app. They cannot get away with good effort alone. They must make their mobile app flawless and reliable, because if only a couple of users out of hundreds of millions publicly criticize their app, this hurts their reputation badly.

I do not agree with what most people are saying. HTML5, CSS, Javascript are already good enough standards for 99% of all apps.

The real problem lies with the popular mobile browsers. Anybody who ever tried developing a rich interface for Mobile Safari and for Android knows just how bad things are - and some people think having to support IExplorer 6 was painful.

Also, at least on iOS, the browser has better performance than a WebUI embedded in an app. From what I know the web component doesn't use the same Javascript engine for instance. Also, not sure if this changed, but on iOS 4 you couldn't upload files from the mobile browser (file fields in forms were deactivated). You also couldn't automatically place the focus on a form field, to force the keyboard to pop, because you couldn't trigger any mouse/keyboard event other than in response to a physical user action (I think this was a problem with mobile WebKit in general). And I also experienced many problems with Android's browser. I can't even remember all of them.

The difference is that iOS allows Mobile Safari to turn memory areas into code pages, which is what you need to do to JIT JavaScript. It doesn't trust other apps not to be able to exploit that somehow, so UIWebView is not allowed to do this.

That explains a lot of things. Thank you.

Are you 100% sure?

I believe webkit (either in safari or UIWebView) should be able to run JIT, while your custom engine can't.

UIWebView doesn't support JS JIT, as it's still running in your process space.

thanks, didn't know that. this is really sad.

They would rather do that then open an exploit possibility. As a user, I prefer that trade-off. It would bother me if I relied on PhoneGap or something similar, but in practice, the performance really isn't that bad.

> They must make their mobile app flawless and reliable, because if only a couple of users out of hundreds of millions publicly criticize their app, this hurts their reputation badly.

Vehemently disagree. I know very few apps that are flawless and reliable, including Apple's native apps. A couple of users have already publicly criticized the app for YEARS now and it hasn't hurt their reputation to the point where they are losing users. Facebook has power because of the network effect. People are willing to deal with a flawed experience as long as the network effect is left in tact. Facebook will need to worry about a flawless app experience when the network effect diminishes.

iOS6 adds file upload support for images.

What I don't get is why facebook has to be an app at all. If you build it as a purely browser-based app, you can get better performance than running it in a UIWebView, and updates can be pushed out without anyone's permission. With HTML5 app cache you can get the "instant launch" experience that a native app gives you. For interacting with the camera they could have used a helper app.

Why are people so desperate to put their free non-ad-supported apps in apple's app store? It doesn't make any sense to me. I recently built an offline web app using sencha touch, and it works great. No install necessary, just "add to homescreen".

Users are trained to want apps. They are not trained to add to homescreen.

Apps get notifications.

IMHO, HTML5 isn't the issue. It's just a convenient scapegoat to distract investors from the fact that they either lack technical prowess in mobile app development (fairly unlikely...) or simply have poor leadership, vision and direction to deal with the challenges of mobile apps. To succeed in mobile, Facebook needs their own ecosystem.

Apple, Google and Amazon are years ahead of Facebook at this point and they have a tremendous upper hand right now. I don't see how Facebook can continue their growth in the current post-PC world. They've basically peaked at this point with their facebook.com site, and for future growth my bet is that they'll start growing through acquisitions. Sounds like yahoo.com to me.

> I think we all believe HTML5 has a great future.

I don't. Absolutely not. I have a confidence HTML5 will fail in the end.

> Hardware gets better at a rapid rate

Moore's Law is about to over. We have no free lunch anymore. The next Intel CPU (Haswell) gets only 10% performance improvement at the same clock.

And don't you hear our consumers complaining the battery life and the heat problem of their mobile devices? Things become worse on the coming wearable computers.

I can't understand why HTML/CSS/JavaScript advocates are so optimistic about this point. And looks like people completely forgot the buzzword of a decade ago, "green computing".

My simple question is, "Are you really a SOFTWARE engineer?" HARDWARE engineers will solve the problem. Hah!

> HTML5 (CSS, Javascript, etc) is still improving.

Yeah, at a deadly slow speed. There are many critical bugs which has been stuck for several years. I'm tired to wait them fixed. Apparently web standards became too complex and about to collapse. Many programmers completely forgot the KISS principle. Very sad.

> I have a confidence HTML5 will fail in the end.

When is the end? What will replace it in the browser? Will people stop using browsers? Why do you have confidence other than things are not perfect now?

>optimistic

Being optimistic makes people want to solve problems. Being pessimistic makes people think defeat is 100% likely so they never try to solve anything.

Our games already work very well in HTML5. They "work" on an iPad 3, but we still make native versions because the technology we use, Monkey, allows us to very painlessly do so.

On desktop, Chrome, Firefox, and IE all run the games perfectly on a now 4 year old computer build.

I'm not betting everything on HTML5 but to me it already is succeeding and I am confident that consumers will drive demand for it, vendors will produce and release devices which support it. Even if Apple, or the other big sellers don't support it there will be those who do and the great support will sell units and make anyone who doesn't support it well look bad.

I believe you will always be able to make html5 apps if you want. But I believe the iOS 'apps' model is going to become the standard for consumer pc's. This will cause native apps to no longer be second class citizens, and HTML based apps will have to compete with native just like they do on iOS. Right now basically all consumer computing happens through the browser, except for ms office, and it takes enormous effort to get a non-technical user to install software.

> Hardware gets better at a rapid rate and HTML5 (CSS, Javascript, etc) is still improving.

Hardware is only improving as fast the vendors see a need to. If the ARM chips in a smartphone suffice for say 90% of the games produce on a iPhone, why on earth increase it's power? We all know (hopefully by now) that the HTML5 spec chews through CPU, especially when called in parallel requests. It's not advantageous for Apple to optimize the HTML5 spec, otherwise it decreases lock-in.

Also, this is the same argument that happened in the 90's with desktop/laptops and only really has progressed now with the existence of modern browsers. The only way that this was possible was when telecommunication infrastructure was able to support always connected devices, which the late 90's and early 2000's has proven. We are almost there, but considering 3G (4G, LTE, or whatever) is still not 100% reliable, I don't see this happening anytime soon. I really think we are less "connected" (technologically speaking) than the general public gives us credit for.

Also core count is increasing, but raw speed per core really isn't. Multicore really doesn't help web rendering very much. Nearly all javascript out there is single threaded and most dom rendering is too.

> Nearly all javascript out there is single threaded and most dom rendering is too.

http://en.wikipedia.org/wiki/Web_worker

That's really not a rebuttal. Yes, lots of browsers now support web workers. Yes, it is therefore possible to write multithreaded javascript. And that may become more common over time. But for now, the fact that it's possible does not change the fact that nearly all javascript is still single threaded.

IE10's chakra engine parallelizes interpreted javascript execution (on page load) with JIT compilation and garbage collection. So you can have up to three cores at work executing javascript even without web workers. Meanwhile, the rendering subsystem offloads to the GPU, and the whole thing can exist multiple times for multiple tabs, potentially involving dozens of cores executing your web apps.

http://blogs.msdn.com/b/ie/archive/2012/06/13/advances-in-ja...

Of course all of this is useless in the context of mobile web views because Android dropped web workers and IOS just picked them up.

Raw speed per core is increasing DRAMATICALLY in mobile. Faster than even Moore's law would dictate. As the die process has shrunk, more transistors are fitting within the mobile TDP ceiling so modern processor methods are finally getting used. As recently as the ARM A8, out-of-order execution wasn't even used!

You can verify that this is correct by looking at any benchmark.

> Multicore really doesn't help web rendering very much.

There are people working on changing that, for what it's worth.

Indeed. Blossom[0], a mobile MVC client framework for business apps, is being updated as we speak to split apps into a UI/animation thread, with the application/model layer/network in a web Worker on a separate thread.

Disclaimer: I wrote Blossom.

[0] https://github.com/erichocean/blossom

Why are people downvoting this?

There is also work from the other side, to make the browser engines take more advantage of parallelism. That's more what I was referring to.

Blossom sounds pretty neat!

I'd say it depends more on app type than on HTML5 progress. For apps what are little more than glorified content viewers HTML is promising, for others — not so much. HTML5 brings some sanity and improvements, but at the roots it is still same old and lame HTML. You may spin and twist it, but at the end the question is "was it worth is". And the answer, most often than not is "hardly". Improving hardware won't change that, at least not substantially.

I think it adds the clarity that they don't think HTML5 is actually bad, but rather that it's still not ready for prime time (for them!) The many other quotes I've read around the web don't mention this, giving more of a "HTML5 sucks" hint to the quote.

Even when HTML5 will be ready for prime time it could never compare to a native app. This isn't a new issue, cross-platform solutions have been around for ages and they always fell short.

Sure, if you're comparing like-for-like experience and performance. But HTML5 provides advantages with rapid development, cross platform, distribution etc. over native apps. The debate is whether these advantages are enough to sacrifice the quality of experience and performance provided by a native app (or rather, whether the gap is sufficiently small enough to justify going for HTML5). Zuckerburg's opinion appears to be... yes, but not quite yet.

Fell short in what way? Yahoo Mail came out in 1997 and people flocked to use it. You can guess what the UI was like for Yahoo Mail in 1997. But UX isn't only about UI. Being able to shop for a new computer or phone and knowing the stuff I use will continue to work is great UX as well. There are always tradeoffs. I'm tired of the anti-web brigade acting like web development is only good for the developer.

Once upon a time I worked at a company where we developed in a platform called Clipper. We used a cross-compiler to port apps from a PC to an HP-UX system. Although Clipper was based on C and the cross-compiler created C code it was never as optimized as it could be if written from scratch-actually it wasn't even close. In the years since I've heard numerous stories of similar situations. The one size fits all, which was best materialized by Java, never lived up to its name.

You say HTML5 could deliver a unified UX. I disagree. If the problem is the need for unified visual environments then HTML5 is the wrong answer to this problem - CSS is more close to the answer. HTML5 was supposed to be that kick-ass solution for delivering a more robust development platform for the web that could reduce the need for third-party plugins like Flash or Silverlight.

I won't argue that what HTML5 has achieved is no small step. But I wouldn't have high hopes of it ever manage to compare head-to-head with a native app, no matter how mature it would become-and that last part takes a lot of argument since evolution of HTML takes ages.

> You say HTML5 could deliver a unified UX. I disagree.

Me too, I never said that. I said that, using Yahoo Mail as an example, users are willing to sacrifice some integrational purity when ease-of-use and portability are so compelling. Today that balance hasn't been tipped on mobile. I'm willing to bet it will be, eventually.

"HTML5" includes CSS, javascript and the actual HTML markup along with a myriad of other things.

Without context this partial quote makes deceptive buzz in general media and that's gonna hurt many people and businesses.

> Facebook, for example, needs a 5 star app.

Could you explain why?

Facebook relies on people using their service all the time, when they want. They want it to simply work. That's why they have this obsession about 24/7/365.25 uptime on their servers. It means also no friction when people use Facebook on their mobile, thus a 5 star app.

If you're being that precise the calendar actually has an average of 365.2425 days per year and not 365.25. In fact that was the major motivation for switching from the Julian Calendar a full 430 years ago.

http://en.wikipedia.org/wiki/Gregorian_calendar

Or, if you're being really precise, you'd say 24/7/52... </pedantry>

I was expecting this kind of comments if I had only written 365 days a year, thought I was covered, apparently not.

I think the pedantry was invited by the attempt at specifics. C'est la vie.

I was just kind of surprised to see the .25. If you had put just 365 I'd have read that as "a year" and not give it a second thought. Instead it got me thinking if it actually rounded out to .25 or not so I went and checked. Apparently that wasn't too appreciated... :) No offense intended.

They have cemented their position. They can, at this stage, suffer down time without too much concern (hell, even twitter was down recently)

> hell, even twitter was down recently

You seem to think Twitter has a strong reliability record.

Fail whale...

I hypothesise user engagement would suffer in the face of down time. This, plus the added scrutiny this technical failure would place on their stock, means now is not a time when they can be careless about reliability.

Agreed, in fact it's ironic that they try sooo hard to have 100% uptime, as a small amount of downtime, can be a good thing.

No-one cares if vital utility x is working. It's not like they are texting their friends, about x being 'up'.

But if you take away x, often it highlights just how important it was, and it becomes relevant to them.

It reminds them just how much x, means to them.

Then, if x reacts to the adversity in a crowd pleasing way... instant karma and mindshare.

cf. new coke as well.

(speaking from experience in the hosting industry)

I disagree. There is so many social websites out there that you need your users to think you are the only option, If your service is down, people will have a look at others', and might them interesting.

Probably the main reason that they have so much traffic going to the mobile website (aside from international audiences with dumbphones) is that the app sucks. My colleagues use the webapp on their androids because they hate the native app.

Interestingly, once html5 becomes fully ubiquitous, Facebook will probably already be sliding no matter how well it's native apps run. Will be a non-issue in the end.

Reply on news.ycombinator.com