DEV Community: JLarky

Running a Local Sandboxed macOS Desktop Using VNC and a Restricted User

JLarky — Mon, 09 Mar 2026 23:47:06 +0000

Sometimes you want to run commands that you don’t fully trust or that intentionally bypass safeguards. A good example is running AI agents like:

claude --dangerously-skip-permissions

If that command executes arbitrary shell commands, writes files, or installs software, running it in your main admin session is risky.

A lightweight alternative to a full VM is to create a separate macOS user session and connect to it via VNC in a window. This gives you a local desktop sandbox with minimal setup.

No virtualization required.

The architecture looks like this:

Admin user
   ↓
Screen Sharing (VNC)
   ↓
Restricted macOS user
   ↓
Run risky commands safely

Why This Works Well for Developers

This setup provides:

separate $HOME
separate login keychain
separate permissions
no admin privileges
easy reset by deleting the user

You also get a windowed sandbox desktop, similar to a VM but much lighter.

This is ideal for things like:

running claude --dangerously-skip-permissions
testing install scripts
experimenting with unknown npm packages
isolating automation tools
testing shell agents

Step 1 — Create a Restricted User

Open:

System Settings → Users & Groups

Add a new user:

Account Type: Standard
Name: sandbox

Important: Do NOT make it an admin user.

This ensures the sandbox cannot:

install system software
modify system settings
escalate privileges easily

Step 2 — Enable Screen Sharing

Open:

System Settings → General → Sharing

Enable:

Screen Sharing

Click the ⓘ info button.

Set access to:

Allow access for: Only these users

Add your restricted user.

Example:

sandbox

This ensures only that account can initiate screen sharing sessions.

Step 3 — Log Into the Sandbox User

Enable Fast User Switching:

System Settings → Control Center
→ Fast User Switching
→ Show in Menu Bar

Then:

Click your username in the menu bar
Select Login Window
Log in as the sandbox user

The sandbox session is now running in the background.

Step 4 — Connect to the Sandbox Desktop

macOS normally blocks connecting to your own screen and shows:

You cannot control your own screen

To bypass this, create a local port forward.

Run:

ssh -NL 5901:localhost:5900 localhost

This forwards:

localhost:5901 → localhost:5900

Now connect using Finder.

Press:

⌘ + K

Enter:

vnc://localhost:5901

This opens the Screen Sharing app in a window connected to the sandbox desktop.

Fix for “You Cannot Control Your Own Screen”

If you try connecting directly to vnc://localhost, macOS will block it.

The SSH tunnel above solves this issue.

See the StackExchange discussion explaining the workaround:

https://apple.stackexchange.com/questions/151151/can-i-remote-desktop-to-another-user-on-the-same-machine

Step 5 — Run Your Risky Commands

Inside the sandbox desktop window you can now safely run things like:

claude --dangerously-skip-permissions

Even if the agent:

modifies files
installs packages
writes scripts

it will only affect:

/Users/sandbox

Your main development environment stays safe.

Convenience Shortcut

To open the sandbox quickly:

open vnc://localhost:5901

You can even create a shell alias:

alias sandbox="open vnc://localhost:5901"

Now launch the sandbox with:

sandbox

⚠️ Security Caveat

A separate macOS user is not a strong security sandbox. It helps prevent accidental damage but does not fully isolate data.

Files in your main home directory that are world-readable can still be accessed by the sandbox user.

For example:

/Users/realUser/.aws/config
/Users/realUser/.aws/credentials
~/.gitconfig
~/.npmrc
~/.env

If permissions look like:

-rw-r--r--

then any user on the machine can read them.

For instance, the sandbox user could run:

cat /Users/realUser/.aws/config

Many tools lock down sensitive files automatically, but not all do.

You can audit files that other users can read:

find ~ -perm -o+r

And tighten permissions where needed:

