81–90 of 169 posts
Earlier quoted context omitted.
This maybe an option in the making: https://code.google.com/p/dart/wiki/Android
This is actually the only place where I see a future for Dart.
They need to improve the APIs for developers though, a Visual Studio 6 for Chrome platform development, probably the high point in softees history. Really tie together web with more traditional native api development. No-one has cracked that yet.
Chrome is a resource hog. I don't want that on my phone, which barely lasts 4 hours idling in my pocket. Thanks but no thanks. On my Mac, Chrome with 20 open tabs is always using most of my memory and CPU.
Earlier quoted context omitted.
This is actually the only place where I see a future for Dart.
I like Dart, it's the most productive language/environment I've ever used and if it's unable to gain any traction on its core objective building of client-side complex web apps, it will still have a compelling server-side story ala (node.js) after v1.0 is released and the ecosystem catches up with it.
The only way Dart will have any future is if Google makes a requirement to use it somewhere.
Earlier quoted context omitted.
I like Dart, it's the most productive language/environment I've ever used and if it's unable to gain any traction on its core objective building of client-side complex web apps, it will still have a compelling server-side story ala (node.js) after v1.0 is released and the ecosystem catches up with it.
Server side is already too crowded, there is nothing that Dart brings to the table. 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
Earlier quoted context omitted.
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 yo…
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.
Prediction: 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?
I don't know if the convergence will happen, but they certainly need to fix WebView in Android to at least allow migration. It's still using the old Android Browser and is severely outdated (no WebSockets, etc). 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
A stop gap that adds at least 30mb to your application is a really shitty solution.
Google says that "packaged apps are written in HTML5, JavaScript, and CSS" but the first one they show, Pixlr Touch Up, is actually written in Flash. New breed, eh?
Prediction: 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?
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 /…