HN

Comments (337)

• Menu

  Waterluvian
  If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources.I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely.I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.
• Menu

  tonic_note
  Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it.But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
• Menu

  atonse
  We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish.Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and had the whole thing working in android and iOS in the morning. Took it about 6 hours while I slept.The app is way smaller, launches instantly, and the android app is (supposedly) native looking. I say supposedly because I don't use android phones. But it's using Jetpack Compose and Kotlin.And I don't know Swift or Kotlin. I honestly don't see the point of React Native anymore. I know Expo is doing very cool agentic stuff, but I'm just not sure why I'd need any of it when I can write a native app.
• Menu

  pkaler
  I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform.The latter is true but the former is false.What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.I've seen that countless times in the last two decades.
• netshade
  I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.All to say that this decision is worth considering without even taking LLM assistance into account.
• Menu

  fnthawar2
  We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.What we found led us back to native.
• canto
  So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create the same with more. Yeah, that's smart. Super smart.
• Menu

  jrochkind1
  I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before.> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?
• LelouBil
  [delayed]
• Menu

  asimovDev
  Dropping React and going back to raw JavaScript next?I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use
• Menu

  underdeserver
  And I'm just sitting here looking at the Codex desktop mac app wondering why a list, a chat window and textbox require a 579 MB download (compressed) and 4 GB of RAM.
• Menu

  iBelieve
  It's interesting that they don't mention Kotlin Multiplatform or any sort of shared core logic between their iOS and Android apps. Seems like maybe the apps are fully independent codebases but with shared specifications and tests? They say that agents:> Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpointsI've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully native.
• vmg12
  React native isn't a terrible idea, its fundamental issue is that Apple does not allow for JIT compilation on iOS. So that means your app's js logic will be an order of magnitude slower than what you would get in the browser.
• Menu

  seanhly
  Bragging about "using agents to code pre-GPT" is quite the corporate flex... weren't they notoriously bad back then? Might as well say, "We've been doing spreadsheets with quantum computing since 2016"
• trynotsober
  The shared specs and tests seem like a big part of making this work. I'd be interested in a follow-up after a few months of shipping new features on both platforms. Does keeping behaviour consistent still take much coordination, or have the agents reduced that work too?
• pzo
  Wish they explained more. Even though I'm mostly native iOS its seems react native is better stack for AI and iteration (hot refresh etc) - the main reason pretty much all AI vibecoding app were implemented via expo/react native.I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.
• w10-1
  Most of the costs of switching have yet to be borne: user issues with untested code, maintenance issues with code few understand, and the strategic dependency on coding LLM's, which will change in character after providers go public and need revenue to fit reasonable stock multiples. All only get worse with time unless they're addressed proactively.
• ChiperSoft
  Before I even opened the article I knew the reason was because LLMs don't need abstractions. React Native was always about making app construction easier for people who don't want to learn ObjC or Swift. If you're not writing or even reviewing the code yourself, this is unneeded overhead.For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.
• mcsniff
  I use Shopify app every day, multiple times a day to run my business and it has always been buggy and inconsistent for me on Android, and I don't expect this will make it any better, especially with more AI in the mix, but we shall see.Who wants to bet there still won't be a dark mode?
• Menu

  lackoftactics
  I believe this will be overall trend in industry. Dropping React Native and Flutter for native
• rietta
  The promise of React Native was easing development burden from the web app to the native app. It makes sense if they are just using coding agents to cut out the framework and just go native.That was my thought when I saw the headline and then reading the article confirms this is the inflection point per their own words. Very interesting.
• Menu

  negative10xer
  I remember their blog post claiming how much of a win it was to move over to react native and maintain high performance. They even listed their performance metrics. At that time I was a mobile developer for an e-commerce business and the metrics they were proud to share were unacceptable on our native apps. Here they are coming full circle
• Menu

  muddi900
  It is the "why use python" for mobile.The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.
• Menu

  simonhamp
  As the builder of a post-AI, cross-platform native app building framework like React Native, I 100% believe this to be a backwards move.I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years.[1]: https://nativephp.com/blog/why-not-write-it-twice
• koeliga
  https://shopify.engineering/shop-app-migrationfollow up with some more technical details and benchmarks
