261–270 of 300 posts
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…
Earlier quoted context omitted.
Honestly, you don't. It's used for many Google projects like Chrome, parts of YouTube, Maps APIs, Collab, the Google Store, and a ton of internal things, so I think it's unlikely, but I understand Google's reputation. This is one reason why we care so much about low coupling and lock-in, and a small, easy-to-understand codebase. You should be able to migrate away from Lit very easily, and fork or maintain it if neces…
> It's used for many Google projects like Chrome, parts of YouTube... so I think it's unlikely, When Custom Components v0 was barely released Google re-wrote Youtube with Polymer. Where's Polymer now? > You should be able to migrate away from Lit very easily And that should comes from which part of lit? Custom DSL? Custom decorators? Custom data bindings? Custom tasks? As I wrote elsewhere, Preact, Svelte, Vue, and A…
So because it's small and doesn't need much new features, it's also easy for the community to maintain it. I think not much has changed in the Lit library over the last few years. So it's also easy with upgrading.
Earlier quoted context omitted.
> I personally saw a huge project ported from Angular to React basically doing the same. Do Angular and React components talk to each other? Lit and other Web component frameworks can share components. To refactor Lit components into other web component framework or raw web component is orders of magnitude easier than converting Angular React.
> Do Angular and React components talk to each other? You can make them talk to each other. Depends on what exactly you need, how components and projects are structured etc. > Lit and other Web component frameworks can share components. To refactor Lit components into other web component framework or raw web component is orders of magnitude easier than converting Angular React. You're putting a false equivalency betw…
you can make almost whatever you want with code but they weren't build for that. Besides that, both angular and react are bloated software, adding another layer to create web components version of their components is just more bloat. It took some time for chariots to be considered a legacy way of transport but you can't fight its obsolescence just by saying that chariots will also carry you from one place to another.
Earlier quoted context omitted.
There are a lot of things you can do with shadow DOM that you can’t with iframes or scope/donut selectors: - transclude other elements (technically you can with iframes, but hopefully it’s clear why making something like this breadcrumb component would be extremely awkward [1]) - control and react to the display of child elements via s - call methods on custom element objects etc etc. It’s fine if it doesn’t solve an…
Transclusion can totally be done with CSS now. That’s a donut selector. The other things are just plain old JavaScript and have nothing to do with Shadow DOM. Yes, they can be done with customElement, but they can also just be done without it.
Earlier quoted context omitted.
Lit's features are internal to each component (except context which is being developed as an open community protocol with the Web Components Community Group) and there is no coupling between components written in Lit. So you can port from Lit to something else component-by-component. Lit is also modular. The template library, lit-html, is usable independently and used by other web component and non-web component libr…
This is just splitting hairs in an attempt to pretend that lit isn't a framework (or framework-like lib), or that it's somehow unopinionated, or that it somehow prevents you from lock-in. Almost all of the things you listed are specific to lit, and lit only. So, people who will develop with lit will be locked in to lit. Because it's not like you can just pop the code you wrote with lit into stencil or ionic, and will…
Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality.
So I don't really see the issue with vendor lock-in here. Most logic regarding your app is not gonna have anything to do with Lit. Only the way the templates are structured is a bit specific. But it is way less specific than JSX. Because it's just normal HTML with a few specific attributes to easily bind event listeners on HTML elements.
So Lit basically just gives you easy access to powerful browser APIs, making it really easy to build complex webapps without using a big framework.
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…
"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.
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 k…
You can use ` ` for that purpose and keep your separation of concerns okay.
Earlier quoted context omitted.
The server is typically not a retained-mode kind of abstraction. Incremental view maintenance in retained-mode MVC systems is the main source of bugs. If you render the view from scratch on every request, it's more similar to React style immediate-mode UI than something like UIKit where you end up handling many UI events and keeping little bits of the UI up-to-date with model changes incrementally.
You can render the view from scratch on every user interaction, even in MVC. In fact, you can use React for that purpose. "Lots of people use React as the V in MVC." See that quote on this page: https://github.com/facebook/react/tree/015833e5942ce55cf31ae... Personally, I have not run into large amounts of bugs of this type, and I have written plenty of MVC code using VanillaJS.
Earlier quoted context omitted.
"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.
> 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…
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 compone…
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.