Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: One – A new React framework unifying web, native and local-first (onestack.dev)
506 points by nwienert 68 days ago | hide | past | favorite | 254 comments
Hey HN, I'm Nate, the creator of Tamagui.

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'm definitely getting too old. Back when I was just learning Backbonejs, I gulped up every single framework that came out, tried them all, every language, every variation, server side, client side, mobile, hybrid.

In the end, after all that journey, I settled into Laravel Backend and Vue3. Every app I create now is just a copy-and-paste of what I've done before. The tech stack disappears into the background and I try to actually build the features that I want to build.

I'm definitely old because I see this great work called "one" and I look at the video and I get immediatey turned off by so many "new things". It's me - definitely me. It's maybe for a different generation of devs.


I've reduced my stack to C#, raw HttpContext middleware and string interpolation (aka poor man's PHP). Multipart form posts and full page reloads are my bread and butter these days. I'll still reach for Ajax and websockets if need be, but it's not the default. The entire site doesn't have to be one gigantic fucking SPA. Targeted application of the distracting shiny tech will take you so much further.

The problems themselves are way more interesting to me now. I get very upset when the tech gets in the way. I'll happily pay for licenses, fees, royalties, etc to clear the path.

It wasn't always this way though. The first decade of my career I didn't really care for the problems I was working on, so theorycrafting the tools all day was a nice respite. Coming up with principled clean architectures is a lot easier when you don't have to answer directly to the customer.


Programmers love programming for other programmers. We most respect the writers of operating systems and languages. We hold them as having the deepest wisdom. But really, it's just because their target audience is us.

Doing stuff for actual customers is seen as grunt work. Their interests aren't ours, and we can't share what we learn with our peers.

So we end up reinventing the wheel just because it's more fun. And it is fun, and that's ok. Sometimes it's even useful. You just have to figure out what your real goal is, and not spend your whole life polishing your craft for its own sake.


Nah you just realized that CRUD has been the same since the 90s and that everything that gets reinvented isn't actually in the path between the problem and the solution, but pure architectural masturbation that wouldn't be necessary if web devs didn't come up with new designs for the wheel every 5 minutes.

You don't see the same bs in other areas of computer science.


> You don't see the same bs in other areas of computer science.

It's not like databases haven't been reinvented every time there's a new fancy startup.

MySQL the OG "but web scale" DB (even with InnoDB because consistency level set to - you guessed it - "web scale"), then all the NoSQL kids because of course "web scale", then SSD/NAND write-amplification and LSM and LevelDB and whatnot and nowadays RocksDB. And there's the memcached/Redis/Valkey.

It's not like networking is not doing the same. HTTP2, HTTP3. DNS over HTTPS, how amazing it is to establish a TLS connection just to send a base64 encoded DNS question. WTF. And there's a myriad things in eBPF land, all the kubernetes-related CNI providers, and during the OpenStack years we had new overlay networks every year (VXLAN, Geneve, and I forgot the name of the other stuff), and if you go a bit closer to datacenter networking and peek into the firehose of 802.1 of new protocols you'll drown from the constant buzz over which variation of the same thing is the obviously best one! (I still remember when people started to realize that maybe there's a better and cheaper way to avoid VLAN and spanning tree problems than "just buy Cisco forever and don't forget to enable rapid STP (802.1w)" ... and then for a while there was MSTP (802.1s), TRILL, and SPB (802.1aq) and now it's managed networks all the way down, I guess)


While I agree with you in general I have to disagree about HTTP3. The reason we got it is because of middleboxes preventing the adoption of SCTP. And SCTP and QUIC solve very real needs in a good way, things which we could not solve with TCP.

Maybe Google instead should have used their politucsl clout to push for Http over SCTP. But it is not like there was a suitable predecessor to HTTP3.


One, Zero, NextJS and so on all solve real problems on the level similar to what SCTP/QUIC does. That's my point. The seemingly endless churn has very good reasons. But of course the cost of the churn is still real too.


I too am getting older (nearing 40), but I attribute this in myself to just improved pattern recognition with the now two decades plus of experience I’ve had. I don’t get excited by most new frameworks because I’ve seen it before in a shape similar enough to not waste energy on it, and know much quicker whether it’s practical for my uses or not.


Being around the same age as you, I agree. But also, there's a slim line between this and becoming a jaded old asshole. Very slim. I'm noticing it happening to friends of my age.

I'm trying to work to ensure that doesn't happen to me. What I've realized is that I need to take breaks - of at least months or even years - and come back with fresh eyes to the things I know well.

And I need find new things to be a beginner at so that I don't forget what that's like. I'm trying and mostly failing to learn guitar over the past year. I've taken up resistance training in a semi-serious manner in the last few months, and that's going much better than the guitar.


I think it just means I don’t jump on things any more. Certainly not if they claim to be the one true solution.

If it’s still around 5 years down the line, it might be worth investigating.


This is how I look at things. I’ll let other people dance on the bleeding edge. I know enough to get my job done and if I spend the time to bring something new into the fold, I want it to be worth my time, being used for the next 5-10 years, not 5-10 months.

Chasing trends in web dev looks exhausting.


I keep myself in check by exploring software -- and most things in life -- from a first-principles perspective.

Last few weeks I've been writing a software 3D renderer from scratch not because there isn't countless of great engines out there ready to use, but because I need to understand the base principles of 3D rendering much better than I did before I tackle the technologies that have presumptions and bias towards specific problems baked in.

For my intended use case, my own 3D software blitter in JS is probably going to be good enough, but if it isn't, at least I know why it didn't work for me and I can make a much more informed choice.

This is how I approach programming as a senior developer at my job as well. And I find that asking the right questions and reframing problems before looking for technologies to solve them is one of the key benefits of age and experience. It's also why the last few places have hired me, specifically because I reframe questions and break down assumptions before I start typing away at the keyboard.


I'll use whatever the client wants me to, but for my own projects, it's PHP, htmx, Postgres, Shoelace, and plain HTML and JS for everything else.

It's 10× faster than in any modern approach, there's no build step, I can sync it to any server and it just runs, the code is simple, the end result is snappy, it loads immediately, it has great UX, and I don't need to scale to a million users anyway.


40+; python sever side rendering + sprinkels htmx where needed; all works is fast and yes you can post forms without JS :D edit: and is still use bootstrap css because it works


40+ as well; Django server side rendering and larger doses of React where we need more interactivity; but absolutely no SPA, client-side routing, etc. It's too much. And yes, bootstrap CSS (3.3.7 even!) because it still works.


40-1; I use Rust for almost everything. For smaller projects I always test SPA approaches (with Rust and WASM of course), but for long-lasting important projects I would always go for boring, reliable, server-side rendering. Other client-side things remain optional (keyword “Progressive Enhancement”).


I don't think it's an age thing. I'm 22 and I agree that I can't be bothered with learning javascript frameworks. There are too many other things to learn in our limited lives


Same except for me it’s Laravel and Livewire. Not having to build a separate app on the frontend and backend dramatically simplifies development. And Livewire now has a proper component library (Flux).


custom php backend and vite with vanilla ts / fetch mostly here.

It's fast, it's secure, i implement everything myself -> it's flexible.

It's great that vite does the bundling, but it's the only job it does.

My page is now down to 2 ms response time, i don't see a reason to go back to the symfony/laravel days.


I'm familiar with the feeling of "old, not keeping up", but rest assured, there's also other very important factors at play here:

Simply put, stuff gets much more much quicker compared to 5, 10, 15 years ago.

Not being quite able to keep up with any and all frameworks popping up and being overloaded with the size and speed of current web ecosystem is a struggle for younger peers aswell, and the days of "you even COULD check out every other new framework" are long, long gone


has nothing to do with your age even at early 20s I was sick and tired of constant new frameworks in web dev.


Spring Boot, Thymeleaf and vanilla HTML,CSS and JS here. I do not feel I am missing out on anything, and it is simple and easy to maintain. For dynamic content I just implement websocket and models with publish subscribe pattern.


> I'm definitely getting too old

Is it really an age thing or actually an experience thing? I see the same sentiment in a lot (though not all) of the replies here and I think the fatigue that people feel from announcements of new tools is really down to having seen the same promises of 'simpler' and 'better' before in hundreds of other tools, with none of them ever really playing out or lasting.

