I had apps on Google Play and every year I had to upgrade libs, recompile and loose and afternoon (or two) to not win anything, just churn for the sake of churn.
Compare this to plain HTML, CSS & vanilla JS. You can deploy a webapp today and if you are not using any beta JS Chrome API you will be able to use that site in 10 years without touching a line.
I built an app for micro-journaling [0] in 2013. I think the iOS version stopped working in 2016, the Android version maybe a year or two after (I switched to iPhone so don't know for sure).
The interactive demo site I built in JS?
Still works exactly the same.
And I tried to make the apps as backwards compatible as possible.
Maybe AI could help make OS upgrade maintenance easier?
Unfortunely using plain HTML, CSS & vanilla JS feels like being a hipster in the age of using SPA or WebAssembly frameworks for displaying static text.
Unselectable static text is so last year. The cool new thing is these funny blue bits of text with click handlers that, when all the stars align, navigate to a different URL. Somewhere on the road map is context menu support, and the ability to open in a new tab is on the will-never-happen wishlist because no one can figure out how to do it in a cross-platform manner. Showing the target URL in a status bar didn’t even make the wish list.
The <a> tag is only for retro fanatics.
Seriously, I was peeking at the docs for Qwik, one of the cool new supposedly-lighter-weight frameworks the other day, and I was delighted to discover that, in what is obviously intended to resemble ordinary multi-page HTML, the links aren’t links. The long press behavior is utterly, comically wrong. This isn’t even unusual any more. I guess Qwik is proud that the JavaScript needed to emulate links is only 1kb minified and doesn’t add time-to-interactive overhead that scales poorly with page size, but literally every browser has had complete, native, no-script needed support for <a> even if the entire browser was a terminal app! Check it out:
The problem with relying on these high-level frameworks, or heavy frameworks of any kind, is that one day they will change their entire approach to how things should be implemented, and then you have a giant pile of legacy on your hands.
I learned that lesson the hard way with ExtJS 3 => 4, and now my wife claims I have commitment issues.
They are close to finally stabilizing the API (as much is possible given underlying platform stability). New Architecture has been in the works for 8 years. It’s such a massive upgrade over legacy architecture. Migrating our app to new architecture was not that hard tbh.
Ooh, I felt this one. I went through porting a webdav browser widget from ExtJS 2.1 -> 3 and then 3 -> 4. It was a nightmare. Does ExtJS still not html encode replacement values in it's templates by default?
With the New Architecture & Expo, react native is in a great state right now and is gaining momentum. We've been able to onboard a lot of web devs onto working on our new Expo universal app at my employer and only a small subset of us need to be react-native experts. We provide a component library & other platform tools to help a bunch of web devs ship an app that works on iOS, android, and web.
Over the air javascript updates are such a massive advantage over fully native apps, and expo-router now has server-driven UI via react server components.
I have a lot of respect for the work the React Native folks do but at the same time the constant reinvention just highlights an inherent weakness in any framework like this: you don’t control the platform, so you’re always always at least one step behind.
Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight.
This used to be the case when the platforms were much younger and new features were introduced every year. But I would say it’s mostly stabilized now. React native had day 1 support for Liquid Glass and new AI APIs introduced on iOS 26.
> Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight.
But then you have double the work, in double the languages/frameworks for the two platforms.
For a real world datapoint - my team at a FAANG invested heavily into RN over the course of years, the promoters kept touting the "only write code once!" line, and after years and years of effort in the end we managed to share only ~10% of code for any given new feature. For any given RN feature we also had to write so many APIs/hooks/setup in native code to support it that the 10% code share didn't even save us any time.
In fact, we were prevented from doing a lot of stuff that we wanted to do, because RN either A) didn't support it (because iOS didn't have a similar concept), or B) we were gated on upgrading / using something because it depended on doing a massive RN version upgrade, which nobody wanted to schedule the time for. So I'd argue it was a net negative to productivity overall.
I could continue ranting and raving about this for many paragraphs but I'll limit it there. Not a fan.
We're looking at moving to Expo from RN precisely to reduce the pain & risk of RN+dependency upgrades just to stay compatible.
Google (and Apple) have been keeping us on the upgrade treadmill, so I'm hoping Expo can be responsible for handling that and maintain a stable API for our apps and dependencies.
Have had our apps on expo for a while. Highly recommend, much easier upgrades and you can turn off any platform vendor stuff like their OTA updates and do local builds also. Expo + RN has saved us a ton of time on our apps and no way a small team like us could support both platforms otherwise.
It’s not really double, something closer to 1.25x. The bulk of the work is on whatever platform you first implemented the UI on, because that’s where rubber hits the road and you run into things like assumptions the designer made breaking. On the second platform all that’s already done and you just need to replicate.
Besides that, in your typical CRUD app the UI really shouldn’t be the hard part anyway.
Additionally, you’re going to have to deal with per-platform bugs which require you to dig in to the native side to fix even if you go all in on RN or Flutter or whatever the cool thing is this month, and that’s in addition to the bugs with the framework. Finally, major system updates tend to be much more of an ordeal with these frameworks where (for example) mature iOS apps can easily go years without major changes.
There’s also things like https://skip.tools/ which translates your iOS SwiftUI app into native Android Jetpack Compose on the fly.
Double the code, but not necessarily double the work. And look at this blog post: these "write once" solutions often have the surprise of a bunch of extra work you weren't expecting.
Perhaps it's buried in the article somewhere but I think it should highlight in the introduction what business problems were solved or improved, and what the original architecture was; essentially why this major migration was undertaken.
One of the biggest arguments against using cross-platform frameworks like React Native comes from the people who use it the most. I can’t help but read articles like this and think that it’s so much unnecessary toil. It took them years to migrate to React Native, and now they have to deal with all this crap.
I’m realizing from first hand experience that there’s a lot of complexity in RN, it offers a lot of benefits but not without significant cost. Reading source code, debugging dependencies, and even working with dependency maintainers can be necessary.
That's why 'New Architecture' is a bad name. They should have called it 'Bridgless Architecture' or just 'V2 Architecture'.
I remember how in an old ClearCase codebase we had a comment saying `New! <projectname> 4`. Version 4 was about 20 years old at that point. We kept this comment as a reminder to never use 'new' when naming or describing anything.
I tried a little while ago, sticking to raw HTML sucks arse, basic shit that should be built into the language like file upload is fucking painful. If react is too heavy just say react is too heavy
In the time it took to write this self-congratulatory post, they could have used the AI they push down everyone's throats to add dark mode to the mobile app.
React is a bad idea imo. I see small teams do way better with plain old HTML augmented with minimal Javascript. React itself is huge to download and slower to execute. I can't believe we're still stuck in React world.
React's core concept was excellent. It solved many of the issues with previous view libraries. What React turned into over the years is problematic, accumulating bad design decisions until it became the monster that it is.
The way React Native works is an example of how good the original React concept still is. It has nothing to do with HTML, it's made of cross-platform view components. It has similar ergonomics as the web version, like one-way data flow, immediate-mode rendering, view as function of state.
It's true that React has passed its peak usefulness (relative to the problems it brings), in a long tail of decline for the next decade. Newer better view libraries are being created and adopted by the community. Some of them will eventually overtake React as the next standard tool. But they all learned from React's lessons, because it really did push forward the evolution of web development.
How genuine are you being here? Because I've tried doing native apps using LiveView Native and it is ROUGH. The reason I ask is because I would consider using Hotwire Native for a future project if it really is good.
You likely mean "small projects". No way you see teams do better with plain old HTML + minimal JS on anything of substantial complexity. It was hell to organize code for a web app without a framework using nothing or jQuery.
When I use React / Next.js on Web projects, is not because I personaly like them, but because I have been part of projects using SaaS products whose SDKs are only available alongside those stacks.
Its easy to say now, if react creators knew everything that we know they would've made different choices, but at its time it was a breakthrough compared to other approaches.
The only constant in mobile development is churn.
I had apps on Google Play and every year I had to upgrade libs, recompile and loose and afternoon (or two) to not win anything, just churn for the sake of churn.
Compare this to plain HTML, CSS & vanilla JS. You can deploy a webapp today and if you are not using any beta JS Chrome API you will be able to use that site in 10 years without touching a line.
My java apps from uni days still work on windows and non-arm macs. With a little tweaking for opengl links, arm works too.
My old uni android apps still work on android last i checked. With a recompilation my ios apps work on ios too.
However, with absolutely zero work, ALL of my web stuff across all time works just like it used to even the angular 1 stuff.
It is why i love web so much. It is the ultimate distribution platform with so little needless churn.
Now compare this to Windows. You can run a Win32 program built in the 1990s, and it would work fine.
Half the 90s was DOS and Win16 which got dropped a while back. Still, I salute them for supporting backward compatibly much longer than most.
I wish that were true.
Modern windows won't even play crysis without a binary patch.
This hits too close to home.
I built an app for micro-journaling [0] in 2013. I think the iOS version stopped working in 2016, the Android version maybe a year or two after (I switched to iPhone so don't know for sure).
The interactive demo site I built in JS?
Still works exactly the same.
And I tried to make the apps as backwards compatible as possible.
Maybe AI could help make OS upgrade maintenance easier?
[0]: www.ifeelio.com
Unfortunely using plain HTML, CSS & vanilla JS feels like being a hipster in the age of using SPA or WebAssembly frameworks for displaying static text.
> for displaying unselectable static text
FTFY (but seriously, why do so many sites do that?!?)
Unselectable static text is so last year. The cool new thing is these funny blue bits of text with click handlers that, when all the stars align, navigate to a different URL. Somewhere on the road map is context menu support, and the ability to open in a new tab is on the will-never-happen wishlist because no one can figure out how to do it in a cross-platform manner. Showing the target URL in a status bar didn’t even make the wish list.
The <a> tag is only for retro fanatics.
Seriously, I was peeking at the docs for Qwik, one of the cool new supposedly-lighter-weight frameworks the other day, and I was delighted to discover that, in what is obviously intended to resemble ordinary multi-page HTML, the links aren’t links. The long press behavior is utterly, comically wrong. This isn’t even unusual any more. I guess Qwik is proud that the JavaScript needed to emulate links is only 1kb minified and doesn’t add time-to-interactive overhead that scales poorly with page size, but literally every browser has had complete, native, no-script needed support for <a> even if the entire browser was a terminal app! Check it out:
https://qwik.dev/docs/getting-started/
Wow. That is insane.
That is crazy.
Mobile experience.
It makes sense in some places; buttons, mostly so quickly tapping a button doesn’t zoom or whatever.
I agree that a lot of people are lazy and block text selection sitewide though because it’s easy and makes the PM go away.
If the PM didn't even request it explicitly.
SVG is the future /s
[flagged]
The problem with relying on these high-level frameworks, or heavy frameworks of any kind, is that one day they will change their entire approach to how things should be implemented, and then you have a giant pile of legacy on your hands.
I learned that lesson the hard way with ExtJS 3 => 4, and now my wife claims I have commitment issues.
They are close to finally stabilizing the API (as much is possible given underlying platform stability). New Architecture has been in the works for 8 years. It’s such a massive upgrade over legacy architecture. Migrating our app to new architecture was not that hard tbh.
Ooh, I felt this one. I went through porting a webdav browser widget from ExtJS 2.1 -> 3 and then 3 -> 4. It was a nightmare. Does ExtJS still not html encode replacement values in it's templates by default?
React-router has betrayed me so many times…
That package’s churn single handledly changed my career path during the days of react 0.x away from FE. I think it was on v2 or v3?
I still feel anger hearing its name the better part of a decade later.
"high-level frameworks" no different to native OS APIs. Apple/Google is constantly releasing new APIs, changing old one, deprecating, etc.
The difference is only in the velocity of changes/updates.
With the New Architecture & Expo, react native is in a great state right now and is gaining momentum. We've been able to onboard a lot of web devs onto working on our new Expo universal app at my employer and only a small subset of us need to be react-native experts. We provide a component library & other platform tools to help a bunch of web devs ship an app that works on iOS, android, and web.
Over the air javascript updates are such a massive advantage over fully native apps, and expo-router now has server-driven UI via react server components.
I have a lot of respect for the work the React Native folks do but at the same time the constant reinvention just highlights an inherent weakness in any framework like this: you don’t control the platform, so you’re always always at least one step behind.
Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight.
This used to be the case when the platforms were much younger and new features were introduced every year. But I would say it’s mostly stabilized now. React native had day 1 support for Liquid Glass and new AI APIs introduced on iOS 26.
> Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight.
But then you have double the work, in double the languages/frameworks for the two platforms.
For a real world datapoint - my team at a FAANG invested heavily into RN over the course of years, the promoters kept touting the "only write code once!" line, and after years and years of effort in the end we managed to share only ~10% of code for any given new feature. For any given RN feature we also had to write so many APIs/hooks/setup in native code to support it that the 10% code share didn't even save us any time.
In fact, we were prevented from doing a lot of stuff that we wanted to do, because RN either A) didn't support it (because iOS didn't have a similar concept), or B) we were gated on upgrading / using something because it depended on doing a massive RN version upgrade, which nobody wanted to schedule the time for. So I'd argue it was a net negative to productivity overall.
I could continue ranting and raving about this for many paragraphs but I'll limit it there. Not a fan.
We're looking at moving to Expo from RN precisely to reduce the pain & risk of RN+dependency upgrades just to stay compatible.
Google (and Apple) have been keeping us on the upgrade treadmill, so I'm hoping Expo can be responsible for handling that and maintain a stable API for our apps and dependencies.
Have had our apps on expo for a while. Highly recommend, much easier upgrades and you can turn off any platform vendor stuff like their OTA updates and do local builds also. Expo + RN has saved us a ton of time on our apps and no way a small team like us could support both platforms otherwise.
What makes you think Expo is not going to just be more of the same? Genuine question.
They manage so much of the pain points, like the toolchain, building, releasing etc.
It’s night and day compared to using RN directly
It’s not really double, something closer to 1.25x. The bulk of the work is on whatever platform you first implemented the UI on, because that’s where rubber hits the road and you run into things like assumptions the designer made breaking. On the second platform all that’s already done and you just need to replicate.
Besides that, in your typical CRUD app the UI really shouldn’t be the hard part anyway.
Additionally, you’re going to have to deal with per-platform bugs which require you to dig in to the native side to fix even if you go all in on RN or Flutter or whatever the cool thing is this month, and that’s in addition to the bugs with the framework. Finally, major system updates tend to be much more of an ordeal with these frameworks where (for example) mature iOS apps can easily go years without major changes.
There’s also things like https://skip.tools/ which translates your iOS SwiftUI app into native Android Jetpack Compose on the fly.
All in all a lot less trouble than it might seem.
Double the code, but not necessarily double the work. And look at this blog post: these "write once" solutions often have the surprise of a bunch of extra work you weren't expecting.
It’s not double the work – native developers don’t have to do the type of work listed in the article.
Perhaps it's buried in the article somewhere but I think it should highlight in the introduction what business problems were solved or improved, and what the original architecture was; essentially why this major migration was undertaken.
One of the biggest arguments against using cross-platform frameworks like React Native comes from the people who use it the most. I can’t help but read articles like this and think that it’s so much unnecessary toil. It took them years to migrate to React Native, and now they have to deal with all this crap.
My biggest surprise is no mention of AI.
I would have expected Tobi to open cursor and tell it to "migrate."
I’m realizing from first hand experience that there’s a lot of complexity in RN, it offers a lot of benefits but not without significant cost. Reading source code, debugging dependencies, and even working with dependency maintainers can be necessary.
but does it still use cocoapods
Yes, but not for long.
Src: https://github.com/react-native-community/discussions-and-pr...
A new React native architecture again?! I bet later this year we will have a new React (base) architecture change too
That's why 'New Architecture' is a bad name. They should have called it 'Bridgless Architecture' or just 'V2 Architecture'.
I remember how in an old ClearCase codebase we had a comment saying `New! <projectname> 4`. Version 4 was about 20 years old at that point. We kept this comment as a reminder to never use 'new' when naming or describing anything.
There’s literally only one time this has happened in react native and it took 8 years to finish being built and roll out completely.
I think "TurboModules" are from the "current" new architecture (now several years old), not a new one, but I might have skipped some episodes.
Maybe it's not so new, like "modernism" in art is 100 years ago.
why "again"?
I tried a little while ago, sticking to raw HTML sucks arse, basic shit that should be built into the language like file upload is fucking painful. If react is too heavy just say react is too heavy
Still no dark mode, it's almost as embarrassing as HN not having dark mode. Yeah I said it, again.
https://news.ycombinator.com/item?id=34263628
In the time it took to write this self-congratulatory post, they could have used the AI they push down everyone's throats to add dark mode to the mobile app.
I don't use Shopify so I don't know the nuances but isn't that your responsibility? Also seems a little off topic to the article ?
Their mobile app, that a merchant would use to manage their store, has no dark mode.
React is a bad idea imo. I see small teams do way better with plain old HTML augmented with minimal Javascript. React itself is huge to download and slower to execute. I can't believe we're still stuck in React world.
React's core concept was excellent. It solved many of the issues with previous view libraries. What React turned into over the years is problematic, accumulating bad design decisions until it became the monster that it is.
The way React Native works is an example of how good the original React concept still is. It has nothing to do with HTML, it's made of cross-platform view components. It has similar ergonomics as the web version, like one-way data flow, immediate-mode rendering, view as function of state.
It's true that React has passed its peak usefulness (relative to the problems it brings), in a long tail of decline for the next decade. Newer better view libraries are being created and adopted by the community. Some of them will eventually overtake React as the next standard tool. But they all learned from React's lessons, because it really did push forward the evolution of web development.
While you might be right.
It seems like you didn't notice this was about React Native, the cross platform mobile app framework.
So "just write plain html" isn't a valid alternative unless you want to write a Progressive Web App instead. Which means you:
- Forego the App Store and need to ask users to bookmark your website
- Loose ease of access to device features (cameras, sensors, push notifications)
Ruby on Rails' Hotwire Native is basically augmented "plain HTML", and requires practically zero effort for Android and iPhone support.
How genuine are you being here? Because I've tried doing native apps using LiveView Native and it is ROUGH. The reason I ask is because I would consider using Hotwire Native for a future project if it really is good.
Yeah but the UI is webviews. It's not as native as React Native.
You likely mean "small projects". No way you see teams do better with plain old HTML + minimal JS on anything of substantial complexity. It was hell to organize code for a web app without a framework using nothing or jQuery.
When I use React / Next.js on Web projects, is not because I personaly like them, but because I have been part of projects using SaaS products whose SDKs are only available alongside those stacks.
Its easy to say now, if react creators knew everything that we know they would've made different choices, but at its time it was a breakthrough compared to other approaches.
I don't really see that, aside from the 1 to 2 jump, angular has been very steady and stable in their approach and and upgrades.