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

121–130 of 135 posts

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

#121

Post by whstl »

dncornholio wrote: post #118
whstl wrote: post #66

Earlier quoted context omitted.

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.

It's an awful trend really. When authors do this sometimes I even feel personally attacked and have to hold myself to be nice in the comment section. That usually means I don't even comment at all.

Same. I was quite happy that jakelazaroff was able to phrase it in a better way than I would.

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

#122

Post by throwitaway1123 »

spoiler wrote: post #120
throwitaway1123 wrote: post #110

Earlier quoted context omitted.

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

The TS compiler might produce something, but that's not usually enough in the context of a larger React application (eg, they often import non-ts files).

> The TS compiler might produce something

It'll produce calls to React.createElement provided with: the tag name, props, and children. That's all JSX is.

> but that's not usually enough in the context of a larger React application (eg, they often import non-ts files)

React and JSX don't require you to import non-ts files. If RawJS's nascent ecosystem picks up momentum, people might start importing non-ts files in RawJS projects (e.g. css modules). My point is that there's nothing special about the RawJS api that allows you to skip a build step, and conversely, there's nothing about React that requires Babel (assuming you're already using TypeScript).

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

#123

Post by throwitaway1123 »

whstl wrote: post #115
Py_ wrote: post #103

Earlier quoted context omitted.

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 don't personally have a problem with ES Modules per se, but I do agree with the "I really dislike having to include every last identifier that exists in other files" part. I'm a big fan of "global" components in Vue.js, which are "dependency injected" into all your components but in a totally transparent way. You can "just use them" in templates, with zero boilerplate. You also don't have to mock imports in unit te…

> I don't personally have a problem with ES Modules per se, but I do agree with the "I really dislike having to include every last identifier that exists in other files" part.

Isn't this exactly the problem that esm's namespace import feature solves?

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

#125

Post by whstl »

throwitaway1123 wrote: post #123
whstl wrote: post #115

Earlier quoted context omitted.

I don't personally have a problem with ES Modules per se, but I do agree with the "I really dislike having to include every last identifier that exists in other files" part. I'm a big fan of "global" components in Vue.js, which are "dependency injected" into all your components but in a totally transparent way. You can "just use them" in templates, with zero boilerplate. You also don't have to mock imports in unit te…

> I don't personally have a problem with ES Modules per se, but I do agree with the "I really dislike having to include every last identifier that exists in other files" part. Isn't this exactly the problem that esm's namespace import feature solves?

Not really. I elaborated more in the rest of the message.

IMO the language is fine, and imports are fine too, but the way they're used in popular frameworks isn't good programming. Again, IMO.

My problem is with the excess of transitive dependencies in JS files as a programming style, even though the language supports other more modern idioms just fine. It's the classic Banana-gorilla-jungle problem, to quote Joe Armstrong. One component depends directly via imports on dozens of others, and it can't be separated. This specific style needs lots of compilation trickery to mocking imports in unit tests, for example. It's like Java or C++ in the 90s: zero independency and maximum coupling of everything, killing all portability and reusability.

Every React component directly depends on React, for example. This was a design decision, and is not strictly necessary, from first principles. This is IMO bit of a regression in terms of framework design. Like I said, with injection this would be unnecessary.

IMO one doesn't need "dependency injection everywhere" or "interfaces everywhere" (like 2010s Java, which is also not good), but when you have such a good and simple abstraction like "components" in React or Vue, it is a bit of a waste IMO to not use them and just use the imports-everywhere strategy.

Vue got it right, IMO, with "global" components for example. But this is also shunned by the community (even though it is used a lot by the authors of Vue and authors of libraries).

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

#126

Post by throwitaway1123 »

whstl wrote: post #125
throwitaway1123 wrote: post #123

Earlier quoted context omitted.

> I don't personally have a problem with ES Modules per se, but I do agree with the "I really dislike having to include every last identifier that exists in other files" part. Isn't this exactly the problem that esm's namespace import feature solves?

Not really. I elaborated more in the rest of the message. IMO the language is fine, and imports are fine too, but the way they're used in popular frameworks isn't good programming. Again, IMO. My problem is with the excess of transitive dependencies in JS files as a programming style, even though the language supports other more modern idioms just fine. It's the classic Banana-gorilla-jungle problem, to quote Joe Arm…

You're editing your comment very frequently, so I'll reply to it as it appears to me right now.

> IMO the language is fine, and imports are fine too, but the way they're used in frameworks isn't the best.

Ok so I think we're talking about two different things. The RawJS author was saying that he doesn't like es modules as a language feature because he has to separately import each identifier from a package. I was pointing out that you don't have to import each identifier separately, you can simply use the 'import * as identifier from "package"' syntax (es module namespace imports).

You seem to be talking about a separate issue (dependency injection).

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

#127

Post by whstl »

throwitaway1123 wrote: post #126
whstl wrote: post #125

Earlier quoted context omitted.

Not really. I elaborated more in the rest of the message. IMO the language is fine, and imports are fine too, but the way they're used in popular frameworks isn't good programming. Again, IMO. My problem is with the excess of transitive dependencies in JS files as a programming style, even though the language supports other more modern idioms just fine. It's the classic Banana-gorilla-jungle problem, to quote Joe Arm…

You're editing your comment very frequently, so I'll reply to it as it appears to me right now. > IMO the language is fine, and imports are fine too, but the way they're used in frameworks isn't the best. Ok so I think we're talking about two different things. The RawJS author was saying that he doesn't like es modules as a language feature because he has to separately import each identifier from a package. I was poi…

Yes, I edited it as I went to make it more clear.

> The RawJS author was saying that he doesn't like es modules as a language feature [...] You seem to be talking about a separate issue (dependency injection).

Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't. But I dislike the abuse of the feature, and frameworks that force its use.

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

#128

Post by jakelazaroff »

Py_ wrote: post #88
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

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.

I see. I don’t really agree with lumping everything else into “yet another tool”:

- The marginal cost of adding a second tool to your build step is generally lower than adding a build step in the first place

- Tools like esbuild give you both TypeScript compilation and bundling out of the box with zero extra dependencies, so you don’t actually need to add an extra tool to your workflow

- Tools like Vite technically do include extra tools but hide the complexity from you, so from your perspective it’s just a single tool

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

#129

Post by throwitaway1123 »

whstl wrote: post #127
throwitaway1123 wrote: post #126

Earlier quoted context omitted.

You're editing your comment very frequently, so I'll reply to it as it appears to me right now. > IMO the language is fine, and imports are fine too, but the way they're used in frameworks isn't the best. Ok so I think we're talking about two different things. The RawJS author was saying that he doesn't like es modules as a language feature because he has to separately import each identifier from a package. I was poi…

Yes, I edited it as I went to make it more clear. > The RawJS author was saying that he doesn't like es modules as a language feature [...] You seem to be talking about a separate issue (dependency injection). Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't. But I dislike the abuse of the feature, and frameworks that force its use.

> Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't.

But you also quoted a criticism of ES Modules and explicitly said "I do agree". That's the part that threw me off. The commenter you were quoting (and agreeing with) wasn't talking about dependency injection. Earlier in the thread he said "I admittedly have a visceral hatred for ES modules", and this was him listing his grievances. Dependency injection and ES Modules are completely orthogonal.

I think your other comment where you admit that this is off topic was a more straightforward statement of your position, because you didn't quote (or purport to agree with) an unrelated argument [1].

[1] https://news.ycombinator.com/item?id=38865550

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

#130

Post by whstl »

throwitaway1123 wrote: post #129
whstl wrote: post #127

Earlier quoted context omitted.

Yes, I edited it as I went to make it more clear. > The RawJS author was saying that he doesn't like es modules as a language feature [...] You seem to be talking about a separate issue (dependency injection). Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't. But I dislike the abuse of the feature, and frameworks that force its use.

> Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't. But you also quoted a criticism of ES Modules and explicitly said "I do agree". That's the part that threw me off. The commenter you were quoting (and agreeing with) wasn't talking about dependency injection. Earlier in the thread he said "I admittedly have a visceral hatred for ES modules", and this was him listing…

Well, sorry for throwing you off, then. That's why I was verbose with my edits: to ensure there was no misunderstanding. Hope all is clear now.
Post reply on HN