JavaScript Views, the Hard Way – A Pattern for Writing UI
127 comments
·April 19, 2025athrowaway3z
chrismorgan
A couple of issues that will arise from this:
• Using DOM attribute or text nodes limits you to text only. This is, in practice, a very big limitation. The simple cases are Plain Old Data which can be converted losslessly at just an efficiency cost, like HTMLProgressElement.prototype.value, which converts to number. Somewhat more complex are things like classList and relList, each a live DOMTokenList mapping to a single attribute, which needs unique and persistent identity, so you have to cache an object. And it definitely gets more intractable from there as you add more of your own code.
• Some pieces of state that you may care about aren’t stored in DOM nodes. The most obvious example is HTMLInputElement.prototype.value, which does not reflect the value attribute. But there are many other things like scroll position, element focus and the indeterminate flag on checkboxes.
• Some browser extensions will mess with your DOM, and there’s nothing you can do about it. For example, what you thought was a text node may get an entire element injected into it, for ads or dictionary lookup or whatever. It’s hard to write robust code under such conditions, but if you’re relying on your DOM as your source of truth, you will be disappointed occasionally. In similar fashion, prevailing advice now is not to assume you own all the children of the <body> element, but to render everything into a div inside that body, because too many extensions have done terrible things that they should never have done in the first place.
It’s a nice theory, but I don’t tend to find it scaling very well, applied as purely as possible.
Now if you’re willing to relax it to adding your own properties to the DOM element (as distinct from attributes), and only reflecting to attributes or text when feasible, you can often get a lot further. But you may also find frustration when your stuff goes awry, e.g. when something moves a node in the wrong way and all your properties disappear because it cloned the node for some reason.
kikimora
This approach is simple but does not scale. People did this long time ago, perhaps starting with SmallTalk in 80’s and VB/Delphi in 90’s.
You need separation between components and data. For example you got a list of 1000 objects, each having 50 fields. You display 100 of them in a list at a time. Then you have a form to view the record and another to update it. You may also have some limited inline editing inside the list itself. Without model it will be hard to coordinate all pieces together and avoid code duplication.
epolanski
That screams pub sub which is trivial with JavaScript proxy imho.
homarp
can you elaborate on the 'don't scale part'? because apps in 90's don't see 'smaller' than webapps now
austin-cheney
So, state is simple, stupid simple.
The way to keep it simple is to have a single state object, which is the one place where state is organized and accessed.
The way to make it scale is architecture. Architecture is a fancy word that means a repeatable pattern of instances where each instance of a thing represents a predefined structure. Those predefined structures can then optionally scale independently of the parent structure with an internal architecture, but the utility of the structure’s definitions matter more.
Boom, that’s it. Simple. I have written an OS GUI like this for the browser, in TypeScript, that scaled easily until all system memory is consumed.
alternatex
I feel like you completely misinterpreted their comment. They replied to a comment saying that state should not be centralized. They said that if the state decentralized (as in held by individual child components) it's difficult to coordinate between sibling and parent/child components.
It seems like you're saying that it's easy to do UI with a centralized state, therefore agreeing with them whilst having the tone of disagreement.
SkiFire13
> use the DOM element value/textContent/checked/etc as the only source of truth
How do you manage redundant state? For example a list with a "select all" button, then the state "all selected"/"some selected"/"none selected" would be duplicated between the "select all" button and the list of elements to select.
This is the fundamental (hard) problem that state management needs to solve, and your proposal (along with the one in the OP) just pretends the issue doesn't exist and everything is easy.
athrowaway3z
I don't think I understand your question, or its just a poor example.
Regardless of design pattern or framework; the state all/some/none of a list, should practically never exists as separately updated state variable. Whenever its required you need to derive it.
noneSelected = !querySelectorAll("input:checked")jdsleppy
They could always fall back to storing a value in a hidden element in the worst case. All/some/none selected is often done with an indeterminate state checkbox https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... that can represent all three states.
Maybe I don't understand the problem you are talking about.
robocat
As soon as you need to store some state elsewhere you can store it in another suitable form (there's often some state not visually represented). I seem to recall jQuery stored state on a POJO (plain old JavaScript object) within a JavaScript variable of an element.
johnisgood
Did you know you can have "stateful" UI without any JavaScript, using pure CSS and HTML? JS-less (Tor) websites use them.
I have implemented a fully functional, multi-state CAPTCHA using only HTML + CSS for state simulation, and PHP for real validation.
SvenL
A List of items could just contain checkboxes holding the state of selected/not selected. Then it’s a trivial query selector. To get every selected item or to know if every item is selected.
liveafterlove
That is just select with multi. And one can also have class vs id.
motorest
> (...) I think 'state' variables are an anti-pattern. I use webcomponents (...)
It's unclear what you mean by "state variables". The alternative to state variables you're proposing with webcomponents are essentially component-specific state variables, but you're restricting their application to only cover component state instead of application state, and needlessly restricts implementations by making webcomponents mandatory.
> (...) but now with WebComponents there is separation of (...)
The separation was always there for those who wanted the separation. WebComponents in this regard change nothing. At most, WebComponents add first-class support for a basic technique that's supported my mainstream JavaScript frameworks.
_heimdall
"State variables" is a section in the original article. It shows a variable in the view, "name", that holds the value separate from the DOM.
setName(value) first checks the local state variable, and if different the value is both written to the state variable and the DOM.
The GP's pattern uses getters and setters to directly read and write to the DOM, skipping the need for a local variable entirely.
mcintyre1994
I think this makes a lot of sense when you’re just wanting to update a single DOM node. And if you wanted to eg update its color as well, scoped CSS with a selector based on checked state is probably as nice as anything else. But how does this look if you want to pass that value down to child elements?
Eg if you had child form fields that should be enabled/disabled based on this, and maybe they’re dynamically added so you can’t hardcode it in this parent form field. Can you pass that get function down the tree the same way you would pass react state as a prop?
MatthewPhillips
Hey, I'm the author of this doc. The reason for the pattern is to make it so you always can find why a mutation occured. So combining state variables and dom changes is ok as long as that's the only place that does the mutation. If not, now you've made it harder to debug. I keep the strict separation so that I can always stick a debugger and see a stack trace of what happened.
fendy3002
this is what I did in jquery era and it works very well, since it seldom to have state management at that era. Sure there's data binding libs like backbonejs and knockoutjs for a more complex app, but this approach works well anyway.
Having a manual state that do not automatically sync to elements will only introduce an unnecessary complexity later on. Which is why libraries like react and vue works well, they automatically handle the sync of state to elements.
Galanwe
I don't think that is heresy, essentially you are describing what MUI calls unmanaged components - if I understand you well.
These have their places, but I don't see them as an either-or replacement for managed components with associated states.
epolanski
I have been writing recently an application in plain "vanilla" TypeScript with vite, no rendering libraries, just old-style DOM manipulation and I have to say I more and more question front end "best" practices.
I can't conclude it scales, whatever it means, but I can conclude that there are huge benefits performance-wise, it's fun, teaches you a lot, debugging is simple, understanding the architecture is trivial, you don't need a PhD into "insert this rendering/memoization/etc" technique.
Templating is the thing I miss most, I'm writing a small vite plugin to handle it.
prisenco
I take it a step further and go no-build js with jsdoc.
The hardest part about scaling this approach is finding UX designers who understand the web. Just as frontend devs have trained themselves to "think in react" over the past decade, so have designers. The understanding of the underlying capabilities and philosophies of the web have been lost to the idea that the web and mobile can be effectively the same thing.
This approach can go far if the team using it knows and respect web technology.
designerarvid
IMO designers should read hypermedia systems by the htmx guy.
klysm
If you look at it as a tradeoff space it makes more sense why the majority of folks are on some kind of react. What kind of problems do you want to experience and have to solve in a production setting?
klysm
The problems with this approach are exacerbated in a team setting. The architecture might be trivial from your perspective but good luck getting a bunch of other folks on board with different mental models and levels of experience.
only-one1701
I get what you’re saying but people still write SPAs
nonethewiser
Can you elaborate on website functionality, team size, and production readiness?
I mean I totally agree on small personal projects. Thats just never the limiting factor though.
iamsaitam
"I can also ditch a database and just dump everything into a text file." <- This is what you're saying. It isn't hard to see the problem with this kind of thing.
AmalgatedAmoeba
ngl, a lot of the times, an in-memory “database” that gets backed up to a file is perfectly reasonable. Even consumer devices have dozens of gigabytes of RAM. What percentile of applications needs more?
Just because a technology works well for a few cases shouldn’t mean it’s the default. What’s the 80% solution is much more interesting IMO.
skydhash
> an in-memory “database” that gets backed up to a file is perfectly reasonable.
We have org-mode, application configs, and music playlists as three widely used examples for this.
You switch to a database when you need to query and update specific subsets of the data, and there's the whole concurrency things when you have multiple applications.
null
zffr
The read me says this approach is extremely maintainable, but I’m not sure I agree.
The design pattern is based on convention only. This means that a developer is free to stray from the convention whenever they want. In a complex app that many developers work on concurrently, it is very likely that at least one of them will stray from the convention at some point.
In comparison, a class based UI framework like UIKit on iOS forces all developers to stick to using a standard set of APIs to customize views. IMO this makes code way more predictable and this also makes it much more maintainable.
netghost
Convention works when the culture is there, but I think you're right a dash of typescript and a class or interface definition could go a long ways.
I think the maintainability comes from easy debugging. Stack traces are sensible and the code is straightforward. Look at a React stack trace and nothing in the trace will tell you much about _your_ code.
I'd also point out that this looks like it's about seven years old. We've shifted a lot of norms in that time.
_heimdall
Any code base lives or dies by how well it defines and then sticks to conventions. We can enforce it in different ways, or outsource the defining of convention to other tools and libraries, but we still have to use them consistently in the codebase.
I think the OP here is basically proposing that the developer should be directly responsible for the conventions used. IMO that's not a bad thing, yes it means developers need to be responsible for a clean codebase but it also means they will better understand why the conventions exist and how the app actually works. Both of those are easily lost when you follow convention only because a tool or library said that's how its done.
nonethewiser
Using a framework like react constrains developers in a different way. React isnt simply a convention like the linked example.
_heimdall
I see it differently there, react (any framework) is simply convention built into shared libraries and enforced through tooling.
React is a particularly interesting one because it is still flexible enough that there is still a lot of reliance on developers actively sticking to the conventions recommended.
dsego
This reminds me of the venerable backbone js library. https://backbonejs.org/#View
There is also a github repo that has examples of MVC patterns adapted to the web platform. https://github.com/madhadron/mvc_for_the_web
lylejantzi3rd
I came up with something similar recently, except it doesn't use template elements. It just uses functions and template literals. The function returns a string, which gets dumped into an existing element's innerHTML. Or, a new div element is created to dump it into. Re-rendering is pretty quick that way.
A significant issue I have with writing code this way is that the functions nest and it becomes very difficult to make them compose in a sane way.
function printPosts(posts) {
let content = ""
posts.forEach((post, i) => {
content += printPost(post)
})
window.posts.innerHTML = content
}
function printPost(post) {
return `
<div class="post" data-guid="${post.guid}">
<div>
<img class="avatar" src="https://imghost.com${post.avatar.thumb}"/>
</div>
<div class="content">
<div class="text-content">${post.parsed_text}</div>
${post?.image_urls?.length > 0 ? printImage(`https://imghost.com${post.image_urls[0].original}`) : ''}
${post?.url_preview ? `<hr/><div class="preview">${printPreview(post.url_preview)}</div>` : ''}
${post?.quote_data ? `<hr/><div class="quote">${printQuote(post.quote_data)}</div>` : ''}
${post?.filtered ? `<div>filtered by: <b>${post.filtered}</b></div>` : ''}
</div>
</div>
`
}chrismorgan
This is begging for injection attacks. In this case, for example, if parsed_text and filtered can contain < or &, or if post.guid or post.avatar.thumb can contain ", you’re in trouble.
Generating serialised HTML is a mug’s game when limited to JavaScript. Show me a mature code base where you have to remember to escape things, and I’ll show you a code base with multiple injection attacks.
foota
Yeah, OPs code is asking for pain. I suspect there are now developers who've never had to generate html outside the confines of a framework and so are completely unaware of the kinds of attacks you need to protect yourself against.
You can do it from scratch, but you essentially need to track provenance of strings (either needs to be escaped and isn't html, e.g., user input, or html, which is either generated and with escaping already done or static code). It seems like you could build this reasonably simply by using tagged template literals and having e.g., two different Types of strings that are used to track provenance.
brigandish
Thus recreating Perl’s taint mode. Everything new is old.
lylejantzi3rd
Posts are sanitized on the server side. This is client side code.
chrismorgan
Although appealing, that’s an extremely bad idea, when you’re limited to JavaScript. In a language with a better type system, it can be only a very bad idea.
The problem is that different contexts have different escaping rules. It’s not possible to give a one-size-fits-all answer from the server side. It has to be done in a context-aware way.
Field A is plain text. Someone enters the value “Alpha & Beta”. Now, what does your server do? If it sanitises by stripping HTML characters, you’ve just blocked valid input; not good. If it doesn’t sanitise but instead unconditionally escapes HTML, somewhere, sooner or later, you’re going to end up with an “Alpha & Beta” shown to the user, when the value gets used in a place that isn’t taking serialised HTML. It always happens sooner or later. (If it doesn’t sanitise or escape, and the client doesn’t escape but just drops it directly into the serialised HTML, that’s an injection vulnerability.)
Field B is HTML. Someone enters the value “<img src=/ onerror=alert('pwnd')>”. Now, what does your server do? If it sanitises by applying a tag/attribute whitelist so that you end up with perhaps “<img src="/">”, fine.
hombre_fatal
Server-side sanitization means that your view code is inherently vulnerable to injection. You'll notice in modern systems you don't sanitize data in the database and you don't have to manually sanitize when rendering frontend code. It's like that for a reason.
Server-side sanitization and xss injection should be left in the 2000s php era.
MrJohz
How do you update the html when something changes? For me, that's the most interesting question for these sorts of micro-frameworks - templating HTML or DOM nodes is super easy, but managing state and updates is hard.
dleeftink
I find the coroutine/generator approach described in a series of posts by Lorenzo Fox/Laurent Renard to be a promising alternative[0].
It takes a little to wrap your head around, but essentially structures component rendering to follow the natural lifecycle of a generator function that takes as input the state of a previous yield, and can be automatically cleaned up by calling `finally` (you can observe to co-routine state update part in this notebook[1]).
This approach amounts to a really terse co-routine microframework [2].
[0]: https://lorenzofox.dev/posts/component-as-infinite-loop/#:~:...
lylejantzi3rd
I call printPosts with the new post data. It rewrites the whole chunk in one go, which is pretty snappy. I haven't decided how I'm going to handle more granular updates yet, like comment count or likes.
MrJohz
Yeah, that's a pretty common approach. Unfortunately, browsers aren't very good at doing patch updates, so it'll completely reset any UI elements in the region being rerendered.
It also will make it hard to scope anything you want to do to an individual DOM element. If you want granular updates, for example, you want to be able to do something like `document.querySelector(???)` and be certain it's going to refer to, say, a specific text input in your `printPost` template, without worrying about accessing the inputs created by other instances of the `printPost` template. You can do that with unique IDs, but it's fiddly and error-prone.
spankalee
You should really check out lit-html[1]. It's not a framework like this README claims. It just renders template with template literals, but it does so with minimal DOM updates and safely. And it has a number of features for declaratively adding event handlers, setting properties, and dealing with lists.
econ
I prefer something like this before building the template string.
image = post.image_urls?[0] || "";
Then have the printImage function return an empty string if the argument is an empty string.
${printImage(image)}
Easier on the eyes.
hyperhello
I like it. Not only does it move the UI into JavaScript, but it moves the scripting into the HTML!
Koffiepoeder
Have a feeling this will lead to XSS vulnerabilities though.
edflsafoiewq
It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.
_heimdall
Reactive view libraries exist to hide those details. I think the OP is proposing that the benefit of reactive views/state isn't worth the cost and complexity.
d357r0y3r
It is absolutely worth the cost and complexity. The cost and complexity of building a web application using some home grown vanilla JS system will end up being a horrible engineering decision most of the time.
There have been zero times in my career where I thought "hmm, maybe we shouldn't have build this thing in React and let's just go back to page scripts." If you're building landing pages and websites, then okay. But that's not most of what we're all hired to build these days.
_heimdall
That's way too dependent on context to say the cost is always worth the complexity.
On a team that is experienced in react, or a project that is heavily dependent on client side rendering react (or similar) make sense.
On a team that is more backend focused or a project that is CRUD heavy and generally rendering state that persists on the server, it could very well make sense to lean on server rendered HTML with small bits of JS scripts for interactivity.
We as an industry way over tilted on client-side rendering. If you're building Facebook or Figma or Discord, sure maybe CSR is a must. For most websites you don't need much CSR though, and if you're only using it for small bits of interactivity you may be better offer foregoing the complexity of a framework and taking responsibility for the full render pipeline.
kyleee
It’s probably about time for that to become fashionable again
vendiddy
It's easy to forget how tedious things used to be before React became popular.
Keeping data in sync with the UI was a huge mental burden even with relatively simple UIs. I have no desire to go back to that.
JoeyJoJoJr
Do you mean subscribing to events/callbacks, manually managing object lifecycle, manually inserting list elements, keeping it in sync with the state, etc, etc. Because that was all friggen horrible. Maybe new approaches could make it less horrible, but there is no way I’d go back to what it was like before React. If anything, I want everything to be more reactive, more like immediate mode rendering.
ChocolateGod
IIRC its what frameworks like Svelte do when they hit the compiler and optimize, which makes the best of both worlds.
wruza
They still nail "state" to element trees, which creates unbenchmarkable but real update costs. Svelte does better than react, but only within the same paradigm.
efortis
I use a helper similar to React.createElement.
const state = { count: 0 }
const init = () => document.body.replaceChildren(App())
init()
function App() {
return (
h('div', null,
h('output', null, `Counter: ${state.count}`),
h(IncrementButton, { incrementBy: 2 })))
}
function IncrementButton({ incrementBy }) {
return (
h('button', {
className: 'IncrementButton',
onClick() {
state.count += incrementBy
init()
}
}, 'Increment'))
}
function h(elem, props = null, ...children) {
if (typeof elem === 'function')
return elem(props)
const node = document.createElement(elem)
if (props)
for (const [key, value] of Object.entries(props))
if (key === 'ref')
value.current = node
else if (key.startsWith('on'))
node.addEventListener(key.replace(/^on/, '').toLowerCase(), value)
else if (key === 'style')
Object.assign(node.style, value)
else if (key in node)
node[key] = value
else
node.setAttribute(key, value)
node.append(...children.flat().filter(Boolean))
return node
}
simonw
That looks like it replaces the entire document every time state changes. How's the performance of that?
WickyNilliams
Even if performance is fine, the big usability issue is that it will blow away focus, cursor position etc every render. Gets very painful for keyboard use, and of course is a fatal accessibility flaw
efortis
yes, that’s the downside, focus is lost on init()
yumaikas
I've been working on https://deja-vu.junglecoder.com which is an attempt to build a JS toolkit for HTML-based doodads that shares some ideas with this.
I don't quite have proper reactive/two-way data binds worked out, but grab/patch seem pretty nice as these things go. Also, the way this uses templates makes it very easy to move parts of the template around.
It's also largely injection safe because it's using innerText or value unless told otherwise.
atum47
On my first official job after college I was working on making a web version of a Delphi software. The team was already on their third rewrite of the front end cause they had to change frameworks. I made the cass that we should write our own framework, so I prototyped FOS (the components I use on my website) to prove my point. The team (a bunch of mostly Delphi programmers) did not like my suggestion. Anyways, soon after that another company made me a better offer so I left. Years went by an I finally take a shot at another framework: tiny.js [1]. I've been using it in all my personal projects so far. I'm particular proud of the ColorPicker [2] component I wrote that I've used in two projects so far. As you can see, one can argue that tiny.js it's not a framework at all, just some wrapper functions that helps you create Functional components.
1 - https://github.com/victorqribeiro/TinyJS
2 - https://github.com/victorqribeiro/Chip8js/blob/master/js/Col...
npodbielski
I dont know... I kind of like diffrent look of HTML and JS. At least you know what is what. In tiny evrything looks like JS and you actually have to read it to know what is what. Also what if someone will define span variable? Does it override the span HTML component function?
Otherwise looks like nice.
atum47
In tiny evrything looks like JS and you actually have to read it to know what is what
Also what if someone will define span variable?
hu3
You might want to look at something like morph Dom to keep input focus when you have to re-render the form, for example.
atum47
Since the user decides what happens when the state gets updated its up to them to address that. For me, I usually avoid re-renders when possible, I rather update the property associated with the state.
Have you faced any scenarios where that's needed? I'm curious.
seumars
It seems the "hard way" here is just avoiding frameworks. The real hard part of UI is in fact state management and the myriad of methods for handling state.
floydnoel
this is pretty much how i wrote one of my side projects, https://bongo.to
it was fun and very fast to ship. no frameworks or libraries needed.
triyambakam
I like to prompt Claude to create artifacts in plain HTML, CSS and JS. I like the portability and hackability of these. React is too heavy for a lot of simple ideas even if reactivity is needed.
This might be heresy to many JS devs, but I think 'state' variables are an anti-pattern.
I use webcomponents and instead of adding state variables for 'flat' variable types I use the DOM element value/textContent/checked/etc as the only source of truth, adding setters and getters as required.
So instead of:
it would just be akin to: Its hard to describe in a short comment, but a lot of things go right naturally with very few lines of code.I've seen the history of this creating spaghetti, but now with WebComponents there is separation of objects + the adjacent HTML template, creating a granularity that its fusilli or macaroni.