For some reason the website fails to prominently mention the two defining characteristics: it's based on Dart and it uses its own widget implementation.
Honestly, between the use of a relatively exotic language of dubious quality with types that are "optional and unsound" (https://www.dartlang.org/articles/why-dart-types/), their custom widget implementation that who knows how well is going to work, and lack of web support, it doesn't seem very attractive.
It's true that Dart is an optionally-typed system, and that type annotations are ignored at runtime. That may seem scary at first, but we built an analyzer that statically analyzes your program and gives you feedback (errors, warnings, and hints).
Dart is used at Google to build very big and complex apps, and our engineers use the analyzer in their build/CI systems to check their program. The analyzer is also wired into their IDEs. So they get feedback if a method doesn't exist, or you are trying to pass a variable into a method that is expecting something else.
The Dart team is also working on an optional analyzer feature called "strong mode", which does even more static checking. In strong mode, you can't write code that is incorrectly typed (but, you can still write code that is dynamically typed, if you want to).
Our experience, at least internally, is that as your program matures and grows in complexity, developers appreciate the extra checks provided by strong mode. The win is that it's something you can turn on later, when you're ready. Early on in the program's development, you are probably refactoring a lot and you don't want to bother with strong mode. This scalability is a win for us.
So for those of use outside of Google, it's not a "smooth" environment to work in. I wish we have the tools that you have. Are they available outside of Google?
Dart + "Unfortunately, due to iOS restrictions, updating your Flutter app over the network is not possible" means 100% no thanks from me.
I don't want another language in my build ecosystem. Between javascript (necessary for web), objective-C, Java, C++ for shared stuff, adding another one that provides no genuinely useful semantics or performance implications is a sheer non-starter.
I am sorry but part of your comment smells a little bit like a red herring, what is the language of react-native? Ah.
Website clearly stresses that the main point of flutter is to build cross platform high performance applications. I think language of choice is of lower importance. There are still many developers who would not touch javascript with a ten foot pole but I can see them using a saner language like Dart. It may find its place.
It's definitely saner to use something that has a community and traction. You definitely can't argue that Dart is a saner choice of language than JavaScript. After all if they'd chosen JavaScript, Dart could be useable via compilation. So would a whole bunch of other more commonly known and probably saner languages.
Sane by your definition is not the same as my definition then. A community can't grow if people aren't a part of it. Using Dart is one of the best decisions I have made in my life.
I gather you're already compiling it to JavaScript, though? Otherwise your audience would be very limited.
The decision to use Dart for this project seems to me like an attempt to find a lifeline for it. That's fair enough, but it could ultimately be a highly limiting factor and the reason it doesn't go anywhere. That would be a shame as cross-platform frameworks need to keep evolving to be more useable and performant.
"There are still many developers who would not touch javascript with a ten foot pole but I can see them using a saner language like Dart." haha sir you need some reality check.
I used to hate JavaScript. It is a very imperfect language, but many of its pitfalls come from widespread mediocre practices and craftsmanship, rather than the language's quirks.
But do you program in Dart? My point is, when given a choice I can't see a reason why someone who would invest their precious time to learn some relatively obscure language like Dart would NOT learn javascript. Also hating something and not using it are two different things. You say you hate javascript but you probably do use javascript.
Funny you say that given JavaScript's immense popularity. JS is by far the most popular and easy to learn language out there and has a large, inclusive community. There are little reasons to knock JS these days, especially with the upcoming language extensions and powerful tools like Babel.
React Native in my eyes has done a fantastic job of demonstrating highly performant JS driven applications that are accessible to tons of developers. An added bonus is the luxury of bundling in millions of existing NPM modules along with existing native modules. Facebook in my eyes is doing better at solving the code portability problem than Google, they are extremely focused, whereas Google, they want us to build things in a million different ways. Which direction do we go? Web components? Angular + Typescript? Dart + Flutter? Or maybe some new development far on the horizon that is the new way?
Web Assembly is on the horizon so we will see. In the meantime, how do you explain meteoritic the rise of JS? Why do devs choose to use tools like Babel over Emscripten? Why is it that companies like Netflix, PayPal and LinkedIn, etc all utilize and embrace NodeJS? Why is Facebook so interested in using JS for future apps rather than native languages? Your theory is very short sighted and based in fantasy
The big draw of React-native is that I can reuse largely the same core code everywhere, and for the parts I can't (mobile UI), I'm at least working in a language that everyone on my team is familiar with, with the same pattern as elsewhere (react/flux).
This to me sits in a weird middle ground between RoboVM/Xamarin and Cordova, but has the benefits of neither (it uses a language that I'm not already familiar with, and doesn't give me access to native controls).
Am I being unfair? (Is there a killer feature here I'm not seeing, beyond being backed by Google?)
I've only had a short look at this but here are my impressions :
It doesn't pack a huge VM/class library like RoboVM/Xamarin and doesn't try to gap two VMs/GC like Xamarin on Android - instead it uses IPC for talking to system services using it's custom service definition language to define the IPC API/schema in cross language way.
Dynamic language/custom VM lets them do a better job at development experience (dynamic code reloading) as opposed to buggy/complex one you get from trying to statically compile bytecode or bridging two VMs to share objects.
IPC architecture then lets you write performance parts in portable native code (eg. C/C++/Rust) or system specific language (eg. Java/Swift/Objective-C) and it should be easier to make cross platform - hiding the dirty FFI crap.
Dart is much closer to C# than you think, go look at some examples - it's quite a productive language from my experience with it so far.
Custom GUI framework means it doesn't behave/look the same as native framework (just like webview tech) but at the same time it can also mean higher performance (certainly better than WebView), consistent behavior between platforms and versions (faster development), etc.
Overall I like it, I can see a GUI framework on same tech built for desktop (custom widgets but same rendering principles) and doing client side development in Dart sounds great - fast prototyping and iteration because of it's dynamic nature but the optional type system gives you same guarantees as C#/Java type systems.
I totally agree with you with regards to the language itself sharing similarities with C#, and you make a good point about avoiding all the FFI native calls hassle.
I couldn't find a whole lot of independent benchmarks but I'd suspect that at least in Chrome, it does outperform V8.
I guess I'm just not the target developer for this, though. If I want optional static types I can implement typescript incrementally into my existing stack, while retaining the code portability benefits. For desktop apps, NW.js is aiming to plug that gap, and I wouldn't have to give up my npm modules.
Another poster mentioned waiting until it sees a push at Google I/O before taking it seriously. I'd settle for them just to explain the problem case that drove it's development.
EDIT: I hadn't spotted harryf's reply below that makes the point about transparency better than I have above, kudos.
> It doesn't pack a huge VM/class library like RoboVM/Xamarin and doesn't try to gap two VMs/GC like Xamarin on Android - instead it uses IPC for talking to system services using it's custom service definition language to define the IPC API/schema in cross language way.
A minimal "Hello World" RoboVM app adds 3mb per CPU slice. I'd assume packaging the Dart VM has a similar footprint.
I've heard tales of Google engineers creating tools and frameworks largely as a way to attract positive performance reviews and enable promotions. That said there projects like Google Web Toolkit that have a long history and well cared for. Perhaps some transparency would help i.e. instead of "this was made by Google" how about "was made by this team at Google for these reasons and here's where we see it going"
And still Google Web Toolkit slowly gets deprecated.
The problem on GWT is that it builds too slow on bigger Apps, while ScalaJS builds even faster. Also the compiler needs to be reworked on lot's of side, I'm not sure if 2.6, 2.7 will handle all these problems.
But I don't think that GWT gets a 3.0. But thats mostly caused by the fact that this is a really really old technology and there are newer technologies which google builds upon. (AngularJS). They replaced lots of GWT Things already (Cloud Console, Google Apps Console, App Engine Console).
Gwt mostly got abandoned. Far better solutions like teavm that we use at Codename One are available.
GWT is now maintained by the community and not by Google.
QML is slow, you only get the compiler in the commercial version.
Still no proper support for mobile platforms. You basically have to write most of the bindings yourself. Specially a pain in Android, given JNI.
Only QML widgets get some platform theme support, not the C++ ones, so you need to add the QML engine to the set of libraries to pack.
Also you are supposed to code all native UI behaviours yourself, thus having more work than an hybrid development of native mobile OS language (views) + portable C++ libraries (business logic).
If you pack Qt libraries with your application it is around 30 MB for the runtime dependencies. You can also scare the user by asking them to download the libraries as separate app instead.
I got my demo application using Java + C++ and C++/CX + C++ around 5 MB.
Finally if you look at the set of exposed platform APIs across all mobile OSes, they are way behind Xamarin and their commercial licenses are much more expensive.
None of answers is correct in my opinion. I follow Qt/Gtk news from old days (2005-4). The problem with Qt right now is its direction is not clear , all people remember when Qt was only C++ widget library.after a while because of one person decision they change whole direction to QML and RICH application development, and who knows ? maybe they changed it tomorrow again . at least behind react and and flutter and cordova there is big name
while that is certainly true, using QML you can build native apps using almost only javascript (if you want), most people have no idea about that too i suppose.
but i agree, for many people C++ is a no-no, even though Qt C++ is pretty straightforward with all the helpers they provide (like the parent-child memory management).
You can write all of your Qt logic in javascript if you want to. It will probalbly still be much faster than a browser. But the thing is that Qt allows you to write your logic (and your ui) in C++ if you need to. It gives you somewhere to go when performance is an issue. And on mobile or embedded there is a high chance that only a compiled, no-vm, no-gc language like C/C++ or Objective C or Rust will give you the performance you need. One thing is for sure: If you have to build a cross platform native application be sure to first prototype the performance and processor/battery use of your technology choice. Even if you don't choose something like Qt at least you can write your backend in C++ and write a different native front end for each OS. But if you use e.g. web technology and don't prototype first there will be absolutely fire escape later. A lot of people have learned this the hard way.
> You can write all of your Qt logic in javascript if you want to. ... But the thing is that Qt allows you to write your logic (and your ui) in C++ if you need to.
Maybe that sounds appealing to some, but for me is just choosing between two evils. Unsafe dynamic language on one side - kitchen-sink low-level language on the other side.
I personally would like something in between, but still cross platform. F# with Xamarin looks most appealing to me, but Xamarin is unfortunately not free, so...
All these QML/js stuff smells rather artificially put (into Qt) to me... I mean, why not have a functionality to define the scene (and not just a logic) in pure C++? I think one reason for QML/js is to (try) attract contemporary js/web devs.
Last time I checked (Qt 5.3), I was forced to duplicate native widgets on my own, and write my own Framework wrappers on Android, with zero support for Windows Store applications.
From what I could understand in the Qt 5.5 release notes, this has hardly changed.
I think it should support platform own widget or an abstract UI framwork implemented by playform api like facebook's react native.
Flutter's own widget implementation can make simple apps,but it is more difficult to implement native style UI with rich user experience (animation,touch...) provided by platform api.
Looking at own widget implementations such as Delphi/firemonkey,Qt/Qml,JUCE...,they are far behind native widgets
Ho come on, that's the flutter sources. Why is it so popular on HN to "debunk" points with irrelevant statistics? As if numbers win arguments no matter what?
The point is that Flutter application code is intended to be 100% Dart. Just like React Native application code is 100% JavaScript (and React Native itself isn't).
And at the same time another group at Google is working on Singular, again cross platform development for Android, iOS & Web (web is not for Flutter), which works in AnuglarJS-like fashion. There is a difference though, Singular doesn't go into widgets (you should use platform specific). Maybe they will be able to merry them, but I doubt, so we will need to choose.
I'm cautiously optimistic about Singular; they've "gone dark" and are implementing it internally, which is kind of disappointing.
But for someone (e.g. me) who:
a) thinks the skill set reuse of React Native is genius (reuse the UI framework/mental model, and purposefully not the widgets), but
b) doesn't like Javascript, I think Singular has the best chance at winning my personal mind share.
Of course, "doesn't like Javascript" is a minority mindset these days, so in terms of community/etc. I'm sure React Native is going to be very strong.
In terms of Flutter/Singular, Flutter trying to play the "write one app for N devices" is interesting...AFAIK, that's something React Native/Singular are explicitly trying to avoid, since historically it's resulted in sub-par UIs on each device.
But it would be an interesting coup if material design meant developers (and users) really did want/expect the same exact L&F on both Android and iOS.
I am never basing architecture on small Google projects again.
We use app engine which has horrible support and billing. We used to use GWT which is no longer maintained. I just don't trust Googles commitment to anything it releases. They throw stuff against the wall to see if it sticks and I ended up with sludge on the floor one time too many.
> We used to use GWT which is no longer maintained
I understand where you're coming from, but FWIW this is incorrect: Google has a team of ~4-5 engineers still actively making changes to GWT, and even currently prepping/testing a new release.
Interesting, I had not heard of this. Personally I find HTML to be the best layout system there is, besides animations, and I'm not even a web developer. I like Dart, but its not statically typed and Flutter uses its own layout system.
Swing didn't have baseline alignment until Java 1.5 iirc, so you couldn't put a label next to a text box without it looking dorky. And the controls felt slightly uncanny on every platform.
"Flutter is optimized for 2D mobile apps that want to run in both Android and iOS. Apps that use Material Design are particularly well suited for Flutter."
Which means that, if Flutter succeeds, iOS users should expect to see more and more apps built using Google's Material Design language. It's already happening for some of Google's iOS apps--the floating action button in Calendar, Hangouts, Photos, Docs, the iconset in most of their iOS apps (Gmail and Chrome are partial exceptions), etc.
In other words, Material Design is making significant inroads into iOS. But Apple's design language isn't doing the same in Android world.
Disclaimer: I'm a cofounder of Recent News (https://recent.io/), and we borrowed some Material Design concepts for the iOS version of our app.
if Flutter succeeds, iOS users should expect to see more and more apps built using Google's Material Design language
You may see that for big must have apps from Google like gmail or Maps where the user has little choice. But if indie developers try pushing Android-y looking apps on iOS I would suspect most of them would lose out to an app that utilizes the native design language.
> But Apple's design language isn't doing the same in Android world.
I don't how long ago you started using Android, but iOS design language was in a lot of Android apps. For example, a "Back" button on the top left corner when Android had a hardware (later software) back button, and navigation controls where normally at the bottom. I blame designer's who insisted on 'direct' ports of iPhone apps.
Too many designers worship on the alter of Apple: I remember when brushed aluminium backgrounds where the rage (even on websites), this was later replaced by "linen" backgrounds and gossamer-thin font-weights everywhere. So I beg to differ: Apple's design language was making "significant inroads" on many platforms (web, native windows apps), not just Android.
I must confess I feel a bit of schadenfreude on the turned tables.
Apple's design influence reaches everywhere. While Android apps don't visually mimic iOS, the tons of designed interactions that were introduced on iOS (not necessarily by Apple but it's dev community) are frequently replicated on Android apps. It's just now that Google has a good enough design language that we can all be proud (depending on who you ask) to implement on all platforms
I wouldn't be surprised if this is Google's longer-term solution to the Java problem. It's clearly not tenable for them to stay on Java 6 forever so they either need to make web-based apps first class citizens on Android or put forward their own new stack.
When it started out it was completely uninteresting as a language and it's only selling feature was that it someday might find it's way in to browsers and that it compiles to JS.
Now that it's ditched the whole "replace JS in browser" the language has actually matured enough to the point where I would code in it outside of browser use case and the VM quality puts it in a unique performance/productivity spot. It is very much a hybrid of C# and Python in good ways with a decent package manager built in.
It's much more suitable to be viewed as a high performance Python replacement - unlike Go it's dynamically typed but offers optional static typing so the level of abstraction is much closer to Python - in fact I would argue that the static typing built in from start makes it more productive than python for project you need to scale up to multiple people.
But it was built by a VM team that knows how to get performance and knows the bottlenecks that prevent JS optimizations - so it's probably faster than V8 and the likes - not CPyhon level.
The VM/class library is small and embeddable which separates it from Java.
And finally the compile to browser was a design choice from the start so compile to JS is much simpler than existing languages (eg. Python/Java)
It's a great language for client side programming and it's usable in server side if you are already using it for client side and want same languages on both server and client.
Dart is still much much closer to JS than C#, specifically in terms of threading, native interop, value types, etc. Until these are all improved I just don't see a compelling mobile story for Dart when compared to Java.
Furthermore, TypeScript, Facebook's Flow etc provide stronger static analysis than Dart.
>specifically in terms of threading, native interop, value types, etc.
AFAIK the VM they are working on for mobile has green threads (aka. isolates), value types are irrelevant at this level of coding and interop is arguably better than standard FFI with their IDL/IPC system.
It's actually a perfect frontend language where you delegate stuff where you care about threads/memory layouts/performance/etc. to native code in whatever language that has bindings for their IDL.
TypeScript, Flow, etc. are JS type systems - Dart is a programming language - it's superior to JS in that it has sane semantics and standard library/collections, etc. It also has stuff like async/await shipping for a long time now (still not in TS official).
"It's strange how much it looks like web development" - It looks a bit like a browser for native app development. To me it looks like it could be the solution to a lot of problems. What is good about the web for applications is that it is write once run everywhere (because people do not expect a native look and feel) and also that it is zero install. What is bad about the web for applications it is that it is designed for content presentation and not applications. For mobile it has a number of things that limit it for performance. To get something to even approach decent performance I have to try to understand a complex and opaque machine called the browser. Compared to native app development this is a lot more difficult. The machine is working against me because its primary concern is document layout.
So it looks to me like a browser for applications in resource constrained environments (mobile). I see nothing wrong with this; We used to have innovations like this all the time but since the browser came along its been a bit of a tyranny of orthodoxy. Why not have a browser for documents and a browser for applications? I certainly don't like web apps in my browser for content sites. (They don't work at all, or the scrolling is all over the place or they burn up my battery).
For the moment though they seem to be clear that flutter is for application development on android and ios only and won't run everywhere. Plus Apple will probably never allow zero install (which knocks out half of my "browser for applications" theory, the other half being write once run anywhere)
It's strange how much it looks like web development
I saw a talk that discussed this - it's deliberate. Flutter is intended to be a lot friendlier to web devs, to let them bridge the gap between mobile web and mobile native.
Yes, strong mode is something the Flutter team uses to help check their code.
Dart is pretty cool this way: you can scale up or down how much "typiness" you want. As your program matures, you can dial up the static type checking. Hence: strong mode.
and this:
We are building a Flutter plugin for Atom. Today, it can syntax highlight, code complete, refactor, launch apps, create new apps from a template, show type hierarchies, jump to definition, and more.
Why not Android Studio ? this release announcement is weird. it seems to be as much political as technical.
I think they are trying to be more friendly to non-android developers , and you may noticed this is platform for both iOS and Android . If it were for only android they you were right, but as it stated they targeting iOS too, then we can deduce they are trying to be more like React or Cordova(if I spell correctly).
p.s. It seems that is their approach , does not mean I agree with that.I would prefer android studio support. Then they can advertise android developer can produce iOS version of their app in android studio too.But clearly they want be more like react.
Intellij Idea and Webstorm already supports Dart as language. I am guessing they wanted something lightweight initially. Since Flutter is in pre-alpha state, support for Android studio may come later.
honestly, my atom must have something wrong as it hangs like I'm working on a 386 with 1MB ram on startup, open file (I will let you imagine what happens if I open the occasional unfortunate file with long lines)..., and I'm not even taking in account the feature mismatch. I come from vim so I can appreciate a text editor, it's not I'm an IDE lover or anything...
Atom is a good choice to get started on editor integration because it's easier to develop for using a language that can compile to JavaScript. But the underlying technology (Dart analysis server) works with multiple editors and IDE's.
Yeah another caution of mine. I would very much not like my projects to be a causality in an internal political war at Google. Who knows what might happen down the line...
I get the feeling that Android Studio is a ship on the seas of Google with a helmsman of sorts but with a flotilla of smaller boats around that vie for attention.
The new features they introduce look interesting-ish but there are big problems, and I suspect that bundling Flutter into Android Studio, whilst a good headline, would not be high in the list of priorities.
For example, the C++ NDK is still not properly supported in Android Studio, despite the message that Eclipse is being deprecated at the end of next month. I have ran into numerous issues with it which has meant I have to currently abandon hope of porting this C++ library across to it.
Issues I have ran into:
a. I can either run the emulator with resume support and no GPU acceleration so that it is dog-slow to use, or have GPU acceleration and the very slow startup of the emulator.
b. On my Mac, it will randomly not install or find the device with adb (oddly intermittent!).
c. The emulator does not support WiFi, meaning monitoring apps that rely on wireless and multicast and the wireless interface being there are impossible to debug (the app makes checks for the wireless interface being available and uses its address to join an interface lower in C++ land). What's the point of the emulator, I hear you ask?
d. You have to jump through Gradle hoops to stop the ndk-build system generating its own build script and to get it to respect your existing Android.mk and Application.mk files. Getting it to build static libs involves bulding shared libs and then adding another build command to include that static lib into your dummy shared lib. Static libs that you build in a build process will not be automatically copied to the APK library - only shared ones will.
e. My application is having problems with OpenGL textures early on but breakpoints for NDK C++ apps will NOT be hit until 10 seconds after program startup...... this is really rubbish; I can't stress how unfathomably lame this is.
f. Android Device Monitor (DDMS) does not support networking monitoring for Intel images (https://code.google.com/p/android/issues/detail?id=25997) so you can either have a fast Intel emulator with no network monitoring support, or you can use the dog-slow ARM software emulator with network monitoring support, with the caveats that the wireless interface you depend on will be missing from the emulator, and that your breakpoints during program setup will not be hit etc. etc. etc.
g. Android Studio randomly stops accepting keyboard input. Random background crashes happen (but the IDE does not disappear).
I cannot see Flutter being high on the priority list here.
I use C++ for portable code between Windows Phone and Android. Slowly thinking about jumping into a JVM/CLR friendlier language though, without JNI/NDK headaches.
Currently my mobile development is just an hobby.
Based on my experience, the issues related on the NDK issue tracker, the mailing list, IDE support, Google IO talks and the state of the still experimental and incomplete Gradle support, it feels as if the Android team was dragged into supporting anything else other than Java.
At least you manage to hit the breakpoints, on my cases the IP just flies by the address never stopping.
Compared to the tooling experience on Windows Phone or the few cases I used iOS at work, one feels as if they only do NDK development on as needed basis, but actually it would be better if the NDK never existed in first place.
If I was on the NDK team I would feel ashamed that Microsoft and NVidia are able to provide a better developer experience than the platform owners.
Yes this is precisely how I feel. I have spent days trying to get a decent development platform (can't remember how I got breakpoints to hit, I think after upgrading to 1.4 things stopped working) so I have completely given up. I can really see why development is typically iOS first and then Android second.
And I say this having written Android applications in Java (no problems there really) and now getting my feet wet in iOS with Swift/ObjC.
I agree with you about the NDK being a thing they never wanted to support. You can see this in the documentation where they state that applications should be written in Java for Android, first and foremost. But given that the underlying libraries can be compiled under Windows, OSX, iOS etc it makes sense to have a C++ system for Android too. It's a pity that it's such a complete mess, and is at best a complete joke.
The engine’s C/C++ code is compiled with Android’s NDK, and the majority of the framework and application code is running on the Dart VM. The Dart VM generates JIT-compiled optimized native code on the device. (In other words, the Dart VM is not an interpreter.)
So Google is officially making its stand as Dart being the future of Android (the Swift of Android?).
Anybody who has worked on this and Kotlin, care to compare ?
EDIT: how does this work inside Google ? I mean you have legendary heavyweights behind Go. Were they designed as domain specific (Go for server and Dart for mobile)?
Dart was originally designed for the client-side as a challenger to Javascript, and I consider it to have generally succeeded in its ulterior goal of spurring the Javascript standardization committee into greater velocity out of threat of competition. Recently it's pivoted towards server-side programming, though I could see it finding a home in mobile app development. Given its familiarity to Java, it was always more likely than Go to succeed Java on Android (though IMO less likely than a typed variant of Javascript).
To be clear I don't think this is an "official stand" proclaiming Dart as the future of Android (and regardless of Oracle's asshattery, I don't see Google outright removing Java support any time soon). As other commenters have pointed out, Google has more than one ongoing initiative in this area.
> Dart was originally designed for the client-side as a challenger to Javascript, and I consider it to have generally succeeded in its ulterior goal of spurring the Javascript standardization committee into greater velocity out of threat of competition
Dart was never a threat to JS in anyway. I don't think it had any effect on ES spec. ES spec evolved "faster" because the committee changed, the old guard (anti OO ) moved on and Microsoft didn't sabotage the effort this time. Things were way different back in 2007 for those who remember it. MS had a commercial interest in not wanting ES4 to succeed ( Silverlight ) while ironically Adobe and the Flash team were pushing for a strong standard. So I fail to see how Dart has anything to do with ES6 success.
I tend to agree that Dart was never a "threat" to Javascript (smarter hackers than I have remarked at how difficult it would be to have both V8 and the Dart VM playing nicely together), but at the time of its announcement Dart (nee Dash) was certainly the cause of much consternation over potential fragmentation of the web. I recall more than a few of Brendan Eich's impassioned denouncements of Dart during that time. Dart's origin was just as much political as it was technical (though I do think it's transcended that origin to become quite a nice language, though still trying to find its foothold in the dev community).
Google is notorious for officially funding multiple competing solutions to every problem under the sun. I'm not trying to discount how important this is for Dart, but this announcement here doesn't carry even a thousandth of the heft as e.g. Apple's support for Swift over Obj-C.
The C# runtime on android is used by thousands of apps; this is simply a dart runtime that runs on android.
This is a cool project; and its great to see people trying to do interesting things with dart; Dart as it currently stands is a total and abject failure in all of its goals as a replacement for javascript.
New goals for it to live as a mobile platform might give it a breath of fresh air. Pretty nice to see; it's a nice language with a good ecosystem, if it gains traction as a 'app' language, it could go places.
...but this is absolutely not Google saying 'the future of android is dart'.
> So Google is officially making its stand as Dart being the future of Android (the Swift of Android?).
It's almost never accurate to use "Google" as a singular noun. We are a very large company, and teams are given much wider latitude than at most other companies, so there is rarely a single official "voice" representing what Google is doing.
Instead, you have a lot of teams each working to make the best thing they can. Some of these projects overlap, sometimes they coordinate, occasionally they even compete with each other. Google is big, and the world is even bigger. There's a lot of room for different solutions to problems.
I don't work for Google, but as far as I can tell Go was developed for helping with Google's internal server issues. They found the C++ code to be too difficult to get new Googlers acquainted with, and they had legal and other issues with Java. Dart on the other hand is a migration path for their heavy use of Java in front end areas for cross client-server usage with their GWT toolkit. It's also designed to make Javascript 'nicer' to use for some of their developers who do not like using Javascript.
However, Google is really big with a lot of differing opinions. They still have a lot of developers working on GWT. They still have a lot of developers heavily involved with C++ standards etc. So some Googlers are not going to be giving up Java or C++ any time soon. Some Googlers who really like Dart want to use it for everything. Some want to use Golang for everything. So the languages aren't really pushed or designed to be complimentary and they're more along organizational boundaries inside Google.
From the last words on the topic, Android itself is still staying fully Java and Dart or Golang will be alternative ways to deploy certain kinds of applications to Android which don't need very heavy integration. This Flutter appears to be closer to a Google replacement for javascript-based Cordova cross platform apps in the same way Dart is designed to be a replacement for Javascript websites.
Note that the legal issues with Java revolve around Google's custom implementation of Java that ships with Android, which is certainly not the version of Java that Google is using for its internal server programming.
Flutter ships with a functional-reactive style framework, inspired by React.
Flutter gives developers access to any service or API that the host operating system provides, via Mojo’s IPC system
If I can write android apps with the SAME performance as Java, then this is effectively a replacement for me. I was seriously considering Kotlin, but with Google making a play here - this is the way I'll go.
pjmlp, according to the FAQ, the mention the performance in a section
"You can expect excellent performance on both Android and iOS. Flutter is designed to help developers easily achieve a constant 60fps. Flutter apps run via natively compiled code, no interpreters are involved"
But I'm no Android developer so might just be marketing fluff.
It's a custom UI framework, you will only need to use JNI to call system services which shouldn't be a bottleneck - rendering engine is written in C++ AFAIK and it then uses IPC to talk with it.
IPC is usually slower than JNI specially on ART, because ART can optimize native calls across the boundaries better than Dalvik since the interpreter/JIT execution mix no longer happens.
Android's hardware renderer does not use Skia for 2D drawing. So if your canvas returns true from canvas.isHardwareAccelerated() (and it should unless you're running on Gingerbread), it does not use Skia.
I think they update their benchmark results to https://chromeperf.appspot.com/ (browse for benchmarks with mofo prefix)
Looks like pretty damn fast to me.
I find that hard to believe. I think someone who doesn't understand the architecture wrote that or that Google opened a semi truck sized security hole.
Jit requires self modifying code. That's a huge security risk on devices which is why 3rd parties aren't allowed to ship jits. If Google makes a special case for Dart that would be a huge hole.
I'm guessing they just use AOT like the rest of us which is required on ios as well.
Where would we be without alternatives for developers? Should C# never have existed because of Java? Or any language for that matter?
Flutter exists because some people (also internally at Google) enjoy writing their stuff in Dart, so they created this tool for themselves, which they released in public.
People shouldn't get upset nor should they feel threatened by alternatives to their preferred tools.
Although I think this gives Google too much credit of forethought. Most of these projects are as Eric Schmidt used to say "throw stuff against the wall and see if it sticks".
I investigated Flutter some time ago after seeing it mentioned on HN, and it is quite fascinating - as an Android user. It has a stated goal of 120fps on all UI elements, which would be a huge step in bringing sluggish-feeling Android up to the levels of iOS.
But Flutter is also intended as a cross-platform framework for iOS too. That part I'm less sure about, though if it lives up to its promise, it would be great. Overall though, far too early to tell. Using Dart might not be popular, but if you don't already know Objective C/Swift and Java, it might not be any worse than today.
Not quite sure how props are passed but it does have that concept... anyway if you're going to copy something might as well change some of the names of the functions :^)
I'd say React benefits from not having a bundled UI library, instead using native components (and obviously includes web). Google would have been better to go with embrace and extend on this one.
React Native's basic navigator component is non-native and implemented in a way that has fundamental performance problems. There is also a native navigator component for iOS, but it's buggy and unmaintained to the point of being unusable. The list view also has issues. See e.g. issues like these:
"Many people have noticed that performance of NavigatorIOS is better out of the box than Navigator. The reason for this is that the animations for the transitions are done entirely on the main thread, and so they are not interrupted by frame drops on the JavaScript thread. (Read about why you should probably use Navigator anyways.)"
"... As mentioned above, Navigator animations are controlled by the JavaScript thread. Imagine the "push from right" scene transition: each frame, the new scene is moved from the right to left, starting offscreen (let's say at an x-offset of 320) and ultimately settling when the scene sits at an x-offset of 0. Each frame during this transition, the JavaScript thread needs to send a new x-offset to the main thread. If the JavaScript thread is locked up, it cannot do this and so no update occurs on that frame and the animation stutters."
Regarding the native-styled and higher-performing NavigatorIOS:
"Development belongs to open-source community - not used by the React Native team on their apps. A result of this is that there is currently a backlog of unresolved bugs, nobody who uses this has stepped up to take ownership for it yet."
Disclaimer: this comment is written by a consultant undergoing high levels of frustration and may have traces of FUD. If React Native works well for you, I would love to hear about it.
Edit: I was really hoping to do some good work on the app today. The frustrating problem this time is that the devtools are entirely broken due to a commit made back in September.
>>> React Native's basic navigator is non-native and implemented in a way that has fundamental performance problems.
- just use the InteractionsManager - Navigator works well enough on all the Facebook apps and Paper etc. yes agreed about the NavigatorIOS - it doesn't work and I complained bitterly somewhere on github about that.
- You probably aren't coming from the web where I think most people know that if you are making requests in the background and doing too much stuff inside of requestAnimationFrame your performance will be bad.
- Maybe you should move the Javascript that is causing performance slowdowns into Native code if it's that complicated then it'll run on the different thread? I think if you come from an app background it's probably easier to expect better performance.
- I hope you are testing performance in the Release build mode in xcode, it needs to be on for loads of optimisations to be made.
- I've found performance acceptable so far and excellent when you use actual Native things.
Yeah, I'm in the process of putting in spinners conditioned by InteractionManager. I'd prefer rendering to be fast enough by default, but there's no free lunch.
I am coming from the web, where I usually don't have to think about animation frames when implementing basic functionality. React Native's way of implementing navigation animations with repeated timer calls between JavaScript and iOS makes this a problem.
The performance slowdown is caused by lists, texts, and images. I am not doing any animations or fancy interactions. Moreover, we chose React Native exactly because it would let us use JavaScript for these things, since that integrates with our web app "isomorphically."
I'm hopeful that with release build mode and InteractionManager-based spinners, I'll be able to get acceptable performance. I'm just a little surprised at how many performance gotchas I've run into.
Yeah, let me know how you get on with a release build - we've had a few issues that went away with that on. How big is your app, ours seems fine with normal usage on a real device... Guess it does depend on what you are doing.
I had big hopes for today's work, but it involves some UI stuff that would be much easier if the devtools hadn't been almost entirely broken since September.
I'm not sure how to quantify the bigness of our app. It's kind of Twitter-like in structure: a list view of cards containing images and texts and which on click transition to an expanded card view.
Once streamlined, it will probably be the best mobile framework world wide (IMHO). Great job dartisans, Good Luck!
I also hope to see it running deaktop apps, something like NW.js
No Windows Phone Support. Oh man this platform is so forgotten.
Btw. I don't care about the language, but I care about support of IDE's and Tooling and I hope that you built around the Dart Tooling of IntelliJ, then I would give it a try!
> I hope that you built around the Dart Tooling of IntelliJ
Dart's IntelliJ tooling is built on top of a reusable analysis library written in Dart[1]. It exposes a service-like API so that it can be integrated into lots of different editors/IDEs without each having to reinvent the world.
Just to be clear, this is full-featured, rich static analysis, not just parsing and syntax highlighting. The entire static type system of the lanugage, including the new stronger type checking[2] is in there.
Honestly, though, what sort of market share does Windows Phone have? Surely it's a single digit percentage. How could anybody justify developing for that platform without having a significant interest?
MS is trying to make iOS and Android applications easy to port to windows phone apps, so hopefully having an easy path from your existing app to windows phone will be almost a no brainer, but Windows Phone 10 dev tools or phones are not out yet afaik.
Given that WP10 and Windows 10 should have a similar "universal" runtime, maybe once you are done with your android/iOS to WP10 port it will work quite nicely on Windows 10 after you update the UI to support larger screens.
So, hopefully once enough people are on Windows 10, the windows (phone) 10 ecosystem will be attractive enough that people want to build things for windows 10, rather than the web.
I have no idea if this strategy will work out, but it's what I sort of expected windows 8 to be, but hey, maybe the ship hasn't sailed so far as to make this pointless.
I used to work at MSFT though, so this please excuse the bleakness shrouded in the unwarranted optimism.
Don't we have enough cross platform dev kits anyways?I fail to see the need for so many more platforms.The state of the ART/DVM is going to become like that of the JVM. Maybe as devices become more powerful,it would be capable of handling such needs.But why would you want to develop such apps which you would have to wait till the native platforms release updates which are then ported to these platforms.Android updates happen every 3 months.Maintaining evergreen apps in such cycles is a task in itself.
I understand the evolution of Javascript based frameworks considering the large number of developers available.But now days you have to spend more time learning a framework in comparison to developing something with it.
The only feature which seemed to grab my attention was :
> Can I update my app over the network, outside of the Play Store?
Yes. On Android, you can update your app over the network (via HTTP), without first publishing to the Play Store. This can be useful because it doesn’t bother the user with a notification, ensures your users are on the latest version, makes it easier to run A/B experiments, and more.
This would be extremely useful. But I think there would be a catch to this too.I am actually tired of seeing new frameworks come up everyday,especially orgs like Google.
> Don't we have enough cross platform dev kits anyways?
Absolutely not. Right now the choices are very, very small for the platforms you'd actually want to use. React-native, before Flutter, was the only one (that I know of at least) that uses real, native components but uses a different language for orchestrating them.
Beyond that everything else is either "shove html in a web view" or the xamarin approach which, and please correct me if I'm wrong, is closer to the approach of QT in that it renders all its own controls.
We need more options in the first camp, the one where real native components are used but can use a common language across the mobile operating systems.
I only wish react-native and this supported Windows Phone. It's such an awesome OS but no one will ever use it because of the lack of apps :(
«Beyond that everything else is either "shove html in a web view" or the xamarin approach which, and please correct me if I'm wrong, is closer to the approach of QT in that it renders all its own controls.»
Xamarin uses native components, in a similar manner to react-native. (Or more accurately, the other way round, Xamarin pre-dating react-native.)
I also wish react-native or NativeScript would actually provide/finish Windows Mobile/UWP support, but I'm not currently holding my breath. (That said, at least Windows supports JS as a native build stack so maybe you don't really need react-native/NativeScript to support Windows, you just need some glue scripts...)
Interesting, thanks for the heads up! I was invited to their original Alpha (before they called it Xamarin) years ago and I could have sworn it did not work like that back then. So I'm assuming it's either changes or I'm mistaken.
So far as I've followed Xamarin it has always been about native components, but they've not always been great with marketing that. The waters are also muddied a bit in that they have their Xamarin.Forms library now which is an abstraction layer over top of the native components (but at the end of the chain, still defers to the native components to actually do the work). It's easy to confuse Xamarin.Forms with a non-native toolkit, but it too is just a wrapper over top native tools.
> What do you consider awesome in Windows Phone comparing to Android and iOS?
So I only have experience using a cheap phone I bought from Amazon last year (it was a $35 Windows Phone that surprisingly worked very well) but it has a lot of things to love about it
- Smooth OS even on older / cheaper phones. Can't always say the same with Android.
- It does notifications the right way in that it has updates on the app tiles in addition to the drop down. So if you dismiss it from the drop down the number will still be present in the app (I constantly dismissed all notifications in Android and it would take some time to figure out what app had a notification I accidentally dismissed).
- The development environment is second to none. It's so easy to get started, build, deploy and your app can work on a mobile phone, tablet, computer and even a freaking gaming console. Single software project!
- Live tiles are awesome; basically a nice and easy way to do widgets that iOS sorely lacks but forces them to be more uniform so you don't have oddly styled widgets like you run into on occasion in Android
- Cortana is more open than Google Now and Siri and was the first assistant that could help you with things regarding contacts and locations ("Remind me to tell my wife I love her the next time I talk to her" works)
I'm not disillusioned though; I'm pretty sure it lacks stuff that some of the other OSes have I just don't really remember off hand as it's been a year since I've used it. But it's an incredible little OS that, with the newest phones, you can plugin in a monitor and keyboard and bam, you're using the same applications in a desktop view (so it's not enlarging the mobile app; you get the same menus that you get on the desktop).
If it had most of the apps I use every day I would move to it.
Android development as of today is painful and application logic is complicated and bloated. Dart and Flutter may be a good option to current way of things.
I'm not ready to throw in the towel just yet. The security issues and user updates with Android are making me consider Windows. If Windows 10 can run Android apps (as rumored), that will be icing on the cake.
The thing people need to realize is that Microsoft has been around for 40 years. They're in this for the long haul. Until Microsoft quits, it is not game over.
You mentioned my point , Microsoft is too big to fail, in software development term they are bigger than Google and Apple combined . They are one of leaders in gaming industry (which is pure money, even profitable than web). They controlling Windows which dominate whole pc market without even competition(don't get me wrong , I have been on fedora for years and I am on fedora right now, but thats it truth , Microsoft is absolute leader of PC's).And after this new smart CEO they understand what was wrong about their approach and they are fixing it right now.
they are pushing cloud as fast as possible. they are dead serious about edge.they are bringing ssh and whole another tools to make windows more developer friendly.They are pushing windows 10 for internet of things more than google pushes android for internet of things.(Because they know it will be a revive for Windows phone) and whole another things.
If I were google. I would be very stressed , Nadella's Microsoft is not ordinary company and it is attacking google in every front.
Google's biggest mistake was their hesitate to beat windows on desktop(I would say recent news about chrome/android desktop version is related to their analysis from Microsoft approach). We all know it does not matter where goes computing. Desktop will be there ! even for 10 % of users (developers). but desktop will not dead (there is no way , absolutely ).And until desktop is alive , Microsoft is like snake with venom , ready to attack.
I am betting on Microsoft ( despite being linux guy ). Microsoft coming back and they compete vigorously , because they have resource , they will win !
>in software development term they are bigger than Google and Apple combined .
I dunno. Since a couple of years, a lot went wrong for them
- Websearch (Bing usage must be abysmal)
- Webmail
- Mobile (I have lost track how many approaches failed over the years)
- Web-tech (IE, Silverlight, all the other proprietary extensions)
- Media sales (They had something for the Zune thingy, right?)
- Web ads
- Languages. Java is still around, JS likewise. The whole .NET ecosystem is kind of holding out, but nowhere exploding.
- Social web
I have a hard time believing their inclusion of SSH in 2015 is making a difference. The whole lot of younger coders I know are either on Mac, on Linux or on ChromeOS. No one wants to do Windows. Powershell is nice, but why learn it if you also work on Unix?
The ordinary user or enterprise desktop is their mainstay and I don't see that evaporating fast. Surface is making some inroads into the corporate tablet/laptop (laplet?) market. And their productivity suite seems healthy despite the design choices.
But that's it. Apple is eating the smartwatch market, the phone high-end, the tablet high-end, the ultrabook market. Android is slurping up the low-end to high-end phone market. Online productivity suites means Google. Search is Google. Media sales is Amazon/iTunes. Social web is Facebook/Twitter. New languages and frameworks come out of OSS or Google or Mozilla.
I don't run Windows on any of my computers and have been a Linux user since forever but I have to disagree with at least one of the points here.
Microsoft is pretty excellent in language development, I don't agree with the "new languages and frameworks come out of OSS or Google or Mozilla". F# would be my prime example. Axum was also pretty interesting. LINQ integration is also pretty interesting etc. etc.
I think your points are woefully behind the times.
> Websearch (Bing usage must be abysmal)
Nope. In fact Bing usage is really good. 1 in 5 people are searching on Bing (maybe even more if you factor in the multiple companies that use Bing though I'm not sure Yahoo does anymore). http://money.cnn.com/2015/04/16/technology/bing-usage/
> Webmail
Office 365 is KILLING it and as part of that ecosystem they have Outlook on the web. I'm not sure what's going wrong for them here. Do you have any data?
> Mobile
Fair. Unfortunately, in my opinion.
> Web-tech
Their new browser in Windows 10 is actually really, really good. Silverlight is still one of the best options for streaming video but Microsoft is embracing the web like crazy! They worked on TypeScript, they have a new version Visual Studio that's built on web technologies, you can make universal Windows apps with web technology, their .Net framework constantly works with the latest developments in web tech.
Microsoft is hugely in on Web Tech. Have you seen how well their Word, Excel, OneNote, etc work in a web browser? Pretty damn well.
> Media sales
What does this mean? There is XBox for gaming and music, there is groove for music in general, they have the Surface; are you referring to ONLY MP3 players? Even Apple is quitting that game.
> Web ads
Fair. No idea what their statistics are on this.
> Languages. Java is still around, JS likewise. The whole .NET ecosystem is kind of holding out, but nowhere exploding.
You can develop Java in Visual Studio. You can developer practically anything in Visual Studio now, even Objective-C to a degree (well, soon). The .Net platform is simply amazing and when the open sourcing is finished and they start offering their binaries for download there is no reason why it can't get bigger.
Java isn't exactly exploding either. Not sure what this criticism is really trying to convey.
> Social web
Google also sucks at this. Apple too. Everyone but a few players suck at this. Microsoft actually has a decent social presence if you consider XBox Live but beyond that I don't think they have much of anything.
> Apple is eating the smartwatch market, the phone high-end, the tablet high-end, the ultrabook market. Android is slurping up the low-end to high-end phone market. Online productivity suites means Google. Search is Google. Media sales is Amazon/iTunes. Social web is Facebook/Twitter. New languages and frameworks come out of OSS or Google or Mozilla.
About half of this I disagree with but, even so, you act like it's a "well Google and Apple are winning so...Microsoft, just give up guys".
Having a good web browser or partially obscure language does not make Microsoft a web company in a sense that Google or Facebook are. That would be a dishonest comparison. Us devs will never forget about IE, though Edge is a good start in repairing a very frayed relationship.
Regarding social web it is also highly dishonest to compare Xbox Live with Facebook or Twitter, which are deeply ingrained cultural phenomena.
His points are valid, much more than ticking off positives of Microsoft's efforts. There's a reason MS isn't as confident as it was. Redmond is constantly haunted by 2006(AWS), 2007(iPhone), 2008(Chrome) and 2009(Facebook's rise). They seem to be the last to the party...
You seem to have your own narrative for how Microsoft is and you don't really seem to care much about the reality of the day. I implore you to drop former prejudices when it comes to technology because this changes fast and what you're talking about (much like the parent) is very much in the past.
> Having a good web browser or partially obscure language does not make Microsoft a web company in a sense that Google or Facebook are. That would be a dishonest comparison. Us devs will never forget about IE, though Edge is a good start in repairing a very frayed relationship.
No one said Microsoft was a web company. But yes you devs (including me) will forget about the IE of old because that is no longer the reality. Holding superficial grudges over software that becomes less relevant everyday is pety and counter productive.
Besides, since IE8 Microsoft has ackowledged its issues, has been far more open and more like a partner with the other companies involved in the W3C specifications and they've made fantastic strides (IE 11 is awesome as well; IE 10 isn't that far off).
> Regarding social web it is also highly dishonest to compare Xbox Live with Facebook or Twitter, which are deeply ingrained cultural phenomena.
If you re-read what I wrote I simply said if you counted XBox Live as social then sure they have some social presence but that's it. I never compared it to Facebook or Twitter. So zero dishonesty there.
> His points are valid, much more than ticking off positives of Microsoft's efforts.
You haven't refuted my responses to his points and yet you are saying parent's are valid. I'm not sure if you're simply trying to troll or what but if you feel his points are valid and all of my points, which mostly just corrected incorrect statements from the parent, are not then please present your evidence instead of trying to dismiss.
> There's a reason MS isn't as confident as it was. Redmond is constantly haunted by 2006(AWS), 2007(iPhone), 2008(Chrome) and 2009(Facebook's rise). They seem to be the last to the party...
Azure is second to AWS; I'm sure Google is kicking itself because of that and it's a pretty awesome business. Why would they be haunted by that?
For iPhone yeah Microsoft missed the boat but so did countless others. Microsoft has a new tactic with making all of their software available on all platforms and you know what? It's higher rated than some of the contenders in the same space (for instance Word is higher rated than Pages). They're doing fine with mobile except for their own OS.
I doubt they are "haunted" by Chrome. If anything Mozilla would be considering they were making ground on IE and then Chrome came right in and grabbed many of their users. Microsoft still has plenty of users here and they probably don't care nearly as much as you want to think they do.
Everyone was caught off guard with Facebook. If you'll notice Microsoft hasn't even tried to over take them, unlike Google who tried 3 times in different ways.
Microsoft might be ambitious now, however I think they are the ones who will lose out in the future, where platforms are everything. A huge problem I see in Microsoft's approach is its ability to build a compelling platform for consumers, especially in a time of increasing skepticism in American tech. It's technology might be great, but it's cultural influence is low and may not be enough to keep it strong in the face of Chinese competitors in the future. They may end up like Sony...
I hope their foray in the consumer space proves fruitful. It's a shame they have to compete with the likes of Apple and Google, along with any future Chinese tech company.
> The security issues and user updates with Android are making me consider Windows.
The problem is that the average Joe (and that's 90% of people buying phones) doesn't care about security issues and updates. IMO the ship has sailed for Windows Phone. It will remain the third player on mobile, like Linux is on desktop.
Windows 10 is a still an insignificant blip in the phone world. For sure, the two largest ones by far are iOS and Android, and everything else (Windows 10, BlackBerry, Tizen, Sailfish, Ubuntu Phone) is basically crumbs.
If anything Windows 10 is a special snowflake in that it does not have an underlying posix-y kernel, which makes it less likely to get anything cross-platform, even if it does get slightly more prevalent than the other crumbs.
> What POSIX stuff (it is just CLI and daemons anyway) can you really use for mobile apps?!
It's not about POSIX per se - but among the Linux and Unix derived kernels, most of the things are similar. e.g., files are open with an open() syscall, file sharing semantics are mostly the same -- whereas on Windows, you call the differently-behaving OpenFile, and you can't delete or move an open file.
Porting infrastructure (e.g. flutter) among POSIX-y kernels is much less work than porting to Win.
> There Windows Phones are the only alternative for those that don't want to get an Android device.
I thought Firefox phones were another alternative. Aren't they?
Windows 10 Mobile can run Android apps using "Windows Bridge for Android", a.k.a. Astoria.
I've tested it with some simple apps, it works as advertised. The Windows device shows up in Android Studio as if it were a KitKat phone.
Since Microsoft has done all that work already, I don't think it makes sense for 3rd party frameworks to bother supporting Windows 10 Mobile separately anymore.
Developers will eventually care about Windows 10 as an important native platform when universal apps start to matter. As Apple and Google move in this direction, Microsoft starts to look stronger here with desktop and xbox plays. This happens when app experiences start floating across screens more easily and consumers lock into an ecosystem (for good reasons)
Just like devs will eventually build apps for Windows 8...
While I've some great apps built on the Windows Universal app platform, there really haven't been anything that I've seen that is a must have or the next explosive app. The larger problem is the hacker community's love for their Macs & Linux. Microsoft should just flood the Bay with Surface Books, that might prove more fruitful than giving devs cash
I sort of want this to be the case, but I feel like the web won, and that's going to keep making windows 10 a niche platform for things that want to break out of the web model.
Similarly as Ubuntu Phone or FirefoxOS. This is a chicken-egg problem - no one will invest in supporting platforms what has not that big market share. Windows is now probably somewhere on the balance point whether support it or not. In some countries it is popular and then local applications have Windows version.
Supporting Windows requires a lot of resource allocation and unfortunately their global mobile market share cannot justify it yet (http://www.idc.com/prodserv/smartphone-os-market-share.jsp). Microsoft can give a hand though, since it is open source.
The amount of JavaScript-is-God philosophies on here is excruciating.... I respect everyone who likes JavaScript, but just because Dart isn't what you like doesn't make it inherently useless or bad. The world is all about diversity, how about some language/preference diversity?
In my opinion, JavaScript is a large flame, and all the
languages that were inspired by it are the sparks. Eventually the JavaScript flame might die out, but the sparks it makes can still burn, and create their own flame.
I'm a huge lover of Dart, and I generally dislike JavaScript. My advice is to welcome Flutter. If it works out, it will work well, if it doesn't work out, it will fade away.
I recorded two webm's of playing with the examples on a Nexus 6.
It's quite early to call it either way but in my quick testing it seemed not any more performant than a webview for traditional tasks like scrolling through lists of "material-design" elements (eg: text), but then it surprisingly did very well with 2D graphics. A bit of lag in the game, a bit of lag scrolling, but maybe it'll get better.
Nothing wrong -- except I don't have enough juice on my laptop to run VirtualBox, etc. Want to attract 70% developers, have something to run easily on windows.
"Flutter is unique technically because its rendering implementation uses neither WebView nor OEM widgets. Instead, Flutter uses its own high-performance rendering engine to draw widgets."
Factually incorrect since http://www.qt.io/qt-quick/ has done this for a while and has a very mature fast mobile reactive amazing UI engine.
Codename One also has that architecture but its pretty old. Swing has it as well as JavaFX and both took it from SmallTalk libraries that inspired them (and Trolltech of QT fame).
semi-off topic, but the guy who wrote the style guide needs a little more experience in the real world. Not using braces is an accident waiting to happen.
if a flow control structure's statement is one line long, then don't use braces around it, unless it's part of an "if" chain and any of the other blocks have more than one line. (Keeping the code free of boilerplate or redundant punctuation keeps it concise and readable.)
For example,
if (children != null) {
for (RenderBox child in children)
add(child);
}
...rather than:
if (children != null) {
for (RenderBox child in children) {
add(child);
}
}
Cross-platform on mobile isn't the same as cross-platform on desktop, so there really isn't any irony there.
Android, iOS, Linux, and OS X are all Unix-like, and Windows is... Windows. There's a ton more work that goes into supporting Windows than a *nix variant.
To be fair , so is React Native, calling itself cross platform but not running on Windows ( not even sure it runs on Linux either, AFAIK it's mac only ).
David dumetz and his money grubbing family used this wonder program to ruin endless devices .put fake social sites up and put my family's info on the web.Diane dumetz u knw I know all ur lieing to disability .wat ur husband makes .play time is over.
This is very new from the looks so who know how it will play out, at the moment I am not excited about it. Sounds like Java swing where you could create cross platform apps but the UI was not the platforms native components and so never quite felt right.
I think its a different thing. Its more like Codename One https://www.codenameone.com/ for apps that have widgets and not as much for games. Although you probably could create games with it in a pinch.
Unfortunately I don't see how a system like this could be accessible using the native accessibility tools like voiceover, and so IMO is a non-starter. The FAQ doesn't seem to address it.
They don't mention it and might not have it, but is this that different to React Native? They have a reasonably thorough looking integration so this might just be a case of waiting on Google to implement here? React docs for it: https://facebook.github.io/react-native/docs/accessibility.h...
Looks like it's more suitable for making games, since it "uses its own high-performance rendering engine to draw widgets" -- non-games typically don't reinvent widgets.
And to me this is a great shame. Unique industrial design adds appeal to a product and can improve its user experience.
Kai's power tools were a fantastic experiment in visual UI design. I'm left wondering why games are the only brand of software where ui innovation "is ok".
True, but sometimes the UI does not need innovation. iOS had problems where they suddenly made a button look like text and nobody could tell what was a button, and what was text. It didn't need innovation - it wasn't broken.
In the case of custom GUI elements sometimes things don't need fixing. The audio industry always makes control panels etc. look different to the common UI and this is one area you still see it.
But for the most part, having a consistent UI means the system is easier to use. I wouldn't want my fork mutating every time I had a different meal, in the interests of innovation.
"I wouldn't want my fork mutating every time I had a different meal, in the interests of innovation."
The meal is a good analogy. For prolonged activity a local minima of utility that is 'good enough' can be achieved. This would correspond with a single app.
The fork, however, is not necessarily the best tool for 3D modeling, composing music or some new entirely new activity.
In this instance though, the fork is the method by which you interact with the food. In GUIs, the GUI elements are the ways you interact with the underlying concepts in the program (the food).
The fork is basically a GUI element, eg. a button.
Buttons appearing to be anything but buttons is as useful as a fork being shaped like a playing card - it isn't useful at all, and I could not easily shovel food into my fat face with aplomb.
I am not saying that custom GUI controls/widgets shouldn't be invented where needed, just that the basics being reinvented just for the sake of reinvention is unnecessary, and confusing.
Well, it's Google that is reinventing the widgets, not the app developer. They say it is especially good for Material Design apps, which would seem to indicate non-game apps. Admittedly it might look a bit out of place on iOS, but hopefully they've done a reasonably good job at making widgets that look at home on iOS.
>Admittedly it might look a bit out of place on iOS
Since last year, Google's iOS apps have gradually adopted more and more elements of Material Design, including the color palette, the app bar menu, the MD iconset, the floating action button. And they typically remain best in class; it turns out that Material Design works well on iOS too.
(Note Google's implementation is not necessarily consistent--just look at the different button tap effects for Calendar vs. YouTube on iOS. Sigh.)
We've also borrowed MD concepts for the iOS version of our new app (https://recent.io/) without user complaints.
>And they typically remain best in class; it turns out that iOS users enjoy Material Design too.
Ugh, no thanks. Please keep the low information density, searing color blocks with white text, FAB covering content, drop shadows, and overdone animation away.
Not only are you right, but Google realized you're right. They've removed some of the overdone animations--tap on some of the buttons on iOS Hangouts and you'll see. And the color blocks aren't quite as searing anymore (didn't the original version of the spec call for FABs in a contrasting accent color, like bright yellow?).
I view the YouTube iOS app as a good example of the direction Material Design is headed; it's even dropped the hamburger menu, which was a big part of the original spec.
Only if the navigation would condense while scrolling... Hate that 25% of the UI is blinding me with color/space and distracting away from what I'm interacting with.
It's funny that due to the fact that the iOS code is compiled, it can't self update like Android can, despite iOS having significantly more update friction.
I am wondering in what world self app updates would be considered a good thing. As an end user it terrifies me. Although in android you have to declare permissions beforehand, does it cover that? With android 6 would you be able to update to require anything and just ask on demand? Is the fear irrational?
Do you have any way to actually scrutinize app updates? About the only thing the constant update notifications do is cause me to uninstall apps that I'm not using any more.
Do we really need cross-platform app development framework? No, It should only be focused on Android. Why the hell iOS? There are other frammeworks for them.
Optimized 2D engine? Hmm, is there any chance that there's a hardware-accelerated version of Skia somewhere in there? A while ago I was looking for a nice OpenGL vector (read: path rendering) library for an iOS app I was working on, but none of the available options at the time were good enough. Ended up hacking together a custom implementation in Cocos2d. (Actually, still hacking...)
Looks like it's there but I don't think it uses OpenGL. (Also, the page states: "Today we don’t support for 3D via OpenGL ES or similar. We have long-term plans to expose an optimized 3D API, but right now we’re focused on 2D.") Still, this is very promising!
Ain't going to happen. There is no real support for Go on Android at first place, sure you can compile Go programs on Android , but that's about how useful Go is on that platform. And frankly have you ever tried to write a desktop app with a GUI in Go ? Because you'd know how painful it is.
The app I want to write is basically a service that just does stuff (with files) based on signals from other devices/services. The UI is actually client side webapp. So I was hoping to write the service bit in Go which then would run on Linux, Windows, Mac, Android. Oh well.
Flutter is build on top of the mojo. This exposes IPC interfaces to the devices. There are Java, Dart, C++, and I believe also go bindings for this. Not sure if this is in a usable state - but worth a look.
"Unfortunately, due to iOS restrictions, updating your Flutter app over the network is not possible. We are curious how much you use this feature, please let us know at flutter-dev@googlegroups.com."
I'm not sure how long Apple will let the current situation stand. As it is, developing with React Native is more flexible than with their own frameworks, which I can't imagine they're too happy about.
Honestly, between the use of a relatively exotic language of dubious quality with types that are "optional and unsound" (https://www.dartlang.org/articles/why-dart-types/), their custom widget implementation that who knows how well is going to work, and lack of web support, it doesn't seem very attractive.
React-native seems a much safer bet.