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

[xnorswap]

You know what's an even easier way to call "document.createElement"?

    $.append

Sure, there's a reason why people moved away from JQuery, but I'm not convinced that a half dozen lines of boilerplate per element is a good solution either.

The example almost reads like a parody, here's a half dozen lines to write what you could write in one line of raw html:

    <div onClick="alert('Hello World')" style="{padding:100px;background:red}"></div>

But I guess I just don't get it, I don't understand the use case where you want to manipulate the DOM but don't want to do so directly through the DOM API. You also don't want the convenience of JQuery, nor want the composibility of react or similar components.

Somehow they think they've found a worthwhile middle ground between just calling the DOM API and using Jquery. I don't agree that targetting that is a worthwhile endeavour. It's almost avoiding the DOM API for the sake of it, and tying yourself to a library without many benefits.

p.s. Having had the concept of writing "Vanilla JS" hijacked by a library author, now writing "Raw JS" is too.

Any day now we can maybe expect a new "Libraryless" framework.

[Py_]

RawJS library author here.

$.append appends, in the name ".append".

Though

The point of RawJS is to help with element constructions. jQuery was a god-send back in the day for manipulation and querying (before we had document.querySelector()) but constructions of hierarchies were never really its thing.

There are other libraries that work like RawJS to make complex DOM constructions with function calls. I just don't think the ergonomics of them were as well thought-out as it is in RawJS.

[tomhallett]

To me the usescase feels like: I am using Hotwire/htmx. When I need more complex behavior, instead of using stimulus/apline/hyperscript, you can make custom webcomponents which use rawjs for the rendering.

[tambourine_man]

> Sure, there's a reason why people moved away from jQuery

And after all these years, I can’t see a technical one. Especially if the answer is React.

[pests]

> p.s. Having had the concept of writing "Vanilla JS" hijacked by a library author

Woosh?

You've obviously missed the joke. VanillaJS is not a real framework or library - try to download it, its 0 bytes. The whole intent is that you are using built-in JS features, aka Vanilla Javascript.

[nogridbag]

This showed up in my google news feed last night and I immediately searched to see if it was posted to HN, which it had not. So it's interesting to see this reach the front page this morning.

There's a youtube video linked from the github that goes into some explanation into the "why", e.g. we should minimize deps, use standards instead of framework silos, avoid frameworks which have monopoly on dom, easier debugging, onboarding, etc. I agree with most of that in principle, I just don't know if this is the solution.

When we had larger component frameworks built on vanilla JS, like ExtJS, they had their own problems, e.g. framework code which alternated reading styles and updating styles from DOM causing reflow, or DOM listeners that were not properly cleaned up. But with those older frameworks, when something went wrong, it was trivial to debug the entire codebase including the framework, because it was all basic JS.

These days with something declarative like Vue, there's far less need to reach for a debugger and usually stuff just works, but when something does go wrong it's often a bit perplexing and you feel you're stuck because everything is happening in the framework black box. I still like Vue, but I must admit even if it's one of the simpler frameworks, there's a bit of an onboarding issue. I still see our devs making mistakes like doing side effects in computed variables, or modifying props state in children, even after a few years of experience.

[Py_]

This take is really on-point.

I'd like to add that from my experience, the more "out there" and the less "rudimentary" your UI and general app is, the more the frameworks really get in your way.

[iandanforth]

Apparently the author has it out for import statements.

"No import dumpster at the top of each file. Forget imports even existed. Just access whatever you want, wherever you want. TypeScript knows where to find it."

This is a bizarre preference. Is there some reason the JS community has turned against explicitly listing what libraries are used by a module?

[jakelazaroff]

I definitely would not say the authors’ opinions are representative of the JS community.

[theogravity]

the namespacing is also odd as well. I don't usually see it used that way in Typescript.

[jakelazaroff]

Can someone explain these bullet points from the sample repo? [1] They seem contradictory, but maybe there's some esoteric definition of "builds" that I'm missing.

> - No bundler, no build system. Near-zero complexity.

> - TypeScript builds your app in milliseconds, even if your app gets huge.

[1] https://github.com/squaresapp/rawjs-sample

[Py_]

Repo author here. Sorry–maybe not the best choice of words.

By "no bundler, no build system", it kind of means "no webpack, rollup, gulp, etc".

