Hacker News Reader

Comment by RivieraKid | Hacker News Reader

As an Android dev I can tell you this isn't happening in the next 5 years. They may add Chrome apps to Android, but it will be a niche option that won't be used by anybody.

My utopic wish is a new open platform that will combine strengths of the web and of operating systems (Windows, Android):

- Web: Great for documents, which it was originally designed for. Automatic updates. No installation. You can "fork" an app / document by middle clicking a link.

- Operating systems: Great for apps. Speed. More low level access to the hardware. Much richer platform than the web (window mnagment, human interface guidelines, ...).

View on HN

Why not? What if the apps are purchased seamlessly through the play store and can run on Android or in Chrome?

I have a feeling they will add more and more Android device APIs to whatever is coming, until it has just as many as the Java APIs.

I've thought for the past year or so that there is no way the future of Android app development is Java/Dalvik.

That's possible today - there are apps, that are basically web apps. But they usually offer inferior user experience. It's cheaper, but for the price of being worse than a native app.

It's possible they will add support for other languages besides Java. Android is stuck with Java 6, which sucks...

That language will be web, I suspect. Perhaps Google will offer prerolled components specifically for Android? I strongly suspect that Chrome is the platform Google wants to push for client development now, with Android essentially as a shell for it. While web may arguably be "worse" on Android now, Google has a very large, talented engineering team who could change that relatively fast. Java is a dead end at this point for them I think as far as pushing client development forward. My personal preference would be Android development via Go lang, but I don't think there's much of a chance of that.

I am not a web developer BTW, I am primarily an iOS dev who has done ~6 months of Android work.

Web is a platform, so they would need to rewrite half of Android, I don't think it would be worth it, I don't see real benefits of that for users or devs...

I think that Java 8 is a great language, I like it a lot more than Javascript. Go would be great too.

In all seriousness, I just want a C API. I like different languages for different purposes, but C is still the lingua franca. You can have your Go, I can have my C++, the next guy can have his Python.

As-is, native code on Android is a cluster, and even for games it's pretty uncomfortable and filled with Java shims. Kinda gross.

Why would you have Go on a mobile OS as a mobile application development framework?

One guy calls the web a language, now someone calls Go a mobile application development framework. Come on, guys, we're programmers, let's call things by their right names. Go is a programming language, and technicalities like goroutines aside, you'd want it pretty much for the same reason why you'd want Java, Objective-C, JavaScript or, Heaven deliver us from the Symbian days, C++: some people think it's a nice language.

Frankly, I'd trade Java for Go any day.

My bad, meant programming language.

I probably wouldn't switch from Java but lots of people want to use Go to make Android apps.

I'd trade Java for Go in a heartbeat

I think of Go as being a language and runtime as opposed to a "development framework", but why wouldn't you have it as a mobile OS language, particularly when compared to Java?

I'd love to see Go on Android. I doubt it will happen anytime soon though because it would require an entirely new runtime library environment to really be Go-like, just bridging Go to the existing Android Java APIs via Java<->JNI<->CGO<->Go would result in something very horrible.

Word on the street has it that Android and Chrome are two highly separate fiefdoms within Google which are somewhat antagonistic (fighting over company priority). There is unlikely to be a high level of cooperation between the two teams without significant internal restructuring. As far as I remember, chrome isn't even Android's default browser.

> There is unlikely to be a high level of cooperation... without significant internal restructuring

Internal restructuring like, say, Andy Rubin beyond deposed as head of Android and replaced by the guy in charge of Chrome (Sundar Pichai), who now oversees both Chrome and Android? Because that happened in March.

(Chrome is the default browser in nexus devices. Whether it's the default in non-nexus devices is up to the manufacturer & carrier, who usually choose to use the AOSP browser - an unbranded front end of the system webkit - because they can control and customise it, which they obviously can't with chrome as a branded google app that's updated through the play store).

Why, as an Android dev, do you say that?

Because, as an Android dev, I understand that both platforms have different strengths. Merge of the android and chrome/web platform, that would keep the strenths of both, is basically impossible. So the only possible scenario is making interative improvements to the chrome/web platform. But:

1) That would break backwards compatibility with Android apps. They would basically have to kill Android and replace it with Chrome OS Mobile.

2) Chrome OS platform is far, far behind Android (and operating systems in general) in many aspects.

Merge of the android and chrome/web platform, that would keep the strenths of both, is basically impossible.

Why do you say that? Add some APIs to the Android browser, allow it to open apps full-screen... there doesn't seem to be much more to it than that.

They would basically need to recreate the Android API in the browser if they wanted Chrome apps to be as good as native Android apps. So Chrome OS would become a virtual machine emulating the Android platform.

Right now, it's quite easy to package a web app into an Android app. But users generally dislike that.

That's really not too different from what it takes to package HTML5 code into Android apps already, with the same result of apps with UIs that feel foreign to the system.

The trend is not towards HTML5, but actually away from it. Quite honestly the Chrome Mobile team are swimming against the tide on this.

The trend is not towards HTML5, but actually away from it.

I'd argue that is because the functionality isn't there to make it competitive. So the Chrome Mobile team isn't really swimming against the tide, they're... whatever you do when you put things in the sea to adjust tidal flow.

Mozilla, too. I have a Firefox OS phone on my desk and while it's far from ready for end users, it is an impressive showcase of what you can achieve with HTML.

> it is an impressive showcase of what you can achieve with HTML.

That statement right there is the single biggest problem that web faces. You still have to qualify it with impressive for HTML. Because the bar for HTML is just so, sooooo low compared to native. On desktop it kind of works because performance really isn't a problem - you've got boatloads of CPU & RAM to just throw at it and nobody expects 60fps. On mobile it's the exact opposite.

Web isn't a viable platform for app development until people start saying "that's impressive" without the "for HTML" qualifier. And that isn't going to happen anytime soon.

> The trend is not towards HTML5, but actually away from it. Quite honestly the Chrome Mobile team are swimming against the tide on this.

That's quite a statement. The average Android app is already a UI nightmare that feels foreign to the system, I don't see how HTML is going to be somehow worse (especially when there would be a full set of HTML5 components to use).

>The average Android app is already a UI nightmare that feels foreign to the system, I don't see how HTML is going to be somehow worse

Well, it's gonna be worse by being even more foreign, feeling even more foreign (what's with custom components re-created for HTML5) and slower.

Actually, it's not a hypothetical: you can already check "wrapped in native" HTML5 apps and proper native apps, and the former do feel inferior, unless the developers have put tons of effort in them (and still, they are not able to do cpu-intensive things that native apps do, from live video filters to audio stuff).

Of course that might still be OK for simple apps, todo lists, glorified web clients, etc. But those are not what will drive mobile forward, it's just the lowest common denominator.

But there are also apps that are pretty slick and that's more and more common. It's quite easy to make sure your app will have 60 FPS most of the time on modern devices.

That sounds like Firefox OS.

There are thousands of PhoneGap apps out there, pretty much disproving your point.

Yes, but they suck.

Reply on news.ycombinator.com