[HN Gopher] Web components are okay
___________________________________________________________________
Web components are okay
Author : keybits
Score : 168 points
Date : 2024-09-29 11:57 UTC (11 hours ago)
(HTM) web link (nolanlawson.com)
(TXT) w3m dump (nolanlawson.com)
| burcs wrote:
| I love web components and am bullish on them breaking us out of
| the current frontend hellscape we have created for ourselves. I
| was recently able to give a short talk on the future of frontend,
| and it seemed like a lot of other people are hopeful for a way
| out as well.
|
| As far as performance we built out a data table for our DB GUI
| that can load in hundreds of thousands of rows and the scrolling
| through is still buttery smooth.
|
| We actually are getting ready to release our web component
| library, it's a bit early and rough around the edges but would
| love to get some more eyes on it! www.astra-ui.com
| candiddevmike wrote:
| The only way to get out of the current front end hell IMO is if
| we get client side import:
|
| https://github.com/whatwg/html/issues/2791
| askonomm wrote:
| I mean <script type="module"></script> can do ECMAScript
| module imports.
| meiraleal wrote:
| That's a solved problem. You can create a custom element for
| that with some 5 lines of code. Or use one ready:
| https://github.com/justinfagnani/html-include-element
| PaulHoule wrote:
| And that's exactly what some people don't want!
| meiraleal wrote:
| Some people will never be happy
| arcbyte wrote:
| I'm aghast at the comments in that thread. They are truly
| asleep at the wheel.
|
| No wonder the front end is such a disaster with those
| mindsets running the show.
| stavros wrote:
| Why aren't web components there/more popular yet? They seem
| like a fantastic solution
| burcs wrote:
| The cynic in me wants to say it's because they aren't VC
| backed so there's no main catalyst driving them.
|
| I don't think a lot of people know about them, or if they do
| they have just heard about it in passing and have never
| actually used them.
|
| Whatever the reason is they have a marketing problem that's
| for sure.
| stavros wrote:
| Ah, well that's encouraging, if the tech itself is good, it
| means I can start using them more.
| j45 wrote:
| New developers follow social proof often instead of learning
| from first principles.
|
| Web Components are seriously cool and worth looking at.
| stavros wrote:
| Excellent, thank you!
| evilduck wrote:
| Social proof does tend to follow employment opportunities.
| If you're a new dev you don't have the luxury to make
| principled choices in technology, you're more worried about
| housing and food security and maybe paying back student
| loans. Asking new developers to trend-set the industry
| would be deeply unfair. If we want them to learn from first
| principles then entry level jobs should have first
| principles opportunities available.
| j45 wrote:
| I meant social proof like prejudice against technologies
| that employ but don't seem popular and cool.
|
| Another confusion might be expecting an employer to
| educate you. That's part of it but not the requirement.
|
| Self-directed learning is critical to go with any formal
| learning.
|
| First principles are needing to be taught where or before
| people are learning things like react. But they don't,
| and get pulled into a world of complexity.
| pfraze wrote:
| Web Components have some nice features, some bad features,
| and no killer feature. Developers have mostly chosen to
| ignore them for other approaches (React, Vue) where there are
| better ergonomics and stronger network effects.
| meiraleal wrote:
| ShadowDOM should be a killer feature for people that wants
| to make web scrappers life a bit more difficult.
| nsonha wrote:
| just do a quick scan in this thread, many say it's the
| one thing that makes web components not work for them.
| It's the opposite of what a killer feature means
| meiraleal wrote:
| What users/devs like and what CEO/PMs want (stop bot
| scrapping) are different things.
|
| It was a joke tho, I use custom elements heavily but
| never with ShadowDOM. It is indeed a PITA.
| kansface wrote:
| > They seem like a fantastic solution
|
| for which problem? They don't replace the need for a
| framework nor do they make writing in one easier. They don't
| make dev ex better. What is the actual use case? If they were
| highly useful, they would be used.
| stavros wrote:
| Creating self-contained components that don't rely on
| loading extra management code, in a standard way.
|
| Maybe they aren't useful because the modern trend of web
| development is to not care about speed or size as much.
| tomjen3 wrote:
| Why would I used them over something like a Vue component?
| burcs wrote:
| They are framework-agnostic, meaning you're not locked into
| Vue, React, Angular, or any specific framework. They work
| natively in the browser, which makes them reusable
| everywhere, now and in the future.
| throw310822 wrote:
| > They are framework-agnostic
|
| This is a selling point only if your job is producing
| component libraries. Otherwise, if you're an application
| developer, you'll be using a framework anyway.
| apotropaic wrote:
| Not entirely true. Making UI parts of your app using web
| components can future proof and prevent getting stuck on
| a framework.
| jitl wrote:
| I looked at your docs:
|
| - renders very weird on my iPhone iPhone 15 Pro Max in Safari
| 18.0. Consider responsive design for smaller screen sizes to
| restyle the sidebar and set a body max-width instead of a
| width. You might not expect your users to develop on phones,
| but you might have a hard time with adoption if the docs are
| mobile hostile.
|
| - the "explore components" button at the bottom of the home
| page seems to link to nowhere
|
| - site claims "Learn from well-structured, accessible component
| implementations" as an advantage but I didn't find any links to
| the implementation from the docs
|
| - site claims "No dependencies to manage or update" but isn't
| astra-ui a dependency? It has a changelog (https://www.astra-
| ui.com/changes/). Likewise "Full control over the code and
| styling" I don't understand how I can both have full control
| but also be taking a dependency on implementations provided by
| a library.
|
| I'm curious why you've decided to release this library? I've
| come to view open-sourcing internal software as useful to the
| company for a few specific reasons but to generally be a time-
| sink without much return unless it's accomplishing a goal.
| Component libraries need to fight for general ecosystem
| adoption or there's no audience and you might as well not
| publish at all.
| burcs wrote:
| Really appreciate the write up here!
|
| Maybe rough around the edges is an understatement haha, we
| are actively working to make the docs here better.
|
| So a few things, these are very primitive components that can
| easily be updated and restyled.
|
| There's a given that there will be a dependency when using a
| library, right? The thing is with this you don't even need to
| npm install if you don't want to. Just plug and play.
|
| As far as why... there isn't much out there in terms of a web
| component driven component library and I think we've done
| some great stuff with ours. That plus we have customers
| embedding our components into their platform and it's always
| helpful to see the source code.
|
| I hear you on the docs quality though we will work on that.
| tomrod wrote:
| I like seeing accessibility respected. Good post.
| mentalgear wrote:
| One of the things I really appreciate about Svelte is its support
| for generating Web Components through the Custom Elements API.
| Since Svelte compiles down to plain JS/HTML/CSS, creating
| reusable components that work across any framework or vanilla JS
| becomes seamless. https://svelte.dev/docs/custom-elements-api
| skrebbel wrote:
| I'm bullish on web components as a distribution mechanism. In
| fact, we're currently hard at work betting our entire company
| (https://talkjs.com - a component library + API for chat) on it.
|
| I agree with Nolan here that the performance is _fine_. People
| keep comparing web components to React or Solid components, but
| the latter inherently have a tiny granularity whereas web
| components is primarily a way to _distribute_ reuseable elements,
| not an application framework on its own. Don 't make every tiny
| piece of your app its own little web component (or, at least,
| don't do it without a framework such as Lit to skip the pain).
| But web components are _the_ way to build a component once and
| have it usable in all web frameworks (including none at all) out
| of the box. That 's fantastic! And also unprecedented (on the
| web, that is).
|
| It bothers me that so much of the discussion is still about
| whether web components are good primitives to build frameworks on
| top of. No, not really, they're pretty awful for that! But for
| distribution, nothing else comes close.
|
| I'd love it for some alternative standard to emerge, without all
| the awful design choices of web components. And I agree with Rich
| (Svelte) and Ryan (Solid) that WCs being built into browsers are
| getting in the way of some other collective component interop
| design emerging. But until the framework authors stick their
| heads together and invent a fast, modular, non-shitty, property-
| only, functional-smelling standard for distributing components,
| I'm sticking with web components. For component authors, the only
| alternative is making a React version, a Preact version, a Lit
| version, a Svelte version, a Vue version, an Angular version, a
| Solid version and a vanilla JS version of the same UI component.
| That's awful! Web components are clunky but they're here, now!
| delusional wrote:
| > With every programming language, you can do
|
| There are plenty of programming languages where you can't do
| that. If you really need that, can't you just register it as
| "my-thing-1" and then register the other one as "my-thing-2"?
| skrebbel wrote:
| Sorry, I edited my post and took that out for being too
| detailed.
|
| > If you really need that, can't you just register it as "my-
| thing-1" and then register the other one as "my-thing-2"?
|
| Yes you can, but it means you gotta search-replace something,
| whereas in every modern programming language you just do an
| import or an alias or something like that.
|
| And you still can't solve hot-reloading a web component that
| way.
| webdevladder wrote:
| I think this minimizes the fact that interop - the main selling
| point to me as a user - comes at a performance cost where every
| component you use could have its own unnecessary runtime
| attached.[1] Using a framework like Lit with web components is
| the recommended way to use them.
|
| This cost will compound over time where new frameworks emerge,
| and components get stuck on older versions of their frameworks.
|
| I can't see this as anything but significant, and not to be
| minimized. Having multiple redundant libraries on a page is not
| the direction I would advise anyone to take, particularly not
| when baked into the accepted best practices. This bodes poorly in
| the long term.
|
| I've listened to the arguments from web component advocates in
| blog posts, social media, and videos for years now, and I should
| be in the target market. But on top of the interop tax, they're
| full of negatives that aren't present in the mainstream
| frameworks.
|
| Interop works great within each framework's ecosystem. The same
| dynamics that cause developers to seek interop cause them to
| huddle around a small number of mainstream frameworks. So we get
| a few vibrant ecosystems that push the state of the art together.
| Web components cannot keep up on the tech side of things, and
| introduce a ton of complexity to the web platform - ignorable to
| me as a dev, but not for browser implementers - in service of
| their early 2010s designs.
|
| [1] https://x.com/Rich_Harris/status/1840116730716119356
| afavour wrote:
| While this is true I think the multiple libraries problem is a
| rounding error when you look at the majority of web apps
| created today. React and react-dom combined are over 100KB.
| Svelte and Lit are in the single digits. So you could embed a
| _lot_ of frameworks before you get close to the bloat people
| use every single day without even thinking about it.
| webdevladder wrote:
| As a Svelte user this argument rings hollow. You can't judge
| frontend by React and the way it's badly used.
| afavour wrote:
| > You can't judge frontend by React and the way it's badly
| used.
|
| IMO you can because it's the vast majority of webapp usage
| today. I'm also a heavy Svelte user and I love it but front
| end web dev is practically a React monoculture so it makes
| sense to think about it when evaluating options.
|
| I'm not saying it isn't a problem inherent in web
| components, it is. But using it as a reason to not adopt
| web components runs contrary to the logic the vast majority
| of the industry currently uses. Perfect as the enemy of
| good and all that.
| webdevladder wrote:
| React is irrelevant for me and my users. This is not an
| argument in favor of web components over Svelte. Adopting
| web components would mean an objectively worse UX for my
| users - for example requiring them to enable JS.
|
| You won't get a Svelte to look past the flaws of web
| components by saying "React is bad".
| afavour wrote:
| Yes, you're talking about _you_ and _your_ users. I'm
| talking about the industry at large. Those two
| perspectives don't have to line up.
|
| The article we're discussing is titled "Web Components
| are okay", not "Web Components are better than Svelte for
| webdevladder and their users".
| webdevladder wrote:
| Look at the thread you've created here - I'm arguing that
| the article minimizes the antipattern cost they impose,
| and your response brings up React as if it somehow
| changes that.
| afavour wrote:
| Yes, I previously mentioned the "perfect as the enemy of
| good" argument.
|
| Like I already said, I use and like Svelte. But the vast
| majority of the web dev ecosystem uses React. Web
| components would be better than everyone using React.
| Arguably everyone using Svelte _could_ be better still
| but that's a separate debate.
|
| > your response brings up React as if it somehow changes
| that.
|
| It does. Because the industry clearly has no problem with
| a large upfront cost, given that it imposes one today.
| Web components would be better than what we have today
| even if it isn't the ideal.
| azemetre wrote:
| You absolutely can judge tools by how they are used,
| especially if said tool encourages poor usage.
| webdevladder wrote:
| You can judge React, but like I said, not frontend.
| You're responding to an argument I didn't make.
| hajile wrote:
| React has one up-front size for rendering code whether you
| use 1 component or 10,000 components.
|
| Svelte and Lit rendering code size just keeps going up, and
| up, and up....
|
| You can argue about which is better, but this kind of naive
| size comparison is disingenuous.
| afavour wrote:
| While it's true that Svelte and Lit can grow in size
| dependent on project there's no world in which even large
| projects get close to the base level of the React runtime.
| mdhb wrote:
| Only if you are doing it wrong.
| https://lit.dev/docs/tools/publishing/
| skrebbel wrote:
| I don't really understand this argument, to be frank. Most
| runtimes are pretty small, and there's not much of a
| performance overhead to both runtimes _running_ at the same
| time. It 's not like these are two realtime engines both
| purring along in the background or something like that. All
| modern web frameworks are reactive, and won't do anything
| unless something needs responding to. If one part of the page
| is built with React, another part is built with Lit, and a
| third part with Svelte, I don't see how that will have
| noticeably worse UX (or battery consumption) than a page made
| with just one framework, even when reactive triggers are
| frequently exchanged between them.
|
| The tweet you quote is about whether web components are "useful
| primitives on which to build frameworks". I doubt many web
| component fans (who actually really used them) would say that
| they are. They're a distribution mechanism, and the only
| alternative I've seen from these framework authors is "just
| make the same library 7 times, once for React, once for Preact,
| once for Svelte, once for Solid, once for Vue, once for vanilla
| JS". This is awful.
| webdevladder wrote:
| You're ignoring page bloat as a performance cost. That's
| hugely impactful for UX on the web.
| skrebbel wrote:
| Not entirely, I said "Most runtimes are pretty small".
|
| I think people got trained by React into thinking that
| frameworks are big. SolidJS is 7kb, Lit is 5kb, Svelte is
| tiny and used to have no runtime at all, etc. Only React is
| big. And, well, if you're writing React components and
| publishing them as web components, it's usually quite
| feasible to build them with Preact instead, which is tiny
| as well.
|
| So on a page with like some hodgepodge of 5 frameworks
| purring along inside various web components, there's still
| going to be only 20-30 kb of extra overhead. You can
| compress one image slightly better and save more than that.
| webdevladder wrote:
| The point being made is that web components can pay this
| cost per-component, and this problem will compound over
| time. This is an unprecendented cost to frontend
| framworks and it's the expected usage pattern.
| mhoad wrote:
| It's also just not actually true though. It's not
| considered good practice to bundle your web components
| when publishing to npm for this exact reason. That's
| something that should happen inside the final app itself
| where the components get used so you only have one
| instance of Lit for example if you are using that.
| skrebbel wrote:
| I've yet to see this go wrong in practice. The kinds of
| components that are worth publishing as web components
| are often large, non-trivial components. Eg media
| libraries, emoji pickers (like the one made by this
| article's author), chatboxes, and so on. They are the
| kinds of things you only have a limited number of on your
| page. They're also the kinds of things where application
| code tends to be much bigger than the framework (except
| if the framework is React).
|
| On the other hand, if a component is small and focused in
| scope, it's likely either written in vanilla JS (like
| https://shoelace.style/), or made for a single framework
| (like the average React infinite scroll component).
|
| In other words, I don't think you're wrong, but I do
| think you're prematurely optimizing a problem that
| doesn't really exist in reality. And the cost is big: if
| you get your way, every component author needs to either
| lock themselves into a single framework's users, or make
| 7-8 different versions of their component. I'd argue that
| that's much more wasteful than a few kb extra framework
| JS.
| nolanl wrote:
| I cover this in another post [1], but broadly:
|
| - Not every web app is perf-sensitive to every extra kB
| (eCommerce is, productivity tools typically aren't)
|
| - Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB
| [2]
|
| - I wouldn't advocate for 100 different frameworks on the page,
| but let's say 5-6 would be fine IMO
|
| No one is arguing that this is ideal, but sometimes this model
| can help, e.g. for gradual migrations or micro-frontends.
|
| BTW React 17 actually introduced a feature where you could do
| exactly this: have multiple versions of React on the same page
| [3].
|
| [1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-
| comp...
|
| [2]: https://bundlephobia.com/package/svelte@4.2.19
|
| [3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
| webdevladder wrote:
| A more broad observation, I'm being pointed in the parent
| comment - web components need to win over framework authors.
| The signs are not trending well here from what I've seen
| consistently. That community is on X and web components are not
| addressing their problems and they're not used in optimal
| scenarios. I hope web components can win them over but they're
| mostly saying they've been a failure, arguably on balance bad
| for the web.
| newhotelowner wrote:
| Safari is the only browser without the full support
|
| *Supports "Autonomous custom elements" but not "Customized built-
| in elements"
| MrThoughtful wrote:
| I have been following the web components discussion for years now
| and just don't see what I can do with them that makes my life as
| a fullstack developer better.
|
| All the examples I have seen use them to template some data into
| html. I can do that with handlebars already.
|
| Am I missing someting?
| someothherguyy wrote:
| Are you genuinely asking as a professional? Seems like a big
| ask for someone to go over all you are misunderstanding if you
| think they are equivalent to a template language.
| tome wrote:
| On the other hand, if they're completely different from a
| template language it seems like it should be just a moments
| work to demonstrate why, and help a fellow professional
| understand what they're missing.
| EGreg wrote:
| Well um
|
| 1) You dont have to load an external library
|
| 2) Shadow DOM
|
| 3) Dynamic slots
|
| That's about it, honestly LOL.
|
| I guess the main point of most browser APIs was to let apps
| use browser features.
|
| This one actually tried to make a standard way for apps to
| use other apps. But they already had their own libraries so
| nyeh, thank you very much! LOL
| PaulHoule wrote:
| The standard, like PWA, is designed for maximum feasible
| misunderstanding. To the average dev it seems like a random
| bunch of features that don't hang together. Five developers
| could look at it and be like the blind men discussing the
| elephant --- hung up on individual parts and not seeing the
| whole, if there is a whole.
|
| There are a lot of candidates for "what's wrong with modern
| web standards" but this fragmentation, which comes from a
| rather mathematical view of programming, is one of them.
| Thing is, a lot of web devs never studied computer science
| (even CS 101) and less than 5% live in San Francisco.
| Capricorn2481 wrote:
| > and less than 5% live in San Francisco
|
| How will they ever understand web components.
| jhp123 wrote:
| the examples probably avoid talking about the dynamic APIs
| because they are super ugly and very stateful. It's hard to say
| that Web Components are the future when your demo shows 200
| lines of manual DOM reconciliation.
| j-krieger wrote:
| I've come to the same conclusion while using them pretty
| extensively. The idea is nice, but they are not there yet.
| microflash wrote:
| Sure, there is some pain but after years of several Angular
| and a Vue migration, I'd say that pain is much less than
| the pain of framework migration. People often overlook the
| experience of a framework for a long term use.
| vinnymac wrote:
| This could summarize every interaction I've had with Web
| Components since the beginning. Web Components are becoming
| the Nuclear Fusion of Web standards.
| j-krieger wrote:
| Only 10 more years or so, pinky promise ;)
| skrebbel wrote:
| Web Components let you use a UI component made in a different
| framework than yours. That's it. For most other purposes
| they're pretty awful.
|
| Also they let you _publish_ a UI component that works in every
| framework, without having to build 7 versions of it (or just
| exclude everyone who 's not on React, or something like that)
| BostonFern wrote:
| That's also the conclusion I've drawn. This seems to be the
| reason Web Components exists.
| mejutoco wrote:
| IMO the slots that allow a component to have children are the
| difference. You can compose indepent components that way. Also
| the styles are scoped to the component by default, and you can
| only break the scope with custom vars (css vars)
| tomxor wrote:
| Full native isolation. HTML, CSS, JS, the whole thing, no
| tricks, the browser isolates it for you. It's really nice to be
| able to make a web component, clearly define the JS, HTML and
| even CSS API in terms of variables, and then throw it into any
| environment without it breaking, or without creating a complex
| maze of CSS name spaces and framework dependencies.
| MrThoughtful wrote:
| Is there really ever a use case for that?
|
| When do you want part of your page to have different fonts,
| colors, everything from the rest of the page?
| gedy wrote:
| This 100%. Web components get praised for this isolation -
| and it's like the exact thing I do not want if I'm building
| an application. Like try to have a global CSS theme, or use
| bootstrap, etc. (Please don't suggest I embed a link to
| global CSS in every component.)
|
| Like I get it if you're sharing a component on different
| sites, like an embedded component or ad banner, etc. But it
| just gets in the way if you're trying to do normal things
| that the majority of web apps need.
| HumanOstrich wrote:
| There are ways to apply global styles to your components
| other than importing a global sheet. There's just not a
| standard way defined in the spec. Isolation by default is
| the correct path for them to take compared to the
| alternatives. That doesn't make it useless just because
| you don't know how to do it in a good way.
|
| See https://developer.mozilla.org/en-
| US/docs/Web/API/Web_compone...
| gedy wrote:
| My main point is that gets in the way, unlike most other
| web frameworks when building normal applications. It's a
| headwind that always comes up and hurts adoption imho.
| rty32 wrote:
| It is not a choice in many situations. For a large company
| that has many different teams that own many different parts
| of a product, even though teams adhere to the same "UI
| standards", things get complicated quickly. For example,
| CSS classes that have name conflict can cause UI to break
| (which happens more often than you think, and strictly
| adhering to naming rules is just hard for humans). That's
| just one example. Custom elements with shadow DOM is a
| simple and straightforward solution to this, and it makes
| sense -- JavaScript code are scoped to modules and use
| imports/exports to define interfaces, and it is just
| natural to do that for UI instead of putting every class
| that other people don't care about in the global CSS space.
| eyelidlessness wrote:
| In terms of style isolation, the answer is very much "it
| depends". And it depends as much on the nature of what the
| component does, as the kind of isolation you want to
| achieve.
|
| - Namespace isolation. Example: you have different
| components in the same codebase or otherwise meant to work
| together; you may want assurance that a locally defined
| style attached to class "foo" doesn't have unexpected
| effects on other components which happen to use the same
| class a different way. This is commonly achieved with build
| tooling, eg by mangling class names.
|
| - Cascade isolation. Example: you have an embeddable widget
| that you want to look consistent in any context, regardless
| of the styles of its parent DOM. This is achievable to some
| extent without custom elements, but they are a way to
| achieve it with confidence in a relatively straightforward
| way (at the expense of other limitations and complexity).
| pradn wrote:
| The use-case for having isolated objects with parameters,
| much like classes in Java, is to be able to a) share code,
| b) hide internal details, and c) have object behavior be
| governed solely by a constrained set of inputs.
|
| So the point isn't to have your web component be different
| from the rest of the page. The point is that you can pass
| in parameters to make an off-the-shelf component look how
| you want. However, exactly how much freedom you want to
| give users is up to the component author. It is possible
| for there to be too little freedom, true.
|
| See here [1] for a concrete example of someone writing a
| reusable web component, and figuring out how to let users
| customize the styling.
|
| [1]: https://nolanlawson.com/2021/01/03/options-for-
| styling-web-c...
| skrebbel wrote:
| We ran into this too, and ended up not using the Shadow DOM
| at all. We want our stuff to automatically use the page's
| fonts, sizes, colors etc. Also we want customers to be able
| to customize stuff with CSS without having to use JS hacks
| to inject CSS into the shadow DOM (this gets especially
| cumbersome when you're nesting web components). Personally
| I feel like the shadow DOM is the most oversold part of web
| components, in that it's so all-or-nothing that it often
| creates more problems than it solves.
| mock-possum wrote:
| Which is another thing I love about web components - if
| you don't want shadow dom, then don't use it - you can
| build using just custom elements.
| mixmastamyk wrote:
| From reading the parent site the use cases seem to be large
| enterprise and cross site components, say a twitter embed
| or advertising bar.
| SahAssar wrote:
| Web components don't do any JS isolation, right? And when you
| say HTML isolation I think its probably important to say that
| any custom element registered is global, so if Web-
| Component-A uses Web-Component-B version 1 then Web-
| Component-C cant use Web-Component-B version 2 (unless Web-
| Component-B includes the version in its name).
|
| If you want actual isolation of the whole web stack
| (HTML/CSS/JS) I don't think there are any alternatives to
| iframes.
| deergomoo wrote:
| They are very good for progressive enhancement, for example you
| could have a web component that wraps a <table> to add fancy
| features like filtering or drag-and-drop reordering. If JS is
| disabled or fails to load, the user just gets a plain table,
| but they still get the content. When this stuff was new, that
| was much better for the user than what would happen with a
| front-end framework (they would get a white page), but now
| server-side rendering is widely available in those frameworks
| it's less of a selling point.
|
| They are also good for style encapsulation, i.e. you could drop
| someone else's component in your page and not worry about it
| affecting or being affected by your CSS. Anecdotally I feel
| like that is less of a common desire now than it was ~10 years
| ago, with the rise of both "headless" UI libraries (behaviour
| without dictating appearance) and the prevalence of scoped
| styles in front-end frameworks.
|
| What does annoy me about the standard is that to use slots you
| _must_ opt into the shadow DOM, which means that if you're
| trying to create reusable components for your _own_ stuff, you
| can't style them just by dropping a stylesheet into the page.
| I'm sure there's a technical reason why this is the case, but
| annoying nonetheless.
| zupatol wrote:
| Without the shadow dom, your component can still have
| children.
|
| If you need several slots, there's an example duplicating
| that functionality with javascript in the second comment of
| this blog post: https://frontendmasters.com/blog/light-dom-
| only/
| traverseda wrote:
| There are two models of the "web", where HTML is a document and
| where HTML is the scenegraph of a more complicated app.
|
| If you're using HTML as a document you can use web-components
| to include fancier interactive real-time feature
|
| * A terminal emulator web component that attaches to a
| websocket * A date picker web component, add features like
| checking if a date is already taken * Custom form elements in
| general, a search-box that takes a URL for auto-completion
| suggestions * A map, but not a full mapping application * A
| data table, like the jquery plugin of old * Lightweight
| interactivity like tab widgets * Basically any of the custom
| components that jquery-ui provided
|
| Yes you can do all of these without webcomponents, but the HTML
| is a lot cleaner and a lot more document like if it's a custom
| component. Mixing the model and scenegraph views of the web is
| not my favorite. It sure would be nice if there was a
| consistent library of web components available.
|
| You can actually do pretty decent live-chat with something like
| HTMX and server-sent-events, I think. But it's sort of a
| progressive-enhancement view of HTML as a document model.
| lapcat wrote:
| The worst part about web components and the shadow DOM is how
| they can prevent browser extensions from working correctly, or
| working at all.
|
| And the browser vendors aren't in a hurry to remedy this
| situation.
| superkuh wrote:
| Web components are okay as long as you only use them to
| progressively wrap actual HTML elements. If you're using custom-
| elements by themselves like a JS frontend replacement and just
| making entire web pages full of blank grey boxes that do nothing
| without JS, you're doing a bad job.
|
| See: https://blog.jim-nielsen.com/2023/html-web-components/
| claytongulick wrote:
| Oh? So anyone writing applications, PWAs, healthcare software,
| responsive mobile web apps, or a billion other business domains
| where the web makes sense as a UI is doing a bad job?
|
| Guess I've been doing a bad job for a long time now.
| superkuh wrote:
| Yes, https://www.gov.uk/service-manual/technology/using-
| progressi...
|
| "All [UK] government services must follow progressive
| enhancement, even if part of the service or a parent service
| needs JavaScript"
|
| But more seriously, it's okay to do a bad job if you're being
| paid/forced to do it by a for-profit entity. That's what jobs
| are. Being paid to do things you wouldn't do otherwise (like
| making a webpage entirely inaccessible to people with screen
| readers because there's no text in the custom-elements pre-JS
| execution and not caring because the visually impaired don't
| contribute significantly to profit). Just don't chose to do a
| bad job for personal stuff.
| royal_ts wrote:
| While that link is great advice it's not 100% true that you
| need to have JS enabled to render anything in a web
| component - there's declarative shadow dom. Also while it's
| also true to depend on as little as possible JavaScript
| it's also required for some accessibility aspects. You can
| get far with only HTML and CSS but not always all the way.
| DecoySalamander wrote:
| Screen readers that can't do their job on dynamically
| generated pages are faulty and should not be relied upon by
| anyone, especially for browsing the web. There is
| absolutely no reason to be beholden to the incompetence of
| the developers of such software.
| superkuh wrote:
| Yeah, those visually impaired people should be constantly
| changing their screen reader software so as to follow the
| eternally changing wave of web dev. That's totally a
| feasible and reasonable thing to ask. I'm sure the shadow
| dom is giving those dynamic screen readers zero problems.
| /s
|
| Please, please just consider putting actual text in the
| HTML. It helps a lot.
| PaulHoule wrote:
| I did a project that used Shadow DOM and related tech to address
| the problem of embedding a widget into a partner's web site
| without any risk of CSS interference. Worked great, but this was
| one medium-sized widget that did not interact with the rest of
| the page.
| veggieroll wrote:
| One thing about web components that I've appreciated is that they
| can work without JS enabled (at least in theory). I've done this
| a few times for progressive enhancement.
|
| Broadly I agree with Nolan, though. Web components have enough
| rough edges that they're not going to take over the world in the
| current state. But, they are pretty nice for certain use cases.
|
| I'm not sure what he means by not playing well with server side
| rendering though. I've been doing that without issues.
| mariusor wrote:
| > they can work without JS enabled (at least in theory).
|
| I wonder what makes you say that. All that I've seen seems to
| indicate[1] that Javascript is needed in order to register the
| template with a specific tag.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/Web_compone...
| debugnik wrote:
| Allegedly, declarative shadow DOM lets you declare the
| template next to the prerendered slot, without JS.
| mariusor wrote:
| Where is this "alleged" though? From one of the paragraphs
| behind my link:
|
| > This won't appear in your page until you grab a reference
| to it with JavaScript and then append it to the DOM
| debugnik wrote:
| Your link isn't showing the _declarative_ shadow DOM,
| this does:
|
| https://web.dev/articles/declarative-shadow-
| dom#how_to_build...
|
| And the example below that one shows how to hydrate
| declarative shadow roots with JS custom elements, so the
| path to progressive enhancement should be clear.
|
| I say alleged because I haven't had the chance to try it
| beyond a toy example.
| mariusor wrote:
| I'm not sure what you meant when you said "without JS".
| To actually use templates you need JS. Yes you can
| declare them, but what's the point?
| debugnik wrote:
| You've ignored the part where the declarative template is
| immediately attached to its parent as a shadow root by
| the parser, and its siblings become the slot children.
| You don't need to instance or register anything with JS
| there, just copy-paste the template (admittedly lame, but
| kinda the same repetition as SSR today, just less
| involved and with a shadow root).
| nsonha wrote:
| that's just wrong
| debugnik wrote:
| What, exactly, is wrong? I need actual replies to
| continue a discussion.
|
| This is a _declarative_ shadow root [1]. The template
| goes next to its slot contents, so you can render both
| separately on the server and let the HTML parser attach
| the shadow root, without JS, then use JS custom elements
| to progressively hydrate it.
|
| [1]: https://web.dev/articles/declarative-shadow-
| dom#how_to_build...
| DonHopkins wrote:
| Using HTML and CSS to make web interfaces without JavaScript
| is like using concrete to make garden gnomes without rebar,
| while the rest of the adult world is more concerned with
| using pre-stressed concrete with rebar to make skyscrapers
| and superhighways. Sure it's a marginal whimsical decorative
| use case, but not an important or interesting one.
|
| Most people who think turning off JavaScript is an important
| use case are only inflicting it upon themselves (and
| aggressively evangelizing that other people do it too) as
| performative luddites, to feed their martyr complex, so they
| have something to whine and complain about how the web is so
| unfair and out to get to them, and have exactly zero
| customers or products to support.
| mariusor wrote:
| You seem to be quite careless about whom you offend, but
| I'm not a fan. Please quit it, the only one whining right
| now seems to be you.
| nsonha wrote:
| really I feel the same as them
| charrondev wrote:
| How is this supposed to work?
|
| With reactJS I know I can server render a component or template
| and I'll say JSX makes a pretty good tempting language.
|
| With web components as far as I understand there is no good
| templating language built in anyways (so you have to bring your
| own) I'm not aware of a standard mechanism in which I can take
| some chunk of JS for a component associated with a tag and have
| it render out HTML that does not require JS to run.
| nolanl wrote:
| Author here. I cover this in another post [1], but basically
| the interop benefits you get on the client just aren't there
| (yet) on the server. My north star:
|
| > Maybe in the future, when you can render 3 different web
| component frameworks on the server, and they compose together
| and hydrate nicely, then I'll consider this solved.
|
| [1]: https://nolanlawson.com/2023/08/23/use-web-components-for-
| wh...
| jeswin wrote:
| I tried to understand the referenced article "Web Components Are
| Not the Future" - but found that there weren't many convincing
| arguments.
|
| The current state of Front-end frameworks is an absolute mess.
| Speaking for myself, I don't want to learn a complex framework. I
| don't want to learn magic that I don't understand without reading
| the documentation (useState, createSignal et al). Magic in
| frameworks is often a hack, unlike magic in libraries. The first
| library I used was Prototype. It felt like magic, and it truly
| was. And so was jQuery, and Backbone. I never had to guess what
| "useState" does behind the scenes.
|
| There are many things which don't carry over into Web Components
| from current JS frameworks. But if you start from Web Components
| (ignoring everything you know about frameworks), it suddenly
| becomes intuitive. And it brings in abilities which are missing
| otherwise, such as isolation via Shadow DOM. It grows on you.
|
| In my view the only thing we should retain from the React era is
| JSX (for many reasons, true type-safety, autocomplete etc). I
| wrote a library last week for using Web Components with JSX. No
| magic other than JSX. https://webjsx.org
| wslh wrote:
| > I don't want to learn a complex framework.
|
| Completely agree. As a casual programmer, I just want something
| simple, inspired in VB6.
| azangru wrote:
| > In my view the only thing we should retain from the React era
| is JSX
|
| How do you deal with the non-existing difference between
| attributes and properties in JSX? Is every attribute a property
| and vice versa? Do properties reflect back as attributes?
| nsonha wrote:
| jsx is just a syntax to construct elements with attributes.
| You can still add properties like you do in a web component.
| In React you mostly never deal with instances (and
| properties) but that doesn't mean other ways to model
| components utilizing jsx cannot.
| azangru wrote:
| Jsx uses properties, not attributes, while pretending that
| it uses attributes. Html attributes are strings, whereas
| jsx allows you to pass different data types to child
| components. Thus, properties. Which is also why is uses
| camel-cased names, or insists on className. Because these
| are the names of HTMLElement's properties.
| nsonha wrote:
| that's React's implementation, we are talking what it
| would be if not React. IMO the semantic is similar to
| attribute, example:
|
| let element = <my-thing my-attribute={value} />
|
| element.property = prop
| coffeefirst wrote:
| Yeah. I know React quite well, there are legitimate use cases
| where it shines, but...
|
| What we've _lost_ is the ability to say "let's make a website
| today" and just start making UI without build tools or crazy
| install trees or massive libraries that need maintenance and
| security updates, and drop it on a server somewhere.
|
| I keep thinking I can have that back... ES6 imports are fully
| supported now, modern CSS is amazing, all we really need is an
| SSR/a11y-friendly way to do some kind of nestable HTML
| macro/component, and we can party like it's 2007 (but with
| grid, and import statements, and all the other new shiny
| objects).
| lolinder wrote:
| As I'm thinking about this, the main thing that is left
| before I could imagine a build-free website/webapp is
| TypeScript support in the browser. Even just esbuild-style
| stripping of types would be enough, but I can't imagine
| bringing myself to write even a small amount of JavaScript
| without types any more.
|
| Even without that, a tiny system that just depends on tsc
| should be within reach at this point.
| evilduck wrote:
| I wouldn't personally make these tradeoffs but for the sake
| of argument if you're willing to write substantially more
| type info into JSDocs (AI tooling may alleviate this
| nowadays) you can retain most of the coverage and
| assurances without using anything Typescript adds to the
| syntax superset while still using it for type checking
| during development. Even without the type-heavy JSDocs you
| might be able to alter your coding style to lean into
| easing and increasing inference (more classes instead of
| types or interfaces) and get pretty far.
|
| Honestly though, I just never really run into use cases
| where I need to "make a page in a day" and where modern
| tooling gets in the way. I'm comfortable with create-react-
| app, NextJS, Gatsby, and a couple other things, I can
| definitely put a new static asset project from one of those
| on a VPS by shuffling files over scp in the timespan it
| takes to make a pot of coffee, and I would strongly prefer
| having those tools than trying to be "pure" for hand-wavy
| reasons and unproven benefit.
| jrochkind1 wrote:
| You implied but didn't say explicitly, are you doing your
| front-end development with web components now personally?
| jeswin wrote:
| Yes.
| rty32 wrote:
| One aspect of this is how you think about UI. The underlying
| pattern of jQuery is fully side-effects -- you select an
| element and make some changes to it. Frameworks like React and
| Vue.js allows to create UI components whose states are
| completely determined by data, i.e. what the UI looks like is
| the value of a pure function, mathematically speaking. It also
| updates the UI with minimum DOM changes when the data changes.
| (Although you don't have to make them pure, and arguably you
| can achieve the same thing with jQuery.) Depending on where you
| are, it makes UI widgets much more readable and maintainable.
| These frameworks are innovative in terms of state management
| compared to "old approaches" (of course, with additional
| benefits like reusability etc)
|
| Bear in mind that today's websites and web based desktop
| applications are much, much more complicated than two decades
| ago, and has a much higher requirement for scalability and
| maintainability. If you just want to create simple UI, indeed
| they may not be your best choice.
| InsideOutSanta wrote:
| I'm building my most recent project with web components + htmx,
| and it's mind-blowing how much better all of this feels to me
| than the typical React/Angular stack. I think there's a place
| for React and Angular and technologies like them, but 90% of
| the projects that currently use them would be better off with a
| much simpler stack.
| crabmusket wrote:
| > I don't want to learn a complex framework. I don't want to
| learn magic that I don't understand without reading the
| documentation (useState, createSignal et al).
|
| I can't really parse this sentence. It seems to have a lot of
| ideas in it. Do you want to learn a framework at all, or have
| one that is so magical that it feels like it doesn't need to be
| learned? Do you want to read documentation or not? Do you think
| the problem with React is that its primitives are unsuited to
| the work you do in it? Or to the work anybody needs to do?
|
| I've spent most of my professional career in Vue, so I don't
| have a great perspective on the React ecosystem. But Vue feels
| like it must be included in your "complex framework" statement.
| I've definitely felt some pain from overuse of the framework,
| or poor understanding of various features, libraries, etc. The
| ecosystem around full-on SPAs is indeed complex. I'm just not
| sure what other systems would let me personally, and us
| broadly, manage a complex stateful client-side app.
|
| (This is entirely separate to overuse of SPAs for things that
| shouldn't be SPAs.)
| szundi wrote:
| I think he was pretty clear that the "magic" in frameworks is
| not something you can easily understand, therefore have to
| guess how it really works. He doesn't like that.
| jemmyw wrote:
| You don't need to guess. You can actually read the code!
| Not saying that you should straight away when learning, but
| later, when you're familiar with your framework, I think
| reading through the codebase and understanding it is good
| practice.
| cj wrote:
| You can read the code, but it's complex and convoluted.
|
| He referenced Backbone as a comparison point. If you
| compare Backbone's source code to React's source code,
| you'll get what he means.
|
| Basically, libraries like Backbone are small and simple
| enough that you can literally read the source code and
| fully understand how it works. Compare that to React,
| where the source code is an order of magnitude larger and
| very difficult to fully grasp the inner workings.
|
| The simplicity and ability to easily understand the
| source code obviously comes with tradeoffs (e.g. with
| Backbone, to use it to build a reasonably complex app,
| you basically have to build your own framework on top of
| it, compared to React which has more abstractions and
| therefore is more plug and play.
| eddd-ddde wrote:
| I think the point is that frameworks ' magic isn't 100% there
| yet. You eventually HAVE to dive deep and understand things
| about the implementation to understand how to use it.
| AlexErrant wrote:
| Ryan builds out Solid's reactivity system (createSignal)
| _from scratch_ in about 20 minutes, live, in this video
| https://youtu.be/N-Y32BqhoYQ?t=1100
|
| I haven't bothered fully grokking it because I've never
| _had_ to understand the impl details. Solid gives me
| literal dom elements, and that 's low-level enough for me.
| hu3 wrote:
| I'll try to give an example of "bad magic".
|
| Did you know React renders twice in developer mode to try to
| expose bugs with side effects?
|
| If this doesn't raise an eyebrow, I don't know what will.
| jemmyw wrote:
| That seems like a pragmatic solution. The point of having a
| dev mode is to help development and catch mistakes.
| if(devMode) { rerender() } doesn't seem like magic. Though
| in general I really dislike the term magic for what is just
| code doing something.
| hu3 wrote:
| Humans have limited cognitive capacity (and time).
|
| To me magic code is code that requires a significant
| level of cognitive investment to understand and keep in
| your brain RAM. That threshold varies between people but
| it's always there.
|
| In React's case, the chosen solution is not the issue
| here. It's a symptom of bad architecture. The library
| should be doing more than rendering twice to protect
| developers from side effects, to a point that rendering
| twice wouldn't be required.
|
| That feels as bad as rebooting JBOSS servers once a day
| to "fix" OOM crashes. It's a hack at best and doesn't fix
| the real issue.
| jsyang00 wrote:
| You do not need to know how `useState` works to understand how
| to use it to write a React application, it is fairly intuitive
| to understand how to apply the pattern.
|
| If I look at your library, it seems to me like it requires a
| much more complex mental model to begin to use.
|
| Of course, it is better in theory for a developer to thoroughly
| understand the details of their framework, but empirically,
| React has been very successful in allowing people to build
| relatively sophisticated applications while understanding very
| little of the underlying model.
| bakugo wrote:
| You don't need to understand how useState works if you're
| writing a page with a button that increments a number when
| pressed, from a beginner's tutorial.
|
| As soon as you work on any remotely complex codebase, you
| _will_ run into problems that require a decent mental model
| of the underlying "magic" to properly understand and solve.
| "Building sophisticated applications while understanding very
| little of the underlying model" is how you end up with
| gigantic piles of unmaintainable spaghetti code full of awful
| hacks, which seems to be the standard for React applications.
| lolinder wrote:
| Is this less true of Web Components?
|
| I've worked with a lot of different tech stacks over my
| career and every single one of them has required
| understanding the internals once you start using them
| seriously. I haven't found React to be substantially worse
| for that than any other tech stack I've used.
| peebeebee wrote:
| With webcomponents you are pretty close to the "metal".
| If you know how to write good vanilla JavaScript, you can
| take most of that knowledge into webcomponents. You only
| need to learn the custom components lifecycle, and
| shadowDOM, which is knowledge about web-standards. With
| other frameworks you need to learn template syntaxing,
| how state propagates, how the compiler works, etc etc.
| Lot of that knowledge might be obsolete in 10 years.
|
| Which isn't to say it can't be worth it. Learning
| multiple frameworks and libraries is also very helpful to
| skill up because you are learning about different
| concepts and implementations.
| Narhem wrote:
| Another advantage of web components is the syntax is
| similar enough to Java (especially with JavaDocs)
| switching between coding a Java spring backend and a Web
| component based front end is doesn't need as much of a
| mental context switch.
| InsideOutSanta wrote:
| "You do not need to know how `useState` works"
|
| I feel like you eventually do. The issue with React, at least
| in my experience, is that it's a type of abstraction that
| seems ill-suited for how the web works under the hood, so
| it's incredibly leaky. Everything seems to make sense
| initially, and you get along just fine, but then you run into
| an edge case, and there's an official workaround for the edge
| case, but then you run into edge cases for the workaround for
| the edge case, and suddenly, that's your whole life.
|
| Before you know it, you really do have to know how things
| actually work under the hood.
| djbusby wrote:
| Seems like that happens with every frameworks I've ever
| used since 2000 (in Perl, PHP, Ruby, JS, etc). Every
| framework makes the easy things slightly easier, the boring
| stuff is included and you get to focus on the fun/hard part
| - and I think then, naturally, you bump into the edge. But!
| You get to that point faster. And then you have to know the
| guts to solve the issue the "framework" way or do some
| lower-level shit-hack.
|
| I feel like it's just a natural law of any general purpose
| framework.
|
| It made the first 80% of the job easy. Now you just have to
| finish the other 80%.
| jeswin wrote:
| > If I look at your library, it seems to me like it requires
| a much more complex mental model to begin to use.
|
| How so?
|
| It has two functions:
|
| (1) createElement(jsx): Allows you to use JSX to write HTML
| markup. Returns Virtual Nodes.
|
| (2) applyDiff(parent, vNodes): Merges Virtual Nodes created
| with JSX into the real DOM efficiently.
|
| This is all you need to know. I can keep it simple because I
| am not doing much in the library. I felt that if I stayed
| close to the standards, I wouldn't need to do much.
| BoorishBears wrote:
| Maybe you have the luxury of users who want applications
| that have all the reactivity of a DMV form, but in my apps
| at some point I'll need the very simple priciple of "do
| something complex when this value changes" and reimplement
| useState/useEffect in an ad-hoc manner anyways.
|
| I'm more of a backend/embedded developer than a web
| developer and I still honestly don't get how people find
| useState/useEffect as intimidating as your comment makes
| them out to be.
| recursive wrote:
| This hasn't been my experience at all. The implementation
| details even leak into this crazy thing called "the rules of
| hooks". It looks like a function but it's actually this new
| thing called a hook. Which state will you get? That depends
| on whether the reconciler considers this invocation to be a
| mount or update. Getting the wrong one? Try restructuring
| your elements or adding or removing a "key" attribute.
|
| People tolerate this because they learned it but I don't
| think there is anything essentially simple about it.
| sandreas wrote:
| Well, there is a project to convert react components to native
| ones[1]... this way you can write react and use it everywhere.
| I think this is the way to go, similar to svelte's approach.
| Write what you want but compile it to native standards.
|
| 1: https://github.com/bitovi/react-to-web-component
| 8n4vidtmkvmk wrote:
| In my admittedly little experience with shadow DOM, it doesn't
| isolate as much as it claims. CSS variables pierce the
| boundary, so if your styles are built around that, you can
| still run into trouble.
|
| I just haven't seen any benefit whatsoever once you have CSS
| modules. And CSS layers help too.
| peebeebee wrote:
| ShadowDOM, and by extension web components are great for
| providing an extended set of HTML 'native' components. Let's
| say your company has multiple frontend SPAs with different
| technologies (angular, react, svelte,...) they could all use
| the same set of company custom components, like a custom
| datepicker, or fancy selectbox.
| EMM_386 wrote:
| > The current state of Front-end frameworks is an absolute
| mess. Speaking for myself, I don't want to learn a complex
| framework.
|
| It's really not that hard. I was able to pick up Angular to a
| level where I could create complex sites with it, or submit
| acceptable PRs that involved in, in week or so.
|
| Granted, I am an experienced developer (C# since beta,
| HTML/JS/CSS from the start) but it seemed to just make sense
| quickly.
|
| So when I was asked by a company to replace their aging,
| complex portal to manage critical infrastructure, I chose
| Angular for the front end.
|
| That was smooth sailing. It was stable, performant, looked good
| and everyone was happy.
|
| People often avoid it because it has a "steep learning curve"
| but that mainly seems to come from developers who came into the
| industry knowing only JavaScript and maybe a little React. If
| you are more experienced, you can pick it up right away.
|
| And it helps, a lot, to use such frameworks on large complex
| sites. For various reasons.
| jeswin wrote:
| It's a libraries vs frameworks thing. Libraries are
| relatively safer.
|
| Frameworks in C# are slightly better (compared to those on
| JS), because there are blessed Frameworks and most people are
| using them. In the JS world, you can see very popular
| frameworks (with millions of downloads) get abandoned. Not
| saying that all is well in the .Net world; desktop frameworks
| are an example. But overall it's a bit different because one
| company more or less controls it.
| blovescoffee wrote:
| How does your library deal with state management and data flow?
| What primitives does your library offer for optimization?
| Narhem wrote:
| If you use web components enough you realize why tools like
| useState exists then you have to bring in another library like
| alpine to offer the functionality.
|
| The whole point of web components is the ability to offer class
| encapsulation within the browser without anything other than a
| file server.
|
| JSX has much nicer syntax but I'd rather not have to deal with
| the overhead of launching a node server. Makes developing time
| quicker when working with smaller codebases.
| jaredklewis wrote:
| > I never had to guess what "useState" does behind the scenes.
|
| It's weird to me that React hooks are always dragged out in
| these arguments as some kind of bogeyman. If you understand the
| idea of a virtual DOM and a render loop, then it is only a tiny
| step from there to understand hooks. And you can understand all
| of these concepts in about 15 minutes:
| https://www.youtube.com/watch?v=1VVfMVQabx0
|
| I just don't get all the hand wringing regarding frontend
| frameworks. I've been using React since 2014 and in 10 years,
| there has been exactly one big change to the framework: hooks.
| When they came out, I spent 15 minutes to understand them. It
| didn't kill me.
|
| And React has been undisputed king the frontend frameworks hill
| for at least 9 years, but people still act like it's some sort
| of ever-changing, confusing landscape of options. If you want
| boring, stable front-end development, choose a super popular,
| well documented tool like React. Or if you don't like
| frameworks, use vanilla JS. It's not a crisis.
| mock-possum wrote:
| Have you tried the Lit library? Using lithtml to write web
| components based on Lit Component is DREAMY imo, if you're into
| web components. It really reminds me of using jquery's helper
| methods for ajax - like why wasn't it just this way by default
| all along.
| meiraleal wrote:
| > In my view the only thing we should retain from the React era
| is JSX
|
| honestly lit-html is much better and based on existing browser
| APIs. We should make it part of the webcomponents spec! Which
| is a work in progress:
|
| https://github.com/WICG/webcomponents/issues/1069
| claytongulick wrote:
| I think one of the biggest "mistakes" with web components was
| coupling them in people's mind with shadow dom.
|
| For app dev (not library dev) web components are a super
| lightweight easy option when you stick with the light dom.
|
| You can continue to use bootstrap or tailwind or whatever css
| thing you like, but get great functional encapsulation with near
| zero cost, especially if you use lit-html or something similar as
| a renderer.
|
| My teams have generally found working with native web components
| refreshing. It takes a dev coming from the framework world about
| a week to adjust, and then they never want to go back.
|
| Just using simple class properties and a manual call to a render
| function on set() gives you all the benefits of reactivity
| without all the hassle of frameworks.
|
| The problem most people have with getting started with WCs is
| that there's not much out there showing how do to it in "easy
| mode".
|
| Most of the getting started things throw you right into shadow
| dom, css parts, and all these really painful technologies that
| were primarily intended for use by library authors, not app devs.
|
| I've been building apps with native WCs for a long time now, I
| should get off my keister and write a guide on how to make your
| life easier with WCs, something like "The Good Parts".
| meiraleal wrote:
| That's exactly it. We are just missing slots for lightDOM
| nolanl wrote:
| I use shadow DOM every day, but yes, it is often the part of
| WCs that baffles people - probably because they don't need it.
|
| Alternative approaches that may work for your use case:
|
| - "HTML web components" [1] - light DOM only, SSR-first, good
| as a replacement for "jQuery sprinkles"
|
| - "Shadow gristle" [2] - use as _little_ shadow DOM as
| possible. If you need styling or composition, put it in the
| light DOM!
|
| [1]: https://adactio.com/journal/20618
|
| [2]: https://glazkov.com/2023/03/02/shadow-gristle/
| kolme wrote:
| In my last gig we had exactly the same stack (WC without the
| shadow dom part + just lit-html) and it's great.
|
| The best part is not having a dependency hell situation every
| other week.
| replete wrote:
| > I've been building apps with native WCs for a long time now,
| I should get off my keister and write a guide on how to make
| your life easier with WCs, something like "The Good Parts".
|
| If you consider writing about this I'd like to read it. Or
| listen! Do you have a blog? In the process of gathering various
| comments about this technology as it appears there are
| blessings and curses, depending on how you use it.
| apitman wrote:
| I think part of the reason people talk past each other on this
| issue is because they're optimizing for different things. If
| you're working for a VC-backed startup with a central product
| that needs to move quickly and is going to require constant
| maintenance anyway, a framework might be a good fit for you.
|
| But I work in an academic lab. We don't have tons of money to
| maintain the apps that we've written. We need them to just keep
| working once funding has moved on to new projects.
|
| We're just finishing up a rewrite of an app from Vue to Web
| Components. It had dependency rotted to the point where we
| couldn't update anything because of dependency hell. Rather than
| spend hours trying to fix it, which we've done before and would
| have to do again until the end of time, I decided to experiment
| with Web Components. The experience was immediately so nice that
| we went all in. No regrets. We went from ~15 dependencies to ~1
| (d3js).
|
| If you're curious to try the apps, old one[0] new one[1].
|
| [0]: https://bam.iobio.io/
|
| [1]: https://bam2.iobio.io/
| jitl wrote:
| If you can rewrite to remove all dependencies except for d3js,
| why couldn't you do the same thing, but also retain a
| dependency on Vue? What is it about Vue that requires the extra
| dependencies - is it built system things? (I've never used Vue)
| apitman wrote:
| Vue itself must be updated. And if you throw out the router,
| Vuetify, state management, etc, what is it adding above Web
| Components anyway?
| Jcampuzano2 wrote:
| Sometimes I don't understand this argument because theres
| nobody forcing you to always be on the latest version of a
| framework. You could have just stayed on the version of Vue you
| were using without issues. Unless theres some compelling reason
| you could use it into the end of time and be just fine.
|
| Thats not to say that maybe for your use case you could have
| not used it in the first place or that removing the dependency
| was a bad idea - just that if you do like Vue there doesn't
| seem to be anything forcing you to always be on the latest
| version.
| WD-42 wrote:
| What happens when old versions stop receiving security
| updates?
| Jcampuzano2 wrote:
| Rarely do security issues come from directly as a result of
| your choice of frontend/client framework which should
| really only be in charge of displaying your data. Almost
| all issues should be handled by your backend.
|
| Most cases where it becomes an issue is when people drop
| security best practices falsely believing their
| frontend/client validation is a security layer.
|
| Anybody thinking updating your frontend solves your
| security issues has deeper problems.
| WD-42 wrote:
| > Rarely do security issues come from directly as a
| result of your choice of frontend/client framework
|
| Front end client frameworks now span the backend. Nextjs
| is the prime example. It has plenty of CVEs already.
| Jcampuzano2 wrote:
| Well next is not a frontend framework and doesn't claim
| to be. Its very clearly a full stack framework. Vue by
| itself isn't.
| wavemode wrote:
| Doesn't matter, a security update is a security update.
| So, especially when you work in a larger company, you end
| up having strict compliance requirements to keep things
| up to date.
|
| I'm as annoyed by it as the next guy. The supposed
| vulnerabilities are almost never actually relevant for
| frontend code, and rather assume that you are running
| Node as a web server.
|
| It's just one of those weird things that has resulted
| from how the JavaScript ecosystem has centralized around
| using node for everything (i.e. building frontend code as
| well as executing backend code - even though the two have
| kind of nothing to do with each other.)
| tannhaeuser wrote:
| Let me explain the argument to you:
|
| > _You can always add another layer of abstraction to solve a
| problem but removing one can be difficult._
|
| The argument being that there's no need to add anything to the
| browser stack and make it even more complex when it doesn't add
| any essential capability. There's already JS making everything
| possible; and yet, they keep on piling stuff. When with custom
| elements specifically, you also require JS anyway (to declare
| them).
|
| > _Elements are not components._
|
| Idk maybe for "web devs" the concept is difficult to grasp that
| HTML isn't for them. It's for text authors, and as such a markup
| vocabulary where low-level elements are placed next to complex
| custom controls nilly-willy isn't really a useful evolutionary
| direction.
| renegat0x0 wrote:
| This might be a stupid hot take, but I am surprised that so
| little of web UI exist outside of the browser. I mean why
| bootstrap or other frameworks are not managed by browser
| ecosystem? Why millions of people how to download same frameworks
| over and over?
| ramones13 wrote:
| There's a pretty thorough post covering this here -
| https://infrequently.org/2022/03/cache-and-prizes/
| addicted wrote:
| Web components are lacking some basic functionality that makes
| using them in something complex difficult.
|
| For example, one of the deal breakers we faced was the inability
| to unload and reload a web component. Once you load a web
| component you're stuck with it until you refresh the browser.
|
| You cannot have an SPA with one page loading 1 version of the web
| component and another loading another version without some ugly
| namespace mangling.
| thomassmith65 wrote:
| I use web components, but I often want to design classes as MVC.
| It isn't obvious how this should work (though I assume the Web
| Component spec authors discussed the topic at some point). The
| awkwardness is:
|
| (a) When you instantiate your View class (ie: 'web component')
| from JS, you probably want your Model and View to be 'owned' by
| properties of the Controller (eg: con.model and con.view).
| However...
|
| (b) when an HTML tag instantiates your View, the View has to
| create its Model and Controller. And now there's no obvious place
| to store a reference to the Controller.
|
| As a result, you have either to stick the Controller in a global
| variable somewhere, or - more likely - end up, not just with
| 'con.model' and 'con.view', but also with a new property:
| 'view.con'
|
| So... two paths to create everything (Controller-based, or View-
| based), and this ugly '.con' property stuck in the View.
|
| But, aside from this gripe, Web Components are okay.
| mattlondon wrote:
| I don't think we components were intended as a complete
| "framework" for writing web apps, but more for the rendering of
| reusable UI components.
|
| So trying to do MVC with just web components feels a bit weird,
| at least to me. You'd need something extra I think
| thomassmith65 wrote:
| The problem is that the ShadowDOM is sort of the _real_ View,
| and the CustomElement (judging it by its methods), is kind of
| a mix of a View _and_ a Controller.
|
| Perhaps I should try making my _controllers_ the HTMLElement
| subclasses, instead of my _views_. My gripe remains: the best
| approach is not obvious.
| mmcnl wrote:
| I don't really get this "frameworks vs. web components"
| discussion. They are both tools to solve different problems.
| Frameworks exist to render your view as function of state in a
| declarative way. They use web primitives to define the view
| layer. Web components can help there, but it doesn't solve the
| state management issue that frameworks aim to solve. That's a
| different problem that requires different solutions. In my
| opinion they can perfectly co-exist.
| drawkbox wrote:
| I dig WebComponents because I love building on standards which
| promote interoperability across frameworks and have long term
| lifelines. Standards reduce platform + dev lock-in and reduce
| framework balkanization and frankly chaos in many cases. You are
| a better developer if you understand the root standards and core
| systems, which WebComponents get you closer to.
|
| I also like the Lit Framework (https://lit.dev/) from Google
| which is rarely mentioned but it is quite nice for some of the
| simplifications and extras you might need when building them but
| it doesn't get in the way or try to take over your entire domain
| with dev-lockin.
|
| Whether going direct to WebComponents or a higher level
| simplification like Lit, they really are a freedom from dev lock-
| in that is nice to see.
| wellpast wrote:
| What's missing in his point and examples about "performance isn't
| everything" (aria properties, forEach, ...) is that these are
| cases where you could optimize later when and if needed. Using
| forEach is a fluid coding choice at the time but if for any
| reason you need to optimize to a for loop you can with minimal
| fanfare. But buying into web components is more of a one-way door
| and harder to iterate optimizations, and that's the problem.
| gaganyaan wrote:
| I really dislike the Shadow DOM part of Web Components. Someone
| didn't learn any lessons from past mistakes and went and
| reinvented iframes. Trying to write tests or any automation for a
| web page that uses shadow dom is an exercise in misery,
| unnecessary at that.
| dandrew5 wrote:
| Web Components are fun. I've played around with Lit, which some
| people have mentioned. Anybody tried Stencil? It looks similar
| from the outside but wondering how it plays out mid/late-term.
| commanderkeen08 wrote:
| Stencil has a way better DX. Especially if you're doing a whole
| library of components. You pay a slightly higher perf tax for
| their auto loader and light vdom. Lit is the way to go if you
| have opinions and want no magic
| breck wrote:
| We do web components better than the web. We just call them
| Parsers.
|
| Geniuses build for The Scroll first. Retards build Web first.
|
| (Don't misinterpret, I love The Web, but The Scroll is on track
| to be 100x better)
___________________________________________________________________
(page generated 2024-09-29 23:00 UTC)