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

> What is the added value of using it over just Expo?

My answer:

The added value of One is crossplatform compatibility with SSR, and HMR, all using Vite as the single bundler on all platforms.

Nate baked in his vxrn.dev project to get off of Metro and forked Expo Router to do that.

Since Expo Web has a large bundle size, requires NextJS for SSR, Solito for unified filesystem routing, and 2 bundlers: Metro as a bundler on RN plus a separate bundler like Webpack for web.

With One then all of that is integrated. With Zero as the optional data sync engine.

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

So yes, the fact One use one single bundler from the start is nice win.

Also, looking at the direction Expo is taking, I believe they will eventually introduce SSR mode to Expo Router in the future.

[1]: https://blog.expo.dev/expo-sdk-49-c6d398cdf740

Great context, thank you for sharing!

github link on the landing page seems to have been fixed, and leads to that repo now.

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:

https://magnemg.eu/the-different-tech-strategies-for-buildin...

thank you, the thing about metro bundler seem like it could make react-native less exotic and that article is really comprehensive

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.

Not, if you are programming in Clojure. With [1] SQL is as composable as datalog or any other Clojure data.

Compared to the strongly-typed deep embedding of SQL in Slick in Scala it is astonishing how useful something so simple can be.

[1]: https://github.com/seancorfield/honeysql

«Absence of evidence is not evidence of absence», seems to apply here.

There’s a good response to this article here:

https://news.ycombinator.com/item?id=40536581

`bend` is a convenience syntax that "just creates an in-place recursive function, immediately calls it with an initial state, and then assigns the end result to a local variable" ... "in a single statement, rather than needing to name a separate external auxilliary function that you'll only use once", according to the original author on Twitter: https://x.com/VictorTaelin/status/1791964640533958924 and https://x.com/VictorTaelin/status/1791996185449791932

But contrary to this, I think explicitly separating function declaration and function calling, in the following kind of syntax, would make it much clearer and less complected where the initial condition `tree = fork(0)` comes from. In the original example it came from `bend x = 0`, but here the function declaration is separate and the call more explicit: so it more obviously comes from `createTree(0)`:

    type Tree
      Branch { left, right }
      Leaf { value }

    def main():

      createTree(x):
        x < 3 ?
          Tree.Branch { left: createTree(x+1), right: createTree(x+1) }
        Tree.Leaf { value: 7 }

      createTree(0)

Besides not needing a local variable `tree` here, the unique thing here is the elimination of the else-clause, to reduce unnecessary nesting, and a rule that the language just early returns the last result of any nested condition. If it doesn't go into any nested condition, then it just returns the last result in the main function body (like Ruby). Without any `return` keywords needed in either case. Wouldn't this be quite beautiful?

Thanks for a masterfully written article, with an excellent overview of the problem and the language design choice.

It makes sense to have to opt-in to floats for performance in domains like scientific computing or graphics (where silent precision loss matters less). But in all other cases business logic (money etc.) would give you normal arithmetic as you would expect.

It also makes sense to not allow numbers to overflow to the Heap, but rather have the programmer take special care for exceptionally high numbers.

Having no shenanigans between the compiler output and the runtime output is also a sane choice (staying true to predictability / determinism).

All in all, it sounds like good language design choices for a Web Server and Business Applications focused language such as Roc.

Background:

While predicate logic (first-order logic) provides the logical foundation for logic programming (Prolog etc.) and databases, functional programming is based on the different formalism of the lambda calculus.

There are proposals to combine functional and logic programming paradigms into "functional logic programming" languages, but these involve mapping between the two rather than being purely based on predicate logic.

Abstract:

«Logic programming is a flexible programming paradigm due to the use of predicates without a fixed data flow.

To extend logic languages with the compact notation of functional programming, there are various proposals to map evaluable functions into predicates in order to stay in the logic programming framework.

Since amalgamated functional logic languages offer flexible as well as efficient evaluation strategies, we propose an opposite approach in this paper.

By mapping logic programs into functional logic programs with a transformation based on inferring functional dependencies, we develop a fully automatic transformation which keeps the flexibility of logic programming but can improve computations by reducing infinite search spaces to finite ones. «

Passkeys?

How? AFAIK a passkey is just a replacement for a password. If my passkey tells you I can authenticate as john.doe@gmail.com, how does that help with establishing trust and identity?

Maybe combined with biometrics like FaceID?

In Sweden we have the proprietary BankID system, which is linked to one’s ‘personnummer’. (The personnummer is similar to SSN and compulsory for all citizens.)

https://www.bankid.com/en/foretag/secure-digital-identificat...

I think India has something similar?

Not sure if open source developers would be so keen on introducing requirements like that into the development process. Some developers want to keep a low profile and not reveal to much about their AFK identity. And nearly all tech for doing stuff like this is proprietary.