Flutter – Cross-platform mobile framework from Google
flutter.io
flutter.io
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.
What problem is this trying to solve?
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?)
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.
A minimal "Hello World" RoboVM app adds 3mb per CPU slice. I'd assume packaging the Dart VM has a similar footprint.
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.
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).
most people hear Qt and immediately think about heavy desktop applications. its a shame really, Qt is pretty awesome atm for mobile development.
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).
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...
From what I could understand in the Qt 5.5 release notes, this has hardly changed.
This is I idea I as an outsider get from the talks at Qt events and the various iterations of QML and WebViews that took place in the 5.x releases.
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.
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.
lmao what universe do you live in
If all the browsers supported a real programming language in their runtime, JS would die like Flash is doing.
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?
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).
What you mean is there: https://github.com/flutter/flutter (99.1% Dart)
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.
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.
Indeed. One of _the_ biggest selling points of React Native is the promise of near-instant over-the-air updates for iOS and Android.
The developers on this project are using Atom https://github.com/atom/atom/ for their day to day Dart development. They are contributing to the Dart plugin https://github.com/dart-atom/dartlang, and implementing a Flutter specific plugin https://github.com/flutter/atom-flutter-dev. The Dart SDK https://github.com/dart-lang/sdk provides the basic source code analysis tools. All of these projects are open source, on github, and see regular commits.
Could you potentially generate smaller js libraries if the language was statically typed?
Are you familiar with Codename One (https://www.codenameone.com/ )?
It seems to me that what we implemented there is roughly in the same direction although not as mature.
- XUL
- Layout managers like Motif, Swing, Tk, ...
I never had with them half the problems I do have making HTML/CSS work properly across browsers.
True, the XHTML + XML modules would have brought us there, but another path was chosen.
No thanks, wouldn't buy again.
What I mean by that, was being aware information like "Filthy Rich Clients" blog, http://filthyrichclients.org/
I have been out of the CSS loop in the last three years.
Can we finally center vertically without lots of tricks in a good way across browsers?
I am not a designer and never managed to control layout in HTML/CSS, as easily as, I do in all the native toolkits I have used thus far.
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 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.
"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.
They have a number of Material Design web components that are very easy to integrate into your site but also more difficult for people to override.
http://mbrock.github.io/disclaimer.html (https://news.ycombinator.com/item?id=10521578)
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.
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.
Some interesting ideas here, though. It's strange how much it looks like web development, with route handling for navigation etc.
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.
Furthermore, TypeScript, Facebook's Flow etc provide stronger static analysis than Dart.
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).
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)
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.
The Android team has been very clear where they stand.
Why not Android Studio ? this release announcement is weird. it seems to be as much political as technical.
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.
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.
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.
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.
I really am giving up on it.
Just for reference and general understanding, can you link something on this point? Thanks.
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 for mobile
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.
Doesnt that make for a pretty strong statement ?
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'.
User facing side of the framework is written in Dart. That means something.
/me spins finger in the air...
This is like any other 'insert language here' mobile runtime with native bindings to the mobile apis (eg. camera, etc) and its own widget library.
Unity and kivy spring immediately to mind as examples of other ones. Hardly revolutionary.
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.
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.
> they had legal and other issues with Java
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.
https://github.com/domokit/mojo
I doubt it is faster than Java ART for access to Android Frameworks.
Call JNI from C++ it might have delays around 300ms or more per call.
https://www.youtube.com/watch?v=Wb5HAI73QRE&list=PLWz5rJ2EKK...
From some examples using buffers, maybe I am wrong.
I mean calling Android APIs via JNI vs calling them from Java.
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.
"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.
Where did you read that? They just provided a way to build Android apps with Dart (like you can with C# via Xamarin and other such frameworks).
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.
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.
"Crap. Anybody got anything?"
"Jimmy has a brainfuck to Objective-C transpiler"
"Anybody else?"
"How about non-native controls with a language no one cares about?"
"Ship it"
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".
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.
If it's easy to mix with native code, this could be really useful to me.
* StatelessComponent ... (props) => (<Tags />)
* Widget build() ... render()
* setState() ... setState()
etc.
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.
https://github.com/facebook/react-native/issues/3452 https://github.com/facebook/react-native/issues/567 https://github.com/facebook/react-native/issues/3049 https://github.com/facebook/react-native/issues/2569
The marketing claim on their main web page that "React Native apps are naturally fluid and responsive" needs qualification.
These pages are essential reading for anyone considering using React Native for a project with deadlines:
https://facebook.github.io/react-native/docs/performance.htm...
"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."
https://facebook.github.io/react-native/docs/navigator-compa...
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.
https://github.com/facebook/react-devtools/issues/229
"I don't know how to fix this. I now remember that this is why we didn't merge that RN pull request originally."
UGH. Shoot me.
- 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.
https://github.com/facebook/react-devtools/issues/229
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.
I'm sorry.
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!
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.
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.
The Atom plug-in uses that too.
[1]: https://pub.dartlang.org/packages/analyzer [2]: https://github.com/dart-lang/dev_compiler/blob/master/STRONG...
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.
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 :(
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.
- C++ is a first class language on the platform, not constrained like the NDK
- C++ also gets first class tooling not the second class treatment Google gives C++ devs
- WinRT is a very nice framework as the second coming of COM
- .NET is compiled to native code AOT
- Visual Studio rocks in debugging capabilities, specially for parallel and graphics debugging.
- Less resource hungry as Android
- XAML and its tooling (Expression Blend) for UI design
- Common runtime, develop WinRT components and use them from any language that understands WinRT.
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...)
I mean, if this then do that is a common construct in all languages, surely?
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.
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.
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 !
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.
> 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".
I don't understand the point of your criticisms.
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...
> 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.
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 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.
But actually with Windows ability to run Android & iOS apps, it will be less of a problem I guess (http://www.theverge.com/2015/4/29/8511439/microsoft-windows-...)
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.
There Windows Phones are the only alternative for those that don't want to get an Android device.
Android also doesn't have a proper POSIX kernel, its Linux version is very customized, for example IPC is out.
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?
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
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.
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.
At a superficial level, seems like a strange statement to make since those languages are quite different. Unless the point is that Flutter is C-like?
Most of the major hurdles are fixed and now it's just a matter of some clean up and documentation.
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.
https://github.com/flutter/engine/blob/master/sky/specs/styl...
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);
} if (children != null) {
for (RenderBox child in children) {
add(child);
}
}http://facebook.github.io/react-native/docs/linux-windows-su...
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.
They don't offer the full POSIX API.
"Those who cannot remember the past are condemned to repeat it": George Santayana
I understand that examples exist elsewhere, but better to have a few linked up for launch than a placeholder.
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.
Ugh, no thanks. Please keep the low information density, searing color blocks with white text, FAB covering content, drop shadows, and overdone animation away.
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.
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".
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.
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.
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.
https://github.com/moai/moai-dev/blob/develop/samples/vector...
Where did this rumor come from?
https://github.com/domokit/mojo/tree/master/mojo/go https://groups.google.com/a/chromium.org/forum/#!forum/mojo-...
React Native 1, Flutter 0.
Same for use of OpenGL ES.
Same for use of the phone's native UI components.
Dart?! Really?