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

201–210 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#201

Post by itronitron »

willio58 wrote: post #171
djrenren wrote: post #20

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

I completely agree. Recently I listened to a podcast where Brad Frost talked about web components being useful for design systems, as you can make a button in a web component and have that defined no matter what JS framework the dev team (or teams) want to use company-wide. One issue I see though and I almost feel dumb for saying it, I don't like how web component code looks. Using innerHTML feels really weird when y…

For me, it feels weird to have four file types I need to manage in order to define a UI, instead of just one.

Re: Web Components Eliminate JavaScript Framework Lock-In

#202

Post by recursive »

WorldMaker wrote: post #138
menssen wrote: post #39

Earlier quoted context omitted.

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

> 4. Observables (Ember, maybe Angular 2+?) Don't forget Knockout which was the OG. You can also make the case that Svelte, Vue, and Qwik all are different takes on Observables (at least as much as Angular 2+ is) all with more or less magic and more or fewer escape hatches from Observable best practices to imperative(-looking) code. I got a "What if we did Knockout but with with the compile-time benefits of TSX and P…

I got the same itch. Here's my thing. https://mutraction.dev/

Re: Web Components Eliminate JavaScript Framework Lock-In

#203

Post by QuadmasterXLII »

nightpool wrote: post #187
QuadmasterXLII wrote: post #71

Earlier quoted context omitted.

With modern browsers, " completely re-output the entire user interface on every state change" is kinda viable. I recently wrote a trebuchet simulator app (hastingsgreer.github.io/jstreb) without a framework. instead I wrote a "rebuild UI" function that I call on every new state, and the user experience is super snappy

Weirdly I see that changing the "Projectile" selection to "P3" and then back to the original "P4" made the range drop way down, even though the new value was identical to the old value. But changing the "Main Axel" value made it jump way back up: https://imgur.com/a/boo5Xw3 So maybe some kind of "non-functional"/reused state issue exists regardless?

Oh, I don’t like the look of that. This may be a valuable lesson in “I should have just used a framework”

Re: Web Components Eliminate JavaScript Framework Lock-In

#204

Post by wayfinder »

nostrademons wrote: post #67
wayfinder wrote: post #40

Earlier quoted context omitted.

Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other lan…

> But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. It's not actually, with HTTP/2. The separate requests are all multiplexed over the same connection, often with prefetching, and compressed together so that there's little to no overhead vs. putting them in the same file. This illustrates a common failure point for web frame…

Oh I'm aware, but I'm talking historically.

But HTTP/2 is not the right example. You're missing some things on the web timeline.

Long before HTTP/2 (time in web terms), and after React (and Angular, etc.) came about, people created actually-popular bundler toolchains that can bundle arbitrary files together and then incrementally load them as needed. This effectively fixed the multiple HTTP request problem long before HTTP/2 existed. Efficient template files have been possible for years. (Granted, not anything standard though.)

The issue right now is that someone has to make a full toolchain with strong developer support to make this a de-facto and popular way to distribute apps. Just because you have a bundler or HTTP/2 doesn't mean you have a nice way to make use of it. You need a nice library. Your usage examples need to look pretty. It needs to work with other toolchains. It needs to look like your library will be supported for a long time, just like how React was supported by Facebook.

You can't just write a blog post about how it's possible because you're basically asking your readers to invent and maintain a library or worse, roll their own internal library that will confound people at their company.

Re: Web Components Eliminate JavaScript Framework Lock-In

#205

Post by zaphar »

willio58 wrote: post #171
djrenren wrote: post #20

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

I completely agree. Recently I listened to a podcast where Brad Frost talked about web components being useful for design systems, as you can make a button in a web component and have that defined no matter what JS framework the dev team (or teams) want to use company-wide. One issue I see though and I almost feel dumb for saying it, I don't like how web component code looks. Using innerHTML feels really weird when y…

You don't have to use innerHtml. The ShadowRoot pretty much acts like a document. So you can also use appendChild. Combined with a template element you can completely avoid innheHtml. You could even use jsx to create the template element I suppose.

