Live data from Hacker News

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

squaresapp.org

71–80 of 135 posts

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

#71
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.

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

#72
post #55

Earlier quoted context omitted.

> 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.

You can use many other frameworks for that like Svelte (with SvelteKit), or Solid (with SolidStart)

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

#73
It seems so obviously bad to have to write your CSS and HTML in javascript.

I don't get why people keep coming back to it.

I mean, I get that the point is to add something that plain CSS and HTML don't do on their own, but it seems so much better to start with regular CSS/HTML and enhance... keep the standard syntax and semantics everywhere you possibly can, so that the dev only has to deal with framework-specific syntax and semantics where it's needed.

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

#74
post #73

It seems so obviously bad to have to write your CSS and HTML in javascript. I don't get why people keep coming back to it. I mean, I get that the point is to add something that plain CSS and HTML don't do on their own, but it seems so much better to start with regular CSS/HTML and enhance... keep the standard syntax and semantics everywhere you possibly can, so that the dev only has to deal with framework-specific sy…

I mean, that is basically JSX is it not?

I agree with your points, however. How the W3C has not come up with a good solution is beyond me.

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

#75

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

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 synch…

> But where FP tries to avoid monads and stay pure

Does not compute, monads are a construction you see pretty much only in functional programming. Monads are the tool Haskell uses to model effects and generate them from pure computations. They're not magic, they're nothing more than a pairing of a "map" and a "join" function (or "pure" and "bind" if you prefer that angle). Bottom line, monads are as pure as anything else, it's just the behind-the-scenes interpreter for the IO actions produced by the "main" function that isn't (edit: I suppose ST also counts as hidden magic)

Other effect systems not based on monads have recently been catching on, such as Effect for TS, or language features like Abilities in Unison. Right now I get "observable-everything" by using computeds in Vue as much as possible and keeping raw refs private (i.e. not exported). But ultimately, something has to set the refs, and there's still no easy way to account for that mutation behavior in the type system.

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

#76

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

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.

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

#78
post #66

Earlier quoted context omitted.

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

This is the third or fourth time I see today in HN of someone treating someone's personal project or opinion as "the direction the community is moving". If every new toy framework is treated like this, it's no wonder people feel overwhelmed by frontend development.

This seems to happen on subjects much broader than FE community direction. Fringe twitter posts on politics are very frequently interpreted as "what the entire community believes."

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

#79

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

> 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.

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

#80
post #76

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

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'…

> With React/Vue/etc you need at least something like Babel

VueJS works with just a CDN link and a script tag. Nothing serious actually uses this approach, and they stopped using it for examples, but it still works.

Post reply on HN