Hacker News Reader

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

RawJS-style development (using whatever library to accelerate document.createElement) becomes more appropriate the more divergent your UI is. This is the kind of thing I've found myself working on over the years.

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

RawJS library author here.

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.

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

You can already do encapsulation without them by using TypeScript namespaces. It's sad that namespaces didn't become part of JavaScript.

I really dislike having to include every last identifier that exists in other files. Yes I know that IDEs will sometimes do this for you

I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this.

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

RawJS author here.

I've been working on said large scale projects for 20 years.

Thank you for your positive encouragement.

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

RawJS author here.

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

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

RawJS library author here.

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.

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

Library author here.

I didn't fork anything.

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

Thank you.

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

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

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

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.

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

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.

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

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)

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

Cool. My arm is available if you need a donation.

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

RawJS library author here.

I wish I could upvote your comment a thousand times, after spending literally the whole day so far trying to pour water on a burning building.

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

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.

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

RawJS library author here.

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

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

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.

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

RawJS library author here. Moving away from modules is definitely not what I've observed in the community, I see no evidence that this is "the direction the community is moving".

That said, I admittedly have a visceral hatred for ES modules. I personally believe them to be the worst thing that has ever happened to the language. Encapsulation is of course a great thing but in my opinion there are much better ways to do this. I'm not the only person that thinks this–there was a gist that got to the homepage of HN a while back titled something like "ES Modules are terribly, actually" (IIRC).

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

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.

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

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.

Py_on [dead]

RawJS creator here. Here to answer any questions anyone might have.

Py_on Show HN: JSFiddle-style object-relational BaaS

The 403 on the sourcemap is by design (I might change this), I'll have to look into the stack overflow though...

Py_on Show HN: JSFiddle-style object-relational BaaS

I guess I need a full-screen button to expand the docs pane.

Py_on Show HN: JSFiddle-style object-relational BaaS

Yes but they're all isolated / custom-built at the moment ... other than the actual class editor which is built using the Back.io public API (it's a self-hosted system)

Py_on Show HN: JSFiddle-style object-relational BaaS

Async network requests wired up via Object.defineProperty()

It's covered in the docs: https://back.io/#docs/io

Py_on Show HN: JSFiddle-style object-relational BaaS

Cool, thanks for the report.

There is a code generation process that needs to occur, but I suppose this could be optimized.

Py_on Show HN: JSFiddle-style object-relational BaaS

LOL -- I guess that remark could be interpreted a little crude :)

Py_on Show HN: JSFiddle-style object-relational BaaS

This is a backend-as-a-service that I've been working on for a few months. It's for people to build simple apps with. Any feedback would be very helpful.