I agree with you. I don't think LLMs magically solve the problem that comes with writing twice.
Even if they were to write for two platforms, they'd likely want to have a whole bunch of business & state management logic that would be shared between the two with the native part being a thin platform layer.
It seems like a mostly shared codebase (reglardless of specific tech choice) would let them get precisely the end user UX they care about. Both for performance and capability.
Not saying they should use React Native but maintaining two large apps and using LLMs to keep them in sync seems far worse than many other options.
Besides API features, it won't require downloading 0.5 GB of web browser in order to run.
Sure, you can make it smaller, but how many companies actually do this?
Sure, you can make it faster, but how many companies actually do this? Accountants and product managers don't care about speed or size -- that's a user problem.
Judging by the app sizes I download (and try to avoid), few companies really care about the user experience as long as the basic feature is checked off.
I worked at a company that provided an unnecessary and heavy FE framework (original devs didn't know what they were doing and "just got it out there"). Most of the target audience used used older PCs, and thus slower and memory limited. Some pages required multiple GB of browser memory. We've had this problem for decades because devs usually have well spec'd computers.
I happen to work on a product that is built for accountants. You would not believe how slow these apps are and all they do is display forms!
I believe customers do care about performance even in these B2B industries.
But it feels like they sink into some form of learned helplessness. We were interviewing our customers to learn how to build a better PDF viewer for them. Their biggest complaint had about Adobe Acrobat? Too slow!
If the entire page is rendered on the server, the information required to do so is presumably reasonably approximate (same datacenter). If most of the page is rendered on the client, the information needs to be pulled in from arbitrary physical distances.
At some point the engineering really is this simple.
Which is also, or at least has also been a culture thing, because of the
"Oh no, we can't possibly do the computation of all that on our backend! Yikes! Let that run on every single client instead! Let users spend their own compute over and over."
Is it? I looked at the source but it doesn't appear to be react. It has a React API but also a "vanilla js" API and when I looked at the code it seems to be doing everything by hand:
The history of Elixir has its roots in Jose learning Erlang, loving the properties BEAM, but wanting a different language.
All of the principles of the BEAM still exist in Elixir. And a lot of the Elixir semantics come from Erlang, precisely because Jose studied Erlang and the BEAM.
My biggest complaint about ChatGPT is how slow their interface is when the conversations get log. This is surprising to me given that it's just rendering chats.
It's not enough to turn me off using it, but I do wish they prioritized improving their interface.
Even if they were to write for two platforms, they'd likely want to have a whole bunch of business & state management logic that would be shared between the two with the native part being a thin platform layer.
It seems like a mostly shared codebase (reglardless of specific tech choice) would let them get precisely the end user UX they care about. Both for performance and capability.
Not saying they should use React Native but maintaining two large apps and using LLMs to keep them in sync seems far worse than many other options.
reply