offline
Marcus Obst
webworker.js

Javascript - New Wave of HTML

Lol @ router implementations in JavaScript... it's already in the browser :)

❓ About Memory Leaks

http://triskweline.de/unpoly-rugb/#/75

HyTags

100

https://hytags.org/

hyTags is a programming language embedded directly in HTML for building interactive user interfaces in backend-driven web applications and static websites.

AlpineJs

https://github.com/alpinejs/alpine is really close to Vue, but much slimmer and focused on only a handful of components.

https://alpine-ajax.js.org is an attempt to use htmx/unpoly like dyntax

Alpine Ajax

Implements the HTMX or Unpoly behavior with AlpineJs.

https://alpine-ajax.js.org

Petite Vue

https://github.com/vuejs/petite-vue

5kb subset of Vue optimized for progressive enhancement and even slimmer than Alpine.js lol.

Quick Demo: https://codepen.io/localhorst/pen/GRmLjzb

Surreal

Tiny jQuery alternative for plain Javascript with inline Locality of Behavior!

https://github.com/gnat/surreal

<button hx-get="/">TEST
	<script>
		me().on('htmx:afterRequest', _=>{
			console.log('run script')
		})
	</script>
</button>

<script>me()</script> refers to the <button> I really like this concept.

Htmx

Htmx is the successor of intercooler.js, without jQuery dependency and focus on HTTP requests and extensibility.

Similar to Unpoly, htmx wants your server to do the heavy lifting, like parsing JSON, and send back HTML instead of client side templating (Client side templating is possible via an extension and a template engine of your choice.).

Also creator of Idiomorph used by #Hotwire (Turbo) and Datastar.

Unpoly

27e16ab0551a9afa9200ed7a7bd22cd7_MD5

Forms with Unpoly

http://triskweline.de/unpoly-rugb/#/52

Two Way Binding with Rivets.js

http://rivetsjs.com/

<div class='template' up-data='{ "name": "Arne" }'>
  <input rv-value='name'>
  Hello { name }!
</div>

up.compiler('.template', function(element, data) {
  let view = rivets.bind(element, data)
  return function() { view.unbind } // clean up
})

Source

Why would I use this instead of VueJs? Occasionally you need to integrate a templating and binding system in a crowded legacy environment, where it's easier to integrate something like rivets into existing template/MVC system than re-building and re-factoring large amounts of existing (working) code to bring in something like vue. -- https://github.com/mikeric/rivets/issues/730

Tinybind is a successor of Rivets.js, but already outdated (no commits since 2019)

Middleware to Handle Requests Server-side

Datastar

🚀

https://data-star.dev/guide/getting_started

If you are familiar with libraries, like HTMX or AlpineJs; Datastar brings them together. This breaks down essentially to:

  1. Send the current UI from your backend via HTML fragments like HTMX.
  2. Manage client-side state that wouldn’t make sense to be managed by your backend like AlpineJS.

Intro

Hotwire (Turbo)

9fc77a13431cf69f413df8ff06842f7e_MD5

https://turbo.hotwired.dev

Hotwire is the label under which the new version of Turbolinks and Stimulus resides.

Turbo now has something called Frames that can be targeted if you want to swap out content or lazy load html fragments.

µJS

https://mujs.org/

There's no framework to learn, no build step, no server-side changes. Add a single script tag to your existing site, call mu.init(), and every internal link becomes an AJAX navigation. It works with any backend — PHP, Python, Ruby, Go, or anything that serves HTML.

Turbolinks

🚀

Turbolinks might be the easiest script to automagically make a website faster (means the perception of speed).

Drop it in and all links are getting intercepted and a loading indicator is added by default. Depending on existing JavaScript there might be some work to be done and some head wrapping around the concept and side effects of scripts and events living in the page forever.

