DEV Community: Dev Encyclopedia

Building Native Desktop Apps with Deno 2.9 and Pure TypeScript

Dev Encyclopedia — Fri, 31 Jul 2026 04:14:21 +0000

Shipping a web application as a desktop binary has traditionally required significant compromises. Electron developers deal with massive binary sizes due to bundled Chromium instances, while Tauri developers face a steep learning curve by being forced to write backend logic in Rust. For teams completely standardized on TypeScript, neither approach feels entirely seamless.

Deno 2.9 addresses this gap by introducing deno desktop, a canary feature that lets you package a Deno web project into a native desktop application using only TypeScript. Instead of manually wiring up ports or managing inter-process communication boundaries, you can point the command directly at your server. Better yet, the framework supports a window.bind API that bridges page JavaScript straight to backend functions with zero HTTP overhead.

Whether you are targeting macOS, Windows, or Linux, the workflow stays firmly within the runtime you already know. I break down the full tutorial, configuration, and native API bindings here: https://devencyclopedia.com/blog/deno-desktop-tutorial

Stop Guessing What Your Cron Expression Actually Does

Dev Encyclopedia — Thu, 30 Jul 2026 03:54:04 +0000

If you've ever stared at "0 9 * * 1-5" and had to mentally reconstruct which field is which, you're not alone. Cron syntax is compact by design, which makes it great for config files and terrible for readability.

The real problems show up once you leave plain Linux crontab. GitHub Actions runs everything in UTC regardless of your repo's timezone, and it silently ignores any schedule more frequent than every 5 minutes, no error, it just won't fire as often as you asked. AWS EventBridge adds a 6-field format with seconds and year, plus its own rate() syntax. Kubernetes CronJobs look identical to standard 5-field cron but run in the pod's timezone, which defaults to UTC unless you set it explicitly.

Then there's the logic trap: when both the day-of-month and day-of-week fields are restricted at the same time, cron doesn't AND them together, it ORs them. So an expression meant to mean "first Monday of the month" actually fires on the 1st of the month OR every Monday, whichever comes first.

I put together a free Cron Expression Builder that translates any expression into plain English, shows your next 5 scheduled run times in your local timezone, and breaks down the platform-specific quirks above. I break down all of it here: https://devencyclopedia.com/tools/cron-builder

How to Switch to uv: Replace pip, virtualenv, and Poetry in Your Python Project

Dev Encyclopedia — Wed, 29 Jul 2026 07:18:42 +0000

If you've worked on a Python project for more than a year, you know the drill: pip to install packages, virtualenv or venv to isolate environments, pyenv to manage Python versions, and pip-tools to generate a lockfile. Four separate tools, four config formats, and four different points of failure in CI.

uv, built by Astral (the team behind ruff), collapses all of that into a single Rust binary. It's not a modest speed bump either, we're talking 10 to 100x faster than pip on cold installs and near-instant on warm ones. In CI, where the cache is cold on every run, that difference is often the gap between a multi-minute install and one that finishes in seconds.

This isn't a "starting fresh" tutorial. It's specifically about migrating a project that already has a requirements.txt or a Poetry-based pyproject.toml, since that's the situation most of us are actually in.

