[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2ucd2kqk5wvug":3},{"code":4,"message":5,"data":6,"timestamp":36},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":22,"summary_md":23,"topic":24,"github_topics":27,"license":32,"homepage":33,"updated_at":34,"history":35},"longbridge\u002Fnsh",14,"NSH runs modules written in TSX — natively on iOS, Android, macOS, Windows, Linux, GPUI and the web","Rust",620,48,58,10,[16],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},50151934,"Native Shell – a Rust runtime for dynamically delivered native UI",2,1,"2026-10-19","A Rust-built native UI framework where apps and screens are written in TSX or Rust and rendered with each platform's own views.","NSH wants you to write a screen once and have it show up with genuine native widgets on phones, desktops and the browser. It is early (first release 0.1.1), so the sensible way to read this review is as a map of the design and its boundaries, not an endorsement for shipping.\n\n## The problem\n\nCross-platform UI usually forces a choice: write native code per platform, or accept a webview-rendered UI that looks and behaves unlike the host. You want one set of components, state and layout rules, but menus that behave like desktop popups, sheets that slide like phone dialogs, and text input that uses the platform's own keyboard. NSH changes that step by rendering your components through UIKit on iOS, Win32 on Windows, GTK 4 on Linux, and HTML on the web, while sharing a reactive engine and flexbox\u002Fgrid layout across them. The result is one codebase that packages as a standalone app or embeds into an existing native app.\n\n## What's different\n\nThe interesting mechanism is the split between authoring and rendering. You can write the whole app in Rust, screens in TSX, or mix them so TSX imports Rust components. On the TSX side the engine loads modules at run time, which the authors position for plugins and AI-generated UI, delivered as signed packages and run in a host-configured sandbox. A single Rust-built `nsh` CLI covers init, run, hot updates and packaging.\n\nTwo trade-offs stand out. First, the design is deliberately unstyled: `nsh\u002Fbase` supplies behavior and accessible structure, but colors, typography, spacing and motion are the app's responsibility, with Tailwind classes and shadcn-derived theme tokens on the TSX side. That buys app-owned looks at the cost of assembling your own component library. Second, each desktop uses its own backend, so behavior can differ across AppKit, Win32 and GTK 4; the GPUI backend is an additional target rather than a replacement. Runtime-loaded, signed TSX packages are an architectural capability described in the README, not something this review can vouch for in practice.\n\n## Who should try it\n\nGood fit: a team already comfortable in Rust and TypeScript, building an app that must appear native on several platforms, and willing to own its visual design through primitives. The \"embed in an existing native app\" examples are the clearest reason to choose it over a from-scratch toolkit. Poor fit: someone who wants batteries-included widgets and a settled API. At version 0.1.1 the framework is explicitly early, and the unstyled base means a visually finished app requires significant design work before the framework's value shows up.\n\n## Requirements and limitations\n\nPlatform floors are concrete: iOS 15+, Android 9 (API 28)+, macOS 14+, Windows 10 1809+, GTK 4.14+ on Linux, and Vulkan for GPUI on Linux. Those floors rule out older devices and some long-lived Linux desktops, and building for iOS or Android still needs Xcode or the Android SDK. The Rust path needs both `nsh` and Rust, while the TSX path needs only `nsh` for authoring; installers exist for macOS\u002FLinux via script, Homebrew, and Windows via PowerShell.\n\nOngoing upkeep is the bigger question. The README documents hot updates for TSX but says Rust changes require rebuild and restart, and the install script can update the CLI and the source checkout kept at `~\u002F.nsh\u002Fsource`. Whether the component behavior and theming APIs stay stable enough to avoid frequent rewrites is unknown from the README alone; check the [installation and platform notes](https:\u002F\u002Fnsh.dev\u002Fdocs\u002Finstallation) and the [goals document](https:\u002F\u002Fnsh.dev\u002Fdocs\u002Fgoals) before committing.\n\n## HotRepo's take\n\nHotRepo recorded 614 total stars on the NEW-REPOSITORY board (rust, #14) on 2026-10-25, with coverage spanning only 2026-10-24 to 2026-10-25. That is a dated snapshot, not a growth curve, and persistence cannot be judged from two observation dates on a ten-day-old repository. Treat the design as worth reading and the API as worth verifying: the specific thing to check is whether the unstyled `nsh\u002Fbase` primitives and theme tokens give you enough of a component foundation for the screens you actually need.",{"slug":25,"name":26},"developer-tools","Developer Tools",[28,29,30,31],"cross-platform","gui","native","nsh","NOASSERTION","https:\u002F\u002Fnsh.dev","2026-10-25T02:51:28Z",[],1792921268]