DEV Community: Alex

Go devs just got Superpowers

Alex — Mon, 29 Sep 2025 20:36:15 +0000

HTMX proved there’s demand for different approaches. It’s simple and clever, but limited. Control logic ends up distributed between HTML attributes and back-end handlers. There’s no reactive state to support complex UI flows, and your application isn’t truly “live” - it still needs client-side code for updates without user interaction.

I took it to another dimension: centralized control in Go, flexible routing system, reactivity, and coordinated updates across the UI. The power of React, but without its confusion, npm baggage, and with some unique features.

To show what this looks like in practice, let’s build a dynamic, reactive dashboard app — written entirely in Go. Along the way, you’ll see how each core piece of the framework fits together: from live HTML updates and event handling to state management, concurrency control, and navigation.

Disclaimer.

Some code is omitted, full version is available here

dev.to does not support templ highlighting, so I'll paste screenshots from vim (by the way).

For demo purposes, I deliberately omitted error handling to reduce LOC; that's not how it should be done!

This is a deep dive that supplies you with enough knowledge to begin building yourself. If you just want the big picture, scroll through, check out the GIFs, and read the sections above them if something looks interesting.

1. The First Page

General Page Template

./page_template.templ

This app has one page with multiple path variants, so a separate template isn’t needed.

Still, it's nice to have concerns separated.

Page Interface

The page must provide head and body content to the template:

Template

Two notes:

We include the framework’s assets; that’s crucial.
Instead of just <link rel="stylesheet" href="...">, we used doors.ImportExternalStyle, which also collects information for. CSP header generation. CSP is disabled by default, but this prepares us for it.

doors.Import... handles local, embedded, and external CSS and JS assets. For JavaScript/TypeScript modules, it eenables build/bundle steps and generates an import map

Router

./main.go

Create a doors router, provide a page handler, and launch the server.

Notice how doors.Router just plugs into the Go standard server! Go is awesome.

We are live!

2. Location Selector

./location_selector.templ

Search Input

Write a search fragment and render it on the page.

Fragment

A fragment is a struct with a Render() templ.Component method

Input Component

Attach an event hook to the input field:

doors.AInput creates a temporary, private endpoint for this element and event.

Options Component

Queries and renders search results.

Each doors.Door renders in parallel on a goroutine pool, so data queries during render generally don’t slow page rendering.

Put it on the page

./page.templ

...and enjoy!

Take a second to realize. We just implemented dynamic search without custom JS or API and within a single control flow.

Debounce and Loader

You don't want to stream every keystroke to the server.

Add one line to the input configuration to enable debounce filtering with the Scopes API:

With debounce, repeated values are more likely. Updating search results with the same data in this rare scenario makes me unhappy. Add a simple check to prevent it:

doors guarantees that the same hook’s invocations run in series, so prevValue has no concurrent access issues.

In practice, responses aren’t instant, so indicate progress to the user.

PicoCSS provides an attribute for this. Use the Indication API to toggle it during pending operations.

Final code:

Debounce and indication together (simulated latency):

The indication clears after all hook-triggered changes apply on the client.

Reactive State

Country and city selection can use Door only, without any reactive state.

However, in multi-step forms and complex UIs, this "low-level" approach spreads logic across handlers and hurts readability and debuggability. A single source of truth in that case significantly reduces mental overhead.

Country Selection

Add a Source Beam and subscribe to it in the render function:

Country selector component (previously inside the main render function):

Show the selected country and a reset button:

Update the beam on option click:

BlockingScope cancels all new events while the previous one is being processed. It reduces unnecessary requests and clarifies intent.
Also, note that we used the same scope set for all search options, which effectively means that events from all handlers pass through a single pipeline, allowing only one active handler.

Let's see how selection works with reactive state:

Oops. Search results weren’t cleared. That makes sense; we didn't clear them.

Fix:

Result:

Location Selector

The country selector is a prototype for an abstract place selector. Comment it out for now.

Plan:

Add Source Beam to the location selector that holds combined country and city data.
Derive separate Beams for country and city values.
Transform our previous country selector into an abstract "place" selector.
Write the location selector render function with the place selectors.

Let's Go!

Create a Source Beam that holds country and city data

Derive the country and city Beams

Source Beam is the original value, which can be updated, mutated, and observed. Beam can only be observed.

Abstract the place selector

Structure:

Methods from our previous country selector with minimal changes (see comments):

Main render:

Show selected:

Select place:

Input:

And options:

Use our place selectors in the location selector render

Dynamic form with reactive state:

Beam is a communication primitive with a value stream. You can watch it directly or use doors.Sub/doors.Inject to render a Door that updates automatically on change.

It has a few important properties:

Triggers subscribers only on value change. By default it uses ==to decide if an update is needed; you can supply a custom equality function.
Synchronized with rendering. During a render pass, all participating nodes observe the same value.
Propagates changes top-to-bottom. In other words, subscribers who are responsible for more significant parts of the DOM will be triggered first.
Stale propagation is canceled. Cancels stale propagation if the value changes mid-propagation (override with NoSkip on Source Beam if needed).
Derived beams update as a group. Subscription handlers run in parallel on a goroutine pool.

All these properties together just make it work as expected - you rarely need to think about it.

Bonus: Improve the UX (with JavaScript)

Missing keyboard support in a form is annoying.

Add keyboard support:

Autofocus on the input.
Tab and enter support on options.

Wiring up some JS

Focus by Id via JS:

Better: make it a reusable component:

Sleek.

And render after the input:

doors.Script is awesome. It converts inline script into a minified (if not configured otherwise), cacheable script with src, protects global scope, and enables await. Additionally, it compiles TypeScript if you provide type="application/typescript" attribute.

Enabling Tab + Enter

Attach a key event hook and add tabindex to options:

Keyboard control enabled:

3. Path and Title

Apply Selected Location

Here’s the page code again:

It always displays the location selector. Remember, we have two path variants: / and /:Id. The second is used when a location is selected.

And now take a look at this fella:

You can probably guess where this goes (path subscription). We’ll also have query parameters, but we don’t want the whole page to rerender on each query change, so derive:

And then subscribe:

Display the selected city or 404:

Now the location selector must change the path dynamically.

Add an apply dependency to the location selector:

Implement submit functionality:

Provide the apply function to the selector:

Instead of passing a path mutation function, we could just render a link. This example shows how to navigate programmatically.

