RedwoodJS is going into maintenance mode and is named Redwood GraphQL.
RedwoodSDK is the focus for the team going forward. "It begins as a Vite plugin that unlocks SSR, React Server Components, Server Functions, and realtime features". Which reminds me of the modular approach of Vike.dev (aka. vite-plugin-ssr).
Seems like the unbundled and modular approach won over the opinionated fullstack all-in-one framework approach.
Unbundled won over bundled approach, even for RedwoodJS itself (which is now renamed Redwood GraphQL):
"Unbundled Integrations:
Over the coming months, we'll progressively unbundle third-party integrations—such as the authentication providers, Storybook, and others. These integrations will then be independently maintained by their original teams or the community, giving you greater flexibility, faster updates, and control over which integrations you adopt and support."
No, because you can see when a website is using design components that imitate a particular platform (iOS, Android), like Ionic. Because the UI elements wouldn’t naturally look like that on a website if it wasn’t. They would look like standard HTML form elements.
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:
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.
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:
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.
The added value is crossplatform compatibility with SSR, and HMR, all using Vite as the single bundler on all platforms.
They baked in their 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 or whatnot for web.
Btw, here is a good React Native, Capacitor, NativeScript etc. overview:
If you like Lisp I presume you would prefer Datalog over SQL, as that is used in the Clojure related database Datomic. Datalog is much more elegant and composable than SQL.
See also earlier thread: https://news.ycombinator.com/item?id=43592998
RedwoodJS is going into maintenance mode and is named Redwood GraphQL.
RedwoodSDK is the focus for the team going forward. "It begins as a Vite plugin that unlocks SSR, React Server Components, Server Functions, and realtime features". Which reminds me of the modular approach of Vike.dev (aka. vite-plugin-ssr).
Seems like the unbundled and modular approach won over the opinionated fullstack all-in-one framework approach.
reply