13 ms·

Web Components Eliminate JavaScript Framework Lock-In

263 points by jakelazaroff 3y ago

iteratethis 3y ago
I don't think there's a need to cause a stir and generate hate for either Web Components or React. We should hate both equally. Either approach is frankly an embarrassing way to build complex interactive applications. Web tech is just way too low level, batteries not included. We've added mountain of complexity to deal with it but it doesn't hide that the fundamentals are broken and that productivity is low.
socketcluster 3y ago
The main problem with the Shadow DOM which makes people avoid it is the inability to use CSS externally to style the elements which are generated internally by the component... This is unfortunate because the Shadow DOM is essential if you want to work with child components slotted into it from the outside. This opens up many use cases. There is one alternative which is not being considered; it's possible for components with a shadow DOM to inject their elements into the Light DOM (where they can be styled/skinned externally with CSS), you just have to make the user slot a div (or other element) from the outside to act as a 'viewport' so that the component can inject its children into it (instead of injecting them into its Shadow DOM). With this approach, you can still access slotted elements. It's an ideal pattern for situations where you want the component to generate child elements from a slotted template. I wrote an article about this approach here: https://dev.to/jondubois/web-components-the-template-viewport-pattern-for-the-shadow-dom-2gm4 https://dev.to/jondubois/web-components-the-template-viewpor...
- djrenren 3y ago
  This is a great approach for components that want to inherit all styling from their context. In cases where you want to introduce just a little styling, the CSS Parts API is really cool: https://developer.mozilla.org/en-US/docs/Web/CSS/::part https://developer.mozilla.org/en-US/docs/Web/CSS/::part
  - socketcluster 3y ago
    Thanks for pointing this out. I should probably mention this approach in my article for cases when you need to work with slotted elements but don't want to inherit all page styles.
- aitchnyu 3y ago
  Is there a comparison between light and shadow dom for webcomponents? I kinda want the simplicity of applying light dom css. Svelte doesnt support slots in light dom, I want to know the other caveats of light dom.
- gitaarik 3y ago
  Cool solution. I'm using Lit, and implemented a different approach to this problem. I created a way to easily apply a set of styles to particular components, by using a mixin class: const myStyles = litStyle(css`h1 { color: red; }`); class MyComponent extends myStyles(LitElement) { // ..} You can store the style definition in a separate file and import it and use it for the components that you want it for. https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style
dang 3y ago
Recent and related: Web components will outlive JavaScript frameworks - https://news.ycombinator.com/item?id=38012662 https://news.ycombinator.com/item?id=38012662 - Oct 2023 (244 comments)
yohannparis 3y ago
Thank you for the great read! The last few weeks have seen a lot of thought on HTML web components, and I'm really happy about it.
xutopia 3y ago
I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore. I'm all for web components!
- joshstrange 3y ago
  In your opinion what is the “really bad thing” that React/Angular have resulted in? Is it just the fewer full stack devs? I mean I’m a full stack dev still while using Vue. But also specialization (at a certain scale) is nearly unavoidable.
- lopis 3y ago
  This is not my experience at all. Why can't a full stack dev know react or angular?
  - schwartzworld 3y ago
    Apparently because learning anything more than the minimum necessary to put pixels on a page makes you a specialist?
  - codegeek 3y ago
    GP didnt say that. They said lot of devs become "front end" or "back end" specialists which means that they cannot do full stack. Full stack devs knowing React is fine. The problem is that most "React devs" don't know full stack and most "backend devs" don't know full stack.
    - zztop44 3y ago
      Why does being a front end or back end specialist mean you can’t do full stack? If I’m a full stack dev that’s a back end specialist I can still write a complete feature myself just fine, thank you very much. But of course, if I’m having trouble with some part on the front end I might ask a front end specialist colleague for help, and vice versa.
shadowgovt 3y ago
My hair always bristles a bit when I see plans to "eliminate JavaScript Framework Lock-in." For a backend service, it doesn't matter if you use no framework or one or five, other than pain for your developers having to learn the complexity; storage is so cheap it's nearly free, executable RAM slightly less so, and the end-user doesn't care how complex your server is. Frontend code gets pushed over a wire to your end-user. If you're using three overlapping frameworks to build one web service frontend purely because someone in your team likes Svelte and someone else likes React... that's a problem. You'll be pushing more bytes than you should to your end-users, and that cost doesn't scale the right way; in fact, the more popular your app, the more redundant bytes you'll be passing. We don't want to enable multiple frameworks in the UI. We should be settling on one and committing everyone on the frontend team to using it (ideally lock-stepped to the same version of it) within each app-shaped thing we create as a frontend team.
- politelemon 3y ago
  It isn't a standard HN post if it isn't claiming $new_technology will eliminate $old_technology.
- jakelazaroff 3y ago
  Author here — I feel like I addressed this point in the article, no? Obviously using a zillion frameworks in your app is a bad idea, but there are a bunch of actual reasons that encapsulating and/or mixing frameworks might be useful: - Gradually migrating from one framework to another - Including interactive "islands" within a static or server-side rendered page - Using a dependency only available in one framework from within another (this works best if the dependency framework has a small footprint — e.g. using Svelte within React is better than vice versa)
willsmith72 3y ago
i did this back in 2019 to make the transition smoother between angular.js and react > there are ways to build a web app other than writing the entire thing with a single JavaScript framework totally agree, and reducing rewrites or making converting them into "strangler" rewrites is a huge win on the other hand, it reminds me of the microservices hype a few years back. Just because you can, doesn't mean you should. Uniform languages, frameworks, coded patterns make things SO much smoother for an organisation. I would repeat the author's words of warning: "you should not build a real app like this!". you should seriously think hard before adding this level of complexity to any production app
dbingham 3y ago
One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to build on React are doing it largely out of habit. I'm going to withhold my own thoughts about that quote, cause I'm curious what everyone else thinks. Wrt. Web Components, I played around with Web Components about half a decade ago and they felt promising but not ready for prime time yet. They were pretty messy and felt like they did a poor job of encapsulation. (At least at the time.) I haven't looked at them recently, but the code examples in these articles look much better (and cleaner) than what I remember. [1] https://adactio.com/journal/20618 https://adactio.com/journal/20618
- troupo 3y ago
  > They were pretty messy and felt like they did a poor job of encapsulation, ultimately. (At least at the time.) They are still messy. https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html
- wayfinder 3y ago
  As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do that in JS and every custom way you invent looks like trash. Doing something like this.shadow.innerHTML = `your HTML` with web components is terrible. document.createElement() is terrible. $('div').appendChild() is terrible. <script language="html" name="my-template"></script> is terrible. HTML(Div(Strong(text))) is terrible*. Storing templates as JSON and writing a one-off loader is terrible. <div style="display:none">template</div> is terrible. I've done it every possible way and they are all terrible. JSX fixed all that. The biggest previous attempt at something like JSX was E4X where you could embed XML straight into JS, which was kinda nice except it added the entirety of XML and its complexity. I creamed when it came out but then I tried it and it was not it. (E4X ended up surviving a little longer in Adobe Flash though.) E4X: https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML *This is what JSX compiles to behind the scenes.
