Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

Post reply on HN
Print view View original

291–300 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#291

Post by ecmascript »

josephg wrote: post #167
mardifoufs wrote: post #144

Earlier quoted context omitted.

Exactly. I'm starting to understand the push for web UI now that I've started to use qt for a small GUI. I'm sure qt is good for some type of apps. But for my smaller scale project where the graphic interface is not where we want to spend most of our dev time, I'd rather take javascript/react at this point.

I feel the same after playing with SwiftUI and UIKit on iOS and trying to make something simple like a text editor with a hideable keyboard. The whole platform feels half baked, with various overlapping features that each have serious, barely documented drawbacks and bugs. “I’m getting a warning about my constraints being defined badly” “oh just ignore that - you can’t make it work without that warning”. “Everything…

And then you don't even have come to the real meat, the freedom the web gives you. Freedom to deploy whenever, freedom from app stores with arbitrary rules set by big boring corporate interests.

Why publish with restrictions when you can be free?

Re: Web Components Eliminate JavaScript Framework Lock-In

#292

Post by ecmascript »

Devasta wrote: post #101
ecmascript wrote: post #86

Earlier quoted context omitted.

I do front end stuff for a living and have been in the javascript space for several years. I do other backend development as well and I can't see why people think like you honestly. Most other GUI libraries is in a much worse state than front end web dev. That is probably also the reason why people use front end tech to make native apps today, because you can customize and make apps much faster than in basically any…

Devs use web frontend tech because it is installed on every machine, will never have anything less than the full backing of the browser devs for the next hundred years, and gets around corporate filters. No need to deal with IT security losers to get your app installed, no need to get ports opened, just everything down port 443 until the end of time. INTERCAL could win with that feature set.

If that is the case, why are people writing desktop apps with Electron / other web tech?

Re: Web Components Eliminate JavaScript Framework Lock-In

#293

Post by troupo »

gitaarik wrote: post #290
troupo wrote: post #286

Earlier quoted context omitted.

> Lit is really the littlest amount of tools you would want. - reactivity. Specific to lit - declarative templates. Specific to lit - SSR. Specific to lit. - context. Specific to lit. - tasks. Specific to lit - directives. Specific to lit "littlest amount of tools"

SSR, context and tasks are all separate packages, not in the Lit core package. The others are very basic functionalily for what you expect from a framework like Lit. It has to do something ultimately :D

> SSR, context and tasks are all separate packages, not in the Lit core package.

Splitting hairs

> The others are very basic functionalily for what you expect from a framework like Lit.

Indeed. Framework like Lit. These mental hoops and shenaningans lit defenders have to jump and go through to pretend lit is somehow not a framework and somehow different.

Literally the very first example you get on lit's own page show how invalid all those claims are: https://lit.dev/docs/components/overview/

Re: Web Components Eliminate JavaScript Framework Lock-In

#294

Post by troupo »

gitaarik wrote: post #288
troupo wrote: post #285

Earlier quoted context omitted.

> But yeah it is hard for most developers to adopt a new way of thinking. It's not "a new way of thinking". Things like functioning inputs, buttons, and ARIA are basic browser functionality . > And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. Not only it doesn't provide improvment, it needs 20+ new web standards to fix the issues that literally nothing else has.…

Any technology has issues and limitations. Many basic browser functionalties also don't work with the React workflow, and Lit brings those things back again, making it more native, and less need for framework code. It seems you are only focussing and zooming in on the issues and limitations. And there are issues and limitations in any technology. I think it has to do with adopting a different way of thinking and stru…

> It seems you are only focussing and zooming in on the issues and limitations.

The question literally was: "Can you elaborate further on why web components are a half-baked solution".

Did I say anything about React? No. Did I say anything about lit? No.

Stop making up what you think people are saying and start reading and understanding what people are saying.

> And there are issues and limitations in any technology.

Yes. Yes they are. And web components are literally the only technology that after 12 years in development needs 20+ web specs to not break basic functionality that literally no other technology breaks.

This has nothing to do with react. This has nothing to do with lit. Read what I wrote and not what I think I wrote.

> if you like React

> framework like React.

> keep using React.

> combination with Lit instead of React.

