13 ms·

Flutter is better than React Native in all the ways that don’t matter

136 points by tut-urut-utut 5y ago

intrasight 5y ago
Hiring is certainly very important. But I disagree that JavaScript developer availability is the most important criteria in this decision. After all, we're talking about "quality developers" not script kiddies. Experienced developers will hit the beach running with Dart. It's just another C-style language like many others that experienced developers will have used extensively.
- lpapez 5y ago
  Calling Dart "C-style language" sounds very weird. The curly-brace syntax is the only parallel I can draw between the two... What other similarities do you see?
  - meetups323 5y ago
    Clearly the parallel is that types come before identifiers in declaration contents.
  - a4isms 5y ago
    Dart is absolutely a C-style language.* ——— * In all the ways that don't matter.
    - jamonholmgren 5y ago
      I suppose this is going to become part of the HN lexicon now...
      - a4isms 5y ago
        In a rant that was (at one time) legendary, the late Erik Naggum responded to the argument that XML was nothing more than another way to write s-exprs, and if you like s-exprs, the only quibble you have with XML is the syntax. Erik wrote, They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. He went on to write a great deal more that I am not willing to quote, but at its core was this same argument: Sometimes two things seem very similar, but the ways in which they are similar are unimportant, and the ways in which they differ are profound. My guess is that little aphorisms like this will come into and out of fashion over and over again, because this argument is one we will have over and over again. https://www.schnada.de/grapt/eriknaggum-xmlrant.html https://www.schnada.de/grapt/eriknaggum-xmlrant.html
- Fauntleroy 5y ago
  Yet another entry in the completely unnecessary and banal annals of "dumping on js developers for no good reason".
  - philtar 5y ago
- evan_ 5y ago
  Did you just fall through a time portal from 2008? JavaScript hasn't been the exclusive domain of "script kiddies" for a loooong time.
  - a4isms 5y ago
    What's very interesting about your comment is this: Let's say that JavaScrip was a language for "kiddies" in 2008. Let's call them people in the age group 17-22. That was fourteen years ago, and those "kiddies" are now 31-36. In 2008, they were in entry-level positions. Today, they have over a decade of industry experience and are lead engineers, engineering managers, &c. It's not like they "grew up and switched to adult languages." They brought JavaScript with them, and as they recognized its shortcomings... They fixed the language and its ecosystem. (For some debatable definition of "fixed," but the general point is that even if it was a language for script kiddies a decade and a half ago, those kiddies grew up and to a certain extent, the language grew up with them.)
    - deleted 5y ago
      [deleted]
    - evan_ 5y ago
      I kinda got the year wrong, 1998 would've been a better thing to say. I was working on multiple shipping products using JavaScript in 2008.
      - deleted 5y ago
        [deleted]
      - a4isms 5y ago
        Exactly, add another decade and we're talking about the original Script Kiddies being seasoned executives, or possibly even having cashed out a startup or two and are now investing in startups via the Founder-to-VC pipeline.
wiradikusuma 5y ago
I think Flutter is better _because_ it uses Dart. I used to hate that decision ("Not another language to learn.."), but Flutter and Dart are like Mac and macOS (I'm aware people complaining about macOS quality going down the hill.. but that's another story). They're both from the same company, seemingly built for each other, and the language (Dart) improvements are _relevant_ for the platform (Flutter). Flutter still has its quirks, but hands down, it's the best platform for the majority of "standard" apps. Great developer experience, acceptable performance and size. Also, about hiring.. from my experience, it's one of my selling points in recruiting mobile developers. Many mobile developers want to learn Flutter, so I easily get dozens of candidates who know Flutter only from their hobby projects but want to get involved in real projects. But, of course, you still need some senior Flutter guy. My only complaint is since the platform is expanding, things break too easily. You _can_ lock dependencies, but you'll feel guilty.
- edwnj 5y ago
  I went through the exact same experience. Choosing dart felt like silly to me but after a using flutter for years now it makes 100% sense. The way both flutter and dart adapts for each others needs is super cool.
- amelius 5y ago
  As someone who started programming using GCC, Vi and commandline tools, I just hate the tooling around Flutter. And yes, someone will probably point out that I can use Flutter with commandline tools after I disable all the bloatware that needs to be installed anyway, but that's missing the point.
  - brabel 5y ago
    > but that's missing the point. How is pointing out that you don't need the tools you hate and you can use the same kind of tools in the CLI as you would with any other framework missing the point?
  - tlamponi 5y ago
    You only need dart and flutter itself, and both of those can used via CLI just fine, I know because when I develop flutter I exclusively use my classic tmux+vim setup to do so. If I want to create an android build I naturally also need the android SDK, but that is even packaged for Debian or Arch Linux, and even if I use the newest one directly from Google its just a one time setup, and that is completely unrelated to flutter (which I can test via the native or web build too) but 100% related with the build target (android in this case), so really not seeing your point.
meerita 5y ago
In 2019, I joined a project with other 2 partners to develop an app for audiobooks. The CTO said the app should be done using Flutter and he sold it like it was paradise on earth. I disagreed but couldn't push that much to try to convince the rest of the guys about this detail. On month 8 on the project, the CTO resigns and leave, leaving us 8 months ahead of no major development because it was impossible to find Flutter people and, most importantly, people who were proficient on that platform. In the end we relied on an agency, paying a huge price to do upgrades. Nowadays I am doing a RN project and the speed, results still put that over any option I could do. I would only pick Flutter once it reaches a degree of maturity in all terms like RN.
- vsareto 5y ago
  > because it was impossible to find Flutter people and, most importantly, people who were proficient on that platform If you can't find them, you gotta train them
  - meerita 5y ago
    We did that with one guy after month 3, the guy accepted and started Flutter course, etc. He quit the job on month 5 arguing he disliked Flutter and Dart.
    - penjelly 5y ago
      sample size of 1. It may not have been for that individual but that doesnt mean hiring and training on the job is incorrect
      - meerita 5y ago
        Correct, but the reality was we couldn't afford a larger sample to see if Flutter is superior or not to other options.
    - questiondev 5y ago
      i’ve trained on flutter for over 8 months and pushed an from design to app on the app store and built the api in dart as well. i am one of those weirdos who likes it but nobody is hiring so i am rebrushing back up on javascript and react native. one area i would love to see is json being automatically accessible just like in javascript, also their routing in flutter needs work. it’s not for everyone but it has a ton of potential if some things get change
mwattsun 5y ago
I've programmed a lot in both Dart and C# and my take is that Microsoft looked at Java and decided they needed a Java-like language like so they made C#. Google was into Java but Oracle sued them over it so they decided they needed a Java-like language so made Dart. Edit: Dart is ridiculously easy to learn because it's very familiar so if someone complains about having to learn Dart it means they don't want to learn it
- mjburgess 5y ago
  If that's the strategy behind dart, it would be the de-facto android language and they'd have a JVM target. It's hard to place dart in a modern languages context, it really only made sense as a "next javascript" bet in 2011 -- pre-ES6. It feels legacy now, maybe flutter will be a rivial -- seems unlikely though.
  - deleted 5y ago
    [deleted]