• moomoo11
  i think many ppl don't understand this newsIMHO...if you have a large org, a large app, lots of revenue and $$$ and resources...it makes sense to do fully native now.if you're a startup, you don't have the resources and $$$, you stick to RNyou can obviously have AI maintain both, but that is a cost. double maintenance = more $$$ on tokensso many people are being doomer about this, but most people are also not Shopify
• larodi
  Truth is the Shopify app is simple enough to get right by a model. Lots of things hare simpler to get right in native code, so it is to be reiterated - a lot of interpreter code/libs is going down the drain, along with the devs that write it. These are not needed anymore.And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.
• dev_l1x_be
  Native is the new React?! I could never drink the React Native cool aid due to background in performance optimization. Agents gave us the way to go native with less effort. Compilation is a good feedback loop for the agentic workflow as well.
• Menu

  ergocoder
  A companies with thousands of engineers should simply go native.Write once, deploy everywhere like React Native mainly benefits small teams and startups who are okay with building 90/10 solutions.At the shopify's scale, they would want to go advance for every corner of the apps and use cases, and only native allows that.
• ecshafer
  They don't say anything in the post. But hotwire native supports pushing ui elements to ios and android. I imagine that might be part of the reason. I haven't built anything substantial with hotwire native though so I am not sure on all of the edge cases.
• bilater
  This is obvious in hindsight. I expect most companies that move fast and care about performance to abandon React Native. Code is cheap now, and the tradeoff of having a single codebase and only hiring React devs basically isn't there anymore.
• m_sharma
  As things get more complicated and you need to worry about performance, where every millisecond counts, it makes sense to go to native: React Native and Flutter. These kinds of technologies are really good in terms of building faster and building one app which can work across. Where that deep performance might not be of a bigger concern, or you need to go build components natively and then expose them through React Native. I think, with AI, now building even a native app is faster, so moving back to native can make sense if you have a team which can understand how things work.
• parentheses
  The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen.The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.
• tzone
  With latest AI models, we will most likely see shift back to just fully Native apps even for smaller teams. This is type of stuff that AI models do really well, if you get a particular feature or even a bigger app change done in one platform, you can just tell Opus or Fable to replicate to the other platforms and in almost all cases it will just do it as well as most human teams would have done it.
• bearjaws
  We made the same change for our patient app last month, took 2 months to rewrite from react-native to two mobile apps, but we had the PoC in under a week.Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
• manlymuppet
  This is probably one of the things that excites me most about AI.Companies can now just afford to maintain a hundred different native apps, rather than settle for a write once, run anywhere approach.
• nielsbot
  When companies can afford to build a native app but instead use a WOSE (write once suck everywhere) toolkit, it’s because they don’t care about the user experience.
• Menu

  uncle_kostya
  An Android developer since 2010 here.I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck.But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs?I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.
• Menu

  polloRebozado
  I have not coded any mobile apps, I understand the downsides of using react native/electron due to them being web apps but what about things like Kotlin multi platform or flutter? Aren't this frameworks supposed to allow your to have 1 codebase and the apps be truly native instead of web apps?
