RawJS is a better way to call document.createElement() (squaresapp.org)

https://rawjssample.pages.dev/

I immediately see that it ~hijacks my back button~ fills my back-stack such that I can't use the back button normally. Doesn't look promising.

    namespace App {
      export class SegmentedButtonComponent {
        readonly head
    
        constructor(...segments: ((element: HTMLElement) => Raw.Param)[]) {
          this.head = raw.div(
            raw.css(
              "> *", {
                display: "inline-block",
                padding: "1em",
                borderRadius: "5px",
                userSelect: "none",
                webkitUserSelect: "none",
                cursor: "default",
              },
              "> .active", {
                backgroundColor: "hsl(215, 100%, 50%)",
                color: "white",
              },
            ),
            () => {
              const buttons: HTMLElement[] = []
    
              for (const fn of segments) {
                const button = raw.div()
    
                raw.get(button)(
                  raw.on("click", () => this.select(button)),
                  fn(button),
                )
    
                buttons.push(button)
              }
    
              return buttons
            },
          )
        }
    
        select(childElement: HTMLElement) {
          toggleClass(childElement, "active")
        }
      }
    
      function toggleClass(child: Element, cls: string) {
        Array.from(child.parentElement!.children).map(e => e.classList.toggle(cls, e === child))
      }
    }

The live sample of that is not very impressive. And even worse:

> These are the limitations you need to accept with this project structure:

> You have to be disciplined to only use dependencies that are published on jsdelivr (npm install programmers need to clean up their act)

That with a package.json which has dependencies @squaresapp/rawjs and rawter, both of which have no info on npmjs. Talk about "do as I say, not as I do". The idea that you might be able to handle things like i18n and a18y without dependencies screams "not invented here" syndrome.

There's a demo app here: https://github.com/squaresapp/rawjs-sample

(Does that help you? Or do you think it still needs more?)

I'll get on updating the readme shortly.

I didn't fork anything.

And your link just pr0n'd me in a coffee shop.

Thank you.

“last years framework” should be “last year’s framework”

“How long with it take to find and fix bugs as our app grows?” should be “How long will it take to find and fix bugs as our app grows?”

You have to admit at least admit that minimizing dependencies is an admirable goal (despite my tougue-in-cheek comments in the readmes I write)

Honestly this whole thing blew up so fast I wasn't expecting any of this. The home page for the website isn't even done yet.

Thanks for +1'ing this idea. I like what that website did and I might need to build something similar.

I think it's probably more fair to say that SolidJS is "insanely close" to React rather than RawJS.

For example, everything today is built on promise chains, which are borrowed from monads in functional programming, which someone came up with (partially) to let immutable synchronous blocking code be written in mutable imperative style. But where FP tries to avoid monads and stay pure, promises are now considered so fundamental that we have async/await on nearly every function. Delivering such a degree of nondeterminism that we've effectively resurrected goto.

If I ever design a language, all variables will already be proxies so that everything can be observed. Just like it will use pass-by-value instead of references, the same way that php copies arrays via copy-on-write internally. And have channels between fork/join green threads with full memory isolation provided by the runtime, to provide a declarative style of multithreading that looks like vanilla higher-order functions. There are at least a dozen alternative approaches like that which reduce code complexity by orders of magnitude, that never got widely adopted in recent decades. So we're all manually managing exceptional behavior rather that avoiding it in the first place.

ArrowJS shows how simple programming could be if we catered to developers instead of some abstract notion of lightweight purity that results in GHz computers struggling to run unmaintainable GUIs that ran fine with less code on 33 MHz computers in the 1980s. ArrowJS <-> FP/spreadsheet, "modern" JS <-> C++/assembly language.

What I meant was that it's a small library with a relatively small surface area for bugs, and it's been under pressure from a few different projects for some time now, and it's been quite a while since we have discovered any behaviour I would consider to be buggy.

I'm sorry you took this as a "brag". This wasn't the intention.

The main thing RawJS brings is ergonomics when creating element hierarchies of plain HTMLElement instances. I don't see JSX as something that does this very well. A lot of people don't like JSX, because its not JavaScript. There are other libraries that are better document.createElement() that work somewhat similar. RawJS isn't new in this regard, I just believe that it's better executed than the others.