public digest · 5 picks
Industrial PLC tooling in Rust, a Blazor grid, and the codebase-to-LLM pipeline
Five picks this week that span a wider range than usual — from industrial control systems to AI-assisted code workflows, with a Phoenix UI library and a .NET data grid in between. The thread connecting them is the same one we keep noticing: developers building the tooling they wish existed, in spaces where the incumbent options are either proprietary, abandoned, or both.
A few of these are early-stage projects with real ambition and honest rough edges. We're including them because the architecture decisions are worth studying even if you're not ready to ship them to production. The caveats are in the write-ups — read them before you commit.
// pick 1 of 5
truST is a full IDE and runtime stack for IEC 61131-3 Structured Text PLC programming, built in Rust. It ships an LSP server, DAP debugger, runtime engine, browser-based HMI, and VS Code extension as one integrated system. The target audience is industrial automation engineers who are fed up with locked-in vendor tools like TwinCAT or CODESYS.
The IEC 61131-3 Structured Text tooling space has been stuck for years: CODESYS and TwinCAT dominate, both are vendor-locked, and every open-source attempt either stops at a parser or ships a toy runtime. truST is the most complete attempt at a full open-source alternative I've seen — LSP, DAP debugger, browser HMI, and PREEMPT_RT Linux support in one repo, all in Rust.
The architecture choices are solid. Salsa-backed incremental compilation in trust-hir is the right foundation for an IDE that needs to keep up with keystrokes without full reparsing. Shipping a DAP adapter alongside the LSP means VS Code breakpoints and locals inspection actually work — that's the gap every other open-source ST tool leaves unfilled. The conformance test suite with manifest-driven expected outputs is well-structured and gives a real compliance baseline.
What to know going in: this is a solo maintainer project, pre-1.0, in a domain where tooling abandonment has real consequences. The conformance suite covers timers, edges, and arithmetic, but RETAIN/PERSISTENT semantics and complex FB scoping rules are likely incomplete. EtherCAT appears as a topic tag but there's no obvious EtherCAT stack in the tree. The browser IDE and HMI sharing a runtime process with the controller is convenient for demos and concerning for anyone thinking about safety boundaries. Worth watching closely; not ready to be your production control system.
View on GitHub → Our full take →
// pick 2 of 5
A Phoenix/LiveView UI component library that works as a code generator rather than a runtime dependency — you run a mix task and the component source lands in your project, yours to modify. Aimed at Phoenix developers who want a full component set without being locked into a third-party API surface.
The right instinct for a Phoenix component library is to get out of the runtime dependency business entirely, and that's exactly what mishka_chelekom does. You run a mix task, the component source lands in your project, and it's your code from that point forward. No upstream API breakage, no version mismatch with LiveView internals on the next upgrade cycle.
The component count is genuinely large — 80+ now with a roadmap to 200 — covering forms, navigation, overlays, and data display rather than just buttons and badges. The MCP server integration is an unusual addition that turns out to be practical: AI tooling can query component metadata and trigger generation directly, which removes a manual copy-paste step from the AI-assisted workflow. It's a dev-only dependency, so nothing extra ships to production.
What to know going in: 728 stars and 21 forks after significant development effort suggests the Phoenix UI space hasn't fully discovered this yet. The JavaScript side — carousel, combobox, floating elements — is plain JS with no abstraction layer, so LiveView hook integration for stateful interactions is your responsibility to wire up and maintain. Test coverage is mostly smoke tests; there's nothing testing actual rendered HTML output, so visual regressions are a manual concern. At version 0.0.8, the API isn't stable, and a roadmap that ambitious almost guarantees churn before 1.0.
View on GitHub → Our full take →
// pick 3 of 5
JamAI Base is a RAG backend that wraps SQLite and LanceDB behind a spreadsheet-like UI and REST API, letting you define AI-populated table columns with natural language prompts instead of writing pipeline code. It's aimed at teams who want to prototype LLM-backed data workflows without standing up their own vector DB infrastructure. The cloud offering and OSS self-hosted path coexist, which is either convenient or a warning sign depending on your tolerance for vendor lock-in.
The generative table abstraction at the core of JamAI Base is a genuinely clever idea: LLM outputs as computed columns, defined with natural language prompts, backed by LanceDB for vector search and SQLite for relational data. Non-engineers can wire up a RAG pipeline without writing Python, and the whole thing runs in-process without a separate vector DB to operate. Hybrid search — keyword plus vector plus BGE M3 reranking — is built in and not something you'd configure from scratch in an afternoon.
The Python and TypeScript SDKs have real test coverage against both the OSS and cloud endpoints, which is more than most projects at this star count bother with.
What to know going in: SQLite as the relational store is a ceiling for multi-writer or high-throughput workloads, and migrating off it later will be painful. The Docker Compose stack pulls in ClickHouse, VictoriaMetrics, Kong, and an OpenTelemetry collector for what is ostensibly a simple local setup — the operational weight is out of proportion to the use case. The v1-to-v2 migration guide existing this early in the project's life signals the API surface isn't settled. The 1098 stars and only 41 forks is worth noting: more people are looking than building, which tells you something about where it sits between 'interesting demo' and 'production dependency.'
View on GitHub → Our full take →
// pick 4 of 5
GridBlazor is a full-featured data grid component for Blazor (both WASM and server-side) and ASP.NET Core MVC, with built-in CRUD, filtering, sorting, pagination, and sub-grids. It targets teams building internal tools or admin UIs on .NET where they need a heavy-duty grid without writing one from scratch. The feature set is genuinely wide — gRPC, OData, REST, and local-data backends are all supported.
GridBlazor's standout quality is backend flexibility done right: you can point the same component at a REST API, gRPC service, OData endpoint, or in-memory data with minimal code changes. That's not common in the Blazor component space, where most grids assume one data access pattern and make the others awkward. The localization coverage is also unusually thorough — 30+ language files already present, which is real saved work in non-English projects. Bootstrap 3/4/5, Materialize, Bulma, and MudBlazor are all supported, so it fits into whatever stylesheet you're already running.
The hosted demo app is comprehensive and actually reflects the current version, which lets you evaluate real behavior before writing a line of code.
What to know going in: the migration history is a red flag worth reading carefully — class names, interfaces, and package splits have changed multiple times across versions, meaning upgrades have historically required manual find-and-replace across your codebase. The 732-star community is small enough that when you hit an edge case, you're likely on your own. The architecture requires a compatible back-end package (GridCore or GridMvcCore) rather than working with arbitrary IQueryable sources, which is tighter coupling than it sounds during a refactor. Virtualization support exists, but there are no published benchmarks for how it holds up at 100k+ rows.
View on GitHub → Our full take →
// pick 5 of 5
Repomix concatenates an entire codebase into a single file (XML, Markdown, JSON, or plain text) for feeding to LLMs. It handles gitignore rules, token counting, secret scanning via Secretlint, and can clone remote repos on the fly. Aimed at developers who want to do code review, documentation generation, or Q&A against a full codebase without manually copying files.
Repomix has quietly crossed from 'useful script' to 'actual infrastructure' for AI-assisted development. The --compress flag is the feature that makes it more than a glorified cat command: Tree-sitter extracts function and class signatures while stripping bodies, which in practice means a 70% token reduction that preserves enough structure for most analysis tasks. Combined with built-in Secretlint integration that catches API keys before the output file is written, and --token-budget with a non-zero exit code on overflow for CI guardrails, this is a thoughtfully engineered tool.
The MCP server mode (--mcp) is the recent addition that changes the workflow: AI assistants can call pack_codebase or grep_repomix_output directly, removing the 'copy this file into the chat' step entirely.
What to know going in: the default XML output format breaks when your code contains XML-like strings — --parsable-style exists to escape it, but Markdown or plain text avoid the problem entirely and are worth defaulting to. The --compress flag is still experimental, and Tree-sitter grammar coverage is uneven; it works well for TypeScript and JavaScript but can produce incomplete output for less common languages without warning you. --remote only works for public repos — private repos require a local clone first, which the README mentions briefly enough that it will surprise you the first time you try it on a private org. For large monorepos, even compressed output regularly hits 200k+ tokens; the tool shows you the damage but offers no automated guidance on what to cut.
View on GitHub → Our full take →
That's the week. If you want these picks in your inbox every time we publish, there's an email signup at the bottom of the page — no other mail, just the digest.
Get this in your inbox →