4 ms·

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 convin

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: <div onClick="alert('Hello World')" style="{padding:100px;background:red}"></div> 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.

tomhallett 3y ago
To me the usescase feels like: I am using Hotwire/htmx. When I need more complex behavior, instead of using stimulus/apline/hyperscript, you can make custom webcomponents which use rawjs for the rendering.
Py_ 3y ago
RawJS library author here. $.append appends, in the name ".append". Though The point of RawJS is to help with element constructions. jQuery was a god-send back in the day for manipulation and querying (before we had document.querySelector()) but constructions of hierarchies were never really its thing. There are other libraries that work like RawJS to make complex DOM constructions with function calls. I just don't think the ergonomics of them were as well thought-out as it is in RawJS.
- vasyop 3y ago
  I think the main reason why small things like rawJS are appealing is that a lot of devs got directly or indirectly forced into learning a framework and then got themselves burned one way or another while using it. We then developed a shared fantasy: "What if the native browser API was good enough so that we don't have to learn any fluff (frameworks, build tools, libs) to be productive? After all, other languages don't have this framework bloat problem. Let's just use this minimal lib instead." But this is just a fantasy. Element constructions are not the problem. Updating the state and DOM is the issue. We don't do stuff like rawJS or jQuery for bigger apps because they are too low-level and they don't scale well. What we need is to operate at a higher level, not get rid of almost all of the abstractions entirely like rawJS. Have a look at https://github.com/squaresapp/rawjs-sample/blob/35939695dba63698d581defb8ce171ba90b5c71f/src/SegmentedButtonComponent.ts#L90 https://github.com/squaresapp/rawjs-sample/blob/35939695dba6.... This is the kind of code that is meaningless to my app. It's just DOM housekeeping. The example app is small enough so that there isn't much of it: this is the only interactive bit of your demo app. But the bigger the app, the more housekeeping like this you need. Try to showcase a bigger demo app with a lot of interaction. Now, there are specific cases where I don't want/need a framework. If I want better performance, the framework can become a hindrance (this is generally the case - when you want performance, you need to look at the lower levels). If the app is tiny, frameworks are just fluff. But for the overwhelming majority of cases (apps that are not tiny and don't need amazing performance): As a web dev, I want to assign some object to some reference and then my app to be updated based on my state. When some event happens, I want to update some of the app state. That's it! I don't want to mix my business logic with DOM fluff. I don't need another piece of code to worry about. I want some dependency to do that for me. Is it going to happen via virtual DOM or change detection or something else? Who knows.
pests 3y ago
> 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.
tambourine_man 3y ago
> 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.
- xigoi 3y ago
  The technical reason is that jQuery increases the size of your page by a lot without really adding much benefit.

tomhallett 3y ago

To me the usescase feels like: I am using Hotwire/htmx. When I need more complex behavior, instead of using stimulus/apline/hyperscript, you can make custom webcomponents which use rawjs for the rendering.

Py_ 3y ago

RawJS library author here. $.append appends, in the name ".append". Though The point of RawJS is to help with element constructions. jQuery was a god-send back in the day for manipulation and querying (before we had document.querySelector()) but constructions of hierarchies were never really its thing. There are other libraries that work like RawJS to make complex DOM constructions with function calls. I just don't think the ergonomics of them were as well thought-out as it is in RawJS.

vasyop 3y ago
I think the main reason why small things like rawJS are appealing is that a lot of devs got directly or indirectly forced into learning a framework and then got themselves burned one way or another while using it. We then developed a shared fantasy: "What if the native browser API was good enough so that we don't have to learn any fluff (frameworks, build tools, libs) to be productive? After all, other languages don't have this framework bloat problem. Let's just use this minimal lib instead." But this is just a fantasy. Element constructions are not the problem. Updating the state and DOM is the issue. We don't do stuff like rawJS or jQuery for bigger apps because they are too low-level and they don't scale well. What we need is to operate at a higher level, not get rid of almost all of the abstractions entirely like rawJS. Have a look at https://github.com/squaresapp/rawjs-sample/blob/35939695dba63698d581defb8ce171ba90b5c71f/src/SegmentedButtonComponent.ts#L90 https://github.com/squaresapp/rawjs-sample/blob/35939695dba6.... This is the kind of code that is meaningless to my app. It's just DOM housekeeping. The example app is small enough so that there isn't much of it: this is the only interactive bit of your demo app. But the bigger the app, the more housekeeping like this you need. Try to showcase a bigger demo app with a lot of interaction. Now, there are specific cases where I don't want/need a framework. If I want better performance, the framework can become a hindrance (this is generally the case - when you want performance, you need to look at the lower levels). If the app is tiny, frameworks are just fluff. But for the overwhelming majority of cases (apps that are not tiny and don't need amazing performance): As a web dev, I want to assign some object to some reference and then my app to be updated based on my state. When some event happens, I want to update some of the app state. That's it! I don't want to mix my business logic with DOM fluff. I don't need another piece of code to worry about. I want some dependency to do that for me. Is it going to happen via virtual DOM or change detection or something else? Who knows.

pests 3y ago

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

tambourine_man 3y ago

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

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