• Menu

  synergy20
  wow, what about electron.js the bloated cross-desktop GUI, can LLM either totally modernize wxWidgets(to avoid Qt's license mess), or create some light-weight cross platform GUI widgets to make GUI easy on windows/macos/linux that is not resource heavy?
• thisismyopinion
  Would be nice if Spotify and Notion did the same.
• aecorredor
  The most interesting part to me here was the whole helix thing + how they split business logic and UI just so AI agents could drive/test state via a CLI. I hope they do a deeper blog post on just that. I’m surprised they are making “decouple state from UI” sound like something groundbreaking when that’s kind of been the foundation for any sane/testable app for a LONG time.
• Menu

  iamgopal
  when you are large enough to allocate sufficient resource, you should go native, if not, go flutter/react native etc. Its very simple decisions I guess.
• Menu

  gargs
  What I want to know is if the agents are so good that they can convert React Native code to native with amazing efficiencies along the way, what's stopping them from improving React Native itself?
• jnwatson
  In the history books, this'll be the post indicating the end of writing code as a professional occupation.
• tower-shield
  Finally some common sense. Time to put electron to rest.
• robofanatic
  this motivates me to rewrite my Flutter app in Swift. I gave up on deploying the app to Android because of their 20 testers requirement at that time (not sure if its still true).
• rramon
  Missing out on flawless App Intents integration could be business risk for Shopify once people get used to doing everything from a central chat interface, including shopping. I guess it's the real reason for the switch.
• BringItBack
  Makes sense in the LLM age.With cheap/fast code, it's easy to support multiple software stacks since most of the abstract engineering problems are already solved.Code - especially straightforward low-level code - is so cheap and easy to write now that some people are building their own version control systems, game engines, and other low-level tooling.Thus, some of the most demanding, human-centric work in software dev right now - where we now spend more time than coding - is in technical PM, UI/UX, devops, and overall architecture. The decision-making and design aspects of the job.Exciting times.
• nshelia
  The rendering layer and APIs differ significantly between iOS and Android. Agents currently do not know how to test the UI, at least in my experience. I would be scared to do that migration right now.
• anon
  undefined
• shawabawa3
  "native" shouldn't be capitalized in the title
• running101
  I suspected we would start seeing these types of blog posts. Code is becoming low level, where people do not care what language, it is written in anymore. The cost of moving from one to another is becoming low.
• yusufnb
  Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.
• firemelt
  expected
• Menu

  AJRF
  Most large tech companies are just job programmes, i've seen so much effort, time, cost go into things that are truly unimportant.React Native gives you (with asterisks) - one "source" for things to go wrong (as it sits on top of the native implementations of the UI + Native APIs). You are writing at that source level, and that filters down to the native builds. I am WELL aware to do certain things on each platform you need to get your hands dirty, but most apps are just serialising JSON from a database and displaying it.AI writes very buggy, sloppy code.They've decided - instead of containing that code to 1 surface, they would now have 2 surfaces they throw slop on top of.I look forward to the 2027 version of this where they've gone back
• Menu

  mt_
  The article failed to provide reasons on they why move back to native.
• 1saadcodes
  What I find interesting is how AI has changed the cost of maintaining two native apps enough that a decision that made no sense a few years ago is worth revisiting now
• weightedreply
  Isn't it silly that this even needs to be a conversation? Shouldn't we be able to write in any language we want and have the bindings for it to work cross platform? And shouldn't AI aid in building those cross-platform tools?Maybe React Native isn't the right choice - but two tech stacks for virtually identical interfaces is dumb. Three stacks if you include browsers.
• Menu

  randysalami
  “We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield)… However, this time greenfield emerged as a clear winner for the following reasons”“To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.”If this is driven by proper engineering then hats off! Supposedly a simpler app has already been migrated and they are working on migrating the main app using this approach. I don’t even know how I can be a cynic here… because the technology is good enough and so are the engineers I don’t know how management or executives could ruin it.“…product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.”If this was written using AI and human-edited, you missed a spot.
• jgwil2
  I wish more companies would just focus on webapps. It's infuriating how many services try to push an app on you when it's completely unnecessary. The other day I went to a restaurant that had an app. Not a fast food chain, a nice full-service place. No, I'm not going to download an app to order dinner.
• Menu

  aurareturn
  How long until LLMs just write machine code?
• Menu

  AtNightWeCode
  Why on earth is Shopify not just a web wrapped in an app like most apps? I mean, they implement most of that stuff for the desktop anyway.
• Menu

  quotemstr
  The wheel of fashion turns once more.
• anon
  undefined
• crossroadsguy
  Few of the biggest reasons for "migration" to the likes of React Native, and web-views et cetera, were "lack of talent", and not getting that talent fast, and for cheap, et cetera, while of course terming that as innovation, embracing the future, and "that's where the game is at" et cetera. Now with the LLMs that is mostly sorted. So if anything I'd be able to see the eradication of the Electron infestation in my lifetime. But then I see the very tools these LLMs are accessed with i.e harnesses (and of course mostly made by the LLM houses) are made of Electron or similar things (sometimes a Frankenstein like mix). And even today Claude Code shows up as `2.x.yyy` for process name ffs! So if anything, this is getting worse.Then they say:> We decided to switch from native to React Native in 2020 for three reasons:> Stop building the same features twice> Allow developers to work across the stack> Spend less time chasing feature parity and more time shipping valueTotally!Is there some kind of shame in just saying:- we didn't want to hire more people- we didn't want to pay those salaries- we fired a lot of engineers with move to react native/hybrid in mind- we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.
