Ask HN: Did You Ever See an HTML5 App That Feels Like a Native App? | Hacker News Reader

Ask HN: Did You Ever See an HTML5 App That Feels Like a Native App?

7 pointsmatt4211 comments

I see more and more article saying that modern HTML5 frameworks removed the gap between web apps and native apps. However, on a xperia U (2-cores 1GHz + Mali 400mp gpu) every sample apps I can find are far more laggy than any native apps I have installed on this phone.

I have two questions :

Did you ever see an HTML5 app as smooth as a native app even on a 150$ smartphone ?

Javascript and Java seem pretty close today: both benefit from highly optimized VMs, and both have to pause to garbage collect memory. CSS3 allows to directly tap into the GPU to accelerate the rendering of web app. Asmjs allows to write code running close to native assembly code. With all these great technologies, I do not see why web apps can be slower but the difference is still big. Did we miss something?

View on HN

Ionic Framework seems to be coming the closest an HTML5 app has felt to native from what I've seen. One of the reasons why is that the framework by default is mitigating many of the issues that hybrid apps currently have, and this update in particular demonstrates that really well- http://ionicframework.com/blog/ionic-huge-update/

It seems to promising: Fast, nice design, a MVC with angular js, and tools (via cordova).

Famo.us ( http://famo.us/about ) claims they can do performance comparable to native speeds with HTML (+JavaScript). Their code is already open source:

https://github.com/Famous/famous

It can render to DOM (hardware accelerated by CSS 3D transforms), Canvas, or WebGL.

Here are some examples:

http://www.codepen.io/befamous/

They will be "fully open to everyone by May 19th 2014." whatever that means... Also here is a long video with demos: https://www.youtube.com/watch?v=wxBxsLl9ViE

Thanks, the demos are amazing on Chrome, but slow on firefox 29. I guess they will fix it in the next release. The physics engine is impressive, but I hope it will add not to much code complexity. Let's see next month how are the first apps built with famo.us.

Actually as the first engineer (but one working on backend stuff, not the platform), I've actually be shocked at how little complexity it adds. At the end of the day all the animations are accomplished by passing in the function for the animation you want. That means that making an animation is just a matter of setting the coefficients on the function you pass in to the thing being animation. It's amazingly well decoupled.

Also, if you give us more details on the slow demo, we'll look into improving it on the browser you're using. What operating system? What browser? What demo? etc.

Do you also test famo.us on low-end smarphones ? The famo.us videos I found show smooth results on high end smartphones like the nexus 5. It would be interessting to see if we can the same performances of low-end smartphones.

About the slow demo. It was tentacule, runing on firefox 29, archlinux with a i5-2500k processor.

Processing power usually is not the issue.

What we don't work well with are browsers that either don't support the HTML5 APIs we rely on (CSS 3D matrices, perspective, backface visibility, preserve-3d, etc) or have very buggy implementations of those APIs. Old versions of the Android browser for example don't work for this reason.

If those browser APIs we need are present and they are properly implemented, then Famo.us generally runs comparably/competitively to native apps on the same device.

However, at the end of the day, we're skating to where the puck is going. Low-end devices from 1-2 years ago don't worry us too much because devices often get replaced with contracts and recent announcements show that feature phones are all soon going to be decent smartphones. The days of dumb phones are numbered. That's the world we're preparing for.

If I was founding a startup today, I'd be looking at the myriad greenfield opportunities out there that are only doable with apps that can be perform comparably to native and be launched by a link. The category of ephemeral apps in particular will take off in the next year or so.

I agree. In two years, things will be completely different, webgl and CSS3D will be supported by a majority of mobile devices and a nexus5-like phone will cost 100$. But today is a different story, and if your app is usable only on flagship devices, this is a severe disadvantage. It would interesting to see a study showing what are the smartphone used today, and if the majority are high end - low end or middle end. It would help us to know what kind of resources an app to be released will have to deal with.

Actually: http://www.antutu.com/en/view.shtml?id=7834

Every iOS app is only usable on a high end device from one manufacturer. Being limited to a market that includes all of the iOS market and a lot of the Android market, plus desktops/laptops, TVs, etc. is a pretty huge market market even without the feature phones.

I think it's possible, but it's rare. The HTML5/CSS3 Based App I'm working on right now does feel like a Native App, but it's because it was designed specifically to mitigate some of the "issues" with HTML5/CSS3 Apps. In terms of User Experience, one of the biggest factors is how the App is packaged and distributed. If it is a traditional Web App, then the UX will be heavily impacted while the content is downloaded from the Web. Especially if the connection is slow, and the content is rich. If the App is packaged as a Native App (which is what I'm doing), then most of the content is local, and only dynamic information needs to be downloaded. In this scenario, the UX is much more acceptable since most of the content does not need to be downloaded, it's already there. I'm using PhoneGap to package our App, and we've specifically crafted our API calls to be very light, so the resulting UX does have a Native Feel. But that does not mean that it's the same as Native, and once you get to that point, you'll find there are additional points that need to be addressed (mainly relating to the limitations of whatever javascript engine you use). Another point is the delay when clicking buttons. But the good news is, all these "issues" can be mitigated if you recognize them, and design the product accordingly. Very different approach from designing the Product without taking this into account, and then trying to "fix" it or "band-aid" it after the fact. Design it right from the start, and the differences become less and less apparent. So I guess my answer would be, not yet, but pretty soon!

Reply on news.ycombinator.com