That said I think this is mostly a non-issue.

Re: Web Components Eliminate JavaScript Framework Lock-In

#206

Post by lioeters »

QuadmasterXLII wrote: post #107
nostrademons wrote: post #67

Earlier quoted context omitted.

> But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. It's not actually, with HTTP/2. The separate requests are all multiplexed over the same connection, often with prefetching, and compressed together so that there's little to no overhead vs. putting them in the same file. This illustrates a common failure point for web frame…

Can I borrow some knowledge? What sort of operations trigger a reflow and repaint?

"Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout."

> What forces layout/reflow. The comprehensive list.

> All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

Re: Web Components Eliminate JavaScript Framework Lock-In

#207

Post by stickfigure »

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?

As parent pointed out, the MVC in server-side development only shares a name with the MVC in GUI development. Yes, MVC is a proven and popular name. But it means different things to different people.

Re: Web Components Eliminate JavaScript Framework Lock-In

#208

Post by WorldMaker »

recursive wrote: post #202
WorldMaker wrote: post #138

Earlier quoted context omitted.

> 4. Observables (Ember, maybe Angular 2+?) Don't forget Knockout which was the OG. You can also make the case that Svelte, Vue, and Qwik all are different takes on Observables (at least as much as Angular 2+ is) all with more or less magic and more or fewer escape hatches from Observable best practices to imperative(-looking) code. I got a "What if we did Knockout but with with the compile-time benefits of TSX and P…

I got the same itch. Here's my thing. https://mutraction.dev/

Interesting, thanks. Your mutation tracker isn't enough like "pure" RxJS Observables for my tastes and what I've been doing with my itch, but you captured a few of the things I'm covering in my system and are probably the next closest I've seen to what I've been doing (and I tried to research a deep dive). I think the only other thing is that I took an approach that observable change bindings look different from static HTML-like attributes. I did that in part because that's how Knockout used to do it, and also in part because I think it should better facilitate SSG/SSR/progressive enhancement when I get back around to those ideas (it's not a current priority, but definitely an idea I'm tracking).

Re: Web Components Eliminate JavaScript Framework Lock-In

#209

Post by WorldMaker »

jeremycarter wrote: post #196
WorldMaker wrote: post #138

Earlier quoted context omitted.

> 4. Observables (Ember, maybe Angular 2+?) Don't forget Knockout which was the OG. You can also make the case that Svelte, Vue, and Qwik all are different takes on Observables (at least as much as Angular 2+ is) all with more or less magic and more or fewer escape hatches from Observable best practices to imperative(-looking) code. I got a "What if we did Knockout but with with the compile-time benefits of TSX and P…

I remember 2012, ASP.NET MVC Razor pages, combined with individual page knockout Js. Actually worked quite well. Infact that system is still running for that company. Sure we could have made a angularJS 1.0 SPA at the time, but knockout meant we only had to apply the pattern to the pages that needed it.

I even used Durandal some in those cases where we really did want a SPA, but Knockout was good enough. That was something I appreciated about Knockout too was that the SPA framework was around it, not a part of it or implemented inside of it. Same with routing frameworks like Crossroads.js if you wanted something lighter than Durandal for just boring hash-navigation somewhere in the boundary spectrum between full SPA and MPA.

It was something that was also attractive about early React that React was similarly just a view engine and could do MPA or SPA or things in between and it didn't try to have the full kitchen sink. I don't know exactly where React stopped being that, but it always feels harder to argue that current React is "just" a view engine.

In the larger context here with this article, libraries that are just view engines should be great for building the internals of Web Components. (I'm hoping the view engine I've been working on might serve that role well, though with a dependency like RxJS I'm not sure if it would be towards the top of the list for many developers. It will certainly feel bigger than Lit, for example, no matter how well it tree shakes.)

Re: Web Components Eliminate JavaScript Framework Lock-In

#210

Post by pvorb »

dberg wrote: post #79

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

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.

Post reply on HN