One is a React framework that does two things differently in hopes of simplifying how we build websites and apps:
1. It unifies React Native and React web with typed file system routing by making Vite able to serve RN. This lets you share (or diverge) your code in a simpler way for cross-platform apps.
2. We've partnered with Zero (https://zerosync.dev) to make local-first work well. We've been building a solution in One that makes Zero supporting server rendering, without waterfalls, and with seamless server/client handoff.
---
Honestly - I'm a bit hesitant to post One here.
HN has really soured on frontend/frameworks. And I get it. We've collectively complicated the hell out of things.
That's why I decided to build One. 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).
I worked at Uniswap and built Tamagui and so spent a lot of time building cross-platform apps that share code. Uniswap is built on Tamagui and I think proves you can make really high quality UX while sharing a lot of code - but it's insanely hard and requires a huge team. My goal with One is to make what is now possible but hard dramatically easier.
And I think the path to there goes through local-first, because it makes building super responsive apps much, much simpler, and Zero is the first library to actually pull it off in a way that doesn't bloat your bundle or have very limiting constraints.
I happened to live down the street from Aaron, one of the founders of Zero, in our tiny town in Hawaii. We talked a lot about Zero over the last couple years, and I found it really admirable how he consistently chose the "harder but better" path in building it. It really shaped into something incredible, and that convinced me to actually launch One, which at the time was more of an experiment.
I can see a lot of potential criticism - do we need yet another framework, this is too shiny and vaporware-y, this is just more complexity and abstraction, etc. Happy to respond to those comments if they come.
I'm just building out something that I've been wanting for a long time. Opinionated enough to let me move fast like Rails, but leaning on the great work of team Zero so that we don't end up with the scope creep of Meteor. And honestly, it's just really fun to hack on.
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.
Tamagui Takeout is a paid fullstack starter kit based on Tamagui (and Drizzle): https://tamagui.dev/takeout
They’ve started a rewrite of Takeout to One (Zero instead of Drizzle, etc.), and are grandfathering in all existing users (also those who start using it before the rewrite is released). More in thread:
https://x.com/tamagui_js/status/1841985327139098649
PS: I’m happy you found use of my blog post about the various tech strategies/choices when making a cross-platform app. :)
And thanks for adding the context on Takeout.
more context: https://www.youtube.com/watch?v=aWfYxg-Ypm4
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?
Well, at least once Zero is out. It won't have all the stuff Rails has for now, just the data solution (and we have a drizzle-to-zero adapter and setup we'll be recommending as well so you get schema/migrations).
So yea we want to bring the ethos of Rails to JS, but do it in a way that isn't NIH.
Explained a bit more here: https://onestack.dev/docs/introduction#our-full-stack-philos...
> 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.
So yes, the fact One use one single bundler from the start is nice win.
Also, looking at the direction Expo is taking, I believe they will eventually introduce SSR mode to Expo Router in the future.
Haven't looked at One yet, I'm holding out hope that it doesn't actually use React.
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!
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.
High level: https://onestack.dev/docs/introduction
Honestly the demo video is the best if you want a lot of code examples:
https://www.youtube.com/watch?v=ZJH4bKkwo90
But you've reminded me that I need to add a clear code example to the homepage.
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.
And if you can include this info: npx envinfo --system --npmPackages --binaries --browsers
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.
On React Native then One uses Expo, which is used in a lot of top tier and complex apps.
For more about the CTO type decision of going with 3 apps or 1, and the various options from RN, Flutter, Ionic Capacitor, NativeScript (etc.) then you’ll likely find my comprehensive blog post helpful:
https://magnemg.eu/the-different-tech-strategies-for-buildin...
If the app is simple, as many of the top tier apps are, I'd recommend flutter/RN/One* in a heartbeat. However, many apps are also quite complex, and should be built for the target platforms to provide a great user experience.
However, as even Airbnb found out, they're spending half their time writing bridge code to make things work.
At that point I'd almost argue you're better off having 3 apps. FWIW I used to work at a tech unicorn that had a great exit, and we had native applications. We did some research projects to see if we could leverage RN and Flutter but found the headache was not worth it.
Most of the libraries out there are low quality and without any tests let alone good documentation. That means we would most likely have to write our own (which we did).
Then, we found out the underlying abstraction layer (flutter/RN) had its own set of issues. Then we started maintaining bridge code for those.. as I mentioned basic interactions were broken, which you'd think are the lowest hanging fruit.
Uniswap I think proves it can be done, try out their apps. They still can improve, and I need them to upgrade tamagui and turn on the optimizing compiler because it's gotten like 60% faster in latest releases, but basically - we've come a long way, I'm long RN.
Speaking with my experience with Expo, this kind of framework works great for their purpose in enabling a small team of engineers working closely with products and business analyst to deliver features as fast as possible.
From business perspective, turns out not everything needs to be a blazing fast native code. That means if you can write code once and it will run in other platforms with minimal changes, you save some time. More time to ship more features!
In a zero sum market where every extra features could bring more customers, this could become important factor when picking the tech stack. More so when you're running on investors money and need to make profit ASAP.
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.
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.
Once you accept that 1) JS and the ecosystem has a ton of shortcomings, 2) JS isn't going to be replaced on the web for front-end for a while, then I think you can move on and think about things more objectively.
I like this project because at this point in 2024, it feels like it should be easier to build and deploy cross platform web/mobile apps (I blame Apple for PWA not taking off). React is not my cup of tea, but if One's mission pans out, then I'd use it to streamline my workflow if I were building across web and mobile.
I'd personally prefer PWAs and Apple making it easier to install PWAs as apps since that would make it even easier and more streamlined from a DX perspective. Right now, we all have to jump through these hoops and build this extraneous tooling and infrastructure because of Apple's resistance on installable web apps.
What I am saying is that the paradigms of "modern" front-end development are all wrong. Don't re-invent basic functionalities of the browser. Don't try to turn the web server connection into a glorified database (either by implementing bastardized HTTP-SQL, or by treating the socket as a bidirectional JSON channel). Accept that server-side generation of HTML is fundamental to the medium. Embrace progressive enhancement. I could go on.
None of these things requires that you drop JS as your language. If you wanted to build Rails in JS, you totally could [2].
If I had to draw a crude metaphor, the state of web development today would be as if an entirely new generation of engineers decided that TCP was wrong because most stacks are implemented in C, and therefore re-created bad versions of handshakes, etc. by writing a new protocol on top of UDP in Javascript. It's not the language, it's the architecture.
[1] Though you absolutely should consider that JS isn't perhaps isn't a great language for most forms of development, and be open to, you know...using better tools when they're available, instead of trying to do everything in the lowest common denominator, while patching over all of the stuff you're missing with gobs and gobs of bad libraries.
[2] Though again, why would you want to? I submit that the core cognitive dissonance here is that as soon as you accept that these "modern" paradigms are wrong, you quickly conclude that Javascript is a net burden on your development process. But sure, if you really like it for some reason, then great. You can use it.
javascript lacked (lacks?) even the basics of a practical programming language -- real packages and the like
you're re-inventing wheels (like routing, rendering, a request/response paradigm) that the browser does for you, for free.
for the vast majority of CRUD websites
However, static sites are by definition not CRUD sites and yes I would guess most HN web devs make CRUD sites. And I would submit that in 2024 there is still not a rails-level happy path for doing that in ts (though Redwood is trying).
The very fact that you cite Typescript (itself a hack built on top of Javascript to make up for its deficiencies), and npm (a third-party packaging system...since, you know...JS doesn't/didn't have one), is just emphasizing my point.
Setting aside the goodness or badness of either of these things, you're so immersed in the complexity of all of the hacks that you don't even see it anymore. It's the old joke about the fish and water.
Imagine a world where packages and types were a built-in, first-class feature of the language...oh wait.
Also, more importantly by far: can you point me to what language(s) you’re talking about? C++ doesn’t seem to have a “built in” dependency manager, just vcpkg and Conan. Python has poetry, anaconda, and pip, the latter of which is run by the Python nonprofit — but something tells me that’s not the old school classic you’re referencing lol. Java has ant, gradle, and Maven, none of which seem official. I guess we’re talking about ruby, since their manager is published by a group that claims ownership of the language (https://rubycentral.org/)?
Basically I’m still not sure what im missing. I very much might be a fish in water, and I am a newbie to all of this, relatively! But I’ve never once noticed a real difference in the languages I’ve developed in professionally (those mentioned above, minus ruby) so I’m not sure what ruby’s being more “first-class” gets me. At a certain point, if your build system is setup using boilerplate, then the two steps are 1. Download package, 2. Import package into relevant file and start calling its members. What part of that can be improved?
95% of apps people glue together are quite bad so i get that some people see it as a lost cause, but i could never go back, it's clearly better to me but only if you do manage to have the time to put together a great stack.
once zero is released i'd be interested to see your opinion of trying it out.
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
2. Tamagui is bootstrapped and makes some money, we haven't raised and aren't sure yet if we will. But we may need to if we want to compete long-term against well funded competition. Honestly web works really well, we have a few sites in production already. Native works pretty decent but we just want to add a lot of tests and get a more apps into the app store before we call it stable. I'd estimate 6 months it'll be stable, but you can probably reliably deploy an app within 3.
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.
* 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.
It's just not a 20-something with the energy, nor interest, to be out every weekend til 2am
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.
can't really work around that, perhaps there could be a mode where if you give your browser FS permissions or something it can make use of more storage.
if you were building an electron app for example you could do this too more easily.
i think one thing to understand is local-first !== local-only. can always use servers for things that make sense.
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)?
[1] https://2023.stateofjs.com/en-US/libraries/front-end-framewo...
* Components don't have exposed identities, but component state is based on identity. Secretly they're fibers.
* Everything is treated as if it's immutable. Reference equality is used to infer no changes. Working with array-based state, or almost anything really, is awkward and unnecessarily verbose. Spread all the things.
* The rules of hooks. These are just implementation constraints based on the rest of the design decisions of react.
* You can't use symbols as keys. This is small, but particularly irksome for me.
* The smallest unit of UI change is the component render function.
* Effect dependencies need to be listed explicitly.
Immutability is a great callout; frontend ecosystem is quite divisive on it.
For my flavor, as React exploded, redux and the advanced state management frameworks came and made everything bananas[1]. "It solves real problems for advanced apps"; maybe but I could never shake that these problems are self-inflicted.
There's a mathematical functional purity that's nerd-snipe worthy; but reactivity with mutation observers just seems to model the real world of UIs better.
Anyway, https://mobx.js.org/README.html is the exact opposite take: mutate your state! Subscribe to changes to your heart's content.
The divisiveness is real, it's what makes staying up to date exhausting.
[1] Come on, no one seriously thinks "bind action creators" made intuitive, ergonomic sense.
i loved react when it came out, it was magnitude improvement for rapid prototyping. jsx as an idea seems ridiculous, but in practice, might as well make everything js and use the programming language's full power—otherwise you get pseudo-code-in-html. html directives will never be a full programming language, I can't understand why frameworks go down this path, repeatedly!
"fuck it, everything is javascript" is react's great insight, for interactive applications.
The frontend ecosystem overall, i find very exhausting, yes. but that's not on react.
What don't you like about it?
I'd argue that jsx was react's great insight. But maybe that's the same thing. Anyway yes. But unfortunately, you can't use react without using the rest of its insights, such as all data must be immutable, and DOM updates are based on reconciliation.
> The frontend ecosystem overall, i find very exhausting, yes. but that's not on react.
That's true. React has more than enough of its own problems though.
I’ll give this a shot and subbed to the zerosync mailing list :)
Your framework preserves the status quo rather than simplifying it.
The iPhone is more “complicated” than an old blackberry, in a way. It’s also way simpler and more useful.
Complicated has nothing to do with amount of features, abstractions, or tech choices. It’s all in the thought and effort put into the final product.
It is harder to pull off with more layers, I hope we can make it work.
Me and my team have been working on a new Web Draw-first IDE that we're going to launch in a few weeks. And I just sent this thread to my engineering team demanding that they swiftly integrate One into our web draw, or they will walk the board! Just kidding. We're not really pirates. Anyway, amazing work, looking forward to using it for many projects here!!!
Can't help but roll my eyes here
And the solution, of course, is a framework on top of a framework on top of JS and the DOM. OK, maybe I'm being too harsh.
1. Write lots of code to deal with the complicated problems
2. Use a framework that abstracts around these problems and solves some of them for you
3. Cut features from your app
This framework helps you with approach 2. If you don't want to use it, you are welcome to use approaches 1 or 3.
This community has been central to the idea of local-first: https://localfirstweb.dev/
The term local-first was coined by Martin Kleppmann et al in this essay: https://www.inkandswitch.com/local-first/
In the context of Web Apps, I suppose this means that data is first stored to some sort of in-browser storage and synced to remote in the background.
Don’t get me wrong, that’s super cool - but if you’re going to claim it’s local first software, I want to see the principles of local first software at play. And I don’t think Zero delivers that - at least as I understand it from its website.
Like, “the network is optional” and “the long now” and “you (the user) retains ultimate control”. It just looks like an excellent server sync system with client side caching. What if the data I need isn’t in the cache? What happens when I edit things offline then come online later? What happens if the company shuts down and the server gets turned off permanently? Will the app still work?
Local first software can handle these cases too.
First, is this a whole new router? Is it based on expo-router, or is it sitting on top of react-navigation? Maybe all new with react-native-screens as a foundation?
As far as Vite goes, I assume this is only on the web? Metro is still be used on the native side? If true any reason why you’re not using metro on the web as well (I’m kinda partial to having all platforms as similar as possible, tooling wise)?
I suppose I should also ask how expo fits into this all…meta framework on top of expo or something “all new” on stock react native?
I’m also not really sure what problem this is solving. We already have the ability to create android and iOS apps based on one source code to react native. So what’s the additional benefit here?