The simple answer as to why these tools don't last is that everything builds on and improves on everything else, but genuine 'improvement' is hard to quantify here and what we really have is changing abstractions, with the underlying contraints (browser environment) not changing as quickly due to the need for standardisation.

Web/cloud in particular is particular bad for churn in 'tools'. It seems surprising, as open source projects with no expectation for monetisation don't have a financial incentive to succeed, only the personal satisfaction of tool development and perhaps (cynically) a sort of online celebrity type of success that comes with being a known creator and maintainer of a well-used project.

For people that feel excited to learn new tools and techniques, when they stop feeling excited at this week's new shiny tool, I don't believe that's because the excitement of learning has gone, but the realisation that the new shiny is another thing operating at the same level of abstraction. Personally, new frameworks operating at the same level bores me, but deeping my understanding of the layers below is still exciting, and I personally think should have more emphasis on importance.

This doesn't mean people should feel discouraged from exploring new ideas and approaches, but it's important to realise that the cost to a creator of releasing anything into the web is virtually zero (essentially just development time), while the cost of adoption is high for every person that needs to learn yet another idea of how to structure their application and the abstractions that someone else came up with.

Web and cloud in particular seems to have a 'tools' problem, where every 'problem' that could be solved by simplifying or reducing (as general approaches) ends up just getting more tech 'solutions', but more tech to solve tech problems only serves to bury complexity.

Unfortunately it always ends up as the easier option to simply build new tools or build on top of what exists instead of developing a deeper understanding of the problem. It's also genuinely incredibly difficult to make sigificant changes to browsers as a target environment, so naturally all the tooling falls to things that can be done at development time or on-request.

Just my 2p.


I just spent almost a week battling with node, webpack, npm dependencies, electron. I once again don't want to touch js/ts, any fancy new framework and any FE for the coming years....


I feel the same. My immediate reaction to this wasn’t excitement but, “Oh fucking hell, not another one.” It’s so tiring and demotivating. Most of the cycle burning problems I deal with day to day are workarounds for quirks in the framework du jour (currently NextJS for me), and aren’t directly related to the actual interesting, value-adding problem I’m trying to solve.

I am so fed up of this churn. It is boring. It is uncreative. It is uninspiring. It is a waste of the limited time I have left it my life. All it achieves is to keep me shackled to the fucking hamster wheel and I am so tired of it.


I feel this perspective every single day, but then I recently went to get my old tires replaced. The people there's days are 8 solid hours of taking tires off, putting tires on, driving the vehicle over to the alignment rack and gluing weight onto wheels. All day. And they get paid pretty well all things considered.

I'm happy learn some new things even if there's resistance.


Yeah, I get where you're coming from. For me, though, the interest comes from the different problems we're trying to solve within the domain we're working in, not from learning yet another front-end framework.

(EDIT: Here's a great example of the kind of quirky bullshit I absolutely hate dealing with in JS frameworks: https://www.propelauth.com/post/getting-url-in-next-server-c.... Why do I have to jump through so many hoops just to get the pathname of the URL within a server component? Seriously, why are you making me write all this bullshit unnecessary code that adds no value to my end user to achieve something so simple? Absolutely ridiculous.)

I don't mind picking something up where it makes sense: over the past year I've found myself using Python fairly regularly for more data science type tasks, but in that case - again - it makes sense for the problems I'm trying to solve. It's the right libraries, the right ecosystem, the right tooling, and it's pretty stable and mature. I feel like anything I learn there is still going to be useful in 5 or maybe even 10 years.

The thing with JS and even TypeScript is that they're no longer immature technologies. Yet within the broader ecosystem around the languages we cannot seem to move beyond endlessly reinventing the wheel in very much the way we were already doing a decade ago. And, yes, there is progress, but the benefits versus the costs - to me - seem so minimally incremental nowadays as to be not worth the disruption. And the balance has tipped enough that it seems like really a lot of this churn is simply wasting peoples' time.

Like, if I'm going to learn something, I want it to really transform the capabilities at my disposal. The Python ecosystem is a great example of this but it's not the only one: I've never been a Ruby guy but I'm seriously considering picking up Rails 8 for my own interest simply because it streamlines and simplifies so much and the emphasis on realising and shipping the idea (or the value) is built-in.


same, laravel and vue is best


Though I don’t use it regularly, it does sound like an incredibly productive combo.

I really like vue. Laravel I don’t so much, but I appreciate how boring yet well designed it is.

I often wish the js ecosystem had real counterparts to laravel. We have too many ways to do things.


Be the chance you want to see in the world! JS has all the tools required to build its own Laravel; it just takes someone to actually put them all together and do it.


I actually think about this quite often, but I can’t imagine myself creating something better than Adonis for example. I’m not sure I necessarily have better ideas, or equivalents which are worth sharing.

Unfortunately it isn’t a framework I enjoy using much either. There aren’t any kitchen sink frameworks which seem to cover bases quite as well as the MVC frameworks I used earlier in my career (Symfony, Laravel, Rails, Django, etc).


If only there was One.


AdonisJs gets pretty close to Laravel.


Is Laravel used for backend?


I'm a bit old myself, I can share the same feeling and what I would call my "base tools" have been stable for more than 20 years now. But I don't have a problem adopting "new things", as long as they solve problems I actually have. If you're turned off by what is shown in the video, maybe that's just because this framework does not solve anything for you. Another reason could be that it does not fit well in your current, battle-tested, stack. Let the new generation try these new things if you don't want to, it will always be possible for you to adopt these when and if (and that's a big if !) they stand the test of time. No need to always stay "ahead of the curve", as an experienced professional, you have other qualities.

To whoever posted the video accelerated: don't do that. It's very difficult to understand what the man in the video says unless the YT speed is down to 0.75. What is the point of that ?


Wonderful work, but this doesn’t look like local first software to me. It looks like server first software with live updates and caching.

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.

[1] https://www.inkandswitch.com/local-first/


Hi Joseph,

There is a lot of debate about this in the community. People like pvh, adam wiggins, and johannes have all said they consider Replicache and Zero part of the local-first movement [1] and that they would be sad if we and other things like us weren't in it. I was even invited to speak at local-first conf, where we announced Zero last May. [2]

I think in practice delivering on the local-first ideals is ultimately up to the app developer not the library. Like in practice every yjs app talks to its server over some bespoke protocol and is loaded over a URL. If that server goes away your yjs app is a brick. No less a brick than if your zero server goes away.

Similarly although everyone likes to claim Linear as a local-first app, if the Linear server goes away your Linear app is a brick. Yeah you can export the data from IDB or whatever but you could do the same for Zero or any of these systems.

That all said, for our part, we have recently tried to avoid claiming Zero and Replicache as local-first on our own sites to avoid this controversy [3].

I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day. So I don't really care too much if it qualifies as local-first (except insofar as I like hanging out with the local-first folks and would be sad to not get invited to the parties).

I forgot to mention this to Nate when he showed me these mocks for One because honestly almost everyone else (not us) refers to Replicache and Zero as local-first and it's easy to forget. I'll leave it to him to decide what to do with his own product, but it seems easy enough to me to soften the language.

[1] https://youtu.be/cgTIsTWoNkM?si=6bYAAunqd5kdl-UL&t=2692

[2] https://www.youtube.com/watch?v=rqOUgqsWvbw

[3] https://zerosync.dev/, https://replicache.dev/


> I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day.

I agree! I wanted live server sync like this for years. And I built ShareDB years ago along those lines, many years before the term “local first” came into being.

But I see a pretty big difference between “server based app with sync” and “local first software”, party invitations aside. I wish we made a term for server based sync - I think it’s marvellous, and it’s important for all sorts of use cases. I think it’s ridiculous modern databases don’t have live queries built in as a standard part of sql. You’re doing great work here.

But all that said, I personally actively avoid calling sharedb local first because I don’t think it is. One big difference is authentication - who has permission to edit the database? And when? With sharedb (and I assume zero), it’s possible to add logic on the server to reject edits. It’s not possible to do this in the same way when clients can write to Yjs or automerge, connect to one another directly and broadcast their changes without the server in the loop.

