Love this the most:
> almost all features can be built completely client-side, with no need for new server-side APIs
Any thoughts on a desktop target for this (e.g Electron/or Webview Desktop target)?
I first encountered Takeout about a year ago while experimenting with cross-platform development after reading this blog post: The Different Tech Strategies for Building a Cross-Platform App (https://magnemg.eu/the-different-tech-strategies-for-buildin...)
At work, we urgently needed an iOS app to enable push notifications for our logistics app, but our frontend was web-only and built with React/Next.js. Since the codebase was already several years old with many screens, we decided to port it to Capacitor, which led us to adopt a stack with Next.js and Capacitor (https://github.com/RobSchilderr/nextjs-native-starter).
However, once we began working with Capacitor, we ran into numerous issues. Dealing with the iOS keyboard and Safari WebView was almost impossible with famous scrolling issues, and Android’s Chrome WebView also suffered from poor performance (https://github.com/ionic-team/capacitor/discussions/3899).
This experience pushed me to switch to Expo with Solito and Tamagui, and the new stack has been a game changer. The support from Nate and the Tamagui team has been outstanding. Also Expo and EAS has been working flawlessly.
Now, with One, cross platform development is entering a new phase which address the final challenges of cross-platform development. Sharing code with Expo and Tamagui used to be manageable only for those familiar with cross-platform solutions, but now it’s becoming accessible to everyone. I bet it will be easier for new folks to understand how to work with Expo and Tamagui.
Combine that with local-first, and small teams will be able to build high-performance applications across three platforms using just one simple codebase quickly.
I know the project is still in beta, but do you have some thoughts already around testing a One app? I watched the intro video but it didn't mention any.
Since the native is powered by RN, maybe unit test will be using jest? Or vitest should be used because the app bundler is already using vite? And what about testing platform specific code?
Asking this because "unified" framework like One or Expo usually only covers 80% of the development process, and the remaining 20% part like testing need custom solutions.
You don't know me and I don't know you, but I know of you through your work on Tamagui. Very excited to see this coming from someone with your kind of experience – we desperately need something to challenge Expo and hopefully truly bridge the native/web divide in a way that actually works, without leaky abstractions everywhere.
Very hopeful that your experience and knowledge in the space will get us there – thank you for your efforts! I will be checking this out in earnest as soon as possible. Very exciting!
As a long time Rails dev who has primarily worked in stacks of Rails APIs and React UIs, does One fit into this category?
I'm excited about local first, but I haven't played around with any of the existing solutions because I was hoping to get my hands dirty with Zero. Thus I come from a point of ignorance. Are there any limitations? Will Zero need adapters to different frameworks or does it hook directly into your running postgres instance so the backend doesn't matter?
I have a super basic reason and use case. I've been using spliit.app (https://github.com/spliit-app/spliit) while traveling and having very slow internet. The app is amazing with fast internet but absolutely doesn't work well with spotty connections. It often makes two entries if I tap submit twice because I think the request failed after so long and it's really slow to switch pages. The design is generally great and works well but I want to add much better offline support. Maybe it means forking it and doing CRDTs and something like One. I haven't looked at their codebase much yet but I'm hopeful some improvements can be made!
Anyways thanks for the great work with your framework and I really look forward to trying it out in the future.
It generated 200 lines of output, but in the end, didn't end up doing anything that can run. I'm not putting any effort into debugging this, but let me know if you want the output from the session somewhere.
The local-first angle is a compelling difference too.
My wishlist as you build this out:
- email / messaging support
- background jobs / queues / workers
- postgres / support
- auth
- testing
- "one man framework" design goal... focus on how this enables a tiny team to build a company and avoid the common TS tarpits where you're thinking about the stack more than the customer problem or paying for a SaaS spiderweb that is very hard to test, monitor, reason about. For me, that tight integration is what made and continues to make rails valuable. Of course, this stuff should not be first-party / developed by you, but having an omakase set of tools for building a product company with a happy path for composing it all is really lacking in the most popular js frameworks.
Edit:
Just read the "Our Full-Stack Philosophy" section and realized you're not actually going for a rails that handles modeling all the business logic stuff. Seems more like a local-first next alternative. Still very cool and good luck, but I guess disregard most of the wishlist.
Serious question though. Who is this for?
I’ve done mobile app dev in all the popular ways - native, flutter, and react native.
Both flutter and react native bring up a ton of issues anytime the app becomes more complex than rendering a list with some detail pages.
I wrote so much custom code bridging gaps.
Swift and Kotlin make native dev so easy and straightforward.
With flutter (which I have the most experience with along with native) I had to anyway write bridge code for handling both platforms.
I think considering how easy it is to write APIs, isn’t it better to just use native for both platforms to deliver a fantastic user experience built on those APIs?
Is this another project that’s suitable for simple apps or will it actually be useful for very complex UIs and deep device integration. I mean flutter still has open issues around scroll to top breaking which I fixed with custom bridge code. It’s impossible to get issues addressed.
Like say it takes 3 days to make a complex UI. Then a week or more to write and test the bridge code. I’d rather take 6 days writing platform appropriate code and save a day or more of pain. And when that breaks fix it. Over time this adds up to a lot of saved time I think.
Yes.
> I loved Rails, it made me as a young developer able to finally realize way more ambitious projects than I'd ever done before. I also liked the promise (not implementation) of Meteor - it felt like the clear future, I guess just a bit too early (and a bit too scope-creeped).
Meteor and Rails were fundamentally incompatible views of the world, and the root of the "complicated the hell out of things" problem is that the Meteor approach wasn't practical for the vast majority of web development projects.
Once you've decided to build everything in the front end and turn the server channel into a glorified database connection, you've created a nightmare for yourself on multiple levels. Setting aside the fact that javascript lacked (lacks?) even the basics of a practical programming language -- real packages and dependency management and the like, all of which needed to be implemented via a panoply of non-standard libraries that have been subsequently re-written every 2.5 weeks -- you're re-inventing wheels (like routing, rendering, cacheing and a request/response paradigm) that the browser does for you, for free. Maybe that's worth it in a few niche cases (say, making a web-based code editor), but for the vast majority of CRUD websites, you're just swimming upstream.
Spinning languages and libraries misses the point that the problem is fundamental to the approach. I guess what I'm saying is: lean into your first instinct. It's all too complex. Go back to the root of what makes Rails -- traditional web development, really -- good.
1. Why have a React Native clone of your SPA instead of just doing a PWA? Does it provide some technical benefit (better offline local data persistence, maybe?) or is it just to get your site advertised on the App Store? Surely all the device APIs for movement, multitouch, etc. are supported on mobile browsers? This has been bothering me for a while, so perhaps too broad of a question.
2. What’s the rough timeline and funding look like for this? In my eyes this is a solution to, like, all complex web apps ever, so I was shocked to see just a few developers. I know you acknowledge some bugs in the Native implementation, but besides that, do you feel like this could be used for a data intensive Postgres-backed TS application today with minimal chances of bugs, or is it still a bit more experimental? I guess I’m looking for a bit of clarification on the intended meaning of “production ready”, since it seems so damn ambitious.
Either way, Godspeed! Your website is gorgeous, and the whole project is insanely up my alley. Plus ‘npx one’ is just slick as hell
> What is the added value of using it over just Expo?
My answer:
The added value of One is crossplatform compatibility with SSR, and HMR, all using Vite as the single bundler on all platforms.
Nate baked in his vxrn.dev project to get off of Metro and forked Expo Router to do that.
Since Expo Web has a large bundle size, requires NextJS for SSR, Solito for unified filesystem routing, and 2 bundlers: Metro as a bundler on RN plus a separate bundler like Webpack for web.
With One then all of that is integrated. With Zero as the optional data sync engine.
Then the Introduction page states "One is a React framework that aims to make full stack development as simple as possible"
But there is no mention of 'what' 'I' 'am' 'getting' 'myself 'into' 'by' 'using' 'One' ...
If I click on 'Get Started' it takes me to the 'Installation' page. :(
Dude, what the fuck, I shouldn't have to install the thing to get a description of it.
* Overall, not bad. Using React Native is far better than trying to mimic platform UI in the web, which is always terrible. * When tapping on an item on the “Feed”, the transition is made to the details _and then_ the navigation bar has a sudden title transition. This is weird. * The button in the upper left to switch between light and dark mode is nice but it should default to the system setting. It did not for me. * The Notifications tab content isn’t scrollable at all on my phone. Seems like a bug. * If you tap on an item in Notifications you navigate deeper in, but when you hit back you are back on the Feed tab.
Coming from native app development, it has the normal uncanny valley feeling that React Native gives off but for normal users they may not notice it as much.