Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

squaresapp.org

Post reply on HN
Print view View original

101–110 of 135 posts

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

#101

Post by Py_ »

seattle_spring wrote: post #70

Whenever I see projects like this, I'm convinced the authors have never worked on actual large-scale frontend projects and teams, especially not for a meaningful amount of time. It's telling when people say "React has gotten too complex." This might be good for "Squares", but I am not looking forward to having to explain to the new bootcamp grad why this would ruin any sort projects of size.

RawJS author here.

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

Thank you for your positive encouragement.

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

#102

Post by ble »

Py_ wrote: post #98
LudwigNagasena wrote: post #42

> RawJS is a better way to call document.createElement(). React is a way to reduce calls of document.createElement using virtual DOM, ie using React.createElement. It’s JSX which is supposed to be a better way to call document/React.createElement. So what exactly does this compete with?

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

My biggest beef with JSX is that what I might call the "most natural way" and certainly the "most concise way" of writing certain somewhat-complex structures in JSX often ends up being a huge mess. E.g. an element is some JSX elements with some code embedded, and the embedded code is returning some other JSX elements that have yet more code embedded in them, and the easiest refactoring to make the whole thing less gross is extracting functions that don't really deserve a name of their own.

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

#103

Post by Py_ »

ble wrote: post #99
Py_ wrote: post #87

Earlier quoted context omitted.

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

I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... ), but what do you dislike or hate about ES modules? From my own experience, they are extremely frustrating when tooling doesn't work well or at all with them. Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily…

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.

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

#104

Post by Py_ »

jawns wrote: post #36

"No known bugs" is not the brag that they think it is. It's like someone peddling a medication and saying, "No known side effects."

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.

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

#105

Post by seattle_spring »

Py_ wrote: post #101
seattle_spring wrote: post #70

Whenever I see projects like this, I'm convinced the authors have never worked on actual large-scale frontend projects and teams, especially not for a meaningful amount of time. It's telling when people say "React has gotten too complex." This might be good for "Squares", but I am not looking forward to having to explain to the new bootcamp grad why this would ruin any sort projects of size.

RawJS author here. I've been working on said large scale projects for 20 years. Thank you for your positive encouragement.

Not according to your LinkedIn you're not. I'm talking real scale, hundreds of developers and millions of users. Hell, even midsized companies like Redfin, Grammarly, Brex, etc would suffer using something like RawJS.

Seems fine for hobby projects though.

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

#106

Post by Py_ »

seattle_spring wrote: post #105
Py_ wrote: post #101

Earlier quoted context omitted.

RawJS author here. I've been working on said large scale projects for 20 years. Thank you for your positive encouragement.

Not according to your LinkedIn you're not. I'm talking real scale, hundreds of developers and millions of users. Hell, even midsized companies like Redfin, Grammarly, Brex, etc would suffer using something like RawJS. Seems fine for hobby projects though.

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.

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

#107

Post by striking »

Py_ wrote: post #93
striking wrote: post #19

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.

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)

I don't have to admit anything, I think it's a complete waste of time until you're shipping something with so much value that juicing your conversion rate by 1% more is a meaningful improvement. And I don't care if the comment is tongue-in-cheek or not, even ironically this holier-than-thou style of argumentation grates like you wouldn't believe.

Help me turn my ideas into reality faster. Then you can be as snarky as you like. It's the only reason anyone tolerates DHH or anyone like him.

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

#108

Post by throwitaway1123 »

Py_ wrote: post #103
ble wrote: post #99

Earlier quoted context omitted.

I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... ), but what do you dislike or hate about ES modules? From my own experience, they are extremely frustrating when tooling doesn't work well or at all with them. Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily…

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…

> I really dislike having to include every last identifier that exists in other files.

How do you feel about esm's namespace import feature [1]? For example:

  import * as React from 'react'
> 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.

You can obviously use es modules directly in the browser without additional infrastructure. Bundlers simply combine (bundle) all your dependencies into a single file to prevent multiple http requests (although this is less relevant today with HTTP2). HMR solves a completely different problem — replacing individual modules in the browser during development when they change instead of reloading the entire page. HMR isn't something that es modules necessitate. You're free to reload your entire page every time you make a change in development.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#109

Post by pests »

xnorswap wrote: post #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 cas…

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

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

#110

Post by throwitaway1123 »

spoiler wrote: post #76
jakelazaroff wrote: post #45

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

The TypeScript compiler has native support for JSX. You don't need Babel, you just have to add the '"jsx": "react"' line to your tsconfig file to enable it.

Post reply on HN