chmod 600 ~/.aws/*
chmod 600 ~/.ssh/*

This setup protects against accidental breakage, but it is not meant to contain malicious software. If you need stronger isolation, use a VM.

Advantages Over Virtual Machines

Feature	This Setup	VM
RAM usage	very low	high
Startup time	instant	slow
Disk usage	minimal	large
Native macOS apps	yes	limited
Hardware acceleration	full	partial

For many developer workflows, this feels like a lightweight local VM.

Final Result

Your system now looks like:

Admin Desktop
↓
Sandbox Window (VNC)
↓
Restricted macOS user
↓
Run risky tools safely

A simple, fast, and effective way to isolate powerful developer tools.

Modern Ways to Tame GitHub Action Workflows

JLarky — Mon, 20 Oct 2025 23:07:45 +0000

If you’ve ever cracked open a .github/workflows folder, you probably felt that mix of resignation and dread that only YAML can inspire. Indentation errors, random on: vs jobs: confusion, the joy of debugging a misaligned dash — truly a rite of passage. If you’re lucky, GitHub Actions is the only place in your stack where you still have to deal with YAML on a daily basis. For the rest of us, it’s an ever-present reminder that whitespace is a cruel and unforgiving god.

Thankfully, we don’t have to hand-craft every workflow file anymore. You can generate them, reuse them, or even visually design them — the YAML just happens to be the final delivery format. GitHub itself has been improving the situation: first with reusable workflows and composite actions, and more recently by adding YAML anchors (finally!) to let you reuse sections within the same file. Still, those features only go so far — you can’t run a loop or type-check your inputs, and good luck spotting a missing field until your CI job fails.

The Landscape: Lint, Generate, or Visualize

There are three main schools of thought when it comes to keeping your sanity with GitHub Actions:

Linting and validation.
Tools like actionlint help you catch structural mistakes before you push your code. They parse and validate your YAML files, ensuring field names, indentation, and job references are valid — basically a CI spellchecker. If you’re living inside VS Code, the GitHub Actions extension provides autocomplete, schema validation, and instant red squiggles for common errors. Linting doesn’t remove YAML from your life, but it makes it less of a horror movie. Think of this as adding bumpers to your YAML bowling lane — you’ll still hit the walls, but fewer builds will end up in CI jail.
Generation and code-as-config.
This camp believes the best YAML is the one you never have to write. Instead of treating workflows as text files, you define them in a real programming language like TypeScript, Kotlin, or C# and compile them to YAML. This gives you static types, autocompletion, loops, variables, and the ability to share workflow components as normal code modules. It’s configuration as code — literally. You can create a single “build pipeline” function and reuse it across dozens of repos, and your editor will help you refactor it safely. The YAML output is still there for GitHub to consume, but it’s now just a build artifact, not the source of truth.
Visual tools and builders.
A newer breed of tools aims to make workflow authoring accessible even to non-developers. Visual editors like Actionforge let you drag, drop, and connect boxes representing jobs and steps. They handle the YAML generation for you and even enable logic that plain YAML doesn’t support — such as loops, conditionals, or branches. These are especially useful in large orgs where not every team wants to read YAML syntax diagrams just to tweak a test matrix.

Tooling in the Wild

The “YAML escape plan” ecosystem is surprisingly diverse, spanning from strongly typed DSLs to visual editors. What unites them is the goal of making workflows less fragile and more maintainable — each taking a slightly different path toward that end.

The most common approach right now is generation via a general-purpose language. Here, developers write workflows in TypeScript, Kotlin, or C#, relying on familiar tooling like type checking and linting to ensure correctness. These solutions treat CI pipelines the way frontend developers treat CSS: you don’t edit the generated file — you write the higher-level definition and let the compiler handle the messy bits. For large teams, this means workflows can evolve safely, reviewed and versioned just like application code.

Meanwhile, visual tools have opened the door for teams who prefer to reason about pipelines visually rather than textually. The node-graph interface of Actionforge, for instance, makes it possible to express complex logic with minimal YAML knowledge — a huge win for onboarding and accessibility. At the same time, the YAML remains fully exportable, so teams aren’t locked in if they ever want to switch back.

Finally, linting and IDE integration form the safety net for everyone else. Even if you stick to plain YAML, actionlint and the official VS Code GitHub Actions extension offer quick feedback loops that save hours of trial-and-error debugging. Combined with GitHub’s recent addition of YAML anchors and reusable workflows, they give YAML authors some of the modularity and reuse long enjoyed by code-based alternatives.

A Few Standout Tools

Here are a few of the most active projects tackling the “YAML fatigue” problem, roughly ordered by GitHub stars:

github-workflows-kt (★630+) – A mature Kotlin DSL for GitHub Actions. You write workflows in strongly typed Kotlin and compile to YAML. Excellent type safety, powerful IDE support, and a thriving community.
ghats (★130+) – A TypeScript-based workflow generator that aims for simplicity and predictable YAML output. Ideal for teams already using Node tooling.
gha-ts (★110+) – A lightweight TypeScript library with deterministic generation and strong typing. It focuses on the developer experience of defining workflows as real code while keeping YAML output transparent and review-friendly.
Actionforge (★75+) – A VS Code extension that replaces YAML editing with a node-based visual interface, including branching and looping that standard YAML can’t do.

Each of these tools attacks the same pain point from a different angle. Whether you prefer Kotlin’s strict typing, TypeScript’s developer ergonomics, or Actionforge’s drag-and-drop design, the end goal is the same — reducing the human error surface of YAML while keeping your CI pipelines consistent and DRY.

The Bigger Question

Wouldn’t it be cool if GitHub just let us use something other than YAML to define workflows? GitLab, Buildkite, and others already allow pipelines in JSON, HCL, or even full programming languages. GitHub Actions is incredibly powerful, but its YAML-only approach increasingly feels like a relic of simpler times.

Until that changes, we’ll keep finding clever ways to wrap, lint, or generate our workflows. Whether you choose reusable workflows, anchors, or a DSL in your favorite language, the mission remains the same: spend less time fixing indentation and more time shipping code.

Combine Multiple Repos Into One Monorepo With One Root package-lock.json (Step-by-Step Guide)

JLarky — Tue, 14 Oct 2025 00:17:53 +0000

If you’ve ever tried to merge multiple Node.js or frontend apps into a single monorepo and struggled with conflicting package-lock.json files, this guide explains how to unify them under one root using NPM workspaces — with scripts to verify nothing breaks.

Unifying Multiple Apps Into One Monorepo With a Single Root Lockfile (npm Workspaces)

This article explains how to bring multiple independent applications into a single monorepo that uses one shared npm workspace and one root lockfile. It focuses on the practical approach: unify under one root workspace, let npm re-resolve the dependency graph, and validate the result with a simple diff of dependency trees. Hoisting, inter-app dependencies, publishing/versioning, deployment, engine/platform details, and governance are out of scope.

Who this is for

Audience: Engineers running large monorepos with multiple separately-evolved applications who want deterministic installs and a single source of truth for dependencies.
Prerequisites: Familiarity with npm workspaces and lockfiles. We’ll use npm; the concepts map to pnpm/Yarn with different lockfile shapes.

Problem statement

Multiple applications evolved in separate repositories with their own package.json and package-lock.json. When consolidating them into one monorepo, keeping per-app lockfiles introduces drift and non-determinism. We want:

One root workspace (root package.json with workspaces)
One root lockfile (package-lock.json at repo root)
Deterministic installs via npm install at the repository root only
A way to validate that each app’s dependency tree stays as intended across the migration

Approach (high level)

Unify under a single workspace: Move apps into the repo and declare them in the root workspaces array.
Merge lockfile state conceptually: Bring per-app lockfile information under a workspace-scoped namespace in the root lockfile (helper script optional), then reinstall at the root and let npm compute the final graph.
Validate: Snapshot each app’s dependency tree before and after the merge and compare.

Target workspace layout

{
  "name": "my-monorepo",
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

Example file tree:

.
├─ package.json                # root workspace definition (single source of truth)
├─ package-lock.json           # unified root lockfile
├─ apps/
│  ├─ app-a/
│  │  ├─ package.json
│  │  └─ ...
│  └─ app-b/
│     ├─ package.json
│     └─ ...
└─ packages/                   # optional shared libraries
   └─ ui-components/
      ├─ package.json
      └─ ...

Migration flow (end-to-end)

1) Move apps into the monorepo under apps/<name> with their own package.json.

2) Configure root workspace by listing apps in root package.json -> workspaces.

3) Snapshot each app’s dependency tree (before) to establish a baseline:

cd apps/app-a && npm install && npm ls --all > versions-before.txt
cd ../../
cd apps/app-b && npm install && npm ls --all > versions-before.txt
cd ../../

4) Converge to a single root lockfile:

Preferred: run npm install at the repo root to let npm compute the unified graph.
Optional helper: a script that conceptually folds per-app lockfile entries into the root lockfile under apps/<app-name>/... prior to the reinstall. This can reduce noisy diffs and make the transition easier to reason about.

5) Reinstall at the root:

npm install
npm ls --all > versions-after.txt

6) Compare per-app trees (after vs. before) using a small diff script. Fail CI if unwanted changes are detected.

The rest of this article focuses on two small scripts you can adopt or adapt:

merge-to-root.ts (optional helper): conceptually folds a workspace lockfile into the root lockfile before reinstalling.
diff-workspace-deps.ts: compares an app’s “before” vs “after” dependency trees.

Optional merge helper: `merge-to-root.ts`

Purpose: A pragmatic helper if you want to seed the root lockfile with each app’s lockfile content (namespaced under the workspace path) before running the root npm install. This is not strictly required; you can skip this entire step and rely solely on npm install at the root to produce the unified lockfile.

Conceptually, the script does three things for each workspace you fold in:

Reads the root package-lock.json and the app’s package-lock.json.
Copies the app’s lockfile entries into the root lockfile under a namespaced key like apps/app-a/node_modules/... and creates a top-level packages["apps/app-a"] entry with the app’s own metadata.
Writes the updated root lockfile; you then run npm install at the root to let npm reconcile.

Example (illustrative, partial — adapt as needed):

// scripts/merge-to-root.ts
import { readFile, writeFile } from 'node:fs/promises';
import path from 'node:path';

type Json = Record<string, any>;

async function readJson(file: string): Promise<Json> {
  return JSON.parse(await readFile(file, 'utf8')) as Json;
}

async function writeJson(file: string, data: Json): Promise<void> {
  const text = `${JSON.stringify(data, null, 2)}\n`;
  await writeFile(file, text, 'utf8');
}

function namespacePackages(packages: Record<string, any>, namespace: string) {
  const out: Record<string, any> = {};
  for (const [key, value] of Object.entries(packages)) {
    if (key === '') continue; // handled separately for workspace root entry
    if (key.startsWith('node_modules')) {
      out[`${namespace}/${key}`] = value;
    } else {
      // leave other keys as-is (e.g., other workspaces already present)
      out[key] = value;
    }
  }
  return out;
}

function foldWorkspaceIntoRoot(
  rootLockfile: Json,
  workspaceLockfile: Json,
  workspaceDir: string, // e.g., 'apps/app-a'
): Json {
  const rootPackages = (rootLockfile.packages ?? {}) as Record<string, any>;
  const wsPackages = (workspaceLockfile.packages ?? {}) as Record<string, any>;

  // Create a namespaced view of the workspace's node_modules entries
  const namespaced = namespacePackages(wsPackages, workspaceDir);

  // Copy namespaced entries into the root map
  const mergedPackages: Record<string, any> = { ...rootPackages, ...namespaced };

  // Create the workspace's top-level entry (metadata from the workspace lockfile root "" entry)
  const wsRoot = wsPackages[''] ?? {};
  mergedPackages[workspaceDir] = {
    version: wsRoot.version,
    dependencies: wsRoot.dependencies,
    devDependencies: wsRoot.devDependencies,
    engines: wsRoot.engines,
  };

  return {
    ...rootLockfile,
    packages: mergedPackages,
  };
}

async function main() {
  const workspaceName = process.argv[2]; // e.g., 'app-a'
  if (!workspaceName) {
    console.error('Usage: bun ts scripts/merge-to-root.ts <workspaceName>');
    process.exit(1);
  }

  const workspaceDir = path.join('apps', workspaceName);
  const rootLockPath = path.resolve('package-lock.json');
  const wsLockPath = path.resolve(workspaceDir, 'package-lock.json');

  const [rootLock, wsLock] = await Promise.all([
    readJson(rootLockPath),
    readJson(wsLockPath),
  ]);

  const merged = foldWorkspaceIntoRoot(rootLock, wsLock, workspaceDir);
  await writeJson(rootLockPath, merged);

  console.log(`Seeded ${workspaceName} into root lockfile. Now run: npm install`);
}

await main();

Usage examples:

# Seed app-a into the root lockfile (optional helper), then reinstall
bun ts scripts/merge-to-root.ts app-a
npm install

Notes:

This helper’s goal is to reduce churn and make the transition predictable. It is not a generic, lossless lockfile merger; npm’s resolver remains the source of truth once you run npm install at the root.
If you prefer not to seed, skip this step and rely solely on npm install at the root.

Dependency diff helper: `diff-workspace-deps.ts`

Purpose: Compare an individual workspace’s dependency tree before vs. after unification. It reads npm ls --all output and reports:

CHANGED (packages whose version set changed)
ADDED (new name@version combos)
REMOVED (removed name@version combos)

Design:

“Before” file is captured inside the app (when it was standalone or before unification): apps/app-a/versions-before.txt.
“After” file is captured at the repo root after npm install: versions-after.txt.
The parser extracts the dependency subtree for the specific workspace from the monorepo-level npm ls tree by detecting the app-a@<version> -> ./apps/app-a block and collecting lines until indentation returns to the root.

Example (illustrative, partial):

// scripts/diff-workspace-deps.ts
/* eslint-disable no-console */
import { readFile } from 'node:fs/promises';
import path from 'node:path';

