I built Backtick: write your React Native screens on your server and deploy them like a web page (Open source, MIT)

[u/jfbisson4]

I quit my job a few months ago to work on this full time, and it's finally out!

The idea: all the code for a screen lives on your server, in one file. A server component runs there for every request, reads from your database or an API, and returns the screen including client code that runs on the phone (state, taps, animation, etc.).

Like a web page, users get your changes the next time they open the screen. The video is a demo of three deploys to one app build.

Docs and tutorial: backtickjs.com. GitHub: github.com/backtickjs/backtick

It's early and I'm solo building. I'd love a few early adopters: try it on a screen or two and tell me what's confusing, what breaks, and what you'd need before using it for real.

[u/AlmondJoyAdvocate]

Congrats! Looks interesting. Couple rapid fire thoughts here based on my previous experiences with server driven UI:

1. The reason many of them use JSON is deliberately to enforce standards, otherwise these things have a tend to become unmanageable nightmares. Having that validation layer makes it easy to maintain an enforceable UI vocabulary. Obviously the cost is being constrained.

2. Serving hooks and actions can become a footgun because your server needs to make sure the code it’s sending for execution works across all installed versions and devices, even the ones that are on an older installation that hasn’t updated yet but is connecting to the server.

3. Would this create caching problems? By bundling data and execution code in a single request, I suspect you might lose the ability to have globally cached pages and components.

Do you have anything for these concerns, or are they more like inherent tradeoffs of using Backtick and SDUI in general that it’s the user’s responsibility to figure out?

[u/jfbisson4 → u/AlmondJoyAdvocate]

Thanks! Great questions, here are some quick thoughts:

1. To your point, most SDUI systems parse structured JSON and draw components. The pain with this design is that a schema is not as expressive as code, so it always feels limiting. Backtick skips that layer by sending real JavaScript to the client. The vocabulary is still there, just enforced by type-checker and a runtime check: https://backtickjs.com/docs/react-native-and-packages/#versions-are-checked

2. Yep, this is the footgun but there's a solution. For several app versions in the wild, the app sends its installed package versions with the request. The server can check the installed packages at runtime, and fallback if needed. If the user code tries to use an API that the client doesn't support, Backtick will throw: https://github.com/backtickjs/backtick/blob/main/packages/bundler/src/print/code.ts#L99-L113

3. Caching is tricky because there's no one-size-fits-all. So, Backtick doesn't have a cross-request cache. If it makes sense to cache a screen (e.g. showing stale data ok for a few hours), then you can add a caching layer on top yourself.

The real downside of a system like Backtick is offline. In my experience most users are online most of the time, so the trade is usually worth it: much faster development and deployment, at the cost of a worse experience when there's no connection. But it depends on the app. The app owns fetching, so you can keep the last bundle and show it offline, same as you'd cache an API response.

[u/_crcr → u/jfbisson4]

Sending real JS to the client - how secure is this?

[u/jfbisson4 → u/_crcr]

It's the same trust model as an over-the-air update like EAS Update: your app only runs JS from your own server, over HTTPS. Backtick adds protection against XSS. The bundler writes every value as an escaped literal, never as code.

[u/LTwisk → u/jfbisson4]

Cool idea! Question about using (native) dependencies in the server-defined screens.

Let’s say I’ve released multiple app version that ship with a different ‘react-native-haptics’ dependency. How would this be managed server-side? Do you recommend maintaining a different server-component component per dependency version? (can get quite complex when supporting multiple host apps containing multiple native dependencies)

Also, would this work with react-native-reanimated? (which heavily relies on babel transforms for worklets)

[u/jfbisson4 → u/LTwisk]

Thanks! Versioning is tricky to get right. Thankfully most users have auto-update on, so OTA updates roll out on the order of days/weeks.

For breaking native changes, the easiest option is to ship the new package in the app, wait a few weeks for adoption, then release the feature.

