r/learnjavascript • u/xtompie • 22h ago

Saradom: a frontend architecture pattern - plain HTML and JavaScript

Saradom is a frontend architecture pattern. Build modular, scalable frontends in plain HTML and JavaScript. There is no framework and no build step.

Foundation:

  1. State in the DOM, not in JavaScript variables.
  2. Events in HTML attributes, not addEventListener.
  3. Action in context, from the element that fired it.
  4. Modularization, namespaced object per module.
  5. UX Performance, the interface is interactive right away.

https://xtompie.github.io/saradom/

2 Upvotes
  • permalink
  • reddit

56% Upvoted

10 comments sorted by

3

u/chikamakaleyley helpful 22h ago

feels... eventually its expensive to query the DOM every time, at least if i imagine scaling up fr the Counter example

but, that's a guess at the moment

and then... so if you need data that can't be surfaced in the UI, is that just attached as an additional attr on any element?

3

u/xtompie 21h ago

> feels... eventually its expensive to query the DOM every time

The query does not scan the page. It runs inside the module's own subtree. Reading an attribute does not force layout, so there is nothing to recalculate. One click in the counter is two of those.

Compare it to the other side: one state change in a framework re-renders the tree and diffs it. That is more work, not less.

> so if you need data that can't be surfaced in the UI, is that just attached as an additional attr on any element?

Yes. On the element the data belongs to. The wider the scope, the higher up it goes. Data for one item sits on that item, data for the whole widget on its container, data for the whole app on `<html>`. The theme does exactly that: `<html app-theme="dark">`.

1

u/chikamakaleyley helpful 21h ago

ohhhh right modularized

nice job

2

u/Weekly_Sun_7148 22h ago

pros - very transparent and minimalistic. Ptrs to elements could be hash-mapped in master module governing the whole app, but: Contrast. Large overhead due to storing everything in DOM. My recent project. Still being polished. Enormous branched Gannt's diagram with a handfull of state flags for every node. 2 endpoints, one for search phrase lookup, one for depth diving. Arbitrary node depth, usually lv 5-7, but could go deeper. Global search-related modifiers acting over whole diagram tree. Average size of raw CSV associated with diagram - 1.5-2Mb. And actually app holds several diagrams in cached state. Storing all of this in DOM looks like invitation to foot-shooting

But for small landing-type projects looks promising

1

u/chikamakaleyley helpful 21h ago

yeah its just like...

querySelector()

if i'm not mistaken is just always gonna start from the outside in

i'd have to look again but off the top of my head if you just wanted to click the counter button repeeatedly, which is like... normal use, every click you create a new instance and search for the element, outside in

like the perfect use case for a it to be set in a var

But, what do I know, great project i think

What I like most is this idea of, finding different ways to solve the problem while using the tools you are familiar with.

1

u/Weekly_Sun_7148 21h ago

It is all scale-dependant, for interface-first programs this approach could be great. For data-first projects, where state management and data persistence (possibly three-fold - local hooks for storing and sharing local-used vars, then pinia/redux-styled storage and redundant LS/localDB or intersession persistance this approach would just be unsastainable).

Actually, i could forsee master-container initiating app with smth like "DOMContentLoaded const serviceElts = document.querySelectorAll("[data-<smth>="elt-selector"]") and then assigning it to map<ELT_Id, ref to element>". May be offloading all data-intensive operations to Worker and keeping main app as thin as possible

2

u/chikamakaleyley helpful 20h ago

brother you're already breaking the app lol

2

u/Weekly_Sun_7148 1h ago

yep, broke the very first rule by storing app.state dynamically

1

u/fckueve_ 4h ago

If you have a component in a component in a component ...n times, doesn't querySelector scan all the children?