That’s a pretty big difference - at least to me. I can’t speak for pvh, since I don’t get invited to those parties. But I want language to differentiate those two kinds of software. I’ve been writing software that straddles that line for over a decade, and that difference of how authoritative the root server is really important. It really changes a lot of things about how we build software.

I think the situation is like if we didn’t have a good term for client-server encryption so everyone just calls their software E2E encrypted even when it’s just using tls and encrypting data in transit.

I don’t think you should stop going to local first events. But I don’t think being invited to super cool parties tells us anything about your code. That makes you, personally, a member of a community. But the local first software question is, as I see it, a technical distinction. Not a social one.

The zerosync website says this:

> But where Zero really shines is “local-first” style applications like Linear and Superhuman.

Personally, I find that a pretty confusing claim. “Seamless online / offline support”? Sure. Rad as f? Absolutely. Local first? Eeehhh. It looks like a modern sharedb with a Postgres backend, better caching, maybe cleaner client side api and no collaborative editing. Definitely cool, but very, very different how local first software is described in the paper. That or I should start claiming sharedb is local first too, and muddy the waters forever. Gmail offline mode? Local first everyone. You're welcome!

As for websites that support offline data but can’t be loaded without a server, why not? App manifests can solve a lot of that. (Though nobody ever tries actually opening websites when they’re offline, so maybe there’s no point setting it up).

Personally, I’ve never heard of Linear. And I’ve never heard “everyone say” it’s local first. But if it’s a brick without the server, sorry, but I think everyone is wrong.


> The zerosync website says this:

>> But where Zero really shines is “local-first” style applications like Linear and Superhuman.

It is a difficult thing to communicate since the vast majority of people interested in Zero are coming looking for "local-first". And for better or worse what they have in mind is Linear (it's a very popular and widely respected bug tracker that calls itself local-first) not Apple Notes.

https://www.youtube.com/watch?v=XTMyOtvBJ_g

I'll think about how to reword.

I'm officially (waves hands in proclamation) inviting you to the next local-first conf. It's crazy fun. Tons of smart people working on all things sync.

https://www.localfirstconf.com/


I don’t get it. Why would you call something that needs a server to work local-first :?

My app that stores its state on my local disk with optional sync to a server is local-first. If the server goes away, the app continues working flawlessly, you just won’t be able to sync any more (unless you host your own server).

I find it hard to imagine people think of Linear when they hear local first.



I think there are two valid interpretations of the words “local-first”.

1) The outcome of all interactions can be seen locally first, but are sent to a server too. Optimistic updates on steroids, largely done to make software seem faster. Linear is the notable example.

2) The app is built so that it’s fully functional and useful without any kind of internet connectivity. But if network _is_ available, there are some augmented capabilities. Think note-taking apps like the one built into MacOS and iOS, or Bear


Right. And I think only (2) should count as local first software. And only (2) fits the definition provided by the local first software paper.

Option (1) is a legitimately useful way to build software. I wish more apps considered offline support. But I don't think "it works offline" is enough to make something count as local first software. For example, I don't consider Dropbox to be a "local first" tool.

I'm worried the "local first" term will be watered down by projects like this. That distinction matters. At least to me.


The crypto coin world is based on an Orwellian abuse of words / meanings.


Exactly this, "local-first" here mostly is a marketing term rather than a technical one.

I'll tell you a funny(real) story. where i live there is a popular valley, well let's call it X-Valley. the name is very popular and gets a lot of tourism to the valley, so much so that all the surrounding valleys now advertise them as X-Valleys on the internet. and they get a lot of (re: majority of) their tourism business from doing that.

Second is the people's understanding of the term "local-first", I doubt many truly understand the real one from ink&switch. what a good chunk of them are really looking for is offline-first or even optimistic-ui based sync system.


Hah I'll watch the video when I have a chance. Thanks for the invite - I'll have to wait and see when the time & place are announced. Maybe I'll see you there!


I think this is fair, as they haven't committed to offline - though they've said they want to do it, they just want to wait to do it right. That said, they do work fully client-side, so I wouldn't say it's server-first, it's more of a hybrid. I will try and clear this up in our wording.

Final note on the user-stuff: that's always up to the person writing the app anyway. You could make a "download the IndexedDB" button with a couple lines of code, but it's more than that, it's really a whole bunch of decisions you have to make as an app-developer to commit to it. And tbh I think the general understanding of local-first has settled on client-side + optimistic + offline - for the better.


> I wouldn't say it's server-first because the mutations are happening locally first and every feature works fully client-side.

That's not even close to what "local first software" means.

Can apps work without the server? Like, if the server goes down, will the app still work?

Can I collaboratively edit my data without the origin server? (Or at all?) Normally replication built on raw postgres queries relies on atomic row level locks on the server, while processing transactions. What happens if two people edit the same data at the same time?

Does it support end-to-end encryption, so my data isn't readable by the server at all?

Can I back up the app & my data together, and open it back up in 5 years and have the app still work?

All this stuff is talked about in the local first paper. Putting a sync engine in front of postgres (as described by the zerosync website) doesn't do any of this stuff. (Or maybe some of it? Its hard to tell without more information, and I can't find a link to the source code.)

It reminds me when Zoom advertised E2E encryption on zoom's website because the CTO clearly didn't know what "end to end encryption" actually means. It looks like an excellent product - so why exaggerate its capabilities?

"Local first" doesn't mean "edits are applied speculatively in the client before they hit the server". It also doesn't mean "caching part of the centralized postgres database in the client".

Go read the paper. The details matter. https://www.inkandswitch.com/local-first/


[Moved up thread]


To answer your specific questions:

> What if the data I need isn’t in the cache?

The developer can arrange for all the data to be in the cache if the want that part of the app to be fully offline capable.

> What happens when I edit things offline then come online later?

