[HN Gopher] Show HN: One - A new React framework unifying web, n...
___________________________________________________________________
Show HN: One - A new React framework unifying web, native and
local-first
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.
Author : nwienert
Score : 304 points
Date : 2024-10-04 15:15 UTC (7 hours ago)
(HTM) web link (onestack.dev)
(TXT) w3m dump (onestack.dev)
| stragio wrote:
| 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.
| anxman wrote:
| I'm really happy with Takeout. It has its flaws but it's the
| easiest stack to get up for web/ios/android.
| redbar0n wrote:
| 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. :)
| stragio wrote:
| 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.
| amne wrote:
| I get "programmers are also human" vibes reading this. It is so
| uncanny.
|
| more context: https://www.youtube.com/watch?v=aWfYxg-Ypm4
| WD-42 wrote:
| The sheer number of Tech Nouns in this post is dazzling. What
| have we done.
| android521 wrote:
| Looks good . Will give it a try this weekend
| Eric_WVGG wrote:
| Zero looks sick as hell. I'll be keeping a close eye on these.
| jeremy_k wrote:
| 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?
| nwienert wrote:
| 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...
| jeremy_k wrote:
| 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.
| pqdbr wrote:
| I'm interested in this as well. Not ready to drop Rails as
| the backend...
| redbar0n wrote:
| 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.
| mstade wrote:
| Great context, thank you for sharing!
| darcien wrote:
| 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
| zwnow wrote:
| Oh we building frameworks upon frameworks now?
| nwienert wrote:
| 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.
| itronitron wrote:
| 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.
| mstade wrote:
| 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!
| nwienert wrote:
| Thank you, love to hear it!
| thegreatpeter wrote:
| As a long time fan of Rails, Expo Router, Tamagui, I'm super
| excited to see One Stack. Great work :)
| itronitron wrote:
| 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.
| nwienert wrote:
| 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.
| itronitron wrote:
| Pro tip -> if you make the font smaller you can add more
| words to describe the thing that you have made
| recursive wrote:
| 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.
| nwienert wrote:
| Yes please, can you email team@tamagui.dev with it?
|
| And if you can include this info: npx envinfo --system
| --npmPackages --binaries --browsers
| moomoo11 wrote:
| 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.
| redbar0n wrote:
| 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...
| moomoo11 wrote:
| 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.
| redbar0n wrote:
| 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.
| nwienert wrote:
| 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.
| darcien wrote:
| > 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.
| raybb wrote:
| 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.
| timr wrote:
| > 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.
| CharlieDigital wrote:
| 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.
| timr wrote:
| 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.
| bbor wrote:
| 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.
| rgbrgb wrote:
| 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).
| timr wrote:
| > 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.
| bbor wrote:
| 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?
| nwienert wrote:
| 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.
| bbor wrote:
| 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
| motoxpro wrote:
| 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.
| nwienert wrote:
| 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.
| bbor wrote:
| Fantastic. You've got a new user in me, will be porting my AI
| from next.js asap. Thanks for taking the time!
| rgbrgb wrote:
| 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.
| monocularvision wrote:
| 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.
| nwienert wrote:
| 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!
| monocularvision wrote:
| Good luck!
| spullara wrote:
| first thing I noticed when I pasted the link into Slack is that
| it doesn't generate a preview
| nwienert wrote:
| 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?
| davedx wrote:
| 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.
| nwienert wrote:
| thank you, definitely look forward to hearing if you use it
| apsurd wrote:
| 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
| darcien wrote:
| 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.
| nwienert wrote:
| 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.
| lxe wrote:
| Funny I was just hacking on an Expo side project... might try
| this instead.
| 0x142857 wrote:
| 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?
| nwienert wrote:
| 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.
| catchmeifyoucan wrote:
| 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)?
| nwienert wrote:
| 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.
| itslennysfault wrote:
| 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.
| awkii wrote:
| 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...
| FractalHQ wrote:
| 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.
| recursive wrote:
| 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.
| apsurd wrote:
| > 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.
| recursive wrote:
| 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
| apsurd wrote:
| 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?
| recursive wrote:
| > "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.
| elif wrote:
| jsx is handy but clearly react's 'great insight' if it were
| to be so reduced, is implicit state management.
| xyst wrote:
| 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 :)
| henning wrote:
| 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.
| nwienert wrote:
| 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.
| gadr90 wrote:
| 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!!!
| parthdesai wrote:
| > most transformative step forward since Next.js
|
| Can't help but roll my eyes here
| gadr90 wrote:
| 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!
| wg0 wrote:
| Closed? How? Genuinely want to know more. Don't have much
| experience with ecosystem.
| gadr90 wrote:
| 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.
| boredtofears wrote:
| 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.
| fragmede wrote:
| arguably, the devrel does actually make it a better
| option though
| gadr90 wrote:
| That is true. Good docs, examples and community wins.
| meiraleal wrote:
| This is exactly how my best friends and family would write in
| my Show HN if I ever post one.
| gadr90 wrote:
| 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 :)
| bitbasher wrote:
| "One" isn't the right name. I think "Oni" would have been more
| fitting.
| guilhermecgs wrote:
| Can I use it for other platforms,. Like lg tv os webos? Samsung
| tv?
| guilhermecgs wrote:
| Edit: Not now, but maybe in the future
| dimgl wrote:
| This looks awesome!!!! I've wanted something like this for SO
| LONG.
| bartozone wrote:
| 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.
| elif wrote:
| What's the process like for migrating an existing react app to
| one?
| inopinatus wrote:
| refreshing attitude, keep it up
| cabalamat wrote:
| > 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.
| mplewis wrote:
| 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.
| aatd86 wrote:
| Every problem can be solved by adding an extra layer of
| indirection xD
| xutopia wrote:
| I love how the influence of Rails comes through here... there is
| definitely a flavour of convention over configuration with this
| framework. Nice work!
| profsummergig wrote:
| Someone please clarify what "local-first" means in this context.
| Thank you.
| throwaway314155 wrote:
| 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.
| ochiba wrote:
| 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/
| profsummergig wrote:
| 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.
| ericyd wrote:
| 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.
| josephg wrote:
| 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/
| gorbypark wrote:
| 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?
___________________________________________________________________
(page generated 2024-10-04 23:00 UTC)