4 ms·

I think we should stop talking about libraries and talk about the crap of browser specs. Libraries are just a tool and evolve over the years. but browsers are g

I think we should stop talking about libraries and talk about the crap of browser specs. Libraries are just a tool and evolve over the years. but browsers are getting worse every year

eyelidlessness 4y ago
Asking sincerely because this take is surprising to me: which specs are you referring to? From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience. I’m not saying your take is wrong necessarily, I just don’t immediately relate to it and I’m curious what specifically you find objectionable.
- spiffytech 4y ago
  > Asking sincerely because this take is surprising to me: which specs are you referring to? I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
  - eyelidlessness 4y ago
    I haven’t worked with web components, and have only had a passing interest generally. But oddly enough I took some time today to dive deeper. It occurred to me that some of the APIs would potentially benefit some work I’m doing in a legacy project. I’m not an expert on the topic, but I have a few thoughts. First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said, > no API for passing non-string attributes to other web components This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this. > no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse. > Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework. I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship. 1: https://developer.mozilla.org/en-US/docs/Web/API/Element/part https://developer.mozilla.org/en-US/docs/Web/API/Element/par...

I think we should stop talking about libraries and talk about the crap of browser specs. Libraries are just a tool and evolve over the years. but browsers are getting worse every year

eyelidlessness 4y ago

Asking sincerely because this take is surprising to me: which specs are you referring to? From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience. I’m not saying your take is wrong necessarily, I just don’t immediately relate to it and I’m curious what specifically you find objectionable.

spiffytech 4y ago
> Asking sincerely because this take is surprising to me: which specs are you referring to? I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
- eyelidlessness 4y ago
  I haven’t worked with web components, and have only had a passing interest generally. But oddly enough I took some time today to dive deeper. It occurred to me that some of the APIs would potentially benefit some work I’m doing in a legacy project. I’m not an expert on the topic, but I have a few thoughts. First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said, > no API for passing non-string attributes to other web components This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this. > no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse. > Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework. I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship. 1: https://developer.mozilla.org/en-US/docs/Web/API/Element/part https://developer.mozilla.org/en-US/docs/Web/API/Element/par...