I started using Kagi because I was tired of digging through ads and SEO spam just to find a straight answer. With Kagi I can actually search again. The interface is clean, the results load fast, and there’s far less noise. It reminds me of the early web – simple and straightforward – while still feeling modern. After a short time it mostly replaced AI chat tools for my search needs, because I’d rather read real sources than risk confident guesses.

What makes Kagi click for me is the focus on the result, not the revenue. I’m not forced to scroll past a wall of sponsored links or affiliate “roundups.” I type what I want and I get useful pages: docs, forums, blogs, papers. That’s the whole point of a search engine, and Kagi gets out of the way so I can reach the information faster.

Lenses: choose your slice of the web

The feature that sold me is Lenses. A Lens lets me choose which slice of the internet I want to look through. If I’m debugging, I set the lens to documentation or forums and I immediately get official references and real-world threads instead of generic SEO content. When I want deeper takes, I switch to blogs and personal sites to find people who actually built or tested the thing. One small toggle turns a vague query into a focused search. It also reduces the mental filtering I used to do on other engines—less skimming, more learning.

A simple, fast workflow

My workflow is straightforward. I start broad, then narrow. I’ll write the plain question first, see what comes back, and then steer with a Lens. I still use basic operators because they’re fast and predictable: exact phrases with "like this", excluding terms with -template, and pinning to a domain with site:docs.example.dev. Two or three promising tabs open in the background, I skim quickly, pick the winner, and close the rest. The whole loop feels efficient because the junk is mostly gone.

Why it replaced AI chat for me

Kagi helps me avoid the “confident but wrong” problem. Instead of a polished paragraph that might not be true, I get links to sources I can verify myself. It’s faster to trust what I can read than to audit an answer that only sounds right. For research, troubleshooting, and learning new tools, that difference matters. That’s why Kagi replaced AI chat in my search routine.

Trade-offs worth making

Kagi is paid, and I’m fine with that; the cost replaces the time I used to waste digging through ads. Index size and coverage can vary compared to the big engines, so once in a while I’ll check a second source. But the net effect is positive: less distraction, more signal, and better use of my attention.

Final thoughts

Kagi brings back intentional search. I spend less time fighting ads and second-guessing slick summaries, and more time reading the sources that matter. If you want the best parts of the old web—clean, useful, direct—Kagi delivers.

Modern software development frequently requires coordinating multiple programming languages within a single project ecosystem. In this article I tried to describe the challenges of managing Rust-to-TypeScript workflows and present a solution using Nix flakes, based on patterns observed in real-world development projects.

The examples presented here are hypothetical but derived from actual implementation patterns used in production environments where high-performance Rust libraries are compiled to WebAssembly and consumed by TypeScript frontend applications.

Common Challenges in Multi-Language Development

Projects that combine Rust and TypeScript typically encounter several coordination challenges:

• Toolchain Management: Different components require specific versions of Rust, Node.js, and associated build tools
• Build Reproducibility: Ensuring consistent compilation results across development, CI, and production environments
• Dependency Coordination: Managing the interface between Rust compilation outputs and TypeScript build processes
• Environment Consistency: Maintaining identical development setups across team members
• Branch Synchronization: Coordinating different versions of core libraries with corresponding frontend applications
• Manual Integration Steps: Copying build artifacts between repositories and maintaining build scripts

Traditional approaches using Docker containers, shell scripts, or manual environment management often prove insufficient for addressing the full scope of these coordination challenges.

Project Structure Analysis

Consider a typical multi-repository project structure combining Rust and TypeScript components:

project-ecosystem/
├── json-parser/              # Rust library for WebAssembly compilation
│   ├── Cargo.toml
│   ├── src/lib.rs
│   └── build.sh              # Build coordination script
├── web-application/          # Primary TypeScript application
│   ├── package.json
│   ├── webpack.config.js
│   ├── src/
│   └── src/utils/json_core/  # WebAssembly integration directory
├── dashboard/                # Secondary React application
│   ├── package.json
│   └── src/
└── integrations/             # Platform-specific TypeScript components
    ├── widget-a/
    ├── widget-b/
    └── iframe-embed/

This structure presents several operational challenges:

• Toolchain Synchronization: Each developer must maintain compatible versions of Rust, Node.js, wasm-pack, and related tools
• Build Script Complexity: Coordination scripts become increasingly complex as they handle cross-compilation, file copying, and dependency management
• Manual Artifact Management: WebAssembly files must be manually transferred from Rust build outputs to TypeScript project directories
• Branch Coordination: Different development branches require corresponding versions of core libraries
• CI/CD Complexity: Continuous integration systems require complex Docker configurations and dependency caching strategies

Nix Flakes as a Solution Framework

Nix flakes provide a declarative approach to managing multi-language development environments. The solution addresses the coordination challenges through:

• Unified Dependency Declaration: Single configuration files that specify exact tool versions and dependencies
• Environment Reproducibility: Identical development environments across all team members and deployment targets
• Automated Build Coordination: Programmatic integration between Rust compilation and TypeScript build processes
• Branch-Based Dependency Management: Dynamic dependency resolution based on git branch references

Foundational Flake Structure

A basic Nix flake for multi-language development begins with input declarations:

{
  description = "Multi-language development environment";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    rust-overlay.url = "github:oxalica/rust-overlay";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, rust-overlay, flake-utils }:
    # Implementation details follow
}

The inputs section declares external dependencies required for the project. The rust-overlay provides access to specific Rust toolchain versions, while flake-utils reduces boilerplate code.

Overlays enable precise version control for language-specific tools:

let
  overlays = [
    rust-overlay.overlays.default
    (final: prev: {
      # Specify exact Node.js version
      nodejs = prev.nodejs_20;
      yarn = prev.yarn.override { nodejs = prev.nodejs_20; };
    })
  ];
  
  pkgs = import nixpkgs {
    inherit system overlays;
  };
in

This approach eliminates version conflicts and ensures consistent toolchain availability across development environments.

Rust-to-WebAssembly Compilation Pipeline

The core challenge in Rust-to-TypeScript integration involves establishing a reliable compilation pipeline that handles:

1. Rust Library Development – Performance-critical code implementation

2. WebAssembly Cross-Compilation – Targeting the wasm32-unknown-unknown platform

3. TypeScript Binding Generation – Creating type-safe interfaces using wasm-bindgen

4. Build System Integration – Automating artifact delivery to frontend applications

5. Multi-Branch Coordination – Supporting different development environments

The following example demonstrates a comprehensive flake implementation for WebAssembly compilation. First, let's establish the required project structure:

Project Structure:

json-parser/
├── flake.nix
├── Cargo.toml
├── Cargo.lock
└── src/
    └── lib.rs

Cargo.toml:

[package]
name = "json-parser"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

[dependencies.web-sys]
version = "0.3"
features = [
  "console",
]

src/lib.rs:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);
}

#[wasm_bindgen]
pub struct ParseOptions {
    indent_size: u32,
    sort_keys: bool,
}

#[wasm_bindgen]
impl ParseOptions {
    #[wasm_bindgen(constructor)]
    pub fn new(indent_size: u32, sort_keys: bool) -> ParseOptions {
        ParseOptions { indent_size, sort_keys }
    }

    #[wasm_bindgen(getter)]
    pub fn indent_size(&self) -> u32 {
        self.indent_size
    }

    #[wasm_bindgen(getter)]
    pub fn sort_keys(&self) -> bool {
        self.sort_keys
    }
}

#[wasm_bindgen]
pub fn parse_json(json_string: &str) -> Result<String, JsValue> {
    let value: serde_json::Value = serde_json::from_str(json_string)
        .map_err(|e| JsValue::from_str(&e.to_string()))?;
    
    serde_json::to_string(&value)
        .map_err(|e| JsValue::from_str(&e.to_string()))
}

#[wasm_bindgen]
pub fn stringify_json(json_string: &str, options: &ParseOptions) -> Result<String, JsValue> {
    let value: serde_json::Value = serde_json::from_str(json_string)
        .map_err(|e| JsValue::from_str(&e.to_string()))?;
    
    if options.sort_keys {
        // For simplicity, just return pretty-printed JSON
        serde_json::to_string_pretty(&value)
            .map_err(|e| JsValue::from_str(&e.to_string()))
    } else {
        serde_json::to_string(&value)
            .map_err(|e| JsValue::from_str(&e.to_string()))
    }
}

