DJ Khaleds response to this: Anotha' one
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.
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.
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.
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.
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).
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
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.
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
> 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.
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 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 ?
has nothing to do with your age even at early 20s I was sick and tired of constant new frameworks in web dev.
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?
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.
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.
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
> 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.
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.
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).
- 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.
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.
thank you, definitely look forward to hearing if you use it
I really wonder when javascript frameworks will get over file system routing. It didn't take PHP too long to move to better solutions.
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.
> 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.
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)
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.
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!!!
Thanks! Get in touch with me if you guys do end up using it.
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.
Worse things have been said about them
> 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!
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.
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.
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.
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.
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
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 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
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?
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.
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.
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*
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!
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!
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.
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.
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.
is zero a paid product?
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.
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?
As a long time fan of Rails, Expo Router, Tamagui, I'm super excited to see One Stack. Great work :)
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.
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 :)
I love how the influence of Rails comes through here... there is definitely a flavour of convention over configuration with this framework. Nice work!
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.
Zero looks sick as hell. I'll be keeping a close eye on these.
"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.
Can I use it for other platforms,. Like lg tv os webos? Samsung tv?
Edit: Not now, but maybe in the future
Funny I was just hacking on an Expo side project... might try this instead.
> 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.
> 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
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)
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
you're re-inventing wheels (like routing, rendering, a request/response paradigm) that the browser does for you, for free.
for the vast majority of CRUD websites
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?
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.
> 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.
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.
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.
Whats the release date for Zero?
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.
> 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.
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.
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>
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.
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.
After 10 years I also hate the current incarnation of it.
Looks good . Will give it a try this weekend
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
refreshing attitude, keep it up
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
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!
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.
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.
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