Web components are honestly the first time I have seen web stuff in years and thought "that actually looks nice".
Maybe it's time for me to crawl out of my systems-software-only hole and play around with the web again.
Plain Vanilla Web
211–220 of 715 posts
Re: Plain Vanilla Web
#212I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being…
Web Components don't solve the problems I do have and add new problems I don't want.
Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only be used in my app.
Re: Plain Vanilla Web
#213Earlier quoted context omitted.
This is just a lie perpetuated by the React team 10 years ago All HTML elements are JavaScript objects that have properties. You can pass arbitrary data to custom elements via those properties. Look at any modern HTML template system and you'll see the ability to pass data to properties declaratively.
Well it's not a lie, it's how HTML and the DOM work. Attributes are strings, and what you write in HTML will be passed as attributes. You do also have access to properties, but only in Javascript — you can't for example write something like ` `. That means that if you need to pass around complex data types, you need to either manipulate the DOM objects directly, or you need to include some sort of templating abstract…
It is absolutely a lie, because web components can handle arbitrary data just at much as any framework.
You're holding web components to a higher standard here in expecting them to take arbitrary data in HTML when HTML itself doesn't support arbitrary data. Notably you can't assign arbitrary data to framework components from within HTML either, so how are web components any more limited?
Re: Plain Vanilla Web
#214I don't find WebComponents a good replacement for what in other web frameworks are called components. For one thing they don't support complex values like Objects and Arrays as attributes. The amount of boilerplate you have to write is way too high, and you still don't have reactivity. I do vanilla-ish JS using signals[1]. Not everything the W3C releases should be canon, XHTML is a testament to that.
Re: Plain Vanilla Web
#215Earlier quoted context omitted.
I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requi…
We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies. Not saying frameworks are never the right answer of course, but it's as much a trade-off for complex apps as it is for blogs. Things like performance, bundle size, tooling complexity, easy of debugging and call stack depth, API stability, risk of hitting hard-to-work-around constraints all matter at scale too. [1]…
Agreed that it's a trade-off. In your case I probably would have made the same call. Again, though: that's why use cases matter. Web app/blog is only one dichotomy—the most common two types of web dev but far from the only.
Re: Plain Vanilla Web
#216Earlier quoted context omitted.
As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…
> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…
There’s a hidden cost in web applications as well: you lose the value of the operating systems application language. Every website and thus electron app suffers from this. There’s no standard place for settings, buttons and windows don’t behave normally. There’s a lot of value in native apps in usability just in it sharing the same UX language as the operating system. Sadly this is mostly dead for new applications.
Re: Plain Vanilla Web
#217This is a great resource.
IMHO everyone building for the web should understand how it works and know how to use the foundational web stack, leveraging the web platform per se. Then, by all means use a build system and your preferred frameworks at your discretion, remaining aware of tradeoffs.
For my part, one of the things I like best about Remix (/React-router v7+) is its explicit philosophical alignment with leveraging web standards and doing more by doing less (e.g. mutate server data using... the HTML form tag).
I also highly recommend https://every-layout.dev which showcases eye-opening, mind-expanding techniques for implementing performant, accessible, flexible web layouts using only browser-native CSS.
Context: I've been professionally involved with web development since 1998.
Re: Plain Vanilla Web
#218Earlier quoted context omitted.
Could you explain what you mean by "storing it in a variable"? It's perfectly fine to store data in a variable (that's what most frameworks do in the end), but that state needs to be reactive in some way — updating that state needs to trigger the necessary UI changes (and ideally in such a way that the entire component isn't being regenerated every time the state changes). This is what makes state management so hard.
Maybe I'll write a blog post on it someday. It depends on the exact method you use to build the calendar my man. You could just change classes and attributes. Or you could use a variable within the scope of where you initialize the component. I wouldn't re-render the whole thing to apply changes, but that's up to you. The nice thing about using vanilla APIs is you don't typically have to worry about thrashing the DOM…
Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems.
The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input is another string, what state should you store here? Fundamentally, there's only one thing that's interesting: the input's value. Anything else — say, the class used to set the background colour — is derived from that value. And therefore we always want our data to flow in one direction: the input value is the source, and any other state or UI updates are based on that.
But in practice, it's usually hard to maintain that strict flow of data. For example, you'll probably have multiple sources that combine in different ways to create different derived data. Or you might have multiple different ways of updating those sources that all need to perform the same updates to the derived data. Or you might have multiple levels of derived data.
It's definitely possible to build applications like this — I started out this way, and still use this for simple projects where the state is fairly easy to manage. But as projects get more complex — and as the state gets more complex — it almost invariably leads to weird glitches and broken states that shouldn't exist. Hence why state management is the core of most modern frameworks — it's the most important problem to solve.
N.B. `useMemo` in React has nothing to do with the DOM — React will never thrash the DOM with unnecessary changes, that's the point of the diffing process. `useMemo` is instead about reducing the number of times that React builds its own VDOM nodes.
Re: Plain Vanilla Web
#219I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being…
I think it’s time to go back to Unobtrusive JavaScript. What is needed for this are lightweight libraries or practices you can code yourself. HTMX is lightweight which is nice but it’s like script tags. I would rather the urls and methods go in plain HTML and stuff like hx-target be determined by JavaScript, using data- attributes if needed. That way all the unused HTMX features aren’t included.
Re: Plain Vanilla Web
#220I don't find WebComponents a good replacement for what in other web frameworks are called components. For one thing they don't support complex values like Objects and Arrays as attributes. The amount of boilerplate you have to write is way too high, and you still don't have reactivity. I do vanilla-ish JS using signals[1]. Not everything the W3C releases should be canon, XHTML is a testament to that. [1] https://wrnr…
See also:
Meiosis Pattern: https://meiosis.js.org/docs/01-introduction.html
Mithril: https://mithril.js.org/