Flutter is better than React Native in all the ways that don’t matter
shift.infinite.red
shift.infinite.red
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.
This could be a good approach for someone huge like Google or government. Asking that from an ordinary company will not work.
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.
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.
Exactly. Tech stacks are extremely transferrable, at least to an experienced developer.
Imagine hiring a painter. You want a green wall. You don't rule them out, or pay them 20% less, because the last wall they painted was pink.
It may seem this cannot happen, but in a system experiencing rapid inflation it's what you'd expect to see. This doesn't have to be on a macro level. The endless tide of VC + crypto funds have created a form of (hyper?) inflation inside the tech industry in which wages are spiralling upwards without any fundamental link to increased value. It's simply a bidding war in which those who fight for closer access to the flow of inbound money can always outbid other firms, regardless of how much they pay, because there is no "market rate", just "whatever this guy currently makes + 20%".
> The endless tide of VC + crypto funds have created a form of (hyper?) inflation inside the tech industry in which wages are spiralling upwards without any fundamental link to increased value. It's simply a bidding war in which those who fight for closer access to the flow of inbound money can always outbid other firms, regardless of how much they pay, because there is no "market rate", just "whatever this guy currently makes + 20%". .
Of course there's a market rate, it's just increasing. That's called supply and demand. And it would happen regardless of any one specific technical skillset.
If anything this just further emphasizes the OPs point as specifically because demand so significantly outstrips supply, companies should be willing to train someone up rather than forego a promising hire, as that increases their potential labour pool (this is basically the labour market version of a substitute good). For the same reason companies are looking at partial- or full-remote hires, launching offices in other markets, etc, as that gets them access to a broader labour market outside the SV bubble.
Frankly, I don't know what you even mean by the claim that there's no "fundamental link to increased value". There is a demand for labour. There is a clearing price in the market for that labour. That clearing price is going up due to a high demand for that labour relative to the supply. Buyers are willing to pay for labour at the clearing price based on their assessment of cost-vs-benefit.
You may not think that labour is being put to productive use. But that doesn't imply the labour market is in any way flawed or that the laws of supply and demand have somehow broken down.
If you're competing against firms like Google or startups that just raised unicorn funding, and these days everyone is, then the people bidding in the market or labor are not doing cost benefit analysis. They just need to hire. They have the money, they need to hire and they're going to do it no matter what the price ends up being because that's just what they do. Whether the hires actually generate more value than they're costing is only rarely assessed because the money won't dry up anytime soon.
Additionally, market rates are an abstraction. Consider a simplified example where you have 3 people who need to buy a chicken. They're all starving so they need the chicken or else they die. First person bids $1. Second person says, I'll pay $2. Third person says no wait, wait, I'll pay $3. First person says, I'll bid $4.
This loop ends when only one of the people can still pay and everyone else starves. It does not end when the price has reached some a-priori knowable "market rate" that you could go out and measure ahead of time. To the people actually in the market, they have limited information and don't know what the bidding limit is for the other players, and thus to them it can appear that regardless of what price they bid, they are always beaten by 20%.
In a properly functioning liquid market in which nobody has access to printed money, this cycle is supposed to reach an equilibrium fairly quickly with supply catching up to counterbalance demand. In the actual software market there's been a fairly direct flow from quantitative easing and crypto directly into employers, as well as the yearly 20% revenue bump Google always seems to achieve, so some participants have effectively "unlimited" money. It doesn't make sense to talk about a clearing price in that situation. From the perspective of any normal business that gets money from customers, they will always lose.
That is a cost-benefit analysis.
They've received funding, they have a business model, now they need labour.
It seems to me your real gripe is that there's a large amount of investment flowing into Silicon Valley and you don't believe that should be happening.
> This loop ends when only one of the people can still pay and everyone else starves.
That's right. And that means, in the valley in particular, some companies will never get off the ground because they can't afford the price for labour.
The solution is simple: hire in a different labour market.
> To the people actually in the market, they have limited information and don't know what the bidding limit is for the other players, and thus to them it can appear that regardless of what price they bid, they are always beaten by 20%.
Sure, that's called incomplete information, and it's a feature of virtually all markets, minus open and instantly traded markets like stock exchanges.
I'm not sure what point you're trying to make, here, other than to complain about a general feature of capitalism that (in a refreshing change of pace) happens to be working in favour of labour.
> In a properly functioning liquid market in which nobody has access to printed money
And now we get to the political axe you're grinding.
Look, the SV labour market has been explosively expensive for 20-30 years. This isn't a new phenomenon by any stretch, and it certainly pre-dates the 2008 financial crisis and the low interest rate environment that followed. There's a reason outsourcing became so popular throughout the early 2000s.
The problem is that tech companies failed to expand their labour pool beyond a few tight markets, either by opening offices in other locations or supporting remote workers. That's their choice, but don't complain when labour prices go up as a consequence.
1. "Hire/retain at market rate". Easy unless you don't know what the market rate is, which you don't, because - as you say - incomplete information is an inherent feature of any resource allocation system including markets. Which is probably why vbezhenar phrased their claim in relative terms instead of absolute terms, whilst caveating that this is true for an "ordinary company" but maybe not for Google or governments. Theirs is an inside-the-market view. You're arguing that all you have to do to solve this problem is somehow step outside the market, and just know what the final price actually is for any given person.
2. "Hire in a different market". But that isn't an answer to the OP's point, it's an agreement with it. He's explaining why ordinary companies will refuse to train people. You're claiming the "solution" is to get out of Dodge i.e. not train people. It's not a refutation.
There's no political axe grinding here. What's happening is not unique to SV tech firms. It's an inevitable consequence of CB monetary policy distorting classical market economics. The causes of the policy may ultimately be political, but the outcomes are inevitable.
Or your budget took a hit due to half year gap in delivery, caused by boot camp you conducted and then bigger company snatches your team, while you have no way to react.
If you need to slip or stop development for a half year because you need to train up a whole new team, you have a whole other problem.
If, prior to hiring, you failed to budget for an appropriate market rate reflecting a skilled up staff, you have yet another problem.
Honestly, at what point can we agree the real problem is bad management?
Yes, which is why nobody reasonable does that. Which leads us to the original point, that many companies will not be interested in taking risk to introduce flutter.
I might grind away at Amazon for a couple of years (personally - no offense to the people that love it, it isn't for me), but that sort of job first, life second - everyone move up metric isn't for everyone. Some people are "professionals" and some people are "craftsmen"... I guess? Neither one is good or bad, they're just different mindsets and goals.
There are companies (though few, I suppose) that want "craftsmen". There are companies that want "professionals". A good company, wants both.
If you hire decent developer and it takes a year to teach them for example react to be productive the problem is not with the developer. Normal developer should be reasonable productive in a matter of days. Ok give it a month. And it does not require tutor hanging over the shoulder.
The problem is with you as you've just hired someone who's at the moment unqualified as a developer in general.
A week is just enough time to get a cursory understanding of the product and tooling and fix a newbie bug.
If it's a tiny startup on mostly greenfield stuff then sure, but that's also not a reasonable proxy for the rest of the industry.
After Google I joined a startup where I built two new products from scratch, including hiring most of the team myself. On boarding time was about a week and that included learning a new programming language from scratch (Kotlin, which is in fairness, easy to learn). This remained true true even after several years where the codebase had become quite large. On-boarding time never really changed for programmers of equivalent skill.
Ramp-up time in most normal businesses and most normal codebases is measured in weeks, not six months.
Now you could make an argument that React/Rails/whatever shares some of the blame for encouraging/allowing the state of the code.
Well the developers you want to hire would know zilch about that codebase so you have to train them anyways. And after you do they will not leave because for greener pasture with that new knowledge since nobody else is using that codebase internally.
> Unless companies start hiring to mentor people this will not change, and probably TS will just eat all the others in the long run.
You and I both know this will not change. Thus, TS will eat all the others. That's an underlying assumption in my article, to be honest.
It is a job satisfaction risk though. Just because a person is capable of learning a language or technology, it doesn’t mean that once they have learnt it they will find satisfaction in using it every day. Surely most people with a decent amount of experience has at least one language or technology they dislike?
Only hiring people who have experience with the language or technology doesn’t just mean that they can be productive much sooner, it also means that you are selecting only the people who know they want to work with it every day whilst filtering out people who would end up disliking it.
Doesn't that imply that we all like the languages we use every day? I'm fairly sure that's not the case for a lot of developers. In fact, I'm certain loads would like the opportunity to use what they think is a 'better' language, but they can't because too few companies hire for it.
If somebody hasn't worked with the language before, that confidence is not there at all.
> I'm certain loads would like the opportunity to use what they think is a 'better' language
Sure, but expectations and reality are not always in agreement. The grass is always greener on the other side, right? Those people might have a different opinion after working with the “better” language for a while.
Yes and no. I tolerate writing in Java, but for most applications I'm not a fan. I think what GP is alluding to is that developer ergonomics matter more than we give them mindshare for.
Developers also switch jobs to get more salary and market themselves as specialists in a specific stack.
I yet have to see developer taking pay cut to retrain in a different tech.
Companies already have to factor in training of people on their company specific stuff. That is why no one expects new hire to be fully productive in first 3-6 months. Even if you know JavaScript it still is quite a lot of work to understand code base ... now take someone who does not know JavaScript and as addition has to learn company specific stuff.
That is why hiring is like that because "tech" is transferrable skill between companies and developers like to invest into transferrable skills.
If you need a JS expert because you currently don’t have anyone who can figure out performance problems with junior engineer’s changes, that’s one thing, but you then probably can train that JS expert in any JS framework very quickly. Likewise if you need a UX expert, that UX expert should be able to pick up Swift or whatever language you need them to work in faster than it takes them to grok the business problems you’re actually solving.
I'd argue that most tech just does not take that long to train in. If I am proficient developer that knows Postgres, how long is it really going to take me to be productive with Mongo?
This is very different compared to say a web developer moving to robotics. I would take a pay cut for that because the knowledge gap is so wide.
Do people really look at the JS webapp framework landscape and feel that LACK of proliferation is a problem?
React is the clear winner in terms of market penetration as that is what happens to projects with the largest marketing budgets / corporate hype.
Then, you have the tooling that are completely different. Where it would normally take me 5 min to jump into Xcode to profile an application, inspect for leaks or other performance issues, I spent a few hours going through Android documentation learning how to do the same thing.
Last, and this one is a bit nuanced and sort of hard to explain. As a senior engineer, you're typically expected to help mentor others and maintain the foundations of your product so that as new people join they have a template to work from. If you're switching to something so different, you could end up hurting the team (or company) by using the wrong patterns and promoting incompatible ideas. People need to trust you and if you break that trust at the beginning of your employment, it'll be really hard to earn it back.
No regrets though, and I'm grateful to my employer for giving me the space to make the shift. However, I do not believe in the idea you can hire someone at a generalist level and then expect them to be productive anytime soon.
There is a saying, "Jack of All Trades, Master of None," and although very cynical, it's just an honest statement when it comes to these things. Hire the right person for the role you need filled first, then if you want to make room for engineers who are looking for big career changes, make sure your product and team won't suffer for that and you have the right culture in place to encourage that kind of growth.
This wont change until SWE stop job-hopping so much. In turn, the job-hopping won't stop until employers stop prioritizing new hire compensation over existing employees...and I don't see how this stops because it's measurably profitable and is self-reinforcing.
On the flip side, as an employee, I like that I can reuse the skills I have, it commoditizes employers and lowers the friction in changing jobs. Knowing what I know about capitalism in practice, employers would love the savings from employee tech lock-in.
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.
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.
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?
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.
It's like going from Kotlin to Java, or Swift to ObjC, or Typescript to Js. Tooling stinks, language features are missing, ergonomics are bad.
I don't want to get down too much into the details because much of language design is subjective. I found it very easy to work with because it has a lot of the edges sanded off, relative to JavaScript. The developer experience is pretty good.
I have definitely heard stories of people at companies like Google and Facebook who have done things in their career that saved or made the company enormous amounts of money in one fell swoop, people who can help get massive projects back on track or solve thorny resource usage problems. The theory is that if they've done it a couple times in the past, you do what it takes to keep them around because they'll probably do it again in the future.
These people generally get positions crafted for them, and sometimes teams.
They just weren't going to go through yet another rewrite and thus kept the team going.
Notice that almost everyone involved with Dart 1.0 is no longer around.
How is the market for "standard" apps doing? One would think that by now "UI for a Database/API" should have died out already? Even if companies do need an UI for a DB or an API, that job must have had become really simple with all the frameworks and libraries.
On Twitter I keep seeing people building the millionth water tracking app, so I guess there's still market for everything but I feel like "Coding regular UI with a login form and stuff" kind of jobs must be vanishing, aren't they? Surely design tools must be able to extract functioning UI's or a bit of coding know how should be able to enable anyone put together a decent UI using components libraries?
From my casual observation the learning curve for "UI for a Database/API" is becoming steeper every year. Such software reached its high point with VB6 or MS Access but since then simple tools have been dying and replaced with ever more complex frameworks. You still can't easily develop a web app that's as powerful and simple as you could do on the desktop with VB6 or MS Access.
Established companies have established company problems, complex flows that need to account for things like legacy deep links, A/B testing, UIs that go off the beaten path for brand identity, etc.
It all adds up to very little of a common denominator for all of these apps.
I've worked on some of the top apps in the play store for their respective categories, and if you saw their codebases your first thought would be "I could recreate this app in 1/10th this much code!".
After actually talking to all the stakeholders involved your second thought would be "I'm amazed this didn't take 10x the code!"
I was thinking about greenfield projects.
Also in my experience, basically every company out there needs or wants an app. A web app, a phone app, a TV app, a tablet app.. internal apps, external apps, apps to gap 3rd party app integrations, they're fucking everywhere. A lot of these 'apps' are just web forms over CRUD data for one reason for another, but it's custom for some reason. And the reasons for why a GUI builder gets phased out also applies to why app-farm apps also get phased out of a company. Eventually, with enough success, having an internal dev team is just so much smoother than contracting or bridging the gap with excel spreadsheets. Someone has to wire things together, and eventually they get to fixing the root cause of inconsistency and a custom app is born.
I think we will have programming jobs for basic forms for a lot longer than any one of us would suspect, for a lot of reasons. But my last and most important thought is, once something becomes easy for anyone to do it becomes common. To stand out you need to be uncommon in some way, so there will always be space for people who can do what most others cannot.
Causes:
1. Web platform is very unproductive and hard to learn compared to what was available in the 90s. There's no widely accepted, robust and modern equivalent for Access, VB, etc. These tools were designed to be easy to learn. Smart business analysts could throw something together. It'd be a mess but you could graduate it into a "real" app, or something approximating that, without needing a rewrite. This culture is gone. No, the web is definitely not as easy. Think about how complicated just binding a DB table to a paging table view is. HTML doesn't do this, SQL queries can't even be serialized natively, so you end up needing a custom web server, a backend framework, a frontend framework, extra JS libs or widgets to give paging or scroll or fast updating search. Consider that with Access or FoxPro it could be almost all GUI driven.
2. Although a few complex requirements got simplified out by the march of tech (e.g. offline access, supporting downlevel browsers), mostly, enterprise requirements became more complex. Some of this is reasonable and legitimate, like integrating with SSO systems, mobile versions, better auditing, more beautiful UIs and elimination of scheduled maintenance periods. Some of it is of questionable legitimacy. A lot of CRUD apps become over-engineered because of CV-driven development. Does your internal app for the business really need to run on AWS Lambda for scaling reasons? No. It doesn't, because the traffic levels are predictable a long way into the future and a single dedicated machine can do what you need. Will you be able to find a developer who will actually admit that and throw together a simple Spring Boot or PHP app, instead of trying to Web Scale™ it up the wazoo? Maaaaybe.
3. Platform churn. Businesses don't like rewriting apps but from time to time they have to, because either they can't find anyone who knows the old tech anymore e.g. COBOL, or the platform goes out of support. So the same stuff gets rewritten again and again without underlying change in business requirements. Worse, these projects often fail and may need to be attempted multiple times.
4. Many of these "standard" apps are astoundingly complicated. "Regular UI" can involve complex and frequently changing UI designed to navigate large datasets. Is Facebook a "regular UI with a login form"? Well yeah but it's still a lot of work to build. Think about the complexity of Bloomberg terminals for example.
5. The idea that all business apps were written by 2000 already is false. Even today there are a shocking number of business processes that have little or no IT automation; they're still based on physical paper. I didn't believe it myself until I worked in the enterprise space for a while and saw it with my own eyes - there is still enormous business value that can be delivered from writing new "standard" apps. And of course, even once you get beyond paper the long tail of business processes that are automated using an unholy and unstable mix of nightmarish Excel macros, PDFs and executive assistants is more or less unlimited.
I think programmer salaries are partly being squeezed upwards by the fact that we've made the tech stack so difficult to learn. Have you ever watched someone try to learn programming from scratch, like at a bootcamp? I have. It's excruciating. I watched as they tried to teach someone who'd never coded before how to write a "standard" CRUD web app, using Ruby on Rails. Total failure. They were not even remotely in reach of the goal. To succeed with even a basic app they needed to learn about Ruby, SQL, HTML, HTTP, ORMs, JavaScript, JSON, CSS, and of course the UNIX fucking shell because even if you pay $$$$ to Heroku to simplify deployment, it's all driven by a CLI anyway!
Back in the 90s one reason Microsoft won was that they managed to hide the complexity of their underlying platform with beginner friendly languages and tools. When Windows programming starting sliding into irrelevance and they dropped VB to try and compete with Java, we made the on-ramp way steeper.
But since they aren't free beer, they are only available to those that happen to live in Fortune 500 universe.
If I needed to quickly throw together a business CRUD app then I'd be tempted to buy it. At $1000/yr/developer, that's about the cost of 2 weeks of work (assuming a lowballed $90k/yr salary). Can it save two weeks per year? My guess is yes, especially if it lets you hire less experienced devs who maybe haven't written a CRUD web app before or would find it slow going / be likely to make errors. I dunno if that pricing level puts it in the Fortune 500 universe. It probably makes sense for freelancers and internal corp devs too.
The way both flutter and dart adapts for each others needs is super cool.
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.
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/
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_forge...
I've had apps where I memoized everything, then turned it all of for a testrun and it was very visibly slower without memoizing.
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.
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.
If you can't find them, you gotta train them
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
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
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.
Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart
Often it comes down to certain engineers having outsized voice and influence combined with them having a preferred hammer and then hunting around the organization looking for nails. IMHO that's what happened with Dart & Flutter.
I saw it happen in two PAs, and the second time it involved literally rewriting an entire shipped product on a platform I worked on. Slowly and tortuously, rewritten from a JS/HTML application to Dart/Flutter on "native" (i.e. not web or android or ios target), and only a few months after said product launched. To me this was classic Joel Spolsky "Things You Should Never Do, Part I" aka "rewrites considered harmful" alarm bells, but who listens to me, I'm just a grouchy old engineer.
One promise was that it would be faster (because "native"), but this was frankly based on a lot of untested assumptions and biases and was never correct. V8 and the Chromium rendering engine have (low estimate) hundreds of thousands of hu-man hours of optimization put into them. It's actually really hard to beat. Chromium has a pretty decent accelerated rendering stack, and boatloads of work went into getting it optimized for smaller SoC type devices (work often done by friends / coworkers of mine, actually).
And switching to Flutter meant having to jerry-rig (or worse, rewrite from scratch) basic things like accessibility (screen reader, magnification, etc.) or virtual keyboard that Chrome (or at least ChromeOS) had solutions for and we had just spent over a year making work for our product. Flutter delegates down to Android or iOS's implementation of these features, and as we were neither, we had no such thing. So it had to be built.
So the net result was either rewriting things that had already shipped, or, more commonly building awkward translation layers and bridges between the two platforms so that both things could run at once. a) waste of engineering hours b) source of bugs c) was happening instead of dealing with tech debt and improving or evolving the existing codebase.
The one upside was portability between Android and our product, so the same feature/app could be written for both... which I would accept as the only compelling reason to justify what was done.
I could go on, but I'd probably give away internal secrets or something, and probably piss someone influential off or burn some bridges.
My overall point being: test your assumptions and don't use some tech just because you a) like it or b) wrote it.
Also I don't really understand why Dart even exists. In the 21st century, there are very rarely serious problems to which "we need a new language" or "we need a new operating system" are the correct answer.
Nope, they already had their own version of Java, J++, which is where Windows Forms was initially born, alongside their extensions like what would become P/Invoke in C#.
J++ was going to be the main language for Ext-VOS, the project that would eventually be known as .NET.
Then the lawsuit happened, COOL was born and eventually rebranded as C#.
Quite easy to know how C# happened when reading HOPL papers about its history.
In this regard, Microsoft was less lucky with the lawsuit than Google with their Android Java.
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.
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.
Flutter is a very Android first framework, for obvious reasons.
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.
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.
If Apple or Google decides to boot you off the store for whatever reason, you're not out of business, you can distribute as a PWA and never really notice.
For many LOB apps, discoverability via the app store isn't relevant at all.
My primary app distribution mechanism is a SMS message with a link to a PWA that installs to home screen. Works everywhere, on every platform, which is a huge advantage for my senior population users.
To me, it feels that Ionic is only good for the "minimum common denominator" of apps (a webpage, maaaybe with some storage), but once you move a bit from that path, you struggle a lot with half-baked plugins and "black boxes".
Oh, and the documentation... both for Ionic (which? cordova o capacitor?) and the plugins, it is SO bad. Also, the fact that Ionic is actually a for profit endeavour, and you will pretty soon hit a wall that you only can remove by paying.
On the "for profit" side, I see this as an advantage. We try to only charge for things that are cloud and have natural cost, or that really only enterprises need. We deliberately keep the vast majority of our platform free and open source. The fact that we generate revenue from enterprise customers is actually awesome for our projects because we are directly incentivized to improve them!
We aren't merely an advertising-driven business that creates open source for other reasons (hiring, internal use, etc), but we are literally in the business of mobile technology. If you're a big company, you can actually call us or use one of our integrations that we directly support and you can file tickets against and have an SLA, and our cloud services integrate with your existing enterprise CI/CD infrastructure. Think about Facebook ever doing this! It's a unique offering in this space that our customers really love and directly benefits our OSS work.
Finally, on our docs, there is certainly room for improvement, but we often hear the opposite: that we have some of the best docs around for OSS projects!
The only reason I got to use them was because I had no saying in what they were trying to do, just a cog on the machine.
Both applications could have been done as PWAs, but they decided to push Angular into a Webview instead, taking ages to start and react to any screen interaction.
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.
Said differently: I believe it's often worthwhile to discuss the deeper technical merits of options without hastily jumping to a cost discussion.
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 !
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.
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.
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?
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.
When I see cross-platform frameworks suggested, it's usually to reduce the internal project management and QA work.
I've always thought this was a bad reason. Fix the real problems first, and don't force users to accept a substandard app.
But this is changing. The frameworks are getting better at a much faster rate than the humans are improving their own management processes.
And users don't seem to care if apps lack some polish, anyway.
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.
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.
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
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.
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.
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.
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.
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.
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.
———
* In all the ways that don't matter.
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.
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.)