>Google today announced the first preview of Jetpack Compose, a new open-source UI toolkit for Kotlin developers who want to use a reactive programming model similar to React Native and Vue.js.
This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ? Remember I'm talking about developing nations like India - where startups like ours invest in training college graduates . These guys can't afford 10$ courses on udacity and Coursera.
But even if it was not India, having this parallel signalling for Android based startups is very confusing. Atleast Apple was very clear about Swift .
Where will Android be in 2 years : Dart or Kotlin ?
Internal politic wars at Google, with management having popcorns to see who wins at the end.
If you are confortable with Qt, JavaFX, Xamarin, there is hardly anything to see with Flutter, plus they are based on programming languages that you actually want to have on your CV, instead of one that was dropped from Chrome and rescued at last minute by AdWords team.
Plus, even Fuchsia is not so focused on Flutter anylonger. Android userspace is being ported to Fuchsia, and now they have a UI Framework agnostic layer, Scenic, with examples in C++ and Rust.
If you allow internal politics in technical decisions, the old is drowning the new child that is tasked with killing the old every time.
This is what really killed Nokia's platform domination in mobile phones. Google should take a note.
Nokia had dominating smartphone platform (Symbian) and market dominance in mobile phones. It was becoming old, messy and outdated but still doing fine at the moment. Instead of choosing and committing they allowed innovation but allowed the most critical decision for the company to be the question of internal politics. Linux/Qt based new system was sabotaged from inside buy people whose careers were based on the old Symbian. Of course the VP who overseeing overseeing billions in revenue is looked differently than VP that is tinkering with the new platform with bunch of young Linux hackers.
Netflix is perfect example of how to execute technological transition correctly. They made the decision to move from DVD rental to steaming when disc rental was still making money and there was time. They committed to it. People working in the money making disc rental side were shut down completely from the discussions where the company future was planned and made.
Google has so much market dominance that it can make these attempts and never commit, but it also guarantees that they will never succeed. Developers outside the company know that everything is just 'another try out' and it's not worth of getting into it.
Weren't Symbian and MeeGo both sabotaged by Stephen Elop who came in briefly from Microsoft to assume the role of CEO of Nokia, decided to burn everything they had to instead buy Microsoft's solution, and then returned to Microsoft when the job was done?
> Plus, even Fuchsia is not so focused on Flutter anylonger. Android userspace is being ported to Fuchsia, and now they have a UI Framework agnostic layer, Scenic, with examples in C++ and Rust.
I don't think scenic is written in Rust. A big chunk of the source code in the topaz layer (the view layer) is still written in dart. With that said, many were actually surprised when it was revealed that ermine (the new fuchsia shell) was written in dart/Flutter [1] since earlier code for it was in Rust [2]. Guess that didn't pan out.
Your last sentence is a bit hard to comprehend but not paying for Qt and shipping a commercial embedded product is pretty difficult due to the anti-tivoization clauses of GPL3.
I agree with parent poster that flutter is very interesting for Embedded GUI development.
It's really easy to ship commercial Qt app with LGPL3 (except few modules that are GPL3) You just provide sources or linkable object files.
Qt intentionally avoids explaining how to do this because they are selling commercial licenses. If you are in software business and can't figure this out, maybe you should consult someone.
(disclosure: I own commercial Qt license and stock in the company)
That is really easy as you say. What you seem to have overlooked are the implications of doing this. You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications.
So ... no thanks!
I do contract work for a company licensing Qt5. I'm hoping for Flutter or something else to kill Qt in the long run.
I think I'm allowed for the tone when you respond with the following:
>You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications.
The above is completely wrong.
You develop and distribute your closed source software and link it with QT libraries like you would do normally. Nothing is needed from the customers.
Your closed source software can be statically linked to LGPL binaries (to fix another common misconception).
What is needed from you is a way for the customers to get things separately. It can be written offer, link to files in the website (used to be directory in DVD). You can be almost 100% certain that your customers will never use or notice this option. It's just there to comply with the license.
You don't agree that you need to provide a way for your customers to replace the Qt libraries? (because that is a fact of LGPL3, read the anti tivoization clause).
Do you see any possible security problems with the above?
Because in reality it means that you give your customers the possibility to run their own code on your hardware. That is a problem for many companies and products.
>You are forced to help customers replace the Qt libraries in your product.
Depends on what you mean by 'help'. You are forced to give the opportunity for them to do the work if they need it. If you have statically linked files, it can't be done by accident.
> Do you see any possible security problems with the above?
No I don't. When I provide completely closed binaries for my customers, they can hack with the binaries and create security problems if they want to.
Software security is not improved by obfuscation. If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.
Btw. I'm confused by your wording. I'm suspecting that you have some underlying assumptions you are not stating. Are you thinking that LGPL forces you to allow customers to modify the software in the hardware they are buying?
I think I'm clearly stating my assumptions. GPL3 and LGPL3 requires you to enable the user to replace the GPL/LGPL3 code on your device with the users own version of said code. It does not matter if you link statically.
Now, it would be possible let the user do this and not let it be a problem for your product (in terms of security, reverse engineering, ip theft, etc) but it is more and harder work.
I have used both older version of Qt (LGPL2) without licensing and newer (LGPL3) with licensing in commercial products. The former was not a problem. But using LGPL3 Qt without licensing in a commercial embedded product is a headache (if you are concerned about the problems it might bring), according to me.
> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
- If you ship embedded product where the code is not supposed to be easily upgraded, you don't have to provide means to do that. Anti-Tivoization applies to cases like TiVo where they added DRM to prevent users from upgrading but allowing you to upgrade.
- Also, anti-Tivziation clauses don't apply software distributed to business. Medical devices or safety critical software etc. Any devices sold to business.
> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
Also, anti-tivoizaton clauses does not apply to devices sold to business.
Good point, forgot about the latter part, that probably would help in some cases. Gotta ask some licensing experts about that one.
From what I see, only a tiny part of the potential market for embedded Qt and things like that can get away with "no updates possible", but still, applies for some.
JavaFX is fully open source, it doesn't need licensing. It also supports hardware acceleration, embedded usage on Linux, animation framework etc. Also, fits well with kotlin.
Flutter is very similar to Qt: signals and slots are similar to streams and sinks, and the BLoC pattern is similar to the state machine paradigm in Qt. I've been loving Flutter and Dart, developing with it seems almost too easy.
I’m sure those are all great cross-platform solutions, and Qt in particular has been around forever and predates smartphones, but you never hear about high-profile app examples that use them. Unlike React Native, which has lost more high-profile companies that previously tried them than I’ve ever heard of any firm using Xamarin.
I wonder why is that. Doubtlessly you can make great apps with say NativeScript, or in Pascal with Delphi or Lazarus, but no one chooses those frameworks for some reason.
> but you never hear about high-profile app examples that use them.
part of the reason for that is that a bunch of companies are paying TQTC for their tech stack not being known. But if you are looking for high-profile stuff using Qt, how about :
but generally speaking, it is not in the DNA of Qt-using companies to post nice articles on reddit / HN which has the pernicious effect of reducing its place in the dev mind marketshare and making it harder to hire...
Can you explain what you mean about React Native? If I understand, you're saying more companies have tried and then abandoned React Native than Xamarin? Can you provide evidence of this please?
Sure. The major apps that were previously using React Native are AirBnB and Udacity, who are fairly prominent as far as startups go. As far as companies currently using the framework, they are respectably impressive:
If you want to do multi platform development, flutter.
I think flutter will be an amazing tool for smaller teams, especially in non-tech-primary organisations. I work in the public sector of Denmark, we do in-house development, our main focus is the public services we provide though. So there is just no way we can do mobile, desktop and web without something like Flutter, or severely increased funding. The latter won’t happen, but flutter might.
If you want to do multi platform development, Kotlin multi platform
Kotlin mpp is still in beta but it works pretty amazing. I have 1 app in production that shares models/API/database. The UI on Android and iOS is native and platform specific. I highly recommend it.
Not naysaying you but i learnt kotlin and flutter this past year(from january). flutter has an AMAZING experience for the things that are "done", kotlin multi platform only does one thing well - kotlin.
it's basically like xamarin with C# swapped out with kotlin(and that sucks as much as kotlin mp does right now even after 3 years of ms acquisition time).
The development experience with flutter is great, that's right. But I don't like the end result. It feels very close to a native app but still not 100%. And I think it will always be a step behind.
One benefit of kotlin mpp compared to xmarine is, that kotlin mpp is not limited to iOS/Android. You can have a shared code base between web frontend/Backend/iOS/android and even macos/windows/linux and all native. One language to rule them all.
Flutter is on its way there, too. Already native on iOS, Android, and Fuchsia, with the web build in technical preview and desktop OSes under development.
I use C# almost on a daily base in Unity3D and have a little experience in Xamarine but I have no idea how a android/iOS/desktop/web project would be build up. Would be interesting to compare it with kotlin mpp.
If i understood it correctly,
React Native basically gives you a JS runtime environment that handles communication with native APIs of the system and is shipped with your app.
Flutter (and Dart) will transpile into native code and compile natively for your platform.
So on React Native you will have that abstraction layer add runtime latency and package size of your app, while Flutter (Dart) really outputs native code.
When React Native's fabric rearchitecture is available you will see much better performance. The thing that hurts performance today is that damn bridge communication between javascript and native that will be severely improved in fabric.
Package size for Flutter apps is a lot larger than RN, even the RN Android build that ships it’s own JS runtime. There are complaints everywhere of simple apps reaching 100MB size.
As for runtime latency, I’ve recently worked on a RN app that outperformed its native sibling. Looking forward to the Fabric release.
Unless you're importing a ridiculous amount of packages and assets, you'd never hit 100MB with simple apps, that's just people looking at debug mode and thinking that it's the final app size.
Simple apps can easily be under 8MB once compiled.
Not really true, you are likely comparing a debug build. An Android Flutter apk sits around 4MB for smallest app. Most of my apk sizes are around 8MB-10MB w/ Flutter
I haven't written any myself, going from reports online that builds are a lot larger than expected. That minimum size is for an app without any components or other modules. The RN app I mentioned was ~6MB with a fully blown app, state management, heavy data layer, hundreds of components, animation, i18n, a handful of native modules, encryption, and so on.
In short, Flutter doesn't really have any advantage in size over RN.
React Native has a JavaScript layer that hurts performance and it is not truly native as they say. Just do a reach on flutter vs react native and you'll see better explanations and comparisons.
I’m not sure this really matters for a lot of things anymore. Sorting a few hundred text items in a list, for example, is going to be so fast on modern smartphones that it will not make much of a difference whether it’s done in JavaScript or native.
Maybe a poor example, but I suspect the only times it really makes a difference is significantly computationally expensive tasks
so? most apps are by nature going to be computationally expensive if they want to compete/successfully use all phone features. i made a simple(according to them) corporate data sync app recently and the company wanted a laundry list of features - background sync, smooth scrolling of extremely large datasets, photographic analysis of images taken at tolls(extracting license plate information/classifying vehicles automatically for tracking).
All of this had to be made in a performant way so as to run on phones with 1 gig of ram as the company was giving phones to everyone specifically for just this purpose(and general communication ofc).However it also needed to work on iphones/windows phones(old ones the execs purchased en masse)
Xamarin was the only choice att as react just doesn't work stably on windows phones but i'm excited to see the future
Your app sounds like it used some advanced features, but I don’t think most apps are going to be computationally expensive in the way that local-AI, image processing, or crypto activities might be. I am not sure what qualifies as extremely large datasets, but I’d be surprised if keeping a few dozen objects in order is significantly lower in JS than Swift. Yes, it may be an order of magnitude slower - or ten orders - but that seems negligible if the total time for processing is still nanoseconds.
Guess it always comes down to the task at hand.
Preference for Dart over JS (lots of reasons, involving language, package manager, compiled performance)
Predictable UI behaviour across devices, OS versions, platforms. As long as you handle presence/absence of device features, and build your UI to scale properly, it behaves as you would expect, everywhere. The value of this cannot be overstated enough.
Future opportunity for code sharing with non mobile platforms. Even without Flutter-web, I could still compile the business logic part of my code to JS and use it with another UI (similar things can be done with React).
I don't think anyone has a definite answer, not even Google itself. Google placed several bets on different technologies and community will ultimately decide which of them is the winning one. Personally I think native Android (Kotlin) and iOS (Swift) development is here to stay. I have tried many cross-platform frameworks and on any non-trivial mobile app, all of them cause more problem than they solve.
I tried flutter. The available plugins cannot compete with the cordova or react native plugin system. For most apps a PWA or cordova-based web app is enough... Many apps are data-intensive and don't require fancy animations... My clients are more than happy with what the web has to offer.
I can only disagree. Flutter is primarily a UI framework. The "functionality" of a mobile application requires access to core features of the mobile platform (e.g. accessing sensors, bluetooth, nfc, contacts, camera, ...). The platform feature access is made available via plugins also when working with flutter. This is the same for RN, Cordova, Xamarin etc. There is no SDK in flutter, Android is the SDK. Flutter has no direct access to Android SDK APIs...
They're changing their stance on that gradually, just recently they started tracking their options for natively implementing multithreading in the background using dart(the current advice is to use platform specific plugins which isn't robust for services that run without a visible app). You're also wrong about xamarin- you do have direct access to android sdks(if you know enough C# to correctly translate the API usage into Xamarin android - which is a bit of a headache admittedly)
i really like the flutter dev community btw, very agile and open to newer ideas for plugins. havent seen this in react(fb controls all and devs usually just talk about js patterns all the time) or xamarin(community is nonexistent at this point, even questions barely get answered unless you post an interesting one on the gitter monitored by core xamarin devs)
That's mostly my opinion as well... Your better off with a mostly portable web based codebase, or dedicated or hybrid apps. Say what you will of Facebook, their ux approach with react send the most pragmatic.
You can't avoid learning Kotlin & Java, that's the native language for Android platform. Even if you use Flutter, leaky abstraction mean you will probably have to dig down to the native layer as your apps get more complicated.
That’s right. I’m a professional plugin developer. I’ve got my hands in both worlds, making dart APIs into the Obj-c/Java bridge where I’m implementing native APIs.
And several universes as well...I do plugins for React Native and Cordova, as well: same thing but JavaScript APIs into the Obj-c/Java bridge.
>This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ?
Oh come on. Pick one. That's what you do for every other platform. Hell, even for web development, you'll have to make framework and transpilation decisions. This is no different.
>These guys can't afford 10$ courses on udacity and Coursera.
Yeah, too bad there are no free ways to learn programming languages on the internet.
But there is something arrogant about stating that programmers in developing nations somehow aren't capable of reasoning about tool choices for Android development.
Yeah, get out of business if you can't afford to send your offshored $5/hour indian developers to a 1-time $10 course to learn a new paradigm... Not sure I'm for flutter, react native, or some other (shopping around now for a good cross platform solution, quasar + cordova might be enough for my needs as I prefer vue), but these people need not be in business if they have no money to run their business properly. They'll just get shitty code that someonee else will eventually have to rewrite.
edit : I am not a Googler, but that's what I gathered from talking with them
Here is what is happening :
A couple of years ago, when the dart team failed at getting their runtime embedded into the browsers, they started searching for a problem to solve. They thought they had hit jackpot with multiplatform development. So they started working on Flutter. This is all entirely independent from the Android team at Google.
The Android Team at Google continuously improves their own framework, hence the jetpack set of libraries. One of the new libraries they have been working on and that is now public in pre-alpha stage is JetPack Compose. They have hired one of the engineers behind React and had them work inside of the Android Team on a "React like UI framework for Android".
The official direction of the platform is what the Android Team is doing.
Flutter is interesting, with all the advantages and caveats shared with other multiplatform tools like ReactNative.
As far as the bit about Flutter goes: Flutter was started by engineers from the Chrome team, and myself (who worked in the open source team as editor of the HTML standard). We had no relationship with the Dart team at all until some times into the project, when we were looking around for a language to replace JavaScript in our project (codenamed Sky at the time). We considered a large number of languages but ended up picking Dart because it was the best fit (see the Flutter FAQ for more details). We then had to learn Dart and made friends with the Dart team, with whom we now work very closely.
Languages I recall us considering include: Java, Kotlin, Swift, C++, Dart, Lisp, Lua, ObjectPascal, Python, C#, Go, Rust, TypeScript, JavaScript itself, Perl.
I wish I had our notes from back then, but I looked for them recently and couldn't find them. Our best theory is we did it on paper or on a whiteboard. :-(
How cross platform can this be? What's the fallback plan if you need some API that's unavailable? Simply having a lightweight native wrapper around the webview allows a lot of oomph.
Invest in Kotlin. It's been created by Jetbrain and they are showing clear support for it. I can't say the same about Dart. Google won't support Dart, GWT, Angular, Polymer ... eternally. Yes different purpose, tech and ambitions but too much overlapping. In case of a "more wood behind a fewer arrows" situation, you'll have to pray that the Google gods didn't choose to sunset the stack you bet on.
I don't mean to be cynical, but the answer may be 'whichever language wins'.
Maybe Google wants to support Dart because its built in-house, while simultaneously supporting Kotlin because it is so well loved by developers. Just a guess.
No. Mobile Dev is not anything close to web dev : developers don't have control of run time devices.
Google is now mandating 64 bit APK for its apps (after years and years of trying) - that's a end device support issue. React native has had 64 bit problems for years.
Viewmodel is a lifecycle aware component. Android Q will come with foldable-aware SDK. Will that be
supported both on Dart & AndroidX/Kotlin ?
Someone has to explain to Google management that an ecosystem that has gazillion different devices , that are not in developer control is a far different beast than web dev .
Microsoft understands this better than anyone else. Look at their bug-compatibility spanning 30 years.
We cannot afford a fight-to-the-finish when my customers are on a gazillion different devices with different hardware. NBU markets like India operate at a very different level of complexity than the two-device markets of North America.
As a developer you cannot expect that the technology you learned at university will be used forever ( or actually at all) in your professional life. Schools are supposed to teach you enough of the fundamentals to be able to adapt and learn the tech du jour on your own.
The sooner your students learn that lesson the better.
this is not an issue with two languages targeting the same SDK. you are mistaken on these aspects - I'm not sure if you are an android dev, so please forgive me if I'm pedantic.
Kotlin vs Java is the situation you described. They both target the same underlying SDK. For example Pyspark vs Spark-scala. You can program in either, but you are still using the same paradigms - RDD, Graphframes, Dataframes.
Flutter and AndroidX are not even the same paradigm - the lifecycle management is completely different. Android development forces you to think in terms of Activities and Fragments since they are a lifecycle model. Flutter changes it entirely.
I'm pretty sure I can learn it fast, but the issue im asking is about investment. If you are running a company with 100 android devs, where will you invest your training and future architecture research.
Or do you believe that the code of an app that's being used by a couple of million users for financial transactions can be ported to a new framework in a jiffy ? Just the testing and validation impact is huge.
The issue is that we are just coming out of a Java -> Kotlin transition that required significant investment on our part. Because of Google making their stand very clear that Kotlin was the future. So now, this is very confusing.
Sorry, i read your original post a bit too fast. Indeed, for corporations that’s a big question ( i thought you were teaching students, not hiring them)
And you think that anybody can answer that from Google? There are different factions in every company, they are fighting over things constantly. This is why Google has many similar products.
There's been activity porting the Android Java components to Fuschia.
I have no inside information (not a Googler) but that leads me to believe that if Fuschia becomes the next mobile OS from Google it will support both.
So same goes for Android I would assume. Why does an OS need to have a single stack? You can write desktop apps in a zillion different languages and Frameworks after all.
s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about.
> You can write desktop apps in a zillion different languages and Frameworks after all.
You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Electron/CEH but lose performance and still have to do a lot of trickery, and so on.
> s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about.
Is this necessary? Also, you definitely shouldn't be throwing stones while living in a glass house. s/mobiles/mobile
> You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Electron/CEH but lose performance and still have to do a lot of trickery, and so on.
ABI only matters if you're linking code or directly running bytecode on another platform. If you're targeting another platform, you're almost certainly going to recompile libraries/your application to target the new platform, so you won't run into ABI issues. Especially because most desktop platforms (read: x86) have bytecode incompatible with mobile platforms (read: ARM).
Also, Qt and Electron are abstraction layers over OS interfaces. As long as the OS supports the required primitives you could presumably rewrite Qt and Electron to target the new platform. Although it might take a fair bit of work, people have done so.
Aside: Would love to see electron and Cordova bridge the gap together for mobile targets. If they can establish a few common interop libraries, you could come very close to the same code for both.
I'm really uncertain about a huge JavaScript runtime on mobile -- seems like an energy waste/slow code. Dart's AOT story the Cupertino wrappers for iOS in Flutter really excite me.
Disclaimer: I work for Google; all opinions are my own.
The runtimes is already there. Not to mention there's still room for improvement.
I'm not against other options being available. But there's a certain amount of pragmatism to being able to use the same skills, developers and code to approach development that targets several disparate platforms in a very open way.
My favorite language is JavaScript for all the flexibility. My second and third are Rust and C#. Just getting my feet wet with rust and have done C# from the beginning. They all have very different reasons to exist and most applications can be written with any of them.
In the end of the people paying for the development cannot fund a given approach, there's a certain pragmatism that must and should take priority.
With JS I can use functional, classical, and procedural approaches and mix them as needed. There are foot guns. They are there in every language.
As to overhead and battery, I can see the point. If rather have an app with more overhead, than no app at all. I use Windows, Linux and Mac and tend to favor apps that work everywhere. If like to see that extended to phones.
Me not knowing how to spell the name of a plant/colour/operating system has something to do with my recollection of recent tech journalism?
I appreciate the correction of my spelling (honestly) but this is a bit of a stretch.
Your API/ABI point is also completely off topic. My comment points out that on the _same_ OS you can use different technologies, like Electron or Qt. I'm trying to point out that having both Kotlin and Dart/Flutter as options isn't bad or unprecedented like the parent comment seems to allude to.
And what do you think those plugins implementing the native sensors or CLLocationManager / FusedLocationProviderClient is written with? Obj-c/Swift and Java/Kotlin.
>Android development will become increasingly Kotlin-first,” Google writes in today’s announcement
https://techcrunch.com/2019/05/07/google-launches-jetpack-co...
>Google today announced the first preview of Jetpack Compose, a new open-source UI toolkit for Kotlin developers who want to use a reactive programming model similar to React Native and Vue.js.
This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ? Remember I'm talking about developing nations like India - where startups like ours invest in training college graduates . These guys can't afford 10$ courses on udacity and Coursera.
But even if it was not India, having this parallel signalling for Android based startups is very confusing. Atleast Apple was very clear about Swift .
Where will Android be in 2 years : Dart or Kotlin ?