Jesus Christ.

Literally nowhere was I talking about React or lit. Not a single one of my comments in this thread had anything to do with either.

And yet you keep arguing with the voices in your head that are telling you that I'm talking about React.

> It does take some investment to learn a bit about how Web Components work.

So go ahead and learn about how they work, why don't you? Or, rather, about how they don't work, and why after 12 years they still need 20+ new web specs to to the most basic things.

Edit: from now on I will disengage from this conversation and sibling ones, because it is useless and pointless.

Re: Web Components Eliminate JavaScript Framework Lock-In

#295

Post by troupo »

gitaarik wrote: post #289
troupo wrote: post #284

Earlier quoted context omitted.

> 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 examp…

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, w…

> 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`
Hello, ${this.name}!
`;
      }
    }
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.

Re: Web Components Eliminate JavaScript Framework Lock-In

#296

Post by gitaarik »

troupo wrote: post #295
gitaarik wrote: post #289

Earlier quoted context omitted.

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, w…

> 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…

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

Re: Web Components Eliminate JavaScript Framework Lock-In

#297

Post by troupo »

gitaarik wrote: post #296
troupo wrote: post #295

Earlier quoted context omitted.

> 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…

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

I: list all the custom things that lit has

I: ask to show me how converting from lit to something else is easier as you claim

You: ignore everything completely and answer a question literally no on asked, and pretend that the only custom thing is the DSL.

Yup. My choice to completely ignore you in a sibling discussion was correct.

On the other hand, after a few years of engaging with web component defenders, propoenents and propagandists I'm not surprised in the least. This behaviour is on par with the rest of them.

Re: Web Components Eliminate JavaScript Framework Lock-In

#298

Post by EnergyAmy »

jakelazaroff wrote: post #238
EnergyAmy wrote: post #216

Earlier quoted context omitted.

Shadow DOM was a mistake. It's a 0.1 version that was unfortunately pushed out as a completed standard. Basic stuff is missing like your link. The entire thing should be deprecated and we should start from scratch. If you want to embed something that doesn't use your page's styles, we already have iframes. Shadow DOM is just a half-assed recreation of that.

How would you build, say, a component library like Shoelace [1] using iframes? [1] https://shoelace.style/

You wouldn't, but shadowroot is bad design for that. What's wrong with bootstrap or any other number of of existing frameworks? I don't want to include a button and have it stick out like a sore thumb because it ignores my page's styles. ::part() is a stupid hack to make up for a bad approach.

If you want to include something "as-is" (i.e. the demos you mention), use iframes. If you want to include a component like a button, use any of the existing frameworks that work just fine. Trying to build a button that pretends to be a browser-native component but actually isn't is a terrible idea.

Re: Web Components Eliminate JavaScript Framework Lock-In

#299

Post by gitaarik »

troupo wrote: post #297
gitaarik wrote: post #296

Earlier quoted context omitted.

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

I: list all the custom things that lit has I: ask to show me how converting from lit to something else is easier as you claim You: ignore everything completely and answer a question literally no on asked, and pretend that the only custom thing is the DSL. Yup. My choice to completely ignore you in a sibling discussion was correct. On the other hand, after a few years of engaging with web component defenders, propoene…

From all our arguments I think it's obvious that Lit has less lock-in than any other framework we discussed. If you find it so important to prove your point, why don't you make an exstensive comparison of all the discussed frameworks?

Re: Web Components Eliminate JavaScript Framework Lock-In

#300

Post by jongjong »

djrenren wrote: post #225
jongjong wrote: post #218

Earlier quoted context omitted.

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.

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:

Interesting. I recognize that lit-html is much more lightweight than React and others but personally I really like to avoid any magic at all and I like being forced to pass strings between components. It reminds me of an Alan Kay quote about OOP "The big idea is messaging". You want your components to be passing around messages, not state. This seems to go against FP philosophy but I've found that it really works for OOP. After all, OOP is traditionally about state encapsulation and prioritizing concern boundaries over logic/state boundaries as in FP.

Note that it's still possible to pass complex objects to native we components but only imperatively via properties so it's a lot higher friction (as it should be).

Post reply on HN