Turbolinks also parses inline Java Script (unpoly doesn't)

Two Way Binding with Stimulus.js

https://stimulusjs.org/

Trimmings

I want to like it and to use it, but it's quite limited.

https://github.com/postlight/trimmings

Mavo

https://mavo.io/

Some More

https://htmx.org/essays/alternatives/

Framework Notes — Darren Shepherd interview

Video: “What I hate about React, HTMX, NextJS, Datastar, Templ, Go…”

YouTube video

React — 04:03

Essence: React’s hook-based state model begins simply but becomes hard to reason about as an application grows.

Darren’s objection is less about React as a view library or JSX itself, and more about the evolution toward hooks and reconciliation-style state management. Components execute repeatedly rather than having an obvious initialization/setup phase; state and effects can therefore feel non-linear. As hooks accumulate or are wrapped into custom hooks, it becomes difficult to predict what runs, why it runs, and which state change triggered it.

He compares the mental model to backend reconciliation loops—something he knows well from Kubernetes-style orchestration—but argues that it is inherently difficult to teach and operate across a team. React also leaves an application with two synchronization problems: managing client-side state and reconciling that with the server’s authoritative state.

His core point: React can deliver working software with a vast ecosystem, but its dominant state-management model creates complexity that is easy to underestimate.

HTMX — 13:16

Essence: HTMX has a compelling, simple server-first premise, but it is not a complete application platform.

He likes HTMX’s idea of moving work back to the server: instead of fetching data, managing it in browser state, rendering it, and inserting it into the DOM, the server can return the HTML that should be displayed. For many ordinary interactions—such as paginating a table—that can be simpler and potentially more direct.

The friction starts as soon as an interface needs meaningful browser-side interactivity. Then Alpine.js enters the stack, followed by UI libraries, build tooling, package management, and choices about components. HTMX solves one focused problem very well, but it does not prescribe or provide the end-to-end conventions, component ecosystem, and maintenance path that teams often need.

His core point: HTMX is a strong foundation, but choosing it shifts many architectural decisions back to you.

Alpine.js — 15:44

Essence: Alpine supplies the local browser reactivity that HTMX applications quickly need.

Darren presents Alpine as the natural next dependency after adopting HTMX: HTMX handles server interactions, while Alpine handles small client-side behaviors. He regards the combination as functional and reasonable, but it demonstrates the broader problem: a supposedly small stack rapidly becomes a collection of independently chosen parts.

His core point: Alpine is useful, but its necessity reveals that HTMX alone does not cover typical UI needs.

DaisyUI — 16:19

Essence: A UI library helps, but adopting one can reintroduce tooling and ecosystem decisions.

DaisyUI appears as an attempt to avoid building a component system from scratch. However, using it may mean bringing in npm and its workflow after deliberately avoiding that complexity. The issue is not DaisyUI itself; it is the continual expansion of decisions around a minimalist hypermedia stack.

His core point: every gap filled by another library can reduce the simplicity that attracted you to HTMX in the first place.

Next.js — 18:37

Essence: Next.js is heavy and complex, but it offers an end-to-end path that fragmented stacks lack.

He calls Next.js a “monstrosity,” yet acknowledges why it exists: it provides a relatively complete solution. It brings conventions, tooling, a broad ecosystem, familiar ways to source components, and an easier handover path for future maintainers. In contrast, an HTMX-oriented application can leave a team dependent on the original author’s many individual choices.

His core point: Next.js’s complexity is partly the cost of solving a large set of problems coherently rather than leaving them open.

Laravel, Rails, Hotwire, and Livewire — 21:36

Essence: Mature server-side ecosystems already offer productive, integrated alternatives to frontend-heavy architecture.

He has strong respect for Laravel and Ruby on Rails because their communities consistently ship software. The discussion notes that both ecosystems developed their own server-centric interaction approaches: Rails has Hotwire, while Laravel has Livewire. These tools make hypermedia-like approaches less novel in their respective communities because they are embedded in larger, established frameworks.

His core point: hypermedia works best when it is backed by a mature server-side framework, conventions, and a maintainable ecosystem.

Go + templ + HTMX — 23:34

Essence: The stack is conceptually attractive, but its development feedback loop feels far behind modern JavaScript tooling.

Darren considers Go, templ, and HTMX a plausible combination, but finds the developer experience poor compared with JavaScript frameworks. Saving a change requires rebuilding and refreshing, and the delay becomes more noticeable as an application grows. Tools such as air improve the loop, but they do not provide the targeted hot-module replacement commonly available in frontend frameworks.

Server restarts can also reset in-memory state and caches, making the feedback cycle less natural for a long-running Go service. In contrast, rapid visual feedback while editing is a major practical advantage of modern frontend tooling.

His core point: the architecture may be sound, but the edit-save-see-result loop materially affects developer productivity and willingness to use a stack.

Svelte — 26:40

Essence: Svelte is the frontend framework he dislikes least because it is HTML-first and comparatively small in conceptual surface area.

Svelte works well for him because a component can start as ordinary HTML and add JavaScript only where needed. He contrasts this with React, Solid, and JSX-oriented frameworks, where the top-level construct is typically JavaScript and HTML is embedded within it. Svelte’s compiler model and relatively small set of reactive concepts—such as state, effects, and derived values—make it easier to learn.

His remaining problem is not primarily Svelte; it is client-side state synchronization in general. When the authoritative state is server-side or distributed across systems, maintaining a browser cache and keeping it correct introduces race conditions and difficult reconciliation logic.

His core point: Svelte has a better authoring model, but it cannot remove the fundamental complexity of client/server state synchronization.

SolidJS — 27:41

Essence: SolidJS is mentioned chiefly as part of the JavaScript-first family of frameworks.

The comparison is brief: Darren sees Svelte’s lifecycle/reactivity concepts as related to ideas found in Solid, but prefers Svelte’s HTML-first orientation. In his view, Solid remains part of an ecosystem where JavaScript and JSX are the primary abstraction rather than HTML.

His core point: the distinction that matters to him is not only reactivity, but whether UI development begins with HTML or JavaScript.

TanStack Query and SWR — 31:15

Essence: Data-fetching and synchronization libraries address a real problem, but reveal how complex that problem actually is.

He cites local-first and data-sync tools such as TanStack Query and SWR as examples of systems that become deeply complicated when inspected. They deal with caching, invalidation, concurrent requests, stale data, retries, server authority, and race conditions—problems that cannot simply be wished away with a convenient API.

His core point: client-state synchronization is intrinsically complex; a library can package it, but not eliminate it.

DataStar — 31:36

Essence: DataStar’s model is technically elegant, but its philosophy, documentation, and incomplete ecosystem make it difficult to adopt confidently.

Darren does not really “hate” DataStar; he calls it brilliant. The important idea, as he understands it, is a server-held state combined with fast, stateless, idempotent rendering: update server state, render the view, and morph the relevant DOM. This avoids maintaining a browser-side virtual DOM and a complex reactive dependency graph.

He particularly connects with a CQRS-like model: clients submit commands; the server processes them, owns the state, and publishes rendered updates—potentially through server-sent events. That maps naturally to his orchestration background, where systems already cache and reconcile state on servers.

The hard part is deciding where view state belongs, how far to commit to DataStar signals and expressions, how JavaScript modules should integrate, and whether partial DOM updates are traceable enough in a larger application. He also sees missing pieces around components, UI patterns, and broadly adopted conventions.

His core point: DataStar may offer a cleaner architecture, but adopting it requires understanding and committing to a less familiar end-to-end model.

Hypermedia Ecosystem — 53:20

Essence: HTMX and DataStar struggle less because of their core ideas than because they do not sit atop a dominant, integrated server-side platform.

He argues that hypermedia is effectively positioned against much of the JavaScript ecosystem, even if it is not explicitly anti-JavaScript. Most frontend resources, UI kits, patterns, and developers are centered on JavaScript-based rendering. The hypermedia answer—“use whatever backend you like”—is flexible, but can leave teams without a clear default framework, component model, or standard way to structure applications.

He accepts that HTML, CSS, JavaScript, and a server-side language can all coexist. What he misses is a strong server-side framework designed around that arrangement—something as clear and productive for Go as Rails or Laravel is in their ecosystems.

His core point: “hypermedia on whatever you like” is appealing in principle, but a cohesive default stack is often more valuable in practice.

Go — 57:49

Essence: Go is his favorite language for backend work, but its deliberate verbosity and culture make it a poor fit for much frontend authoring.

He values Go’s simplicity, explicitness, predictability, and fast path to productivity. Its low feature count helps developers keep the language in their heads, and its design favors reliable backend systems over expressive or aesthetically concise code. However, frontend work often benefits from compact inline expressions and functional operations—areas where Go’s more verbose style feels awkward.

He also flags channels as difficult despite being a signature Go feature. Goroutines are lightweight and powerful, but channels and concurrency remain fundamentally hard to reason about; familiarity does not make multithreaded programming simple.

His core point: Go makes pragmatic backend trade-offs extremely well, but those same choices conflict with the expressive, UI-focused style common in frontend work.

Rust and Zig — 1:02:58

Essence: Languages encode different priorities rather than approaching a universal ideal.

He characterizes Rust as valuing fine-grained control with a mixture of sophisticated mechanisms, while Zig seeks explicitness and control with less “magic.” Go, meanwhile, prioritizes predictable, practical backend development. The comparison supports his larger argument that language design is a set of trade-offs shaped by a domain and community.

His core point: there is no objectively perfect language—only designs optimized for different constraints.

TypeScript — 1:07:04

Essence: TypeScript demonstrates that developers value type safety when it is largely inferred and supports rapid feedback.

He admires TypeScript’s inference: consumers of well-designed libraries often get useful type information without writing many annotations. In his idealized language, the low conceptual surface area of Go would be combined with TypeScript-like inference, static compilation, and a fast development loop.

He argues that types are valuable for performance, refactoring, editor feedback, and making program assumptions explicit. TypeScript helped developers who historically preferred dynamic scripting accept types and compilation, though it retained an always-running, fast-feedback workflow that traditional compiled-language tooling often lacked.

His core point: the ideal developer experience may be a simple, statically compiled language whose type system mostly stays out of the programmer’s way.

Server/Client Architecture — 1:13:20

Essence: Client-server separation is a simple, useful default, but a system should be able to move “the server” into the browser when no remote server is needed.

He argues that teaching applications as clients and servers creates a clear architecture. However, some applications—especially local-first or desktop-like web applications—do not need a remote server at all. His thought experiment is a language/runtime in which the server-side portion could run in a browser worker, preserving the same architecture while deploying entirely client-side.

This could allow one programming model to support both conventional networked apps and fully local applications, potentially using WebAssembly and caching to load quickly.

His core point: preserve clear client/server boundaries, but make deployment location flexible rather than forcing every app into a remote-server model.

Dart — 1:16:26

Essence: Dart is referenced as an earlier attempt at a web-oriented compiled language, though not one whose style he prefers.

He uses Dart as a conceptual reference: a language that could compile to JavaScript and target web development. His preferred direction would instead focus more explicitly on client-server applications, compile efficiently—possibly toward WebAssembly—and work naturally with the web’s native technologies.

His core point: a web-targeted compiled language is plausible, but it needs a clearer application model and better alignment with HTML and JavaScript.

E4X, JSX, and templ — 1:18:30

Essence: He prefers HTML as the outer language of UI code, with programming logic embedded inside it—not the reverse.

Darren recounts having built a framework around E4X, an old approach that embedded XML inside JavaScript, then later recognizing it as a poor fit. This informs his discomfort with JSX and Go templ-like approaches where a programming language is the top-level syntax and UI markup is nested inside it.

His preference is HTML-first because HTML is already the browser’s native UI description language. It makes the DOM tangible and persistent: rather than continually reconstructing a UI tree, a system can preserve elements and toggle or update them. He also argues this is friendlier to standard CSS behaviors such as animations, which can become harder when frameworks frequently remove and recreate elements.

His core point: for the web, start with HTML and CSS; add code where needed rather than treating the UI as an output of general-purpose program syntax.

[!NOTE] The notes above are a condensed interpretation of the interview transcript, preserving the speaker’s perspective rather than presenting independent framework evaluations.

Prepared using GPT-5.6 Terra Thinking

• #js, #programming, #AlpineJS, #Turbolinks, #Intercooler, #Htmx, #Trimmings, #Petite, #Vue
Marcus Obst
Güterweg 89b
09474 Crottendorf
Germany

+49 37344 133407
info@marcus-obst.de