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

241–250 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#241

Post by mardifoufs »

breadwinner wrote: post #189
jitl wrote: post #64

Earlier quoted context omitted.

The server side style of MVC you describe is a far stretch from how MVC is practiced in retained-mode UI frameworks like UIKit, Cocoa, or Backbone. It’s possible to make this style work fine with careful design and planning; Apple built web versions of Pages and Keynote using SproutCore (which evolved into Ember?) in 2013-era. In fact back then, everyone’s big app was MVC - usually Backbone. I worked on Airbnb’s host…

MVC is a proven and popular technology. It works very well, otherwise it wouldn't be so popular. I notice you allude to "problems we all experienced with MVC" without mentioning any . Surely if there are so many problems, you would be able to mention one?

Well React is also a proven and popular technology, so there must be a reason why those using it chose it instead of using MVC.

Re: Web Components Eliminate JavaScript Framework Lock-In

#242

Post by shortrounddev2 »

yCombLinks wrote: post #228
shortrounddev2 wrote: post #193

Earlier quoted context omitted.

> Html and css is a terrible API for app layout, because it wasn't designed for that And yet it's so easy and forgiving that millions of 13 year olds learned it for their myspace and tumblr pages over the last 15 or so years. Somehow, despite all the CS graduates and 20 year software engineering veterans bemoaning it, more and more people learn HTML, CSS, and Javascript every day while the number of people learning n…

Those aren't apps, they're closer to documents, which is what it was designed for.

Wanting it to be that way doesn't make it true

Re: Web Components Eliminate JavaScript Framework Lock-In

#243

Post by steve_taylor »

toasted-subs wrote: post #36
oblak wrote: post #16

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…

Svelte compiles into WebComponents.

That’s news to me and probably everyone who uses Svelte including its developers.

Re: Web Components Eliminate JavaScript Framework Lock-In

#244

Post by recursive »

WorldMaker wrote: post #231
recursive wrote: post #227

Earlier quoted context omitted.

I was also influenced quite a bit by knockout. SSR was explicitly not a goal of mine. To me, SSR as a feature in a framework like this is mostly interesting in the context of server/client continuity like rehydration. But I have a feeling the constraints imposed by anything like this aren't going to be worth it. If I was doing pure server rendering, flat text templates seem like the sweet spot, since it's fundamental…

Knockout was designed in the heyday of the "progressive enhancement" era so it seems hard for me to claim a Knockout influence/inspiration if I'm not at least contemplating "progressive enhancement" of some sort. SSR isn't really my goal on that front but progressive enhancement/SSG (static site generation) certainly is a side goal for me (that's what I would like to have to self-host my own documentation site in som…

I don't know much about the state of the art SSR/SSG, but in my mind, a whole document can be built synchronously, with a depth-first traversal of the templates/components. From that perspective the power and the constraints of reactive UI seem like overkill and limiting at the same time.

But anyway, the more UI frameworks, the more ideas get out there, the better. I'm hoping that some day in my lifetime, web UI gets "solved" and I'm not willing to believe that React is the answer. Does your project have a name yet? I'll keep an eye out.

Re: Web Components Eliminate JavaScript Framework Lock-In

#245

Post by earthboundkid »

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 could use srcdoc="..." to simulate a component, except that iframes don't have automatic height adjustment, which is the thing they should actually fix.

In any event, shadow DOM is just a worse version of scope selectors. There's not really a good use for it now that you can just do a style reset on a donut selector inside an import layer. It can all be done declaratively with CSS instead of using an imperative JS API that has a ton of gotchas.

Re: Web Components Eliminate JavaScript Framework Lock-In

#246

Post by jakelazaroff »

earthboundkid wrote: post #245
jakelazaroff wrote: post #238

Earlier quoted context omitted.

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

You could use srcdoc="..." to simulate a component, except that iframes don't have automatic height adjustment, which is the thing they should actually fix. In any event, shadow DOM is just a worse version of scope selectors. There's not really a good use for it now that you can just do a style reset on a donut selector inside an import layer. It can all be done declaratively with CSS instead of using an imperative J…

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 any problems you personally have, but that doesn’t mean it’s not useful.

[1] https://shoelace.style/components/breadcrumb

Re: Web Components Eliminate JavaScript Framework Lock-In

#247

Post by marcosdumay »

wayfinder wrote: post #236
marcosdumay wrote: post #68

Earlier quoted context omitted.

> template It's new and has no significance for the history. But I think it's relevant to point out that isn't horrible. And that those articles about web components are doing a really bad job of using constant strings instead of this.shaddow.innerHTML = getElementById("myhtml").innerHTML.

The implementation is new but as far as the UX goes, it's very similar to . That said, the UX is going to be slightly better for simply because it's is an official standard and so IDEs and tooling will be more likely to support it without additional extensions or plugins.

It's much more descriptive and obvious, and it's just plain HTML, so anything that assists you on writing HTML will assist you inside the templates.

It's bad because it's inline and your templates have no obvious place to go. You also can't import them on the fly (or rather, it's as idiomatic to import as any HTML). And obviously, because they have no effect on HTML and can only be used in javascript

