Show HN: One – A new React framework unifying web, native and local-first (onestack.dev)
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.
267 comments
[ 3.4 ms ] story [ 288 ms ] threadI 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...
Basically Zero will run in the browser and has it's own server which will exist next your database. So you can do all your database management through Rails and there is a section about Custom Mutators where if you need to pipe data through to AR to have it run callbacks, that is possible.
Also - One is not tied to Zero, you can use One for just about any web/native project and bring any libraries you want, we just are making it nice if you follow a certain path.
> 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.
[1]: https://blog.expo.dev/expo-sdk-49-c6d398cdf740
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.
I think there's 2 distinct use cases here: a) a classic "web-site" that people "visit", interact with and leave b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state
Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there. I'd aim at 100 ms page loading time (without initial network delay).
Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top". This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps.
And about people re-implementing TCP: I first thought you referred to QUIC. Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).
WebSockets would like a word
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?
Literally every language with support for modules that extend across files has some form of dependency management. Even C -- simple as it is -- has headers and source files which separate interface from implementation. Some languages go further (e.g. Ruby), and have far more developed, standard systems of version management built right in -- rubygems will do the graph analysis of your module includes, resolve dependency cycles, enforce versioning, and so on. Python is a total mess when it comes to high-level dependency management, but only because it offers 3-4 different "standard" ways of doing it!
Notably, Javascript didn't even have the the export or import keywords until ES6 (2015). It had literally no support for even the primitive, C-like version of the idea, and there were multiple competing implementations of it, from Node, to CommonJS, to RequireJS, Webpack, Babel and so on. But you still can't get rid of webpack, though -- JS has no built-in notion of minification or tree pruning, so that's all still implemented via a panoply of third-party tools.
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.
How do you know?
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.
The DB is smart enough to understand if a query can be fully or partially resolved client side based on what other queries have already been synced.
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...
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.
[1] https://github.com/tomtheisen/mutraction
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 prefer VueJS or Svelte much more, but unfortunately due to its popularity I am stuck with React.
And the tag closing semantics are slightly different from HTML. And approximately no one understands how HTML tag closing works anymore because of it.
In contrast, I can't understand how magic attributes on html nodes is more clear. What's your take on that?
For example in Vue's introduction:
The completely made up "@click" makes no sense outside of Vue. "count++" is a string that stands for real programming code? So we're making up pseudo code now. And the {{}} interpolation isn't real either, so it's not actually an HTML <template>Using native HTML nodes, templates, and tags makes it seem standard. This is the worst learning curve: the bait and switch vs being clear—albeit intense—that the component is 100% a JS programming env that yields the UI.
React component is not the UI it's a JS function that yields the UI.
I have done html templating syntax in many different languages and frameworks starting with Laravel Blade and it always felt much better than the native syntax of doing that e.g. with PHP.
I don't think it ks a worthwhile feature to have everything strictly JS. Use different tools as they are appropriate, why hinder yourself.
Ultimately there are some very frequent and limited patterns in defining interactive html elements so best to use the syntax that has the highest meaning to noise ratio.
The combination of useState, stateValue, setStateValue are simply unnecessary boilerplate that makes important things like the state variable itself hidden in a sea of noise.
> React component is not the UI it's a JS function that yields the UI
I don't think that is a good philosophy at all. The code should be about clarity not around an odd dogma about having to be a JS function that yields the UI. It in my view is a misplaced enthusiasm for something that really doesn't matter, but will hinder things since you have to constantly work and hack around those self posed arbitrary restrictions.
The "everything is JS" and "JS yields the UI" is 100% based on the constraints of the runtime.
Modern UIs need browser APIs, events, DOM management, and stying. We MUST use HTML/CSS/JS. My take is "everything in JS" _in this context_ is more reasonable, more integrated, and ultimately more intuitive, not that it's simple or easy, but that we're stuck with the runtime, we're going to need these all to integrate with one another, let's be clear on in the integration interfaces.
Not saying that it's bad necessarily, but there are pros and cons to the JSX approach and the template approach (a lá Vue, or actually Mustache that Vue's template syntax partly comes from).
I think what's easiest/best comes down to: 1. Your background (ppl coming from BE tend to prefer to stay in a more full-blown programming language, people with a HTML/CSS background tend to prefer the template approach. 2. How junior you are. Generally people tend to say that React has more of a learning curve then Vue. 3. What your needs are. Full-blown web apps? Simple small enhancements of static websites? How much detailed/special control do you need or your components HTML output, etc.
PS. @click is actually very similar to the native click attribute. Furthermore, React has className as a special attribute that's definitely on a similar level same-but-not-really.
The special React-ism that bugs me the most in this area is that React elements map the "change" event to "input". There's no way to handle "change" without getting a ref and wiring it up yourself. As a consequence, most developers don't seem to remember or ever knew what "change" actually is.