I tend to think of TypeScript as a non-negotiable for any serious project (hopefully I don't get flamed for saying that), so using the build system that's baked into TypeScript means you don't have to rely on yet another tool to handle this.

[spoiler]

I think they reference two different things

The first statement means you don't need a compiler (or larger build system) to use the library. With React/Vue/etc you need at least something like Babel (but usually also needs a bundler); which has become common lately in the web dev ecosystem. This is all just vanilla JS (or TS) you write; no need to transform JSX or some else.

I assume the second statement means there's not a lot of added type checking time burden for using the library, if you do decide to use TypeScript in your project (but don't have to). Not sure what this means specifically, but I might be something along the lines of it relying on simpler types or eager `any`s in internal types to short-circuit resolving/checking types.

[merelysounds]

I appreciate that there is a code sample at https://github.com/squaresapp/rawjs-sample , but I'd prefer something more explicit.

Like what https://youmightnotneedjquery.com did - comparisons between the popular library and the replacement.

[Py_]

RawJS library author here.

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

[synergy20]

https://medium.com/@arannadelwar361/embracing-the-power-of-r...

https://dev.to/paulgordon/after-using-rawjs-im-never-touchin...

Both links helped to explain, the landing page is indeed not very good.

[ranting-moth]

These are also marketing texts. The crowd at HN is very tech savvy. You could at very minimum implement the classic TODO app to show it off.

[evantbyrne]

lol geez the React devs in the comments of that dev.to post are out for blood

[base]

The page needs some code examples. It's just marketing talk, needs to be more oriented to it's audience.

[Py_]

RawJS library author here.

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.

[striking]

From the example repo:

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

Yeah, no thanks, I'm sticking with my "unclean" ways.

[Py_]

Repo author here.

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)

[thatxliner]

Another 2kb “JavaScript got better” library is https://www.arrow-js.com/

[zackmorris]

That's pretty great! For me, the great tragedy of "modern" programming is that we took the enormous potential of scripting languages and turned them back into C++. Whereas I started with C++ and have done everything I can to get away from it.

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.

[leetrout]

You never _needed_ React in the first place.

[yieldcrv]

exactly, unless you like exchanging time for food and shelter via rendering anything in the browser

[junething]

I'm gonna be honest, you need someone to proofread your website. I spotted two typos on a quick scroll-through, both of which could probably be caught by copy-pasting the thing into Word.

[Py_]

RawJS library author here.

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.

[jack_riminton]

Big claims and zero code examples?

No I'm not going to go digging in a repo without so much as a top-level overview of the approach

[chuckadams]

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

[pcthrowaway]

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.

[8organicbits]

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.

[carry_bit]

Reminds me of componentized jQuery. It appears this has you have to once again apply DOM patches manually; hopefully you implement that correctly every place you update the state.

[catapart]

I respect the intention here. I'm a big fan of "DOM as State", myself. I'm more partial to modularity and encapsulation using custom elements, rather than runtime js objects that inject well-known elements, but I can't say one is better than the other. Just my current naive preference.

[Kerrick]

There's a typographical error on the home page ("It's API design is complete and there are no known bugs" should use "Its"). I would've submitted a PR, but the link to the website repository actually links to a static site generator, not the website itself.

[curtgrimes]

Two more I noticed:

“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?”

[dynamite-ready]

I understand some of the disparaging replies i regards to execution, but if I'm honest, as someone who writes a lot of React, the idea of ditching it for a universally support standard of any kind, is a very appealing idea.

[troupo]

> ditching it for a universally support standard of any kind

RawJS ain't it.

If anything, React' JSX is the universally supported standard these days :)

[tmaly]

The first thing that popped in my head seeing this post was the Christmas Dunkin Donuts commercial about ties.

The guy would keep opening up the present year after year and it was another tie.

It seems like the same thing with frameworks and now this library.

[ramesh31]

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

...what?

Are people actually using 3rd party hosted CDN scripts for anything even remotely serious in production?

[seattle_spring]

> Are people actually using 3rd party hosted CDN scripts for anything even remotely serious in production?

No, and I think that point makes a very important distinction here: Projects like this might be great for small / personal projects, but they fall apart fast in any sort of large-scale project. The reason people think React is bloated is because they've never worked on a project large enough to take advantage of what React offers.

[giancarlostoro]

How does this compare to SolidJS which uses JSX and performs insanely close to vanilla JS already? If I really want to shrink my front-end I might as well, just go for Solid or Preact.

[Py_]

RawJS author here.

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

[can16358p]

While I agree that React has become too bloated, productivity wise I can't see anything like this (or something similar) replacing React.

Yeah, we need something lightweight, but not this.