4 ms·

Excellent list and examples. Browsing through a dozen or so of these I'm amazed at the care and detail in the examples. They are not only functional, but provid

by snide 3y ago

Excellent list and examples. Browsing through a dozen or so of these I'm amazed at the care and detail in the examples. They are not only functional, but provide very solid UI work as well. As I've shifted away from platforms like React to smaller, minimalist implementations, I often have trouble finding ways for how to do complex patterns in standard JS. It's funny when you look at the code and think... huh, that's actually a lot easier than importing a huge library with way too many props :) Thanks to the author for putting this together.

bob1029 3y ago
> It's funny when you look at the code and think... huh, that's actually a lot easier than importing a huge library with way too many props I had this realization after the 3rd or 4th RiotJS major version update. It started getting harder to do it the opinionated way. I realized that every minimalistic JS framework would eventually suffer this fate as totally innocent feature requests gradually accumulate into a monstrous pile of hooks, events and other side-effect bandaids. I don't even use jQuery anymore. I will use things like ES modules to help organize code, but you don't need to run a goddamn npm command to use any of that technology. All of this is a global browser standard, not something you have to vendor in. I look at MDN as the Bible these days. If you take a leap of faith, it will carry you almost 100% of the way. The frameworks will cripple you after a certain point. I can't say this would have been true ~5 years ago. Things have shifted rapidly with browser APIs converging on a powerful set of primitives (modules, flexbox, grid, etc) that are now very consistent across platforms.
- reactordev 3y ago
  I like the fact that you said “I can’t say this would have been true ~5 years ago”. React et al. exist because there weren’t global standards around these things and composability suffered. Now that we are all playing the same chorus, these frameworks provide little more than component libraries to reuse. This can be done with ES modules. JSX is why most React folks stick with React, not knowing they can use Preact or just NakedJSX if they wish. I just wanted to verbally concur that vanilla JS is more than capable of doing everything you need. Custom tags. Shadow dom. Composed UI. etc. if you are ok with returning HTMLElement vs a JSX closure.
  - snide 3y ago
    And this is absolutely true in CSS now as well. I find a lot of people are needing to rediscover the standards now that they've upped their featuresets.
    - paradox460 3y ago
      I even wrote a small article about it at the end of last month: https://pdx.su/blog/2023-10-25-css-is-fun-again https://pdx.su/blog/2023-10-25-css-is-fun-again
  - irrational 3y ago
    I though React, et al were originally created as a better way to manage DOM updates (shadow DOM). Has that need gone away?
    - evan_ 3y ago
      React et al use a virtual DOM, not shadow DOM (unless you specifically render it to shadow DOM). They are a better* way to manipulate DOM in that you no longer need to manipulate the DOM, you just build a function that returns what the DOM should look like and it figures out what transforms need to happen. *They’re pitched as a better way, and I think it’s better, but people can reasonably disagree
    - nicoburns 3y ago
      Not at all. Without React (or a similar framework) you are still left with the options of: - Manually keep track of UI state (which is complex, and often leads to hard to maintain spaghetti code) - Recreate an entire DOM tree every time you re-render (which is slow to the extent that it will often lead to performance problems in practice). Apparently this is not as slow as it used to (so you could probably get away with this sometimes - and you could before), but it's still generally a better idea to use a framework as you get better performance for very low cost. There are plenty of non-React frameworks that will you these benefits too. And many of them are much smaller. I think the reason to use React specifically is more "business reasons" such assurances that the framework will continue to be maintained, library ecosystem, developer pool, etc. Other frameworks are often technically superior, the difference just isn't that great.
- deleted 3y ago
  [deleted]
hombre_fatal 3y ago
Nothing in TFA competes with a web client framework, though, since the framework is solving the general questions of how to manage state and then update the UI when state changes. For example, pretty much all of the TFA examples are code you'd have to write even if you were using React.

by snide 3y ago

bob1029 3y ago

> It's funny when you look at the code and think... huh, that's actually a lot easier than importing a huge library with way too many props I had this realization after the 3rd or 4th RiotJS major version update. It started getting harder to do it the opinionated way. I realized that every minimalistic JS framework would eventually suffer this fate as totally innocent feature requests gradually accumulate into a monstrous pile of hooks, events and other side-effect bandaids. I don't even use jQuery anymore. I will use things like ES modules to help organize code, but you don't need to run a goddamn npm command to use any of that technology. All of this is a global browser standard, not something you have to vendor in. I look at MDN as the Bible these days. If you take a leap of faith, it will carry you almost 100% of the way. The frameworks will cripple you after a certain point. I can't say this would have been true ~5 years ago. Things have shifted rapidly with browser APIs converging on a powerful set of primitives (modules, flexbox, grid, etc) that are now very consistent across platforms.

reactordev 3y ago
I like the fact that you said “I can’t say this would have been true ~5 years ago”. React et al. exist because there weren’t global standards around these things and composability suffered. Now that we are all playing the same chorus, these frameworks provide little more than component libraries to reuse. This can be done with ES modules. JSX is why most React folks stick with React, not knowing they can use Preact or just NakedJSX if they wish. I just wanted to verbally concur that vanilla JS is more than capable of doing everything you need. Custom tags. Shadow dom. Composed UI. etc. if you are ok with returning HTMLElement vs a JSX closure.
- snide 3y ago
  And this is absolutely true in CSS now as well. I find a lot of people are needing to rediscover the standards now that they've upped their featuresets.
  - paradox460 3y ago
    I even wrote a small article about it at the end of last month: https://pdx.su/blog/2023-10-25-css-is-fun-again https://pdx.su/blog/2023-10-25-css-is-fun-again
- irrational 3y ago
  I though React, et al were originally created as a better way to manage DOM updates (shadow DOM). Has that need gone away?
  - evan_ 3y ago
    React et al use a virtual DOM, not shadow DOM (unless you specifically render it to shadow DOM). They are a better* way to manipulate DOM in that you no longer need to manipulate the DOM, you just build a function that returns what the DOM should look like and it figures out what transforms need to happen. *They’re pitched as a better way, and I think it’s better, but people can reasonably disagree
  - nicoburns 3y ago
    Not at all. Without React (or a similar framework) you are still left with the options of: - Manually keep track of UI state (which is complex, and often leads to hard to maintain spaghetti code) - Recreate an entire DOM tree every time you re-render (which is slow to the extent that it will often lead to performance problems in practice). Apparently this is not as slow as it used to (so you could probably get away with this sometimes - and you could before), but it's still generally a better idea to use a framework as you get better performance for very low cost. There are plenty of non-React frameworks that will you these benefits too. And many of them are much smaller. I think the reason to use React specifically is more "business reasons" such assurances that the framework will continue to be maintained, library ecosystem, developer pool, etc. Other frameworks are often technically superior, the difference just isn't that great.
deleted 3y ago
[deleted]

hombre_fatal 3y ago

Nothing in TFA competes with a web client framework, though, since the framework is solving the general questions of how to manage state and then update the UI when state changes. For example, pretty much all of the TFA examples are code you'd have to write even if you were using React.