sohzm 3y ago
lit.dev is awesome. I am a backend dev so I don't really want to get into the intricates of React or Angular. But if I need some reactivity for some complex element, I use lit. It's awesome
- deleted 3y ago
  [deleted]
troupo 3y ago
They don't. When your tech needs 20 more web specs [1] to fix stuff that literally no one has issues with, it means that you will be locked in to frameworks that solve these issues. Literally right now Web Component SSR is a framework-specific barely working non-solution. Even the most ardent web component proponents have given up and advocate a framework lock-in with lit-html and others. [1] https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html
tauchunfall 3y ago
I recently rebuild some parts of a large APM (application performance monitoring) solution to find out how much JavaScript is needed to have similar functionality (minus the backend, of course), e.g. faceted search. It's interesting how much of a component system one can build only by using `<input>`, `<label>`, and `<form>`. For the remaining interactive elements that can't be build easily without JavaScript I plan to use Web Components. For me this is a reasonable 80-percent solution. But for web applications with high requirements I would use React and React-Aria components/hooks.
oblak 3y ago
I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve a number of problems that are not directly solved by Web Components. State management, rendering, routing - right now, these are, imho, the high level areas that need solid solutions for an UI app to function in any sane way. How much of that is solved by going Web Components?
- DarkNova6 3y ago
  A foolish consistency is the hobgoblin of the little mind
- earthboundkid 3y ago
  "Web Components" are the name for a dream, not an actual technology. The actual technologies involved -- customElement and shadow DOM -- are pretty crappy to use directly, and even when hidden behind a framework/library don't buy you that much. But people want it to be true that there is such a thing as a "Web Component" so the dream lives on.
  - gitaarik 3y ago
    Why do you think this? I've been using it for years and it works lovely, no complaints at all.
- spankalee 3y ago
  I work on Lit, which I would hesitate to call a framework, but gives a framework-like DX for building web components, while trying to keep opinions to a minimum and lock-in as low as possible. It's got reactivity, declarative templates, great performance, SSR, TypeScript support, native CSS encapsulation, context, tasks, and more. It's used to build Material Design, settings and devtools UIs for Chrome, some UI for Firefox, Reddit, Photoshop Web... https://lit.dev https://lit.dev if you're interested.
earthboundkid 3y ago
No, they just lock you into one framework per component. I don't know why people say obviously false stuff like this about web components besides they just really, really want it to be true. Yeah, if you're willing to have the same framework on the page ten times, you can just chuck them all in separate script tags using the custom element API. But if you care about making a performant page with progressive enhancement, etc. this is a bad strategy. Even the name "web components" is basically just marketing fluff. When people say "web component", they mean using two particular DOM APIs: customElement and shadow DOM. Those are both pretty niche APIs. There are some cases where they are helpful, but 99% of the time, they don't add much to a project versus good old querySelectorAll and normal CSS.
- jakelazaroff 3y ago
  Author here — I'm not sure what you mean by "lock you into one framework per component". The point is that you can encapsulate framework code within web components, not that every component you write should be a web component. Let's say you're writing a Vue app and you really want to use a library that's only available as a React component. You can wrap that library in a web component and use it in your Vue app just like you would any other HTML element. The rest of your app can continue being Vue, using normal Vue components.
  - jdmg94 3y ago
    except you can't use it as a normal component, you can't adjust its CSS normally, you have to `&::part()` your way around and hope for the best. Accessing through refs is a complete blackbox. I work with web components daily and it is a hindrance to my daily work, it is very common for people at my org to just re-write a component instead of using its web component version.
    - mmis1000 3y ago
      I also wonder about this. The webcomponent make the style completely immutable unless you add part selector specifically… how on the earth this is even useful? Imagine using an ui library that you can't change the style at all. That sounds like a total joke to me. That isn't even a sane default that is useful to most web folks that make page base on layout that designers gave.