Zero won't support offline mutation at launch, but there's nothing preventing it from working. It is built on [Replicache](https://replicache.dev) which does support offline mutation.

I think almost no software that claims to be local-first actually supports robust offline editing and merging. The only people I've seen really go for this is the I&S folks with their branching stuff and that was just an experiment.

I'm excited to do this right, but most of our users care more about the ux and dx improvements while online, so we'll do it later.

> What happens if the company shuts down and the server gets turned off permanently? Will the app still work?

Developers can self-host Zero. In advance of any standards for sync, this is about the best you're going to get with any local-first software today, except maybe stuff that syncs to Dropbox (which is cool!).

> Can apps work without the server? Like, if the server goes down, will the app still work?

Yes. Read-only at alpha, and later read-write.

> Can I collaboratively edit my data without the origin server? (Or at all?) Normally replication built on raw postgres queries relies on atomic row level locks on the server, while processing transactions. What happens if two people edit the same data at the same time?

Yes. Zero uses server reconciliation, like our previous products Replicache and Reflect. You can read more here:

https://rocicorp.dev/blog/ready-player-two

(how could you even do realtime collaboration with postgres locks? that doesn't really make sense)

> Does it support end-to-end encryption, so my data isn't readable by the server at all?

Sure. That's up to the developer in how they design their database schema, but of course it's possible.

> Can I back up the app & my data together, and open it back up in 5 years and have the app still work?

I mean I guess so? If you had it in an electron app you just snapshot the data directory? An app developer could arrange for this to happen if it was important to them.

Does this all count as local-first? I think it's about as local-first as most other software claiming the title. But again, I kind of prefer to focus on what our product does and for that reason I try to avoid claiming we're local-first.


Thanks - very interesting stuff!

> Yes. Zero uses server reconciliation, like our previous products Replicache and Reflect. You can read more here: https://rocicorp.dev/blog/ready-player-two

Oh I hadn't seen that before, and I love that. It looks like an extension of database transactions / MVCC into the client.

Its interesting thinking about what situations this will & won't work in. I imagine it'd work for most of the mutations made in most applications, like editing rows in a database. And in your example, inserting at the end of a list would work.

But what about inserting in the middle of a list (or, typing in a text document)? Naively, it wouldn't work because "insert at position X" changes its meaning wrt. concurrent edits. But you could make OT work if you provided a way to change the arguments themselves if concurrent changes were detected. (Thats essentially all OT is. When concurrent changes happen, run the transform function. op = transform(op, other_op)).

Interestingly, I think you could use a text CRDT (like yjs) with your architecture. You would need to run the crdt's prepare function in the client first, to convert the edit into the CRDT's format (eg for Yjs, that looks like Insert('a', left_id: XX, right_id: YY). Then if you passed that object into the transaction closure, you could run the CRDT on the server and it'd all work out.

Its not quite as obvious and straightforward as your examples. But still, very cool that its extensible like that.


That is a disappointing interpretation of “local-first”, and would not suit the kind of applications I want to write.

On the other hand, this is still tethered to the server, so likely more commercially viable than a true local-first design.


> That is a disappointing interpretation of “local-first”, and would not suit the kind of applications I want to write.

I don’t think anyone wants or expects all software to be local first.

What would it even mean to "locally first" turn the lights in my house on and off, check the weather, or play a multiplayer-only video game?

Local first makes a lot of sense for some use cases - like personal / creative work (eg Apple Notes). But not for others.


> What would it even mean to "locally first" turn the lights in my house on and off?

It would mean that even when the vendor decides to disconnect the cloud server, the app still knows how to find the lights over the local WIFI and turn them on-and-off. This is one of the poster-child use cases for "local first".

> check the weather?

There's less to work with here, because we generally treat weather as a read-only use case. But it isn't! There are weather apps today that let you connect to your own local weather station, and/or fetch results from other tiny weather stations in your region. All of which could be handled in a "local first" manner (modulo some reasonable way to discover nearby weather stations).

> or play a multiplayer-only video game?

Chess, scrabble, or really any asynchronous turn-based game can be handled via local edit for your move, and then sync to your peer (optionally through a server for easier coordination).


> It would mean that even when the vendor decides to disconnect the cloud server, the app still knows how to find the lights over the local WIFI and turn them on-and-off. This is one of the poster-child use cases for "local first".

I agree with this, but my point is “what should the app do when you’re offline” - as in, your phone is on aeroplane mode. “Local” as in, local to your device. Not your wifi.

What does it mean to turn the lights on and off in that situation?

In my opinion, nothing, it shouldn’t work. And if that’s true, the light is essentially a server, the app / phone is a client. Nothing has changed except making the routing more efficient.


Sure, that's just the nature of interacting with a remote object of any type. But I don't think that invalidates wanting the app to be designed in a "local first" manner with respect to whatever happens to the cloud backend.


Right. A remote object. But the point of local first software is the objects are local.

If I edit a note using Apple Notes, I’m not editing a remote object. I’m editing something local - authoritatively local - to my device. The server doesn’t know more than my phone does, and the server doesn’t get to tell my phone that I don’t have permission to edit my own, local stuff.

That’s different from interacting with a remote object as a client. Hence, I don’t see turning a remotely controllable light on and off to be local first software because way more like interacting with a server than it is like Apple notes. The server just happens to be harder to route packets to sometimes.


By that definition, pretty much the only apps that qualify for local first are document stores. I'm not convinced that it is useful to narrow the definition that far (nor that most of the local first advocates would agree with such a narrowing).

We're basically talking about 1 bit of state that the light is authoritative about (on/off), versus all the other state that your copy of the app can be authoritative about (configuration, schedules, etc).


- turn on lights — there are smart light bulbs that phone home to the cloud. Along with smart assistance, home automation, etc. those are exactly the things that should be local-first, or at least, the server software should be onsite (such as Home Assistant — edge computing). We already have examples of what happens when companies shut down the servers those automations depend upon. To go even fuether, each device that is truly local-first enables the kind of cooperative automation conceived of in Promise Theory.

- checking the weather — although predictions are easier to come by from NOAA’s weather models, areas can have microclimates both natural and man-made that are not so easily predicted through atmospheric modelling. Permaculture design includes scaling microclimates in very small areas (on the order of specific plants) to tweak what can grow there. Local-first makes sense if you want to instrument those microclimates. Better yet, there are ways to read the clouds and conditions to get decent predictions for weather conditions for your immediate area.

- local-first multiplayer video game - what an intriguing idea! The closest I can think of is that multi-user virtual reality spaces that was built on a modern version of Smalltalk. It isn’t local first, but it supports multiple, independent servers that mesh together. There are probably also ways to do this with turn based games, such as chess or go.

Do you have any other examples? The ones you brought up were a good exercise to see how far one can take local-first design.


As a native iOS mobile developer, I was curious so I got into the TestFlight and downloaded the demo app. Thoughts:

* 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.


Glad to hear! That title jump and dark mode stuff we can fix, and honestly we can make it feel a lot better. As you can maybe guess our small team had a hundred things to pull off to launch so that demo app actually just has minimal investment. Appreciate the feedback!


Good luck!


> trying to mimic platform UI in the web, which is always terrible

How do you know?


I can answer that: I've used plenty of apps the past decade that tried to do this and each and every app "felt wrong". You know it within seconds that an app is not using native UI. There is always some basic interaction missing or just not working. Be it something simple like swiping navigation from the side of the screen or text fields that just do not work as expected.


Isn’t this the same logical error as saying “I can always tell when someone is wearing a wig”? You are only counting the times when you can tell.


No, because you can see when a website is using design components that imitate a particular platform (iOS, Android), like Ionic. Because the UI elements wouldn’t naturally look like that on a website if it wasn’t. They would look like standard HTML form elements.


Just want to say as a fellow dev who loved the glory days of Rails and then later Meteor (I actually launched a production app on HN that used Meteor!), best of luck! I'm not really in the market for a universal app framework like this but will definitely keep it in mind for future work.


Rails is still glorious and an excellent modern choice.

It's just not a 20-something with the energy, nor interest, to be out every weekend til 2am


with hotwire allowing realtime apps with no JS, and kamal for deploying to your own hardware, the glory days are back for Rails.


Amen to that.


thank you, definitely look forward to hearing if you use it


We were an early adopter and sponsor of Tamagui. Impressive tech but massively unstable even on minor version bumps. We even had a core team member working on the project and the breakage was every version. Lost more than 6 months of time relying on it. Ultimately we killed the project because of the decision to go with Tamagui. Just an FYI for those considering this. Abstractions on unstable abstractions is a good way to hate your project.


I feel sorry for your problems, but to be honest I'm reading the discussion here to understand what others think and who exactly can buy in that sort of "too good to be true" ideal solution.

Because to me it just looks like another shiny thing that tries to be everything to everyone and ends up doing nothing good. They seem to be good salesmen, but less competent devs, at least when it comes to creating real innovation, not repacking old code/ideas.

I'm saying that because, both of their websites are so bad that they create problems in Chrome, something that is rather rare nowadays with an adblocker; the Tamagui one repeatedly eats memory and crash in tab and the One seem to have some rendering issues.

It did not investigate because I don't really care, but I'll say it doesn't inspire confidence at all and in my opinion, it is largely enough evidence to dismiss the whole thing as a toy project of semi competent devs.

In another comment, I have seen you drop the hypocrisy and be a bit mad about the support you gave for disappointing results. I think the one you are the maddest at is yourself, because you feel you should have known and to be honest, you probably should have. But we all learn everyday...


That's a mean thing to say, but shows you lack the ability to judge skill. I've been doing this for a long time at the highest level, and I love doing it so I take care.

Our websites both get very high performance scores and if you profile them neither of them does anything at idle. Tamagui site does a ton of fun animations to show off how well it works, it's possible if you're on Linux or Windows with certain drivers causing issues, mind telling me any of that info?

I'm an old school web developer, I've spent a lot of time on performance. I'm proud of the sites, they weren't easy to pull off. I checked in Chrome again just now and things feel very smooth, and I don't see memory runaway. Do you have any other extensions?


No problem I was mean first. And you are right, I don't have enough competency to judge skill in this particular field.

However, I was just relating what was happening on my computer, my experience. Out of the 30 or so tabs that were open at this moment, your site was the only one to cause problem, so I don't think it has anything to do with the particularities of my install (I do have many extensions, they just don't cause trouble on any of the many sites I browse).

Right now, I can't reproduce the issue so I can't say more nor investigate a bit with the dev tools (not that I care enough to, sorry).

I will close by saying that I do not need to be a 3-star chef to judge the quality of an expensive multi-course meal. You may want to argue that it is not the same thing or attack me personally but realistically it is much better to realize that your standards may be different and that for some people, your stuff isn't up to snuff.

I don't think your stuff is exceptionally bad but it's a relatively simple page, that loads a gazillion js/css and uses more memory than a YouTube page with buffered/playing video with fully loaded comments and sidebar. You may very well have some specific benchmark that tells you that it's fast but if it feels slow in use that's clearly a problem. Maybe you are not focusing on the right thing.

I don't think your approach is very valuable for useful products but I guess that's just my opinion, good luck for the future regardless!


I loaded tamagui.dev, onestack.dev and a random youtube video (not playing): in order, 107Mb, 48Mb, and 219Mb of memory. Lighthouse scores are good. Profiling shows near 0 main thread work at all while scrolling or doing common actions, no memory leaks I can see after moving around the pages. Loading many JS files is not bad so long as it doesn't waterfall, actually good practice to an extent, and we have no waterfalls and prefetch everything on hover.

I don't doubt you saw something, I'll keep an eye out for issues. I checked in Safari and it looks similarly fine there.


This comment single-handedly made me do an enthusiasm 180. I'd find it helpful if the developers responded to it.

Just to give a bit more meat to my comment: these experiences are really helpful when you're in the position to adopt a potential time-saving (stack-cutting/unifying) technology. I find I get a huge benefit from word-of-moth experiences from others who have tried such frameworks. Specifically compared to takes on the _idea_ of the technology.


I responded in a sibling comment.


Im sorry to hear that. Tamagui is one of the biggest projects you’ll find in terms of scope - it’s not one library, it’s over 200, and it’s targeting 4 platforms, 4 JS engines, and has a featureset that is unmatched.

So I don’t think it’s surprising if you have regressions when upgrading 200+ packages for any project, and I also don’t think you should upgrade it honestly more than once every six months.

Second point is that we also moved (and had to move) much faster than a typical project. Because we had so many packages and were solving very hard problems, we had a lot of ground to cover. We never broke any API surfaces in a minor or patch, but we weren’t afraid to improve our underlying code because if we didn’t, on a project of that scale, we’d have quickly succumb to tech debt. A good chunk of our UI kit was under the “beta” tag until recently.

That said I’ll take responsibility for it. I wonder when this was that you adopted it, I think we’ve gotten a lot better over time as things have stabilized. We stopped adding features over a year ago now, and have entirely focused on stability, performance and documentation since.

A final note is that I have never been full-time on Tamagui, it’s always been a side project of mine while I had a full time job. We have a large test suite, but again, the surface area of the project is simply massive.

Now that I am full time on One and Tamagui, I am looking forward to proving that we know what we’re doing. We’ve hired great developers and have greatly expanded testing even just in the last few months.

One is a lot simpler than Tamagui. Like… not 10x simpler, closer to 1000x simpler. I keep telling people: a universal framework is surprisingly simple compared to a universal style library + UI kit.

Editing to add one more point of context. One of the best and pickiest developers I know - Fernando Rojo - has been using Tamagui since the beginning. He even wrote his own style library before Tamagui. He recently started on a new side project that he wants to turn into a real venture down the road, and he is using Tamagui for it. It’s actually one of my most proud accomplishments. It’s an extremely strong signal imo, as someone who is known for NIH and being very picky to choose such a big dependency like Tamagui again.


Nate - We discussed the issues extensively on discord and you even did a video call with me and my team. The entire core theming structure changed multiple times and worked with Eshan (which you represented as being a great developer and contributor to Tamagui) to solve the issues… just to have them break again on a minor version for you to release takeout. Having donated over $1,000 to the project and spent a ton of time in the discord and messaged with you more than a handful of times I feel like this comment isn’t genuine but is to save face on HN.


The theme API has not changed, we did refactor the logic behind it, and yes we've had regressions. It's a complex system. But we've always followed on with a fix, and we've added many, many tests in that area.

Listen, I really am sorry that you guys had trouble, and I really appreciate the support you gave. Did you come to me when you had these regressions? If there's one thing it's that I am responsive to issues, especially with sponsors.

Ehsan is a decent developer, and I'm not sure what you mean by "to release takeout". But I don't appreciate the end of your comment, I'm being pretty frank here and admitting we had regressions.

It feels a bit more like you want to offload a failure entirely to me. I don't think it's a smart strategy to be updating hundreds of dependencies many times within a few month period. Tamagui has generally been stable and we have tons of success stories, and I get thanks literally daily from people.

Again, I don't deny that we have had regressions and instability, especially around January when we had a bug slip through that we missed for a week, and that was hard to fix due to a change that was merged after it. That was one of the worst two weeks of my life - I spent an entire period of 4 days over a weekend with 3 hours of sleep on average each night fixing that issue.

But I think the real and true story is that Tamagui has been generally stable for quite a long time, and if you compare it to the 50+ libraries you'd need to glue together to make up a similar surface area it likely would be more stable.


> Tamagui is one of the biggest projects you’ll find in terms of scope - it’s not one library, it’s over 200, and it’s targeting 4 platforms, 4 JS engines, and has a featureset that is unmatched.

Tamagui is impressive, but TBH it's sounding like this is a bug, not a feature.

> So I don’t think it’s surprising if you have regressions when upgrading 200+ packages for any project, and I also don’t think you should upgrade it honestly more than once every six months.

In my experience it gets exponentially harder to upgrade packages the longer you let them get out of date.


For the first part - what's the bug? It's certainly ambitious, and perhaps too much so, but I think we've managed to pull it off. To take more responsibility here - I think we should have waited longer to cut "1.0." One of the reasons we did was because we were already more feature-complete and generally stable than many competitors, but that's not a good enough reason.

On the second part - I think that's true if you're upgrading across many minors, or a major. But we've not released a major in nearly 2 years. For the most part you can upgrade pretty big gaps in Tamagui. And again, we're incredibly responsive to people who give us a reproduction of any issue.


I am also an early adopter of Tamagui and can say that documentation has gone much better than it was before, but still needs lots of improvements. I myself struggle with many packages we have installed with Tamagui, and at this point I don't know which one to keep and which can be removed.


We are working on documentation more actively than before. Please do reach out to me with any questions or feedback. Now that I'm full-time for the first time this is something I can actually focus on.


Thanks Nate! One immediate feedback I would like to give is to improve the configuration/setup documentation, like config/v1/v2/v3, packages like @tamagui/animations-react-native/babel-plugin/config/font-inter/react-native-media-driver etc. There is very less about these packages on the documentation or maybe not easily accessible.


Thanks - noted to the team. We're moving a lot faster now that I'm full-time and I finally have two really great devs alongside. Look forward to improving this and having people say "actually it's really good now" in a few months time.


Good to see this on HN, I’d love to share my journey with Takeout!

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.


Context:

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. :)


That blog post was spot on in 2022! Cheers for that. Time for a re-write in 2025!

And thanks for adding the context on Takeout.


I get "programmers are also human" vibes reading this. It is so uncanny.

more context: https://www.youtube.com/watch?v=aWfYxg-Ypm4


Was this written by AI? It sounds very uncanny valley like. Or otherwise, is it a paid marketing post?


We're gonna need a new entry in HN guidelines about AI sniffing


The sheer number of Tech Nouns in this post is dazzling. What have we done.


I'm really happy with Takeout. It has its flaws but it's the easiest stack to get up for web/ios/android.


> Creating websites and apps is simply too complex

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.


The problem of integrating high-quality modern UI with complex live data is something that is actually complicated! Your choices here are limited:

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.


The problem is most people think their app is super complex and requires some mad thing that's actually complicated when actually its a glorified crud.


The iPhone is 100x more complex and does 10x more than like 10 separate gadgets from the 90s, and yet is also easier to use and more efficient than them all, broadly.

Your CRUD app could be terrible in pure HTML and amazing in Svelte. Or vice versa. But a competent engineer will make a better version with the more modern tech.

Your OS GUI is an abstraction on an abstraction, it's UI kit is on top of that, the browser is on top of that, React on top of that...

People always draw the ideal line exactly at where they learned things / stopped learning things.


> high-quality modern UI

I do think that some UIs are more complex than they need to be.


Every problem can be solved by adding an extra layer of indirection xD


Except the problem of too many layers of indirection.


That's not a problem, it's an opportunity!

(for more layers of indirection)


Wait.. It's all layers of indirection?

Always has been.


What the hell, Nate! As a long-time web developer who witnessed the divide between frontend and backend, this looks like the most transformative step forward since Next.js. What you have built here is amazing, and it's definitely something that the industry needs right now.

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!!!


This is exactly how my best friends and family would write in my Show HN if I ever post one.


I happen to be from Rio de Janeiro, Brazil, so I never met Nate — yet! But I'm pretty sure our paths will cross in the long long road of web development ahead of us :)


> the most transformative step forward since Next.js

I'd consider Next.js a giant step backwards, frankly.


Would you mind elaborating on this?


Worse things have been said about them


Thanks! Get in touch with me if you guys do end up using it.


> most transformative step forward since Next.js

Can't help but roll my eyes here


I am a fierce hater of the complexity and closed-ness which Next.js became, BUT "results don't have to be explained" and Mr. Guillermo unarguably executed the hell out of it. It IS the default for new frontend developers, right now. I don't think it will necessarily remain, specially because of things like One!


It’s the default because Vercel dumped millions of dollars into devrel and marketing. It’s not and never was definitely better than other available options.


arguably, the devrel does actually make it a better option though


That is true. Good docs, examples and community wins.


Good docs? Have you tried to get definitive answers on image optimisation, response modification, error codes, or much anything other than “serve these react components at this path”?

When there is documentation, it’s often a mishmash of incomplete examples and links between the two totally incompatible editions of the framework.


Closed? How? Genuinely want to know more. Don't have much experience with ecosystem.


There are those who would say they created a "bait and switch" from their open framework into their closed for-profit deployment platform. That is not objectively wrong, though. But still, many complain. I say: good for them. Let competition happen.


Unless you want a very painful experience then you basically have to host it on vercel.


So far I've only used Next.js for static site generation, for a couple of long-term projects. Self-hosting it is as easy as any static site. Upgrading major versions of Next.js, however, has been fairly painful. The experience made me reconsider the decision to use it, and I'm keeping up on possible replacements like Remix. But honestly I'm getting a lot of value out of the framework that I'm in no hurry to change.

For dynamic sites that require running Next.js on the production server, I'm not too interested in trying because it feels like too much vendor lock-in. The same reason I wouldn't consider Vercel for hosting, since they develop the framework that is already a big dependency.


I think this is the key though really, and what peeves me the most.

NextJS is fine to self host if you don't need any of the features that actually make it worth dealing with all the additional complexity.

Essentially if you want any of the special sauce you have to host on vercel, or use opennext guides to build equivalent infra.

Its just not worth the complexity for me to use.


Having 75% of the landing page dedicated to Zero, then clicking into "read more" to learn that it isn't even released yet, feels weird. This feels more like a soft launch than a grand opening, which is fine but not what I expected based on the post. Best of luck to you and team.


This is cool and I’ll definitely try it out some time.

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 have experienced the same. These tools make 99% too easy and rest 1% too difficult. I have worked on a RN (expo) app, it was working well for the client. New requirement added - geofence, wifi connect from app in background. There is no RN (Expo) plugins. So tried last few days with custom expo module. I didn't know kotlin, i worked with java only. Now i am learning Kotlin and realized that Jetpack compose is way better than wasting time with these do all magic tools. Now rewriting the whole app in Kotlin only.


> Who is this for?

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.


To target iOS, Android and Web, you’d have to write 3 apps / frontends then, instead of just 1 (with One).

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...


Not arguing with you there, of course there will be 3 apps.

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.


Airbnb was early, React Native has grown immensely since then. Honestly not to tout myself, but Tamagui brings so much as well to make it possible to share styling.

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.


Yeah, I’ll add that the decision to use RN if you already have a couple of native apps is way harder than if you are starting out with RN. I think the former was why AirBnB reverted their RN foray, and it seems to match your experience.


Rails mentioned!

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?


One is like the halfway point between Next.js and Rails.

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...


Got it. So you're aiming to be a full stack framework. Let's say I want to keep all my business logic and schema in Rails. But I want a UI for web + native, would One work in this case? It is kind of where my lack of knowledge about how Zero works is causing my confusion on all this.


You definitely can, so long as you use Postgres you should be able to use Zero (as of now they have a few limits on column data-types as well).

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.


I'm interested in this as well. Not ready to drop Rails as the backend...


The answer is you won't have to. I asked in the Replicache discord if there was any more public info on Zero and the creator linked to this notion document https://replicache.notion.site/Introducing-Zero-8ce1b1f184aa...

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.


I worked for Famo.us back when it was an open source framework, and I know intimately well how hard it was to create something like this. Incredibly powerful if this reaches it's full potential, and kudos to you for embarking on this path to try! I keep waiting to see if this ever comes to be.


Hi Nate!

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!


Thank you, love to hear it!


I liked meteor a lot and I built Thingstudio on top of it for making IOT ui's.

https://youtu.be/8a9rK4Xdfqs?si=k-UantDmT-HXnUlg

I'll give this a shot. Maybe I'm not too old yet. I don't turn 70 for another year


Watched the video and tried to visit the website. What happened to it? You close up shop? Looks like it was a good solution


Good solution, too early. I made this 10 years ago and found myself having to explain what MQTT was before I could get people to try the platform.

I may yet have another go.


I tried `npx one` to get an idea what this is about, as the description sounds too magical for me to make sense of.

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.


Yes please, can you email team@tamagui.dev with it?

And if you can include this info: npx envinfo --system --npmPackages --binaries --browsers


OP most people replying to you are old and ossified and not your target audience, and there is something to be said for being polarizing (it increases your dating success!). I think this is great, and the reason people keep making new frameworks is because we all know that webdev sucks a lot more than it has to, and there really shouldn't be different solutions for all of these different platforms.


Thank you, frankly I'm shocked to only have 25% or so negative comments here, a first for a new framework :)


I'm extremely excited for this! Especially with Zero on it's way.

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.


One of the main issues I had when I tried to do an app in react native was not really the UI,performance or data.

The main problem was that you where in an uncanny vally type of situation where some browser features where supported and some nodejs(?) features but never the right ones.

So you now had to write 3 different apps(web,ios,android,electron(?)) with all the problems of react/js while not having the wealth of libraries and batteries included benefit of a browser

E.g. crypto.subtle was not available, so forget anything with encryption running in react native and on the web without separate libraries.

So my question is how do you solve the problem that react native loses many of the benefits of using a webview type framework?


It’s a trade off - better performance and native UI but a bit more of a learning curve and need to curate some API surfaces.

We have something close to ready based on Expos “use dom” feature they just announced. It should be available soon. I think that’s a smart strategy so you can do webviews if your want.

But to be honest I haven’t felt much pain in that regard. You can almost always find a library pretty easily for what you need, and the trade off in getting a great native feeling app is worth it, especially if we can keep improving DX, which I plan to do.


Hi Nate and team, congrats on the launch! What an exciting time to have an Expo alternative for cross platform app!

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 can’t test with Vitest minus full integration (ie app runtime). For that we’re investigating solutions still, noted to add some docs around this next.


Can*


Man this is awesome.

I‘m using a somewhat similar stack for an app in development with a monorepo consisting of a Postgres backend (Rails) + Expo (with Router) + Tamagui + Redux Toolkit. And, as one would expect, it’s been quite a struggle, to say the least.

But currently this is one of the few viable stacks imo for a small team or sole developer to serve both native mobile platforms and the web in a decent quality.

So it’s kind of cool that with One there is now a framework available that brings all those great tools together in a polished and structured way.

Can’t wait to give it a try next week. Could make things a lot smoother.


Great writeup(s), thanks for sharing! My immediate reaction was “that sounds too good to be true”, which is a nice compliment I think. I have some high level questions if you find the interest:

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


even being a "tech" person i havent ever installed a PWA and no one in my "non tech" circle even knows that they exist. Lots of user education to do there for them to work in my opinion.


1. With Tamagui you can share almost 100% code, so it's not a re-write, and mostly the reasoning is that it feels a lot more native. Especially interactions, scrolling, and being able to use native UI and libraries anywhere you want. Performance is a bit better too in general. It's a bit more work for sure, but I think Tamagui + One really does make it a ton more doable than before.

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.


Fantastic. You’ve got a new user in me, will be porting my AI from next.js asap. Thanks for taking the time!


Web apps are complicated because we chose to make them complicated. We started with HTTP headers being sent over a socket and added on infinite layers of shit to "abstract" things. As if hiding what is actually going on is inherently helpful.

Your framework preserves the status quo rather than simplifying it.


I think people draw the line arbitrarily. Do you know how complex an OS is, a browser, etc. JS is super complicated, so is even CSS.

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.


I agree, people often underestimate the complexity of a browser and its ecosystem. Yet, I find it valuable that people question the merit of all these additional layers, especially those added by JS frameworks. What do they yield? Do they allow you to more quickly develop an application? Are the applications better than before, by any metric?

I'm pretty sceptical because coming from real-time & desktop programs, I find UX on most web apps I use leaves a lot to be desired: I regularly see state inconsistencies when I go back & forward in my browser, I cause race conditions by quickly editing fields, fight with input validation missing my input, and just die a slow death because the page is just slow. I would have assumed that frameworks existed to remove all these burdens from developers. Yet that such issues persist so stubbornly for over a decade shows to me that somehow, even such simple and recurring tasks as providing and validating forms are not properly solved by those frameworks (or the field is full of people that don't know how to use them properly? Then, why is using them correctly not easier?).


