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

181–190 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#181

Post by jacobsimon »

megaman821 wrote: post #168
jacobsimon wrote: post #142

Earlier quoted context omitted.

There are certainly lots of great component libraries out there for various frameworks that help with this, but I agree with the parent comment that it's still not the kind of progress we should have had by this point. I think it's unfortunate that we have to stick to HTML/CSS as the foundation for everything to maintain compatibility and accessibility, but that's how the web works I suppose. If we were to design the…

I am not sure it would look that different. It would be more consistent with terminology. Things like SwiftUI and Jetpack Compose look a lot more like HTML and CSS than their predecessors, and there is nothing forcing them to go in that direction. The biggest difference between other major platforms and the web, is that the web doesn't come with a default UI framework. The primitives for building UI on the web are pr…

Yeah maybe it's a grass-is-greener situation, but from a quick look at SwiftUI and Jetpack Compose, they both seem to have a lot more in common with React than HTML/CSS itself. They seem to encourage functional UI that combines state management, event handling, and view layout. They have primitives like `Text`, `Row`, `Column`, `Spacer`, etc.

I do think the web is a lot easier to learn and the on-ramp is so much faster compared to older mobile UI frameworks, so it makes sense that they're sort of evolving toward the same patterns.

Re: Web Components Eliminate JavaScript Framework Lock-In

#182

Post by tubthumper8 »

zelphirkalt wrote: post #34
wayfinder wrote: post #14

Earlier quoted context omitted.

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in…

> Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS.

> This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code?

Remember that React is "just JavaScript", JSX is a syntax transformation of JavaScript. When you use `className` in your JSX, you're using the standard DOM Attribute [1]. You wouldn't use `class` either in vanilla JS to set the CSS class, you'd use `className`.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

Re: Web Components Eliminate JavaScript Framework Lock-In

#183

Post by nbe »

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…

lit [1] provides declarative templates for web components for example.

[1] https://lit.dev/

Re: Web Components Eliminate JavaScript Framework Lock-In

#184

Post by nostrademons »

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?

Short answer: anything that modifies the DOM, followed by a call which measures geometric properties of the DOM. Also you get an automatic reflow/repaint when control leaves the Javascript event handler that triggers a modification (this is how the browser's UI is updated). You can batch up a bunch of modifications without triggering a reflow and then have it account for all of them on next reflow, though, which is what React tries to achieve with the Virtual DOM and what you get for free after ~2013.

Slightly longer answers:

[modifies] https://developers.google.com/speed/docs/insights/browser-re...

[measures] https://gist.github.com/paulirish/5d52fb081b3570c81e3a

Also there's a bunch of exceptions where you can modify things without triggering a full reflow. Anything that takes elements out of normal flow (position: fixed, position: absolute, float:, overflow: hidden) creates a layout boundary where changes inside only reflow the containing element. Any element with a transform: or opacity: property gets rendered as a 2D texture on the GPU, and then you can do subsequent transform/opacity animations purely on the GPU without touching the CPU. Used to do this to make performant animations on mobile devices.

Re: Web Components Eliminate JavaScript Framework Lock-In

#185

Post by robin_reala »

troupo wrote: post #180
pseudosavant wrote: post #84

Earlier quoted context omitted.

I'm glad to have read this today. I'm going to look into how I could use web components in my next side project. I'd really like something that worked easily with SSR and client-side, maybe using htmx. In retrospect, I think I avoided web components because of Google and their aggressive dev relations pushing Polymer. It felt so one-sided that it didn't seem like a web standard. It felt more like a Google "standard"…

> I'd really like something that worked easily with SSR and client-side Then you should skip Web Components :)

For sure. SSR is one thing that React has done well, and that Web Components don’t have a great story for.

Re: Web Components Eliminate JavaScript Framework Lock-In

#186

Post by nostrademons »

chatmasta wrote: post #94
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…

Multiplexing requests doesn't help when there is a logical dependency between them, e.g. some javascript code needs to download and then execute just to determine what template files it needs to subsequently download. That can't be parallelized.

If you're in a position where you could've written the template inline in your source file, this is a static dependency, independent of any page content, and can be handled through build systems and prefetching.

Re: Web Components Eliminate JavaScript Framework Lock-In

#187

Post by nightpool »

QuadmasterXLII wrote: post #71
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…

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?

Re: Web Components Eliminate JavaScript Framework Lock-In

#188

Post by pseudosavant »

robin_reala wrote: post #185
troupo wrote: post #180

Earlier quoted context omitted.

> I'd really like something that worked easily with SSR and client-side Then you should skip Web Components :)

For sure. SSR is one thing that React has done well, and that Web Components don’t have a great story for.

I'm pretty sure that just shipping the HTML works. The nice thing if I use web components is that I can just have my backend create HTML that uses those components. I can create elements whatever way I want on the backend or the front-end so long as it is HTML.

Re: Web Components Eliminate JavaScript Framework Lock-In

#189

Post by breadwinner »

jitl wrote: post #64
breadwinner wrote: post #51

Earlier quoted context omitted.

> Make a convincing argument that a different design pattern is better. Simple Model-View-Controller pattern works well for JavaScript, just as it does for ASP.NET Core, JSP and JSF, Ruby on Rails, Django and so on. Want proof? Browse this code: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... This is the application: https://github.com/wisercoder/eureka

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?

Re: Web Components Eliminate JavaScript Framework Lock-In

#190

Post by nicoburns »

throwaway_1987 wrote: post #145
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. Most projects that I have been involved with have some kind of build system that does all sort of magic. It should be possible to include the template in the JS file during the build process

Yep, and that's what was being done before React existed. JSX took over because people (including me) prefer to have the full power of JavaScript for their templates rather than a half-based templating language.
Post reply on HN