Location selected via path mutation:

Dynamic Title

In doors you can register a JS handler on the front end with $d.on(...) and invoke it from Go with doors.Call(...). Implementing a dynamic title is straightforward.

However, you can just use premade doors.Head component:

Besides title, it also supports <meta> tags.

4. Advanced Scope Usage

In practice, the submit handler won’t respond instantly. What if we interact with the UI during processing?

Let's simulate conflicting actions:

It didn't change the outcome, but caused weird UI behavior.

This issue can be easily mitigated with Concurrent Scope from the Scopes API.

Concurrent Scope can be “occupied” only by events with the same group id.

Add a concurrent scope to the location selector:

Add a parent scope property to the place selector:

Assign group Id 1 to both place selectors:

Use it on the ‘change place’ button:

Finally, apply it to the submit button with a different group Id:

This setup ensures that either the submit or the change-place event can run, not both at the same time:

While changes to city and country won't affect each other, since they share the same group:

Concurrency control is needed because of the framework’s non-blocking event model. This is a major advantage of doors over Phoenix LiveView or Blazor Server, enabling highly interactive UIs without UX compromises.

5. Menu

Query Params

In the weather API, besides the city, we also have two variables: units (metric/imperial) and forecast days.

Add it to our path model:

./page.templ

Notice I used reference types. Otherwise, query parameters get a zero value and always appear in the URI.

Dashboard Fragment

./dashboard.templ

Separate the dashboard fragment

To keep the page simple, let's move the dashboard to a separate fragment.

The dashboard depends on the location ID (provided by the page already) and the days and units query parameters:

We derive those from the path:

Render the dashboard on the page:

Dynamic links

Change City

For the location selector to appear, we need to render a link to /. It would also be nice if query parameters persisted, so we generate the link based on the settings beam:

AHref also supports the Scopes and Indication APIs

Switch to the location selector via dynamic link:

After clicking, the query parameters appear with default values. It’s okay, but not ideal.

Provide nil for the defaults so the behavior is consistent:

Now I’m happy:

Units

Render a link to switch units back and forth:

Add some styles and render the units switcher:

Query param switching:

Forecast Days

The forecast-days links must preserve the units query value. To avoid unnecessary updates, derive a beam for the units:

Subscribe the menu to it:

And maintain the units query value:

Reactive menu:

doors doesn’t keep the whole DOM in memory. With beam derivation, you explicitly tie a specific HTML section to a specific piece of data. Diff data, not DOM.

Bonus: Active link highlighting

The client can automatically apply active-link highlighting if you configure it in doors.AHref:

By default, it checks the whole path and all query values to apply the indication, but you can configure a narrower matching strategy.

Active link is highlighted:

Path as state is powerful. It’s declarative, type-safe, and doesn’t constrain how you map paths to HTML.

6. Charts

Temperature

Let’s prepare a temperature chart and see how it goes.

Instead of doors.Sub, I’ll use the doors.Inject helper. It essentially does the same, but instead of evaluating a function, it renders children with context that contains the beam value.

To serve the generated SVG, I’ll use doors.ARawSrc, which creates a src attribute with a custom request handler:”

doors.ARawSrc (and doors.ASrc, doors.AFileHref, doors.ARawFileHref) use hook mechanics and privately serve resources.

Temperature line chart with dynamic SVG:

Everything

Abstract the chart component so it can be reused for all charts:

All charts:

UX improvements

Image preloader + parameter-switch indication:

Include this indication on all menu links:

Charts with preloaders:

Final Optimization

You may have noticed that weather and humidity don’t depend on the units value.

Apprach as always - derive the beam that does not depend on units:

Additionally, we don’t need that indication triggered, so make it more specific:

Chart component with a days variation:

Final result (slow internet simulation):

Page size:

where ~13 KB is PicoCSS and ~10 KB is the doors client.

Conclusion

Confession. I hate writing UIs, it always gives me the impression I’m doing something wrong. It's like having 10 different tools, none of which are designed for the job, so you have to combine them in an awkward way to get something done. It doesn’t feel like programming anymore.

With doors it feels like programming. Predictable solution path, known outcome, and freedom.

I enjoyed every minute of writing this small app, and I hope you will find time to experience it yourself.

GitHub
Official Website

Special thanks to Adrian Hesketh for his brilliant work on templ, which made this project possible.

You don’t need NPM to ship fully-featured apps.

Alex — Sun, 21 Sep 2025 18:52:16 +0000

In programming, a bad decision is like a node_modules directory — it never stops growing.
Sometimes you have to step back and realize you’ve been solving problems that never needed to exist.

Have you ever doubted choosing React, Next.js, or another “safe” stack for your next project? Most of us have — complexity keeps growing, the developer experience keeps getting worse, but the momentum makes it hard to walk away. And then came the recent NPM fiasco, which showed the “safe” choice might not be literally safe.

You can probably sense that the industry is in need of a next generation of tools, just as React brought us one in the past.

Hybrid approaches (HTMX-like) have gained some traction, but they can’t offer even half of what React enables. Server-driven frameworks are becoming more common, but none have pushed it far enough to overcome the compromises.

So, I built a full-stack framework for dynamic web applications in the Go ecosystem. It has reactive state, components, lifecycle control, SSR by default, and an HTTP API-free architecture — while fixing the flaws that held back existing server-driven UIs.

You can find more details about the architecture and competitors analysis in my previous articles.

This article provides a general overview of the framework's API and some thoughts behind its design, and at the end, I will share a link to the tutorial and GitHub repo.

Fix The Web Dev: Part 4, The Framework.

Fundamentals

Philosophy: Deconstruct the modern front-end framework concept into orthogonal, composable primitives that developers can use independently or combine into purpose-built abstractions.

DOM updates: control > abstraction.

Modern web UI, at its core, is dynamic HTML. How to approach it — first decision I needed to make.

Reactive frameworks abstract DOM manipulation: the component's render function reruns "virtually" when the state changes, allowing the framework to calculate the difference with the previous output and apply it.

Vanilla JS, jQuery, and HTMX-like solutions, on the other hand, work directly: take the element ~~in a hard way~~ by selector and insert new content.

The first one goes against my philosophy (similar behavior should be possible, not enforced). The second one is essentially just string manipulation with no semantics.

Meet Door

A dynamic container in the DOM tree that can be updated, replaced, or removed at runtime in a type-safe way.