Yes, modern computer systems are unbelievably complicated from the application level down to the hardware. The consequences are absolutely devastating. https://www.youtube.com/watch?v=kZRE7HIO3vk


So I watched the video on the home page. It made almost zero sense to me. It was all very vague and seemed to be targeted at people who already knew all the product and the problems is solves without needing to be told. if that was the goal then great but maybe another video targeting a wider audience?

I got the point of rails and meteor immediately. it wasn't clear at all if this was even solving similar problems or what


Zero seems like a promising approach for developing local-first applications. However, if I want to develop a SPA in the traditional way—using fetch or react-query to communicate with the server—will I need to configure anything special to separate Zero from One? In other words, I hope One is not tightly coupled with Zero. It should be a data-solution-agnostic framework, focusing on the UI for various needs. We really need something to fill the gap after CRA is replaced by Next.js, as Next.js does not provide a mature SPA solution (and neither does Remix).


They are not tightly coupled. We just want to be able to build some great tooling for those who do opt in.

But it will always be opt-in to Zero.

I think it’s an amazing alternative to CRA - it’s got the lightness of Vite, but you get all three rendering modes on a per page basis!


It must be! You can’t imagine how desperate I was when I found the main stream UI framework in React nowadays didn’t think SPA is a thing, I just want a file-based routing SPA framework, but people keep talking about SSR and Next. With the release of One, I finally don’t feel alone.


