Core Concept: Content-Addressed Code

At the heart of Unison is the idea that every code definition is identified by a unique cryptographic hash of its syntax tree, rather than its human-readable name. Names are treated merely as metadata pointers to these hashes. Because the syntax tree structure strips away specific naming variations and normalizes variables, a hash uniquely and immutably pins down a function's exact implementation and its dependencies.

Key Benefits of Unison

1. Simplifying Distributed Programming

• On-the-Fly Dependency Syncing: Since definitions are identified by hashes, arbitrary computations can be shipped directly across a network. The receiving machine checks the bytecode for missing hashes, requests only what it lacks on the fly, caches them, and runs the computation.

• Elimination of "Glue" Infrastructure: Network boundaries are handled naturally by the language. There is no need for complex out-of-band setups, container building, or writing tedious serialization/deserialization layers (JSON/YAML) to stitch separate programs together.

2. Elimination of Builds and Re-testing

• Permanent Compilation Cache: Because a definition's hash never changes, code is parsed and typechecked exactly once. The results are permanently cached in the codebase format, eliminating compilation wait times.

• Deterministic Test Caching: Pure, deterministic test results are cached. If a function's hash and its dependencies haven't changed, the tests never need to be rerun.

3. No Dependency Conflicts

• Coexistence of Versions: Dependency conflicts (like the diamond dependency problem) occur when different definitions compete for the same name. Because Unison references code by hash, multiple versions of the same library or type (e.g., two different Email types) can coexist seamlessly in the same codebase.

• Non-Blocking Upgrades: Developers can write functions to bridge or convert between different versions at their own leisure, without a dependency conflict breaking the build or halting work.

4. Typed, Durable Storage

• Automatic Serialization: Any value or function can be persisted and loaded without manually writing encoders, decoders, or schemas.

• Guaranteed Deserialization: Since the serialized values are bound to immutable content hashes, deserializing data years later will always yield the exact same behavior, regardless of how the surrounding codebase has evolved.

• Type-Safe Database Interoperability: Storage layers can be typed directly within the Unison language, ensuring compile-time type safety when interacting with persisted data.

5. Richer Codebase Tools

• Codebase as a Database: A Unison codebase is a structured database containing perfect dependency graphs and type indices, making features like type-based search and hyperlinked documentation exceptionally easy to build.

• Decoupling Text from Storage: While developers still edit code as text, the codebase stores it in a structured format. This enables instant, codebase-wide renames that never break downstream users.

6. Structured Refactoring

• No Broken Codebase States: Refactoring in Unison means changing which hashes human-readable names point to.

• Tidy "Todo" Lists: Instead of causing a cascade of compiler errors, the codebase manager creates a parallel workspace. The original program remains fully operational while Unison provides a precise list of name updates to resolve before cutting over to the new implementation.

How does Go compile so fast?

The Go programming language was conceived in late 2007 at Google to address severe software engineering challenges posed by massive-scale server infrastructure, including multicore processors, networked systems, and codebases comprising millions of lines of code. Existing languages like C++, Java, and Python were ill-suited for this modern environment, leading to painfully slow build times (minutes or hours), uncontrolled dependencies, and clumsy development processes for teams of hundreds of engineers. Go was explicitly designed not as a research breakthrough but as an excellent, efficient, compiled tool focused on productivity and scalability for large projects. Its core goal was to eliminate the slowness and clumsiness of development by prioritizing practical engineering concerns such as rigorous dependency management, adaptable software architecture, and cross-component robustness.

A critical scaling innovation in Go is its dependency model, which is explicit, clear, and "computable." Unlike the slow, convoluted C/C++ "include of include" approach that can blow up compilation input by factors of 2000, Go mandates that unused package imports are a compile-time error, ensuring a precise dependency graph with minimized compilation. Crucially, Go compilers read only the necessary "exported" type information from the object file of an imported package, avoiding the massive I/O overhead associated with reprocessing source headers, leading to dramatically faster build times. Further enhancing clarity and tooling, Go's grammar is simple, C-like, and parsable without a symbol table. Identifier visibility is dictated solely by the initial letter's case (uppercase for public), decoupling packages and guaranteeing that adding new exported names will not break existing client code. This structure enables powerful, automatic tools like gofmt for canonical source code formatting and gofix for large-scale, semantic refactoring, allowing the codebase to be updated automatically as APIs evolve—a capability infeasible in massive C++ codebases.

Go incorporates modern semantic features for improved software engineering, including built-in concurrency and automatic garbage collection (GC). Concurrency, based on CSP (Communicating Sequential Processes) via goroutines and channels, is added orthogonally to the procedural model, making it practical and robust for writing networked software. The decision to use GC was made to simplify memory management and interface specification, although Go provides tools to limit GC pressure, such as controlling data structure layout and allowing interior pointers. Architecturally, Go rejects type-based inheritance and instead favors composition using simple, implicit interfaces. A type satisfies an interface merely by implementing its methods, promoting a flexible, decoupled, and linear design style where components (like io.Reader and io.Writer) can be fluidly chained, preventing the brittle code that results from rigid type hierarchies. Finally, explicit error handling is favored, using multiple return values and the simple error interface instead of conventional exceptions, which maintains straightforward control flow and forces programmers to address issues as they arise rather than ignoring them.