type VersionSetMap = Map<string, Set<string>>;

function extract(line: string) {
  const m = line.match(/((?:@[^\/\s]+\/)?[A-Za-z0-9._-]+)@([0-9][^\s]*)/);
  return m ? { name: m[1], version: m[2] } : null;
}

function parseBefore(content: string, workspaceName: string): VersionSetMap {
  const lines = content.split('\n');
  const out: VersionSetMap = new Map();
  const rootRe = new RegExp(`^${workspaceName}@[0-9]`);
  for (const line of lines) {
    if (rootRe.test(line)) continue; // skip the root line like "app-a@1.2.3 /path"
    const nv = extract(line);
    if (nv && nv.name !== workspaceName) (out.get(nv.name) ?? out.set(nv.name, new Set()).get(nv.name)!).add(nv.version);
  }
  return out;
}

function parseAfter(content: string, workspaceName: string): VersionSetMap {
  const lines = content.split('\n');
  // Example monorepo tree line: "└─┬ app-a@1.2.3 -> ./apps/app-a"
  const rootRe = new RegExp(`^[├└]─[┬─]\s+${workspaceName}@`);
  let inBlock = false;
  const out: VersionSetMap = new Map();
  for (const line of lines) {
    if (!inBlock) {
      if (rootRe.test(line)) inBlock = true;
      continue;
    }
    // Stop when indentation returns to the repo root
    if (!line.startsWith('│') && !line.startsWith(' ')) break;
    const nv = extract(line);
    if (nv && nv.name !== workspaceName) (out.get(nv.name) ?? out.set(nv.name, new Set()).get(nv.name)!).add(nv.version);
  }
  return out;
}

function compare(before: VersionSetMap, after: VersionSetMap) {
  const names = new Set([...before.keys(), ...after.keys()]);
  const combos = (m: VersionSetMap) => {
    const s = new Set<string>();
    for (const [n, vs] of m) for (const v of vs) s.add(`${n}@${v}`);
    return s;
  };
  const bCombos = combos(before);
  const aCombos = combos(after);

  const added = [...aCombos].filter((c) => !bCombos.has(c)).sort();
  const removed = [...bCombos].filter((c) => !aCombos.has(c)).sort();

  const changed: string[] = [];
  for (const n of names) {
    const b = [...(before.get(n) ?? new Set())].sort();
    const a = [...(after.get(n) ?? new Set())].sort();
    const eq = b.length === a.length && b.every((v, i) => v === a[i]);
    if (!eq && (b.length || a.length)) changed.push(`${n}: [${b.join(', ')}] -> [${a.join(', ')}]`);
  }
  return { changed, added, removed };
}

async function main() {
  const workspaceName = process.argv[2];
  const beforeArg = process.argv[3] ?? path.join('apps', workspaceName ?? '', 'versions-before.txt');
  const afterArg = process.argv[4] ?? path.join('versions-after.txt');

  if (!workspaceName) {
    console.error('Usage: bun ts scripts/diff-workspace-deps.ts <workspaceName> [beforeFile] [afterFile]');
    process.exit(1);
  }

  const [beforeContent, afterContent] = await Promise.all([
    readFile(path.resolve(beforeArg), 'utf8'),
    readFile(path.resolve(afterArg), 'utf8'),
  ]);

  const beforeMap = parseBefore(beforeContent, workspaceName);
  const afterMap = parseAfter(afterContent, workspaceName);
  const { changed, added, removed } = compare(beforeMap, afterMap);

  console.log('CHANGED (by package)');
  if (changed.length) console.log(changed.join('\n'));
  console.log('\nADDED (name@version)');
  if (added.length) console.log(added.join('\n'));
  console.log('\nREMOVED (name@version)');
  if (removed.length) console.log(removed.join('\n'));

  if (changed.length) {
    console.error('\nDependency changes detected');
    process.exit(1);
  }
}

await main();

Usage examples:

# Generate snapshots
cd apps/app-a && npm ls --all > versions-before.txt && cd -
npm install && npm ls --all > versions-after.txt

# Diff app-a only
bun ts scripts/diff-workspace-deps.ts app-a apps/app-a/versions-before.txt versions-after.txt

What to do with results:

Empty “CHANGED/ADDED/REMOVED” means your app’s dependency tree stayed equivalent.
Non-empty output means your unified install altered the app’s resolved dependencies. Decide whether to accept or adjust before proceeding.

End-to-end example (bringing two apps into one root lockfile)

# 1) Add apps to the monorepo under apps/
mkdir -p apps/app-a apps/app-b
# (copy in each app's package.json and source)

# 2) Configure the root workspace (package.json workspaces)
#    Then optionally install in each app and snapshot "before"
cd apps/app-a && npm install && npm ls --all > versions-before.txt && cd -
cd apps/app-b && npm install && npm ls --all > versions-before.txt && cd -

# 3) (Optional) Seed app-a into the root lockfile to reduce churn
bun ts scripts/merge-to-root.ts app-a

# 4) Install once at the root to produce a unified lockfile
npm install
npm ls --all > versions-after.txt

# 5) Validate each app
bun ts scripts/diff-workspace-deps.ts app-a apps/app-a/versions-before.txt versions-after.txt
bun ts scripts/diff-workspace-deps.ts app-b apps/app-b/versions-before.txt versions-after.txt

# Use exit codes to gate CI: non-zero indicates changes

Notes on npm vs pnpm/Yarn

The approach (single workspace, reinstall to reconcile, validate via diffs) generalizes.
The lockfile structure differs. If you adapt the optional merge helper, update parsing/keys accordingly.
If you skip the merge helper and rely on npm install at the root, the process is nearly identical across tools.

Pitfalls and guardrails (brief)

Lockfile version mismatch: Align lockfile versions before you start.
Unexpected dependency changes: Rely on the diff script to detect. Review and accept or fix intentionally.

Conclusion

Unifying multiple apps under a single root workspace and lockfile simplifies dependency management and installations across a large monorepo. A small amount of automation — optional seed-merge and a deterministic diff — makes the migration observable and CI-friendly without relying on bespoke, fragile lockfile reconciliation.

