Flutter and Dart, or how to quickly build a mobile app without losing your hair
altkomsoftware.pl
altkomsoftware.pl
But I think keeping in sync changes in API, hardware device drivers and new interactions across different platforms and device will still be nightmare and in general it will play catch up with native. It can be seen in the number of issues opened on flutter project on GitHub [1]. Hopefully there is some support from different platforms so it remains reasonable choice and perform well compared to native.
Also it’s declarative UI paradigm is good and even SwiftUI is doing the same.
I had concern about this project earlier although personally I looked at Dart just because it’s developed by Lara Bak the person who transformed google by giving them V8 engine in chrome. Earlier dart could not take off because no one wants dartvm in browsers except chrome.
It might not have succeeded in replacing JS from browser but Flutter is dart’s killer platform and it is very much focused now on becoming a language focused on user interface programming. So I think dart will survive beyond google.
I also had concerns about Dart/Flutter at first but they almost entirely went away a week after starting.
It’s just really friendly. As far as Flutter is concerned it’s awesome you can see the Dart objects that build the Flutter widgets, the language itself is good and getting better, I’m just really happy we went this direction.
I am an optimist; I have high hopes for the future of mobile development. Specifically, I hope that the developers who develop AndroidOS and iOS will metaphorically bend over backwards to make Flutter compatible with those operating systems. After all, isn't it in Apple and Google's best interest to make mobile development as painless as possible?
Android exists so that Apple doesn't have 100% of the market share, not because Google cares about the UX of the users or the developers.
I think neither have any real incentive to make Flutter work better than it already does.
Why? Last time I checked, Android had 85% of the market share.
A chunk of Android's market share is people for whom $5 isn't a coffee but a days wages.
My team develops and maintains a mobile banking application for a national market of a small European nation, and our user base is 70% Android. Due to wages here, 5$ is chump change.
Obviously though, we aren't monetizing our product in the usual way.
I think that could be a large difference in approaches.
You are a bank and want all of your customers happy. If bank made an iOS only it would piss off a lot of its customers.
On the other hand if you are monetizing, you have to look at revenue streams from both platforms and decide which is the bigger revenue stream (not most users) and make sure that one work's first. Obviously you want both to work well but if the split is 70/30 to iOS you will prioritize iOS first.
Also, I absolutely didn't mean to say it's impossible to monitize Android. I only meant to say it isn't clear Android is a significantly more rewarding to target customer base than iPhone, as my parent said.
Lars Bak
> no one wants dartvm in browsers except chrome
The Chrome team also rejected the Dart VM
I see React as a web-first framework, and RN as a fast path for porting to mobile. I've heard that flutter has early stage web support, but that it's all based on canvas, which is enough to dissuade me for using it for a web-first app. I'd be curious to know your perspective on this.
Dart and Flutter futures are are now married, and I still don't buy into Flutter.
Languages married with UI frameworks seldom last, specially when the competition outside of the UI framework is so much better in tooling and available set of libraries.
Plus hot reloading were a novelty when Smalltalk, Common Lisp, Oberon System, Eiffel got introduced into the market.
And the competition isn't sleeping either, Flutter touched the Android team nerves hard enough that now we are getting Jetpack Composer, Xamarin already has its prototype available, Qt always kind of had it, so in the next twos (give or take it), all the cross-platform mobile frameworks will have dynamic code reload, with more market relevant languages, couple with 20 - 30 years of libraries.
Until Google releases Fuchsia and makes everyone write Dart code, I will pass. Qt, Xamarin, PWAs do the job just fine, with more mature languages.
There's some merit in the mature language argument but dart has been around for some time now and doesn't have any radical features - although on the other hand you seem to be saying it's not novel enough like Oberon etc.
Do all those others have 20-30 years of libraries? I think that's just Qt. I spent a couple of years using Qt and it's very good but it is C++ which isn't for everyone. (The python version probably fails your maturity criteria)
What FUD? Had not been for AdWords team there wouldn't be any Dart to talk about.
Right now, Dart is meaningless without Flutter.
While all the other languages are a safer bet, in terms of what to have on the CV, even if the frameworks written in them fail in the market.
Also UI programming is very complex given the proliferation of device form factors, interaction and implicit inputs using sensors. It needs language especially designed to handle all of it and provide a smooth user experience. For end user UI is the whole system. Dart is especially designed for it.
It provides superior developer experience compared to other cross platform UI toolkit. I think a language designed for user interface programming providing clean, smooth and performant developer experience is a need which dart fill.
Obviously not everyone likes declarative UI programming and they will lean towards what they know. I am from the camp who prefer declarative UI’s and that’s the reason like SwiftUI and Flutter.
Is that true? Pretty sure Munificent is still on the team and he's been the only Dart team member I know of...
This doesn't appear to be true. Do you have a source?
Dart itself is very simple to pick up basically as you write. It feels like the most generic 'algol family' language imaginable, in a good way.
The widgets itself that the framework provides are very complete and make inuitive sense. This was a big differentiator for me compared to my modest experiences with react a while ago.
As someone who doesn't live in the world of UI and end-user software at all react was not easy for me because I had to learn javascript and css and html and so on. When the last thing you've built UI wise is Java desktop apps ten years ago that's not easy. Flutter felt much more like a traditional desktop framework in how high-level and complete it is.
pros:
1- Everything is object. (no more inconsistencies like Java primitives, null and generics)
2- It has very well designed generics and you can access generic type in run time.
3- Good Type inference.
4- Has powerful facilities for asynchronous programming.(eg: async await, coroutines ,...)
5- Not overall bad or complex type system. Compare to Golang or java dart's type system is vastly superior.
some cons:
1- Everything can be null (null is also object).
2- Lack of Union and algebraic data types.
3- Lack of python's like tuple.(eg: (1,'string'))
4- I personally dislike C-style type definition and mandatory semicolon (eg: int foo=23; rather than foo : int=23 )
I see the plan to allow libraries to opt-in and migrate that way.. but I wonder how long that migration will take and if it will ever actually be completed?
For example, you can have a List of type List<string>, which would be a list of any length containing any string.
On the other hand, a good tuple implementation (especially a typed one) could allow tuples like (string, integer, boolean), i.e. only arrays of length 3, where the first positions holds a string, the second position holds an integer and the third position holds a boolean. So yes, usually they are represented as arrays, but on a higher level, they are fundamentally different.
As for unions, the parent comment is not referring to the Set operation, he's referring to Union Types.
With this concept, a variable can be one of many types. For example: var input: string | number And at Runtime you would have to find out whether it is a string or a number, to be able to use it.
(Not here arguing whether Dart does or does not have these language features, just trying to clarify this misunderstanding)
For example, in C, you can define a Union type that can hold either a string or an integer, declare a variable of that type and initialize it with a string, and then simply assert that it is an integer.
I think that with your assertion of "valuable in catching bugs" you are referring to Sum Types (often called tagged unions). For Sum Types, if a language supports this concept, it usually also forces you to cover all cases at compile time, whereas with plain unions, you can shoot yourself in the foot, if you're willing to do so.
I think over time the crippling of Google’s developer initiatives because of this perception will cost a lot more than all the money saved from all the retired services.
Flutter is the UI framework for Fuschia. It is picking up huge momentum [1]. The support for native apps and web[2] is still immature, but promising.
Flutter brings the joy back into UI development. No messing with CSS, tables, etc. - "everything is a widget" makes for a very composable framework that is super fun to use.
[1] https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2... [2] https://flutter.dev/web
Plausible, but i wouldn’t put odds on anything.
LUCKILY, for me because i really like Flutter, I think it hits critical mass soon and wouldn’t matter if Google killed Fuchsia.
From day 0 on launch, you can expect Fuchsia to run your Dart apps and to run existing Android apps via a tool called Machina (Zircon hypervisor running Linux kernel). If Fuchsia benefits from the Flutter apps being made and gives Google more complete control over the OS unlike Android, then it looks highly unlikely that it will be killed.
In reality as Fuchsia is being ’dog-fooded’ on Google devices it is increasingly likely that Android will be killed.
If Fuchsia ever gets released, I bet ART will replace Flutter.
It is already being ported to run on Fuchsia anyway.
Flutter has zero relationship with ART, it just plugs into Android via the NDK, like anyone else using C++ code.
Where's that "huge" momentum?
Often this is a conundrum of naive technologists clamoring to shove untested tools into production for... reasons? Excitement? Risk-taking adrenaline? I'm not quite sure.
Yes Google's marketing oversells (or even lies a la Google Stadia), but at the end of the day I think Google SREs/devs/evangelists expect (wrongly) some measure of common sense and restraint from users and that is just not there. For example, if you ever watched some of Kelsey Hightower's earlier kubernetes talks he practically begs users to deeply consider their use case and whether or not they should actually be using kubernetes.
Google also expects their users to SRE/devops/refactor/upgrade constantly like they're able to. Which is also insanely unrealistic.
Ultimately, while some cases are Google's fault, often the blame is shared - most of the time. The market realizes this and thus the opportunity cost is already priced in somehow.
My understanding is that you get promoted at Google for launching new things, not for maintaining them, so there's a perverse incentive to launch projects that become orphans almost immediately. So much so that I wouldn't even say that they retire popular services prematurely, but that because there is no institutional will nor support for these projects to survive into the future, they are simply de-launching proofs of concepts. Translation: nothing is intended to survive at Google besides search and AdWords, and everything else is subject to cancellation at any moment without warning.
I'm not sure what you're saying about sharing blame, that these products are too popular? I'm not sure that's a sufficient reason, but it would certainly explain Google's overarching product strategy through the decades.
> I'm not sure what you're saying about sharing blame, that these products are too popular? I'm not sure that's a sufficient reason, but it would certainly explain Google's overarching product strategy through the decades.
I'm not sure if it's sufficient cause either, I just try to peel back the onion to understand more then just "those people are dumb profiteers with simple minds making simple mistakes". Also I think it yields some unique insight into my own work/coding/life when I identify the deeper subconscious flaws in product development.
If we look at main projects/products at Google like Chrome, Search, Gmail, Android, YouTube, Maps, Kuberenetes none of them has any serious competitors out there (except for Android perhaps). I mean, sure we technologists are more aware of alternatives and open to try new things but almost every average user I know is utterly uninterested in an alternative. There's a perception of Google as simply being the most technologically capable company on the planet for average users and that any alternative simply can't match, let alone surpass, Google's offering. Sometimes, when I think about, there's some truth to the latter part of that sentiment. Google does a good job with the projects that actually last.
So, perhaps any project that can't have a similar traction in the market probably doesn't get a whole lot of attention on a collective level.
But I do have some criticism for dart. While it's nice that they moved to a static types, they still made every single type nullable. So e.g. if you get a boolean in your function, be aware that it can be true, false and also null. I have my problems with java having nullable objects, but having the primitives also be nullable?
Well, I'm pretty much a beginner, so maybe there are better ways and I still don't know them. But afaik, they weren't mentioned in the brief Dart intro on the flutter page.
Dart does also have some cool things, though: Extensions (for adding interfaces to existing types), explicit getters, async/await and lots of syntactic sugar. Building your widget-tree in dart sometimes looks like a declarative style similar to xml, but far more concise, except that it's really imperative, which is really cool. No long
Component a = new Component();
a.setOnClickHandler(xyz);
a.setColor("green");
b.add(a);
chains anymore!
NNBD is almost here: https://github.com/dart-lang/language/blob/master/accepted/f...
The dev experience was lightyears ahead of Android. Dart was nice fit. I came upon some edge-cases where Flutter's API seemed immature. But as far as quickly getting apps/prototypes out there, there was no competition.
My main roadblock: the UI was centered around Material design. To use the iOS widgets, which looked good, it seemed you need to put a load of if statements to use the iOS widgets instead - and this felt hugely cludgey.
I'll reiterate what another poster said: if your business depends on apps, go native. Flutter will get you to 90 or 95% really quickly but it's probably that 5% that gives you an edge.
I'd use Flutter when apps are of secondary importance to the business, and when we need an iOS and Android app, and I want it done without spending huge amounts of effort.
The first "problem" was Javscript.
At one presentation about this I recall that Lars Bak (IIRC) took quite a beating about DArt, just in terms of the questions asked, to the point that someone had to point out just how much he'd accomplished (ie V8). This was, in essence, an appeal to authority.
I recall the Ads PA basically stepping in to save the project. I can only speculate why but my best guess is the AdWords TL woke up one day and decided to rewrite AdWords in Dart (as he allegedly had with GWT some years before). But all that's pure speculation.
The second "problem" that Dart solved was using the same code on client and server, something Google is inexplicably obsessed with (eg GWT). I don't know what caveats came with Dart but GWT had plenty (eg for many years it wasn't possible to use the same protobuf classes on client and server).
I believe the intent with Dart was, at one point, to run natively within Chrome (the article mentions Dartium). This worked out really well for vbscript. No one wants to write different languages for different browsers. Again, I speculate here, but my strong suspicion is the Chrome team killed the idea of shipping a Dart VM in Chrome and that was the end of that.
Maybe it's just me but TypeScript just seemed far more sane.
So... Flutter. I don't know why a UI library needs to be language-specific but it strikes me as a bad idea. Now, the counterpoint is that Flutter is an SDK And more akin to, say, React Native (albeit with significant architectural differences) but I don't think it started that way.
:UI frameworks, libraries and SDKs just don't seem to be in Google's wheelhouse (as opposed to, say, infra, which very much does). I can only speculate as to why but my best guess is Google engineers (disclaimer: Xoogler) can't see passed something as an engineering problem, so much so that they take on philosophies no one asked for or needed (eg same code on client and server), which come with a huge cost and no tangible benefits.
[1]: https://insights.dice.com/2019/03/27/fall-rise-dart-google-j...
Yeah in a video last year, Lars said "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://www.youtube.com/watch?v=mPna6D21Eqg&feature=youtu.be...
Mostly I agree with you, but coming from desktop development, I also sometimes feel like javascript and the web in general is a mess, and prefer things in a familiar format. As so I don't find things like "DArt" or "Flutter" as surprising...
I don't have a strong opinion on Node.
> Electron apps perhaps?
Hate them with a passion.
> What problems did these technologies solve?
Node.js to is primarily a platform for high-concurrency event-driven request handling where each request itself is a single thread. In my day job I primarily write Hack (PHP) nowadays. PHP embraced this model years ago and I, personally, think it's pretty much ideal for something most often used to service HTTP requests. You almost never want to be in the business of starting and coordinating threads. It gains you a lot of complexity and a lot more failure modes for very little benefit over the single thread per request model (combined with async/await programming, in particular).
Electron is, in my opinion, trash. It's a cheap and crappy way for people to create desktop apps that have a much larger attack surface than any native desktop app (being the entire Chrome runtime) and a huge memory footprint all for the privilege of being able to use HTML/CSS to layout your app.
> and prefer things in a familiar format
So this explains a lot of the things you see from Google. Google engineers, in general, look down on Javascript. There's actually a hierarchy. The C++ engineers look down on anything that isn't C++. Java engineers look down on anything that isn't C++/Java (and sometimes even C++ is looked down on) and so on.
A lot of Google JS is written for the Closure compiler. This was an early effort to add type hints to JS code. If you look at the code you can tell it's written by Java engineers. I like to quip that "Closure puts the Java into Javascript". The JsDoc comment format is basically Javadoc. The type system is familiar to those coming from Java.
So you have GWT, which seemed to appeal to people who though tit would allow them to not need to know anything about JS [insert standard reference to the Joel Spolsky's "leaky abstraction" essay].
Closure tries to remake JS into Java.
What these things tell you is the people coming up with these ideas don't really understand Javascript and more to the point, they don't think they have to nor do they want to.
> I also sometimes feel like javascript and the web in general is a mess
Everything is a mess if you look closely enough.
Electron promises same code works on web, Mac, Windows, Linux. I don’t see anything come close to it’s offering.
Surely I’d love electron to share the memory footprint with installed chrome. The execution could be improved (I imagine someone at MS is working on it, now that Edge is also Chromium powered).
I realize they can't use Java, but this is a weird horse to tie themselves to.
The chrome guys decided to move on and look at several language before going with Dart, Swift may have been an option, if it was opensource at the time.
Seems a reason for Dart's failure in the web space was mobile.
Lar gave a talk last year about his and Kasper iot startup https://www.toitware.com/ he mentions why dart didn't make it into chrome, saying "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://youtu.be/mPna6D21Eqg
Once a language is in use in many places, you can't do that anymore.
Apple did this too when they wanted a language that was compatible with Objective C.
And this is how JavaScript got started, after all.
HN: Learn a new language every year, it's easy and worth it even the language isn't useful for anything. Also HN: I won't learn a new language that would allow me to double my mobile dev productivity because someone told me it was bad 8 years ago.
If Google creating a language is reason to believe it will die, why does that apply to Dart and not Go?
This assumes you've observed the much higher popularity for Go and lack of it for Dart here on HN (and most elsewhere).
Dart overlaps in goals almost completely with Typescript which is heavily used multiple teams within Google.
Switching Flutter to Typescript is something I could easily see happening if Google wanted Flutter to be truly popular.
As I see it, that's not all that true.
Now, it's true, that it's non-native use competes with TypeScript in domain and shares some implementation method details in that domain (e.g., both are languages that rely on compilation to JS in the web domain), but the goals clearly aren't the same. TypeScript's goals are basically limited to static typing and source compatibility with modern JavaScript (that is, it is an goal to be a typed superset of JS.)
Dart has a wide array of different goals, including being a typed replacement for JS that is not limited in its other goals by being source-compatible with JS.
You are talking about an extremely vocal minority, who inevitably ends up creating echo chambers.
Like everything on earth there are both good and bad vocal minorities. I follow this heuristic about vocal minorities: ignore them when it comes to trivial issues. Online vocal minorities like fanboys who harass directors, writer, or actors are good example of this group. Same goes for the people who constantly complain about Google shutting down some free products. OTOH, I keep close eyes on activists, who are vocal minorities and are fighting for important issues. Activists might not be on the right side of history on every issue, but these are the people who fought for civil rights, LGBTQ rights etc., often at their own personal expense.
This may reflect more on the development of those particular apps than the framework though, hence my asking - in my experience, React Native does a pretty good job of feeling “native” by default in most cases.
Not saying users would necessarily care so much, but I’m interested regardless - I wonder if there have been any studies/anecdotes into how sensitive users are to “details” like animation etc. in terms of engagement.
my intuition is that flutter is used mostly for business apps made of forms and lists, where expectation in terms of graphical performances are very low.
I'm also open to being pointed toward a productionized Flutter app that feels native in the same way as some other x-platform solutions manage to exhibit. It's difficult to sift through the existing live examples.
They are clearly trying to attract the "brand first" marketing crowd by stressing fast graphics rendering, animations, full customization, etc.
I bet we're going to see a flood of Flutter based retail, fashion, food, sports, motor and lifestyle apps very soon.
As it should. React Native wraps around the native controls of the platform as much as possible. Flutter just renders it's own controls in OpenGL.
Before Flutter, if I needed to build a simple app (couple of screens and network requests), there were no real option except of outsource it to the mobile app development studio. After discovering Flutter I've built and published my first app in 3 days while watching initial Flutter tutorials.
Since then, making mobile apps for my projects has become such a pleasant experience, that I'm now trying Flutter Web as a substitute to the madness of JS/HTML/CSS ecosystem, and I'm quite impressed with a result. It's still in Beta, but the development experience is so much smoother.
At the same time, a lot people still don't know what Flutter even is, so having it in your arsenal is a huge competitive advantage at the moment.
React Native, Xamarin, Ionic, and a ton more?
React Native was the best shot in this market, but adding the worst UI framework in the history of software – typesetting markup language (HTML), set of global classes for styling with magic words like "!important" (CSS) and hackish scripting language designed under pressure from Sun in 2 weeks (Mocha, renamed to Javascript) - on top of the already complicated stacks yielded all sorts of problems: from dependency management hell to unforgivably slow UI. Even AirBnB – the largest React Native shop over there – abandoned it altogether and returned to native iOS/Android development. My own experience working with React Native project for 1.5 years (with ClojureScript added on top for coolness) just reassured me that 5 layers of complexity is worse than 1 layer :)
Flutter design is so sick, that unless I'm writing own native plugins, I don't even touch iOS/Android layers. So it's basically single layer of complexity from the perspective of the developer and it's a game changer in this field.
AirBnB abandoned it for other reasons - mostly difficulty integrating it with existing native codebases and developer pushback, without fully commuting to it. MS Office, Shopify and a host of other products are fully invested now.
Flutter doesn’t have native UI, so I don’t think it compares well (or will catch up for non-gaming/casual apps).
I think we've all learned at least that much in the past few years.
A lot of businesses either overestimate or underestimate their mobile product needs because they don't understand the market or the platform. Expectations for an interactive consumer mobile app (Ride-sharing, Social media, Photo editing, etc) are extremely high and it would be foolish to under-invest or try to take shortcuts. At the same time there are ton of businesses (Home listings, Saas tools, Informational apps, etc) that would be well served by a simple React Native app. Know which type of business you are.
If these banks want to compete with revolut or transferwise they need to provide an app that's isn't garbage.
Contrast this to Robinhood, which jumps from cold boot to main screen in about a second.
The problem is not the frameworks, it is poor development practices. Until the big guys learn that outsourcing critical software is a stupid idea, the next generation cool kid apps will continue to eat at their customer base (until they become relevant enough to be bought out by the big guys, and the cycle repeats).
For an entity like Snapchat, it is the business. It'd be stupid for them to even think of trying to cut corners to save a few bucks by maybe sharing some code.
We’ve built a pretty complex and highly visual music learning app for iOS and Android recently, and thanks to the combination of React Native, Unity and JUCE (C++ audio framework), pretty much all the code is shared. Seeing it run on Android with no big changes needed (aside from audio stuff, which is a challenge on Android in general) for the first time was pretty impressive. Even given unlimited resources, I’m not sure I’d choose to go down the 2 native apps route - automatic feature parity across platforms is a pretty killer feature.
If you were building something like Snapchat where I guess things like app startup time and performance on budget devices are important, I can see why you’d choose to though.
Most of those apps are perfectly doable as PWAs.
I'm also seeing the Expo.io project (ready made starters for React Native) mature to production quality extent.
At this point, I'm seeing a massive production scale behind React Native which doesn't exist in the Flutter world.
Plus the elephant in the room - React. How do you compete against that ? Incidentally, Flutter was inspired by React.
At this point, if I had to take a bet - React Native would win against Flutter definitely. There will still be a massive Java/Kotlin userbase...but I don't see why Flutter will exist in a even-Microsoft-Office-is-using-React-Native world.
React Native is also one of the reasons why WinUI core components are all going to be C++, instead of a mix of C# and C++.
Future common data boilerplate. Qt/gtk-style app init boilerplate. Routing boilerplate. Future builder boilerplate. Homepage title state boilerplate. Setmapsfordicts boilerplate. DTOs. Widget scaffold. Step builder boilerplate. New policy subject(?). Complex handwritten setters and validators.
How on earth is that not losing your hair? Can’t we just drop a list view, few controls on a form, attach field formatters, and then write a simple controller that implements a part of a table view delegate and a save method? What’s wrong with modern ui?
Do you know any company that doesn't retire a product once it's deemed obsolete?
Leads to an empty repository.
[1] https://github.com/asc-lab/personal-insurance-flutter-poc
I know almost no JavaScript. I know C and asm and python. So... looking at the two, guess which one looked better to me?
The code for Dart just makes sense. It’s not beholden to JS or XML or HTML or CSS. It just does it’s own thing.
If you are heavily invested in JS, I bet there are aspects of Flutter that are still appealing, but if your aren’t invested in JS, I see no reason to get in just for React sake.
I fail to see your point; surely Dart was a new language for you as well?
As a counterpoint, we have whole swathes of JS engineering teams building new mobile apps and would select react-native / Typescript (and where possible Expo) over Dart.
Maybe react-native is easier if you don't know react but for me it seems to keep only the worst parts of react and forcing you into using a lot of components for ui that I found to be poorly documented.
I’ll definitely continue to observe Flutter/Dart, but the investment/payoff doesn’t appear large enough yet for our use cases.
If Flutter apps are two things, Flutter and Dart. Then React Native apps are six things or so.
A few years ago, I was CTO of a small startup and spent a significant portion of a year building out our mobile app in React Native.
I have experience building cross-platform mobile apps going all the way back from when Ionic was called Apache PhoneGap and was an entirely different product.
In my opinion, React Native is a classic case of follow-the-herd syndrome. This is not to say that React Native is not a viable technology, but simply that it just isn't very good. Let me dive into a few of the things that were really grating when developing on RN:
- The hot-reload times were painstakingly slow. I am talking about 15-20 seconds after save. This really takes a toll on development velocity.
- You have a major decision to make when building an RN app: To use Expo or not. Expo is an SDK which allows you to circumvent needing to drop down into the native build processes for each platform and provides wrapper APIs for accessing native hardware functionality on the phone, with the tradeoff being that a wide number of RN libraries were not compatible since they required being installed as Cocoa Pods or Gradle/Maven packages natively. So you are trading convenience and development speed for flexibility. We chose to go with Expo, and did not regret it.
- Performance is an issue in RN that you need to aggressively optimize against. I remember being aghast that rendering a scrollable list of 300 text items caused so much lag and stuttering it required a full day of manual optimization to calculate viewport area and which cells would be in view to prevent that work from being done by the element on-thread in order to be semi-usable. You have to be really cautious about your render cycles and everything else when building views.
- Doing heavy custom styling requires some hacky workarounds since RN wraps the native UI elements and does not expose all of the style API that they provide.
Later on, at another company, we ended up building an app with NativeScript + Vue which was a much better experience. NativeScript is essentially React Native, but allows you to use any JS/TS framework (or none at all) and has much better APIs for interacting with the device, and allows you to fully style the underlying device-specific UI element if you really need to. And the performance ran circles around RN. The entire experience was overall miles better. Very few people use NativeScript though, just due to the fact you never hear about it.
Ultimately, if I had to give advice, it would be this:
Either write a regular PWA web app, so that you can leverage existing web technologies and all the component libraries, and then add native functionalities and publish to the app store using the Capacitor framework that powers Ionic apps. Or just use Flutter.
Flutter has the only cross-platform mobile experience that does not feel really hacky to me. It does not try to compile to platform-specific view elements, instead compiling to native ARM code, and tries to maintain 120FPS. You can use the same Flutter codebase to generate mobile, web, and desktop apps. And the whole developer experience is really incredible. Instant stateful hot-reloading, screaming performance. Google put a lot of effort and thought into it, and Flutter is not going anywhere given that it powers all of Fuschias UI.
We may be in Peak React right now as adoption is at an all time high vs Angular and Vue. But tools such as Svelte and Flutter are the next thing that has a chance to be competitive.
Flutter reminds me of Vue, loved by Developers but low adoption (compared to React or Angular). At least Flutter is backed by a giant. Hopefully the adoption rate keeps increasing.
That's assuming Fuschia ever becomes a priority. So far, there is no reason to believe it will even launch, let alone be a priority.
https://blog.codemagic.io/flutter-vs-ios-android-reactnative...
Before my time, we initially started app development using Cordova. It lined up well with existing expertise in the office as that what we work with most of the time. The apps turned out rather well except for reliability and building. These are by contract applications, so we make them, release them and don't revisit them unless we need to perform support on them. Changes in the web browser, particularity on iOS has broken these apps on several occasions where we have to go back and fix them. Some of these issues have been expected, such as when iPhone X came to market, but sometimes an update has broken something else, seemingly out of the blue.
We decided to try out some new technologies as we we're not too impressed with Cordova and settled on Nativescript + Vue. Again due to expertise with vue as it is one of the technologies we utilize a lot in web projects. Pretty much all of the people who had been involved with the previous apps found it a better experience than Cordova. But in my opinion, it was also quite infuriating to work with. Hot module reloading never truly worked the way it should, we often had to quit and reload the app for changes to be correctly applied. It didn't end up as cross platform as initially thought. We had to make a lot of platform specific components for things we initially didn't think we had to, mostly because the shared options of components in their standard libraries we're not as good as we had hoped. We ended up spending way more time than initially thought wresling components into submission in order to get close to the design we initially envisioned, and we ended up compromising a lot on UI in order to make budget and deadlines. Performance was also something I we had to optimize a lot more for than initially planned. Animations and screen transitions would usually take a performance dive even though our views were very simple and did not really have much data in them at all. We struggled a lot to wrangle UI components into shape, hence why we felt we had to make so many components. And we encountered issues with very simple components such as images in list views not rendering if scrolled out then back in from views.
For this next project I suggested we try flutter before committing more to NativeScript, and we have seen immediate value from this technology over any of the others we have tried.
* We spend way less time on platform specific code, the reusable pieces look more consistent across platforms which means we spend less time tweaking them for either iOS or Android. I think that flutter using its own rendering technique is a serious boon to us who are just making cross platform apps as cheap as possible.
* Any non standard UI component is often way less time consuming to develop in flutter as you don't have to write platform specific version of it. This has also let us cut down on external dependencies which we felt were necessary on Nativescript in order to implement some features in the allotted time available. This is something I think we will appreciate a lot over time, as NativeScript does not have the most active community and the potential work we will have to do to maintain components that may be abandoned by their original developer down the line.
* Tooling works a lot better for flutter. Hot module reloading actually works(most of the time). Statefulness and these reload is not as smooth. Actual breakpoints and debugging is very nice. We could get that with Nativescript too, but only in the javascript code, not for the templates which were written in XML. And if something went wrong on the "native" side, it would be like a black box to us which we could not truly inspect our way into. Flutter allows us to follow the stack deep into any widget.
* When you have to write native code for Flutter, you at least get the help of the tooling built for native platform development, as opposed to NativeScript where you declare that in javascript. It is very seldom needed for the kind of projects we've been doing however so I have no great insights here.
I'm very apathetic towards Dart as a language. It is entirely inoffensive. I felt like I could work in it without even trying to learn it, and I think I have spent at most an hour or two hours to look into and learn the more dart specific language features. I am not that much of a fan of how to deal with JSON data and the dynamic type in there. Dynamic feels a bit accident prone but other than that, Dart as a language gets less on my nerves than some of the more common and frankly way more tedious web related programming languages I have to use daily for work.
As far as the kind of work we're doing, Flutter is great
https://www.ideamotive.co/blog/what-to-expect-from-react-nat...
https://reactnative.dev/blog/2019/06/12/react-native-open-so...
You can also get Skia + whatever you want and get your own "Flutter".
Currently they still have a better experience to sell regarding code reloading, but competing frameworks are upping their game by adding similar capabilities to their developer toolchains.
Though at its early stage, as with all new Apple tech, you will still be losing your hair. Hopefully there's only a few months to go until a substantial increase in its stability (and documentation.)
I think there are a billion apps that no one cares about because developers have forgot about trying to solve actual problems in favor of “we have an app”.
For us, it was “learn once, write anywhere” for react, or “write once and actually use everywhere” for Flutter. Native wasn’t even a question for the size of the team on this latest project.
We make money by solving problems; not launching some app built with some language
With Flutter you have all of your focus on most of of the smartphone market practically for free which makes a massive difference in your addressable market.
No regrets whatsoever. There's no two ways about it - Flutter has already won the battle.
In fact, it hasn't just won the battle, it's already sitting in a spa celebrating its victory with bottles of champagne.
No idea about Flutter though.
Untested unstable software... Never going anywhere near this pile of shit.
Running flutter doctor is recommended in their "Getting Started" page to check the sanity of the install.
But I kept getting the same "license status unknown" error after multiple installs /uninstalls in various order.
Their GitHub issues page has this issue as closed.
If this is the state of a simple install I dread to venture any further into actual development.
This will be a complete waste of developer's time and resources.
I am merely sharing my experience. Do not waste your time trying the flutter / stutter / sputter.
flutter doctor --android-licenses
https://github.com/flutter/flutter/issues/16025#issuecomment...
If you just want to try out flutter, I wonder if you can avoid the android stuff by just running on ios and when they are ready the desktop and the web.
Unfortunately, that solution is a dud. It does not work.
flutter doctor is looking for the sdkmanager in an outdated directory.
The point is not "googling" for fixes, the point is this software is not a well maintained software if I have to spend hours to just "Get started..."
Developers, abandon this piece of crap.
Android sdkmanager tool not found (%LOCALAPPDATA%\Android\Sdk\tools\bin\sdkmanager). Try re-installing or updating your Android SDK, visit https://flutter.dev/setup/#android-setup for detailed instructions.
- Is dynamically typed at the core
- Has no support for nullability
- Has old school syntax for constructors, semi colons
In other words, Dart on the wrong side of history for pretty much every single important feature for programming languages in 2020.
Even C# looks more modern than Dart from a design perspective, and C# is fifteen years old.
- that's currently true but in the next release (at least that's what the Dart team have been working on for the past several months) it will have nullable types just like Kotlin.
- That's a strange criticism. Dart has excellent constructor syntax, I don't know a language that is more flexible with constructors.
e.g.
class Person {
String name;
int age;
Person(this.name, this.age);
String toString() => "Person($name, $age)";
}
main() => print(Person("Joe", 40));
There's some work being done to overcome this but so far no solution has seen the daylight in practice.
I don't think Kotlin is performant enough for Flutter though.
ART is able to do several nice optimizations, including vector instructions, and uses a mix of JIT/AOT with PGO.
Kotlin is performance enough, hence Jetpack Composer.
That's _far_ from performant for the use case in question.
A quite big one actually.
That has nothing to do with performance, and plenty to do with storage space and download times, as anyone knowledgable how compilers work is well aware of.
Is Android-specific, created specifically for Android, and it's almost as if the aim here was to develop a cross-platform framework that could at least target the two major mobile OSes in existence, one of which ships with literally zero Java anything. I brought up HotSpot because that's (part of) the canonical, actually-built-to-run-on-multiple-platforms JRE.
- Kotlin/Native
The state of Kotlin/Native is _far_ shabbier than the state of AOT-compiled Dart, and that's in 2020 (not, you know, 2014 when Flutter (then Sky) initially kicked off). It's interesting to me how in discussions like this people act as though the development of the project in question started literally yesterday.
I guess the lack of mature libraries and integration issues with Android native APIs is one reason why we consider it a language started yesterday.
- should target multiple mobile and desktop platforms (and not, like you seem to think, Android first or alone)
- is a game engine style, Skia-backed project, which you are essentially trying to pick a scripting language for.
So, do you actually have anything to back up Dart's runtime being a worse investment than your proposed ideas (which seem to be "go the way of Multi-OS Engine, that notoriously successful project" and/or "wait half a decade more for AOT compilation that would still be in beta and in a worse state than what we already have")?
yeah, whole 4,5 mb....