Summary

In this article, developer and security researcher Lyra Rebane challenges the contemporary reliance on bloated JavaScript frameworks, arguing that modern HTML and CSS have evolved to a point where much of the interactivity and styling previously handled by scripts can now be implemented natively. Rebane posits that the "bloat" of React or NextJS apps—often resulting in slow load times and hydration errors—is frequently unnecessary for the majority of websites.

The article provides a technical deep dive into several "game-changing" CSS features and best practices:

• Modern Syntax and Tooling: The author highlights native CSS nesting, which significantly improves readability and reduces the need for preprocessors like Sass. They also explore the power of relative colors (using the from keyword), allowing developers to programmatically derive colors within CSS.

• The "Baseline" Guarantee: A discussion on the "Baseline" initiative, which provides a standard for browser compatibility, ensuring developers know when features like nesting are safe for production use across all major engines.

• Performance and Accessibility: Rebane explains that CSS animations are superior for performance because they run on the compositor thread, avoiding the main-thread stutters common in JavaScript. Furthermore, building JS-free sites respects the privacy and security of users who use hardened browsers with JavaScript disabled.

• Interactive UI without Scripts: The text demonstrates practical examples of building complex components—such as theme switchers, tabbed interfaces, and accordions—using only radio buttons, the :checked pseudo-class, the :has() selector, and the <details> element.

• Mobile-First Viewport Units: An essential guide to the new responsive viewport units (svh, lvh, dvh), which solve the longstanding issue of mobile browser URL bars obscuring content.

• Input Validation: A showcase of native HTML5 validation using regex patterns and CSS pseudo-classes like :user-valid to provide immediate feedback without a single line of client-side code.

Finally, Rebane concludes with a philosophical reflection on web development as an "art form." They argue that the choice to use CSS over JavaScript isn't just about performance or security, but about creative expression and the rejection of AI-driven, commercialized coding environments in favor of handcrafted, intentional design.

Transcript

You don't need JavaScript anymore

2025-08-28 | CSS

So much of the web these days is ruined by the bloat that is modern JavaScript frameworks. React apps that take several seconds to load. NextJS sites that throw random hydration errors. The node_modules folder that takes up gigabytes on your hard drive.

It’s awful. And you don’t need it.

Network Log (Simulated):

• app - 200 - document - 153.8 kB - 51 ms

• 6920616d20612066-s.p.woff2 - 200 - font - 31.5 kB - 32 ms

• 686579206d652074-s.p.woff2 - 200 - font - 28.5 kB - 116 ms

• 77687920646f6573.css - 200 - stylesheet - 253 kB - 47 ms

• 2074686520646566.js - 200 - script - 648 kB - 83 ms

• 61756c74206e6578.js - 200 - script - 166 kB - 363 ms

• 746a732074616b65.js - 200 - script - 83.3 kB - 46 ms

• turbopack-20757020.js - 200 - script - 38.0 kB - 95 ms

• 423f207468617427.js - 200 - script - 414 B - 34 ms

• 73206d6f72652074.js - 200 - script - 32.6 kB - 49 ms

• 68616e206d792065.js - 200 - script - 15.1 kB - 71 ms

• 6e7469726520626c.js - 200 - script - 143 kB - 48 ms

• hey there! - 200 - script - 4.1 kB - 103 ms

The intro paragraph of this post is tongue-in-cheek. It’s there to get you to read the rest of the post. I suspect the megabytes of tracking scripts intertwined with bad code is far more likely to be the real culprit behind all the terrible sites out there. Web frameworks have their time and place. And despite my personal distaste for them, I know they are used by many teams to build awesome well-optimized apps.

Despite that, I think there’s some beauty in leaving it all behind. Not just the frameworks, but JavaScript altogether. Not every site needs JavaScript. Perhaps your e-commerce site needs it for its complex carts and data visualization dashboards, but is it really a necessity for most of what’s out there?

It’s actually pretty incredible what HTML and CSS alone can achieve.

So, what do you say?

My goal with this article is to share my perspectives on the web, as well as introduce many aspects of modern HTML/CSS you may not be familiar with. I’m not trying to make you give up JavaScript, I’m just trying to show you everything that’s possible, leaving it up to you to pick what works best for whatever you’re working on.

I think there’s a lot most web developers don’t know about CSS. And I think JS is often used where better alternatives exist.

So, let me show you what’s out there.

“But CSS sucks”

I believe a lot of the negativity towards CSS stems from not really knowing how to use it. Many developers kind of just skip learning the CSS fundamentals in favor of the more interesting Java- and TypeScript, and then go on to complain about a styling language they don’t understand.

I suspect this is due to many treating CSS as this silly third wheel for adding borders and box-shadows to a webapp. It’s undervalued and often compared to glorified crayons, rather than what it really is - a powerful domain-specific programming language.

It’s telling when to this day the only CSS joke in the webdev circles is centering a div.

Yes, the syntax isn’t the prettiest, but is it really that hard?

