Plattformübersicht

NSH läuft auf Smartphones, Desktops und im Web: iOS, Android, macOS, Windows, Linux, GPUI und Webseiten. Jede Plattform hat ein eigenes Backend, das mit der nativen UI der Plattform zeichnet. Eine App besteht also aus UIKit-Views auf dem iPhone, AppKit-Views auf dem Mac, GTK-4-Widgets unter Linux, GPUI-Elementen in einer GPUI-App und HTML im Browser, jeweils mit Text, Eingabe, Barrierefreiheit und Dark Mode der Plattform. Alles oberhalb des Backends wird geteilt: Der reaktive Graph, der Renderer, das Taffy-Layout, die Komponenten und die nativen Module sind überall derselbe Rust-Code, sodass eine App auf allen Plattformen läuft. Eine in Rust geschriebene App besteht aus diesem Code und deinem Crate, ohne JavaScript-VM. Eine TSX-App führt ihre Module darauf mit QuickJS aus (Mit Rust entwickeln).

Auf jeder Plattform wird eine App auf zwei Arten genutzt: paketiert als installierbare App der jeweiligen Plattform (nsh package) oder eingebettet in eine eigene native App, unabhängig davon, ob der Host ein Rust-Root linkt oder TSX zur Laufzeit lädt. Entwickelt wird mit nsh run (Änderungen an Rust-Code bauen die App neu und starten sie neu, Änderungen an TSX sind Hot Updates).

#Auf einen Blick

• GPUI zeichnet Apps mit GPUI, dem Framework des Schwesterprojekts GPUI Kit, gleichermaßen auf macOS, Windows und Linux. Es ist das Backend für das Einbetten in GPUI- und GPUI-Kit-Apps, die ihr AppView in ihren eigenen Elementbaum setzen. Eigenständige Desktop-Apps laufen und werden mit dem jeweiligen Backend des Betriebssystems paketiert (AppKit, Win32, GTK 4).
• Web rendert Apps als HTML in einer Browserseite: nsh package --target web veröffentlicht eine statische Website für jeden Webserver oder CDN, wobei Engine und Crate einer Rust-App nach WebAssembly kompiliert werden. Eine eigene Seite bettet eine App mit createPlayer oder einem iframe ein. Es betreibt auch die Live-Demos und den Playground auf dieser Website.
• Mac Catalyst führt das iOS-Backend zu Entwicklungszwecken in einem iPhone-großen Fenster (390×844) auf einem Mac aus. Wähle es mit --target catalyst aus, um zu sehen, wie eine App auf einem Smartphone aussieht.

#Entwickeln und paketieren

nsh run wählt die eigene Plattform des Rechners, wenn du kein --target angibst: AppKit unter macOS, das GTK-Fenster unter Linux und das Win32-Fenster unter Windows. Smartphones erreicht man von einem Computer aus: iOS von einem Mac mit Xcode, Android von macOS, Linux oder Windows mit dem Android SDK (Installation).

Eine Rust-App (ihr nsh.json nennt die "root"-Komponente) wird aus ihrem Verzeichnis ausgeführt und paketiert: nsh baut den eigenen Runner der App für das Ziel, mit deinem Crate und ohne QuickJS. Eine TSX-App nennt ihren Einstiegspunkt:

# A Rust app, from its directory
nsh run --target macos             # or ios, android, windows, linux, web, catalyst
nsh package --target macos         # or ios, ios-simulator, android, windows, linux, web

# A TSX app
nsh run App.tsx --target macos     # or ios, android, windows, linux, gpui, web, catalyst
nsh package App.tsx --target macos

Jedes Desktop-Betriebssystem paketiert Apps mit seinem eigenen Backend, gebaut für den Rechner, auf dem es läuft: Eine Mac-App paketierst du auf einem Mac, eine Windows-App unter Windows und eine Linux-App unter Linux. Paketierung behandelt Ausgabe, Signierung und Icons für jedes Ziel.

#In eine native App einbetten

Ein Rust-Host bindet ein Rust-Root (Root::of::<App>()) als AppSource::Rust oder App::Rust ein und gibt seinen Engines die UI-Sets der App mit set_ui_sets, sodass TSX, das er lädt, die eigenen Komponenten und Module der App importiert. Jede View ist eine Engine, und eine App kann mehrere anzeigen. Der Host registriert auf jeder Plattform seine eigenen nativen Views, die Apps verwenden können (Native Komponenten).

#Für jede Plattform schreiben

Der größte Teil einer App braucht keine Plattformprüfungen: Elemente, Styles, Layout und Module verhalten sich überall gleich. Wo sich Plattformen unterscheiden, gibt NSH dem Unterschied einen festen Ort (Plattformspezifischer Code):

• Die Umgebung sagt, wo die App läuft: in Rust os(), idiom() und is_desktop() (nsh_core::prelude), in TSX platform.os, platform.idiom, platform.desktop und platform.select aus nsh. Das Betriebssystem ist iOS, Android, macOS, Windows, Linux oder das Web.
• Plattformspezifische Props stehen in TSX in ios={{…}}, android={{…}}, web={{…}} oder desktop={{…}} (desktop: macOS, Windows, Linux und Desktop-Browser).
• Die Eingabe folgt der Plattform. Smartphones erhalten Touch-Eingaben und die Software-Tastatur, Desktops Maus, Trackpad und Tastatur.

Die Komponenten einer App werden mit den Primitiven von NSH gezeichnet, sodass sie auf Desktops ebenso laufen wie auf Smartphones und auf beiden gleich aussehen. Ein Desktop-Layout wird aus den Primitiven aufgebaut (view, text, scroll, virtual_list, …; in TSX View, Text, Scroll, List, …) und einer Prüfung auf den Desktop, wie es beim Desktop-Layout der Galerie der Fall ist:

use nsh_core::prelude::*;

#[component]
pub fn Shell() -> impl IntoElement {
    // macOS, Windows, Linux and desktop browsers get a sidebar; phones get tabs.
    view()
        .flex_1()
        .child(if is_desktop() { sidebar_layout() } else { tab_layout() })
}

fn sidebar_layout() -> AnyElement {
    view().flex_1().flex_row().into_element()
}

fn tab_layout() -> AnyElement {
    view().flex_1().flex_col().into_element()
}

import { View } from "nsh";
import { platform } from "nsh";

export function Shell() {
  // macOS, Windows, Linux and desktop browsers get a sidebar; phones get tabs.
  return <View class="flex-1">{platform.desktop ? <SidebarLayout /> : <TabLayout />}</View>;
}

function SidebarLayout() {
  return <View class="flex-1 flex-row" />;
}

function TabLayout() {
  return <View class="flex-1 flex-col" />;
}

Jedes Backend listet auf, was es auf eigene Weise umsetzt: macOS, Windows, Linux, GPUI.

#Siehe auch

• Erste Schritte: eine erste App, auf jeder Plattform ausgeführt.
• Mit Rust entwickeln: in Rust geschriebene Apps sowie Rust mit TSX.
• Installation: die Tools, die jede Plattform benötigt.
• Architektur: was geteilt wird und was jedes Backend übernimmt.