I picked Flutter and I'm really happy with it. The latest release of Flutter makes me even happier as there are some nice improvements. I'm using Material components because for me it is the bootstrap of UX these days and requires little thought to make a fairly clean UX. As a developer I can just drop in components as necessary.
* Hot reload, on device, works and works well.
* Really nice error messages (in latest release).
* It is fast.
* Dart is pretty nice once you get used to it.
* Provider api for state management works great (basically, react context).
I also do a lot of react web dev, but given that Flutter targets web (and desktop now... goodbye electron), I might try that in the future once it matures a bit.
I like Flutter as well, I've tried both react-native and Flutter for some small size side projects. I did not like Flutter at all when I've tried it just after the release but now that it had time to mature a bit, it's an excellent tool.
However I don't see why people try to push it on the web, it just renders everything in a canvas, it's a poor fit for web development.
Oh wow, I didn't notice that it went to a canvas! Thanks for pointing that out. Definite consideration for whether or not to do use that in the future.
flutter is based on skia rendering engine and recently they added support for web assembly, it's a matter of time. the thing is, think in terms of capacity and vision, react native is done, flutter will move.
it doesn't look promising with the latest beef in the community and the last release notes that I saw in this project - to be real, they're laughable in comparison with flutter 1.9 changelog.
I like flutter and enjoy the benefits you've listed.
But the Web implementation is terrible (reminds me of flash) and the desktop implementation has major lag on the single button demo, I guess it's still early, but it's probably not going to replace Electron yet...
I have seen this question before on HN and I think my previous response seems to be relevant to this and should help the OP.
This ultimately depends on your situation. I would have said Flutter since it is past 1.0 and RN is still in beta. But my main problem here is that you will quickly run into difficulty in attempting to use C/C++ libraries in Dart.
Dart has beta support for native FFI but it is not stable unlike RN. Right now, they instead have 'Platform Channels' which has a significant overhead when passing messages back and forth compared to a native FFI. The issue is still open on Github: https://github.com/flutter/flutter/issues/7053
I can reuse and port my JavaScript/TypeScript projects into mobile very quickly thanks to React Native. Flutter on the other hand, requires learning Dart which depending on your use-case makes sense if it is a new project, not so if you have invested in JavaScript.
Perhaps once Dart gains a production-level C/C++ FFI, then I can seriously look at both Dart and Flutter again.
React Native. Not because of the framework, because they both work well, but hiring a JS dev is about a billion times easier than hiring a Dart dev so if you need someone to support you later things will go much better.
I dabbled with Dart for sometime, got an impression that a competent Java/C# developer can pick up Dart in no time, I think hiring shouldn't be an issue.
There are a bunch of problems. Firstly, people simply don't apply for jobs that use languages they don't know. That makes filling a role really hard. Secondly, if someone has to learn the language when they join that puts a lag on how quickly they can be useful. You can't go as fast, which is bad if you're a startup. And lastly, companies are (usually) very reluctant to let someone spend the first few months getting up to speed if a technology choice means they can recruit people who'll immediately be effective.
That's not to say using a less popular language is a bad idea (it isn't), just that hiring should be a part of the technology decision making process.
> Firstly, people simply don't apply for jobs that use languages they don't know.
I did in my last job change - and 80% of the office here didn't know the stack/language when they first came in.
> Secondly, if someone has to learn the language when they join that puts a lag on how quickly they can be useful.
You could learn enough dart to be useful in a day if you are a C#/Java dev with JS experience - enough to go through the codebase - and thats something that takes time no matter what the language - dart isn't that exotic.
Flutter has a higher learning curve but that should also be on the order of week or two depending on how much you know about frontend. React native is the same deal.
> And lastly, companies are (usually) very reluctant to let someone spend the first few months getting up to speed if a technology choice means they can recruit people who'll immediately be effective.
Meh - when they chose stuff like Dart they know hiring pool is limited and usually word the job posting like that - ie. they expect you to be able to pick it up on the go.
I mean your whole argument is nonsense because things like this happen all the time - my current gig I started as a .NET dev with some python/django experience - I'm working on ruby on Rails stack - never touched that before in my life. Took me like 1 day of reading up to be able to go through the codebase - a few weeks and code reviews and I'm pretty much in tune with how they write RoR.
>Firstly, people simply don't apply for jobs that use languages they don't know.
That could be because experience with that language is often listed as a requirement.
>someone spend the first few months getting up to speed
In my opinion, "few months" is a huge overestimation, if we're talking about an otherwise experienced mobile developer who understands the underlying platforms (Android, iOS) well. A few weeks should be enough to get up to like 90% of their usual productivity (ballpark guess).
I agree. With good frontend development practices (state management, caching, etc) it behaves a lot like a native app, it's quick to get up and running and easy to maintain. Not to mention you can deploy as PWA/mobile web if it suits the situation.
What framework are you using? Angular or another framework? I'm interested to explore this approach using Svelte.
It’s also a compiler for web components like Svelte and a lot like React. You can add the ionic code web components to get animations etc. Try it out, especially if you like TypeScript.
Yeah, but the average user doesn't know what a PWA is and they want to install an app through the app store. Furthermore, with Cordova, you can also use plugins such as In-App-Purchases or access to more persistent storage (SQLite) instead of what the browser offers.
Cordova can access native features on phones via plugins - database, camera, sensors, etc. As well as use different designs for Android/iOS with the same code via Ionic/F7.
That said - if you're not familiar with the JS ecosystem (node_modules, etc), then it can seem a bit overwhelming at first, especially when you encounter configuration or build errors. I don't have any great answers for that except that "it gets easier" with more time and practice.
Also, if you haven't looked at React Native for a couple of years and had a bad experience before - try it again! It's come a really long way in just a few years.
For example: I used to have to worry about cross platform code/libraries working on iOS and not Android - but almost never run into that anymore.
With SwiftUI and Jetpack Compose on the horizon for iOS and Android developers, respectively, you should really invest time into learning those frameworks.
A whole lot of those problems are C++ related and a consequence of starting this very early and possibly going too far. A lot of companies have had good success with code sharing.
I love react for web development, but... idk. If you're interested in material design and don't mind that your app will look like a google app, I would seriously consider flutter.
I think if you are starting mobile app development, learn the basics of the 2 main native stacks (iOS, Android). Preferably learn one of them well. A couple of years ago I might have suggested web (PWA's) as a third kind of 'native' app, but that route seems to have lost traction.
In my experience, you'll be a better x-platform developer if you know at least the basics of the native platforms you're targeting.
This is not to say that native is the best choice for all apps. You may find that flutter or React Native suit a particular project best. You may ultimately prefer to specialise in one of those. But that's a separate issue from what you should do starting out.
Well it's only an impression I have. I'm not seeing much use of PWAs in the wild, and there seem to be fewer articles touting them, but that's just my sample. If what you say is true, I'd be pleased.
The Microsoft example seems a bit desperate - they bombed in mobile so of course they're seeking cross-platform refuge.
But are PWAs being used that much for real? Beyond just installable web sites (ie. full offline support with service workers, etc?). I seem to remember Twitter did a nice job with Twitter Lite, but I've never seen anyone use it. Again from memory I think Skype did a quite impressive PWA. I'm a big fan of Checkvist, & they have a PWA which is moving slowly but in a good direction.
Anyway, that aside, for a dev wanting to get into the mobile space (which I think was the OP's intent), PWAs would hardly be the best first option for a tech to learn. Surely whatever your personal tastes, you wouldn't disagree?
Yes, many digital web agencies are going through that route for mobile web sites, instead of having to deal with native toolchains.
Do you also consider Google and Apple's move desperate then?
While Microsoft has definitively bombed on phones, they are doing pretty alright on convertible laptops/hybrid tablets.
As for best option, I also mentioned a couple of other ones, which I advocate as alternative to PWAs.
I see Flutter has a future as bright as CoffeeScript, if it keeps being tied to Dart.
As for React Native, it depends on how much one feels like having to deal with JavaScript and the interoperability issue that often happen across Android devices.
It was your invocation of Microsoft's move I considered desperate.
You're still studiously avoid mentioning any actual PWAs. I'm someone who wishes PWAs would take over, as I dislike all the OSs and don't want my usage habits or data to be tied to them. But as of now it's not happening, is it?
If a person was trying to advise a developer new to mobile apps, with their interests rather than the advisor's tastes in mind, I cannot believe they'd advise PWAs as a primary focus.
Learning a platform isn't a forever-decision. A new mobile app developer can always learn new tech as needed. But if they want a start now, they're better off learning what's dominating today.
Because the ones I am fully aware as PWAs, are the projects I worked on for internal enterprise customers, not something that joe and jane get on their devices.
EDIT: besides the examples posted by lucasverra, you have KaiOS with its relatively big Asian market share, Google Go-Apps variants of their apps are mostly PWAs.
I know there are some decent individual examples (indeed I mentioned some myself). I'm just unconvinced that the once-anticipated shift from native apps to PWAs is happening. They are expanding into some niches, but mobile app development is still overwhelmingly native. Certainly for my local job market, only an ideologue, uninterested in the repercussions of their advice, would suggest to a mobile app newbie that they learn PWA tech first - iOS & Android developers will walk into a job anywhere, whereas they'd be hawking for a while to find work building PWAs (though web tech more generally is hot as always of course).
That is the whole point, 90% of mobile apps are actually CRUD apps that can be easily done as mobile Web SPAs.
The PWA part is just yet another tool on mobile Web.
Also in case you missed, I suggested Qt, Xamarin and C++ with Native views.
As for job market, on my area you would be having an hard time finding 100% pure native development offers, everyone only cares for some kind of solution that can be deployed across Android and iOS.
And? Is this related to my comment? [edit: I ask because I didn't construe the OP as asking for opinions on the merits of the different platforms, but rather what would be best for them to learn as a mobile app beginner. Of course everyone ignores the question and leaps on their own barrow, but that's the internet for you. I expressed no view regarding the web as a mobile platform]
if you're a corporate slave then pick react native because it's easier to find a JOB with it. If you're a dinosaur who started his career coding in Delphi then pick Xamarin. If you want to enjoy development and make some side project/startup pick Flutter. If you don't respect yourself or you are funny - C++ + native views, that's a huge ROFL.
* no (or less) native platform quirks/differences
* better programming model than Android SDK
* good performance
Reasons to use React Native:
* uses native widgets (if that matters to you)
My recommendation, write your portable app using Flutter/Dart. If that's not satisfactory, call that your Android version and write an iOS in Swift.
Do not fool yourself into thinking either Flutter or React Native will give you native app performance. It can be as fast but the pauses are in different places and users can definitely feel the difference even if they can't articulate it.
I built an app in React native a few years ago, at the time it looked more mature than flutter. However I had a lot of issues regarding keyboard placement, I still had to write platform specific code, which wasn't too bad your could use .android.js or .ios.js. Android also felt like a second class target for React native. A lot of the css features wouldn't work. It could be a lot better now, but I haven't tried since. I very much believe it would be easier pursuing a PWA or writing native code for each platform.
My pick is what's appropriate for the situation - you haven't described yours so it's not really possible to help you! Flutter is imho Generally Better but there are absolutely going to be cases where RN is going to be less fighting against the system
> The biggest issue with Flutter is that it paints it's own custom UI, and doesn't use native components. Historically, frameworks that took this approach haven't stood the test of time (see Java AWT and Swing)
Works in games, with Unity and the like. Not coincidentally, some Flutter users and even devs have been describing Flutter as "Unity for apps."
i’m currently asking myself the same question, and i used to like flutter approach. However, after having tried a flutter demo app from the store ( the one comparing vegetables), and seeing it lag on scrolling on an iphone10 , plus seeing that the keyboard placeholder doesn’t follow the keyboard animation ( so you see a white mark behind), i’m seriously reconsidering this option.
plus, i feel safer coding my business logic in typescript than dart. It’ll be more useful in case i want to code a web site (flutter web renders to a 2d canvas , which feels wrong for some reason), eventhough dart theorically compiles to js, i feel typescript is more used for that.
We picked React Native and while it's not without its problems in general we quite like it. The community around it is pretty good and being able to use a wide range of JS/React packages is really handy.
Flutter. It really helps me my daily life.
You can do many things at home without going outside.
Transactions outside can be done inside the house already.
I'm working on a new framework that attempts to take what I think are the best ideas from the web (zero installation, easy to lay things out without tracking measurements yourself) and combines them with the best ideas from React (functions as components, ideally no mutable state). I want to solve what I see as the original sin of the web: inept separation of presentation from content.
The other thing I aim to solve is the issue of the browser and corresponding web standards being a monolith so large that only Google and Apple can afford to implement them. By wrestling back control over layout, I hope to show that a next-generation browser could be much more like what James Mickens laid out with the research he presented in this talk: https://www.youtube.com/watch?v=1uflg7LDmzI
I decided to prototype it in JavaScript, and right now it just renders into a canvas element. I love working on it, because all the unit tests run really fast. It can do that because there's no browser in the way - node-canvas is much lighter weight. Once the design is settled down, I'd like to rewrite it in Rust. The other advantage of this is that it is incremental. It'll run in any existing web browser, and building a cut-down browser that isn't web-compatible is doable in a few weekends.
The best way to see its capabilities so far is to look at the test screenshots: https://github.com/maxharris9/layout/tree/master/test/screen... - see especially text-actual.png, text-concave-cutout-actual.png, text-diamond-actual.png. I fell down a rabbit-hole with that a bit and made it wrap text around arbitrary polygons, hyphenating on syllable breaks and everything.
I just lost my job a couple of weeks ago, and I've been taking time off to work more on this thing. Tomorrow I hope to get mouse click events tracked through the component tree. And at some point in a week or two, when that's done, I really should write the application that I had in mind for it!
I know a lot of people have concerns about accessibility with the approach I've taken, and all I can say to that is, please help me work on that instead of criticizing me. I know there is talk about an accessibility DOM coming in browsers, but I fear that I'll just have to fall back to rendering plain HTML in order to drive screen readers, which is a terribly inefficient and indirect way of doing things. Also I don't even know where to begin with screen readers, what's the most popular software for that, etc.
Yeah I heard you, but it's terrible as a decision, and honestly your opinion shouldn't be allowed on HN without huge caveats that you clearly have no relevant experience in mobile development.
The only ones allowed to evaluate how relevant my mobile experience is are my employers and the customers I work for, which contrary to HN, actually have to give me money for what I deliver.
Some one is developing this kind of cool example of the web target: https://github.com/rxlabz/panache