As a react native dev I’d love to hear some of the implementation details!

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?


It started as a fork of expo router to test if we could get it to work on Vite. Over time we did diverge a few things and added other features.

It’s actually fully Vite on native. We wrote an entire custom bundling step and hot reloading. This was no small feat, quite hard. That was the motivation though - simple tooling and the same bundler for everything.

Expo is great for Expo Go and EAS. It’s a good complement!


From my limited understanding of Vite, it serves es modules directly on the fly during dev but uses Rollup to bundle in production. Did you swap out Rollup for Metro in production, or have you somehow ported all that byte code generation stuff to Rollup as well? Pretty wild either way!


We use Rollup to build for native, SWC so we can compile class away (RN doesn't support classes, shockingly).

Then we actually build out our own custom bundle using the Rollup output because we need to hot reload it, so we built our own little hot reload pipeline on top of Vite. It's not too complex actually - websocket, listen to vite, transpile it to CJS/ES5, analyze and re-write imports to match bundle, and then send it over.

But yea, it was a lot of work. Going to have to make some content around this as I assume a lot of people thing it's just Vite on top of Metro.


I just started a react native/expo project and saw this. I’m wondering if this is mature enough for me to adopt, and more importantly, how easy will it be to migrate react native/expo project to this in the future. I just don’t feel this thing is stable enough as the guides themselves state, especially for iOS.

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?


What are you using currently to shared code?

One generally has better web features/performance. Our tree shaking/bundle splitting is better, SWC for everything so it's faster, and Vite is a joy to use in many ways compared to Metro.

The routing modes are also neat and novel, you can globally choose a strategy - SSR, SPA, SSG, but then also choose on a per-page basis. This is huge for having performant marketing pages, but not burden yourself with having to server render everything.

Our dev mode is also robust - it will fully SSR render with CSS extracted in dev mode, identical to production. This is pretty huge, even Next doesn't do this (as of a few months ago), you'd have flickers or inconsistencies.

Other advantages include link-hover-preloading, a much slimmer initial bundle size, 0 waterfalls of all assets loaded on first render. Loaders are another, no universal framework does it. Also, we build to production fully for you including a server to serve it, and it works with all your stuff - loaders, API routes, etc - also not true of comparables.


Thank you. I’ll give it a shot. Gotta experiment.


This looks really awesome! Can't wait to try it out. I've worked with React-Native-Web and Nativebase in the past, and it was always fragmented. I'm glad you're working on this. Zero was mentioned a lot in the demo and it seems impressive.

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)?


