The much-anticipated convergence of Android and Chrome is near. These new Chrome apps are the programming model for the upcoming native Android webapps
The next milestone I expect to see is V8 added alongside Dalvik as a first-class runtime for Android. Maybe in Android KitKat?
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, ...).
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.
It's possible they will add support for other languages besides Java. Android is stuck with Java 6, which sucks...
I am not a web developer BTW, I am primarily an iOS dev who has done ~6 months of Android work.
I think that Java 8 is a great language, I like it a lot more than Javascript. Go would be great too.
As-is, native code on Android is a cluster, and even for games it's pretty uncomfortable and filled with Java shims. Kinda gross.
Frankly, I'd trade Java for Go any day.
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.
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).
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.
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.
Right now, it's quite easy to package a web app into an Android app. But users generally dislike that.
The trend is not towards HTML5, but actually away from it. Quite honestly the Chrome Mobile team are swimming against the tide on this.
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.
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.
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).
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.
What exactly are you expecting to get from the mythical "ChromeOS and Android merger", when you already have Chrome for Android?
The only major things I see ChromeOS has over Chrome for Android is the security model, which will be impossible in Android, since you need native apps, too, while ChromeOS will only ever work with "web apps". Changing that could mean its security model will suffer.
And the second one is the upgrade process, for all Chromebooks, coming straight from Google, every few weeks. That's ideal, but I doubt we'll see anything like that for Android even this decade.
Seriously. I don't get this knee-jerk desire to have ChromeOS and Android become some sort of weird hybrid. They're two different platforms. Their combination isn't necessarily greater than the sum of the parts.
People must be playing too much Katamari Damacy or something.
Something needs to change, since the Oracle lawsuit, Java/Dalvik features have been frozen without any new update being officially communicated.
The only way Dart will have any future is if Google makes a requirement to use it somewhere.
- Provides a familiar language with clean semantics and low ceremony
- Provides the fastest dev iteration times (there's no compile step,
just edit + run in Dart VM/Dartium)
- Provides ~10x faster start-up times than JS with snapshots (Dart VM)
- Provides faster run-time performance, that's predictable and can take
advantage of real integers and SIMD instructions (VM Only)
- Provides a unified object model so all classes from all libraries are interoperable
- Providing a rich, well-defined, consistent API, real collections, removing JS WATs,
smoothing over browser quirks
- Provides a unified and composable IO model: Futures and Streams (repeating events)
- Provides a new powerful way to develop client apps with Web UI (Polymer/WebComponents)
offering unprecedented levels of encapsulation and reusability
- Provides optimal dev and deployment options, you never have to worry about choosing
the smallest libs as tree-shaking ensures only code used is compiled and minified
- Providing "full-stack" dev environment, e.g. same language on client and server
Sorry, but I lost count of the languages I have used since 1986 and just don't believe in Dart ever taking off unless Google makes it so.
And less points were covered by Java, and still it got to the top of the language pile.
I've also used a number of languages in the last 15 years, and I've personally found Dart to be overall be the most productive which has become my go-to language whenever I need to something quick done. It's missing an ecosystem of mature libs which popularity helps most with - but Google has a ton of investment behind Dart which is developing the entire platform (language/libs/toolchain) giving it its best chance to succeed - if it fails to gain any traction it wont be for technical reasons. It looks like it will take over and be the preferred to succeed GWT and Closure Library, with internal usage it should see continued investment for years to come.
Smaltalk had it.
> - Provides the fastest dev iteration times (there's no compile step, just edit + run in Dart VM/Dartium)
Smaltalk had it.
> - Provides ~10x faster start-up times than JS with snapshots (Dart VM)
Smaltalk VMs, actually Self, were where the first usuable JIT compilers were developed.
> - Provides faster run-time performance, that's predictable and can take advantage of real integers and SIMD instructions (VM Only)
Self and StrongTalk were quite performant. SIMD was not available back then.
> - Provides a unified object model so all classes from all libraries are interoperable
Smaltalk had it.
> - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, smoothing over browser quirks
Smaltalk had real collections.
> - Provides a unified and composable IO model: Futures and Streams (repeating events)
Smalltalk has streams.
> - Provides a new powerful way to develop client apps with Web UI (Polymer/WebComponents) offering unprecedented levels of encapsulation and reusability
Fare enough regarding WebUI, as the web did not exist back then. However Smaltalk is responsible for the MVC concept.
> - Provides optimal dev and deployment options, you never have to worry about choosing the smallest libs as tree-shaking ensures only code used is compiled and minified
VM pruning in Smaltalk environments for deployment.
> - Providing "full-stack" dev environment, e.g. same language on client and server
This is only true when using Dartium. Transpiling to JavaScript does not count.
Smalltalk's syntax is anything but familiar, which for programming languages means C-inspired syntax.
> Smaltalk VMs, actually Self, were where the first usuable JIT compilers were developed. > Smaltalk had it. > Self and StrongTalk were quite performant. SIMD was not available back then.
Where are the benchmarks? Alan Kay wanted to kill Smalltalk in the 70's because the way they done things like reflection was done and performed poorly. The computer language shootout shows Dart outperforming Smalltalk by several factors for most things and their still working hard on improving performance with v1.0 of Dart not even released yet: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: many of the VM team that were originally on the StrongTalk VM team are working on the Dart VM now who have a heavy influenced on how Dart is designed to ensure it retains a great balance of productivity and performance.
> - Provides a unified object model so all classes from all libraries are interoperable > Smaltalk had it.
Not a coincidence either, Dart's object model was inspired from Smalltalk as many of Dart engineers were from Smalltalk heritage.
> - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, smoothing over browser quirks > Smaltalk had real collections.
But does nothing to simplify web programming, which was the point of this.
> - Provides a unified and composable IO model: Futures and Streams (repeating events) > Smalltalk has streams.
Dart is single-threaded and uses Future's for composing async operations for all non-blocking operations which is the default. Like most languages Smalltalk IO is mostly blocking and multi-threading and has poor support for non-blocking operations.
> Fare enough regarding WebUI, as the web did not exist back then. However Smaltalk is responsible for the MVC concept.
Right, but because its effectively non-existent for web programming we'll never see proper support for web technology like Web Components or tooling like TreeShaking, bundling.
> VM pruning in Smaltalk environments for deployment.
Which means nothing for web deployment and is less useful on the server where size is less of a factor.
> This is only true when using Dartium. Transpiling to JavaScript does not count.
Transpiling to JS does count, Dart has great source-maps support letting you debug Dart code from inside browsers running Dart2JS. But in terms of Native VM not running any JS, then yes Dartium now, Chrome in future and possibly Opera by virtue of Blink.
People could have said the same thing about Go, and yet it's catching up quite nicely.
It doesn't have to bring something "new", just a coherent offer, and that it does.
Yes, in a few places that get lots of up-votes in HN.
In the real Fortune 500 world, it is all about JVM and .NET languages.
although in that article, they also claim chrome apps are going to come to iOS including availablity in the iOS app store, which sounds really really unlikely.
P.S. while trying to add this new type of app, I was tricked into signing into my chrome account, which I had managed to avoid all this time.
I've started jumping the Google ecosystem. I'm now more often than not, not signed into a Google-account, to the point where I can go a week without signing in at all.
No way I'm joining a program which requires me to reverse on that.
My guess is that Chrome Packaged apps will be the replacement for WebViews on Android.
Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview
"Attempting to scroll the view (by swiping a finger across the screen) does not update the displayed image. However, internally, the view is scrolled. This can be seen by displaying a stack of buttons and trying to click on the topmost one. This issue makes ChromeView mostly unusable in production"
Have you used ChromeView successfully in a production application? This seems like a deal killer.
A stop gap that adds at least 30mb to your application is a really shitty solution.
For example: https://www.google.com/search?q="requires+adobe+air"+bloatwa...
Also, I don't care what Facebook says.
If they would do this we'd have a new set of apps that behaved and felt very differently which would probably cause a lot of confusion among users.
What I could imagine is some kind of framework that makes it easier to share data and state between a Chrome app on the desktop and Android apps on mobile.