Readit Newsdxchester commented on If Web Components are so great, why am I not using them? daverupert.com/2023/07/wh... · Posted by u/emegeve83
The main reason is that they're too low-level to use directly.
They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding.
Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer:
https://github.com/dchester/yhtml
It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like...
<button @click="increment">${this.count}</button>
If we could get something in this direction adopted into the spec, it would open up a lot of use cases for Web Components that it just can't address as-is.
Nice writeup. We're working on a framework with similar goals, here: https://github.com/frameable/el
Reactivity, composability, templates, etc with no dependencies, in ~150 SLOC.
Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation.
I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me.
I'm happy that other people seem to enjoy them without restraint, but obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality.
I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years.
I think having seen front-end software come and go so many times, I'd rather write some simple utility functions wrapping `Document.createElement()` and use native event handling.
Too much fluff in front-end.
I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.
Agreed that investing in standards is always a good bet. But at the same time, we have so many web frameworks in part because what is spec'd in plain JavaScript/HTML/CSS is not quite high-level enough to be really be a productive foundation just on its own. Going all the way back to raw `Document.createElement` will come with its own special pain.
With the WebComponents movement though, we are getting ever closer to being able to rely on native browser functionality for a good share of what frameworks set out to do. We're not all the way to bliss without frameworks, but for what it's worth here is my 481-byte library to support template interpolation with event binding in order to make WebComponents pretty workable mostly as-is: https://github.com/dchester/yhtml
dxchester commented on Modern SPAs without bundlers, CDNs, or Node.js kofi.sexy/blog/modern-spa... · Posted by u/kofigumbs
I also sometimes enjoy this approach of starting from absolutely nothing.
Instead of taking the path of starting with DOM manipulation and then going to a framework as necessary, I've kept really trying to make raw web components work, but kept finding that I wanted just a little bit more.
I managed to get the more I wanted -- sensible template interpolation with event binding -- boiled down to a tag function in 481 bytes / 12 lines of (dense) source code, which I feel like is small enough that you can copy/paste it around and not feel to bad about it. It's here if anyone cares to look: https://github.com/dchester/yhtml
We have used Automerge a bunch, but found that there is a threshold where beyond a given document size, performance gets exponentially worse, until even trivial updates take many seconds' worth of CPU. That is often how it works when the document end state is exclusively the sum of all the edits that have ever happened.
Our answer was to reimplement the Automerge API with different mechanics underneath that allows for a "snapshots + recent changes" paradigm, instead of "the doc is the sum of all changes". That way performance doesn't have to degrade over time as changes accumulate.
Project is here: https://github.com/frameable/pigeon, with some benchmarks: https://github.com/frameable/pigeon/wiki/Benchmarks in the wiki...
dxchester commented on The Evolution of Scalable CSS frontendmastery.com/posts... · Posted by u/remrem
> The Evolution of Scalable CSS
The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? They are the next step in the evolution of scalable CSS, and yet they are noticeably absent from the discussion.
We wrote about our journey[0] to sanity after Tailwind:
The answer is to do it all in strategic moderation: Use a subset of tailwind just for spacing and layout and revel in simple things being simple. Use modular CSS for UI patterns and revel in the readability of your HTML and visual consistency of your UI. And then use custom scoped CSS where required, and revel in interesting things being only as hard as need be, without ruining everything else along the way.
[0]: https://frameable.com/company/tech/how-we-found-sanity-in-a-...
dxchester commented on Show HN: I made a CMS that uses Git to store your data Outstatic.com... · Posted by u/AndreVitorio
This sounds cool. We wrote a git-based CMS[0] that is a little different. It has a nice-enough UI for creating and editing markdown documents, which are stored in git. And then it has a JSON API so that your main site can fetch the content and style / format however it likes. Users log in with OAuth or local passwords and their edits end up as git commits that are attributed to them.
WebComponents give us so much, but just not quite enough to be usable on their own without a little bit more on top. Reactivity with observable store and templating with event binding are the big missing pieces.
[0]: https://github.com/frameable/el