It should “just work” for electron, but we probably need to make it easier to build target them. Happy to collab and help there if you join the discord and send us any issues you run into.


This might be a beginner thing but to me it seems like web development is bloated. Since I haven't yet built big web applications can somebody enlighten me what the benefit is of using a framework? Why do websites need this much JS? Wouldn't lots of things work better with just HTML and php? (Although php is getting a lot of hate)


Saw this yesterday, tried to find it again today. Googled "one js" since I couldn't remember the URL

Results:

A unity library

https://onejs.com/docs/gettingstarted

A different js framework

https://onejs.dev/


Is this a personal project, or do you have a path to turning it into a revenue generating framework that you will support commercially?


Tamagui generates enough revenue to support our team currently, but we do want to make this a viable company.

Not sure yet exactly how, but One will always be OSS and further I don't ever want to try the whole "lets make it hard to deploy and have no docs on how" - it's already super easy to deploy anywhere, it builds to something you can basically serve statically, and is very simple architecturally. That's a big feature.


Do you mind sharing how you are creating revenue on open source developer libraries? I.e. what was your path from initially publishing to being able to sustain a team? I have the foundations of one (vaguely in the same space, but different market) and would like to do similar.


Tamagui revenue is 20% sponsors, the rest our paid starter kit and pro UI components.

Honestly I don’t recommend this path. The work to payback doesn’t make sense still to this day. I wish OSS was more viable, but we still have a long path to go to get to success.


Creating websites is easy: just don't try to make them into an app. Stop trying to reimplement the browser in javascript and just write plain static HTML with limited progressive enhancement where it actually makes sense.


As a long time fan of Rails, Expo Router, Tamagui, I'm super excited to see One Stack. Great work :)


first thing I noticed when I pasted the link into Slack is that it doesn't generate a preview


We have a proper OG, its been working on messages app, twitter... will have to test with Slack thanks for heads up, maybe just sub-pages?


Someone please clarify what "local-first" means in this context. Thank you.


Local-first generally refers to apps that work with a local client database which syncs with a server database in the background. Reads and writes go to the local database first. This results in very low latency and not being dependent on the network for working with data. The term is often applied loosely and architectures and implementations differ quite a bit.

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/


Thank you.

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.


Yes, using IndexedDB is common, and increasingly also running SQLite in the browser using Wasm, with its data persisted through a VFS that uses IndexedDB or OPFS. https://www.powersync.com/blog/sqlite-persistence-on-the-web


Hey dawg, I heard u like client-server... so I put client-server in ur client-server so u can client-serve while you client-serve.

Jesus Christ, can you imagine every shitty website on the planet using Wasmed SQLite in the future... I just shuddered with horror.


Assuming it means sites can still run when there's no internet, using local storage for caching when internet is back up and service workers to poll in the background.


I don’t know what makes me want to try this out compared to the hundreds of frontend/cross platform solutions out there. Maybe it’s the “local first” notion.

I’ll give this a shot and subbed to the zerosync mailing list :)