Re: Web Components Eliminate JavaScript Framework Lock-In

#248

Post by WorldMaker »

recursive wrote: post #244
WorldMaker wrote: post #231

Earlier quoted context omitted.

Knockout was designed in the heyday of the "progressive enhancement" era so it seems hard for me to claim a Knockout influence/inspiration if I'm not at least contemplating "progressive enhancement" of some sort. SSR isn't really my goal on that front but progressive enhancement/SSG (static site generation) certainly is a side goal for me (that's what I would like to have to self-host my own documentation site in som…

I don't know much about the state of the art SSR/SSG, but in my mind, a whole document can be built synchronously, with a depth-first traversal of the templates/components. From that perspective the power and the constraints of reactive UI seem like overkill and limiting at the same time. But anyway, the more UI frameworks, the more ideas get out there, the better. I'm hoping that some day in my lifetime, web UI gets…

Just because on most modern hardware file I/O has millisecond latency and feels synchronous doesn't mean it is synchronous. It might feel like overkill to use Observables instead of Promises and I/O event loops or even thread-blocking faux synchronous file system calls, but there is still an asynchronous world there where it can be nice to have the full power of Observables. To be fair, my love affair with Observables started in C# in "backend" applications, so that's always been the natural fit for me and frontend and UI work has been the "side hustle" of taking stuff that I love in the backend side of the house and putting it to even more use.

I'm calling my view engine Butterfloat, and I only just finished the first documentation pass, so be gentle, but feedback is very welcome: https://github.com/WorldMaker/butterfloat

Re: Web Components Eliminate JavaScript Framework Lock-In

#249

Post by troupo »

meiraleal wrote: post #179
troupo wrote: post #166

Earlier quoted context omitted.

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…

> 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 between "talking to each other" and "refactoring one code base into another".

Preact, Svelte, Vue, and Angular can all be compiled to web components. How easy do you think it would be to convert app code between each of these frameworks? Convert that code to and from lit?

Re: Web Components Eliminate JavaScript Framework Lock-In

#250

Post by troupo »

hmcdona1 wrote: post #224
troupo wrote: post #166

Earlier quoted context omitted.

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…

I mean they have to be for now - you're just being semantic for the sake of it a bit. I will say as a team that utilizes Lit for our design system web components (which none of our users even need to know or care about no matter their framework btw). The Lit team are huge advocates of aligning with native standards (now or what they might be in the future) and working to establish or push them forward. The goal of th…

> you're just being semantic for the sake of it a bit.

No. I'm calling it as it is. I don't pretend that something isn't a framework when it has all the same things that the frameworks they so love to vilify do.

> The Lit team are huge advocates of aligning with native standards

Which of the things that lit provides are native standards current or future? Its template DSL? Its custom decorators? Its data binding system? Tasks? Directives?

Not to mention the usual workarounds like support for SVGs https://lit.dev/docs/api/templates/#svg

Post reply on HN