The Hidden Costs of Switching from NetBeans to Cursor

JLarky — Tue, 17 Jun 2025 20:39:00 +0000

For developers raised on NetBeans, the transition to a modern, AI-first IDE like Cursor can feel like stepping from a familiar kitchen into a spaceship. Cursor is fast, sleek, and intelligent—but also minimalist and opinionated in ways that can clash with long-ingrained workflows.

While the benefits are real—AI-powered autocomplete, a VS Code ecosystem, and blazing performance—getting there isn't frictionless. Here’s a breakdown of the challenges you might face when trading the old-school reliability of NetBeans for the cutting-edge world of Cursor.

1. Comfort vs. Performance: Muscle Memory Fights Back

If you’ve used NetBeans for years, you’ve developed more than preferences—you’ve built instincts. Cursor strips much of that away.

NetBeans offers rich GUI interfaces for almost everything: running tests, inspecting services, managing databases, and even designing UIs. Cursor assumes you're comfortable with the keyboard, command-line tooling, and AI-driven suggestions. That means:

You might search in vain for the familiar “New Class” wizard.
There’s no Project Properties dialog—just settings.json and extensions.
Multi-tab panes like Projects, Files, and Services are replaced with a single file explorer and fuzzy search.

Even basic things—like setting breakpoints or viewing the call hierarchy—can feel like a scavenger hunt until you rebuild your muscle memory.

2. Project Types: Java-Centric IDE vs. Language-Agnostic Editor

NetBeans is unapologetically Java-first. Cursor, built on top of VS Code, is language-agnostic with a heavy lean toward TypeScript and web tech.

In NetBeans, opening a Maven project just works. Dependencies resolve, code completion is accurate, and run/debug configurations are pre-wired. Cursor, by contrast, might require manual setup, extension installation, or build tool configuration before things behave.

You’ll especially feel the gap if:

You rely on NetBeans' deep integrations with Tomcat, GlassFish, or Payara.
You're working with Java EE or Jakarta EE.
You use Ant or Maven-based desktop applications or GUI projects like JavaFX or Swing.

Cursor isn’t hostile to Java—it just assumes you’ll bring your own build setup and tools. And if you’re building something monolithic or backend-heavy in Java, the friction can be real.

3. AI-First Isn’t Always Instant Productivity

Cursor’s selling point is AI as a first-class IDE citizen. You can highlight a chunk of code and ask questions in natural language. It can autocomplete large blocks, summarize complex logic, or explain what a regex does.

That sounds magical. But here’s the catch:

You need to know how to ask good questions.
If you’re not careful, you’ll end up with plausible-looking code that doesn’t quite work.
Relying too much on AI suggestions without fully understanding them can create technical debt faster than you realize.

For NetBeans users used to precision and manual control, AI-generated assistance might feel too ambiguous or too eager. There’s power here—but it takes time to wield it effectively.

4. Debugging: From Integrated Simplicity to DIY Configs

NetBeans’ Java debugger is battle-tested. Step-through debugging, conditional breakpoints, thread inspectors—it all works without fuss. Cursor takes a lighter approach.

Debugging in Cursor means configuring launch.json, installing the right Java extensions, and occasionally fiddling with your environment variables. Once set up, it works—but the ramp-up is nontrivial. Especially if you're used to clicking “Debug Project” and just watching your app go.

Expect growing pains around:

Remote debugging.
Attaching to running processes.
Inspecting heap or thread state.

You can get there—but you’ll spend time on StackOverflow and GitHub issues along the way.

5. Build Systems & Tooling Expectations

NetBeans likes to manage things for you. It handles your pom.xml, runs your tests, and offers rich visual interfaces for everything from profiling to deployment.

Cursor assumes the opposite: that you're running mvn test in the terminal and linting via command-line tools or preconfigured tasks. It’s not worse—it’s just manual.

This also means you’ll need to:

Install your preferred formatter and linter manually.
Set up test runners (JUnit, Jest, etc.) via extensions or scripts.
Configure build outputs explicitly.

This shift gives you more control, but it also exposes you to more moving parts.

6. Extension Overload: From All-In-One to Choose-Your-Own Adventure

NetBeans is an IDE in the traditional sense: batteries included. Cursor inherits the VS Code approach—start small, add what you need. This is liberating and dangerous.

You’ll be faced with decisions like:

Which Java extension pack is best?
Do I need the AI inline autocomplete and the chat panel?
Should I install a test runner plugin or wire up CLI scripts?

Each choice adds power—but also fragility. Some extensions conflict. Some silently fail. And keeping your environment stable across machines or teams becomes another layer of complexity.

The Bigger Picture

The move from NetBeans to Cursor is more than just switching editors. It’s a philosophical shift—from IDE-managed workflows to lean, scriptable, AI-augmented development. From safe defaults to fast iteration. From vertical integration to composable tooling.

Cursor can be faster. It can be smarter. But it doesn’t hold your hand—and it won’t protect you from misusing the power it gives.

Is It Worth It?

If you're building Java apps for enterprise deployment, NetBeans might still serve you better. But if you're living in a polyglot world, hopping between Python, Node, TypeScript, and Go—and if you're ready to leverage AI as a coding assistant—Cursor can open new doors.

Just don’t expect a painless transition. Expect friction. Expect to feel slow before you feel fast again.

And once you’ve adjusted… you might never want to go back.

What Most People Get Wrong About the Term SSR

JLarky — Wed, 27 Nov 2024 18:56:57 +0000

The term Server-Side Rendering (SSR) is often misunderstood, with many using it to describe practices that predate its creation or don’t technically qualify. From PHP templates to React’s isomorphic apps, the definition of SSR has evolved—and so has the confusion around it.

This article dives into the origins of SSR, what it truly means, and why understanding the distinction matters in modern web development.

So Here’s the Deal

We didn’t have SSR back in the PHP days. That term didn’t exist. It was created in the 2010s. No one called this stuff SSR before that.

What did they call it? If you believe Wikipedia, it was called server-side scripting (as opposed to client-side scripting).

Fun fact: if you check Wikipedia, they didn’t even add “SSR” to the server-side scripting article until 2021. Here’s the diff. And honestly? I think this is wrong.

Before SSR, There Was...

Until React introduced the term “rendering,” we didn’t use that word. The closest thing we had was server-side templates. Here’s an old snapshot.

The idea was simple: you’d use a static site generator or server scripting to build your dynamic web page.

Some people argue: “Well, if I use server templates, I’m rendering them on the server.”

The Problem With That

Rendering in React doesn’t always mean producing HTML or DOM. It produces VDOM (virtual DOM). The lines blur when you call renderToString because then the component is actually rendered to HTML.

This is why people started claiming their PHP apps were doing SSR. But here’s the issue: this loses the distinction between actual SSR and regular dynamic scripting.

The Main Difference

You can only do SSR on parts that could also be rendered on the client.

For example:

const App = () => <div onClick={handleClick}>Hello</div>;

You can run this app twice: once on the server and once on the client.

But:

<div><?php echo "Hello"; ?></div>

This can’t run on the client. There’s no rendering here—no “client-side” or “server-side” distinction. This is just old-fashioned dynamic scripting.

SR vs. SSR

Since no one uses those old terms anymore (except maybe in ASP), I think I’m giving up and just calling it Server Rendering (SR) vs. Server-Side Rendering (SSR).

One huge difference is hydration.

In the PHP world, there’s no hydration, but they’re still sure they have SSR. That doesn’t make sense. You can only have SSR if you have hydration.

Hydration: The Key

React has two key methods:

renderToStaticMarkup: Produces HTML you’re not expected to hydrate. This is closer to server templating.
renderToString: Produces HTML that gets hydrated on the client. This is SSR.

Angular Universal didn’t have SSR until 2023. What they had was SR: producing HTML on the server, then dropping it once scripts loaded and rendering the app as an SPA into an empty <body> tag.

That’s not the same as PHP, but it’s also not the same as real SSR.