Congrats on the launch! Stoked for another effort to do a typescript rails. That's a very different and IMO much more ambitious goal than doing a simpler next.js. RedwoodJS is the current notable effort in that realm but sadly doesn't seem to have gotten too much traction.

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.


> We've collectively complicated the hell out of things.

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.


Given that we're not dumping JS anytime soon, I think that the shortcomings of JS are kind of moot.

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.


Nobody said "dump Javascript", and that clearly isn't what I meant [1]. I put that part in only to illustrate that these problems were knowable at the time that Meteor was created.

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'm not a web dev, but I see a conflict between server-side HTML generation and a local-first application. ;)

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)).


You're correct about the two use cases. The problem is that too many websites/developers think they are case b) while they really are case a)


> 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

WebSockets would like a word


100% honest as someone who loved Rails - i really love building with react and tamagui if you put together the right tooling.

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.


To play devil’s/react-dev’s advocate: the appeal of local-first is that you can easily configure which business logic you want done on the server, leaving anything that can be done on the client to the client for latency and cloud bill reasons.

  javascript lacked (lacks?) even the basics of a practical programming language -- real packages and the like
Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else? Like, splitting up your code into packages gets you some performance benefit in other languages? I have python packages (read: __init__.py files) in my Flask app, but I’m not sure I’ve ever missed them in TS - am I missing some big picture? In general web bundling is so complex I tend to treat it as a black box, so that could easily be on me.

  you're re-inventing wheels (like routing, rendering, a request/response paradigm) that the browser does for you, for free. 
I’m having trouble seeing what you mean here. I know the typical “implementing an SPA is tough because you have to fake pathname manipulation/history” warnings, but I think you’re going a step beyond that. React does rendering on a way more performant level than browsers if you’re just changing subsets of the DOM, and I’m really not sure what you mean by the “request/response” paradigm at all, sorry. SPAs do have to handle async requests on the client and normal websites make the server do that when building the page, but ultimately the difference seems slight. What am I missing?

  for the vast majority of CRUD websites
I mean, do people making crud websites really need any frameworks, and do they browse hacker news? Aren’t static sites a pretty solved problem by people like WordPress? Seems like the hard part of that would just be writing content and filling templates, maybe some styling — not any engineering work.


Agree with you pushing back on the TS hate. The ecosystem and tooling have gotten very mature and very productive IMO for building UIs.

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).


> Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else?

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.


What language has a built in dependency system…? How would that even work? I’m confused. Every dependency system is a registry of dependencies vetted by some group, along with one or more compilers/runtimes that know how to speak that group’s format. Who cares if the group is GitHub (TIL… ew, tbf) vs. the language nonprofit itself?

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?


> What language has a built in dependency system…?

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.


What's the process like for migrating an existing react app to one?


It's Just React mostly at the base, give it a try, the FS routing will be mostly where you need to adapt things.


Zero looks sick as hell. I'll be keeping a close eye on these.


Crossing my fingers that something like this pops up eventually for modern Signals-based JS frameworks like Vue, Svelte or Solid.

There is no way for me going back to React.


I love how the influence of Rails comes through here... there is definitely a flavour of convention over configuration with this framework. Nice work!


I really wonder when javascript frameworks will get over file system routing. It didn't take PHP too long to move to better solutions.


DJ Khaleds response to this: Anotha' one


"One" isn't the right name. I think "Oni" would have been more fitting.


zero looks insteresting, does it support caching everything that a user might ever need? it says it only store 100MB of cache. But for an 'offline search' feature to work aren't we supposed to cache everything?


Queries span frontend and backend. If a query cannot be resolved entirely on the frontend (due to missing data) it falls back to the backend to get the rest of the results.

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.


browsers limit that storage, what it does is basically offload / re-sync as needed.

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.


Funny I was just hacking on an Expo side project... might try this instead.


Can I use it for other platforms,. Like lg tv os webos? Samsung tv?


Edit: Not now, but maybe in the future


I honestly can't wait for the day I wake up and everyone hates React as much as me. I'd also settle for people just forgetting it for something better.


What is it about React that you hate? React has been the near defacto framework for frontend development for a decade now [1]. Like it or not, it's not going away anytime soon.

[1] https://2023.stateofjs.com/en-US/libraries/front-end-framewo...


As a Svelte / vanilla TS dev, I hate React because looking at it makes me feel like I’m drowning in obtuse, leaky abstractions, none of which feel necessary and all of which are required to do _anything_ at all.


Another react hater here. Here are some of my beefs.

  * 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.
There are more.


> Everything is treated as if it's immutable [...]

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.


Mobx is cool. Nice to see some other mutation enjoyers. I also made my own thing[1] called "mutraction" (portmanteau of "mutate" and "tracking") based on this premise that uses jsx and mutation. I mostly made it prove that it could be made and to understand how it would work.

[1] https://github.com/tomtheisen/mutraction


After 10 years I also hate the current incarnation of it.


why do you hate it?

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?


> "fuck it, everything is javascript" is react's great insight, for interactive applications.

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.


jsx is handy but clearly react's 'great insight' if it were to be so reduced, is implicit state management.


If by implicit state management, you're including the abomination that is `useState`, I could not possibly disagree any harder.


I despise JSX as well. Simply because no one is able to handle if else and conditionals in a readable non spaghetti way. Every time I see {condition && <Component />} or {condition ? <ThisComponent /> : <ThatComponent />} I die a little bit inside. In addition to that people to get around these things will do helper functions within the component itself e.g. {renderSomething()} This ends up inside of the component being really unreadable and spaghetti where you have to jump up and down everywhere.

I prefer VueJS or Svelte much more, but unfortunately due to its popularity I am stuck with React.


It's true, components can get unwieldy. That's the feature aspect of components built with a full programming language (js).

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:

    <div id="app">
      <button @click="count++">
        Count is: {{ count }}
      </button>
    </div>
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've been involved in teaching React and FE for more than 10 years (many hundreds of students), and let's be clear here: Students don't understand that JSX is JavaScript either (and let's be clear here as well; it isn't - it's something that can be transpiled to JS). Rather, people believe it's HTML (since it looks like it), and very much confuses all the differences them in-between - in particularly when mixing with JS (eg conditionals).

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.


> 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.


Despite Vue having this separate template syntax it felt very easy to learn and natural as opposed to the boilerplate that you get with React. It is not like JSX is understandable out of the gate if you know JS.

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.


JS function that yields the UI is not about dogma or JS enthusiasm, to be clear, I would prefer NOT to use JS. And I concede that frontend ecosystem really seems to see "everything in one language" as some kind of benefit and virtue. It's not!

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.


You can do "everything in js" without having functions that return the ui. See svelte or vue or solid or most anything that isn't react.


I'll check those out. Solid keeps coming up, so that's good sign.


Yes. And .map().

And the tag closing semantics are slightly different from HTML. And approximately no one understands how HTML tag closing works anymore because of it.


Looks good . Will give it a try this weekend


Whats the release date for Zero?


refreshing attitude, keep it up


is zero a paid product?


Most likely.


Someone asked on the other news item about onestack.dev :

> 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.


Metro is the default web bundler since Expo SDK 49[1] albeit missing vital features like bundle splitting. I think web bundle splitting is there in SDK 50? And the migration path from webpack to metro was pretty painful for big existing app.

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


Great context, thank you for sharing!


Oh we building frameworks upon frameworks now?


We heard you like build steps, file types, new language syntax, and using other people's code, so we created a new framework that adds new build steps, a new file type, a new language syntax, and more dependencies.

Haven't looked at One yet, I'm holding out hope that it doesn't actually use React.


I really don't like that we're focusing so hard on frameworks in web dev. The creator claimed that web dev has gotten extremely complicated. It's only complicated due to frameworks so One is not interesting to me at all. What if One is complicated in 5 years as well?


Haha - it’s built on React no different than other frameworks are (Remix, Next). Zero is pluggable, so it’s more like a really well integrated library.


This looks awesome!!!! I've wanted something like this for SO LONG.


Some criticisms of your post specifically... the linked page doesn't go into enough detail of 'One' and then the not particularly visible 'read more' link goes to a page that is talking about 'zero' and how it is still in private beta...

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.


We can't put all the info right onto the main page, it's meant to give you the high level.

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.


Pro tip -> if you make the font smaller you can add more words to describe the thing that you have made




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: