Live data from Hacker News

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

squaresapp.org

111–120 of 135 posts

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

#111
post #95

Earlier quoted context omitted.

...yuck. The hilarious part to me is that every single thing this does could be done in one line of an angular template with massively less typing and opportunity for error. just a: Like, I know you want to create an element and blah blah...but if it takes your dev 4x longer to write it, why are you doing it? Ultimately, in the real world, all of this is devs trying to make bragging rights for reasons with no real co…

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.

Component frameworks are for doing exactly that, and they generally make it pretty easy, with no manual DOM manipulation required when state changes.

Rather than continue with my salty commentary, I suggest to anyone still reading to look at any other file in the example project and draw their own conclusions: https://github.com/squaresapp/rawjs-sample

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

#113

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…

> Sure, there's a reason why people moved away from jQuery

And after all these years, I can’t see a technical one. Especially if the answer is React.

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

#114
post #72

Earlier quoted context omitted.

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)

We can also use React for that–the issue is the bundle size and it does not appear to be designed to share the DOM. I would love to see these smaller libraries document the process and best practices for using them within otherwise vanilla environments.

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

#115
post #103
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 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 tests, you just inject them on an as-needed basis. To me this is 100x cleaner and simpler, there's no room for accidentally running a unit test that actually tests multiple components.

The "irony" is that people avoid them because of the name, but the ones called "global" are actually definitely not global :/

React could also benefit from something like that. The `import { createComponent }` part (which is hidden but must be added by Babel plugins) is the worst part of the framework, and is an obstacle to having cross-framework components that work in React/Preact/Mithril/Inferno/etc.

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

#116
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 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…

Off topic and unrelated to the discussion proper, but:

I really wish React had gone with "component factories" instead of `import ... from 'react'`.

This would not only allow for framework-agnostic components (so they could also work in Preact, Mithril, Inferno, etc, etc), it would also make the hooks implementation not dependent on global state.

For example:

    export default const Component = ({ createElement, useState }) => () => {
      ...
    }
Then you would only have to import from React from the entry point.

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

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

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.

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

#119

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…

> Sure, there's a reason why people moved away from jQuery And after all these years, I can’t see a technical one. Especially if the answer is React.

The technical reason is that jQuery increases the size of your page by a lot without really adding much benefit.

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

#120
post #76

Earlier quoted context omitted.

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.

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).
Post reply on HN