21 ms·

I feel you about the inadequacies and oddities of JS, HTML, and CSS, but who's going to engineer this clean break with the past? What entity or entities are co

by ble 13y ago

I feel you about the inadequacies and oddities of JS, HTML, and CSS, but who's going to engineer this clean break with the past? What entity or entities are cohesive enough in purpose and broad enough in interest to produce something that could ever hope to rival the existing, impressive-if-frequently-kludgy, broadly-installed functionality of the web platform? What is so broken ("broken"-broken, not just "hard to do correctly", "inconvenient", or "inconsistent") about JS/HTML/CSS? You bring up general software development, so I want to say: "custom elements defined with HTML templates rendered in a shadow dom" must just sound like layering crazy on crazy, but it's actually a really old-school idea: encapsulation. Encapsulate the HTML structure, the CSS that styles it, and the Javascript that adds behavior and/or fully elaborates the structure into a single thing and maybe some of the crazy can be controlled.

Silhouette 13y ago
it's actually a really old-school idea: encapsulation And that in itself is great. But the applicability of that encapsulation seems very limited in the current proposals. Effectively, everything is still tied back to the DOM, but there is a lot more to serious applications than drawing stuff on the screen, so unless we're going to keep doing all of that server-side... Also, you need two key things for modular design to work: ways to build modules, and controlled ways to connect them together. I'm rather sceptical about whether Web Components are going to live up to the hype in this respect, because while you might have a new tool for encapsulation to help with the "building" part, you're still ultimately relying on JavaScript to connect up the behaviour for these new components and on CSS to connect their visual appearance to the rest of your design, with no new composition tools to make like easier in either case. I can understand the motivation for some parts of Web Components, such as the Shadow DOM, but a lot of it just feels like a marginal improvement on things we already have. After all, it's not as if I can't Google 47 different libraries that will turn a <div> into a set of tabs or a carousel right now, and they all come with a handy JS interface for connecting the rest of my code into the behaviour of that page element, and they all come with styling hooks or theme builders for me to configure the aesthetics. Am I really going to achieve some huge productivity or maintainability boost if I use a custom element instead of a <div> and I read the docs on that custom element's JS and CSS hooks instead of the ones from some UI library like the ones we've been building for the past 5-10 years?

by ble 13y ago

Silhouette 13y ago

it's actually a really old-school idea: encapsulation And that in itself is great. But the applicability of that encapsulation seems very limited in the current proposals. Effectively, everything is still tied back to the DOM, but there is a lot more to serious applications than drawing stuff on the screen, so unless we're going to keep doing all of that server-side... Also, you need two key things for modular design to work: ways to build modules, and controlled ways to connect them together. I'm rather sceptical about whether Web Components are going to live up to the hype in this respect, because while you might have a new tool for encapsulation to help with the "building" part, you're still ultimately relying on JavaScript to connect up the behaviour for these new components and on CSS to connect their visual appearance to the rest of your design, with no new composition tools to make like easier in either case. I can understand the motivation for some parts of Web Components, such as the Shadow DOM, but a lot of it just feels like a marginal improvement on things we already have. After all, it's not as if I can't Google 47 different libraries that will turn a <div> into a set of tabs or a carousel right now, and they all come with a handy JS interface for connecting the rest of my code into the behaviour of that page element, and they all come with styling hooks or theme builders for me to configure the aesthetics. Am I really going to achieve some huge productivity or maintainability boost if I use a custom element instead of a <div> and I read the docs on that custom element's JS and CSS hooks instead of the ones from some UI library like the ones we've been building for the past 5-10 years?