EffinDOM: https://effindom.dev/
Rust UI Framework - FUI-RS: https://github.com/zion-sati/fui-rs
FUI-RS Live Demo: https://fui-rs-demo.effindom.dev/
Ever since WebAssembly (WASM) was just a JavaScrpt file, I've already dreamt of the death of HTML, CSS and JavaScript itself.
Death. Gone from the face of the earth.
Okay, that's a bit much - but the dream was it should never have been the de facto stack of Web Apps.
HTML, CSS and JavaScript won. There are millions of developers, libraries for everything, answers on forums and AI trained against existing them.
But ask around and you'll quickly find all good developers hate them. These are three historical accidents that turned into a badly mashed up application model. The world is now tightly coupled with these accidents, making replacing them extremely difficult.
You'll find bad UX every time HTML quietly gives up. A workflow graph is a good example; so is a tmeline, waveform editor, diagram surface, node editor, etc. Let alone a combination of them on the same page. The page itself remains HTML. The difficult bits that HTML can't do becomes canvas, SVG, WebGL or a stupid pile of absolutely position divs...
Sure, we see the pixels appear and at first glance it looks great. Until someone tries to use it.
Does the mouse wheel scroll the page, pan the surface, or zoom it? Does trackpad pinch mean browser page zoom or graph zoom? What happens when a drag leaves the surface? Which layer owns the pointer capture? What about keyboard? Does keyboard focus enter it and tab across its inner elements? Can a screen reader understand them? Does its hover state look the same as the one next to it?
The custom control provider decides and every provider invents a different answer. Sure, you might be thinking that they'd have all sorts of knobs for you to fine tune all of these. But that simply leads to a combinatorial explosion, and prohibits unified design systems.
The custom control surface has become a second UI system embedded inside the first one.
This is why beautiful and sophisticated HTML5 controls often feel so wrong. The control simply has no knowledge of the application - mouse handling, wheel momentum, pinch-to-zoom, pull-to-refresh, touch arbitration, focus, selection, keyboard shortcuts, context menus, accessibility, gestures, etc etc etc are rebuilt inside an island. That is if they go as far as that to begin with.
Even if they do. You could argue, sure, it works. But so does a lot of tech debt.
The hack inside a hack
HTML is excellent at documents (do we need to be reminded what DOM stands for? No, not the latex kinda DOM... the document kind). It was also pretty good for building conventional forms (also a document). Somewhere along the way, we turned it into a general application platform because it was already everywhere, not because a document tree, a cascade and a scripting language somehow formed a brilliant UI architecture.
When the document model runs out of vocabulary, the supposedly "clean" way is to insert a custom rendering surface and rebuild what's missing in JavaScript. However, that creates two owners for the same interaction:
- The browser owns page scrolling, page zoom, focus traversal, text input, text rendering, accessibility and platform conventions.
- The embedded surface owns its own hit testing, gesture state, inner scrolling, inner page zoom, inner focus traversal, inner text input, inner text rendering, inner... you get where this is going... But the point is, everything "inner" is often just an approximation of the browser's look and feel.
The boundary is where applications become uncanny. GitHub Actions workflow diagram is a good example - it's so bad no matter how long you spent using it, it still feels uncanny. Wheen input is captured when the user meant to scroll. Pinch changes the wrong scale, drag gets stuck because the release happened elsewhere. Keyboard commands work until focus crosses into the island. The graph is themed, but separately so - chances are they'd be sutbly different.
None of this is impossible to fix. Pointer events, touch actions, ARIA, DOM overlays and a crazy amount of JavaScript can reproduce almost anything.
BUT. Once a custom widget has implemented all of that fully polished, it has built a small UI framework. The next control builds another one, often by another provider. Good luck convincing them what the middle wheel button's meant to do...
A canvas is not a UI framework
So I hear you say - what if the entire page is one enormous canvas? It doesn't solve anything - a canvas gives us pixels. It doesn't give us retained control identity, layout, focus, text editing, IME, selection, clipboard behavior, password-manager integration, browser find, semantics, accessibility, touch conventions, or platform-aware shortcuts.
This is where most canvas UI arguments go off the rails. A canvas is a framebuffer, not an application platform.
EffinDOM exists to provide the missing application model. Canvas is simply one presentation surface used by the browser host.
The runtime owns one retained tree for layout, controls, rendering, input, text, selection, scrolling and semantics - yes that's like exactly what the browser currently does. Except the bet is browsers will no longer have to do this in the future.
We then project the parts that the host platform must own. In the browser, that includes a semantic DOM, mirrored editor state, IME integration and browser-facing behavior. On native desktop, it includes the OS accessbility and input adapters.
Your retained application
│
┌─────────┴─────────┐
▼ ▼
FUI-RS FUI-AS
Rust application AssemblyScript web
SDK SDK
└─────────┬─────────┘
▼
EffinDOM
layout | text | input | semantics
╱ ╲
▼ ▼
Browser/WASM Native desktop
canvas + host Metal | D3D12 | Vulkan
The normal application path would share most of the UI code. Genuine platform-specific capabilities would remain available behind clean boundaries.
Native:
Web:
Why start with the browser?
Most custom-rendered UI frameworks start natively and add a WASM target later.
That makes complete sense. Native is easier.
You own the window. You own the event loop. You own rendering, input, clipboard, accessibility adapters and file access. There isn't a browser sitting around your application with thirty years of behaviors users expect you to preserve.
I started with the browser precisely because it is harder.
Drawing some buttons onto a canvas is easy. Drawing them while pretending text selection, IME, password managers, browser navigation, pull-to-refresh, trackpad gestures, accessibility, keyboard focus and find-on-page don't exist is even easier.
But that's not a web application. That's a screenshot that responds to mouse clicks.
For EffinDOM to be credible on the web, it had to participate in browser behavior:
- Keyboard, mouse and touch text selection.
- IME composition and CJK input.
- Clipboard operations and platform-specific shortcuts.
- Password-manager and form integration.
- ARIA and semantic inspection.
- Browser and retained find-on-page.
- Routing and independently loaded WASM pages.
- Async fonts and fallback.
- Page zoom, trackpad pinch and nested scrolling.
And yes, a lot of these are the boring things nobody puts in the first demo.
They are also the difference between a demo and a UI framework.
Once those worked, taking the same retained model to macOS, Windows and Linux was still a lot of engineering work.
Metal, D3D12 and Vulkan did not wire themselves up while I slept.
But architecturally, the direction was much cleaner.
The runtime already knew what a button meant. It already knew what text selection meant. It already knew about focus, scrolling, semantics, editing and accessibility. The native hosts only had to connect that meaning to another platform (I used SDL here which gave me a leg up on unifying the 3 major platforms).
EffinDOM isn't a native UI framework that happens to compile to canvas. It was born in the browser.
The hybrid route is still a hybrid
Cross-platform UI reminds me of the car industry.
Electron and WebView applications are conventional hybrids. They put a native body around a browser drivetrain.
It works. It is incredibly practical. It also means every application drags a browser around just so we can pretend a website became a desktop application. That's your average Slack, GitKraken, VSCode etc. * cough give me back my RAM * Those things are more expensive than gold bars by weight these days!
There is now a cleverer middle ground: remove the WebView and render an HTML-oriented application model natively.
That's a pretty substantial engineering achievement. But it's still a hybrid - the equivalent of a plug-in hybrid.
The browser engine may be gone, but the application still begins with concepts designed for the web, and written for devs who are now close to their fifties (I'm one of them).
EffinDOM and FUI are the EV bet.
I'm not trying to work out how to render HTML somewhere else. I'm asking what should replace it.
Of course, HTML has had three decades to install petrol stations on every corner. Component libraries, browser tooling, integrations, hosting, documentation, experienced developers etc.
FUI has a working drivetrain. Its charging network is young. The built-in controls, browser and desktop hosts, packaging, documentation, Agent Skills and access to the Rust ecosystem cover quite a lot. The third-party control ecosystem does not have thirty years behind it.
Early adopters may occasionally have to plan the route themselves.
That's the bet though. Useful applications create demand for more controls and tooling. Better tooling makes the next application cheaper. Eventually, if enough people use it, the ecosystem develops gravity of its own.
The control that nearly broke the dream
You might assume the hardest control was a graph, custom drawn surface or the interactive dancing yarn demo.
Nope.
It was the boring multiline text box everybody assumes the operating system simply gives you: TextArea. But remember, we are bypassing the browser altogether here.
Text editing exposes every shortcut a UI framework is tempted to take.
Monospaced fonts can use specialized paths. Fixed line heights can be optimized differently to variable line heights (yes unicode chars have different heights encoded by their fonts). Non-wrapping text is different from wrapping text. Static text is different from editable text. Large documents should process only visible lines, otherwise the app crawls to a standstill. Incremental edits should not reshape the entire document.
Then all of those optimizations combine.
Every combination must still preserve Unicode boundaries, caret geometry, forward and reverse selection, scrolling, hit testing, tabs, newlines, clipboard operations, undo, accessibility and font fallback.
On the web, EffinDOM renders the visible editor while keeping a mirrored DOM editor for IME and browser integration.
Text inputs also need the correct semantics for password-manager extensions.
Why retained FUI?
I didn't want another framework that repeatedly rebuilds a description of the UI so it can compare that description with the UI it already had (ok fine, I hate react).
FUI uses retained controls.
Construct the control once. Keep its identity. Change the property that changed.
Focus, selection, editor state, scroll position, subscriptions and overlays remain attached to the actual control the application created.
FUI-RS exposes that model to Rust. FUI-AS exposes the same controls and fluent conventions to AssemblyScript.
The syntax belongs to each language. The application model underneath does not change.
The shared EffinDOM runtime is written in C++ deliberately. Rendering, layout, text shaping, input and semantics are infrastructure for FUI-RS, FUI-AS and future language SDKs such as FUI-KT (Kotlin) and FUI-CS (C#).
A narrow ABI (Application Binary Interface) lets the runtime work with Skia, Yoga, HarfBuzz, ICU, SDL and native platform APIs without reimplementing the engine for every language.
FUI-RS is the idiomatic Rust application surface over a language-neutral runtime.
Is any of this real yet?
Yes.
EffinDOM currently runs in browsers through WASM (WebAssembly) and natively on:
- macOS ARM64 and x64 using Metal.
- Windows ARM64 and x64 using D3D12.
- Linux ARM64 and x64 using Vulkan.
No Electron, no system WebView for native apps.
FUI-RS covers browser and native desktop. FUI-AS currently targets the browser (with plans for native desktop in the future).
A universal routed FUI-RS application can compile each browser route into an independently loaded WASM MFE (micro-frontend) while composing the same retained page crates into one native application.
cargo-fui creates, builds and packages the application. It produces DMG, MSIX and AppImage packages. Native-only Rust developers do not need Node.js or npm.
The current uncached browser transfer (cold load) is roughly 7.6 MB compressed:
- EffinDOM core: about 1.9 MB.
- UI runtime: about 810 KB.
- ICU data: about 2.4 MB.
- Six built-in fonts: about 2 MB total.
- FUI-RS home route: about 321 KB.
- FUI-AS home route: about 122 KB.
Most of that is shared infrastructure rather than application code. Within the same top-level site, routes and FUI language SDKs reuse the content-addressed runtime and fixed assets.
A warm load of the FUI-RS demo home page transfers under 500Kb.
What doesn't exist yet?
This is feature-rich early access, not 1.0.
The APIs can still break if my work porting it to Android and iOS deemed it necessary. The third-party control ecosystem is young.
There is one independent community application so far: Galaga-RS, a space shooter with a live browser build.
The point
The web keeps proving applications need more than documents.
Our answer has been to place increasingly sophisticated private UI frameworks inside HTML and try to patch the differences one control at a time. In the world of AI we live in currently, that's a pretty good way to burn tokens.
I refuse to believe another layer of JavaScript is the best the human civilisation can do.
EffinDOM is my attempt to replace the application UI model without throwing away the browser and OS integration users expect.
FUI-RS is the flagship, FUI-AS is the AssemblyScript SDK, and FUI-KT and FUI-CS are early smoke-level language surfaces.
The project is far enough along to build real applications, but early enough that somebody using it can still influence where it goes.
Try to build something that isn't already in the showcase.
Then tell me where it breaks.
Top comments (32)
Absolutely ridiculous premise, which ignores (or is unaware of) the $2 - 3B of advertising and e-commerce revenue generated on the web all day every day, the democratization of publishing since the late 1990s, the collection of, curation of, and 24/7 global access to human knowledge, instant communication and collaboration, etc.
It may not be great at drawing SVG birds, but all the mission-critical stuff seems to be hobbling along just fine. No canvas needed.
Have you suffered a recent blow to the head?
Good developers do not hate HTML, CSS and JavaScript; they understand them and use them for the purposes they were intended. Many are using them directly, not as part of a framework, and many are employing custom Web Components, as part of the HTML standard.
There is a reason those standards won and have persisted for 30+ years.
#EffYourDOM
🤣 I hope I can stop laughing cause your other comment I wearing me out 🤣
Vercel sheep exhibit 1
I'm not going to engage with this idiocy. Just pointing it out for what it is.
Unable to refute even one of my assertions, you tried to go after me personally -- the weakest, "I give up" move there is in a debate.
I had to look up "Vercel" BTW. A swing and a miss. I've designed and led the implementation of large systems that have been pulling in tens of billions (that's with a "B") of dollars every year for the last twenty years. I would never even consider using a tool like that. More recently, I've been working on fast, lightweight, native web applications that use nothing but HTML, JavaScript, and CSS -- no bloat, no frameworks, no libraries. You have no idea who I am or what I do, which makes assertions like yours look ridiculous.
May I suggest a tactic for the future to keep from revealing that you know almost nothing about the subject you've chosen to write about? Avoid the "clever" clickbait/ragebait titles, and employ a technique called inquiry vs advocacy.
Instead of taking up and trying to defend a fixed and easily assailable position (advocacy), as you did with this ridiculous article, ask questions (inquiry) -- something like "why have the technologies I despise (HTML, JavaScript, and CSS) been so popular and successful over the last 30 years?", "could I be missing something?", "is my proprietary technology really better for every use case, or is it more of a niche solution?" -- things like that. And add just a dash of humility.
Doug, my "Vercel sheep" reply was deliberately rude and deliberately not a technical rebuttal. You opened by calling the premise ridiculous, trivializing the examples as "drawing SVG birds" and asking whether I had suffered a blow to the head, ending the post with Eff Your DOM. I concluded that you were a troll and had either not read the article or were responding to a different thesis, so I matched the level of the comment and declined to treat it as serious technical engagement. Since you are now presenting that choice as an inability to answer, here is the answer.
Your central argument is that HTML, CSS and JavaScript have supported enormous revenue, publishing, commerce, communication and access to knowledge. I agree. The article explicitly says that they won, that the ecosystem is enormous, and that HTML is excellent for documents and conventional forms. Their historical and commercial success is not the disputed proposition.
The proposition is that a document tree, CSS cascade and scripting language are a poor mandatory application model for sophisticated interfaces such as timelines, waveform editors, node graphs, diagramming surfaces and IDE-like workspaces. Those are the places where ordinary HTML controls repeatedly give way to canvas, SVG, WebGL or private JavaScript UI systems, creating a second interaction model inside the browser’s first one.
Your statement that good developers use HTML, CSS and JavaScript "for the purposes they were intended" actually concedes the distinction. Documents, publishing and conventional forms are precisely the cases in which I say HTML works well. The question is whether those same primitives form a coherent general-purpose architecture for the complex application surfaces named in the article.
"No canvas needed" is an assertion, not a rebuttal. Show a serious timeline, waveform editor, node graph or IDE whose difficult interaction surface remains ordinary HTML controls and coherently handles nested scrolling, zoom, pointer capture, focus, keyboard navigation, selection, text editing, IME, semantics and accessibility. Advertising revenue and publishing do not answer that question, and I'm not sure why you thought it did to begin with repeatedly.
Web Components do not answer it either. Custom elements and Shadow DOM provide useful encapsulation, but they remain DOM subtrees manipulated through DOM APIs and styled with CSS. Encapsulating the existing model is not replacing it.
Nor does “no frameworks, no libraries” change the underlying comparison. A framework-free web application still sits on top of the browser’s enormous retained runtime: HTML parsing, DOM, CSSOM, layout, paint, compositing, event routing, focus, editing and accessibility. You are programming that runtime directly. Removing React or another library does not establish that the runtime’s application model is architecturally ideal.
EffinDOM’s premise is to externalize that retained UI responsibility into a portable runtime. It owns retained controls, layout, text, input, focus, selection, rendering and semantics, then projects the host-facing pieces required by the browser or native operating system. FUI-RS is one typed authoring surface over that runtime. The same retained application model can run through WebAssembly in a browser or through native desktop hosts without Electron or a WebView.
The authoring syntax is not the premise. Architecturally, HTML and CSS could be accepted by another frontend and lowered into the EffinDOM retained tree. Browsers themselves already parse HTML and CSS into internal object and rendering structures. Making HTML/CSS one optional input language would be fundamentally different from making the browser DOM/CSSOM the mandatory application runtime.
Your "proprietary technology better for every use case" question is therefore a strawman twice over. The article explicitly preserves HTML's value for documents and forms, and the project is not simply a closed proprietary system: the EffinDOM runtime is MIT-licensed, while FUI-RS is AGPL or commercially licensed.
As for the tens of billions of dollars and your career history: assume every claim is completely true. It establishes that you have worked on commercially important systems. It does not establish that every technology involved in those systems represents the best possible architecture. COBOL can make precisely the same revenue-and-longevity argument.
A relevant rebuttal would do one of two things: provide a convincing complex application counterexample that does not collapse into a private UI framework inside the DOM, or identify a concrete architectural failure in EffinDOM’s retained model and browser/native host projections. You did neither.
Finally, the article does not merely advocate. It provides an implementation, a demo, acknowledges current boundaries and invites people to build something and report where it breaks. That is inquiry backed by engineering. Advising me to ask whether I might have missed something would be more persuasive had your own response first engaged with what the article actually says.
So no, my initial one-line dismissal was not a refutation. It was a decision not to debate a personal attack that was not on the same technical topic. You have now insisted that this indicated an inability to respond. It did not.
"HTML, JavaScript, CSS should have died long ago" was ridiculous. Pick a lane, and stay in it.
What would you say is the percentage of applications that actually need or that would benefit from "sophisticated interfaces such as timelines, waveform editors, node graphs, diagramming surfaces"? 1%?
Good to know you're on top of it, especially since there are no other "canvas" solutions available ... except for the standards-based HTML element, WebGL, etc, etc, etc.
Doug, I think we’ve actually narrowed the disagreement down considerably.
We started at "this premise is idiocy."
Now we’re at:
That’s progress.
But I think the 1% claim is now the part that needs examining, because I’m not sure it means anything without first defining the denominator.
What counts as "one application"?
Does a restaurant reservation form count as one application and Figma count as one application?
Does a small CRUD dashboard count as one, while Google Docs counts as one?
If so, then counting applications tells us almost nothing.
One application might contain 12 form controls and be perfectly served by HTML.
Another might employ hundreds of engineers building editors, rendering engines, collaboration systems, layout machinery, accessibility layers, video pipelines, virtualization and interaction systems used for billions of user-hours.
Calling both "one app" and then counting them equally is not a particularly useful engineering metric.
And there’s an even bigger problem:
What if the apparent scarcity is partly a symptom of the platform limitation itself?
If building this class of application requires enormous engineering investment, you cannot observe that relatively few companies have done it and conclude that nobody needs better primitives.
That’s like standing beside a river and saying:
while everyone currently crossing it has to build their own boat.
And that is more or less what the industry has been doing.
Figma built a boat.
Atlassian built a boat.
Canva built a boat.
Google built several boats.
GitHub/Microsoft have built boats.
Adobe built boats.
And they keep independently rediscovering remarkably similar problems.
Figma famously described building its professional design tool as effectively building "a browser inside a browser" ... its own rendering engine, retained representation, compositor, text machinery and so on.
That isn’t an edge case accidentally proving me wrong.
That is the problem I’m describing.
Atlassian ran into the same boundary with Confluence Whiteboards. Ordinary HTML/CSS wasn’t sufficient for the interaction surface, so the team built a custom WebGL rendering pipeline together with its own hit testing and interaction machinery.
I actually worked at Atlassian, so this category of problem isn’t theoretical to me. I’ve worked around products and engineers dealing with precisely this boundary.
Google is another particularly interesting example.
In 2021 Google announced that Google Docs was moving its underlying renderer from HTML-based rendering to canvas-based rendering, specifically citing performance and consistency across platforms.
Think about that for a moment.
Google Docs.
A document editor.
If anything should be the natural home territory of HTML, surely it’s a document editor.
And yet once the application became sufficiently sophisticated, Google itself moved the document surface away from HTML rendering.
Why?
Because at that scale, the browser’s document representation is no longer necessarily the representation you want for the application.
Google Sheets pushes the problem even further. Google continues investing in specialized execution and performance machinery just to make very large spreadsheets responsive; for example, Google has described using WasmGC to substantially improve calculation performance in Sheets.
Then look at GitHub.
GitHub tried virtualizing its code viewer because rendering huge files conventionally was too expensive.
But once it stopped keeping the whole thing naturally represented in the DOM, browser functionality started breaking.
Ctrl+Fno longer behaved correctly.Text selection became problematic.
Accessibility became problematic.
So GitHub ended up with a fascinating hybrid: an invisible
<textarea>containing the complete file for browser semantics and accessibility, with a separate virtualized syntax-highlighted visual layer on top.Two representations kept in sync to get both application performance and browser behaviour.
Again:
That is the architectural seam I’m talking about.
GitHub’s engineers aren't incompetent.
Google’s engineers aren't incompetent.
Figma’s engineers aren't incompetent.
Atlassian’s engineers aren't incompetent.
They didn’t somehow fail to discover
<div>.They reached a class of application where the straightforward document model no longer gave them everything they needed, so they constructed additional application machinery around, beside or underneath it.
And Canvas/WebGL do not refute this.
They’re literally part of my argument.
They give you pixels.
Great.
Now where do retained controls come from?
Hit testing?
Focus?
Selection?
Text editing?
IME?
Keyboard navigation?
Gesture arbitration?
Accessibility?
Semantic structure?
Cross-platform rendering?
Native desktop portability?
You build those.
Which is why every sufficiently ambitious company eventually seems to create some private variation of an application runtime.
So even if I generously accept your completely hypothetical 1% figure, my question becomes:
Why does this 1% repeatedly have to rebuild the same missing class of machinery?
And how large would that "1%" become if building these applications did not require Figma-, Google-, Canva- or Atlassian-scale engineering investment?
That’s the causality problem with your argument.
Maybe only 1% genuinely need it.
That's possible.
But you cannot establish that by observing the number of applications successfully built after imposing the cost of building your own UI infrastructure on everyone who enters the category.
And I think there’s another subtle problem with the 1% framing.
The boundary doesn’t occur at the application level.
A huge application can be 90% conventional HTML and 10% sophisticated application surface.
GitHub is an obvious example.
Most GitHub pages are perfectly comfortable as documents.
Then you reach code viewers, editors, graphs and highly interactive surfaces and suddenly different engineering constraints appear.
Atlassian products contain endless forms, pages and ordinary controls that HTML handles beautifully.
Then you open a Whiteboard.
Different problem.
Google Workspace has ordinary HTML surrounding the application.
Then you reach the actual document/spreadsheet editing surface.
Different problem.
So asking:
may be the wrong question altogether.
The better question is:
That’s what EffinDOM is trying to address.
Not replacing HTML for blogs.
Not replacing HTML for forms.
Not replacing
<button>because buttons offend me.It’s asking why, when applications cross this boundary, every company has to start constructing the same missing layer independently.
And yes, I can already anticipate the next objection:
Sure.
The title is deliberately provocative.
The first paragraph of the article says exactly that and immediately narrows the thesis.
I explicitly say HTML is excellent for documents.
So if we’ve moved from:
to:
then I think we’ve made enormous progress.
Now we’re finally discussing something interesting.
And the question I’d leave you with is this:
Is this really only 1% because only 1% of software needs it, or is it 1% because, for thirty years, anyone trying to build that class of software has first had to reinvent half a UI platform?
The premise was and still is idiocy. I don't waste time proceeding deeper into what is likely to be more idiocy, when the initial idiocy is still sitting there.
For example, I didn't say that only 1% of applications are affected. I asked what you thought the percentage might be.
We're not communicating. You're just typing. You said a dumb thing right off the bat, and I called you on it. What you said was indefensible, and it colors anything else you might have to say.
Maybe you don't remember what you said - we aren't communicating indeed. Your responses were dumb, and I called you out on them too. That's perfectly fair, don't you agree?
There... you floated 1% as the possible number. My response explicitly treated it hypothetically, which is why I said "even granting your 1%".
But you've now made the more important point clear: you don't intend to engage with the technical argument because you read the TITLE and decided the premise is "idiocy". I hope you are using your real name and the internet keeps record of you for the longest time.
You're quoting me back the question I asked you while still trying to assert that I said it was 1%. More idiocy. It's idiocy all the way down as far as I can tell.
And all you can reply is "idiocy idiocy idiocy". Clearly you haven't even read any of my responses, let alone the article. Doug Wilson, an internet troll.
I read until I hit idiocy, which doesn't take long, as I've repeatedly pointed out. You ignore and avoid answering my direct questions. What's my motivation to read further?
I'm ending this waste of my time. Good luck changing the world with your completely unnecessary and proprietary "solution" to a problem that scarcely exists.
Baaaahhh ! 😆
Exactly. And how about portability?
Just another smart-ass pants who wants to reinvent a perfectly, declarative, functioning wheel upon which billions of dobloons depend, not to mention hundred of thousands of developers and web designers.
Portability is the point you missed most spectacularly. The same retained FUI UI runs in the browser and as real native applications on macOS, Windows and Linux via Metal, D3D12 and Vulkan... without Electron or a WebView. HTML is "portable" because every target either is a browser or has one bolted onto it. That’s browser portability, not application portability. And billions of dollars plus a large workforce prove entrenchment, not architectural fitness. COBOL can make the same argument. 😂
From my point of view, I think The webstack is underutilized.
If someone cannot build or reason about the primitive system underneath, giving them an even more sophisticated framework doesn't create engineering ability.
Before replacing the stack or adding another abstraction layer, how much of what the browser already gives us are we actually exploiting?
Also I think this is also why many senior developers push back against AI slop: the more abstraction hides the primitives, the easier it becomes to generate code without actually understanding what it does.
Quote me right 👍
One distinction I probably didn't make clearly in my earlier reply: I'm not arguing that people should understand fewer primitives by putting another framework over HTML.
EffinDOM is an attempt to move the primitive boundary itself. Layout, retained identity, hit testing, focus, text shaping, selection, scrolling and semantics live in the runtime. FUI-RS is just one language-facing API over those primitives.
So I agree completely with the concern about abstractions that hide everything underneath. In fact that's partly why I'm doing this. If we're going to build application UI frameworks inside canvas/SVG/DOM anyway, I'd rather have one explicit underlying UI engine whose primitives developers can understand than twenty unrelated libraries each reconstructing part of a browser inside another browser.
Spot on! This exact realization is why I am building the underlying engine for this stack.
The mainstream industry underutilizes the browser because they treat it as a dumb document-viewer. In fact, Vercel's entire multi-billion-dollar business model thrives because they keep the client side dumb.
Modern web development has accumulated substantial server-side and client-side machinery around a document-oriented application model. EffinDOM asks how much of the application itself could instead execute locally against a purpose-built retained UI runtime.
I am actually building NetWasm next, which is a C# to WebAssembly compiler using WASI only. By compiling straight to pure, standard WASI, the application code doesn't care where it runs. It can execute securely inside a browser kernel, natively on a desktop, or on a bare-metal edge device without dragging a bloated framework runtime with it. The browser is essentially an OS!
FUI-RS (and FUI-AS) runs on EffinDOM which is the Display Server of the OS. My ultimate dream is to turn Web Browsers into an OS - it should not know anything about HTML/CSS/JS!
You can say that again my friend.
At random, these fantastic latest typography CSS gizmos .
Same.. I think this post is the result of us going down the wrong path at some point. There is a better way... htmx.org/ data-star.dev/ et al.
I actually like the philosophy behind htmx/Datastar much more than the modern React-style stack, but they solve a different problem. They simplify document-oriented web applications by leaning harder into HTML and hypermedia. That’s great for CRUD, forms, navigation and server-driven applications.
But neither gives HTML a retained application-UI model for a waveform editor, timeline, node graph, IDE surface, etc. htmx literally swaps server-returned HTML into the DOM, and Datastar morphs HTML elements in the DOM. So they're excellent answers to "how should we build HTML applications?" My question is "what should the application model be once HTML stops being the right primitive?"
Several replies defend HTML with publishing, e-commerce, forms and htmx. I agree HTML is excellent at documents but that's not the premise.
Show me one serious IDE, waveform editor, timeline or node graph whose hard parts remain ordinary DOM controls instead of becoming a private canvas/SVG/JavaScript UI framework. What is the strongest counterexample?
I feel like a reasonably good developer, and I do not hate HTML/CSS/JS.
Anyways, I came hoping to find some example code or ideas. Hard to find in the sample application code repository.
The demo source has a lot of sample code: github.com/zion-sati/fui-rs-demo/b...
The premise is about an architectural argument that the DOM is fundamentally insufficient (and hacks lead to tech debts) for complex apps like timeline, waveform etc especially when they have to coexist on the same page coherently).
The problem of WASM is lack of DOM access, having to pass everything through JS, which is still stuck in UTF-16. Not so nice is also blob size (to be downloaded on every minor change.)
The problem of browser apps is that they create UIs the Windows way, where many interactions feel alien under Linux. Leave it alone, FFS! Just letting the browser handle widgets is infinitely more ergonomic! VS code has partly adapted to Linux, but it drives me nuts when I search for something, and then want to paste what I selected before – gone! They override my selection, just because I’m searching.
Though even browsers get one thing wrong: the URL field marks on click. Even after years I still want to click into the URL and immediately start typing right there. Boom – everything overwritten! If they think people are too dumb to want to edit a URL, at least give normal behaviour as a power user option!
Btw. typos: tmeline & Wheen
I think what you're describing is a conventional DOM-oriented WASM app, not FUI-RS.
DOM access isn't missing here. We deliberately don't use the DOM as the application UI tree, but we project a semantic/editor DOM where the browser needs it for accessibility, inspection, IME, text input and password managers.
JavaScript is only the browser host boundary. The retained controls, layout, hit testing, text shaping, rendering and selection live in EffinDOM. The internal ABI is UTF-8; UTF-16 only enters at browser API boundaries.
The blob-size point is different too. The runtime, ICU data and fonts are content-addressed shared assets. A small app change can download a new app WASM file, but it doesn't refetch the unchanged runtime or built-in assets. See the network tab in your browser devtools when you go to a new tab in the demo.
And even “just let the browser handle widgets” doesn't guarantee native-feeling behavior. In fact as I'm typing this reply in dev.to's custom rich-text editor right now, keyboard word selection stops at the line boundary in a way that doesn't feel native at all. This one is purely HTML/DOM. In fact, browsers don't use native OS controls - they render their own just like EffinDOM/FUI-RS, only fragmented across the 3 major browsers.
I agree that Linux-specific interaction conventions matter. FUI-RS has platform-specific native adapters, but I don't claim every Linux convention is finished or equally validated yet. With community feedback, I will continue to polish it.
For documents and simple forms, HTML is still great. The interesting case is application UI: editors, graphs, diagrams, timelines and custom drawing. Those already become mini UI frameworks inside HTML pages. FUI-RS is trying to give them one retained model that also runs natively without Electron or a WebView.
Good one.
Say, the URLs you've provided?
Oh yeah, they rely on HTML, CSS and Javascript.
Doh!
Congratulations! You found the bootloader. Browsers currently need HTML and JavaScript to load Wasm and expose browser APIs; that no more makes FUI an HTML application than launching a native binary from Bash makes it a shell script. FUI’s controls, layout, hit testing, text shaping, rendering and state live in the retained runtime. The DOM is a browser integration boundary. Confusing the host with the application is precisely the category error the article explains. Doh indeed.
The title of the post was what captured my attention 🤔
Some comments may only be visible to logged-in visitors. Sign in to view all comments.