4 ms·

> - today, going back as much as possible to vanilla JavaScript Javascript =/= the DOM. All your frameworks are DOM abstractions, not Javascript abstraction, u

> - today, going back as much as possible to vanilla JavaScript Javascript =/= the DOM. All your frameworks are DOM abstractions, not Javascript abstraction, unless you are using Typescript or Reason (or Turbo links on the server). You're still writing Javascript code with knockout and angular and co, you're just not using the DOM directly. Talking about "vanilla javascript" in the context of these frameworks never made sense to me. tangential: Javascript is not the DOM and people use frameworks because they hate DOM manipulation. We "didn't need jquery", or so someone said, but now it seems like we sure need all these frameworks somehow and people don't learn the DOM anymore. How is it any better than jQuery? it isn't...

TrickardRixx 5y ago
I'm not sure I understand your point here. I would say I "hate writing javascript", but I think the point you're making is I "hate DOM manipulation". These days I use htmx[0] wherever possible. Notably htmx is still javascript; I just don't have to write it. htmx should still count as DOM manipulation and I love it. I just hate all the other methods of DOM manipulation that required me to write javascript. So what is the difference in the distinction you're making? [0] https://htmx.org/ https://htmx.org/
- mmcnl 5y ago
  Frameworks like React and Vue allow me to define the UI as a function of state in a declarative way. The language happens to be JS. Please tell me how this can be done in vanilla JS without writing my own framework. I don't think it's possible. In my opinion they are not comparable, they both serve different goals.
  - TrickardRixx 5y ago
    Thank you for the clarification. I definitely agree with you. Unfortunately for me, I still dislike using the declarative frameworks that happen to be in JS.
mhitza 5y ago
> Javascript =/= the DOM My post was explicit in the fact that this was my frontend JavaScript path. I don't think they are DOM abstraction, rather they are "update abstractions", as all the data binding, two way bindings, (whatever way binding a future library might call it) is there to observe X, update piece of html fragment Y with X. The vanilla JavaScript idea is to debloat application and unlayer complexity where its possible. It doesn't offer the niceties, or feature parity of what frameworks do, but it allows me to be more explicit in the places where I'm going to use a framework. E.g. might have handrolled JavaScript code for light interactivity for a website for 90% of the time, and going to use something like VueJS only on the pages that require some highly integrated state associated page components. The people in my circles, didn't hate DOM manipulation. They just didn't understand it (or care to), and jQuery answers where all over stackoverflow (just use this library and this jQuery plugin call). And yes, without jQuery/frameworks DOM building is tedious. I've seen JSX praised before, but in an alternate timeline where IE didn't dominate the entire world with a legacy PoS, maybe the E4X standard would have been implemented in all browsers. Which would have been a pretty sweet deal, and another useful tool for the vanilla JavaScript camp.

TrickardRixx 5y ago

I'm not sure I understand your point here. I would say I "hate writing javascript", but I think the point you're making is I "hate DOM manipulation". These days I use htmx[0] wherever possible. Notably htmx is still javascript; I just don't have to write it. htmx should still count as DOM manipulation and I love it. I just hate all the other methods of DOM manipulation that required me to write javascript. So what is the difference in the distinction you're making? [0] https://htmx.org/ https://htmx.org/

mmcnl 5y ago
Frameworks like React and Vue allow me to define the UI as a function of state in a declarative way. The language happens to be JS. Please tell me how this can be done in vanilla JS without writing my own framework. I don't think it's possible. In my opinion they are not comparable, they both serve different goals.
- TrickardRixx 5y ago
  Thank you for the clarification. I definitely agree with you. Unfortunately for me, I still dislike using the declarative frameworks that happen to be in JS.

mhitza 5y ago

> Javascript =/= the DOM My post was explicit in the fact that this was my frontend JavaScript path. I don't think they are DOM abstraction, rather they are "update abstractions", as all the data binding, two way bindings, (whatever way binding a future library might call it) is there to observe X, update piece of html fragment Y with X. The vanilla JavaScript idea is to debloat application and unlayer complexity where its possible. It doesn't offer the niceties, or feature parity of what frameworks do, but it allows me to be more explicit in the places where I'm going to use a framework. E.g. might have handrolled JavaScript code for light interactivity for a website for 90% of the time, and going to use something like VueJS only on the pages that require some highly integrated state associated page components. The people in my circles, didn't hate DOM manipulation. They just didn't understand it (or care to), and jQuery answers where all over stackoverflow (just use this library and this jQuery plugin call). And yes, without jQuery/frameworks DOM building is tedious. I've seen JSX praised before, but in an alternate timeline where IE didn't dominate the entire world with a legacy PoS, maybe the E4X standard would have been implemented in all browsers. Which would have been a pretty sweet deal, and another useful tool for the vanilla JavaScript camp.