Besides, your devtools probably come with a fun little gadget that lets you fiddle with the flexbox by just clicking around. You don’t even need to remember the syntax. I don’t think CSS is fundamentally any more difficult than JS, but if you skip the basics on one and only focus on the other, it’s no surprise it feels that way.

“But it’s painful to write”

Another source of disdain for CSS is how awful it has been to write in the past. This is very much true, and is probably why things like Sass and Tailwind exist.

But that’s the thing, it used to be bad.

Rebane @rebane2001 (Tweet/Post):

btw u should write css like

and html like <cool-thing shadow>wow</cool-thing> because it's allowed & modern & neat!

In the past few years, CSS has received a ton of awesome quality-of-life additions, making it nice to do stuff that has historically required preprocessors or JavaScript. Nesting is definitely one of my favorite additions!

In the past, you’ve had to write code that looks like this:

And yeah, that’s pretty awful to work with. But let’s try it with nesting:

That is way nicer to read! All the relevant parts are right next to each other.

You may have noticed that I’m also making use of relative colors in the second example. The gist of it is that you can take an existing color, modify it in many different ways across multiple color spaces, and mix it with other colors using color-mix().

There are so many cool new CSS features: using (width <= 768px) instead of max-width, the lh unit, the scrollbar-gutter property, or vertical centering without flex/grid.

All of this is brought together by Baseline. It’s a guarantee that a specific feature works in every major browser. Nesting, for example, has been fully supported in all browsers since December 2023.

Why bother?

I think my reasons for using CSS fall into two main categories - because some users don’t want to use JavaScript, and because doing things in CSS can be genuinely better.

Many security researchers use hardened browser configurations, which often means disabling JavaScript by default. The same goes for privacy-conscious users. As an experiment, I opened a local news site: it fetched 93 JS files. That's crazy!

And the performance of CSS is so much better! Every JavaScript interaction has to go through an event loop. But CSS animations run in the separate compositor thread and aren’t affected by stutters in the event loop.

Practical Examples

Transitioning with @starting-style

In the past, fade-ins required complex keyframes or JS timeouts. Now:

Theming with light-dark()

Radio Buttons as Tabs/Pickers

Input elements are a great foundation. You can style labels based on the input state:

Accordions with <details>

The <details> element is great for FAQ sections. It is accessible, works with Ctrl+F, and requires no JS.

Validation

The :user-valid pseudo-class only activates after user interaction, which is a big UX improvement over :valid.

Do not the vw/vh

On mobile, URL bars hide and show, making vh units ambiguous. The solution is responsive viewport units:

• lvh: Largest viewport height (useful for full backgrounds).

• svh: Smallest viewport height (crucial for buttons that must always be visible).

• dvh: Dynamic viewport height (updates as the UI changes, but can be laggy).

Example browser-reported values:

• vh: 100% of the viewport (implementation dependent).

• lvh: 100% of the largest possible viewport.

• svh: 100% of the smallest possible viewport.

• dvh: 100% of the currently visible viewport.

CSS Wishlist

• Reusable blocks: An @apply type feature to put classes in other classes.

• Combined @media selectors: The ability to combine media queries and class selectors in one block.

• n-th child variable: A way to get the index of an element directly into a CSS variable.

• Unit removal: The ability to divide 100vw by 1px to get a unitless number.

The art

To me, web development is an art, and thus, CSS is too. I have a hard time relating to people who do webdev solely for money. Build chain tooling, linters, and AI take the creativity out of my work. I don't even use an IDE; I use Sublime Text. Using CSS is how I express myself.

Afterword

This post is a self-contained HTML file with no JavaScript, images, or external resources—everything is handwritten HTML/CSS, weighing around 49kB gzipped.

Thank you for reading <3

Uiua is a general purpose array-oriented programming language with a focus on simplicity, beauty, and tacit code.
Uiua has the terseness and expressivity afforded by Unicode glyphs without the need for special keyboard or editor support. Instead, the language comes with a formatter that converts the names of built-in functions into glyphs.

Nota is a new document-authoring language designed to turn static academic papers and blog posts into interactive, responsive web applications that compile to JavaScript and run in any browser. Its core idea is to make document structure explicit—definitions, references, variables, functions, data structures—so the browser can understand and exploit that structure for the reader (clickable references, tooltips, responsive layout, accessibility, etc.).

A Nota file compiles to a single self-contained HTML/JS bundle, so authors get the portability of PDF with the dynamism of the web (resizing, translation, dark mode, screen-reader support, live diagrams via KaTeX, Vega-Lite, Penrose). Installation is via the @nota-lang/nota npm package (Node ≥ 16).

The CLI provides nota build for one-shot compilation and nota edit for an interactive editor. The language has a low floor (Markdown-like syntax) and a high ceiling (full JavaScript expressivity), aiming to bridge the gap between LaTeX/Pandoc/Markdown (static HTML) and professional web development.

The project is early-stage, API-unstable, and seeks early adopters. Motivation: PDFs replicate paper constraints; web pages are the future but currently require web-dev skills; Nota wants to democratize that dynamism while preserving scholarly rigor.

K is a general-purpose programming language that excels as a tool for data wrangling, analytics and transformation.