The Early Days

Early on, React apps were “pre-rendered” using headless Chrome to save them as HTML strings. That snapshot went into a CDN. Technically, a server wasn’t even necessary to make this work. 😂

It was a pointless endeavor, but Google recommended it for SEO at one point. I tracked down that article once, but I’m not sure if I can find it again.

Why Care About This?

React Server Components (RSC) forced us to revisit this topic.

Technically, RSC doesn’t do SSR. This surprised a lot of people.

The React team tried explaining it but gave up. The gist is that server components are just templates—they produce static HTML. Client components go through SSR to produce both HTML and DOM.

Inertia.js and SSR

Inertia.js makes a similar distinction. PHP runs on the server, but your JavaScript app gets SSR’d by running on the server to produce HTML and then hydrating on the client.

So, Can PHP Do SSR?

No. Like RSC, PHP is doing dynamic scripting (SR) with a step that does SSR.

If you run a React app with a middleware like Hono, injecting some dynamic code into HTML and later calling renderToString, it feels similar. In both cases, it’s SR with a step of SSR.

That’s why it’s bonkers when people claim, “We did SSR in PHP in the ’90s.”

What About SSG?

Every time I bring this up, someone asks about SSG. I don’t care.

The term Static Site Generation (SSG) actually predated React. SSG means producing HTML—no rendering or hydration required. Did you produce HTML? Congrats, you’re doing SSG.

The React Innovation

React frameworks introduced isomorphic apps, using hydration to adopt HTML on the client without re-creating it.

That HTML had to be produced by SSR.

Qwik and “Resumability”

Does Qwik do hydration? That’s the big question.

Qwik developers say no, but I’m leaning towards yes. If you like Qwik, you’d need to chop off another piece of SSR and call it Resumability.

If you prefer listening to discussions over reading, you can hear more of these arguments in audio form from this podcast episode about React Server Components in Go

Argument Against Solving the Double Data Problem in JavaScript SSR Frameworks

JLarky — Sun, 03 Nov 2024 22:19:50 +0000

The "double data problem" in JavaScript Server-Side Rendering (SSR) frameworks refers to the redundancy of sending the same data twice—once in the HTML output generated by the server and again as serialized data to enable client-side hydration. While addressing this issue may seem beneficial, there are compelling arguments against solving it due to trade-offs in complexity, real-world performance, and developer experience.

1. Complexity and Fragility

Attempting to resolve the double data problem introduces additional complexity in the codebase, as frameworks would need intricate optimizations to avoid sending data twice. This added complexity can make frameworks more fragile and harder to debug, potentially increasing maintenance costs and slowing down development. Solutions to this problem could add more points of failure, making the SSR framework less reliable and harder to work with.

2. Limited Real-World Performance Gains

For many applications, the data being duplicated is often small in size, especially compared to other assets like images, CSS, and JavaScript bundles. In these cases, the actual performance gain from reducing double data transmission is likely marginal, yielding negligible improvements in page load times. When network speed or payload size is not a bottleneck, optimizing SSR hydration to solve the double data problem may not deliver noticeable benefits to the end user.

3. Prioritizing Development Time and Impactful Optimizations

Developers generally need to prioritize optimizations that deliver the most significant impact on user experience. Optimizing for the double data problem may not be the best use of development time, especially when there are other optimizations (like selective hydration or bundling) that could yield greater improvements in user experience. With limited development resources, it may be more effective to focus on optimizations that meaningfully enhance load times and interactivity.

4. Loss of Flexibility and Developer Experience

Existing SSR frameworks that have the double data problem allow for a straightforward approach to data usage, where data can seamlessly be accessed on both the server and client side. Trying to eliminate this redundancy could complicate data handling, requiring developers to track data states more closely and rethink data-fetching patterns. This could make frameworks harder to learn and potentially less intuitive to use, impacting developer productivity and flexibility.

5. Existing Strategies Alleviate Performance Concerns

Many frameworks are already exploring alternative hydration strategies, such as selective hydration, which optimizes performance without addressing the double data problem directly. These strategies allow only essential components to hydrate initially, reducing data transmission costs and improving load times without requiring a full solution to the double data problem. Additionally, techniques like Gzip/Brotli compression and caching minimize the impact of sending data twice by compressing the HTML and JSON payloads, making it more manageable and often negligible.

Conclusion

While the double data problem is an inefficiency, addressing it may not yield substantial real-world benefits for most applications. Solving this issue could lead to increased code complexity, reduced developer flexibility, and only minor performance gains. By focusing on alternative optimizations, such as selective hydration and compression, frameworks can enhance performance effectively without the drawbacks associated with solving the double data problem. Thus, in most cases, it may be more pragmatic to accept this inefficiency rather than introduce new complexities into SSR frameworks.

Conway's Law and Separation of Concerns in Web Development

JLarky — Mon, 21 Oct 2024 13:59:54 +0000

Conway's Law, which states that software systems tend to mirror the communication structures of the organizations that build them, plays a crucial role in the way modern web development is structured. The evolution from early practices to today’s more complex systems, like micro-frontends and component-based architectures, has been largely shaped by this principle. By looking at how concerns were historically separated in web development, we can better understand how current practices emerged and why they look the way they do today.

In the early days of web development, different teams were often responsible for specific technologies. One team handled the HTML, another was in charge of CSS, and yet another team took care of JavaScript and server-side logic, such as PHP. This clear separation of responsibilities, or "separation of concerns," was driven by the distinct skills each team possessed. Designers would hand over pixel-perfect Photoshop files to one team, who would then turn those into HTML and CSS templates. Once the templates were done, the next team would integrate them into the app, often encountering friction when things didn’t fit perfectly.

A designer might deliver a .psd file with all nine corners of a table meticulously designed, and the HTML/CSS team would slice it into a working layout. But they were largely disconnected from the app's actual logic or user interactions. Their job was just to make sure the visuals worked. The backend team, dealing with PHP and JavaScript, would then integrate these static templates into the functioning app, often finding the solutions presented by the earlier teams weren’t ideal for the application’s needs. This was a reflection of how organizations were structured, with each team owning a different part of the process without much cross-communication.

The Shift to Component-based Architecture

Today, the way we separate concerns has changed dramatically. Instead of splitting responsibilities by technology—such as one team for HTML and CSS, and another for JavaScript and PHP—modern teams are more likely to be responsible for the entire stack of specific parts of the application. Each team typically owns a vertical slice of the application, including everything from frontend components to backend logic. This shift is driven by the rise of component-based architectures, where reusable, self-contained components are the building blocks of the system.

For example, instead of one team focusing on all the HTML and CSS across the entire site, and another team handling the JavaScript and server-side integration, you now have teams that are responsible for distinct features or components, such as <Article>, <ChatWidget>, or <MainLayout>. Each team manages their component or part of the application from top to bottom, including both the frontend and backend logic. This allows teams to work more autonomously, reducing bottlenecks and miscommunication that often occurred in the old separation model.

This new separation of concerns, by feature or component rather than by technology, allows teams to iterate faster. A team responsible for a chat widget, for example, can implement changes to both the UI and the backend API without waiting for another team to handle one part of the system. The key difference now is that instead of having specialized teams focused only on HTML or JavaScript, you have cross-functional teams that take ownership of their components or features in their entirety.

Micro-frontends and Independent Team Ownership

One of the most significant results of this shift is the rise of micro-frontends, where different teams own different parts of the frontend, just as they own parts of the backend. This allows for a level of independence that wasn’t possible in the early days. A micro-frontend architecture mirrors the independence teams now have in managing their components.

For example, a team responsible for <MainLayout> might own everything from the UI structure to how it interacts with the data fetched from APIs. Another team responsible for <Article> will have full control over how articles are fetched, rendered, and interacted with, from frontend logic to database queries. This level of autonomy means that changes can be deployed independently, without needing to coordinate with other teams as much as in the past.