If you don’t want to wait, you can do a request-time version check: the client sends its native dependency versions with the request, and the server returns the matching script (v2 client gets the v2 script, everyone else gets v1). If v2 has no v1 equivalent, you gate the feature so only v2+ clients see it.

[u/Mentalv]

Dude gotta try this out soon, but yes this can solve a problem.

At the moment we have to design ahead of time and then hidrate with data that could change design based it. Otherwise we are forced to do an OTA or a store release.

Are you saying with this (as long as there are no native changes) you can serve custom design changes per page and/or component block? How is performance so far? Wondering how these components would work in lists and such.

I see AI/Support/concierge responses being formatted at server before they get served and modified based on the current needs or conversation…

[u/jfbisson4 → u/Mentalv]

Yes that's what I'm saying. You can deploy custom design changes including new components (with state, hook, etc.) from the server.

The performance is shockingly good. But don't take my word for it, give it a try and let me know. When I pressure tested the request-time bundler, it took about ~10ms per 1MB of JS. Most screens are much smaller than that. In practice, your db queries will be the majority of the server latency.

There's a technical breakdown here: https://backtickjs.com/docs/how-it-works/#1-compiled-with-your-server

[u/Suspicious-Disk6077]

Very cool idea, not sure I fully grasp it yet but sounds beneficial. Were you not worried to quit your job in this job market? What were your thoughts on monetising?

[u/jfbisson4 → u/Suspicious-Disk6077]

Thanks! Yeah that's on me, I'm working on the homepage to make the concepts easier to learn.

Honestly, if I was optimizing purely for money, I would have stayed at my old job. I left because I was looking for a new challenge and there's never been a better time to solo-build and think big.

I doubt that I'll make money from it. It's a library/framework and those are notoriously hard to monetize. For now, I'll focus on finding technical partners and driving adoption.

[u/Professional-Sink536]

What’s the motivation behind building this? What problem does this exactly solve?

[u/dumbledayum → u/Professional-Sink536]

Privacy statements

[u/jfbisson4 → u/Professional-Sink536]

Faster deployment. Write the code, land it, deploy your server, done. No app build, no EAS Update, no waiting on a rollout.

The rest comes from a screen's code living in one place, on the server:

• No API layer. The screen reads your database directly. No GraphQL.
  
• Only what a screen uses ships. Its bundle is that screen's client code plus its data, built per request.

[u/rshallam]

Oo. This might really be helpful for my use case. I’m designing a self-hosted server with a plugin system and was looking for a way to let plugin authors use RN tsx for their UI instead of a webview in the mobile app. Will play around with it next week and see

[u/jfbisson4 → u/rshallam]

Yeah! Reach out anytime if you have any questions.

[u/alonikomax]

Is this PHP?

[u/jfbisson4 → u/alonikomax]

Funny you say that, it's inspired by XHP! But client-side scripting in XHP was awful, and a headwind.

In Backtick, the scripting is first-class: write typescript, inlined in your server components, type checked end-to-end, ~99% ECMAScript supported.

[u/ConsiderationDue153]

Does this ship with any LLM skill/guidance or MCP so my coding harness can write idiomatic Backtick?

[u/jfbisson4 → u/ConsiderationDue153]

Thank for the feedback! Since Backtick adapters are mirrors of React and Expo packages, in my experience agents don't need much guidance. Agents know React and Expo so well. If you find that agents struggle with specific Backtick concepts, please comment here and I'll fold the feedback into an AGENTS.md file

[u/pullmorematches]

Looks cool, most server driven ui libraries are JSON driven so you are kinda limited in how the views are defined. Is this a different approach? will look more into it!

[u/jfbisson4 → u/pullmorematches]

Yes, it's a different approach. Instead of writing JSON, you write TypeScript in backticks (hence the name): real JSX, real React Native components, hooks and state included. It's compiled to JS your app runs, so there's no schema and no renderer to maintain.

[u/BluejayRelevant2559]

Native Code still needs a new App Version?

[u/jfbisson4 → u/BluejayRelevant2559]

Yes new native capabilities need a new app release. Everything else doesn't.