-
Notifications
You must be signed in to change notification settings - Fork 0
Technology Stack
Status: Planning - No decisions made yet
This document tracks technology stack options and decisions for Zelara.
Based on architectural constraints, we need:
- Cross-platform - Same codebase for Desktop (Windows/Mac/Linux), Mobile (iOS/Android), Web
- Edge-first - Runs locally, no server dependency
- On-device AI/CV - For recycling image validation
- Device linking - Cross-device communication for task offloading
- Conditional builds - Ability to include/exclude modules at build time
- Git submodule integration - Build system must work with dynamic submodules
Pros:
- True cross-platform (single codebase for all platforms)
- Compiled to native binaries (good performance)
- Built-in device communication patterns
- Good support for on-device ML (TensorFlow Lite integration)
- Hot reload for fast development
Cons:
- Dart language (less familiar, smaller ecosystem than JS/TS)
- Larger app size
- Web support less mature than mobile/desktop
Fit for Zelara:
- ✅ Cross-platform
- ✅ Edge-first (compiles to native)
- ✅ On-device AI (TFLite plugins)
- ✅ Device linking (isolates for task offloading, platform channels)
⚠️ Conditional builds (possible but less common pattern)
Pros:
- TypeScript/JavaScript (familiar, huge ecosystem)
- React Native for mobile (mature, widely used)
- Tauri for desktop (lightweight, Rust-powered, secure)
- Tauri can bundle web version too
- Rust backend for heavy processing (perfect for CV, calculations)
- Smaller app size than Electron
Cons:
- Two separate frameworks (RN for mobile, Tauri for desktop/web)
- Complexity in sharing code between RN and Tauri
- More moving parts
Fit for Zelara:
⚠️ Cross-platform (RN + Tauri = 2 frameworks, but both use JS/TS for UI)- ✅ Edge-first (Tauri compiles to native with Rust backend)
- ✅ On-device AI (Rust can run ONNX/TensorFlow models efficiently)
- ✅ Device linking (Rust backend perfect for task offloading)
- ✅ Conditional builds (Tauri has modular plugin system)
Pros:
- TypeScript/JavaScript everywhere
- React Native for mobile (mature)
- Electron for desktop (very mature, huge ecosystem)
- Shared React codebase for UI
- Lots of examples and libraries
Cons:
- Electron apps are heavy (bundles Chromium)
- Poor performance compared to native
- Not ideal for edge/offline computing
- Large app size
Fit for Zelara:
⚠️ Cross-platform (Electron for desktop, RN for mobile, separate web build)⚠️ Edge-first (Electron heavy, not optimized for edge computing)⚠️ On-device AI (possible but slower than native)⚠️ Device linking (possible but not ideal architecture)⚠️ Conditional builds (possible but Electron not designed for modularity)
Verdict: Not ideal for Zelara's edge-first principle.
Pros:
- Familiar to most developers
- Huge ecosystem (npm)
- Works with React Native, Tauri, Electron
- Good tooling, type safety
- AI assistants very familiar with TS
Cons:
- Not as performant as Rust for heavy compute
- Requires runtime (Node.js/Deno/Bun)
Fit for Zelara:
- ✅ UI layer (React/React Native)
⚠️ Heavy processing (CV, calculations) - not ideal- ✅ Business logic (state management, skill tree)
Pros:
- Extremely fast (compiled, zero-cost abstractions)
- Memory safe (no garbage collection overhead)
- Perfect for on-device AI/CV
- Works great with Tauri
- Growing ecosystem
Cons:
- Steep learning curve
- Slower development velocity
- Smaller ecosystem than JS/TS
- Less familiar to AI assistants (but still capable)
Fit for Zelara:
⚠️ UI layer (possible but less common)- ✅ Heavy processing (CV, calculations) - perfect
- ✅ Backend logic (device linking, build system)
Pros:
- Designed for Flutter
- Good performance
- Type-safe
- Hot reload
Cons:
- Only useful with Flutter
- Smaller ecosystem than JS/TS or Rust
- Less familiar
Fit for Zelara:
- ✅ Everything (if using Flutter)
- ❌ Not applicable (if not using Flutter)
Proposal:
- Mobile: React Native (TypeScript for UI)
- Desktop/Web: Tauri (TypeScript for UI, Rust for backend)
- Shared logic: TypeScript business logic (state, skill tree, API)
- Heavy processing: Rust (CV, calculations, device linking backend)
Architecture:
┌─────────────────────────────────────────┐
│ TypeScript (Shared) │
│ - Business logic │
│ - State management │
│ - Skill tree engine │
└─────────────────────────────────────────┘
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ React Native │ │ Tauri │
│ (Mobile) │ │ (Desktop/Web) │
│ - TypeScript UI │ │ - TypeScript UI │
│ │ │ - Rust Backend │
└──────────────────┘ └──────────────────┘
│ │
└────────┬────────────────┘
▼
┌─────────────────┐
│ Rust (Heavy) │
│ - CV/AI │
│ - Calculations │
│ - Device link │
└─────────────────┘
Benefits:
- Leverage TypeScript for rapid development (UI, business logic)
- Leverage Rust for performance-critical tasks (CV, compute)
- Code reuse across platforms (shared TS logic)
- Best tool for each job
Challenges:
- Complexity of 2 frameworks + 2 languages
- Bridge between TS and Rust (FFI, platform channels)
- Build system more complex
Pros:
- Designed for mobile/edge
- Good model compression
- Works on all platforms
- Flutter plugins available
- React Native support via community packages
Cons:
- Focused on inference (not training)
- Limited model architectures
Fit for Zelara: ✅ Good for recycling image validation
Pros:
- Cross-platform (Windows, Mac, Linux, iOS, Android, Web)
- Framework-agnostic (convert from PyTorch, TensorFlow, etc.)
- Good performance
- Rust bindings available
Cons:
- Larger than TFLite
- More complex setup
Fit for Zelara: ✅ Flexible, works with Rust backend
Pros:
- Native platform integration
- Best performance on respective platforms
- Platform-optimized
Cons:
- Platform-specific (need separate models)
- More development overhead
Fit for Zelara:
Pros:
- Smallest size
- Fastest inference
- Full control
Cons:
- Requires ML expertise
- Need to train and maintain models
- May not match pre-trained model accuracy
Fit for Zelara:
Rationale:
- TypeScript for UI and business logic (fast development, familiar to AI)
- Rust for heavy processing (CV, device linking, calculations)
- React Native for mobile (mature, widely used)
- Tauri for desktop/web (lightweight, Rust-powered, secure)
- ONNX Runtime for on-device AI (cross-platform, works with Rust)
Trade-offs:
- More complex than single-framework solution (Flutter)
- Better performance and flexibility than Electron
- Leverages strengths of each technology
Framework Decision: React Native + Tauri + Rust (Hybrid)
Rationale:
- React Native for mobile (mature, widely used, TypeScript)
- Tauri for desktop (lightweight, Rust-powered, secure)
- Best balance of performance, code reuse, and edge-first principles
- Leverages TypeScript for rapid UI/business logic development
- Leverages Rust for high-performance CV and device linking
Language Strategy: TypeScript + Rust Hybrid
- TypeScript: UI components, business logic, state management, skill tree
- Rust: On-device CV/ML, complex calculations, device linking backend
- Maximizes development speed (TS) while optimizing performance-critical paths (Rust)
On-Device AI: ONNX Runtime with Rust bindings
- Cross-platform (Desktop + Mobile)
- Framework-agnostic (can use PyTorch/TensorFlow models)
- Good performance with Rust
- Supports ML-based recycling validation (bag classification, content detection)
MVP Platform: Mobile + Desktop (both required)
- Mobile: Primary UI, camera for recycling photos, daily tasks
- Desktop: Processing hub for CV/ML tasks, device linking server
- Proves device linking from day 1
Code Sharing Strategy: Duplicate UI components per app
- Each app (mobile, desktop) maintains own components
- Shared business logic via TypeScript packages in core
- Simpler dependency management, faster iteration
Alternatives Considered:
- Flutter: Simpler single framework but Dart language less familiar, conditional builds more complex
- Electron: Too heavy for edge-first principle, poor performance
- Pure TypeScript: Not performant enough for on-device CV/ML
Implementation Impact:
- Need Rust environment setup for desktop app development
- Need React Native environment for mobile app development
- Shared TypeScript packages in core for business logic
- ONNX models need conversion/optimization for edge deployment
Technology stack is now locked. Implementation can proceed.