• starlineventure
  Native. Metal. Remove the abatraction layers
• Menu

  faangguyindia
  React Native is slow.Hermes VM doesn't even have JIT.If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you.Look at V8 vs. Hermes performance.We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free
• timedude
  This is what happens when you have too much cash on hand. You start wasting it and doing dumb things. Like rewriting entire apps in two different languages.
• Menu

  giebisch
  Their reasoning makes sense. I'd love to read a follow-up and their thoughts in half a year.
• kraig911
  A side effect of perceived LLM Generated code is now easier to just make it write native I guess.
• basepurpose
  if native became easier to tackle with coding agents, react native would have been even more easier to scale. this decision doesn't sit well with me.
• Menu

  evilfred
  using React Native you end up having to drop into native code to do anything interesting or optimized, so it feels kind of pointless to not just use the platforms directly
• Hamuko
  I'm certain that small startup Shopify could not afford to build native applications before AI became a thing. Thank god Sam Altman stole all the information in the world so that small family companies like this can finally have software too.
• madduci
  The article itself comes from AI ? It says twice why they switched from Native to React Native in two distinct paragraphs at the beginning. The rest sounds also AI slop jargon.
• psadri
  Thanks to coding agents, there is no reason not to
• tonymet
  Let’s see their app size (and heap)
• WhereIsTheTruth
  If you build with electron in the age of LLMs, you should change career
• gadflyinyoureye
  Out of curiosity why not look at Flutter? I know you don't get native look-and-feel, but most apps are branded who cares?
• anon
  undefined
• Menu

  m3kw9
  They are admitting React was a shtty choice for a mobile app if they have a choice.
• MaoSYJ
  Who could have guessed it!
• ex-aws-dude
  I don’t understand why building an app twice is a big deal in the first place if that’s a core part of your businessLike wouldn’t you want to invest in platform specific expertise long term?It’s not like this is a small company or it’s just a dinky side project off of the main business
• xyst
  Can’t wait for the blog post mentioning move back to react native or other cross platform framework.
• yieldcrv
  Perfect, yeah the obvious answer and comment is in the subtitle right at the top. Good way to write an article> Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.
• Menu

  jeffrallen
  Too late. My kids called the app Stop-ify because it was so unreliable. Switched to Apple music and won't go back. On Android!
• BatchJob
  im not a fan of react native per se , but this reasoning does not add up.they are going to "delete an app" because they got some LLM to slop out 2 apps?The architect who wrote that is batshit and will be unemployed after this blows up in his face.
• krttherealest
  this AI stuff is goin crazy
• philipwhiuk
  > It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.So... local maxima?
• philipwhiuk
  I guess expect no new features on mobile until their token budget gets through all the screens?
• Menu

  sergiotapia
  Major loss for react native community at large with Skia and Flashlist dying. :(
• 976157424477
  … from React “Native”
• anon
  undefined
• Menu

  railka
  IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI
• romanovcode
  It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.
• theycallmeritik
  Good one
• gazarsgo
  Cool story but what's the token spend?
• anon
  undefined
• Menu

  hermitwriter
  I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it.Talk to me in a year.The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part.The hard part is keeping them the same.Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking.Agents can write code fast but they aren't a panacea.The load-bearing sentence in the whole post is this:"Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity."Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer?You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0.The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase?If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two.The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI.That's a good idea! Do that!But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps.Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates.So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible.Maybe it is! For Shopify.That's a much narrower claim than "AI changes the economics of cross-platform development."And where are the numbers?For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything?They even say RN performance isn't the problem. "React Native apps can be fast. Ours are."So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants.And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes.But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too.Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit.Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence.The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc.Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibilityBut it's not new, and it has very little to do with LLMs.And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control.None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious.But that's exactly the point.Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned.Right now they've shown that AI makes rewrites cheaper.Whoopty do.
• Menu

  rvz
  Agreed, the whole of the Javascript / TypeScript ecosystem has caused a slop hellscape of workarounds, half-backed fixes and have exposed short-comings in the ecosystem.Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use.Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.
• maltyxxx
  [dead]
• vanillax
  [flagged]
• Nc67
  [flagged]
• LazyIDE
  [flagged]
• jasonmp85
  [dead]
• Menu

  roshanabdullah1
  the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify