The sample repo is at least well-commented. I've taken the liberty of pasting some of the sample code here, sans comments, so we can see what the code style is like. My editorial take: no thanks. This looks less declarative than jQuery. If this is the alternative, then yeah, you still probably need React (or Vue/Svelte/Astro/whatever)

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

...yuck. The hilarious part to me is that every single thing this does could be done in one line of an angular template with massively less typing and opportunity for error. just a:

<div style="display:inline-block...." [style]="{ 'backgroundColor: hsl(215, 100%, 50%)' : active }" (click)="active = !active">

Like, I know you want to create an element and blah blah...but if it takes your dev 4x longer to write it, why are you doing it? Ultimately, in the real world, all of this is devs trying to make bragging rights for reasons with no real commercial viability intended. As much as we like the idea of less JS frameworks and all that, there is a reason why every major company uses them - they allow people to make business-impacting changes and features faster.

What is really funny to me though is that it is even an awful example - you should never use a div as a button, it is an accessibility nightmare. That is telling.

> you should never use a div as a button, it is an accessibility nightmare

Eh, that's easily fixable with role="button" and tabindex="0". Oh, and adding a keyup handler so space and enter both click it. After that though, you have a perfectly good button. Well, minus any visual feedback that it's being clicked, but presumably you're doing some custom effect to go with the custom element...

So never say "never", but yeah, use a damn <button> whenever you have the choice. The roles are there to give you an escape hatch when you don't. And sometimes buttons are actually just button-shaped links, in which case you _really_ want to use an <a> tag, because those are heinous to imitate properly.

Example author here.

I have to say this is a bit disingenuous. You pulled the segmented button component which in a real-world environment would just be a part of a library. You should show the part where it gets used. From my experience, how this ends up playing out in a real-world environment is that these things end up getting boxed into higher-level UI libraries that turn all this stuff into quick function calls.

The vast majority of devs aren't (and shouldn't be) writing their own custom components.

> The vast majority of devs aren't (and shouldn't be) writing their own custom components.

Component frameworks are for doing exactly that, and they generally make it pretty easy, with no manual DOM manipulation required when state changes.

Rather than continue with my salty commentary, I suggest to anyone still reading to look at any other file in the example project and draw their own conclusions: https://github.com/squaresapp/rawjs-sample

Even worse, their "Check out Squares" link takes me to https://github.com/squaresapp/rawjs-sample

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.

my reading on the "limitations you need to accept with this project structure" is that those limitations are about this particular project structure, not on rawjs itself; i.e. my understanding was that you can also write a project using rawjs using normal ES modules and plain JS (as mentioned briefly in the main rawjs github repo readme).

that said, I do agree that pointing to a highly opinionated example project is a bit confusing

My point is that, this being written by the authors of Rawjs, who unironically proselytize that "npm install programmers need to clean up their act" while providing a project which would require you to `npm install` dependencies is telling.

Author here. It was a tongue-in-cheek comment. Let it slide.

The demo is here.

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.

Anything that is supposed to replace web UI frameworks needs to be able to perform client side routing. You can argue that the different colors shouldn't represent a push to history, but that's a criticism of the implementation, not the library.

Demos should cover the happy path really well. This opens modals that don't have an x to close them. If you click outside the modal, a common alternative way to close modals, it just picks a different color. The background fades to black so you can't see what you are picking. Then the back-stack grows large so you can't even back out of the demo normally. I'm not going to look at the code, even if it looks great this isn't an experience I'd ever want. There just too much basic stuff missing.

Maybe it's just a poor demo, are there better examples?

Anything that's like a combination of react and a static site generator? Where it has the ability to build a static site but also includes reactivity

I'm not a fan of websites with super huge font. I'm on a 1080, and a lot of the words fit in a smaller font just fine.

The modal when showing a single colour also suffers from backdrop stacking issues, which the back button navigation doesn't undo.

I guess rendering the UI as a function of state still has its merits.

So it implements core SPA functionality?

Why is that bad? That's implementation detail and I would say the right implementation.

When you click links it changes the URL, so the back button takes you to the previous URL.

I absolutely hate when pages hijack the back button, but this ain’t it.

I mean, it’s not a dark pattern hijacking the back button, it’s a bug hijacking the back button.

It’s still a bad experience, though.

It's not hijacking back like it happens with some sites that redirect and such. It's just pushing each color into history.