#[wasm_bindgen]
pub fn validate_json(json_string: &str) -> bool {
    serde_json::from_str::<serde_json::Value>(json_string).is_ok()
}

flake.nix:

{
  description = "JSON parser WebAssembly package";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    rust-overlay.url = "github:oxalica/rust-overlay";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, rust-overlay, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];
        pkgs = import nixpkgs {
          inherit system overlays;
        };

        # Rust toolchain configuration with WebAssembly target
        rustToolchain = pkgs.rust-bin.stable.latest.default.override {
          extensions = [ "rust-src" "clippy" "rustfmt" ];
          targets = [ "wasm32-unknown-unknown" ];
        };

        # WebAssembly build function
        buildJsonParserWasm = pkgs.rustPlatform.buildRustPackage rec {
          pname = "json-parser";
          version = "0.1.0";
          src = ./.;

          cargoLock = {
            lockFile = ./Cargo.lock;
          };

          nativeBuildInputs = with pkgs; [
            rustToolchain
            wasm-bindgen-cli
            pkg-config
          ];

          buildInputs = with pkgs; [
            openssl
          ] ++ pkgs.lib.optionals pkgs.stdenv.isDarwin [
            pkgs.darwin.apple_sdk.frameworks.Security
            pkgs.darwin.apple_sdk.frameworks.SystemConfiguration
          ];

          # Custom build phase for WebAssembly compilation
          buildPhase = ''
            runHook preBuild

            export HOME=$TMPDIR
            export CARGO_HOME=$TMPDIR/.cargo

            # Build the WebAssembly binary
            cargo build --lib --release --target wasm32-unknown-unknown

            # Generate TypeScript bindings
            mkdir -p pkg
            wasm-bindgen target/wasm32-unknown-unknown/release/json_parser.wasm 
              --out-dir pkg 
              --target web 
              --typescript

            runHook postBuild
          '';

          # Install WebAssembly artifacts
          installPhase = ''
            runHook preInstall
            mkdir -p $out/pkg
            cp -r pkg/* $out/pkg/
            runHook postInstall
          '';

          doCheck = false;
        };

      in
      {
        packages.default = buildJsonParserWasm;

        # Development environment
        devShells.default = pkgs.mkShell {
          buildInputs = with pkgs; [
            rustToolchain
            wasm-bindgen-cli
            pkg-config
            openssl
          ];

          shellHook = ''
            echo "JSON Parser WebAssembly development environment"
            echo "Available commands:"
            echo "  cargo build --target wasm32-unknown-unknown"
            echo "  cargo test"
            echo "  nix build  # Build WASM package"
          '';
        };
      });
}

To use this, create the directory structure, add the files above, then run:

# Generate Cargo.lock
nix develop
cargo generate-lockfile

# Build the WebAssembly package
nix build

Advanced WebAssembly Build Patterns

Multi-Target Builds

When building WebAssembly modules, you often need to support different JavaScript environments. Each target (web browsers, Node.js, bundlers like Webpack) has different requirements for how the WASM module is loaded and initialized. This pattern allows you to build all variants simultaneously, ensuring your library works across all deployment scenarios.

buildMultiTargetWasm = { pname, src }:
  let
    targets = [
      { name = "web"; target = "web"; }
      { name = "nodejs"; target = "nodejs"; }
      { name = "bundler"; target = "bundler"; }
    ];
    
    buildTarget = { name, target }: pkgs.runCommand "${pname}-${name}" {
      nativeBuildInputs = [ rustToolchain wasm-pack ];
    } ''
      cp -r ${src} source
      cd source
      wasm-pack build --target ${target} --out-dir $out
    '';
  in
  pkgs.symlinkJoin {
    name = "${pname}-multi-target";
    paths = map buildTarget targets;
  };

Feature-Based Builds

Rust's feature flags allow you to compile different variants of your library with specific functionality enabled or disabled. This is particularly useful for WebAssembly where you might want a lightweight version for simple use cases and a full-featured version for complex applications. This pattern automates building multiple feature combinations.

buildWasmVariants = { pname, src, variants }:
  let
    buildVariant = { name, features ? [], optimizeSize ? true }:
      buildWasmLibrary {
        inherit pname src features optimizeSize;
        version = "${name}-variant";
      };
  in
  pkgs.linkFarm "${pname}-variants" 
    (map (variant: {
      name = variant.name;
      path = buildVariant variant;
    }) variants);

Frontend Integration Architecture

The frontend integration component addresses the coordination challenges between Rust compilation outputs and TypeScript build processes. This implementation demonstrates automated WebAssembly artifact management:

For a practical MVP, here's a working frontend integration. First, the project structure:

Frontend Project Structure:

web-app/
├── flake.nix
├── package.json
├── webpack.config.js
├── tsconfig.json
├── src/
│   ├── index.html
│   ├── index.tsx
│   ├── components/
│   │   └── JsonEditor.tsx
│   ├── hooks/
│   │   └── useJsonService.ts
│   └── utils/
│       └── json_parser/
│           └── (WASM files will be placed here)
└── json-parser-flake/  # Local reference to the Rust project

package.json:

{
  "name": "json-editor-app",
  "version": "1.0.0",
  "scripts": {
    "dev": "webpack serve --mode development",
    "build": "webpack --mode production",
    "parser:build": "nix run .#build-parser",
    "parser:clean": "nix run .#clean-parser"
  },
  "devDependencies": {
    "webpack": "^5.88.0",
    "webpack-cli": "^5.1.0",
    "webpack-dev-server": "^4.15.0",
    "typescript": "^5.1.0",
    "ts-loader": "^9.4.0",
    "html-webpack-plugin": "^5.5.0",
    "@types/react": "^18.2.0"
  },
  "dependencies": {
    "preact": "^10.19.0"
  }
}

webpack.config.js:

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  entry: './src/index.tsx',
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
    alias: {
      'react': 'preact/compat',
      'react-dom': 'preact/compat'
    },
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
    clean: true,
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
    }),
  ],
  devServer: {
    static: './dist',
    port: 8080,
  },
  experiments: {
    asyncWebAssembly: true,
  },
};

flake.nix:

{
  description = "Frontend application with WebAssembly integration";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };

        # Build JSON parser from local flake
        buildJsonParser = pkgs.writeShellApplication {
          name = "build-json-parser";
          runtimeInputs = [ pkgs.nix ];
          text = ''
            echo "Building JSON parser from local flake..."
            
            # Create the directory where WASM files will live
            mkdir -p src/utils/json_parser
            rm -f src/utils/json_parser/*
            
            # Build from local json-parser-flake directory
            if [ -d "./json-parser-flake" ]; then
              result=$(nix build ./json-parser-flake --no-link --print-out-paths)
              if [ -d "$result/pkg" ]; then
                cp "$result"/pkg/* src/utils/json_parser/
                echo "✅ JSON parser built successfully"
              else
                echo "❌ No pkg directory found in build result"
                exit 1
              fi
            else
              echo "❌ json-parser-flake directory not found"
              echo "Please create a symlink: ln -s ../json-parser json-parser-flake"
              exit 1
            fi
          '';
        };

        # Clean up function
        cleanJsonParser = pkgs.writeShellApplication {
          name = "clean-json-parser";
          text = ''
            rm -f src/utils/json_parser/*
            echo "✅ Cleaned JSON parser artifacts"
          '';
        };

      in
      {
        # Apps for easy access
        apps = {
          build-parser = flake-utils.lib.mkApp {
            drv = buildJsonParser;
          };
          clean-parser = flake-utils.lib.mkApp { 
            drv = cleanJsonParser; 
          };
        };

        # Packages
        packages = {
          build-parser = buildJsonParser;
          clean-parser = cleanJsonParser;
        };

        # Development environment
        devShells.default = pkgs.mkShell {
          buildInputs = with pkgs; [ nodejs_20 yarn ];
          shellHook = ''
            echo "Frontend Development Environment"
            echo "Available commands:"
            echo "  yarn parser:build  - Build JSON parser WASM"
            echo "  yarn parser:clean  - Clean WASM artifacts"
            echo "  yarn dev          - Start development server"
            echo ""
            echo "First time setup:"
            echo "  ln -s ../json-parser json-parser-flake"
            echo "  yarn install"
            echo "  yarn parser:build"
          '';
        };
      });
}

Setup Instructions:

1. Create both json-parser/ and web-app/ directories

2. In web-app/, create a symlink: ln -s ../json-parser json-parser-flake

3. Run nix develop in web-app/

4. Run yarn install

5. Run yarn parser:build to build the WASM module

6. Run yarn dev to start the development server

TypeScript Integration Patterns

The WebAssembly integration generates TypeScript definitions through wasm-bindgen, enabling type-safe consumption of Rust functionality. The following example demonstrates typical usage patterns:

src/utils/json_parser/index.ts:

// Wrapper service for the WebAssembly JSON parser
import init, { 
  parse_json, 
  stringify_json, 
  validate_json,
  ParseOptions 
} from './json_parser';

export class JsonService {
  private initialized = false;
  
  async initialize(): Promise<void> {
    if (!this.initialized) {
      await init();
      this.initialized = true;
    }
  }
  
  async parseJson(jsonString: string): Promise<string> {
    await this.initialize();
    return parse_json(jsonString);
  }
  
  async stringifyJson(jsonString: string, options: { indent_size: number, sort_keys: boolean }): Promise<string> {
    await this.initialize();
    const wasmOptions = new ParseOptions(options.indent_size, options.sort_keys);
    return stringify_json(jsonString, wasmOptions);
  }
  
  async validateJson(jsonString: string): Promise<boolean> {
    await this.initialize();
    return validate_json(jsonString);
  }
}

src/index.html:

<!DOCTYPE html>
<html>
<head>
    <title>JSON Parser Demo</title>
    <style>
        body { 
            font-family: Arial, sans-serif; 
            margin: 20px; 
            background-color: #f9f9f9;
        }
        .container {
            max-width: 800px;
            margin: 0 auto;
            background: white;
            padding: 20px;
            border-radius: 8px;
            box-shadow: 0 2px 4px rgba(0,0,0,0.1);
        }
        textarea { 
            width: 100%; 
            height: 200px; 
            margin: 10px 0; 
            padding: 10px;
            border: 2px solid #ddd;
            border-radius: 4px;
            font-family: 'Courier New', monospace;
        }
        button { 
            padding: 10px 20px; 
            margin: 5px; 
            border: none;
            border-radius: 4px;
            background: #007bff;
            color: white;
            cursor: pointer;
        }
        button:hover {
            background: #0056b3;
        }
        button:disabled {
            background: #6c757d;
            cursor: not-allowed;
        }
        pre { 
            background: #f5f5f5; 
            padding: 15px; 
            border-radius: 4px; 
            border-left: 4px solid #007bff;
            font-family: 'Courier New', monospace;
            overflow-x: auto;
        }
        .error { 
            border-color: #dc3545 !important; 
            background-color: #fff5f5;
        }
        .valid { 
            border-color: #28a745 !important; 
            background-color: #f5fff5;
        }
        .status {
            padding: 10px;
            margin: 10px 0;
            border-radius: 4px;
        }
        .status.error {
            background: #f8d7da;
            color: #721c24;
            border: 1px solid #f5c6cb;
        }
        .status.valid {
            background: #d4edda;
            color: #155724;
            border: 1px solid #c3e6cb;
        }
    </style>
</head>
<body>
    <div id="app"></div>
</body>
</html>

src/hooks/useJsonService.ts:

import { useState, useEffect } from 'preact/hooks';
import { JsonService } from '../utils/json_parser';

export const useJsonService = () => {
  const [jsonService] = useState(() => new JsonService());
  const [isInitialized, setIsInitialized] = useState(false);

  useEffect(() => {
    const initializeService = async () => {
      try {
        await jsonService.initialize();
        setIsInitialized(true);
      } catch (error) {
        console.error('Failed to initialize JSON service:', error);
      }
    };

    initializeService();
  }, [jsonService]);

  return { jsonService, isInitialized };
};

src/components/JsonEditor.tsx:

import { useState } from 'preact/hooks';
import { useJsonService } from '../hooks/useJsonService';

interface JsonEditorProps {}

export const JsonEditor = ({}: JsonEditorProps) => {
  const { jsonService, isInitialized } = useJsonService();
  const [jsonText, setJsonText] = useState('{"name": "test", "value": 123}');
  const [output, setOutput] = useState('');
  const [status, setStatus] = useState<{ message: string; type: 'error' | 'valid' | '' }>({
    message: '',
    type: ''
  });
  const [inputClass, setInputClass] = useState('');

  const handleFormat = async () => {
    if (!isInitialized) {
      setStatus({ message: '⏳ WebAssembly module is still loading...', type: 'error' });
      return;
    }

    try {
      const formatted = await jsonService.stringifyJson(jsonText, {
        indent_size: 2,
        sort_keys: true
      });
      
      setOutput(formatted);
      setStatus({ message: '✅ JSON formatted successfully', type: 'valid' });
      setInputClass('valid');
    } catch (error) {
      setStatus({ message: `❌ Format error: ${error}`, type: 'error' });
      setInputClass('error');
      setOutput('');
    }
  };

  const handleValidate = async () => {
    if (!isInitialized) {
      setStatus({ message: '⏳ WebAssembly module is still loading...', type: 'error' });
      return;
    }

    try {
      const isValid = await jsonService.validateJson(jsonText);
      
      if (isValid) {
        setStatus({ message: '✅ JSON is valid', type: 'valid' });
        setInputClass('valid');
      } else {
        setStatus({ message: '❌ JSON is invalid', type: 'error' });
        setInputClass('error');
      }
    } catch (error) {
      setStatus({ message: `❌ Validation error: ${error}`, type: 'error' });
      setInputClass('error');
    }
  };

  const handleInputChange = (event: Event) => {
    const target = event.target as HTMLTextAreaElement;
    setJsonText(target.value);
    setInputClass('');
    setStatus({ message: '', type: '' });
  };

  return (
    <div className="container">
      <h1>JSON Parser Demo</h1>
      <p>This demo uses a Rust library compiled to WebAssembly for JSON processing.</p>
      
      <div>
        <h3>Input JSON:</h3>
        <textarea
          value={jsonText}
          onInput={handleInputChange}
          className={inputClass}
          placeholder="Enter JSON here..."
          disabled={!isInitialized}
        />
        
        <div>
          <button onClick={handleFormat} disabled={!isInitialized}>
            Format JSON
          </button>
          <button onClick={handleValidate} disabled={!isInitialized}>
            Validate JSON
          </button>
        </div>
        
        {status.message && (
          <div className={`status ${status.type}`}>
            {status.message}
          </div>
        )}
        
        <h3>Output:</h3>
        <pre>{output || 'No output yet...'}</pre>
        
        {!isInitialized && (
          <div className="status error">
            ⏳ Loading WebAssembly module...
          </div>
        )}
      </div>
    </div>
  );
};

src/index.tsx:

import { render } from 'preact';
import { JsonEditor } from './components/JsonEditor';

const App = () => {
  return <JsonEditor />;
};

render(<App />, document.getElementById('app')!);

tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ES2020",
    "moduleResolution": "node",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "jsx": "react-jsx",
    "jsxImportSource": "preact",
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist"]
}

The generated TypeScript definitions (created automatically by wasm-bindgen) will be in src/utils/json_parser/json_parser.d.ts and provide complete type information for the WebAssembly functions.

This integration pattern combines Rust's performance characteristics with TypeScript's type safety, eliminating manual interface management between the two language ecosystems.

Multi-Repository Coordination

Complex projects often involve multiple repositories that must coordinate shared dependencies. The following example demonstrates how Nix flakes can manage multiple TypeScript applications that consume the same WebAssembly library while maintaining branch-specific version alignment.

A coordination flake can manage the entire project ecosystem:

{
  description = "All my TypeScript/Rust projects working together";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    
    # The Rust JSON parser
    json-parser.url = "github:my-org/json-parser";
    
    # TypeScript applications that use it
    web-app.url = "github:my-org/web-app";
    dashboard.url = "github:my-org/dashboard";
    
    # Various integration widgets
    widget-a.url = "github:my-org/widget-a";
    widget-b.url = "github:my-org/widget-b";
  };

  outputs = inputs@{ self, nixpkgs, ... }:
    let
      system = "x86_64-linux";
      pkgs = import nixpkgs { inherit system; };
      
      # Collect all the packages I can build
      allPackages = pkgs.lib.foldl' (acc: input: 
        acc // (input.packages.${system} or {})
      ) {} (builtins.attrValues inputs);
      
    in
    {
      # One development environment to rule them all
      devShells.${system}.default = pkgs.mkShell {
        buildInputs = with pkgs; [
          # Basic tools
          git
          
          # Language toolchains - exact versions
          nodejs_20
          yarn
          rustc
          wasm-pack
          
          # Development tools
          typescript
          eslint
          prettier
        ] ++ (builtins.attrValues allPackages);
        
        shellHook = ''
          echo "🚀 Full-stack development environment"
          echo "Rust: json-parser"
          echo "TypeScript: web-app, dashboard, widget-a, widget-b"
          echo ""
          echo "Quick commands:"
          echo "  nix run .#build-all-parsers  - Build all WASM modules"
          echo "  nix run .#dev-all           - Start all dev servers"
        '';
      };
      
      # Convenience scripts
      packages.${system} = {
        # Build all the WebAssembly modules at once
        build-all-parsers = pkgs.writeShellScriptBin "build-all-parsers" ''
          echo "🦀 Building all Rust WebAssembly modules..."
          ${inputs.json-parser.packages.${system}.default}/bin/build-parser
          echo "✅ All WASM modules built"
        '';
        
        # Start all development servers
        dev-all = pkgs.writeShellScriptBin "dev-all" ''
          echo "🌐 Starting all development servers..."
          
          # Start each app in the background
          cd ${inputs.web-app} && yarn dev &
          WEB_PID=$!
          
          cd ${inputs.dashboard} && yarn dev &
          DASHBOARD_PID=$!
          
          cd ${inputs.widget-a} && yarn dev &
          WIDGET_A_PID=$!
          
          # Clean up when we exit
          trap "kill $WEB_PID $DASHBOARD_PID $WIDGET_A_PID" EXIT
          wait
        '';
      };
    };
}

This coordination approach provides a unified development environment that encompasses the entire project ecosystem, eliminating version management concerns and ensuring consistent toolchain availability across all components.

Branch-Based Dependency Management

Multi-repository projects require coordination between corresponding development branches. For example, a web application's development branch should consume the development version of its WebAssembly dependencies, while production branches should use stable releases.

This coordination can be achieved through package.json script integration:

{
  "scripts": {
    "parser:build": "nix run .#build-parser",
    "parser:clean": "nix run .#clean-parser",
    "dev": "yarn parser:build && webpack serve --mode development",
    "build": "yarn parser:build && webpack --mode production",
    "install-deps": "yarn install"
  }
}

Environment-specific development shells can automate branch coordination:

# Environment-specific development shells
devShells.${system} = {
  # Default development environment
  default = pkgs.mkShell {
    buildInputs = with pkgs; [ nodejs_20 yarn ];
    shellHook = ''
      echo "Development environment"
      echo "Run 'yarn dev' to start with current branch dependencies"
    '';
  };
  
  # Staging environment with beta branch dependencies
  staging = pkgs.mkShell {
    buildInputs = with pkgs; [ nodejs_20 yarn ];
    shellHook = ''
      echo "Staging environment (dependencies: beta branch)"
      nix run .#build-parser-beta
    '';
  };
  
  # Production environment with stable dependencies
  production = pkgs.mkShell {
    buildInputs = with pkgs; [ nodejs_20 yarn ];
    shellHook = ''
      echo "Production environment (dependencies: prod branch)"
      nix run .#build-parser-prod
    '';
  };
};

This approach enables developers to enter environment-specific shells using nix develop .#staging, automatically configuring the appropriate dependency versions for the target environment.

Advanced Patterns and Best Practices

Caching and Performance Optimization

Binary Caches

Binary caches are one of Nix's most powerful features for development teams. Instead of rebuilding everything from source, Nix can download pre-built packages from cache servers. This dramatically reduces build times, especially for large Rust projects with many dependencies. Setting up your own cache (like Cachix) means your team shares build artifacts, so if one developer builds a package, everyone else gets it instantly.

{
  nixConfig = {
    extra-substituters = [
      "https://cache.nixos.org"
      "https://your-org.cachix.org"
    ];
    extra-trusted-public-keys = [
      "cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY="
      "your-org.cachix.org-1:YOUR_PUBLIC_KEY_HERE"
    ];
  };
}

Incremental Builds

Large Rust projects can take a long time to compile, especially when dependencies change. This pattern separates dependency compilation from your source code compilation. Dependencies are built once and cached, then your source code builds much faster since it reuses the pre-built dependencies. This is particularly valuable in CI/CD pipelines where you want fast feedback loops.

buildRustPackageIncremental = { pname, src, ... }@args:
  let
    # Separate dependency building from source building
    deps = pkgs.rustPlatform.buildRustPackage (args // {
      pname = "${pname}-deps";
      src = pkgs.runCommand "deps-src" {} ''
        mkdir -p $out
        cp ${src}/Cargo.{toml,lock} $out/
        mkdir $out/src
        echo "fn main() {}" > $out/src/main.rs
      '';
      doCheck = false;
    });
  in
  pkgs.rustPlatform.buildRustPackage (args // {
    preBuild = ''
      cp -r ${deps}/target .
      chmod -R +w target
    '';
  });

Testing Across Languages

Integration Testing

When you have Rust code compiled to WebAssembly being consumed by TypeScript applications, you need tests that verify the entire pipeline works correctly. This isn't just about testing your Rust code or your TypeScript code in isolation – you need to test that the WebAssembly bindings work correctly, that data serialization/deserialization works as expected, and that the integration points behave properly under various conditions.

integrationTests = pkgs.runCommand "integration-tests" {
  buildInputs = with pkgs; [
    nodejs_20
    yarn
    rustc
    wasm-pack
    # Your compiled packages
    wasmLib
    frontendApp
  ];
} ''
  # Set up test environment
  export WASM_LIB_PATH=${wasmLib}/pkg
  export NODE_PATH=${frontendApp}/node_modules
  
  # Run integration test suite
  cd ${./tests}
  yarn install
  yarn test:integration
  
  touch $out
'';

Cross-Language Testing

This pattern ensures that your WebAssembly modules actually work when called from JavaScript/TypeScript. It's common for Rust code to work perfectly in isolation but fail when compiled to WebAssembly due to differences in memory management, string handling, or async behavior. These tests catch those issues early in the development process.

wasmIntegrationTests = pkgs.runCommand "wasm-integration-tests" {
  buildInputs = with pkgs; [ nodejs_20 rustLib wasmLib ];
} ''
  # Test Rust library directly
  cd ${rustLib.src}
  cargo test --release
  
  # Test WebAssembly bindings
  cd ${./tests/wasm}
  cat > test-wasm.js << 'EOF'
  const { parse_sql, format_sql } = require('${wasmLib}/pkg/core.js');
  
  // Test basic functionality
  const sql = "SELECT * FROM users WHERE id = 1";
  const parsed = parse_sql(sql);
  const formatted = format_sql(sql, { indent_size: 2 });
  
  console.log('Parsed:', parsed);
  console.log('Formatted:', formatted);
  
  if (!parsed || !formatted) {
    process.exit(1);
  }
  EOF
  
  ${pkgs.nodejs_20}/bin/node test-wasm.js
  
  touch $out
'';

Security and Reproducibility

Pinning Dependencies

One of the biggest challenges in software development is ensuring that your project builds the same way today as it will in six months. Dependencies get updated, APIs change, and suddenly your build breaks. Nix flakes solve this by pinning exact versions of all dependencies, including the Nix packages themselves. This ensures that your build is completely reproducible across time and different machines.

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11";
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
}

Security Scanning

Security vulnerabilities in dependencies are a major concern for production applications. This pattern integrates security scanning directly into your build process, automatically checking both Rust crates and npm packages for known vulnerabilities. By making security scanning part of your Nix flake, you ensure it runs consistently across all environments and can't be forgotten or skipped.

securityScan = pkgs.runCommand "security-scan" {
  buildInputs = with pkgs; [ cargo-audit yarn nodejs_20 ];
} ''
  mkdir -p $out
  
  # Rust security audit
  cd ${./rust-core}
  cargo audit --json > $out/rust-audit.json
  
  # TypeScript/JavaScript security audit  
  cd ${./frontend}
  yarn audit --json > $out/yarn-audit.json || true
  
  # Check for known vulnerabilities in dependencies
  yarn audit --level moderate --json > $out/vulnerability-report.json || true
'';

Implementation Example

This section presents a practical implementation based on patterns observed in production environments. The example demonstrates a JSON parsing library ecosystem that illustrates common multi-language coordination challenges and their solutions.

Project Architecture

Consider a JSON processing system consisting of:

• A high-performance Rust library compiled to WebAssembly
• A primary web application for JSON editing and validation
• An analytics dashboard for JSON data processing
• Various integration widgets for platform embedding

The following implementation demonstrates how Nix flakes address the coordination requirements:

{
  description = "My JSON tools ecosystem";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    rust-overlay.url = "github:oxalica/rust-overlay";
    
    # My Rust JSON parser
    json-parser.url = "github:my-org/json-parser";
  };

  outputs = { self, nixpkgs, rust-overlay, json-parser }:
    let
      system = "x86_64-linux";
      pkgs = import nixpkgs {
        inherit system;
        overlays = [ rust-overlay.overlays.default ];
      };

      # The WebAssembly version of my JSON parser
      jsonParserWasm = json-parser.packages.${system}.default;

      # Main web application
      jsonEditor = pkgs.buildNpmPackage {
        pname = "json-editor";
        version = "1.0.0";
        src = ./editor;
        npmDepsHash = "sha256-...";
        
        # This is where the magic happens - automatic WASM integration
        preBuild = ''
          mkdir -p src/utils/json_parser
          cp -r ${jsonParserWasm}/pkg/* src/utils/json_parser/
        '';
        
        buildPhase = ''
          yarn build
        '';
      };

      # Analytics dashboard
      dashboard = pkgs.buildNpmPackage {
        pname = "json-dashboard";
        version = "1.0.0";
        src = ./dashboard;
        npmDepsHash = "sha256-...";
        
        preBuild = ''
          mkdir -p src/utils/json_parser
          cp -r ${jsonParserWasm}/pkg/* src/utils/json_parser/
        '';
      };

      # Embeddable widget
      widget = pkgs.buildNpmPackage {
        pname = "json-widget";
        version = "1.0.0";
        src = ./widget;
        npmDepsHash = "sha256-...";
        
        preBuild = ''
          mkdir -p src/utils/json_parser
          cp -r ${jsonParserWasm}/pkg/* src/utils/json_parser/
        '';
      };

    in
    {
      packages.${system} = {
        inherit jsonEditor dashboard widget;
        
        # Everything bundled together for deployment
        all-apps = pkgs.runCommand "json-tools-deployment" {} ''
          mkdir -p $out/{editor,dashboard,widget}
          cp -r ${jsonEditor}/* $out/editor/
          cp -r ${dashboard}/* $out/dashboard/
          cp -r ${widget}/* $out/widget/
        '';
      };

      # My daily development environment
      devShells.${system}.default = pkgs.mkShell {
        buildInputs = with pkgs; [
          nodejs_20
          yarn
          typescript
          eslint
          prettier
        ];
        
        shellHook = ''
          echo "📝 JSON Tools Development Environment"
          echo "Available commands:"
          echo "  yarn editor:dev     - JSON editor dev server"
          echo "  yarn dashboard:dev  - Dashboard dev server"  
          echo "  yarn widget:dev     - Widget dev server"
          echo "  nix run json-parser#build-parser - Rebuild WASM"
        '';
      };
    };
}

This architecture enables automatic propagation of changes from the Rust library to all consuming TypeScript applications, eliminating manual artifact management and reducing the risk of version inconsistencies.

Development Workflow Analysis

The Nix flakes approach transforms the typical development workflow through several key improvements:

Environment Initialization: Developers begin work by executing nix develop, which provides a shell environment with precisely specified tool versions, eliminating version-related configuration issues.

Core Library Development: Changes to the Rust library follow standard development practices, with testing via cargo test and version control through git branches.

Frontend Integration: Frontend applications integrate updated WebAssembly modules through commands like yarn parser:build:dev, which automatically fetch, compile, and position artifacts according to the build configuration.

Multi-Application Testing: Development server orchestration enables simultaneous testing across multiple applications:

# Concurrent development server execution
nix run .#dev-all

Environment-Specific Deployment: Deployment processes utilize environment-specific configurations:

# Staging deployment
nix develop .#staging
yarn build:staging

# Production deployment
nix develop .#production
yarn build:prod

This workflow ensures consistent behavior across development machines, continuous integration systems, and deployment environments, effectively eliminating environment-specific build failures.

Performance Considerations and Optimization

Build Performance

Parallel Builds

Modern development machines have multiple CPU cores, but many build systems don't take full advantage of them. This configuration ensures that both Nix builds and Rust compilation use all available CPU cores, significantly reducing build times. This is especially important for large Rust projects where compilation can be the bottleneck in your development workflow.

{
  # Enable parallel building
  nixConfig = {
    max-jobs = "auto";
    cores = 0;  # Use all available cores
  };
}

# In package definitions
buildRustPackage {
  # ... other attributes
  
  # Parallel cargo builds
  cargoBuildFlags = [ "--jobs" "$NIX_BUILD_CORES" ];
  
  # Parallel tests
  cargoTestFlags = [ "--jobs" "$NIX_BUILD_CORES" ];
}

Build Caching Strategies

This advanced pattern addresses one of the most frustrating aspects of Rust development: waiting for dependencies to recompile when they haven't actually changed. By separating dependency builds from source builds, you can cache the expensive dependency compilation step and only rebuild your actual source code when it changes.

# Separate dependency builds from source builds
rustDependencies = pkgs.rustPlatform.buildRustPackage {
  pname = "${pname}-deps";
  inherit version src cargoLock;
  
  # Build only dependencies
  buildPhase = ''
    cargo build --release --frozen
  '';
  
  # Don't include source files in hash
  outputHashMode = "recursive";
  outputHash = "sha256-...";
};

# Main package reuses dependency build
mainPackage = pkgs.rustPlatform.buildRustPackage {
  inherit pname version src cargoLock;
  
  preBuild = ''
    cp -r ${rustDependencies}/target .
    chmod -R +w target
  '';
};

Runtime Performance

WebAssembly Optimization

WebAssembly modules can be optimized for different goals: smaller file size for faster downloads, or faster execution speed. The Binaryen toolkit provides powerful optimization tools that can significantly improve your WebAssembly performance. This pattern lets you build different optimized versions for different deployment scenarios.

optimizedWasm = pkgs.runCommand "optimized-wasm" {
  buildInputs = [ pkgs.binaryen ];
} ''
  # Size optimization
  wasm-opt -Oz ${inputWasm} -o $out/optimized.wasm
  
  # Speed optimization  
  wasm-opt -O3 ${inputWasm} -o $out/fast.wasm
  
  # Debug build
  cp ${inputWasm} $out/debug.wasm
'';

Memory Management

WebAssembly has different memory constraints than native applications. This configuration helps you optimize memory usage during both compilation and runtime, which is crucial for WebAssembly modules that will run in memory-constrained environments like browsers or edge computing platforms.

# Configure memory limits for builds
buildRustPackage {
  # ... other attributes
  
  # Limit memory usage during compilation
  NIX_CFLAGS_COMPILE = "-Wl,--max-memory=2147483648";  # 2GB limit
  
  # Optimize for memory usage
  RUSTFLAGS = "-C opt-level=s -C panic=abort";
}

Debugging and Development Workflow

Development Tools Integration

IDE Support

A good development environment includes all the tools you need for productive coding: language servers for intelligent code completion, debuggers for troubleshooting, and profiling tools for performance optimization. This configuration ensures that every developer on your team has access to the same high-quality development tools, regardless of their operating system or local setup.

devShells.default = pkgs.mkShell {
  buildInputs = with pkgs; [
    # Language servers
    rust-analyzer
    typescript-language-server
    eslint_d
    
    # Debugging tools
    gdb
    lldb
    nodejs_20  # for Chrome DevTools and Node.js debugging
    
    # Development tools
    wasm-pack
    wasm-bindgen-cli
    
    # Profiling tools
    valgrind
    perf-tools
  ];
  
  shellHook = ''
    # Configure rust-analyzer
    export RUST_SRC_PATH="${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}"
    
    # Set up debugging symbols for Rust
    export RUSTFLAGS="-C debuginfo=2"
    
    # Configure TypeScript development
    export NODE_OPTIONS="--openssl-legacy-provider"
    
    echo "🔧 Development environment ready"
    echo "Rust tools: rust-analyzer, cargo, wasm-pack"
    echo "TypeScript tools: typescript-language-server, eslint"
    echo "Debugging: gdb, lldb, Chrome DevTools"
  '';
};

Hot Reloading

During development, you want to see changes immediately without manually rebuilding everything. This setup watches your Rust files for changes and automatically recompiles the WebAssembly module, while simultaneously running a frontend development server that hot-reloads when the WebAssembly module updates. This creates a smooth development experience where changes in Rust code are immediately visible in your web application.

# Development server with hot reloading
devServer = pkgs.writeShellScriptBin "dev-server" ''
  # Start Rust file watcher
  ${pkgs.cargo-watch}/bin/cargo-watch -x 'build --target wasm32-unknown-unknown' &
  RUST_PID=$!
  
  # Start frontend dev server
  cd frontend
  ${pkgs.nodejs}/bin/npm run dev &
  FRONTEND_PID=$!
  
  # Cleanup on exit
  trap "kill $RUST_PID $FRONTEND_PID" EXIT
  wait
'';

Testing Strategies

Cross-Language Testing

This comprehensive testing approach ensures that your entire multi-language stack works correctly. It tests your Rust code natively, verifies that the WebAssembly compilation works properly, checks that the TypeScript integration layer functions correctly, and runs end-to-end tests that simulate real user interactions. This catches issues that might only appear when all the pieces work together.

crossLanguageTests = pkgs.runCommand "cross-language-tests" {
  buildInputs = with pkgs; [
    rustPackage
    nodePackage
    typescriptPackage
    yarn
  ];
} ''
  # Test Rust library
  cd ${rustSrc}
  cargo test --release
  
  # Test WebAssembly bindings
  cd ${wasmSrc}
  ${pkgs.nodejs_20}/bin/node test-wasm.js
  
  # Test TypeScript integration
  cd ${typescriptSrc}
  yarn test
  yarn test:integration
  
  # Run end-to-end tests
  yarn test:e2e
  
  touch $out
'';

Deployment and Production Considerations

Container Images

Multi-Stage Builds

Production container images should be as small and secure as possible. This pattern creates minimal container images that include only the runtime dependencies needed to run your application, without any of the build tools or development dependencies. This reduces attack surface, improves startup times, and reduces bandwidth costs for deployment.

productionImage = pkgs.dockerTools.buildLayeredImage {
  name = "production-app";
  tag = "latest";
  
  contents = [
    # Runtime dependencies only
    pkgs.cacert
    pkgs.tzdata
  ];
  
  config = {
    Cmd = [ "${finalPackage}/bin/app" ];
    Env = [
      "SSL_CERT_FILE=${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"
    ];
    ExposedPorts = {
      "8080/tcp" = {};
    };
  };
};

Security Hardening

Security is crucial for production deployments. This configuration creates container images that follow security best practices: running as a non-root user, using minimal base images that reduce attack surface, and including proper metadata for security scanning and compliance. These practices help protect your application from common container-based attacks.

hardenedImage = pkgs.dockerTools.buildImage {
  name = "hardened-app";
  
  # Minimal base with security updates
  contents = [ pkgs.distroless ];
  
  config = {
    User = "65534:65534";  # nobody user
    Cmd = [ "${securePackage}/bin/app" ];
    
    # Security labels
    Labels = {
      "org.opencontainers.image.source" = "https://github.com/org/repo";
      "org.opencontainers.image.licenses" = "MIT";
    };
  };
};

Continuous Integration

GitHub Actions Integration

Continuous integration ensures that your code works correctly across different environments and catches problems before they reach production. This GitHub Actions configuration leverages Nix's reproducibility to create CI builds that are identical to your local development environment, while using caching to keep build times fast.

# .github/workflows/build.yml
name: Build and Test

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: cachix/install-nix-action@v20
      - uses: cachix/cachix-action@v12
        with:
          name: your-cache
          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
      
      - name: Build all packages
        run: nix build .#all
      
      - name: Run tests
        run: nix flake check
      
      - name: Build Docker images
        run: nix build .#dockerImages

Future Directions and Advanced Topics

Emerging Patterns

WebAssembly System Interface (WASI)

WASI represents the future of WebAssembly beyond the browser. It provides a standardized system interface that allows WebAssembly modules to interact with the operating system in a secure, sandboxed way. This enables WebAssembly applications to run on servers, edge computing platforms, and other environments where you need system access but want the security and portability benefits of WebAssembly.

wasiPackage = pkgs.rustPlatform.buildRustPackage {
  # ... standard attributes
  
  # WASI target
  CARGO_BUILD_TARGET = "wasm32-wasi";
  
  # WASI runtime for testing
  nativeCheckInputs = [ pkgs.wasmtime ];
  
  checkPhase = ''
    wasmtime target/wasm32-wasi/release/${pname}.wasm
  '';
};

Edge Computing Deployment

Edge computing brings computation closer to users for better performance and reduced latency. WebAssembly is particularly well-suited for edge deployment because of its small size, fast startup times, and security sandbox. This pattern packages your WebAssembly modules and static assets for deployment to edge computing platforms like Cloudflare Workers, Fastly Compute@Edge, or AWS Lambda@Edge.

edgeDeployment = pkgs.runCommand "edge-deployment" {} ''
  mkdir -p $out/{functions,assets}
  
  # WebAssembly functions for edge runtime
  cp ${wasmPackage}/pkg/*.wasm $out/functions/
  
  # Static assets
  cp -r ${frontendPackage}/* $out/assets/
  
  # Edge configuration
  cat > $out/edge-config.json << EOF
  {
    "functions": {
      "api/*": "functions/api.wasm",
      "compute/*": "functions/compute.wasm"
    },
    "assets": "assets/*"
  }
  EOF
'';

Integration with Other Ecosystems

Kubernetes Operators

Kubernetes operators extend Kubernetes with custom application-specific logic. By embedding WebAssembly modules directly into your operators, you can create powerful, efficient controllers that leverage the performance and security benefits of WebAssembly while maintaining the operational benefits of Kubernetes. This is particularly useful for complex data processing or policy enforcement scenarios.

k8sOperator = pkgs.buildGoModule {
  pname = "app-operator";
  version = "1.0.0";
  src = ./operator;
  
  # Include WebAssembly modules as embedded resources
  preBuild = ''
    mkdir -p assets
    cp ${wasmPackage}/pkg/*.wasm assets/
  '';
  
  ldflags = [
    "-X main.version=1.0.0"
    "-X main.wasmAssets=assets"
  ];
};

Serverless Functions

Serverless platforms are increasingly supporting WebAssembly as a more efficient alternative to traditional JavaScript functions. WebAssembly functions start faster, use less memory, and can provide better performance for compute-intensive tasks. This pattern shows how to package your Rust-based WebAssembly modules for deployment to serverless platforms like AWS Lambda, Vercel Functions, or Netlify Functions.

serverlessFunction = pkgs.runCommand "serverless-function" {} ''
  mkdir -p $out
  
  # Package WebAssembly for serverless runtime
  cat > $out/function.js << EOF
  const wasm = require('./module.wasm');
  
  exports.handler = async (event) => {
    const result = await wasm.process(event.data);
    return { statusCode: 200, body: result };
  };
  EOF
  
  cp ${wasmPackage}/pkg/module.wasm $out/
'';

Analysis and Conclusions

The implementation patterns presented demonstrate how Nix flakes address fundamental challenges in multi-language development environments. This analysis is based on observations from production systems where these approaches have been successfully deployed.

Technical Benefits

The Nix flakes approach provides several measurable improvements over traditional multi-language development setups:

Reproducible Builds: Declarative dependency specification ensures identical build environments across development, testing, and production systems, eliminating environment-specific failures.

Automated Coordination: Programmatic integration between Rust compilation and TypeScript build processes reduces manual intervention and associated error rates.

Version Consistency: Centralized toolchain management prevents version conflicts and ensures all team members use identical development environments.

Branch Synchronization: Git-based dependency resolution automatically coordinates library versions with consuming applications across different development branches.

Implementation Considerations

Learning Curve: Nix flakes require initial investment in understanding declarative configuration concepts and Nix expression language syntax.

Incremental Adoption: Organizations can implement Nix flakes gradually, beginning with critical compilation pipelines and expanding to encompass broader development workflows.

Toolchain Integration: The approach integrates effectively with existing development tools while providing superior coordination capabilities.

Scalability: The pattern scales effectively from single-developer projects to large multi-repository systems with complex dependency relationships.

Operational Impact

Teams implementing these patterns typically observe:

• Reduced onboarding time for new developers
• Decreased environment-related build failures
• Improved consistency across development and deployment environments
• Enhanced collaboration efficiency through standardized toolchains

Applicability Assessment

Nix flakes provide particular value for projects that:

• Combine multiple programming languages with complex build requirements
• Require WebAssembly compilation and integration workflows
• Involve multiple repositories with interdependent components
• Need consistent environments across diverse development and deployment contexts

The approach represents a significant improvement over traditional multi-language development coordination methods, particularly for teams working with Rust-to-TypeScript integration patterns. While the initial learning investment is substantial, the long-term benefits in terms of reliability, reproducibility, and development efficiency justify adoption for suitable project contexts.

Building Your First Multi-Language Project: A Practical Guide

Let's walk through creating a real working example that demonstrates these concepts in action. We'll build a JSON processing application where the heavy lifting is done by a Rust library compiled to WebAssembly, consumed by a TypeScript web application.

What You'll Need

Before we start, make sure you have:

• Nix package manager installed with flakes enabled (installation guide)
• Basic familiarity with Rust and TypeScript (don't worry, we'll explain the tricky parts)
• About 30 minutes to work through this example

Step 1: Building the Rust Core

Let's start by creating the performance-critical part of our application – a Rust library that can parse and manipulate JSON data.

# Create a workspace for our project
mkdir json-tools-project
cd json-tools-project

# Create the Rust library
mkdir json-parser
cd json-parser
mkdir src

Now we'll create the core files. The beauty of this approach is that once you set up the Nix flake, anyone on your team can build this project identically, regardless of what Rust version they have installed (or even if they have Rust installed at all).

Create the files as detailed in the Rust WebAssembly section above. The key insight here is that our flake.nix file is doing something powerful – it's not just managing dependencies, it's creating a completely reproducible build environment.

Let's test our Rust library:

# This command creates a development shell with all the right tools
nix develop

# Generate the lock file (this pins our Rust dependencies)
cargo generate-lockfile

# Exit the development shell and build the WebAssembly module
exit
nix build

# Check that we got our WebAssembly files
ls result/pkg/  # You should see .wasm, .js, and .d.ts files

What just happened? Nix downloaded the exact version of Rust we specified, compiled our library to WebAssembly, generated TypeScript bindings, and packaged everything up. If you share this code with a teammate, they'll get exactly the same result.

Step 2: Creating the Web Application

Now let's build a web application that uses our Rust library. The magic here is that our web app will automatically get the latest version of our WebAssembly module whenever we rebuild it.

# Go back to our project root
cd ..
mkdir web-app
cd web-app

# Create the directory structure
mkdir -p src/{components,hooks,utils/json_parser}

Create all the frontend files as shown in the Frontend Integration section. The key file here is our flake.nix – it contains a script that automatically builds our Rust library and copies the WebAssembly files to the right place in our web app.

Step 3: Connecting Everything Together

This is where the magic happens. Instead of manually copying files around, we'll create a symbolic link that tells our web app where to find our Rust library:

# Create a link to our Rust project
ln -s ../json-parser json-parser-flake

This might seem simple, but it's solving a major problem in multi-language development: keeping different parts of your project in sync.

Step 4: Running Your Application

Now for the moment of truth – let's see our multi-language application in action:

# Enter the development environment (this gives us Node.js, Yarn, etc.)
nix develop

# Install our JavaScript dependencies
yarn install

# Build the WebAssembly module and copy it to our web app
yarn parser:build

# Start the development server
yarn dev

Open your browser to http://localhost:8080. You should see a JSON editor that's powered by Rust running in WebAssembly!

Step 5: Testing the Integration

Let's verify that everything is working correctly:

1. Try valid JSON: Paste {"name": "test", "value": 123} and click “Validate JSON” – you should see a green success message

2. Try invalid JSON: Enter {name: "test"} (missing quotes) and click “Validate JSON” – you should see a red error message

3. Test formatting: Enter some messy JSON and click “Format JSON” – it should be nicely formatted

4. Check the console: Open your browser's developer tools – you shouldn't see any errors

What You've Accomplished

Congratulations! You've just built a multi-language application with some pretty sophisticated features:

• Reproducible builds: Anyone can clone your project and get exactly the same development environment
• Automatic integration: Changes to your Rust code automatically flow through to your web application
• Type safety: Your TypeScript code has full type information about your Rust functions
• Performance: Critical JSON processing happens at near-native speed thanks to WebAssembly

Next Steps

This foundation can be extended in many directions:

• Add more complex Rust functionality (maybe a SQL parser or image processing)
• Create multiple web applications that share the same Rust core
• Set up automatic testing that verifies the Rust-TypeScript integration
• Deploy to production with the same reproducible build process

The patterns you've learned here scale from simple projects like this one all the way up to complex multi-repository systems with dozens of interconnected components.

Beyond WebAssembly: Rust FFI and Native Libraries

While this article focuses on WebAssembly, it's worth noting that Rust's capabilities extend far beyond the browser. Rust can compile to shared libraries (.so files on Linux, .dylib on macOS, .dll on Windows) that can be used from virtually any programming language through Foreign Function Interface (FFI).

This means you can write performance-critical code in Rust and use it from Python, Node.js, Ruby, Go, or any other language that supports FFI. Nix makes this even more powerful by ensuring that your shared libraries are built consistently and can be easily distributed to different target platforms.

For example, you might have a Rust library that handles cryptographic operations, compiled as both a WebAssembly module for browser use and as native shared libraries for server-side applications. Nix flakes can manage both build targets simultaneously, ensuring consistency across your entire technology stack.

Useful Resources and Further Reading

Getting Started with Nix

• Zero to Nix – An excellent beginner-friendly guide to learning Nix from scratch. This is the best place to start if you're new to Nix and want to understand the fundamentals before diving into flakes.
• Lix – A community-driven alternative implementation of Nix that aims to improve upon the original with better performance, clearer error messages, and enhanced developer experience.
• Nix Flakes Documentation – Official documentation for Nix flakes, covering all the technical details.

Rust and WebAssembly

• The Rust and WebAssembly Book – Comprehensive guide to using Rust with WebAssembly, including best practices and optimization techniques.
• Rust FFI Guide – Learn how to create shared libraries from Rust code that can be used by other programming languages.

Multi-Language Development

• Nix Pills – Deep dive into Nix concepts and philosophy, helpful for understanding the underlying principles.
• devenv – A higher-level tool built on Nix that simplifies creating development environments for multi-language projects.

Advanced Topics

• Nix Cross Compilation – Learn how to use Nix to build software for different target platforms.
• NixOS Modules – For when you want to extend beyond development environments into full system configuration.
• Flake Parts – A framework for organizing complex Nix flakes in a modular way.

These resources will help you deepen your understanding of the concepts presented in this article and explore more advanced use cases for multi-language development with Nix.

Below, you’ll find a brief explanation of how to expose Rust functions and pointers to Common Lisp, and how to set up callbacks from Lisp back to Rust.

Rust Side

To share a Rust function with Common Lisp, we mark it with #[no_mangle] and specify the C ABI by using extern "C". That way, we can safely call it from Lisp. Here’s an example of exposing a Rust function that moves an editor’s cursor up:

#[no_mangle]
pub extern "C" fn move_cursor_up(editor_ptr: *mut Editor) {
    let editor: &mut Editor = unsafe { &mut *editor_ptr };
    editor.cursor.move_up(&editor.text);
}

In this function, the pointer editor_ptr is passed in from Lisp. We convert it into a mutable reference (using unsafe { &mut *editor_ptr }) and then invoke move_up on the editor’s cursor. The unsafe block is required because we’re manually dereferencing a raw pointer.

Below is another example that shows how we can run the editor and call back into Lisp when needed. Notice that we have optional callback parameters in the function signature:

fn run_editor(
    path: PathBuf,
    on_initiate: Option<extern "C" fn(*mut Editor) -> c_void>,
    on_key_pressed: Option<extern "C" fn(*const c_char, *const c_char) -> c_void>,
) -> i32 {
    // ... some code

    let mut editor = Editor::new(text, Some(path), on_key_pressed);

    if let Some(callback) = on_initiate {
        callback(&mut editor);
    }

    let result = editor.run();
    
    // ... some code

    match result {
        Ok(_) => 0,
        Err(err) => {
            eprintln!("Editor error: {err}");
            1
        }
    }
}

Here, we receive an optional callback function pointer (on_initiate) which, if present, will be called with a pointer to the Editor. This mechanism can be useful for setting up or initializing data from Common Lisp before the editor runs. We can also call other callbacks (like on_key_pressed) from within Rust whenever a key is pressed, passing any necessary data back to Lisp.

Common Lisp Side

For the Lisp side, we can use CFFI to interact with Rust. CFFI allows us to define foreign functions, callbacks, and work directly with pointers. Here’s a minimal example:

;; some code

(defcfun "c_run_editor" :int 
         (path :string)
         (on-initiate :pointer)
         (on-key-pressed :pointer))
         
(defcfun "move_cursor_up" :void
         (editor :pointer))
         
(defcallback on-initiate :void ((editor :pointer))
  (setq *editor* editor))

1. defcfun "c_run_editor" defines a foreign function named c_run_editor that we can call from Lisp. It takes a string (the path) and two pointers (the callbacks).

2. defcfun "move_cursor_up" defines another foreign function that corresponds to the Rust function we exposed earlier.

3. defcallback on-initiate creates a callback function in Lisp that matches the signature expected by Rust. Here, we simply capture the editor pointer in a global Lisp variable called *editor*. This pointer can then be used elsewhere in the Lisp code to interact with the same editor object that Rust is operating on.

By combining these pieces, we can call into Rust for performance-critical tasks or to leverage Rust libraries, while still using Lisp’s REPL-driven workflow and powerful Condition System for interactive development and rapid iteration. This hybrid approach gives us the best of both ecosystems.

Why try Jujutsu?

There’s a certain comfort in sticking with Git. After all, it’s ubiquitous, battle-tested, and has an ocean of resources supporting it. But sometimes, small frustrations or inefficiencies start piling up, making you wonder if there's a better way. Jujutsu (abbreviated as jj) stands out because:

1. It’s backward compatible with Git. You can continue working in the same repositories as colleagues who haven’t adopted jj. When you need to create a pull request, you can simply push a Git branch without impacting your teammates’ workflows.

2. Stacked branches/PRs are simpler. If you have multiple features building on top of one another, jj presents them in a neatly stacked layout, making it clearer how changes progress.

3. You can combine commits or branches freely. With Jujutsu, you don’t have to wait for a branch to get merged into main before building on it. You can reference multiple changesets in a new feature branch, which is incredibly liberating for rapid development.

4. It has better conflict markers. Merge conflicts become easier to parse, thanks to a cleaner layout.

Of course, nothing’s perfect. Jujutsu has a few downsides:

1. It doesn’t have Git hooks. If you rely heavily on hooks to enforce policies (e.g., commit-msg or pre-receive hooks), you’ll have to find alternatives or revert to Git for those tasks.

2. It has its own philosophy. Even though it’s compatible with Git, jj still approaches version control differently, which can be an uphill battle if your entire team isn’t on board.

What’s the Philosophy of Jujutsu?

Jujutsu aims to simplify Git workflows. There are no traditional “branches” here, and there’s no separate “commit” step after making changes. Instead, you work with a sequence of changesets. When you need a new set of changes, you create it with jj new and begin editing files. Once you’re ready, you can add a description (using jj desc) and finalize the changeset. For convenience, jj commit combines these actions—though it’s not the same as git commit because it just appends a description and seals your changes into a new changeset.

For example, here’s a sample working history:

❯ jj
@  klqwozss sergey.golovin@protonmail.com 2025-02-02 09:53:05 bc1c8fa9
│  fix: clear terminal before going back to the editor
◆  zurmvopq sergey.golovin@protonmail.com 2025-02-01 20:46:22 main git_head() e2286213
│  chore: update colors of status bar
~

To create a new changeset, just type:

❯ jj new
Working copy now at: nmkklpov 77f465f2 (empty) (no description set)
Parent commit      : klqwozss bc1c8fa9 fix: clear terminal before going back to the editor

You can now add or modify files, and those changes are saved automatically. When you’re ready, you can describe the changeset with jj desc or do it all at once with jj commit.

Do not wait! Just add this to your working branch

One of the coolest things about Jujutsu is that you don't need to wait for a feature to be merged into a main branch to build on top of it. Consider this history:

❯ jj
@  ltyrpuno sergey.golovin@protonmail.com 2025-02-02 10:07:35 1be73fee
│  (no description set)
│ ○  lkqryomk sergey.golovin@protonmail.com 2025-02-02 10:06:54 3e036390
│ │  (no description set)
│ ○  pzvmvtpw sergey.golovin@protonmail.com 2025-02-02 10:04:46 ffe78f2a
├─╯  (no description set)
○  nmkklpov sergey.golovin@protonmail.com 2025-02-02 10:04:31 git_head() 2a5dfd41
│  (no description set)
│ ○  uyyszzsz sergey.golovin@protonmail.com 2025-02-02 10:06:16 d9ba2396
│ │  (no description set)
│ ○  knmruutr sergey.golovin@protonmail.com 2025-02-02 10:05:12 b7498368
├─╯  (no description set)
○  klqwozss sergey.golovin@protonmail.com 2025-02-02 09:53:05 bc1c8fa9
│  fix: clear terminal before going back to the editor

If you want to create a new changeset that includes ltyrpuno, lkqryomk, and uyyszzsz, you could do:

❯ jj new u lk lt
Working copy now at: ptsmnxmz 362396b6 (conflict) (empty) (no description set)
Parent commit      : uyyszzsz d9ba2396 (no description set)
Parent commit      : lkqryomk 3e036390 (no description set)
Parent commit      : ltyrpuno 1be73fee (no description set)
Added 2 files, modified 1 files, removed 0 files
There are unresolved conflicts at these paths:
c.txt    2-sided conflict
d.txt    2-sided conflict

Conflicts can arise, but once you resolve them in Jujutsu, it remembers those resolutions. Future merges with the same changes won’t pester you again with the same conflicts.

After resolving conflicts, you might see something like this:

@  ptlrysws sergey.golovin@protonmail.com 2025-02-02 10:15:14 1e9b3710
│  (no description set)
○      ptsmnxmz sergey.golovin@protonmail.com 2025-02-02 10:14:51 git_head() 0078f3ff
├─┬─╮  (no description set)
│ │ ○  ltyrpuno sergey.golovin@protonmail.com 2025-02-02 10:07:35 1be73fee
│ │ │  (no description set)
│ ○ │  lkqryomk sergey.golovin@protonmail.com 2025-02-02 10:06:54 3e036390
│ │ │  (no description set)
│ ○ │  pzvmvtpw sergey.golovin@protonmail.com 2025-02-02 10:04:46 ffe78f2a
│ ├─╯  (no description set)
│ ○  nmkklpov sergey.golovin@protonmail.com 2025-02-02 10:04:31 2a5dfd41
│ │  (no description set)
○ │  uyyszzsz sergey.golovin@protonmail.com 2025-02-02 10:06:16 d9ba2396
│ │  (no description set)
○ │  knmruutr sergey.golovin@protonmail.com 2025-02-02 10:05:12 b7498368
├─╯  (no description set)
○  klqwozss sergey.golovin@protonmail.com 2025-02-02 09:53:05 bc1c8fa9
│  fix: clear terminal before going back to the editor
◆  zurmvopq sergey.golovin@protonmail.com 2025-02-01 20:46:22 main e2286213
│  chore: update colors of status bar
~

You can also edit previous changesets. For instance, if you need to modify nmkklpov, type jj edit n, make changes, and then return to your last commit. Any updates in the earlier changeset flow naturally into subsequent changes. This approach works just as well for long chains of stacked changesets. By running jj git fetch, then jj git push, you can synchronize all updated branches with the remote.

Though Jujutsu technically doesn’t use “branches,” it does support bookmarks, which are analogous to Git branches. You can manage these bookmarks via commands like jj branch create new-branch or jj b c new-branch, and then push them to your remote as you would with any regular Git branch.

Conclusion

Jujutsu offers a refreshing take on version control, blending Git compatibility with a simpler, more flexible workflow. Its stacked changesets make it easier to experiment, resolve conflicts once, and move forward without getting bogged down. While there are trade-offs—especially if your team depends on certain Git-exclusive features—Jujutsu’s approach to branching, committing, and merging can drastically streamline everyday tasks. If you’re feeling the limitations of Git, exploring Jujutsu might just open new doors in your development workflow.