- impjohn 5y ago
  I've messed around with a few simple Flutter applications and I wrote in Java until the IDE complained then made minor fixes. I never had the feeling I was learning a new language honestly, felt more like moving from python 2 to python 3 than a whole different language
- zerkten 5y ago
  Microsoft's story isn't that different from the Google one. Microsoft had a Java language (https://en.wikipedia.org/wiki/Visual_J%2B%2B https://en.wikipedia.org/wiki/Visual_J%2B%2B). Arguably, they had a better language designer in Anders Hjelsberg, as well as a lot of component-based development experience from COM, that enabled them to build a platform that was in many ways better. Things like WebForms were relatively stunted as model for web development and would be replaced by MVC aligning to what the world was mostly doing all along.
- klodolph 5y ago
  I don't have inside information here. My reading of the narrative is that Dart was created originally as an alternative to JavaScript, because JavaScript did (and does) have just tons of problems all around. It pivoted from being primarily a JavaScript alternative to supporting use-cases like Flutter.
sankalp_sans 5y ago
Add to it the ecosystem of libraries which are virtually non existent for Flutter. Even Google (pioneer of Flutter) doesn’t have all their standard SDKs ported for Flutter. We played around with Flutter for a total one day before ditching the idea altogether (in favour of native Android with Kotlin)
- jamonholmgren 5y ago
  Someone pointed this out to me on Twitter this morning and it's an aspect I didn't even think about. Most third-party SDKs have a JS version which generally (not always) works with React Native. Can't really say the same for Dart, so you're almost always doing a native integration or building it yourself.
- repox 5y ago
  > We played around with Flutter for a total one day before ditching the idea altogether (in favour of native Android with Kotlin) I've made several apps in Flutter and so far I'm actually happy with it. I look forward to the next project. I can easily understand why it's not for everyone, as it's true that not all standard SDK's has been ported. And of course, not all projects are suited for hybrid solutions in any case.
devadvance 5y ago
My primary hesitation with posts like this is that it mixes engineering points (performance, developer experience, code sharing) with a more general business point: hiring. Hiring is a cost. There are costs to any decision. Opportunity cost, risk, business continuity, operational costs, etc. Hiring is generalizable so it makes for an easy example here. I would hope that experienced folks making decisions like "React Native or Flutter" would weigh the full gamut of costs in their specific business context.
- clintonb 5y ago
  Your first and last paragraphs seem contradictory. You Hope experienced folks weigh all costs, but a post mentioning the cost of hiring gives you hesitancy?
  - devadvance 5y ago
    The fact that the post mentions hiring (cost) isn't my hesitation. It's that bringing cost into a conversation about the technical merits of a given technology can be a heavy-handed way of shutting down the conversation. In some cases, technical merits very much do justify the cost, but that can only happen by creating the space to find out. Said differently: I believe it's often worthwhile to discuss the deeper technical merits of options without hastily jumping to a cost discussion.
rayiner 5y ago
Worse is better in a nutshell.
- a4isms 5y ago
  https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/WorseIsBetter.html
davidkuennen 5y ago
Using Flutter for my app was one of the best decisions I've ever made.
999900000999 5y ago
Flutter is far more enjoyable for me, but in terms of actually publishing a production ready app, React Native all the way. At work you have deadlines, you don't have time to re-implement solutions that have been solved with React Native for years. Still, for my hobbyist projects, I absolutely love Flutter
onion2k 5y ago
This article highlights one of the things that really bugs me about tech hiring. The availability of developers who know a language or tech isn't a limiting factor if you're willing to hire people and give them the time to learn. Yes, it's expensive, but if there really are productivity benefits from using a particular tool then you should end up better off in the long term anyway. The expectation that another company will train your workforce, or that they'll train themselves in their spare time before joining, massively inhibits the proliferation of different, new, and interesting technologies and keeps 90% of the devs in the web and mobile world on the same 3 platforms (JS/TS, Swift, and Kotlin). Unless companies start hiring to mentor people this will not change, and probably TS will just eat all the others in the long run.
- vbezhenar 5y ago
  You will spend year teaching someone then he leaves for another company who gave him 20% rase. You're net negative, they're net positive. You'll lose the race in the end. This could be a good approach for someone huge like Google or government. Asking that from an ordinary company will not work.
  - rootusrootus 5y ago
    If it takes a year for someone to pick up a new framework and be productive, I didn't want them anyway.
  - carlio 5y ago
    Isn't the corollary that there are other companies who train up people who you can hire for a 20% raise from them? Or even just give your existing staff a pay rise once they reach a more senior level? If you can't afford to do that, then that's saying you can't afford to hire people who know a lot about the technology you're using, and then that's a whole different issue.
  - BaseballPhysics 5y ago
    > You will spend year teaching someone then he leaves for another company who gave him 20% rase. This only makes sense if you hired the person at 20% below their market rate under the belief that they were less valuable as a hire simply because they didn't have a specific skillset you needed, and then once they acquired that skillset you failed to adjust their salary accordingly. But the entire thesis of the OPs comment is that we shouldn't be valuing staff based on any one specific technical skillset, but rather based on their broader software development skills and experience, because learning the ins and outs of any specific software stack is not itself that difficult given enough experience. Solution: hire and retain at a competitive market rate. Problem solved.
vyrotek 5y ago
I really enjoy the dev experience of Flutter. The tooling is great and Dart was easy to pick up with my experience with C#. The various batteries-included features are appreciated as well. Unfortunately, the lack of "Code Push" killed several attempts of using Flutter on various projects for us. ReactNative has been good to us but I really wish there was a bit more built-in for commonly needed features.
rvz 5y ago
Perhaps If you are building a app optimizing for high performance where it is needed (using 3D, trading apps, etc) sure. But in 'all' cases? You would benefit better with the large ecosystem of officially 'supported' TypeScript libraries available in React Native which most companies simply would just use over unofficial ones or the very high likelihood of no equivalent libraries to use on the Flutter side, even if you are migrating a complex app. Flutter is getting there but as for the library ecosystem, it's not there yet for now; especially for Desktop. If it does get there, at least we should be able to see the first of Flutter desktop apps like Rows [0] to replace Electron on the desktop, unless somehow React Native for Desktop gets there which that is even far behind. [0] https://rows.com/ https://rows.com/
stragio 5y ago
Once in a while the Flutter/RN discussion shows up on Hackernews and I'd like to remind you all that Capacitor community is also alive and kicking. For the past months I've been building an E-commerce with Capacitor/NextJS and its been quite a pleasant experience. If you're familiar with JS/TS and React, it's a great option for an e-commerce or a b2b SAAS app. If you don't need many native components or a super slick performance, Capacitor might be the cheapest and quickest solution for web developers.
- flinkit-lars 5y ago
  We are building our native app off from our web app, using Capacitor. One single codebase, 3 platforms targeted. Using very well established technologies that have a very good DX.
  - stragio 5y ago
    Great to hear you're having a similar experience. It became extremely easy for web devs to release mobile apps now.
    - flinkit-lars 5y ago
      I did native app development on-off from about 2010-2018, with at larger apps. Today I see little reason to have 3 code bases with the same features. You got 3x the same problems. Ok, there's Flutter and React Native, but their web code transpilation isn't great. Web Views (both in browsers and in apps) are just a super major technology with excellent developer tooling such as live reloading. Capacitor would always be my first choice today.
GranPC 5y ago
I'm surprised Flutter's performance compares favorably to React Native here. Last time I tried Flutter (around 1 year ago) even the simplest of scrolling demos noticeably stuttered dropped frames on my phone. React Native apps work fine. Was that just my experience?
- akmarinov 5y ago
  Were you testing on an iPhone? They had a big issue on iPhones that they fixed a couple of months back. Flutter is a very Android first framework, for obvious reasons.
  - GranPC 5y ago
    Nope, mid-to-high range Android phone from mid-2017. Haven't tried Flutter on iOS at all.
    - ishaanbahal 5y ago
      I started writing flutter apps in their RC1, and since then up till last year (since then I haven't written flutter), flutter had scrolling frame drops on both iOS and Android (high and low end). It was unrelated to device, and happened always when using the listview builder. It may have been fixed now, but it was an issue for a long while. And it also plagued web (hummingbird then).
jrsj 5y ago
I’ve never worked with anything that made me want to quit software entirely more than React Native, and didn’t feel that way at all about Flutter. Maybe it’s just me but I feel like the developer experience of Flutter is much more consistent.
- JoeyJoJoJr 5y ago
  I worked on a React Native reject in 2019, and decided to exit mobile dev and focus just on web. My frustration at the time was the bonkers reliance on two package managers (npm and cocoa pods) and having many, many problems that had to be resolved in some quirky way in XCode or Android studio. I didn’t like how much native code had to be copied and pasted around to integrate SDKs. At that stage you may as well bite the bullet and just learn native.
  - jrsj 5y ago
    I had a very similar experience. It seems like they’ve just stacked too many different complex pieces of software on top of each other & the result is sometimes unpredictable and difficult to debug behavior that can pop up in any layer of that stack.
samwillis 5y ago
I want to throw Ionic and Capacitor (or any other webview based toolkit with your favourite SPA framework) into this mix, I believe for a lot of apps its probably a better option than either Flutter or React Native. I also don't and believe in "one true cross platform toolkit", each has its place. So: Hiring - The OP suggests React Native has a larger pool of developers than Flutter, very true. But Ionic/Capacitor/etc you have access to an even larger pool of developers, any proficient font end web developer. Sharing Code, Knowledge, and Developers - Again I believe Ionic/Capacitor/etc are even better than React Native here, you can potentially reuse even more of your code/views/logic. In fact your SPA web app version is your mobile app, except you then have access to native apis with Capacitor. Developer Experience - Dev experience with Ionic/Capacitor/etc is as good a React Native at this point. It has all the hot reload features we now expect from any SPA framework. You can even now you Vite for super speedy development. Performance - A webview based app on hardware less than five years old is on par with any React native app. The performance of web views is not the issue, it's the underling app code, modern SPA frameworks and good engineering is all you need. Unified UI Experience - Firstly customers don't really care about a unified UI, they have been trained after 20 years of using web apps not to care. If it works it works. Having said that Ionic have done an incredible job of replicating the Material/iOS components. Native Integrations - Capacitor has all your usual apis covered, if you need more it's as simple as with React Native to drop down to native with Swift or Kotlin. I'm a fan of using NativeScript with Capacitor, it gives you access to all native apis straight from your JS codebase. Internationalization - Standard SPA internationalization support, easy. Built-In Navigation - Use whatever your SPA framework uses. Web Support - Capacitor is the clear winner here as you have built a SPA. Third-Party Libraries - You can use any web/javascript toolkit, along with any platform specific libraries for iOS or Android that you need. Obviously its not the right platform for all use cases, but if you are just starting out small with a tiny team you only have to build your app once. 90% of your app is probably the front end, your don't want to be build that twice until you have the traction and teams to do it.
- angst_ridden 5y ago
  I've developed some apps in Ionic/Cordova and Ionic/Capacitor. I agree that it's a decent system, especially for people (like me) who are just in a rush to implement something and aren't so caught up in platform wars. I'm one of those people who couldn't care less about the language I use to code in - I just want to get stuff done. From my perspective, Javascript has some stupid stuff, but so does every other language. My only significant objection to Ionic/Capacitor is the whole nodejs ecosystem. I hate getting dropped into dependency hell all the time. And it's significantly worse if you're stuck (as I a) supporting an end-of-lifed Cordova plugin for necessary functionality. Now, in the real world, I'd have a team and we'd just build our own version of the plugin and get rid of the web of dependencies, but sadly I'm just one not-very-bright guy off on his own.
flax 5y ago
I do React (web, typescript) for my job, and Flutter for my hobby/side-projects. I chose Flutter specifically because Dart is far superior to javascript/typescript, and the fact that I do not have to deal with the absolutely bullshit JS build ecosystem. Choosing React Native because you can find "Javascript developers" in 2022 is like choosing PHP in 2010 because it was popular. If you're hiring above entry-level, you should expect a developer to be able to pick up a new framework, non-exotic language fairly quickly. And if you are hiring entry-level, you should expect to need to teach the new hire anyway.
ramesh31 5y ago
The argument applies equally well to React vs Vue. Ultimately it doesn't really matter if you slightly prefer the ergonomics or API of one over the other. There is simply no argument whatsoever from a standpoint of community support, tooling, documentation, libraries, and hiring pool that React has a 10x advantage over Vue. If it were the other way around, I would just as happily use Vue. But it isn't, so I use React.
alexashka 5y ago
If you're smart enough to learn Flutter, you're smart enough to learn Swift/Kotlin. So, just do that. The appeal of React Native is that you get to stay in the javascript ecosystem. If you're going to move away, move away to native. It's a no brainer. The very premise of these cross platform tools is flawed, frankly - if you can't afford one dev per platform - your problem isn't tooling, it's money. So, just fix the money issue. Also, as an iOS dev - the second I see mention of Rx, Flutter, React Native or some other third party 'thing' - I don't even bother applying. Apple/Google produce enough new 'things' every year to keep everyone busy. I don't need some third party 'thing' on top of it all.
- claytongulick 5y ago
  > So, just fix the money issue. Have you ever actually had to run a startup? I'm not trying to attack you, but this comment comes across to me as incredibly disconnected. > I don't even bother applying I'm glad for you that our industry has such high demand that you have these options.
  - alexashka 5y ago
    > Have you ever actually had to run a startup? Yes. > I'm not trying to attack you, but this comment comes across to me as incredibly disconnected. No worries. You know what they say about opinions.
ajdegol 5y ago
Maybe things have changed since I last used it, but the styling was very boilerplatey. I didn't enjoy using it. I really liked Dart, was easy to learn. Is there some sort of template-library/style-system that y'all are using? Or is it still one widget in another widget in another widget..? Because if that latter then optimising for some syntactic sugar over that would be very much a game changer.
jbaudanza 5y ago
I've been using react native heavily for the past 18 months. Because there's no JIT, Javascript is slow on mobile, especially on Android. I spend a lot of my creative energy trying to optimize the render function. I often times wonder if I should have chosen Flutter instead. Each framework has its bullshit you don't discover until it's too late. So, I'm sure if I had chosen Flutter I'd be complaining about something else.. but boy am I tired of stuffing things into useMemo, useCallback, and stressing about the identity of things in dependency arrays. There's some exciting stuff coming up this year with React/React Native: Hermes, React Native "New architecture", react concurrency mode (although I still don't 100% understand what this is). I hope one of these things improves the current situation.
- jdmg94 5y ago
  Memoizing everything might be hurting more than helping your apps performance. I’ve built a few different apps with RN, the issues here might be specific to this project
  - danlugo92 5y ago
    No I've had apps where I memoized everything, then turned it all of for a testrun and it was very visibly slower without memoizing.
  - jbaudanza 5y ago
    I know this is theoretically true, but I've never found this to be the case in practice. Coinbase, in fact, has made it a rule that all things must be put in useMemo. https://attardi.org/why-we-memo-all-the-things/ https://attardi.org/why-we-memo-all-the-things/ Facebook is working on an experimental compiler called React Forget that will transparently memoize everything for you. https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forget_compiler_automated_memoization_react/ https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forge...
- cvburgess 5y ago
  My team wrapped an ambitious RN project over the last 6 months and had no such issues. We actually migrated from "vanilla" RN to the latest Expo release as EAS allows you to use native code and do nearly anything you could do with vanilla. Every codebase is unique, but I would (and have) recommended this stack to multiple teams as it served us really well. We onboarded 3 React devs - 2 of which had never used RN before and all 3 were pushing out features within a two week sprint. We also got to scan a QR code from a GitHub PR and allowed other engineers, QA folk, and designers to test PRs before merging on a real physical device - I am not sure if Flutter has something similar, but the tooling around RN is amazing. Also, LogRocket, Sentry, LaunchDarkly, Auth0 and most of the SaaS tools youre familiar with in React have solid ReactNative support - often times including web if you use RNW.
aaronmu 5y ago
It's a lot easier to catch a fish in a small pond if you're the only one fishing. Was a lot easier to hire a competent F# developer than it was to hire a competent C# developer. No one ever got fired for buying IBM. Technology that is unknown to the buyer is significantly harder to sell. You will lose sales because of your exotic technology choice. If you told me this 4 years ago, I'd have argued that the implementation details don't matter but it turns out that they do.
asiachick 5y ago
I wish Flutter would die in a fire! The web version renders everything in a canvas. This sucks! It means, no reading of text because no DOM to read for a11y, no standard context menus (so no OS/browser level spell checking, word lookup, copy and paste, password generation), poor slow 2nd class support for non-roman languages (it has to do it's own font rendering so it asynchronously downloads/rasterizes non-ASCII code points which means new characters show up as placeholders and only appear 500-1000ms later. I'm sure I could go on and on about how bad that decision is.
sandGorgon 5y ago
so this article is fairly nice - and I'm glad you touch on the "hiring" part. Funnily, the opposite is true in India - which is basically the world's largest android (and android dev) market. React Native devs are hard to come by. React is very very very popular. But not react native. Especially in colleges. I have done the A/B tests here. Flutter is really viral. Just FYI - ultimately the talent is going to come flying off the boat from somewhere right !
geodel 5y ago
I think it is all fine. People who seek personal and/or professional growth would learn new tech stacks and apply interesting ways. A lot of people who would rather stay on current stack and take technology as something that just pay bills is also good choice. It is only the incessant talk that try to prove past/present choice of technology as "objectively better" seems unnecessary to me. This also reminds when Sun certified Java developer was the way to hire Java developers. With so many people got this certificate, it became so bad that it was more likely that Sun certified developer would be worse as they put all effort in getting certificate and not really learning programing.
tonis2 5y ago
What I like about Flutter, is that I can develope cross platform without Javascript, even though Dart has dome weird stuff its still better that typescript and javascript, but thats just my opinion.
travisgriggs 5y ago
I've played with Flutter a little. It was OK. I develop/maintain 2x2 native apps (two different apps, with 2 different native versions each). When I started this years ago, the cross platform stories weren't as prevalent, and we needed really strong BLE integration (not just a casual shim library). So we did the native thing. Reading various forums, it almost feels like no one does the iOS/Android native app dance anymore. Is that a vocal minority or is that what's really going on? Or are there still reasons to do native (Kotlin/Swift) apps?
- deutschew 5y ago
  For me, Flutter & Dart were badly needed solutions to the traditional way of developing Android apps. There's really no need to do the "native app dance" anymore, it's costly unless you really want to target a specific Android device. Having said this the article does bring up an important issue, in particular, it's tougher to find Dart developers and you would most likely need to spend 6~8 months for a new team to get into the groove...BUT React Native is a giant mess. It's clunky and slow and throwing Javascript/Typescript at everything has been problematic and it's clear that the performance lags behind Flutter by a large factor. If I had to choose, I would take on the tool that offers the best development experience and a large chunk of that comes from the debugging, and it just so happens Google hit the nail——NullPointerException is one of THE biggest risks of using other toolsets. So If I had to bet here, I would put it on Flutter/Dart. It is essentially a love child of ES6/Java/Typescript and it just hits so many pain points coming from React Native. I really do think React will become the Java Swing of our generation, yes you've done everything right but it seems you need to keep up with new trends and the usage of hooks is really annoying and unintuitive. In fact, here on the web front, I think Backend-as-Frontend where we persist application state in websocket will be a game changer. On the mobile front, Flutter clearly scratches the itch for both newcomers, react native developers but also backend-as-frontend really gets rid of the need to maintain two separate code bases (one for react and the other for backend). I think a web app that loads via Backend-as-Frontend framework that Flutter talks to like a regular joe REST API will be the paradigm shift. I would love to hear what others think of my views as I'm curious as to how my bets will pay off.
- quesera 5y ago
ecshafer 5y ago
I have a couple issues with this article. The first is the claim that Flutter is one of the most popular native apps. I haven't seen or heard of anyone actually using it. Flutter and Dart barely exist. After React native, the next biggest would probably be just plane old native, or electron. The second is their claim that google has a great developer experience. I legitimately have never had any google product with a good developer experience. They always have a painful developer experience compared to Facebook products.
AbrahamParangi 5y ago
As a general rule, I’ve found if you have to choose between a Google maintained project and a Facebook one- pick the Facebook one.
agent3bood 5y ago
A comment on hiring and training. I have work with React, web, RN, and Flutter and I can say the biggest training part is always on the platform/framework part not on the language. So would it be easier to train kotlin/swift developer to learn new mobile framework; or train js/React developer to learn a new platform?
kimown 5y ago
The big mistake of flutter is Dart, I am not optimistic about Dart.

136 points by tut-urut-utut 5y ago

Hiring is certainly very important. But I disagree that JavaScript developer availability is the most important criteria in this decision. After all, we're talking about "quality developers" not script kiddies. Experienced developers will hit the beach running with Dart. It's just another C-style language like many others that experienced developers will have used extensively.

lpapez 5y ago
Calling Dart "C-style language" sounds very weird. The curly-brace syntax is the only parallel I can draw between the two... What other similarities do you see?
- meetups323 5y ago
  Clearly the parallel is that types come before identifiers in declaration contents.
- a4isms 5y ago
  Dart is absolutely a C-style language.* ——— * In all the ways that don't matter.
  - jamonholmgren 5y ago
    I suppose this is going to become part of the HN lexicon now...
    - a4isms 5y ago
      In a rant that was (at one time) legendary, the late Erik Naggum responded to the argument that XML was nothing more than another way to write s-exprs, and if you like s-exprs, the only quibble you have with XML is the syntax. Erik wrote, They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. He went on to write a great deal more that I am not willing to quote, but at its core was this same argument: Sometimes two things seem very similar, but the ways in which they are similar are unimportant, and the ways in which they differ are profound. My guess is that little aphorisms like this will come into and out of fashion over and over again, because this argument is one we will have over and over again. https://www.schnada.de/grapt/eriknaggum-xmlrant.html https://www.schnada.de/grapt/eriknaggum-xmlrant.html
Fauntleroy 5y ago
Yet another entry in the completely unnecessary and banal annals of "dumping on js developers for no good reason".
- philtar 5y ago
evan_ 5y ago
Did you just fall through a time portal from 2008? JavaScript hasn't been the exclusive domain of "script kiddies" for a loooong time.
- a4isms 5y ago
  What's very interesting about your comment is this: Let's say that JavaScrip was a language for "kiddies" in 2008. Let's call them people in the age group 17-22. That was fourteen years ago, and those "kiddies" are now 31-36. In 2008, they were in entry-level positions. Today, they have over a decade of industry experience and are lead engineers, engineering managers, &c. It's not like they "grew up and switched to adult languages." They brought JavaScript with them, and as they recognized its shortcomings... They fixed the language and its ecosystem. (For some debatable definition of "fixed," but the general point is that even if it was a language for script kiddies a decade and a half ago, those kiddies grew up and to a certain extent, the language grew up with them.)
  - deleted 5y ago
    [deleted]
  - evan_ 5y ago
    I kinda got the year wrong, 1998 would've been a better thing to say. I was working on multiple shipping products using JavaScript in 2008.
    - deleted 5y ago
      [deleted]
    - a4isms 5y ago
      Exactly, add another decade and we're talking about the original Script Kiddies being seasoned executives, or possibly even having cashed out a startup or two and are now investing in startups via the Founder-to-VC pipeline.

wiradikusuma 5y ago

I think Flutter is better _because_ it uses Dart. I used to hate that decision ("Not another language to learn.."), but Flutter and Dart are like Mac and macOS (I'm aware people complaining about macOS quality going down the hill.. but that's another story). They're both from the same company, seemingly built for each other, and the language (Dart) improvements are _relevant_ for the platform (Flutter). Flutter still has its quirks, but hands down, it's the best platform for the majority of "standard" apps. Great developer experience, acceptable performance and size. Also, about hiring.. from my experience, it's one of my selling points in recruiting mobile developers. Many mobile developers want to learn Flutter, so I easily get dozens of candidates who know Flutter only from their hobby projects but want to get involved in real projects. But, of course, you still need some senior Flutter guy. My only complaint is since the platform is expanding, things break too easily. You _can_ lock dependencies, but you'll feel guilty.

edwnj 5y ago
I went through the exact same experience. Choosing dart felt like silly to me but after a using flutter for years now it makes 100% sense. The way both flutter and dart adapts for each others needs is super cool.
amelius 5y ago
As someone who started programming using GCC, Vi and commandline tools, I just hate the tooling around Flutter. And yes, someone will probably point out that I can use Flutter with commandline tools after I disable all the bloatware that needs to be installed anyway, but that's missing the point.
- brabel 5y ago
  > but that's missing the point. How is pointing out that you don't need the tools you hate and you can use the same kind of tools in the CLI as you would with any other framework missing the point?
- tlamponi 5y ago
  You only need dart and flutter itself, and both of those can used via CLI just fine, I know because when I develop flutter I exclusively use my classic tmux+vim setup to do so. If I want to create an android build I naturally also need the android SDK, but that is even packaged for Debian or Arch Linux, and even if I use the newest one directly from Google its just a one time setup, and that is completely unrelated to flutter (which I can test via the native or web build too) but 100% related with the build target (android in this case), so really not seeing your point.

meerita 5y ago

In 2019, I joined a project with other 2 partners to develop an app for audiobooks. The CTO said the app should be done using Flutter and he sold it like it was paradise on earth. I disagreed but couldn't push that much to try to convince the rest of the guys about this detail. On month 8 on the project, the CTO resigns and leave, leaving us 8 months ahead of no major development because it was impossible to find Flutter people and, most importantly, people who were proficient on that platform. In the end we relied on an agency, paying a huge price to do upgrades. Nowadays I am doing a RN project and the speed, results still put that over any option I could do. I would only pick Flutter once it reaches a degree of maturity in all terms like RN.

vsareto 5y ago
> because it was impossible to find Flutter people and, most importantly, people who were proficient on that platform If you can't find them, you gotta train them
- meerita 5y ago
  We did that with one guy after month 3, the guy accepted and started Flutter course, etc. He quit the job on month 5 arguing he disliked Flutter and Dart.
  - penjelly 5y ago
    sample size of 1. It may not have been for that individual but that doesnt mean hiring and training on the job is incorrect
    - meerita 5y ago
      Correct, but the reality was we couldn't afford a larger sample to see if Flutter is superior or not to other options.
  - questiondev 5y ago
    i’ve trained on flutter for over 8 months and pushed an from design to app on the app store and built the api in dart as well. i am one of those weirdos who likes it but nobody is hiring so i am rebrushing back up on javascript and react native. one area i would love to see is json being automatically accessible just like in javascript, also their routing in flutter needs work. it’s not for everyone but it has a ton of potential if some things get change

mwattsun 5y ago

I've programmed a lot in both Dart and C# and my take is that Microsoft looked at Java and decided they needed a Java-like language like so they made C#. Google was into Java but Oracle sued them over it so they decided they needed a Java-like language so made Dart. Edit: Dart is ridiculously easy to learn because it's very familiar so if someone complains about having to learn Dart it means they don't want to learn it

mjburgess 5y ago
If that's the strategy behind dart, it would be the de-facto android language and they'd have a JVM target. It's hard to place dart in a modern languages context, it really only made sense as a "next javascript" bet in 2011 -- pre-ES6. It feels legacy now, maybe flutter will be a rivial -- seems unlikely though.
- deleted 5y ago
  [deleted]
impjohn 5y ago
I've messed around with a few simple Flutter applications and I wrote in Java until the IDE complained then made minor fixes. I never had the feeling I was learning a new language honestly, felt more like moving from python 2 to python 3 than a whole different language
zerkten 5y ago
Microsoft's story isn't that different from the Google one. Microsoft had a Java language (https://en.wikipedia.org/wiki/Visual_J%2B%2B https://en.wikipedia.org/wiki/Visual_J%2B%2B). Arguably, they had a better language designer in Anders Hjelsberg, as well as a lot of component-based development experience from COM, that enabled them to build a platform that was in many ways better. Things like WebForms were relatively stunted as model for web development and would be replaced by MVC aligning to what the world was mostly doing all along.
klodolph 5y ago
I don't have inside information here. My reading of the narrative is that Dart was created originally as an alternative to JavaScript, because JavaScript did (and does) have just tons of problems all around. It pivoted from being primarily a JavaScript alternative to supporting use-cases like Flutter.

sankalp_sans 5y ago

Add to it the ecosystem of libraries which are virtually non existent for Flutter. Even Google (pioneer of Flutter) doesn’t have all their standard SDKs ported for Flutter. We played around with Flutter for a total one day before ditching the idea altogether (in favour of native Android with Kotlin)

jamonholmgren 5y ago
Someone pointed this out to me on Twitter this morning and it's an aspect I didn't even think about. Most third-party SDKs have a JS version which generally (not always) works with React Native. Can't really say the same for Dart, so you're almost always doing a native integration or building it yourself.
repox 5y ago
> We played around with Flutter for a total one day before ditching the idea altogether (in favour of native Android with Kotlin) I've made several apps in Flutter and so far I'm actually happy with it. I look forward to the next project. I can easily understand why it's not for everyone, as it's true that not all standard SDK's has been ported. And of course, not all projects are suited for hybrid solutions in any case.

devadvance 5y ago

My primary hesitation with posts like this is that it mixes engineering points (performance, developer experience, code sharing) with a more general business point: hiring. Hiring is a cost. There are costs to any decision. Opportunity cost, risk, business continuity, operational costs, etc. Hiring is generalizable so it makes for an easy example here. I would hope that experienced folks making decisions like "React Native or Flutter" would weigh the full gamut of costs in their specific business context.

clintonb 5y ago
Your first and last paragraphs seem contradictory. You Hope experienced folks weigh all costs, but a post mentioning the cost of hiring gives you hesitancy?
- devadvance 5y ago
  The fact that the post mentions hiring (cost) isn't my hesitation. It's that bringing cost into a conversation about the technical merits of a given technology can be a heavy-handed way of shutting down the conversation. In some cases, technical merits very much do justify the cost, but that can only happen by creating the space to find out. Said differently: I believe it's often worthwhile to discuss the deeper technical merits of options without hastily jumping to a cost discussion.

rayiner 5y ago

Worse is better in a nutshell.

a4isms 5y ago
https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/WorseIsBetter.html

davidkuennen 5y ago

Using Flutter for my app was one of the best decisions I've ever made.

999900000999 5y ago

Flutter is far more enjoyable for me, but in terms of actually publishing a production ready app, React Native all the way. At work you have deadlines, you don't have time to re-implement solutions that have been solved with React Native for years. Still, for my hobbyist projects, I absolutely love Flutter

onion2k 5y ago

This article highlights one of the things that really bugs me about tech hiring. The availability of developers who know a language or tech isn't a limiting factor if you're willing to hire people and give them the time to learn. Yes, it's expensive, but if there really are productivity benefits from using a particular tool then you should end up better off in the long term anyway. The expectation that another company will train your workforce, or that they'll train themselves in their spare time before joining, massively inhibits the proliferation of different, new, and interesting technologies and keeps 90% of the devs in the web and mobile world on the same 3 platforms (JS/TS, Swift, and Kotlin). Unless companies start hiring to mentor people this will not change, and probably TS will just eat all the others in the long run.

vbezhenar 5y ago
You will spend year teaching someone then he leaves for another company who gave him 20% rase. You're net negative, they're net positive. You'll lose the race in the end. This could be a good approach for someone huge like Google or government. Asking that from an ordinary company will not work.
- rootusrootus 5y ago
  If it takes a year for someone to pick up a new framework and be productive, I didn't want them anyway.
- carlio 5y ago
  Isn't the corollary that there are other companies who train up people who you can hire for a 20% raise from them? Or even just give your existing staff a pay rise once they reach a more senior level? If you can't afford to do that, then that's saying you can't afford to hire people who know a lot about the technology you're using, and then that's a whole different issue.
- BaseballPhysics 5y ago
  > You will spend year teaching someone then he leaves for another company who gave him 20% rase. This only makes sense if you hired the person at 20% below their market rate under the belief that they were less valuable as a hire simply because they didn't have a specific skillset you needed, and then once they acquired that skillset you failed to adjust their salary accordingly. But the entire thesis of the OPs comment is that we shouldn't be valuing staff based on any one specific technical skillset, but rather based on their broader software development skills and experience, because learning the ins and outs of any specific software stack is not itself that difficult given enough experience. Solution: hire and retain at a competitive market rate. Problem solved.

vyrotek 5y ago

I really enjoy the dev experience of Flutter. The tooling is great and Dart was easy to pick up with my experience with C#. The various batteries-included features are appreciated as well. Unfortunately, the lack of "Code Push" killed several attempts of using Flutter on various projects for us. ReactNative has been good to us but I really wish there was a bit more built-in for commonly needed features.

rvz 5y ago

Perhaps If you are building a app optimizing for high performance where it is needed (using 3D, trading apps, etc) sure. But in 'all' cases? You would benefit better with the large ecosystem of officially 'supported' TypeScript libraries available in React Native which most companies simply would just use over unofficial ones or the very high likelihood of no equivalent libraries to use on the Flutter side, even if you are migrating a complex app. Flutter is getting there but as for the library ecosystem, it's not there yet for now; especially for Desktop. If it does get there, at least we should be able to see the first of Flutter desktop apps like Rows [0] to replace Electron on the desktop, unless somehow React Native for Desktop gets there which that is even far behind. [0] https://rows.com/ https://rows.com/

stragio 5y ago

Once in a while the Flutter/RN discussion shows up on Hackernews and I'd like to remind you all that Capacitor community is also alive and kicking. For the past months I've been building an E-commerce with Capacitor/NextJS and its been quite a pleasant experience. If you're familiar with JS/TS and React, it's a great option for an e-commerce or a b2b SAAS app. If you don't need many native components or a super slick performance, Capacitor might be the cheapest and quickest solution for web developers.

flinkit-lars 5y ago
We are building our native app off from our web app, using Capacitor. One single codebase, 3 platforms targeted. Using very well established technologies that have a very good DX.
- stragio 5y ago
  Great to hear you're having a similar experience. It became extremely easy for web devs to release mobile apps now.
  - flinkit-lars 5y ago
    I did native app development on-off from about 2010-2018, with at larger apps. Today I see little reason to have 3 code bases with the same features. You got 3x the same problems. Ok, there's Flutter and React Native, but their web code transpilation isn't great. Web Views (both in browsers and in apps) are just a super major technology with excellent developer tooling such as live reloading. Capacitor would always be my first choice today.

GranPC 5y ago

I'm surprised Flutter's performance compares favorably to React Native here. Last time I tried Flutter (around 1 year ago) even the simplest of scrolling demos noticeably stuttered dropped frames on my phone. React Native apps work fine. Was that just my experience?

akmarinov 5y ago
Were you testing on an iPhone? They had a big issue on iPhones that they fixed a couple of months back. Flutter is a very Android first framework, for obvious reasons.
- GranPC 5y ago
  Nope, mid-to-high range Android phone from mid-2017. Haven't tried Flutter on iOS at all.
  - ishaanbahal 5y ago
    I started writing flutter apps in their RC1, and since then up till last year (since then I haven't written flutter), flutter had scrolling frame drops on both iOS and Android (high and low end). It was unrelated to device, and happened always when using the listview builder. It may have been fixed now, but it was an issue for a long while. And it also plagued web (hummingbird then).

jrsj 5y ago

I’ve never worked with anything that made me want to quit software entirely more than React Native, and didn’t feel that way at all about Flutter. Maybe it’s just me but I feel like the developer experience of Flutter is much more consistent.

JoeyJoJoJr 5y ago
I worked on a React Native reject in 2019, and decided to exit mobile dev and focus just on web. My frustration at the time was the bonkers reliance on two package managers (npm and cocoa pods) and having many, many problems that had to be resolved in some quirky way in XCode or Android studio. I didn’t like how much native code had to be copied and pasted around to integrate SDKs. At that stage you may as well bite the bullet and just learn native.
- jrsj 5y ago
  I had a very similar experience. It seems like they’ve just stacked too many different complex pieces of software on top of each other & the result is sometimes unpredictable and difficult to debug behavior that can pop up in any layer of that stack.

samwillis 5y ago

I want to throw Ionic and Capacitor (or any other webview based toolkit with your favourite SPA framework) into this mix, I believe for a lot of apps its probably a better option than either Flutter or React Native. I also don't and believe in "one true cross platform toolkit", each has its place. So: Hiring - The OP suggests React Native has a larger pool of developers than Flutter, very true. But Ionic/Capacitor/etc you have access to an even larger pool of developers, any proficient font end web developer. Sharing Code, Knowledge, and Developers - Again I believe Ionic/Capacitor/etc are even better than React Native here, you can potentially reuse even more of your code/views/logic. In fact your SPA web app version is your mobile app, except you then have access to native apis with Capacitor. Developer Experience - Dev experience with Ionic/Capacitor/etc is as good a React Native at this point. It has all the hot reload features we now expect from any SPA framework. You can even now you Vite for super speedy development. Performance - A webview based app on hardware less than five years old is on par with any React native app. The performance of web views is not the issue, it's the underling app code, modern SPA frameworks and good engineering is all you need. Unified UI Experience - Firstly customers don't really care about a unified UI, they have been trained after 20 years of using web apps not to care. If it works it works. Having said that Ionic have done an incredible job of replicating the Material/iOS components. Native Integrations - Capacitor has all your usual apis covered, if you need more it's as simple as with React Native to drop down to native with Swift or Kotlin. I'm a fan of using NativeScript with Capacitor, it gives you access to all native apis straight from your JS codebase. Internationalization - Standard SPA internationalization support, easy. Built-In Navigation - Use whatever your SPA framework uses. Web Support - Capacitor is the clear winner here as you have built a SPA. Third-Party Libraries - You can use any web/javascript toolkit, along with any platform specific libraries for iOS or Android that you need. Obviously its not the right platform for all use cases, but if you are just starting out small with a tiny team you only have to build your app once. 90% of your app is probably the front end, your don't want to be build that twice until you have the traction and teams to do it.

angst_ridden 5y ago
I've developed some apps in Ionic/Cordova and Ionic/Capacitor. I agree that it's a decent system, especially for people (like me) who are just in a rush to implement something and aren't so caught up in platform wars. I'm one of those people who couldn't care less about the language I use to code in - I just want to get stuff done. From my perspective, Javascript has some stupid stuff, but so does every other language. My only significant objection to Ionic/Capacitor is the whole nodejs ecosystem. I hate getting dropped into dependency hell all the time. And it's significantly worse if you're stuck (as I a) supporting an end-of-lifed Cordova plugin for necessary functionality. Now, in the real world, I'd have a team and we'd just build our own version of the plugin and get rid of the web of dependencies, but sadly I'm just one not-very-bright guy off on his own.

flax 5y ago

I do React (web, typescript) for my job, and Flutter for my hobby/side-projects. I chose Flutter specifically because Dart is far superior to javascript/typescript, and the fact that I do not have to deal with the absolutely bullshit JS build ecosystem. Choosing React Native because you can find "Javascript developers" in 2022 is like choosing PHP in 2010 because it was popular. If you're hiring above entry-level, you should expect a developer to be able to pick up a new framework, non-exotic language fairly quickly. And if you are hiring entry-level, you should expect to need to teach the new hire anyway.

ramesh31 5y ago

The argument applies equally well to React vs Vue. Ultimately it doesn't really matter if you slightly prefer the ergonomics or API of one over the other. There is simply no argument whatsoever from a standpoint of community support, tooling, documentation, libraries, and hiring pool that React has a 10x advantage over Vue. If it were the other way around, I would just as happily use Vue. But it isn't, so I use React.

alexashka 5y ago

If you're smart enough to learn Flutter, you're smart enough to learn Swift/Kotlin. So, just do that. The appeal of React Native is that you get to stay in the javascript ecosystem. If you're going to move away, move away to native. It's a no brainer. The very premise of these cross platform tools is flawed, frankly - if you can't afford one dev per platform - your problem isn't tooling, it's money. So, just fix the money issue. Also, as an iOS dev - the second I see mention of Rx, Flutter, React Native or some other third party 'thing' - I don't even bother applying. Apple/Google produce enough new 'things' every year to keep everyone busy. I don't need some third party 'thing' on top of it all.

claytongulick 5y ago
> So, just fix the money issue. Have you ever actually had to run a startup? I'm not trying to attack you, but this comment comes across to me as incredibly disconnected. > I don't even bother applying I'm glad for you that our industry has such high demand that you have these options.
- alexashka 5y ago
  > Have you ever actually had to run a startup? Yes. > I'm not trying to attack you, but this comment comes across to me as incredibly disconnected. No worries. You know what they say about opinions.

ajdegol 5y ago

Maybe things have changed since I last used it, but the styling was very boilerplatey. I didn't enjoy using it. I really liked Dart, was easy to learn. Is there some sort of template-library/style-system that y'all are using? Or is it still one widget in another widget in another widget..? Because if that latter then optimising for some syntactic sugar over that would be very much a game changer.

jbaudanza 5y ago

I've been using react native heavily for the past 18 months. Because there's no JIT, Javascript is slow on mobile, especially on Android. I spend a lot of my creative energy trying to optimize the render function. I often times wonder if I should have chosen Flutter instead. Each framework has its bullshit you don't discover until it's too late. So, I'm sure if I had chosen Flutter I'd be complaining about something else.. but boy am I tired of stuffing things into useMemo, useCallback, and stressing about the identity of things in dependency arrays. There's some exciting stuff coming up this year with React/React Native: Hermes, React Native "New architecture", react concurrency mode (although I still don't 100% understand what this is). I hope one of these things improves the current situation.

jdmg94 5y ago
Memoizing everything might be hurting more than helping your apps performance. I’ve built a few different apps with RN, the issues here might be specific to this project
- danlugo92 5y ago
  No I've had apps where I memoized everything, then turned it all of for a testrun and it was very visibly slower without memoizing.
- jbaudanza 5y ago
  I know this is theoretically true, but I've never found this to be the case in practice. Coinbase, in fact, has made it a rule that all things must be put in useMemo. https://attardi.org/why-we-memo-all-the-things/ https://attardi.org/why-we-memo-all-the-things/ Facebook is working on an experimental compiler called React Forget that will transparently memoize everything for you. https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forget_compiler_automated_memoization_react/ https://www.reddit.com/r/reactjs/comments/rcn5ks/react_forge...
cvburgess 5y ago
My team wrapped an ambitious RN project over the last 6 months and had no such issues. We actually migrated from "vanilla" RN to the latest Expo release as EAS allows you to use native code and do nearly anything you could do with vanilla. Every codebase is unique, but I would (and have) recommended this stack to multiple teams as it served us really well. We onboarded 3 React devs - 2 of which had never used RN before and all 3 were pushing out features within a two week sprint. We also got to scan a QR code from a GitHub PR and allowed other engineers, QA folk, and designers to test PRs before merging on a real physical device - I am not sure if Flutter has something similar, but the tooling around RN is amazing. Also, LogRocket, Sentry, LaunchDarkly, Auth0 and most of the SaaS tools youre familiar with in React have solid ReactNative support - often times including web if you use RNW.

aaronmu 5y ago

It's a lot easier to catch a fish in a small pond if you're the only one fishing. Was a lot easier to hire a competent F# developer than it was to hire a competent C# developer. No one ever got fired for buying IBM. Technology that is unknown to the buyer is significantly harder to sell. You will lose sales because of your exotic technology choice. If you told me this 4 years ago, I'd have argued that the implementation details don't matter but it turns out that they do.

asiachick 5y ago

I wish Flutter would die in a fire! The web version renders everything in a canvas. This sucks! It means, no reading of text because no DOM to read for a11y, no standard context menus (so no OS/browser level spell checking, word lookup, copy and paste, password generation), poor slow 2nd class support for non-roman languages (it has to do it's own font rendering so it asynchronously downloads/rasterizes non-ASCII code points which means new characters show up as placeholders and only appear 500-1000ms later. I'm sure I could go on and on about how bad that decision is.

sandGorgon 5y ago

so this article is fairly nice - and I'm glad you touch on the "hiring" part. Funnily, the opposite is true in India - which is basically the world's largest android (and android dev) market. React Native devs are hard to come by. React is very very very popular. But not react native. Especially in colleges. I have done the A/B tests here. Flutter is really viral. Just FYI - ultimately the talent is going to come flying off the boat from somewhere right !

geodel 5y ago

I think it is all fine. People who seek personal and/or professional growth would learn new tech stacks and apply interesting ways. A lot of people who would rather stay on current stack and take technology as something that just pay bills is also good choice. It is only the incessant talk that try to prove past/present choice of technology as "objectively better" seems unnecessary to me. This also reminds when Sun certified Java developer was the way to hire Java developers. With so many people got this certificate, it became so bad that it was more likely that Sun certified developer would be worse as they put all effort in getting certificate and not really learning programing.

tonis2 5y ago

What I like about Flutter, is that I can develope cross platform without Javascript, even though Dart has dome weird stuff its still better that typescript and javascript, but thats just my opinion.

travisgriggs 5y ago

I've played with Flutter a little. It was OK. I develop/maintain 2x2 native apps (two different apps, with 2 different native versions each). When I started this years ago, the cross platform stories weren't as prevalent, and we needed really strong BLE integration (not just a casual shim library). So we did the native thing. Reading various forums, it almost feels like no one does the iOS/Android native app dance anymore. Is that a vocal minority or is that what's really going on? Or are there still reasons to do native (Kotlin/Swift) apps?

deutschew 5y ago
For me, Flutter & Dart were badly needed solutions to the traditional way of developing Android apps. There's really no need to do the "native app dance" anymore, it's costly unless you really want to target a specific Android device. Having said this the article does bring up an important issue, in particular, it's tougher to find Dart developers and you would most likely need to spend 6~8 months for a new team to get into the groove...BUT React Native is a giant mess. It's clunky and slow and throwing Javascript/Typescript at everything has been problematic and it's clear that the performance lags behind Flutter by a large factor. If I had to choose, I would take on the tool that offers the best development experience and a large chunk of that comes from the debugging, and it just so happens Google hit the nail——NullPointerException is one of THE biggest risks of using other toolsets. So If I had to bet here, I would put it on Flutter/Dart. It is essentially a love child of ES6/Java/Typescript and it just hits so many pain points coming from React Native. I really do think React will become the Java Swing of our generation, yes you've done everything right but it seems you need to keep up with new trends and the usage of hooks is really annoying and unintuitive. In fact, here on the web front, I think Backend-as-Frontend where we persist application state in websocket will be a game changer. On the mobile front, Flutter clearly scratches the itch for both newcomers, react native developers but also backend-as-frontend really gets rid of the need to maintain two separate code bases (one for react and the other for backend). I think a web app that loads via Backend-as-Frontend framework that Flutter talks to like a regular joe REST API will be the paradigm shift. I would love to hear what others think of my views as I'm curious as to how my bets will pay off.
quesera 5y ago

ecshafer 5y ago

I have a couple issues with this article. The first is the claim that Flutter is one of the most popular native apps. I haven't seen or heard of anyone actually using it. Flutter and Dart barely exist. After React native, the next biggest would probably be just plane old native, or electron. The second is their claim that google has a great developer experience. I legitimately have never had any google product with a good developer experience. They always have a painful developer experience compared to Facebook products.

AbrahamParangi 5y ago

As a general rule, I’ve found if you have to choose between a Google maintained project and a Facebook one- pick the Facebook one.

agent3bood 5y ago

A comment on hiring and training. I have work with React, web, RN, and Flutter and I can say the biggest training part is always on the platform/framework part not on the language. So would it be easier to train kotlin/swift developer to learn new mobile framework; or train js/React developer to learn a new platform?

kimown 5y ago

The big mistake of flutter is Dart, I am not optimistic about Dart.