3 ms·

Well, if Stencil is a Web Component framework using native Web Component technologies and strategies, transferring from Lit to Stencil will probably be a lot ea

• troupo 3y ago
  > Well, if Stencil is a Web Component framework using native Web Component technologies and strategies, transferring from Lit to Stencil will probably be a lot easier than from React to Angular or something. Literally everything that's on the web is using "native technologies and strategies". Because there's nothing else. So, extraordinary claims require extraordinary proofs. I eagerly await a description, with examples, of how much work there is to convert a non-trivial lit component to Stencil. Why non-trivial? Because trivial components are easy to convert from anything to anything. You could convert a trivial React component into knockout.js, then to Angular, and then to Lit, and back, in under half a day even if you've never worked with those technologies before. > And there are actually not that many things specific to Lit I've listed a few of them. They are opinionated enough that lit code and stencil code are completely different and incompatible. Besides, there are a dozen or so libraries and frameworks that can, or do, compile to web components. Their code is also different from lit's. > But their main npm package [0] is 47.8 MB This is completely beside the point. We're not discussing Stencil, or the opinions its authors may or may not have taken.
  • gitaarik 3y ago
    Sorry but I think it is quite obvious that a large framework will create much more lock-in and dependency than a tiny library. The more specific stuff you use, the more you are locked in. And yeah Lit still does some things for you so there's always some lock-in, with any library that you use. So it's not about simply whether it is a lock-in or not, but the amount of lock-in. Lit doesn't need JSX and a virtual DOM, which are React specific technologies. You have to design your React components with these technologies in mind. With Lit there are much less dependencies like that, so your code will be less designed for a specific framework, making it easier to move to another framework that doesn't impose a specific workflow.
    • troupo 3y ago
      > Lit doesn't need JSX and a virtual DOM, which are React specific technologies. But lit needs lit's custom DSL, lit's custom reactive components, custom everything. Even in their most trivial example literally everything is custom, and specific to lit: import {LitElement, css, html} from 'lit'; import {customElement, property} from 'lit/decorators.js'; // custom lit-specific decorator @customElement('simple-greeting') export class SimpleGreeting extends LitElement { // custom lit-specific css function static styles = css` :host { color: blue; } `; // Custom, lit-specific reactive properties @property() name?: string = 'World'; // custom lit-specific render function render() { // custom lit-specific DSL return html`<p>Hello, ${this.name}!</p>`; } } So. So, extraordinary claims require extraordinary proofs. I eagerly await a description, with examples, of how much work there is to convert a non-trivial lit component to Stencil. BTW. Claiming that Virtual DOM is somehow a react-specific technology (and that somehow apparently affects conversion from React to something else) really shows how much you understand about the topic at hand.
      • gitaarik 3y ago
        That is a slight layer upon simple JavaScript string templates, nothing compared to JSX I would say Edit: hint: that is why Lit's library is also much smaller