Door's methods:

Update - changes its content (like innerHTML)
Replace - replace entirely (like outerHTML)
Clear - removes content
Remove - removes entirely
Reload - re-renders (useful if you query data during render and want new or modified data to appear)

Internally, Doors form a tree structure, where each branch has its own lifecycle. Also, Door provides local context that can be used as an unmount hook.

Door is a straightforward tool for DOM manipulation and a foundation for higher abstractions. However, many things can be done in a simple way just by using it directly.

Reactive State: communication > side effects.

Conceptually, state in modern UI is a combination of two roles:

Argument to the render function, determining the resulting output.
Trigger to initiate re-rendering.

But when you look at the code of a sophisticated React component, this concept breaks down. State is often used as a communication primitive or intermediary data, leading to a chain of useEffect hooks that produce the actual render-driving state.

I don’t think developers are following bad practices; the tool itself naturally pushes real-world code toward that abuse. That is the insight.

Meet Beam

Communication primitive first, render driver by choice.

A changing value stream that can be read, subscribed to, watched, or derived.

Let's combine Beam and Door:

Or use the helper component (if you don't need precise control) to reduce boilerplate:

Can hold any type of value
Triggers subscribers upon value change (== or custom distinction function)
Origin (SourceBeam) can be updated or mutated
Not bound to a specific fragment or container
Respects the dynamic container tree, guaranteeing render consistency, beam shines through doors
In practice, you derive element-scoped state so each DOM node depends only on what it needs (diff data, not DOM)

Routing: freedom > automation.

In the PHP era, the path portion of a URI often was an actual filesystem path to a script, while the query parameters (the key-value map after ‘?’) functioned much like React component props. Item IDs, pagination, and filters - every page variation was expressed through query values.

Today, the path itself has become an abstraction, and means whatever the developer wants… or does it?
Front-end frameworks rely heavily on the path (less flexible than a key–value map) while enforcing some coupling between path structure and the component/file tree. It feels rudimentary and underpowered. And it's a shame, because the ability to encode some state directly in the URI is incredibly powerful.

Meet Path Model.

Route is changing data, and changing data is state.

Each page route is an annotated struct used to match, decode, and encode the URI.

You can:

Declare multiple path variants (the matched field becomes true)
Use type-safe parameter capturing
Use splat parameter to capture the remaining path tail
Use almost any types for query parameters (go-playground/form under the hood)

How to work with it

The path model comes through Beam into the page render function:

Derive a specific piece from the path model:

Render dynamic content based on its value by subscribing to it:

Also, you can generate links and navigate programmatically via SourceBeam value mutation.

This approach requires more code than usual. But its type-safe, deterministic, and declarative nature gives a solid, confident experience and unmatched freedom in route modeling.

Toolkit

Philosophy: It’s better to deal with a comprehensive system than with a set of shortcuts. Adding your own wrapper once is far easier than fighting missing features.

Straightforward and type-safe event binding.

To attach an event listener, render the "magic" attribute in front of the target element:

This creates a protected HTTP endpoint and adds event-binding attributes to the element.

The attribute structure provides fields for event flow control, concurrency rules, pre-actions, error handling, and more.

Flexible indication API.

To communicate processing, use any combination of indicators and selectors with the Indication API:

Temporary indications

Add class
Remove class
Set attribute
Set content

Selectors:

Event target element
Global document query selector
Closest ancestor query selector

Indications are automatically cleared once all triggered state and UI changes are applied.

Nuanced concurrency management.

Occasionally, UIs are hit with overlapping actions — rapid form resubmission, double clicks, and conflicting actions. This issue becomes especially pronounced when event processing happens remotely.

The framework offers basic guarantees at a single hook level. Processing occurs sequentially, and if the hook function returns true, subsequent invocations are ignored. That’s too relaxed for some cases, so precise control can be enabled on the client side via the Scopes API.

Debounce: delays handling of rapid bursts of events.
Blocking: cancels new events while one is processing.
Serial: queues events on the client side and processes them sequentially.
Priority: cancels lower-priority events when a higher-priority event occurs.
Frame: creates a boundary between pending events and new ones

Scope value can be shared between handlers to coordinate behavior across them. Additionally, you can combine multiple scopes to form a pipeline.

Combining Scopes may feel complex, but it enables highly dynamic UI without artifacts.

Straightforward JS integration.

There is nothing wrong with using JS for small UI tasks, and in many cases, a client-side solution is more suitable (e.g. drawing).”

The framework allows you to:

declare custom hooks (request handlers) and trigger them in JS like a private API
register JS handlers and call them from Go.
pass Go data to JavaScript

Custom hook example:

Extras

File hosting (private and public)
CSP header automation
Import map generation
JS/TS bundling and building
Routing options
Dynamic attributes
Active link highlighting
Session and instance lifecycle control
Performance and resource management tweaks

Concerns Addressed

Processing events on the server causes delays and hurts UX.

Response:

With a ping of less than 100ms, the response feels almost instant. With 200ms+, it's pronounced, but acceptable. For better UX, you need servers closer to the customer regardless of stack.

Also, in a "traditional" front-end framework, if an event triggers an HTTP request anyway, there is essentially no difference.

Lack of animations.

Response:

Some transitions can be achieved via the Indication API + CSS.

If there really is a demand for more, let me know, and I will figure it out.

Some APIs are verbose.

Response:

Intentionally. My approach is to give you more control. You can always write a small wrapper and use it everywhere — better than hacking missing functionality.

LSP support?

Response:

There are LSP, highlighting and IDE plugins for templ, and it does its job.

However, not perfect. Also, it's nice to have some framework-specific support. If it succeeds, that is a first priority alongside the LLM-specific docs.

Learning curve?

Response:
No doubt, it's different from the tools you're familiar with.

It took me about two weeks to build my approaches and figure out the best practices. But once I got there... I didn't expect it to turn out so rewarding. It has a solid, almost mechanical feel, while being naked to your eye, because of its elementary nature. And the absence of client-server friction makes it flow; I couldn't imagine myself using the traditional stack again.

Licensing

As mentioned in the previous article, the framework is a paid product (lifetime license, no subscriptions). However, it's free for development and non-commercial production use.

Additionally, it's licensed under BUSL-1.1, so each version becomes open source after 4 years of release.

I want it to be sustainable, supported, and continually improved.

Conclusion

It's called doors.

In the two months since my last article, I’ve improved developer experience, performance, and completed documentation and tests to an appropriate level.

The documentation is still not the best, the tutorial is not comprehensive, and there are probably some bugs left. But I am very satisfied with the framework itself and its internals.

I need your input to push it further. Please try it out, open GitHub issues with any questions, and share your feedback.

Stay tuned.

The Link

GitHub
Docs and tutorial (works on the framework itself)

TCP does not guarantee delivery. The only thing it guarantees for the application layer is that if this byte of data is delivered, it will happen after the previous one. Everything else is the developer's responsibility.

Alex — Fri, 25 Jul 2025 07:00:16 +0000

So I Quit $200k Job To Write A Framework

Alex — Thu, 24 Jul 2025 20:07:44 +0000

This may sound like the worst idea ever. But I think there is no better time than now.

Trying To Fix The Web Dev: Part 3, The Formula.

Despite new frameworks popping every week, devs' burnout keeps escalating; the ecosystem is bursting at the seams, and Vercel monopoly gives billing nightmares.

For my solution to succeed, it just needs to be:

1. Modern like SPA

Composable components, shared and local state, reactivity.

2. Straight like MPA

Natural SSR (not by running front-end code on the server), fast loading, functional href, real FormData, and execution transparency (that was lost).

3. API free

Static endpoints only for serving files and pages. Everything else — wrapped and secured by framework.

4. NPM free

Not required to write/run, but not rejected if integration is needed.

5. Server-Driven

Keep business logic-related stuff on the server and user-related stuff in the browser.

6. Straightforward to self-host

Batteries included, a $20/month VPS + basic CI should be enough to kick-start.

7. And don't compromise UX along the way

Give users a genuine feel of a lightweight SPA.

Spoiler: I made it.

How??

1. Architecture: Stateful Server + Extra Thin Client

Imagine - while constructing the "front-end" form (button, whatever), simply attach a "back-end" form handler function, knowing that only a specific user (anonymous or logged in) on that particular form can trigger it without any additional header verification.

How it works:

User loads page
Server assigns session cookie (just a guid) and initializes page instance
During template rendering, the server collects handler functions (hooks) into the page instance and prepares event-binding attributes
Browser loads the page, attaches listeners, and connects to the server for synchronization
Server routes client requests via session and instance to hooks
Hooks trigger state changes inside page instance and layout updates
Server-Client synchronization does its job

Approach Trade-offs:

Each active page will occupy a piece of the server memory

Server restart may interrupt active users

Load balancing requires specific strategies

If you are curious, "back-end role" in such an approach is not gone, now it is a separate module/lib in your project or private (internal) API you call in a secure server environment.

2. Language. Type-safe, Relevant, and Easy to Learn.

Typescript is JavaScript; there is no way to deny it. It's an awesome language to hack on, but it is a shaky foundation for business logic. Additionally, because of our architecture, we can't afford an interpreted language.

There are three industry-proven candidates: Kotlin (as a JVM representative), C#, and Go.

Golang is one of the simplest languages to learn, offering good performance and a low memory footprint, while being boring.

Kotlin is a feature-rich, modern alternative to Java. It is likely the ideal choice for an enterprise. But its toolkit is too diverse - appreciated with experience, but overwhelming for most of us.

I had no experience with C#, but I suspect that what I said about Kotlin applies here as well.

The boring choice is obvious.

Fast forward — that was a perfect choice. Its concurrency model fits right, standard lib is fantastic, and there is templ, which is just genius.

3. Concurrency Control System

To synchronize parallel HTML updates/rendering, event processing, and state change reactions, and ensure the front-end receives only the latest state. No UX compromise in favor of internal simplicity

I need my version of React Fiber. Probably deserves a separate article.

4. Dynamic Components (and why, probably, React is broken)

Component in the front-end framework is essentially made out of three archetypes:

Role	Description
State And Input	Data that is used to determine rendered content, often a component is "watching" it to initiate a re-render on change
Template	HTML pieces used in component logic to construct the final output
Container	The place in the page layout that is affected or controlled by the component

Component Flow: state/input processing -> template filling & construction -> container update

An update can affect the virtual DOM first, so only the diff will be applied in the "container"; however, the principle remains the same.

Typically, this trinity is tightly coupled and represented as a single entity. I think that is a bad design decision, introducing a new dimension of problems on scale because of a lack of execution transparency by design.

By restricting component control to state manipulations alone, it creates indirect, unpredictable flows even for straightforward UI updates.

I kept those three as separate entities, which you can combine however you like.

Entity	Description
Node (container)	A dynamic HTML placeholder that does not affect visuals (displays its content) and can be updated, replaced, or removed. Internally stored in a tree structure to manage lifecycle and concurrency.
Beam (state)	A state and communication primitive that can be subscribed to or combined with Node. Respects the tree to ensure consistent render. Derivable.
Fragment (component + template)	Entity with Render method. Composable. Can encapsulate multiple Nodes, Beams and have control methods and fields

How it works in practice:

You create a Fragment (component) instance, providing a Beam (shared reactive state) as a dependency (or initialize an internal reactive state if you need one).
The Fragment's render function inserts dynamic Nodes with initial content into the layout and establishes Beam relationships (either by explicitly subscribing or by making parts of the layout automatically re-render on change).
On UI events, hook functions update dynamic Nodes explicitly with new content or trigger reactivity via Beam mutations.
The Fragment can expose an interface to provide abstracted control over its internal dynamic Nodes or Beams.

~~If you're interested in trying it out, please submit your email address here for an early preview. I would appreciate your feedback.~~ Try it out

5. Real-time Synchronization Mechanics

That does not build on top of WS or SSE, while providing similar or better performance characteristics.

Ended up with rolling handover request, simplified logic:

Client sends a regular request to the server
Server streams updates (HTML fragments and remote JS calls) with some metadata
Client opens a new request with a report (batched results and metadata)
Server switches streaming to the new request from the old one
Cycle continues

That approach requires a more advanced synchronization error correction protocol (because it involves two independent data streams compared to WS). Probably deserves a separate article.

So the client is always connected, delays are minimal, and QUIC is utilized.

6. Page Routing

Declarative, reactive, and type-safe.

Concept

Each page is a mini-app; if navigation occurs within the single-page routing pattern, the HTML is dynamically updated.

Page Route

Page paths are deserialized into annotated structs (Path Models), which support multiple path variants, route parameters, queries, and catch-all patterns.
The resulting Path Model is wrapped into Beam for reactive updates throughout the application, enabling type-safe routing with automatic parameter parsing and propagation.

Of course, Path Model can be serialized back to path+query string, and Path Models Beam is synced with the front-end.

Limitations

A full reload occurs when you switch between mini-apps (and thus, their Path Models); this is by design. You can still declare many patterns and derive smaller state pieces from the path structure to achieve a 100% SPA experience, though this approach prioritizes clean boundaries over maximum SPA fluidity.

No parameter or query value validation has been implemented yet.

7. Event Handlers

Pointer, Keyboard, Form, and Input related events are captured by the client library and proxied to the back-end if a handler function (Hook) is provided during rendering.

Other events require manual (but trivial) integration and will be supported out of the box later.

8. And Other Things...

Static Serving

Serve assets, images, etc, publicly or session-scoped.

JS integration tools

To call front-end functions from the server and back-end functions from JS for advanced control and integrations

Resource and session/instance management mechanics

Each active page will have representation in server memory, and UI updates will utilize server CPU, so it's a must-have.

JS/TS tools

If the developer needs to enable rich on-page interactivity or embed a mini React app — esbuild is embedded and integrated.

Front-end indications and concurrency control

To display pending states, debounce input events, block duplicated form submissions, etc.

CSP tools

To automate CSP headers insertion

It will be a paid product, but don't worry!

Affordable lifetime ownership license, no subscription
Source code will be available on GitHub, like any open source
Free for development, buy only to go prod
No telemetry or any form of data collection

Why??

Not backed by a big company or VC funding
Not relying on spare time maintenance
Here to give you the best tool, not serving other interests. It's part of The Formula.
Explain to my wife why it should not be

I believe that technologies should be accessible and free. In fact, everything should be. However, that's not a world we currently live in.

Additionally, I am currently working alone, and this cannot continue forever. I need to hire dedicated professionals (it's also part of The Formula), and the project requires top-tier talent.

Status

After nearly eight months of hard work and four or five complete rewrites, I finally checked all the boxes (and I can't describe how tough that was). It's more of an application runtime than a framework. Currently, I'm working on tests (coverage is now around 70%) and documentation. And I'm honestly enjoying the experience it provides.

Server RAM usage for a simple active page is below 1MB*, and CPU utilization is low. Probably, a $16/month (8GB RAM, 4 vCPU) Hetzner VPS will be enough to host a theoretical average app for over 1000 concurrent users with balanced performance settings. However, more detailed benchmarking is needed — I plan to dedicate an article to this topic in the future.
*UPD. Below 50KB...

My goal is to launch a public beta in August. However, before that, input from both experienced and less experienced developers would be invaluable. ~~If you'd like to participate in early access or be notified when the beta is available, please sign up here~~ Try it out.

Production licenses will be gifted to early access participants as a token of appreciation.

In the following article, "The Framework", we will examine its API with real code snippets.

Thank you very much for reading and your feedback. Stay tuned.

Hypermedia or Server-Driven?

Alex — Tue, 15 Jul 2025 15:26:39 +0000

HTMX Is Worse Than React, and WebSocket Is Obsolete?

Alex ・ Jul 15

#webdev #architecture #frontend #backend

HTMX Is Worse Than React, and WebSocket Is Obsolete?

Alex — Tue, 15 Jul 2025 08:26:46 +0000

Trying To Fix The Web Dev: Part 2, The Solution?

If you missed an introduction to the series, please check it out first.

This is the part where it gets serious.

Disqualified Candidates: New Wave Front-End Frameworks.

Svelte, Preact, etc.

Some of them try to address the complexity (making simple things more straightforward and complex things harder).
Some client-side bloat
Some state management burnout
Some are distilled versions of others

But none of them solves The Issue ™ (even Juris) because they do nothing with the server.

Candidate #1: Hypermedia-Driven

HTMX, Unpoly, fixi.js, etc.

"HTML enhancement" that enables fragment fetching and partial page updates in response to user actions without writing JS code.

How It Works

General Flow:

User triggers an event on the element (e.g., clicks a button or submits a form).
The hypermedia library inspects the element's attributes to determine the request URI, then sends the request via AJAX.
The server returns an HTML fragment
The hypermedia library inspects attributes to determine where and how to apply the HTML patch.

What Is Good:

Logic is on the surface (you don't have to understand component state and run JS code in your head to figure out what will happen after user action)
No need for the client-side input validation logic
Extremely light on the client
SSR without hydration
Feels like a natural evolution of HTML (there is even a standardization initiative)

Why I Will Never Use It:

Control Flow Distribution

Imagine that every time you write a function, you do something like this:

Start as always: "function onForm(data) {"
Create a separate file submit.js and write the function body there
In the original file, you write a meaningless text macro to include the body at runtime and then return the result.

function onForm(data) {
  @submit.js
  return result
}

Does it look like a haven?

That's how I feel about HTMX:
function onForm:

<!--  post to "/submit", then replace the form itself with the response body -->
<form hx-post="/submit" hx-target="this" hx-swap="outerHTML">
    <input type="text" name="name">
    <input type="email" name="email">
    <button type="submit">Submit</button>
</form>

submit.js:

// http handler, that processes form data
app.post("/submit", (req, res) => {
  /* authorization, validation */
  const { name, email } = req.body;
  // respond with HTML (usually using a template engine)
  res.send(`<p>Submitted: <strong>${name}</strong> (${email})</p>`);
});

But isn't it the same as the "old" approach? No, because in native HTML after submission, the new page will be loaded, so control is just passed to the back-end and never returned.
Isn't calling the API a similar thing? No, because in 90% cases, the API is just a DB wrapper; it has nothing to do with the control flow.

Shallow Simplicity

Arguably, the hypermedia stack is the fastest way to launch. However, the limitations of the architecture complicate the implementation of an already complex UI.

It's like you have only one way to build user flow - you store stateless functions that always output a single HTML fragment in a huge map, and then for each interactive element, specify the map key and arguments as constants. Does it make simple things more straightforward? Yes. Does it make tricky UIs even messier? Also, yes.

What if you need a multi-step form or non-linear user flow? Store intermediate values in HTML, cookies, or external memory. Is it more transparent than using a variable?

Update several places on the page in response to user action? Make a total control flow mess.

UI state and state management libraries are here for a reason, and complex web apps are a modern-day requirement, keeping web relevant in the mobile apps era. There is a particular hate towards state in the community, but it's probably because it allows us to create more elaborate things.

Text-driven

It's not wrong. However, I don't feel comfortable describing an algorithm via HTML attributes.

Endpoint Security

Although the "API issue" from the previous article is addressed - "DB wrapper" is gone (there can't be more "Backend For Frontend" than HTMX server), you still need to care a lot about proper endpoint authorization logic (with state-in-request, there are even more things to keep in mind).

Verdict:

Front-end hypermedia tools scale the "classic" approach, without improving it, even if there are (or will be) more "sugar" containing libs that partially address my points.
Don't get me wrong, it's great technology that has its niche. However, it's essential to consider its limitations when selecting a stack for a long-term project.

So, does it address The Issue? Partially. Is it The Solution? Hell no.

Candidate #2: Server-Driven

Hotwire Turbo Streams, Phoenix Live View, Laravel Livewire, Blazor Server

Main UI logic is written for the server and runs on the server; the client acts as a "remote" renderer and user input provider.

General Flow:

User triggers an event on the element (e.g., clicks a button or submits a form).
Client lib intercepts the event and sends it to the server
Server prepares HTML updates and how to apply them, wires that to the client
The client follows the server's instructions

Compared to the previous candidate, the server owns control flow completely. The browser has no idea what will happen in response to the event. You can think of it like a backwards API - the server calls the client to modify HTML on the fly.

What Is Good:

Business logic has returned to the server 🔥
Light on the client
SSR without hydration
State-full* server superpowers, like page instance & element scoped endpoints/handlers (no developer-defined and exposed API at all)

* Not all of them are stateful

So this is it? The Issue is solved: extra-thin client, no API, business logic executed in a controlled and safe environment.

Compromises:

Blocking Event Processing

Guilty: Phoenix Live View and Blazor

Page by design lives in a single thread or process (Phoenix). In other words, when interacting with multiple page elements, processing, database interaction, and rendering occur in series, with the next event being processed after the previous cycle is complete.

That makes internal framework logic much simpler (no concurrency issues), but it looks like a blocker for mass adoption. You don't want your UI to be unresponsive or accumulate an event queue when a time-consuming task is running. You can mitigate this by leveraging background processes and asynchronous tasks; however, the complexity cost seems too high to justify the effort (task management & UI synchronization).

Hotwire lacks concurrency control at all. Livewire, by default, blocks the component during a request on the client side, which is most of the time good enough.

50/50 State Situation

You can argue that modern web UI can operate without state. But it's here already, relied on everywhere, and keeps being reinvented.

Hotwire
No built-in state management.

Laravel Livewire
Serializes component state to hidden inputs under the hood, which seems cool.

Laravel server is stateless and does not "live" in memory. It "reacts" only to requests - restores component state from request data and session storage, then uses it to render an HTML update; However, it has built-in mechanics to trigger the update of multiple components (within one request lifecycle).

Blazor Server
Full support: component state, global state, derive functionality, reactivity. But C#, so who cares (

Phoenix Live View
Global state per LiveView (root app component) instance: propagated to components as props and triggers rendering, similar to storing state in the root component in React and passing down the tree as props.
Components state, which operates in a similar way to React.

Grandpa WebSocket

UI updates rely on it in: Phoenix Live View, Blazor Server, Hotwire Turbo Streams (truly server-driven part of Hotwire, because Turbo Frames are just like HTMX)

Let's address the clickbait elephant in the room.

Not compatible with QUIC (HTTP3).

95% browsers now support QUIC. It offers higher resistance to network conditions, lower latency, and faster connection establishment. If your app users live in a datacenter, that makes no difference. Otherwise, for a server-driven UI, lack of QUIC hurts.

WS via QUIC may be enabled in the future. However, even WS via HTTP/2 (after 10 years) adoption remains rare. Also, with wider streaming request body (hello safari) and BYOB support or WebTransport, we won't need WS that much.

Sloppy Reconnect

Connection loss detection is guaranteed only by pings or heartbeats. For example, 10 seconds between pings, with at least two skips required to initiate reconnect, resulting up to 20 seconds of unusual UI behavior.

Timeout-based disconnect detection is unavoidable in real-time scenarios, regardless of whether you are using WS or not. But it adds up to weaker network condition resistance of TCP compared to QUIC, longer handshake, and separate connection circuit (meaning other network app activity failing does not help WS disconnect detection)

App Users Notice

I am talking from experience. WebSocket-controlled UI comes with the deal: there will be cases, despite the internet already being reachable, where the app is not responding for a noticeable time. Maybe it will happen not so often, and perhaps it's not ruining UX, but it's a design flaw.

SSE situation is also not great. The browser is extremely sloppy at reconnecting. I have no idea why. Especially after PC wake-ups from sleep, and again, you will rely on heartbeat (and manual event source recreation).

Non-Native Forms

Guilty: Phoenix Live View and Blazor

By default, it is serialized and passed via WebSocket. Not a deal breaker, but requires care when dealing with files.

Endpoint Security

Laravel Livewire, Hotwire

Server is stateless and does not maintain in‑memory UI component instances with unique "hooks" between requests. Endpoints are static, so you must enforce authentication and authorization on every handler, just as you would with HTMX.

Stateful Cost

Phoenix Live View and Blazor

Load balancing is not so trivial, because a page "lives" on a specific server instance
Each active page consumes memory on the server
Non-cachable HTML
UI will lose state after a period of inactivity (server memory is not infinite) or due to server restart

Seems like a reasonable compromise for me. With more users, you probably can afford more computing resources.

Verdict:

Phoenix Live View is fascinating as a concept (app lives on the server, browser as remote actor), but quirks like "single-threaded" blocking UI and HTTP/1.1 reliance make it hard to recommend. Not to mention that elixir is not everyone's cup of coffee.

From a theoretical perspective, Laravel Livewire represents an evolution (real one this time) of the classic web — stateful Components and "live" page updates, all while the server remains stateless. However, it's not factually "live". There is no app runtime; you can't initiate UI Updates from the server because there's no reactivity, endpoints are static and require care.

Blazor (the server-side variant) is conceptually similar to Phoenix LiveView, but it has a distinct Microsoft flavor. Users' reports confirm it is sluggish and has high resource consumption.

Hotwire looks like it is either advanced HTMX or inferior Livewire.

So, does it address The Issue? Yes. Is it The Solution? Unfortunately, no, too huge of a compromise.

There is no end to our suffering?

I think there is, and now I know The Formula. So, I quit my job as CTO and dived in.

Subscribe for the Part 3: The Formula.

Future proof you career

Alex — Tue, 08 Jul 2025 17:22:53 +0000

Young Devs: 3 Career Hacks in the Age of AI

Alex ・ Jul 8

#programming #career #ai

Young Devs: 3 Career Hacks in the Age of AI

Alex — Tue, 08 Jul 2025 11:20:59 +0000

It's 2025; you are young, ambitious, and preparing for a career in programming.

However, seems like everybody in the industry is discussing how AI will replace programmers.

Maybe it's right about them, but not about you.

I will not recommend or sell you an AI tool or tell you some bullshit, like "be better than others and follow your passion."
I will share a [not easy] strategy you can follow to improve your chances, along with some practical insights - what you can start learning right now.

Disclaimer: I was the head of the R&D department and interviewed over a hundred people. My area of operation was primarily related to software and firmware that run on specialized devices, such as IoT modules, cameras, industrial controllers, specialized tablets, etc. However, we also occasionally did related web development projects.

1. Avoid following common recommendations

You: Where should I start?
They: Python. JavaScript/React. Mobile apps. Testing. It's easy to learn.

Wrong.

Easy to learn doesn't mean right for you.

You are young, your brain is agile. You can handle learning more complicated things. Don't waste the opportunity to gain unique skills.

LLMs are trained on common stuff

JavaScript and Python are the default languages for LLMs due to their extensive training datasets. So React, Node.js, Django, you name it — risky choice.

Don't get me wrong, LLMs can't write code well (and won't be soon), require professional guidance and supervision

Overcrowded.

Training courses are easy to sell. Recommended by almost everybody. Bubble.

2. Look for the natural LLM barriers

Connected To the Physical World

Mistake cost is too high (and can even be fatal); therefore, humans will continue to play a significant role in the R&D process for a long time. And also, you need hands.

Machinery and industrial control

Medicine

Automotive

Low-Maintenance And No-Maintenance Systems

Software or firmware upgrades in the field are often costly or impossible. No one lets the device with LLM-generated code exit the factory.

Environmental data loggers

Fixed-function devices (like an air-conditioner)

Remote Asset Trackers

Mission Critical Systems

The reason is the same as in the previous points.

Telecommunication, networks

Power Grid Management

Transportation

Financial Transaction Systems

But am I good enough for that?

You may think that no one will allow you to touch it. However, it's not true - experienced colleagues will review your code in detail, provide guidance, and education. Trials will take months if not years. And in comparison to guiding the LLM, this will pay off. You are a valuable asset.

In college, one of my fellow students worked on a nuclear power plant control sub-system.

Low-Latency and High Performance

Requires precision, collective effort, and is highly context-dependent (an average approach will not cut it). The quality and complexity are significantly higher than the median, which renders the LLM invalid for such cases (until real revolution in approach/architecture and probably hardware).

Data Processing Cores

Financial market

Transaction Systems

Data compression, encoding, decoding

3. Search For Niches

Here is my top 3. I recommend starting with the first one; it's a solid foundation for the next two and a programming career in general.

Microcontroller (MCU) Programming

The average age of developers in this area is approximately 40, and there is almost no new talent
Unreachable for LLMs and will always remain relevant. Nearly any electrical device more intelligent than a kettle without a colorful display is powered by an MCU.

Writing low-level code to run on low-power hardware is a challenging task. However, it is also fun. Use your fantasy to select the first learning project - build a canon with ultrasonic target detection (my first project), a crawling robot, an active balancing camera mount. It's a dream.

Start with a dev board and bare metal (HAL, learn UART, SPI, I2C), then conquer FreeRTOS and dive into electrical engineering a little—you're safe.

You can try to argue that hardware will get so powerful that we can just run AI/AI-generated JavaScript everywhere. That is not true; there will always be a demand for highly energy-efficient and robust systems.

Warning: Arduino is not recommended to start learning embedded development. It's not recognized by the industry as a professional tool (for DIY, kids, it's ok). STM Discovery boards are the default choice (it's much easier to work with than you may think).

Embedded Linux

Gold specialists. I knew three who know how to modify the Linux kernel, write device drivers, and configure & automate the Yocto/Buildroot building process.

If a MCU is not the brain of the device and it's not 4/5G cellular enabled, it's likely running on Linux. Advanced industrial controllers, cameras, drones, smart home hubs, portable game consoles, medical equipment, and much more.

Android System (not apps)

! Training materials are difficult to find

Even rarer specialists. I knew two, but I couldn't manage to hire a single one in-house (it was impossible to compete with x2-x3 offers from corporations).

If the company plans an Android-based product (even if it's developed and produced in China), there's no way around this competence.

Build an Android from the sources. Add drivers, configure peripherals. Embed the application with system privileges, tweak power cycle and battery management, guide OTA implementation, and write platform native code (not Java/Kotlin).

Android rocks when all-around connectivity is required, advanced media and camera capabilities, and touch-heavy UIs are needed. It's not only about smartphones. POS terminals, interactive panels, digital signage, 4G-connected cameras, vending machines, smart speakers, and various other gadgets.

Conduct Your Research

I am talking from the perspective of my industry alone. For example, low-level, high-performance server code (C/C++/Zig/Rust) - follows the same logic: LLM safe, challenging to master, and not so popular (as it could seem). Also, there is "hardware programming" .

Bonus: don't run for the money

Today's trends are not tomorrow's reality. Making your choice based only on salary ranking may sound reasonable, but

It's not your ranking, but those who came before you.
You can easily end up in an overpopulated niche that was once on the hype.

However, Go and Kotlin are solid choices for today. Industry-proven, well-paid, job opportunities are growing, and extensive training materials are available. If you jump in right now, you probably won't miss.

Cautions Of Suggested Approach

Not So Common

You should search first to see if there are companies that can offer such jobs within your reach.

It won't be many. Not all cities (even countries) can offer that. However, demand for specialists exceeds supply and continues to grow. Relocation is also common.

Fewer Remote Opportunities

If you work with something physical, you need to visit the office often. You need help from your hardware fellas to debug.

Requires Education?

It's recommended to have a related university degree. But training materials are available online (that's how I mainly learned). At least half of the people I was working with had an education in other fields (but mostly engineering).

My perspective is limited to my industry. Still, you can extrapolate suggested principles (and even find new ones following the same logic) to other areas.

Conclusion

I can think of nothing more interesting than programming. I hope you also share my passion one day, while earning a good income as a bonus.

Good Luck!

JavaScript Is Not The Issue

Alex — Sun, 06 Jul 2025 08:52:46 +0000

Trying To Fix The Web Dev: Part 1, The Issue.

Some of us remember the "old" days when web development was simple.

PHP, two types of forms, and some jQuery for the magic to happen (AJAX hit like using ChatGPT the first time).

And it was pretty reliable too, despite everybody managing servers themselves (I still do btw, using vim).

React.js Happened.

Angular happened first, but I skipped that.

So, React felt like a new era was coming – now you could write and embed highly interactive mini-apps.

Of course, that was possible before, but React enforced component architecture with props propagation and manageable component state – back then, I (20 y.o., 70% PHP monkey, 30% jQuery enjoyer) could not even think about something like this, and it gave me superpowers.

BTW, I think micro apps with little to no back-end interaction are the perfect use case for front-end frameworks. Perhaps because that was what they were actually designed for, or maybe because I don't fully understand the world.

Nowadays.

Oh boy. I am CTO and co-owner of an international hardware development + production company (DH + EMS).

How I got there – different story. But what’s important: I’ve built many things with my teams.

From an Electron-based manufacturing control & automation system, to light show drone firmware with a custom UDP swarm control protocol (I wrote the core myself in Rust – I [spoiler] was a bad manager), to actual hardware.

I even had my own JDSL, which powered [spoiler] server-driven production operator terminals — so you could deploy new workstations just by describing the execution process in JSON. It was so bad and somehow surprisingly awesome.

BUT every freaking time I had to deal with the web during this career period, it caused me pain.

The Issue.

I don't want to yell about JS and its ecosystem. Everybody’s already doing that.

I think there is something much fundamental:

Business logic has migrated to the browser.

Take a look:

Ok, for real:

It would be ignorant to claim the old approach fits the modern web. Sites built like that often feel outdated, lack features and the UX sucks.

Why is Business Logic In the Browser an Issue?

You probably already felt that something was wrong. Here are my anti-highlights:

#1 Huge Deal: Front-end dictates API access.

The data you need to read or write conditionally depends on business logic, and so it is reflected in the UI flow.

That means you have to reflect the UI flow in API access schemas, which operate in a completely different dimension.

Such a unified control schema cannot exist.

That’s arguable. And I can object to myself here, often, just role-based is good enough. Ok, role-based with some extra configurable properties. Ok, role-based with some properties and runtime conditions. Ok, with a bunch of architectural nightmare code – 100% doable.

For straightforward logic applications, that’s not a big deal.

However, if you’re entering the B2B space with control panels, a bit of business process automation (not to mention ERP), it's going to be rough.

Or follow the vibe™ and don’t care. Rely on Elusive Joe security strategy and expose your whole db.

Boring: 84% reported experiencing at least one API‑related security incident in the past year

#2 Opinion: Thick Client.

This largely depends on your industry and the complexity of your app's functionality.

Building the complex logic of your service on top of a million lines of JS dependencies to be executed in the browser doesn't feel right.

JavaScript is the best language in the world. Or how else do you explain that something made for SCRIPTING now powers the web?

But seriously. It's genius, just the application seems narrower.

I think that too much freedom in approaching deeper-than-surface-level tasks is not good (why I love Rust). JS/TS provides hallucination-level abstraction tooling.

#3 Reality: Teams synchronization and higher button cost.

That depends on the size of your team or company. I worked in small to medium-sized companies, where adding basic functionality is usually a low-cost operation.

However, I’m hearing stories from my corporate friends all the time about how their work and releases are blocked by multi-level endpoint approval processes (reason #1) and teams syncing (everybody has their priorities).

Anyway, with the growth, an increase in feature cost is unavoidable.

But that makes the fact that you need to do the same thing in two different projections (app and API) even more frustrating.

It’s Just Skill Issues.

Maybe. And I am an impostor.
So don’t subscribe and miss Part 2: The Solution (it's going to be technical)

[Boost]

Alex — Fri, 04 Jul 2025 17:00:19 +0000

DEV Community: Alex

Go devs just got Superpowers

1. The First Page

General Page Template

Page Interface

Template

Page

Page Path

Page

Page Handler

Router

2. Location Selector

Search Input

Fragment

Input Component

Options Component

Put it on the page

...and enjoy!

Debounce and Loader

Reactive State

Country Selection

Location Selector

Create a Source Beam that holds country and city data

Derive the country and city Beams

Abstract the place selector

Use our place selectors in the location selector render

Bonus: Improve the UX (with JavaScript)

Wiring up some JS

Enabling Tab + Enter

3. Path and Title

Apply Selected Location

Dynamic Title

4. Advanced Scope Usage

5. Menu

Query Params

Dashboard Fragment

Separate the dashboard fragment

Dynamic links

Change City

Units

Forecast Days

Bonus: Active link highlighting

6. Charts

Temperature

Everything

UX improvements

Final Optimization

Conclusion

You don’t need NPM to ship fully-featured apps.

Fix The Web Dev: Part 4, The Framework.

Fundamentals

DOM updates: control > abstraction.

Meet Door

Reactive State: communication > side effects.

Meet Beam

Routing: freedom > automation.

Meet Path Model.

How to work with it

Toolkit

Straightforward and type-safe event binding.

Flexible indication API.

Temporary indications

Selectors:

Nuanced concurrency management.

Straightforward JS integration.

Extras

Concerns Addressed

Processing events on the server causes delays and hurts UX.

Lack of animations.

Some APIs are verbose.

LSP support?

Learning curve?

Licensing

Conclusion

The Link

TCP does not guarantee delivery. The only thing it guarantees for the application layer is that if this byte of data is delivered, it will happen after the previous one. Everything else is the developer's responsibility.

So I Quit $200k Job To Write A Framework

Trying To Fix The Web Dev: Part 3, The Formula.

1. Modern like SPA

2. Straight like MPA