101–110 of 715 posts
Earlier quoted context omitted.
Imagine 50 years ago: “Data passing seems inherently broken in Unix, because all processes must use strings for input and output. Such a model just can't be built on top of.”
Show me a successful GUI made with bash.
Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely. I run sites that serve hundreds of millions per day a…
>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework. I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to u…
But you're not wrong about there being many ways to write components and manage state.
And RSC is a mess. But thankfully you can keep pretending that doesn't exist.
Earlier quoted context omitted.
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
You can invoke custom methods and pass in any kind of data into them. As in class SomeElement extends HTMLElement { constructor() { super(); } someMethod(x) { this.innerHTML = ` ${x} `; } } // ignore registry stuff const customElement = document.getElementById('custom-element-id'); customElement.someMethod(42); But you won't learn that from most mainstream custom element tutorials though, for whatever reason.
Note that you can make things even simpler than this: just use vanilla JS to compose HTML strings, and plug them into divs using innerHTML = "...". When your state changes due to user input, just rebuild the page using the new data. I've been building many simple apps using this technique, it works fine. I'm sure there is some kind of performance hit; it's almost never an issue. I have never seen any browser compatib…
if (!this.#span)
Earlier quoted context omitted.
I remember when web components first came out and there was some hype around them, and just being really confused on what they're actually good for. I think it's really telling that since web components came out there's never been a popular framework, website, or company that has heavily leveraged them.
What about Lit?
This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as declarative function of state, with the help of components. That's why we use those frameworks. Web components don't solve the state management problem.
State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.
Even something simple like a date picker. Where are you going to store which month you're looking at?
There's state everywhere, and we should not be sending it all back and forth to the server.
From https://plainvanillaweb.com/pages/components.html I see this piece: if (!this.#span) What is that kind of magic syntax sugar?! A shorthand for document.getElementById?
Earlier quoted context omitted.
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
You can invoke custom methods and pass in any kind of data into them. As in class SomeElement extends HTMLElement { constructor() { super(); } someMethod(x) { this.innerHTML = ` ${x} `; } } // ignore registry stuff const customElement = document.getElementById('custom-element-id'); customElement.someMethod(42); But you won't learn that from most mainstream custom element tutorials though, for whatever reason.
Fine for x:string, but what about w:WebWorker?