Live data from Hacker News

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

squaresapp.org

51–60 of 135 posts

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

#51
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?

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

#55

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.

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

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

#56

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?

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

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

#57

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.

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

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

#58

Earlier quoted context omitted.

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?

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

#59
post #55

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.

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

React is great when you absolutely need state management on the frontend, but is overkill for the vast majority of frontend components to the point I would say it basically doubles the time to create a SPA. I wish I could just import it for one-off components and use traditional HTML rendered by the server for everything else.

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

#60
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:

    

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.

Post reply on HN