The guide covers the real friction points: importing an existing requirements.txt cleanly (there's a one-liner for simple files and a safer fallback for ones with pins, comments, or extras), migrating off Poetry with a dedicated conversion tool, what doesn't auto-migrate (dependency groups, private indexes, poetry run calls), pinning your Python version so the whole team and CI stay in sync, and wiring up GitHub Actions with the one flag that keeps your lockfile honest.

I break down every step, plus the actual benchmark numbers, here: https://devencyclopedia.com/blog/switch-to-uv-python

Electron vs Tauri vs Deno Desktop: A Decision Tree, Not a Comparison Table

Dev Encyclopedia — Tue, 28 Jul 2026 06:37:18 +0000

Every "Electron vs Tauri" article follows the same format: explain what each one is, list some pros and cons, leave you to map it onto your own project. That mapping step is where most teams get stuck.

The actual decision comes down to a small number of forks, in order:

Rendering consistency. Need pixel-perfect output on every OS? That rules out Tauri and Deno Desktop immediately, since both use the OS's own WebView instead of a bundled engine. Electron is the only one that guarantees identical rendering everywhere.
Native access depth. If rendering isn't a hard requirement, the next question is how deep you need to go into OS-level APIs. This is where the three frameworks actually diverge: Tauri needs Rust for anything beyond its built-in commands, Electron leans on Node.js modules, and Deno Desktop uses an FFI layer that keeps you in TypeScript.
Rust comfort or bundle size. Depending on the native-access branch, this becomes the tiebreaker.
Maturity tolerance. Deno Desktop shipped in Deno 2.9, so it hasn't had the years of hardening Electron and Tauri 2.0 have. That matters a lot for production-critical apps and not much for internal tools.

I built a free browser tool that runs this whole decision tree for you and returns a direct recommendation (sometimes two, with a tiebreaker) plus a "why not the others" breakdown tied to your specific answers: https://devencyclopedia.com/tools/desktopstackpicker

Runs entirely client-side, no data leaves your browser.

42 NoSQL Interview Questions That Go Past the Textbook Definitions

Dev Encyclopedia — Mon, 27 Jul 2026 08:03:35 +0000

If you've prepped for a NoSQL interview by memorizing "CAP theorem stands for Consistency, Availability, Partition Tolerance," you've done maybe 10% of the work. The actual interview question is almost never the definition. It's the classification problem: given MongoDB, DynamoDB, or Cassandra, tell me whether it leans CP or AP and why, then explain what a user actually experiences when they read from a replica that hasn't caught up yet.

That pattern repeats across every database. MongoDB questions test whether you know when to embed versus reference data, and whether you can reason about shard key cardinality instead of just naming the feature. Redis questions are rapid-fire "what structure would you use for X", and the wrong answer between allkeys-lru and volatile-lru can look like you've never actually run Redis in production. DynamoDB questions assume you understand there are no joins, so single table design and Query versus Scan aren't trivia, they're the difference between a fast production system and a scan that silently reads your entire table.

I put together 42 questions across these three databases, covering aggregation pipelines, replica sets, distributed locks, cache stampedes, hot partitions, and RCU/WCU math, the stuff that actually comes up once you're past the "what is NoSQL" opener.

Full questions and answers here: https://devencyclopedia.com/blog/nosql-interview-questions

Migrating middleware.ts to proxy.ts in Next.js 16? Here's what actually changes

Dev Encyclopedia — Sun, 26 Jul 2026 11:42:34 +0000

Next.js 16 swaps middleware.ts for proxy.ts, and it's not just a rename. The export shape changes (a default export named proxy instead of a named middleware function), and the default runtime flips from Edge to Node.js.

That runtime change is where things get interesting. A handful of Edge-runtime-specific patterns don't automatically carry over cleanly: request.geo, request.ip, an explicit runtime: 'edge' config, streamed Response objects, and WASM imports. None of these break the migration outright, but each one is worth testing under Node.js before you ship.

The mechanical part, rewriting the export and renaming arrow-function exports that can't be default-exported in place, is easy to get wrong by hand across a big file. I built a small browser tool, MiddlewareToProxy, that does the rewrite, shows a side-by-side diff, and flags every risky pattern line by line so you're not hunting for them manually.

It's meant to complement the official @next/codemod, not replace it: use the codemod for the full project upgrade, use this for previewing a single file or writing up a migration PR first.

Full walkthrough and the tool itself here: https://devencyclopedia.com/tools/middleware-to-proxy

Async Traits in Rust Still Aren't Object-Safe. Here's What Actually Works

Dev Encyclopedia — Sat, 25 Jul 2026 04:38:58 +0000

If you've written a trait with an async method, implemented it for a couple of types, and then tried to throw them into a Vec>, you've probably seen this:

error[E0038]: the trait Notifier cannot be made into an object

It's jarring because the identical pattern works fine for sync traits. Add async to one method and object safety breaks entirely.

The root cause isn't a missing feature, it's structural. An async fn desugars into a state machine implementing Future, and that state machine's concrete type is anonymous and differently sized per implementor. A vtable needs a fixed-size, uniform entry per method across every possible implementor. Those two facts just don't reconcile, and the Rust compiler team has been explicit this isn't getting patched any time soon.

So what do you actually do about it? There are three legitimate workarounds, and the right one depends on whether your implementors are a closed set you control, an open set from third-party code, or you're building a library where the boxing cost matters to your downstream users.

I break down all three approaches with working code, a side-by-side cost comparison, and a decision table for picking the right one here: https://devencyclopedia.com/blog/rust-async-traits-object-safe

Why Your aria-live Region Isn't Announcing Anything (And How to Actually Test It)

Dev Encyclopedia — Fri, 24 Jul 2026 07:00:58 +0000

If you've ever built a toast notification or a form error summary and the screen reader just... stayed silent, you're not alone. It's one of the most common accessibility bugs, and it's almost never obvious from reading the markup.

The usual culprit: the live region gets created and filled with content in the same tick. Screen readers register a region, then watch for subsequent changes. If there's no "before" state to diff against, there's nothing to announce. The fix is to render an empty container up front and update its text later, in a separate update.

There's a second layer most devs miss entirely: the announcement queue. Polite messages wait behind whatever's currently speaking. Assertive messages interrupt immediately and clear the polite queue, which means a status update mid-read can get silently dropped the moment an error fires. You won't see this in the DOM, you only catch it by listening.

That's the part that's genuinely hard to test without firing up NVDA or VoiceOver every single time you tweak a message. I've been using LiveRegionLab to simulate the whole thing in the browser, paste HTML, trigger updates, and watch exactly what gets spoken, queued, or interrupted, plus static flags for the classic mistakes like a non-empty region on load.

I break down how the queue actually behaves and what to check for here: https://devencyclopedia.com/tools/liveregionlab

I Built a Browser Playground for Python 3.14 t-Strings (No Install Needed)

Dev Encyclopedia — Thu, 23 Jul 2026 07:03:31 +0000

Python 3.14 introduces t-strings, and if you've read about them you probably know the headline feature: unlike f-strings, they don't just produce a final string. They give you a Template object with a strings tuple and an interpolations list, so your code can inspect, transform, or reject values before anything gets assembled.

That's a meaningful shift. It means the same template can render five completely different ways depending on what you do with those interpolations: HTML with every value entity-escaped, SQL with values pulled out into a parameterized params list instead of concatenated into the query string, structured JSON logs with one field per interpolation, or an LLM prompt that gets scanned for injection phrases before it's sent anywhere.

The catch is that Pyodide doesn't ship Python 3.14 yet, so there's no easy way to try t-strings in-browser against a real interpreter. I built a JavaScript approximation instead: you type a template with {placeholder} markers, fill in values, and pick a renderer to see how the exact same input produces different output depending on the renderer's logic.

You also get a Template breakdown panel showing the raw strings and interpolations before any renderer touches them, which makes the underlying model a lot easier to reason about than reading it in prose.

I walk through why each renderer behaves the way it does, and the actual code you'd use in production, in the companion guide linked from the tool. Try the playground here: https://devencyclopedia.com/tools/t-string-playground

Before You Add HTTP QUERY to Your API, Check These 3 Layers

Dev Encyclopedia — Wed, 22 Jul 2026 06:43:16 +0000

HTTP QUERY (RFC 10008) solves a real problem: sending a request body with "read" semantics, without the hacks people use GET or POST for today. But adopting it isn't just "does my framework support it."

A QUERY request has to succeed at three separate layers to actually work end to end:

Your web framework. Some, like Hono, route arbitrary methods natively. Others, like Express, need you to intercept req.method === 'QUERY' manually since there's no built-in app.query() yet.
Whatever sits in front of your API. Proxies and CDNs like Cloudflare, nginx, or an AWS ALB can pass QUERY through cleanly, mangle it, or have undocumented behavior nobody's confirmed yet.
The client making the request. Browser fetch() support is still inconsistent across engines, and tools like curl, Postman, and axios each have their own level of support.

Test only one layer and you can end up debugging a "broken" QUERY request that's actually working fine in your framework and failing in the proxy, or vice versa.

I've been using a maintained, filterable compatibility matrix that tracks all three layers in one place, frameworks, proxies/CDNs, and HTTP clients, with each entry linked to its authoritative source (GitHub issue, docs, or changelog) and a "last verified" date, since support for a brand-new method changes fast.

Full matrix here: https://devencyclopedia.com/tools/http-query-support-matrix

If you're on Express specifically, there's also a companion guide walking through the actual middleware workaround.

What a Mercor Frontend Engineer Interview Actually Tests (It's Not What You Think)

Dev Encyclopedia — Tue, 21 Jul 2026 00:15:20 +0000

"Frontend engineer role, AI model training" sounds vague until you realize what it actually means: you're not writing code, you're judging someone else's, except the someone else is a language model.

Companies like Mercor, Turing, and Surge AI hand experienced React/Next.js engineers model-generated code and ask them to decide if it's correct, safe, and idiomatic, then explain exactly why in writing. That last part matters more than people expect. You can spot a bug perfectly and still fail the assessment if your written explanation is vague.

The technical round runs two to three hours and centers on real scenarios, not trivia. Two patterns show up constantly: hydration mismatches (server and client rendering different values) and misplaced client boundaries (a whole page marked "use client" when only one button needed it). Both are common mistakes in AI-generated Next.js code, and both are very learnable if you know what to look for.

There's also a rating dimension most people don't prepare for at all: severity calibration. Flagging a style nitpick as critical, or missing a real correctness bug while praising formatting, tanks your accuracy score fast.

I put together a full breakdown of the exact code scenarios, sample evaluation walkthroughs, and a realistic weekend prep plan here: https://devencyclopedia.com/blog/mercor-frontend-engineer-interview-prep

Stop Guessing Why Your Kubernetes Pod Is Crashing

Dev Encyclopedia — Mon, 20 Jul 2026 05:09:26 +0000

Post Body:
Every Kubernetes engineer knows the feeling. kubectl get pods shows CrashLoopBackOff or OOMKilled, and now you're deciding between five plausible causes with a describe output that could mean any of them.

The problem isn't a lack of information, it's that troubleshooting guides are written to cover every possible cause at once. You end up reading through sections that don't apply to you just to find the one that does. And the causes genuinely do vary, an OOMKilled pod might have a limit that's simply too low, or it might be leaking memory over time, and telling those two apart requires different follow-up checks entirely.

PodTriage takes a different approach: pick your pod's status (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending, Evicted, or a stuck ContainerCreating/Terminating pod), or paste your kubectl describe pod output and let it auto-detect the status for you. From there it asks 2-3 targeted questions, things like whether kubectl logs --previous shows an actual error or comes back empty, built from real Kubernetes failure signatures. The output is one plain-English diagnosis, not a list of maybes.

It also runs entirely client-side. Pasted describe output, including internal hostnames and namespaces, is pattern-matched locally and never sent to a server.

I break down how the whole flow works, plus the exact kubectl commands worth knowing before you start, here: https://devencyclopedia.com/tools/podtriage