djrenren 3y ago
I've found webcomponents to be really good at encapsulating anything that doesn't directly query application state. Specifically there are two type of components that really thrive as web components (as opposed to react): 1. Highly interactive components - Components that implement complex interaction management (but sort of agnostic to application state) are ideal web components. You don't need to mess around with `useEffect` or `useMemo`. You get really tight control of rendering and state updates. 2. Highly internally stateful components - Components that track a lot of state that doesn't escape the component, work great as web component. You get strong encapsulation without a framework requirement. React conflates two concepts that I think are better when separated: templates, and components. Templates provide a "re-render the world" approach, and components encapsulate state and interaction patterns. Conflating these two things causes the standard useEffect and useMemo headaches. It also means that any consumer of your component, must also use your templating system (react's render function). The `lit` library does this separation extremely well, allowing you to implement components using templates if you want, or not. And consumers do not care how the internals are implemented.
- jongjong 3y ago
  I find that they can work very well with state but since state is typically passed via attributes (downstream), it means that components can only share state with each other via strings. I found this to be an advantage, not a drawback because simple interfaces are at the core of my coding philosophy and strings make it infeasible to pass complex instances or functions to other components.
  - djrenren 3y ago
    Well, this is only sort of true. When you’re writing HTML you’re restricted to attributes but custom elements are JavaScript objects and are free to respond to property updates on the object. Relying solely on strings is a limitation of your templating engine. For example lit-html templates support syntax like: <my-element .someProp=${new Foo()}></my-element>
    - 3y ago
toasted-subs 3y ago
Pretty excited to see all those job posts for react disappear.
preommr 3y ago
Web components are a half-baked solution. It only becomes useful with another framework (even if it's very lightweight) like lit. At which point I might as well use vue/react/svelte since I am already brining in a library. Tech like preact is really lightweight as well, and given the popularity of react, is enough to offset any benefits web components have. I would really like it if we reached a point where a web project only had a single dependency that's a bundler like vite that you point to an index file, and that's it.
- OJFord 3y ago
  I think we're going in the opposite direction though - everyone wants to hide what's going on and use some magic CLI that just takes care of everything for you, don't worry about how or when or what to do if it goes wrong, just run `flyctl deploy`, `wrangler publish` (Cloudflare), `npx wizzle wazzle` :sparkles: :tada: never `git commit -m '(chore): [...]'` again! Oh and here's a readme example of how to set that up if you're using pnpm v42 with sveltekit v2 and webpack v99. For any other combination of the 5 packagers, 19 bundlers, and 56 frameworks commonly in use and giving examples like this recommending each other - have fun.
- reidjs 3y ago
  I use them for a basic website (no build step) for things like navigation components and page templates. They are great for that, but not much else in my experience. Once you have a complex UI or multiple devs on a project it’s probably better to just use a full framework
- codegeek 3y ago
  "half-baked solution" Can you elaborate further ? Anything that removes dependencies from external libraries is a huge plus for me so I am curious as someone who is not great at JS.
  - troupo 3y ago
    > Can you elaborate further ? As you read the following, keep in mind that at this time Web Components have been in development for almost 12 years. The core is just three standards, CustomElements, Shadow DOM and HTML Imports (already deprecated and removed in favor of JS-only imports). And people will go out of hteir way to sell you the idea that this is lightweight, all that you need etc. However. They've already spawned half a dozen new web standards just to deal with issues they inflicted on themselves. None of these issues are present in any other solution/lib/framework that exists. These range from the fact that web components cannot participate in forms (fixed with a new spec: https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls) to their inability to share stylesheets (fixed with a new spec: https://web.dev/articles/constructable-stylesheets https://web.dev/articles/constructable-stylesheets) to whatever else (hard to keep track). They will need at least 20 more new web standards to fix other issues that, once again, are not a problem for literally every other framework, library, or hand-written code under the sun: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html. Among my favorite ones: a web component button cannot be a submit button in a form; you cannot reference an id inside a shadow root, and that breaks ARIA. To call them half-baked is an understatement. They are badly thought-out, badly implemented APIs with no forethought or visible planning, and literally no end goal in sight. The people building this met to hash out what more is needed for them to be complete only last year, 11 years into development. All development before that looked like ad-hoc patches by people surprised that a yet another thing doesn't work, but is sorely needed.
tannhaeuser 3y ago
In case anyone was wondering, JavaScript per se isn't replaced at all. All mentioned examples still use event listeners, querySelectorAll, ES modules, and what not. Most importantly, you need to subclass HTMLElement and register your custom element using JavaScript in the first place eg: class MyElement extends HTMLElement { } window.customElements .register('my-element', MyElement) (the hyphen in the name is idiosyncratically required by the custom element spec). As such, "HTML web components" (aka custom elements, which have be around for many years) are targeted at developers not hypothetical web users/authors. Then what is the point? When you're relying on JavaScript anyway, you have already much greater freedoms - syntactically and otherwise. Custom element declarations and custom vocabularies can make sense as a means to organize and isolate authoring concerns when you're creating hypertext documents. The fact alone that you have to use JavaScript for registering custom elements make them a non-starter though (ie consider an authoring tool which surely doesn't want to execute arbitrary JavaScript in client docs). It's not that there's no precedent either. SGML has a mechanism for parametric macro expansion where your element is syntactically replaced into an arbitrary markup fragment, with type-checked arguments (= attributes at the call site, just as with custom elements), and with type-checking the resultant expansion in context (ie. checking whether the expansion adheres to the content model at the expansion site), also having of course the capability to include JavaScript. Moreover, SGML actually can serialize/re-parse such markup whereas HTML's preliminary APIs for fragment parsing won't deal with contextual tag inference at all.
- runarberg 3y ago
  For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change. <script type="module"> import lib from "/path/to/my/lib.js"; for (const target of document.querySelectorAll(".target")) { lib(target); } // TODO: Watch for DOM change and apply lib. <script> <span class="target">Some Input</span> Or I can simply ask them to import my web component module and use the custom element: <script src="/path/to/my/web-component.js"></script> <my-lib>Some input</my-lib> The latter certainly feels like a superior API for my users.
megaman821 3y ago
I don't feel like web components and React should compete for most people. Web components feel pretty good at making leaf components, especially when they will be used with multiple technologies. I tried using React to only make a single component for use within a larger React app and within a Django site, and it was not as smooth as a web component. Also, I tried to make a web component app and there was way more friction and less tooling than a React app. As it stands now, I wouldn't use React for single component nor web components for an entire app.
r3trohack3r 3y ago
For folks looking for a lightweight JS class that manages the lifecycle of Web Components, I have this little Template class I use in many of my front-end projects. It's able to manage the application state by pushing the state down through the application and bubbling changes up. It's a 161-line file that's easy to reason about and modify as needed. https://github.com/retrohacker/template https://github.com/retrohacker/template
switchbak 3y ago
I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we could talk declaratively at a high level about the kinds of interfaces we want to render and where the data lives. Hopefully I'm wrong and the magic is buried under some Elm tree or a React library or something. Something something get off my lawn...
- metadaemon 3y ago
  It's a very complex problem to solve and I think a lot of people need to accept that. There will never be a simple solution with a low learning curve that's actually performant for non-trivial applications without a fundamental shift in browser technology.
  - myaccountonhn 3y ago
    I think elm showed that it is possible to build a solution with a low learning curve. Sadly elm hasn't really taken off but as far as frontend goes... it is just so simple together with elm-ui.
  - rglover 3y ago
    There is. I was frustrated by all of the chaos and built a solution [1]. Not too far off from an RC1 and then a 1.0 (which is being done slowly so I can freeze APIs and avoid the typical JS rug pulls). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- agloe_dreams 3y ago
  The problem is CSS. CSS is so freaking complex with millions of possible outcomes. https://www.w3.org/Style/CSS/all-properties.en.html https://www.w3.org/Style/CSS/all-properties.en.html Building a declarative UI that compiles to that sort of declaration means building that from scratch. We do currently work like that though. React isn't that far and web components built into an element of that.
davetron5000 3y ago
Web Components are not a replacement for React. They are a thing you would use to build React if you were to do so today. To use only Web Components, you will be writing a lot of low-level code using the browser's API, or you will have to use a framework built on Web Components
- gitaarik 3y ago
  For me it's a perfect replacement for React. I've been using it for years, and I'm much more happy about it than React. And I was already very happy with React compared to before that. I think it's the logical next step, but you need to unlearn some React concepts and relearn some Web Component concepts before you are really comfortable with it. But when you know how to work with it it's really super nice, and you'll appreciate better understanding the powerful browser and DOM APIs.
- troupo 3y ago
  > They are a thing you would use to build React if you were to do so today. No, you wouldn't. Very few JS frameworks (however new they are) use web components as their foundation for many, many, many reasons.
dberg 3y ago
unrelated to the content, but what a gorgeous font that is
- pvorb 3y ago
  I'm mostly distracted by it. The cursive parts in particular are distracting me from the actual content, so, while it looks somewhat nice, it does a disservice. At least that's the case for me. A good font should go out of my way in my opinion. When I don't notice it at all, the font is perfect. Android default fonts definitely fall in this category, for example.
3cats-in-a-coat 3y ago
No they don't eliminate anything. Framework never HAD to have a lock-in. They WANT to have a lock-in. They want to have a flashy site, with short sexy demos, and to give you slogans to repeat, and create in you a sense that all your struggles as a developer were caused by %PREVIOUS_TECH%, that you've been wronged and now you get to be a part of a revolution. And they want to CAPTURE you. This is why 99% of frameworks have a deliberately monolithic and isolating architecture, where it's all in, or all out. You don't want to miss the revolution are you? Are you stupid? Of course you're not stupid. So now your apps are locked in. And Web Components won't stop frameworks from finding highly specific ways to be "useful" in a way where you need to do everything in them. The solution is to know how to architect your app and stop believing marketing BS. Otherwise you'll keep fleeting to the Next Big Thing (tm) and never realize why it always ends the same way.
auggierose 3y ago
As far as I can see, web components take only strings as arguments. That alone disqualifies them from being a serious component framework. I've looked at them only for a short time last month, because I was excited about a web native component framework, but they provide basically nothing I would expect from such a framework. They are not even in the same arena as React.
- WickyNilliams 3y ago
  Strings as _attributes_, yes. But that's par for the course when it comes to html (boolean attributes aside). However, anything can be passed as a _property_. React operates on properties by default (hence `htmlFor` and `className`, not `for` and `class`). In fact, react's upcoming improved WC support will first do an `in` check on a property name before falling back to attribute. This is similar in vue etc. So yes if you're only authoring plain html you're confined to primitives, but if you're using a framework or WC lib, they almost certainly support properties
  - auggierose 3y ago
    I see, interesting. That's certainly helpful. Still, I don't see what problem web components solve. New custom html tags? Nice, but useless. And if I have to use a framework or WC lib on top of web components... Well. Nothing gained, it is just switching one framework for another. I am not against that at all, in fact I am writing my own framework for specific reasons. But let's not pretend that web components are a solution to anything, or that there are specific reasons why it needs to exist.
- djrenren 3y ago
  > They are not even in the same arena as React. This is 100% correct. I think a lot of the disappointment about web components comes from a mismatch in expectation between the spec writers and what people when they think "components". Web Components allow you to make new HTML elements. That is, you can make new kinds of DOM nodes out of other DOM nodes. This is powerful, but the resultant API is still a DOM-level API, and not a full templating system like React. On the other hand, because all these templating systems (React, lit, svelte, etc.) ultimately boil down to a series of DOM manipulations, this allows you to create a kind of element that can be plugged into all of these systems. Custom elements are a lot more akin to the C ABI. Than a fully featured framework.
jatwork 3y ago
Do we see a future where the web development free of these frameworks?
- sesm 3y ago
  When browsers implement some API to efficiently synchronize state with UI a-la React.
jdmg94 3y ago
> We’ve seen a lot of great posts about web components lately. where? I work at a fairly big org that some time ago decided to bet on web components. Everyone I work with (including me) hates it.
itslennysfault 3y ago
I like the idea of web components, but really dislike html and js being intermingled (the reason I don't like React/JSX). In web components its even worse because its HTML as a string which means it has no validation and isn't syntax aware. I much prefer the angular approach where you have separate css,html,ts files, and would love a web component framework that could work similarly. Searching for this I found some kinda hacky solutions on Stack Overflow which use fetch to load html/css at runtime.
- paulddraper 3y ago
  > its HTML as a string Can you explain what you mean by that?
  - IshKebab 3y ago
    React uses JSX/TSX which is much better because it is syntax checked and even type checked in the case of TSX.
  - thfuran 3y ago
    Html as a string literal in code rather than the html being in a separate .html file.
  - itslennysfault 3y ago
    This is the example from the article, and pretty common practice for web components. As far as an IDE is concerned this is just a string of text (it doesn't know/care that it is html). This makes it more error prone as the IDE can't catch syntax errors in the html. connectedCallback() { this.shadow.innerHTML = ` <p>Hello from a web component!</p> <style> p { color: pink; font-weight: bold; padding: 1rem; border: 4px solid pink; } </style> `; }
    - paulddraper 3y ago
      Well, you can use `innerHTML` and a string, but you don't have to. But there several alternatives: 1. Use DOM APIs (createElement). 2. Fetch the HTML as a separate resource. 3. Have the HTML in a separate file and bundle it with a bundler. 4. Use React/JSX. 5. Use a preferred templating library of your choice. You can do whichever of these you like the most
byyll 3y ago
I wonder how the preview on hover was made.
adam_arthur 3y ago
People discussing writing Web Components by hand are missing the point. Web Components, once adequately specced, will become a compile target for higher level frameworks like React and Vue. That way you still get the benefits of higher level frameworks but the components can interoperate with each other. Vue CLI already supports compiling down to a WebComponent, though not sure how first class it is. There are far too many lacking ergonomics to expect writing Web Components by hand to become popularized/convention
- jdmg94 3y ago
  I work at a big org and we use Stencil to produce UI kits using web components. In my experience and the anecdotal experience of the people in adjacent orgs that work with web components too: Its still a shit show.
  - adam_arthur 3y ago
    Yes, the Web Components spec is incomplete and not adequate for real-world use currently. But the end state will be as a compilation target, not as a development platform.
    - troupo 3y ago
      We're still at least 20 specs away from them being "adequately specced": https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html And there are multiple other issues that make web components a very unattractive compilation target.
claytongulick 3y ago
I've been using Web Components in production for years with great success. My guiding principles: - Avoid shadow dom unless it's a library. Stick with the light DOM and css system of your choice. - Use lit-html or similar for rendering - Use class properties for reactivity (add a render() call to setters, as needed) - Ignore attributes entirely. Just use properties. - Don't bother with composable components and slots. You generally don't need them - Use a nice router like vaadin or ionic or similar to hoist components and support deep linking - Let components maintain their own state. Structure the dom so that it's easy to grab state from a component with querySelector. If this doesn't work, I have a little state lib called ApplicationState[1] that works great. - Really think about what needs to be a component vs normal html. Don't overdo it with components. - Structure the app with high level "scene" components that map to URL deep links, and app components that you use to build the scenes. Scenes are targets of the router. [1] https://claytongulick.github.io/applicationstate/ https://claytongulick.github.io/applicationstate/
darig 3y ago
[dead]
djrenren 3y ago
Please remember that Web Components are much more akin to an ABI for web projects and not a full-featured framework. Any web component easily plugs into React, svelte, lit, etc. Existing components written in those frameworks can pretty easily be wrapped in a web component. It's a common base-layer we can all use. If you attempt to build a web app using just web components and no libraries, you'll quickly find that you're doing lots of manual DOM updates (no templating engine) and lots of manual state management (no data management API). As an ABI, it's wildly successful. It does, in fact, just work. It's just very low level.
- gitaarik 3y ago
  That is why we have a library to make it easier to work with these low level functions: Lit. And because Lit uses these functions, it can be a lot more lightweight compared to React & Angular etc.
riquito 3y ago
It's not all that shiny. Web components have global names (you should pretty much apply a prefix/namespace if you want to work with others) and managing multiple version of the same component in the same page is an issue in any non trivial codebase (either use a different name per version or fix all breaking changes at once during the upgrade, unless the draft about scoping web elements became standard https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... )
chiefalchemist 3y ago
> To prove it, we’re going to do something kinda crazy: build an app where every single component is written with a different framework. Interesting exercise. But now I wish she/he would one-by-one replace each framework with web components, so that in the end, there are no frameworks, only web components. As in, "Oh shit! We're going to abandon Vue (or React, etc.) and replace it with web components" or "We've been taked to only use web componentst, and no frameworks." What does that migration / transformation look like? Isn't that a likely scenario?
deleted 3y ago
[deleted]

263 points by jakelazaroff 3y ago

I don't think there's a need to cause a stir and generate hate for either Web Components or React. We should hate both equally. Either approach is frankly an embarrassing way to build complex interactive applications. Web tech is just way too low level, batteries not included. We've added mountain of complexity to deal with it but it doesn't hide that the fundamentals are broken and that productivity is low.

socketcluster 3y ago

The main problem with the Shadow DOM which makes people avoid it is the inability to use CSS externally to style the elements which are generated internally by the component... This is unfortunate because the Shadow DOM is essential if you want to work with child components slotted into it from the outside. This opens up many use cases. There is one alternative which is not being considered; it's possible for components with a shadow DOM to inject their elements into the Light DOM (where they can be styled/skinned externally with CSS), you just have to make the user slot a div (or other element) from the outside to act as a 'viewport' so that the component can inject its children into it (instead of injecting them into its Shadow DOM). With this approach, you can still access slotted elements. It's an ideal pattern for situations where you want the component to generate child elements from a slotted template. I wrote an article about this approach here: https://dev.to/jondubois/web-components-the-template-viewport-pattern-for-the-shadow-dom-2gm4 https://dev.to/jondubois/web-components-the-template-viewpor...

djrenren 3y ago
This is a great approach for components that want to inherit all styling from their context. In cases where you want to introduce just a little styling, the CSS Parts API is really cool: https://developer.mozilla.org/en-US/docs/Web/CSS/::part https://developer.mozilla.org/en-US/docs/Web/CSS/::part
- socketcluster 3y ago
  Thanks for pointing this out. I should probably mention this approach in my article for cases when you need to work with slotted elements but don't want to inherit all page styles.
aitchnyu 3y ago
Is there a comparison between light and shadow dom for webcomponents? I kinda want the simplicity of applying light dom css. Svelte doesnt support slots in light dom, I want to know the other caveats of light dom.
gitaarik 3y ago
Cool solution. I'm using Lit, and implemented a different approach to this problem. I created a way to easily apply a set of styles to particular components, by using a mixin class: const myStyles = litStyle(css`h1 { color: red; }`); class MyComponent extends myStyles(LitElement) { // ..} You can store the style definition in a separate file and import it and use it for the components that you want it for. https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style

dang 3y ago

Recent and related: Web components will outlive JavaScript frameworks - https://news.ycombinator.com/item?id=38012662 https://news.ycombinator.com/item?id=38012662 - Oct 2023 (244 comments)

yohannparis 3y ago

Thank you for the great read! The last few weeks have seen a lot of thought on HTML web components, and I'm really happy about it.

xutopia 3y ago

I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore. I'm all for web components!

joshstrange 3y ago
In your opinion what is the “really bad thing” that React/Angular have resulted in? Is it just the fewer full stack devs? I mean I’m a full stack dev still while using Vue. But also specialization (at a certain scale) is nearly unavoidable.
lopis 3y ago
This is not my experience at all. Why can't a full stack dev know react or angular?
- schwartzworld 3y ago
  Apparently because learning anything more than the minimum necessary to put pixels on a page makes you a specialist?
- codegeek 3y ago
  GP didnt say that. They said lot of devs become "front end" or "back end" specialists which means that they cannot do full stack. Full stack devs knowing React is fine. The problem is that most "React devs" don't know full stack and most "backend devs" don't know full stack.
  - zztop44 3y ago
    Why does being a front end or back end specialist mean you can’t do full stack? If I’m a full stack dev that’s a back end specialist I can still write a complete feature myself just fine, thank you very much. But of course, if I’m having trouble with some part on the front end I might ask a front end specialist colleague for help, and vice versa.

shadowgovt 3y ago

My hair always bristles a bit when I see plans to "eliminate JavaScript Framework Lock-in." For a backend service, it doesn't matter if you use no framework or one or five, other than pain for your developers having to learn the complexity; storage is so cheap it's nearly free, executable RAM slightly less so, and the end-user doesn't care how complex your server is. Frontend code gets pushed over a wire to your end-user. If you're using three overlapping frameworks to build one web service frontend purely because someone in your team likes Svelte and someone else likes React... that's a problem. You'll be pushing more bytes than you should to your end-users, and that cost doesn't scale the right way; in fact, the more popular your app, the more redundant bytes you'll be passing. We don't want to enable multiple frameworks in the UI. We should be settling on one and committing everyone on the frontend team to using it (ideally lock-stepped to the same version of it) within each app-shaped thing we create as a frontend team.

politelemon 3y ago
It isn't a standard HN post if it isn't claiming $new_technology will eliminate $old_technology.
jakelazaroff 3y ago
Author here — I feel like I addressed this point in the article, no? Obviously using a zillion frameworks in your app is a bad idea, but there are a bunch of actual reasons that encapsulating and/or mixing frameworks might be useful: - Gradually migrating from one framework to another - Including interactive "islands" within a static or server-side rendered page - Using a dependency only available in one framework from within another (this works best if the dependency framework has a small footprint — e.g. using Svelte within React is better than vice versa)

willsmith72 3y ago

i did this back in 2019 to make the transition smoother between angular.js and react > there are ways to build a web app other than writing the entire thing with a single JavaScript framework totally agree, and reducing rewrites or making converting them into "strangler" rewrites is a huge win on the other hand, it reminds me of the microservices hype a few years back. Just because you can, doesn't mean you should. Uniform languages, frameworks, coded patterns make things SO much smoother for an organisation. I would repeat the author's words of warning: "you should not build a real app like this!". you should seriously think hard before adding this level of complexity to any production app

dbingham 3y ago

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to build on React are doing it largely out of habit. I'm going to withhold my own thoughts about that quote, cause I'm curious what everyone else thinks. Wrt. Web Components, I played around with Web Components about half a decade ago and they felt promising but not ready for prime time yet. They were pretty messy and felt like they did a poor job of encapsulation. (At least at the time.) I haven't looked at them recently, but the code examples in these articles look much better (and cleaner) than what I remember. [1] https://adactio.com/journal/20618 https://adactio.com/journal/20618

troupo 3y ago
> They were pretty messy and felt like they did a poor job of encapsulation, ultimately. (At least at the time.) They are still messy. https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html
wayfinder 3y ago
As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do that in JS and every custom way you invent looks like trash. Doing something like this.shadow.innerHTML = `your HTML` with web components is terrible. document.createElement() is terrible. $('div').appendChild() is terrible. <script language="html" name="my-template"></script> is terrible. HTML(Div(Strong(text))) is terrible*. Storing templates as JSON and writing a one-off loader is terrible. <div style="display:none">template</div> is terrible. I've done it every possible way and they are all terrible. JSX fixed all that. The biggest previous attempt at something like JSX was E4X where you could embed XML straight into JS, which was kinda nice except it added the entirety of XML and its complexity. I creamed when it came out but then I tried it and it was not it. (E4X ended up surviving a little longer in Adobe Flash though.) E4X: https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML *This is what JSX compiles to behind the scenes.

sohzm 3y ago

lit.dev is awesome. I am a backend dev so I don't really want to get into the intricates of React or Angular. But if I need some reactivity for some complex element, I use lit. It's awesome

deleted 3y ago
[deleted]

troupo 3y ago

They don't. When your tech needs 20 more web specs [1] to fix stuff that literally no one has issues with, it means that you will be locked in to frameworks that solve these issues. Literally right now Web Component SSR is a framework-specific barely working non-solution. Even the most ardent web component proponents have given up and advocate a framework lock-in with lit-html and others. [1] https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html

tauchunfall 3y ago

I recently rebuild some parts of a large APM (application performance monitoring) solution to find out how much JavaScript is needed to have similar functionality (minus the backend, of course), e.g. faceted search. It's interesting how much of a component system one can build only by using `<input>`, `<label>`, and `<form>`. For the remaining interactive elements that can't be build easily without JavaScript I plan to use Web Components. For me this is a reasonable 80-percent solution. But for web applications with high requirements I would use React and React-Aria components/hooks.

oblak 3y ago

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve a number of problems that are not directly solved by Web Components. State management, rendering, routing - right now, these are, imho, the high level areas that need solid solutions for an UI app to function in any sane way. How much of that is solved by going Web Components?

DarkNova6 3y ago
A foolish consistency is the hobgoblin of the little mind
earthboundkid 3y ago
"Web Components" are the name for a dream, not an actual technology. The actual technologies involved -- customElement and shadow DOM -- are pretty crappy to use directly, and even when hidden behind a framework/library don't buy you that much. But people want it to be true that there is such a thing as a "Web Component" so the dream lives on.
- gitaarik 3y ago
  Why do you think this? I've been using it for years and it works lovely, no complaints at all.
spankalee 3y ago
I work on Lit, which I would hesitate to call a framework, but gives a framework-like DX for building web components, while trying to keep opinions to a minimum and lock-in as low as possible. It's got reactivity, declarative templates, great performance, SSR, TypeScript support, native CSS encapsulation, context, tasks, and more. It's used to build Material Design, settings and devtools UIs for Chrome, some UI for Firefox, Reddit, Photoshop Web... https://lit.dev https://lit.dev if you're interested.

earthboundkid 3y ago

No, they just lock you into one framework per component. I don't know why people say obviously false stuff like this about web components besides they just really, really want it to be true. Yeah, if you're willing to have the same framework on the page ten times, you can just chuck them all in separate script tags using the custom element API. But if you care about making a performant page with progressive enhancement, etc. this is a bad strategy. Even the name "web components" is basically just marketing fluff. When people say "web component", they mean using two particular DOM APIs: customElement and shadow DOM. Those are both pretty niche APIs. There are some cases where they are helpful, but 99% of the time, they don't add much to a project versus good old querySelectorAll and normal CSS.

jakelazaroff 3y ago
Author here — I'm not sure what you mean by "lock you into one framework per component". The point is that you can encapsulate framework code within web components, not that every component you write should be a web component. Let's say you're writing a Vue app and you really want to use a library that's only available as a React component. You can wrap that library in a web component and use it in your Vue app just like you would any other HTML element. The rest of your app can continue being Vue, using normal Vue components.
- jdmg94 3y ago
  except you can't use it as a normal component, you can't adjust its CSS normally, you have to `&::part()` your way around and hope for the best. Accessing through refs is a complete blackbox. I work with web components daily and it is a hindrance to my daily work, it is very common for people at my org to just re-write a component instead of using its web component version.
  - mmis1000 3y ago
    I also wonder about this. The webcomponent make the style completely immutable unless you add part selector specifically… how on the earth this is even useful? Imagine using an ui library that you can't change the style at all. That sounds like a total joke to me. That isn't even a sane default that is useful to most web folks that make page base on layout that designers gave.

djrenren 3y ago

I've found webcomponents to be really good at encapsulating anything that doesn't directly query application state. Specifically there are two type of components that really thrive as web components (as opposed to react): 1. Highly interactive components - Components that implement complex interaction management (but sort of agnostic to application state) are ideal web components. You don't need to mess around with `useEffect` or `useMemo`. You get really tight control of rendering and state updates. 2. Highly internally stateful components - Components that track a lot of state that doesn't escape the component, work great as web component. You get strong encapsulation without a framework requirement. React conflates two concepts that I think are better when separated: templates, and components. Templates provide a "re-render the world" approach, and components encapsulate state and interaction patterns. Conflating these two things causes the standard useEffect and useMemo headaches. It also means that any consumer of your component, must also use your templating system (react's render function). The `lit` library does this separation extremely well, allowing you to implement components using templates if you want, or not. And consumers do not care how the internals are implemented.

jongjong 3y ago
I find that they can work very well with state but since state is typically passed via attributes (downstream), it means that components can only share state with each other via strings. I found this to be an advantage, not a drawback because simple interfaces are at the core of my coding philosophy and strings make it infeasible to pass complex instances or functions to other components.
- djrenren 3y ago
  Well, this is only sort of true. When you’re writing HTML you’re restricted to attributes but custom elements are JavaScript objects and are free to respond to property updates on the object. Relying solely on strings is a limitation of your templating engine. For example lit-html templates support syntax like: <my-element .someProp=${new Foo()}></my-element>
  - 3y ago

toasted-subs 3y ago

Pretty excited to see all those job posts for react disappear.

preommr 3y ago

Web components are a half-baked solution. It only becomes useful with another framework (even if it's very lightweight) like lit. At which point I might as well use vue/react/svelte since I am already brining in a library. Tech like preact is really lightweight as well, and given the popularity of react, is enough to offset any benefits web components have. I would really like it if we reached a point where a web project only had a single dependency that's a bundler like vite that you point to an index file, and that's it.

OJFord 3y ago
I think we're going in the opposite direction though - everyone wants to hide what's going on and use some magic CLI that just takes care of everything for you, don't worry about how or when or what to do if it goes wrong, just run `flyctl deploy`, `wrangler publish` (Cloudflare), `npx wizzle wazzle` :sparkles: :tada: never `git commit -m '(chore): [...]'` again! Oh and here's a readme example of how to set that up if you're using pnpm v42 with sveltekit v2 and webpack v99. For any other combination of the 5 packagers, 19 bundlers, and 56 frameworks commonly in use and giving examples like this recommending each other - have fun.
reidjs 3y ago
I use them for a basic website (no build step) for things like navigation components and page templates. They are great for that, but not much else in my experience. Once you have a complex UI or multiple devs on a project it’s probably better to just use a full framework
codegeek 3y ago
"half-baked solution" Can you elaborate further ? Anything that removes dependencies from external libraries is a huge plus for me so I am curious as someone who is not great at JS.
- troupo 3y ago
  > Can you elaborate further ? As you read the following, keep in mind that at this time Web Components have been in development for almost 12 years. The core is just three standards, CustomElements, Shadow DOM and HTML Imports (already deprecated and removed in favor of JS-only imports). And people will go out of hteir way to sell you the idea that this is lightweight, all that you need etc. However. They've already spawned half a dozen new web standards just to deal with issues they inflicted on themselves. None of these issues are present in any other solution/lib/framework that exists. These range from the fact that web components cannot participate in forms (fixed with a new spec: https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls) to their inability to share stylesheets (fixed with a new spec: https://web.dev/articles/constructable-stylesheets https://web.dev/articles/constructable-stylesheets) to whatever else (hard to keep track). They will need at least 20 more new web standards to fix other issues that, once again, are not a problem for literally every other framework, library, or hand-written code under the sun: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html. Among my favorite ones: a web component button cannot be a submit button in a form; you cannot reference an id inside a shadow root, and that breaks ARIA. To call them half-baked is an understatement. They are badly thought-out, badly implemented APIs with no forethought or visible planning, and literally no end goal in sight. The people building this met to hash out what more is needed for them to be complete only last year, 11 years into development. All development before that looked like ad-hoc patches by people surprised that a yet another thing doesn't work, but is sorely needed.

tannhaeuser 3y ago

In case anyone was wondering, JavaScript per se isn't replaced at all. All mentioned examples still use event listeners, querySelectorAll, ES modules, and what not. Most importantly, you need to subclass HTMLElement and register your custom element using JavaScript in the first place eg: class MyElement extends HTMLElement { } window.customElements .register('my-element', MyElement) (the hyphen in the name is idiosyncratically required by the custom element spec). As such, "HTML web components" (aka custom elements, which have be around for many years) are targeted at developers not hypothetical web users/authors. Then what is the point? When you're relying on JavaScript anyway, you have already much greater freedoms - syntactically and otherwise. Custom element declarations and custom vocabularies can make sense as a means to organize and isolate authoring concerns when you're creating hypertext documents. The fact alone that you have to use JavaScript for registering custom elements make them a non-starter though (ie consider an authoring tool which surely doesn't want to execute arbitrary JavaScript in client docs). It's not that there's no precedent either. SGML has a mechanism for parametric macro expansion where your element is syntactically replaced into an arbitrary markup fragment, with type-checked arguments (= attributes at the call site, just as with custom elements), and with type-checking the resultant expansion in context (ie. checking whether the expansion adheres to the content model at the expansion site), also having of course the capability to include JavaScript. Moreover, SGML actually can serialize/re-parse such markup whereas HTML's preliminary APIs for fragment parsing won't deal with contextual tag inference at all.

runarberg 3y ago
For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change. <script type="module"> import lib from "/path/to/my/lib.js"; for (const target of document.querySelectorAll(".target")) { lib(target); } // TODO: Watch for DOM change and apply lib. <script> <span class="target">Some Input</span> Or I can simply ask them to import my web component module and use the custom element: <script src="/path/to/my/web-component.js"></script> <my-lib>Some input</my-lib> The latter certainly feels like a superior API for my users.

megaman821 3y ago

I don't feel like web components and React should compete for most people. Web components feel pretty good at making leaf components, especially when they will be used with multiple technologies. I tried using React to only make a single component for use within a larger React app and within a Django site, and it was not as smooth as a web component. Also, I tried to make a web component app and there was way more friction and less tooling than a React app. As it stands now, I wouldn't use React for single component nor web components for an entire app.

r3trohack3r 3y ago

For folks looking for a lightweight JS class that manages the lifecycle of Web Components, I have this little Template class I use in many of my front-end projects. It's able to manage the application state by pushing the state down through the application and bubbling changes up. It's a 161-line file that's easy to reason about and modify as needed. https://github.com/retrohacker/template https://github.com/retrohacker/template

switchbak 3y ago

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we could talk declaratively at a high level about the kinds of interfaces we want to render and where the data lives. Hopefully I'm wrong and the magic is buried under some Elm tree or a React library or something. Something something get off my lawn...

metadaemon 3y ago
It's a very complex problem to solve and I think a lot of people need to accept that. There will never be a simple solution with a low learning curve that's actually performant for non-trivial applications without a fundamental shift in browser technology.
- myaccountonhn 3y ago
  I think elm showed that it is possible to build a solution with a low learning curve. Sadly elm hasn't really taken off but as far as frontend goes... it is just so simple together with elm-ui.
- rglover 3y ago
  There is. I was frustrated by all of the chaos and built a solution [1]. Not too far off from an RC1 and then a 1.0 (which is being done slowly so I can freeze APIs and avoid the typical JS rug pulls). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
agloe_dreams 3y ago
The problem is CSS. CSS is so freaking complex with millions of possible outcomes. https://www.w3.org/Style/CSS/all-properties.en.html https://www.w3.org/Style/CSS/all-properties.en.html Building a declarative UI that compiles to that sort of declaration means building that from scratch. We do currently work like that though. React isn't that far and web components built into an element of that.

davetron5000 3y ago

Web Components are not a replacement for React. They are a thing you would use to build React if you were to do so today. To use only Web Components, you will be writing a lot of low-level code using the browser's API, or you will have to use a framework built on Web Components

gitaarik 3y ago
For me it's a perfect replacement for React. I've been using it for years, and I'm much more happy about it than React. And I was already very happy with React compared to before that. I think it's the logical next step, but you need to unlearn some React concepts and relearn some Web Component concepts before you are really comfortable with it. But when you know how to work with it it's really super nice, and you'll appreciate better understanding the powerful browser and DOM APIs.
troupo 3y ago
> They are a thing you would use to build React if you were to do so today. No, you wouldn't. Very few JS frameworks (however new they are) use web components as their foundation for many, many, many reasons.

dberg 3y ago

unrelated to the content, but what a gorgeous font that is

pvorb 3y ago
I'm mostly distracted by it. The cursive parts in particular are distracting me from the actual content, so, while it looks somewhat nice, it does a disservice. At least that's the case for me. A good font should go out of my way in my opinion. When I don't notice it at all, the font is perfect. Android default fonts definitely fall in this category, for example.

3cats-in-a-coat 3y ago

No they don't eliminate anything. Framework never HAD to have a lock-in. They WANT to have a lock-in. They want to have a flashy site, with short sexy demos, and to give you slogans to repeat, and create in you a sense that all your struggles as a developer were caused by %PREVIOUS_TECH%, that you've been wronged and now you get to be a part of a revolution. And they want to CAPTURE you. This is why 99% of frameworks have a deliberately monolithic and isolating architecture, where it's all in, or all out. You don't want to miss the revolution are you? Are you stupid? Of course you're not stupid. So now your apps are locked in. And Web Components won't stop frameworks from finding highly specific ways to be "useful" in a way where you need to do everything in them. The solution is to know how to architect your app and stop believing marketing BS. Otherwise you'll keep fleeting to the Next Big Thing (tm) and never realize why it always ends the same way.

auggierose 3y ago

As far as I can see, web components take only strings as arguments. That alone disqualifies them from being a serious component framework. I've looked at them only for a short time last month, because I was excited about a web native component framework, but they provide basically nothing I would expect from such a framework. They are not even in the same arena as React.

WickyNilliams 3y ago
Strings as _attributes_, yes. But that's par for the course when it comes to html (boolean attributes aside). However, anything can be passed as a _property_. React operates on properties by default (hence `htmlFor` and `className`, not `for` and `class`). In fact, react's upcoming improved WC support will first do an `in` check on a property name before falling back to attribute. This is similar in vue etc. So yes if you're only authoring plain html you're confined to primitives, but if you're using a framework or WC lib, they almost certainly support properties
- auggierose 3y ago
  I see, interesting. That's certainly helpful. Still, I don't see what problem web components solve. New custom html tags? Nice, but useless. And if I have to use a framework or WC lib on top of web components... Well. Nothing gained, it is just switching one framework for another. I am not against that at all, in fact I am writing my own framework for specific reasons. But let's not pretend that web components are a solution to anything, or that there are specific reasons why it needs to exist.
djrenren 3y ago
> They are not even in the same arena as React. This is 100% correct. I think a lot of the disappointment about web components comes from a mismatch in expectation between the spec writers and what people when they think "components". Web Components allow you to make new HTML elements. That is, you can make new kinds of DOM nodes out of other DOM nodes. This is powerful, but the resultant API is still a DOM-level API, and not a full templating system like React. On the other hand, because all these templating systems (React, lit, svelte, etc.) ultimately boil down to a series of DOM manipulations, this allows you to create a kind of element that can be plugged into all of these systems. Custom elements are a lot more akin to the C ABI. Than a fully featured framework.

jatwork 3y ago

Do we see a future where the web development free of these frameworks?

sesm 3y ago
When browsers implement some API to efficiently synchronize state with UI a-la React.

jdmg94 3y ago

> We’ve seen a lot of great posts about web components lately. where? I work at a fairly big org that some time ago decided to bet on web components. Everyone I work with (including me) hates it.

itslennysfault 3y ago

I like the idea of web components, but really dislike html and js being intermingled (the reason I don't like React/JSX). In web components its even worse because its HTML as a string which means it has no validation and isn't syntax aware. I much prefer the angular approach where you have separate css,html,ts files, and would love a web component framework that could work similarly. Searching for this I found some kinda hacky solutions on Stack Overflow which use fetch to load html/css at runtime.

paulddraper 3y ago
> its HTML as a string Can you explain what you mean by that?
- IshKebab 3y ago
  React uses JSX/TSX which is much better because it is syntax checked and even type checked in the case of TSX.
- thfuran 3y ago
  Html as a string literal in code rather than the html being in a separate .html file.
- itslennysfault 3y ago
  This is the example from the article, and pretty common practice for web components. As far as an IDE is concerned this is just a string of text (it doesn't know/care that it is html). This makes it more error prone as the IDE can't catch syntax errors in the html. connectedCallback() { this.shadow.innerHTML = ` <p>Hello from a web component!</p> <style> p { color: pink; font-weight: bold; padding: 1rem; border: 4px solid pink; } </style> `; }
  - paulddraper 3y ago
    Well, you can use `innerHTML` and a string, but you don't have to. But there several alternatives: 1. Use DOM APIs (createElement). 2. Fetch the HTML as a separate resource. 3. Have the HTML in a separate file and bundle it with a bundler. 4. Use React/JSX. 5. Use a preferred templating library of your choice. You can do whichever of these you like the most

byyll 3y ago

I wonder how the preview on hover was made.

adam_arthur 3y ago

People discussing writing Web Components by hand are missing the point. Web Components, once adequately specced, will become a compile target for higher level frameworks like React and Vue. That way you still get the benefits of higher level frameworks but the components can interoperate with each other. Vue CLI already supports compiling down to a WebComponent, though not sure how first class it is. There are far too many lacking ergonomics to expect writing Web Components by hand to become popularized/convention

jdmg94 3y ago
I work at a big org and we use Stencil to produce UI kits using web components. In my experience and the anecdotal experience of the people in adjacent orgs that work with web components too: Its still a shit show.
- adam_arthur 3y ago
  Yes, the Web Components spec is incomplete and not adequate for real-world use currently. But the end state will be as a compilation target, not as a development platform.
  - troupo 3y ago
    We're still at least 20 specs away from them being "adequately specced": https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html And there are multiple other issues that make web components a very unattractive compilation target.

claytongulick 3y ago

I've been using Web Components in production for years with great success. My guiding principles: - Avoid shadow dom unless it's a library. Stick with the light DOM and css system of your choice. - Use lit-html or similar for rendering - Use class properties for reactivity (add a render() call to setters, as needed) - Ignore attributes entirely. Just use properties. - Don't bother with composable components and slots. You generally don't need them - Use a nice router like vaadin or ionic or similar to hoist components and support deep linking - Let components maintain their own state. Structure the dom so that it's easy to grab state from a component with querySelector. If this doesn't work, I have a little state lib called ApplicationState[1] that works great. - Really think about what needs to be a component vs normal html. Don't overdo it with components. - Structure the app with high level "scene" components that map to URL deep links, and app components that you use to build the scenes. Scenes are targets of the router. [1] https://claytongulick.github.io/applicationstate/ https://claytongulick.github.io/applicationstate/

darig 3y ago

[dead]

djrenren 3y ago

Please remember that Web Components are much more akin to an ABI for web projects and not a full-featured framework. Any web component easily plugs into React, svelte, lit, etc. Existing components written in those frameworks can pretty easily be wrapped in a web component. It's a common base-layer we can all use. If you attempt to build a web app using just web components and no libraries, you'll quickly find that you're doing lots of manual DOM updates (no templating engine) and lots of manual state management (no data management API). As an ABI, it's wildly successful. It does, in fact, just work. It's just very low level.

gitaarik 3y ago
That is why we have a library to make it easier to work with these low level functions: Lit. And because Lit uses these functions, it can be a lot more lightweight compared to React & Angular etc.

riquito 3y ago

It's not all that shiny. Web components have global names (you should pretty much apply a prefix/namespace if you want to work with others) and managing multiple version of the same component in the same page is an issue in any non trivial codebase (either use a different name per version or fix all breaking changes at once during the upgrade, unless the draft about scoping web elements became standard https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... )

chiefalchemist 3y ago

> To prove it, we’re going to do something kinda crazy: build an app where every single component is written with a different framework. Interesting exercise. But now I wish she/he would one-by-one replace each framework with web components, so that in the end, there are no frameworks, only web components. As in, "Oh shit! We're going to abandon Vue (or React, etc.) and replace it with web components" or "We've been taked to only use web componentst, and no frameworks." What does that migration / transformation look like? Isn't that a likely scenario?

deleted 3y ago

[deleted]