JavaScript Views, the Hard Way – A Pattern for Writing UI

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:

  /* State variables */
  let name;

  /* DOM update functions */
  function setNameNode(value) {
    nameNode.textContent = value;
  }

  /* State update functions */
  function setName(value) {
    if(name !== value) {
      name = value;
      setNameNode(value);
    }
  }

it would just be akin to:

  set name(name) { this.nameNode.textContent = name }
  get name() { return this.nameNode.textContent}

  /* or if the variable is used less than 3 times don't even add the set/get */ 
  setState({name}){
     this.querySelector('#name').textContent = name;
  }

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.

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.

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

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.

It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.

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>
      `
    }

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...

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.

Java script

Why not use Web Components? Is it because they’re classes?