In contrast, in the old HTML+CSS vs. JS+PHP separation model, changes to any part of the system required coordination between multiple teams. If the frontend needed a new feature, the HTML/CSS team would have to work with the JavaScript team to ensure the new layout or functionality worked as intended. Today, with teams owning specific components or features from top to bottom, this need for inter-team coordination is greatly reduced, allowing for more rapid development and deployment cycles.

Conway's Law in Action

Conway’s Law remains as relevant as ever. The way we build software today still reflects the way our teams are organized, but the difference is that modern team structures are more feature-focused and less technology-siloed. The old method of splitting responsibilities by technology (HTML+CSS vs. JS+PHP) has given way to a model where each team is responsible for a complete feature or component.

This modern separation of concerns allows for better communication within teams and more focused ownership. Micro-frontends, component-based architectures, and feature-focused teams are all reflections of Conway’s insight: that your software will inevitably reflect the structure of your team. As our team structures evolve, so too do the systems we build, becoming more flexible, modular, and independent.

Conclusion

The shift from technology-based separation of concerns to feature-based separation has revolutionized how we build web applications. Conway's Law explains why this evolution happened: as teams have become more autonomous and feature-focused, the architecture of our systems has followed suit. Micro-frontends, internal component libraries, and component-based development all reflect the modern need for independent, cross-functional teams that own both the frontend and backend of their specific features or components.

While the tools and frameworks have evolved, the fundamental principle remains the same: the way teams are structured directly influences the software they build. By understanding Conway’s Law and the history of separation of concerns, we can better appreciate the systems we work with today and anticipate how they might continue to evolve.

Creating an NPM Package in 2024 (Deno, dnt)

JLarky — Sat, 23 Sep 2023 03:57:18 +0000

Jokey Intro

So, you want to create an npm package? My advice? Don't. It's a lot of work, and the results are often not worth the effort. At the time of me writing this, npm has 2,532,666 packages. By the time you finish this article, it's guaranteed there will be at least 10 more.

On the surface, it sounds simple: write some code in a file and push it to npm. But you can't just push the code; you also need a package.json filled with all sorts of metadata. You can't merely push the source code either. If you're using TypeScript (and you should be), suddenly you have a build step, bundlers, minifiers, CommonJS, ES Modules — the list goes on.

I ain't reading all that. I'm happy for u tho. Or sorry that happened.

The Best Way to Author an NPM Package is Deno

Deno is an alternative JavaScript runtime that comes with built-in lint, TypeScript, and bundling capabilities. You don't need to be familiar with Deno to follow this tutorial.

For the first step, install Deno. If you're on a Mac or Linux, it's just one command:

curl -fsSL https://deno.land/x/install/install.sh | sh

1. Create a New Project

Create a new folder for your project and run deno init:

mkdir is-not-bun
cd is-not-bun
deno init
touch README.md LICENSE

