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/...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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 🤔