Replace is-not-bun with the name of your package. This tutorial is the text version of this Youtube tutorial and will address the same problem space of determining if a user is running an npm package using Bun (you don't need to know about Bun either).

2. Create your code

Create mod.ts and write your code:

import { isBun } from "npm:is-bun";

export function isNotBun(): boolean {
  return !isBun();
}

export function printIsNotBun() {
  if (isNotBun()) {
    console.log("No Bun, no problem");
  } else {
    console.log("Help, I'm trapped in a Bun factory");
  }
}

Create cli.ts and write your CLI:

import { printIsNotBun } from "./mod.ts";

printIsNotBun();

And run it with:

deno run cli.ts

You will see the output:

No Bun, no problem

Notice the difference, because we are using Deno we have to add npm: prefix when importing npm packages, but the positive is that we don't need to run npm install, because Deno will automatically download the package from NPM.

3. DNT build script

We are going to use dnt - Deno to Node Transform tool to build the npm package.

I recommend you to checkout other examples of DNT configs:

Create a file _build_npm.ts and add the following code:

#!/usr/bin/env -S deno run --allow-read --allow-write --allow-net --allow-env --allow-run
// Copyright 2018-2022 the oak authors. All rights reserved. MIT license.

/**
 * This is the build script for building npm package.
 *
 * @module
 */

import { build, emptyDir } from "https://deno.land/x/dnt@0.38.1/mod.ts";

async function start() {
  await emptyDir("./npm");

  await build({
    entryPoints: [
      // change me
      "./mod.ts",
      {
        kind: "bin",
        name: "is-not-bun",
        path: "./cli.ts",
      },
    ],
    outDir: "./npm",
    shims: {},
    test: false,
    typeCheck: "both",
    compilerOptions: {
      importHelpers: false,
      sourceMap: true,
      target: "ES2021",
      lib: ["esnext", "dom", "dom.iterable"],
    },
    package: {
      name: "is-not-bun", // change me
      version: Deno.args[0],
      description: "Return true if you are running not in Bun.", // change me
      license: "MIT",
      keywords: ["bun"], // change me
      engines: {
        node: ">=8.0.0",
      },
      repository: {
        type: "git",
        url: "git+https://github.com/JLarky/is-not-bun.git", // change me
      },
      bugs: {
        url: "https://github.com/JLarky/is-not-bun/issues", // change me
      },
      dependencies: {
        "is-bun": "*", // change me
      },
      devDependencies: {},
    },
  });

  await Deno.copyFile("LICENSE", "npm/LICENSE");
  await Deno.copyFile("README.md", "npm/README.md");
}

start();

Make sure to replace is-not-bun with the name of your project, change your description, keywords, repository, dependencies and entry points.

"./mod.ts" is the name of the "main" entry in your package, most of the time that's the only entry point you need. But if you are building a CLI tool (for example tsc, ts-node), that's when kind: "bin", comes into play. If you are not planning to build a CLI tool, you can remove the second entry point (the whole object).

4. Build your package

First, let's add npm to .gitignore:

echo "npm" >> .gitignore

And make build script executable:

chmod +x _build_npm.ts

Now we can build the version 0.0.1 of our package with the build script:

./_build_npm.ts 0.0.1

You can check that the build was successful by running:

(cd npm/; node -e "console.log(require('.'))")

The expected output:

{
  isNotBun: [Function: isNotBun],
  printIsNotBun: [Function: printIsNotBun]
}

5. Publish your package

We are at the final step, we can publish our package to NPM:

(cd npm/; npm publish)

Keep in mind that if you never published to npm before you will have to create an account and login first:

npm login

That's it

Let's celebrate a bit what we have accomplished:

We were able to author our package in TypeScript and because we are using Deno we can run deno run cli.ts without separate build step or even npm install and get nice developer experience (even though we were using dependencies from NPM)
Using dnt we were able to create nice and modern package setup with three output formats: CommonJS (npm/script/mod.js), ES Modules (npm/esm/mod.js) and TypeScript source (npm/src/mod.ts)
That npm package is checking all the boxes, it generated .d.ts files for TypeScript users and even .js.map with source maps for debugging
As a bonus we even got CLI that you can run with npx is-not-bun or as a script in your package.json "scripts": { "fun": "is-not-bun" } that you can run with npm run fun
And we can use some nice built-in Deno tools as extra bonus, which I will cover in the next section

Extra bonus

This part is not technically required, remember when I said that you don't have to actually care about Deno? Well, this is where the sales pitch comes in.

First things first, we have a few files that were created during deno init, I'm going to guide you through them.

`deno.json` and `main.ts`

Remember how I said that DX for development of packages is great in Deno? It's actually even better than that. deno run supports --watch flag that will re-run your code every time you save a file, no need for nodemon and similar tools.

Similar to package.json Deno has deno.json and at the moment it only has one task defined there:

deno task dev

It will run main.ts with --watch flag, so you can keep your development code in that file.

So in the GH repo here's the content of main.ts:

import { isNotBun } from "./mod.ts";

// Learn more at https://deno.land/manual/examples/module_metadata#concepts
if (import.meta.main) {
  console.log("In Deno isNotBun is", isNotBun());
}

`main_test.ts`

Deno has built-in test runner, so you don't need to install vitest or jest. To run tests you just do:

deno test

In GH repo this file looks like this:

import { assertEquals } from "https://deno.land/std@0.195.0/testing/asserts.ts";
import { isNotBun } from "./mod.ts";

Deno.test(function bunTest() {
  assertEquals(isNotBun(), true);
});

`main_bench.ts`

It looks like this file is no longer there with the new version of deno init, but I still have it for old time sake. To run simple benchmarks you can do:

deno bench

In GH repo this file looks like this:

import { isNotBun } from "./mod.ts";

Deno.bench(function benchIsNotBun() {
  isNotBun();
});

Conclusion

Creating npm packages can be challenging. We've seen many tools in this domain, and I encourage you to try dnt. With dnt, I was finally able to pass the package.json linter, which is no small achievement (try jotai, redux, vite).

This tutorial hasn't covered many dnt features. For more information, please check out this tweet for further reading and some replies from happy users.

Revisiting Web History from web 1.0 to RSC and HTMX

JLarky — Mon, 10 Jul 2023 05:36:01 +0000

Recently, I have been following HTMX talks and realized that while discussing the history of the web, we tend to simplify the evolution timeline, often omitting critical aspects. Let's delve deeper into the web's evolution journey from the beginning up to where HTMX and other web technologies currently stand.

Understanding Web According to HTMX

HTMX explains the history of the web in a simple sequence:

Web 1.0 existed with just HTML and no JS.
Web 2.0 came along with Single Page Applications (SPAs) and JSON communication for everything.
HTMX marked a return to the form.

However, as someone who has experienced the evolution of the web first hand, my recollection differs slightly.

My Recollection of the Web Evolution

The Dawn of Web Apps

In my view, turning websites into applications began before CSS and JS had their footprints in web development. Around 1996-1997, we saw the emergence of ActiveX and Java applets, just a few years after CSS and JS were born.

In the 2000s, technologies such as Flash, Silverlight, and XMLHttpRequest came to the fore. It's interesting to note that it was called XMLHttpRequest and not JSON HTTP Request, suggesting it was primarily designed to exchange HTML or XML. All this happened during the web 1.0 era, highlighting the app vs. website divide even then.

The Era of Web 2.0

The drastic shift came around 2005, marking the start of the web 2.0 era. Platforms like Drupal, WordPress, and others were heavily used. They utilized JavaScript (JS) and embraced AJAX or AJAJ, but the focus remained on using what already worked, i.e., good old HTML from web 1.0. This era gave birth to jQuery, catering to developers who were hesitant to learn JS and preferred to stick to server-side languages.

However, 2005 was also the year when ActiveX died out, and the 2007 iPhone famously didn't support Flash. This change led to a massive demand for creating web apps that relied solely on HTML, CSS, and JS.

The Evolution of JavaScript

Over time, the question that plagued developers was: "Can I re-create existing Flash apps using only HTML, CSS, and JS?" This trend was a step in the right direction, despite the growing pressure to utilize users' CPU and memory resources.

However, browser capabilities hadn't caught up yet. HTML5, CSS3, and ES5 weren't available, and JS was still considered unreliable. It's interesting to note that browsers like IE8 and even Chrome 1 didn't support JSON.parse.

The 2010s - A Turning Point

The years 2010-2012 were pivotal as browsers finally started catching up with emerging web technologies. HTML5, CSS3, and ES5 (along with JSON.parse) became commonplace. The History API emerged, allowing URL modifications without reloading the page.

Around this time, a host of new technologies and frameworks began to surface. For instance, Angular, Ember, Backbone, and Knockout were introduced. With the rise of these technologies, the term Single Page Application (SPA) gained popularity.

Web Transformation in 2015

Fast forward to 2015, traditional web frameworks such as Drupal, WordPress, Django, and Rails had their time in the limelight. However, as mobile apps gained popularity, web traffic started shifting, with 50% coming from mobile devices. In response, Google introduced progressive web apps (PWA), Accelerated Mobile Pages (AMP), and Lighthouse, while promising to index SPA-style web apps.

This period also saw the rise of a new generation of frameworks like React, Gatsby, Next.js, and others.

The Era of Overprescribed JS, JSON, and API

From 2015 onwards, we've seen a persistent focus on JS, JSON, and APIs. Around 2020, traditional server frameworks finally started to adapt to the "HTML is now for apps" world. This was when we saw the rise of Blazor, Phoenix LiveView, Laravel Livewire, and of course, HTMX!

What’s Next?

Reflecting on the history of the web, we can observe two parallel streams of evolution: traditional websites with server-side logic and just a sprinkling of JS, and the more complex side starting with applets and aiming to provide an app-like experience.

What seems to be the ongoing battle is finding a way to maintain the simplicity of traditional MPAs while delivering a user experience akin to SPAs. In this regard, both HTMX and React Server Components are arguing their case to be the best possible emulation of the MPA.

Regardless of how you perceive "traditional web," what's fascinating is that HTML continues to stand tall, even with the decline of /cgi-bin/hello.cgi Perl scripts. The concept of delivering an app over HTML remains alive and kicking, even in the face of competition from native apps.

In the end, it is a reminder that the evolution of the web is continuous, filled with turning points and paradigm shifts. But amidst all these changes, the essence of web development, which lies in creating rich and seamless user experiences, remains unchanged.

Using Git Bisect to Find the Commit that Broke ESLint

JLarky — Fri, 23 Jun 2023 22:15:47 +0000

In the world of software development, bugs and errors are inevitable. Even with the most comprehensive testing suite, some bugs might manage to slip into your codebase. So, when something goes wrong, how do you find the culprit commit?

Luckily, Git provides a powerful tool for this very purpose, named git bisect. It uses a binary search algorithm to quickly and efficiently find the exact commit that introduced a bug.

In this blog post, we will guide you through the process of using git bisect, specifically with the git bisect run command, to debug a failing yarn lint command.

Understanding Git Bisect

Git bisect is a binary search tool that helps you discover which specific commit introduced an error. This works by moving between commits, effectively halving the search range each time, until it narrows down to the faulty commit.

You mark the known good and bad commits, and git bisect will do the rest. It's an extremely useful tool for large repositories where manually checking each commit would be tedious or nearly impossible.

Preparing for Bisect

Before we start, ensure your repository is in a clean state; any changes should be committed or stashed. This is important because git bisect will be switching between different commits during its search.

Starting the Bisect Process

The first step is to start the bisect process with the following command:

git bisect start

Now, we need to inform Git about the state of our current commit. Since we know that our current commit is causing the yarn lint command to fail, we can mark it as "bad":

git bisect bad

Next, we need to specify a commit where we know that everything was working as expected - a "good" commit. Let's assume that the origin/main branch does not have the bug. We can mark it as good with:

git bisect good origin/main

Once you do this, Git will automatically checkout a commit in the middle of the range between the good and bad commits.

Automating the Bisect Process

Here's where the magic happens. Instead of manually checking if each commit is good or bad, we can automate the process with git bisect run.

git bisect run yarn lint

In this case, Git will keep bisecting without your intervention until it finds the first bad commit. It will run the yarn lint command on each commit, and if the command succeeds (returns 0), the commit is considered good. If it fails (returns anything other than 0), the commit is marked as bad.

Once the faulty commit has been identified, Git will present a message like This is the first bad commit along with the commit details.

Wrapping Up the Bisect Process

After Git has found the first bad commit, we need to end the bisect process. We do this with:

git bisect reset

This will take you back to the commit you were on when you started the bisecting.

Conclusion

Using git bisect run can significantly simplify the process of identifying a problematic commit, especially in larger codebases. With the help of an automated command like yarn lint, it makes it easier than ever to isolate issues and keep your project running smoothly. Understanding and using such powerful tools is what separates good developers from great ones, and is a step forward in writing more reliable, robust software.

The Tectonic Shift in React Ecosystem: Unearthing the Future with Next.js, Remix, Gatsby, Vite, QGP, and Astro

JLarky — Mon, 20 Mar 2023 14:37:59 +0000

Introduction

The React ecosystem has recently witnessed a seismic shift, with the team's decision to move from recommending Create React App (CRA) to more feature-rich frameworks like Next.js, Remix, and Gatsby. Additionally, the rise of alternative tools like Vite, QGP, and Astro has stirred numerous discussions within the web development community, as developers ponder the implications for beginners and teams managing large projects. In this blog article, we'll briefly touch on the key points discussed during our live stream and invite you to watch the full video for a more in-depth exploration of this tectonic shift in the React landscape.

React's Shift: apps written "fully in React"

React's decision to switch from CRA to frameworks like Next.js, Remix, and Gatsby stems from the growing demand for more robust solutions in building production-grade applications. Alongside these frameworks, Vite, QGP, and Astro have emerged as popular alternatives, each bringing unique features and benefits to the table.

Next.js: A popular choice among developers, Next.js boasts features such as server-side rendering, static site generation, and API routes. Backed by Vercel, this framework enjoys a strong community presence and offers an opinionated approach to building React applications.
Remix: Developed by the creators of React Router, Remix focuses on server rendering and optimized loading of data and assets, providing a modern, fast, and enjoyable developer experience. Its flexible approach allows developers to customize their setup and choose the features they need.
Gatsby: Gatsby is a powerful static site generator that leverages GraphQL to manage data and build optimized websites. With its vast plugin ecosystem and focus on performance, Gatsby is an excellent option for content-driven websites and projects that require seamless data integration.
Vite: Created by Evan You, the creator of Vue.js, Vite is known for its simplicity and speed, making it an ideal solution for beginners looking for a more accessible entry point into React development without the added complexity of more advanced frameworks.
QGP: This open-source project aims to provide a smooth migration path from CRA to other solutions like Astro or Vite. It allows developers to run their applications in both environments simultaneously, making it easier to transition from one to the other gradually.
Astro: Astro is a new static site generator that allows developers to build fast, optimized websites using components from various frontend libraries, including React. With its user-friendly experience and focus on performance, Astro is an exciting addition to the React ecosystem.

Implications for Beginners

The shift from CRA to more advanced frameworks has raised concerns about the impact on beginners. With additional complexity and features, newcomers may find frameworks like Next.js, Remix, and Gatsby overwhelming. However, alternatives like Vite and Astro offer more approachable options for those new to React. It's crucial to strike a balance between providing accessible options for beginners and offering powerful tools for experienced developers and large projects.

Teams Managing Large Projects

For teams handling large-scale projects, the shift towards more feature-rich frameworks like Next.js, Remix, and Gatsby, as well as alternatives like Vite and Astro, presents exciting opportunities. These tools offer built-in performance optimizations, more advanced data handling, and better support for server-side rendering and static site generation. While the transition may require some effort, the long-term benefits could significantly improve the development process and the quality of the applications being built.

Conclusion

The ongoing evolution of the React ecosystem and the shift away from Create React App have brought new tools and frameworks to the forefront. As developers, it's essential to stay informed, adapt to these changes, and choose the best tools for our projects.

We hope this blog article has piqued your interest in the live stream discussion, where we dive deeper into the implications of React's shift towards Next.js, Remix, and Gatsby, and explore the vibrant landscape of modern web development. So, don't miss out! Click the link below to watch the full video and join the conversation.

https://www.youtube.com/live/zDG6F7VXfxE

Switching from React to Svelte: Why it's Time to Make the Move

JLarky — Sun, 05 Mar 2023 05:11:22 +0000

Good morning, fellow developers! Today, I want to talk to you about an important topic that's been on my mind for a while now: why it's time to switch from React to Svelte.

Now, I know that many of you are probably comfortable with React. After all, it's been a popular choice for front-end development for years. But hear me out. Svelte is a newer, more modern approach to web development that offers some key advantages over React.

Firstly, Svelte is much faster than React. Svelte compiles your code into highly optimized vanilla JavaScript, resulting in much smaller bundle sizes and faster load times. This means that your applications will be snappier and more responsive, providing a better user experience for your users.

Secondly, Svelte is much easier to learn and use than React. With React, you need to learn a whole ecosystem of tools and libraries just to get started, which can be overwhelming for beginners. Svelte, on the other hand, has a much simpler and more intuitive syntax, making it easier to get up and running quickly.

But it's not just about ease of use and performance. Svelte also offers some unique features that are not available in React. For example, Svelte's reactive programming model allows you to write code that is both more concise and more expressive than in React. Svelte also offers powerful animations and transitions out of the box, which can make your applications feel more polished and professional.

Now, I know that switching from React to Svelte can seem like a daunting task. But trust me, it's worth it. With Svelte, you'll be able to build faster, more responsive applications with less code and less hassle. And as an added bonus, you'll be learning a cutting-edge technology that is quickly gaining popularity in the web development community.

So let's take the plunge and switch from React to Svelte. Your users (and your sanity) will thank you for it. Happy coding!

DEV Community: JLarky

Running a Local Sandboxed macOS Desktop Using VNC and a Restricted User

Why This Works Well for Developers

Step 1 — Create a Restricted User

Step 2 — Enable Screen Sharing

Step 3 — Log Into the Sandbox User

Step 4 — Connect to the Sandbox Desktop

Fix for “You Cannot Control Your Own Screen”

Step 5 — Run Your Risky Commands

Convenience Shortcut

⚠️ Security Caveat

Advantages Over Virtual Machines

Final Result

Modern Ways to Tame GitHub Action Workflows

The Landscape: Lint, Generate, or Visualize

Tooling in the Wild

A Few Standout Tools

The Bigger Question

Combine Multiple Repos Into One Monorepo With One Root package-lock.json (Step-by-Step Guide)

Unifying Multiple Apps Into One Monorepo With a Single Root Lockfile (npm Workspaces)

Who this is for

Problem statement

Approach (high level)

Target workspace layout

Migration flow (end-to-end)

Optional merge helper: merge-to-root.ts

Dependency diff helper: diff-workspace-deps.ts

End-to-end example (bringing two apps into one root lockfile)

Notes on npm vs pnpm/Yarn

Pitfalls and guardrails (brief)

Conclusion

The Hidden Costs of Switching from NetBeans to Cursor

1. Comfort vs. Performance: Muscle Memory Fights Back

2. Project Types: Java-Centric IDE vs. Language-Agnostic Editor

3. AI-First Isn’t Always Instant Productivity

4. Debugging: From Integrated Simplicity to DIY Configs

5. Build Systems & Tooling Expectations

6. Extension Overload: From All-In-One to Choose-Your-Own Adventure

The Bigger Picture

Is It Worth It?

What Most People Get Wrong About the Term SSR

So Here’s the Deal

Before SSR, There Was...

The Problem With That

The Main Difference

SR vs. SSR

Hydration: The Key

The Early Days

Why Care About This?

Inertia.js and SSR

So, Can PHP Do SSR?

What About SSG?

The React Innovation

Qwik and “Resumability”

Argument Against Solving the Double Data Problem in JavaScript SSR Frameworks

1. Complexity and Fragility

2. Limited Real-World Performance Gains

3. Prioritizing Development Time and Impactful Optimizations

4. Loss of Flexibility and Developer Experience

5. Existing Strategies Alleviate Performance Concerns

Conclusion

Conway's Law and Separation of Concerns in Web Development

The Shift to Component-based Architecture

Micro-frontends and Independent Team Ownership

Conway's Law in Action

Conclusion

Creating an NPM Package in 2024 (Deno, dnt)

Jokey Intro

I ain't reading all that. I'm happy for u tho. Or sorry that happened.

The Best Way to Author an NPM Package is Deno

1. Create a New Project

2. Create your code

3. DNT build script

4. Build your package

5. Publish your package

That's it

Extra bonus

deno.json and main.ts

main_test.ts

main_bench.ts

Optional merge helper: `merge-to-root.ts`

Dependency diff helper: `diff-workspace-deps.ts`

`deno.json` and `main.ts`

`main_test.ts`

`main_bench.ts`