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

If Web Components are so great, why am I not using them?

daverupert.com

Post reply on HN
Print view View original

151–160 of 189 posts

Re: If Web Components are so great, why am I not using them?

#151

Post by jongjong »

rezonant wrote: post #142
jongjong wrote: post #134

Earlier quoted context omitted.

You don't really need all that stuff. Sanitization is straight forward to implement and only required for user generated strings (since you want to make it HTML-safe). It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. As for events, binding is really very easy to do and…

> Sanitization is straight forward to implement I would not say it's easy. Considering your adversaries are very motivated to do XSS and the web platform is very complicated. > It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. I don't think there's a substantial performa…

By "system generated content" I meant content which is not derived from potentially unsafe user input. For example, if your front end receives a JSON object from your own back end which was generated by your back end and contains numbers, booleans and enums (from a constrained set of strings) and it is properly validated before insertion into your DB, such data poses no risk to your front end in terms of XSS. That said, if you want to make your system fool-proof and future-proof, you could escape HTML tags in all your string data before incorporating it into a components' template string as a principle; such function is trivial to implement.

The main risk of XSS is when you inject some unescaped user-generated string into a template and then set that whole template as your component's innerHTML... All I want to point out is that not every piece of data is a custom user-generated string. Numbers, booleans don't need to be escaped. Error messages generated by your system don't need to be escaped either. Enum strings (which are validated at insertion in the DB) also don't really need to be escaped but I would probably escape anyway in case of future developer mistake (improper validation).

I agree that the automatic sanitization which React does is probably not a huge performance cost for the typical app (it's probably worth the cost in the vast majority cases) but it depends on how much data your front end is rendering and how often it re-renders (e.g. real time games use case).

Re: If Web Components are so great, why am I not using them?

#152

Post by rapnie »

herpdyderp wrote: post #23

I've been using web components now for years and I will do everything I can to never write frontends in anything else. I totally agree with point 2 though: the Polymer phase was very weird, but, as mentioned, https://lit.dev is great and, imo, the perfect abstraction.

It looks good. But it is a Google project, and with Google's DRM attack on the web I don't know if I'm willing to give these more traction by being among the user base.

Re: If Web Components are so great, why am I not using them?

#153

Post by jongjong »

incrudible wrote: post #150
jongjong wrote: post #137

Earlier quoted context omitted.

You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; y…

> You can simply watch for HTMLElement attribute changes You know what's really, really, really slow? Anything involving the DOM, reading, writing, whatever. > often leads to unnecessary double or triple rendering "Renders" on the other hand are very cheap if they don't actually touch the DOM.

In my experience watching for attribute changes is very fast; I suspect in part because you need to explicitly list out the attributes which you're watching for changes and it only triggers the attributeChangedCallback lifecycle hook if one of those specified attributes changes.

React renders aren't always cheap. It depends on the complexity of the component and you don't have as much control over the rendering. I've worked on some React apps which were so slow due to unnecessary re-renders that my new computer would often freeze during development. I was able to fix it by refactoring the code to be more specific with useState() (to watch individual properties instead of the entire object) but this flexibility that useState provides is a React footgun IMO. With HTMLElement, you're forced to think in terms of individual attributes anyway and these are primitive types like strings, booleans or numbers so there is no room for committing such atrocities.

Re: If Web Components are so great, why am I not using them?

#154

Post by rezonant »

jongjong wrote: post #151
rezonant wrote: post #142

Earlier quoted context omitted.

> Sanitization is straight forward to implement I would not say it's easy. Considering your adversaries are very motivated to do XSS and the web platform is very complicated. > It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. I don't think there's a substantial performa…

By "system generated content" I meant content which is not derived from potentially unsafe user input. For example, if your front end receives a JSON object from your own back end which was generated by your back end and contains numbers, booleans and enums (from a constrained set of strings) and it is properly validated before insertion into your DB, such data poses no risk to your front end in terms of XSS. That sa…

> and it is properly validated before insertion into your DB, such data poses no risk to your front end in terms of XSS

This is making a lot of assumptions. Just because the data was acceptable in a database table does not mean it doesn't pose an XSS risk.

Bear in mind, in other branches of this discussion we're talking about using DOM text APIs to insert. Certainly that is a good, reliable way to avoid XSS, but you can consider that to be value sanitization just done for you by the browser. In the absence of that, advocating that "if it comes from the API it is safe" is a dangerous thing to advocate for.

The title "A world where tag is not required for your web pages" might be perfectly valid to submit into your blog's CMS system, but that in no way means you can skip processing that in the frontend because "it is safe". Plenty of what you are saying is reasonable, but I think the topic requires a little more nuance in order to speak about the topic responsibly.

Re: If Web Components are so great, why am I not using them?

#155

Post by rezonant »

jongjong wrote: post #148
resonious wrote: post #144

Earlier quoted context omitted.

You get sanitization for free by using built in browser methods like setAttribute and textContent=.

Agreed, this is the safe approach if you create elements using document.createElement(). For cases where you want to generate some HTML as strings to embed within your component's template string (e.g. in a React-like manner using Array.prototype.map), you would have to escape the variables provided by the back end in case they contain HTML tags which could be used as an XSS attack. Although such sanitization functio…

I agree that sanitization isn't an excuse not to use web components. Only that brushing off sanitization as solved by web components is dangerous rhetoric.

Re: If Web Components are so great, why am I not using them?

#156

Post by jongjong »

rezonant wrote: post #140
jongjong wrote: post #137

Earlier quoted context omitted.

You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; y…

See that's weird, because the parent comments are about using in HTML template binding, and you seem to have suggested instead that a React-like render function model would be better, while simultaneously bashing React. I am no fan of React, but this comment confuses me.

I don't have a problem with the idea of making each component have a render function which can be called whenever you need to render or re-render the component and I concede that there is some elegance in being able to construct a complex HTML component using a single template string. But you don't need React to do this. This idea of rendering a component whenever its internal state changed existed long before React.

React didn't even invent the idea of reactive components; that was Angular 1. I honestly don't know why React became so popular initially. After Angular 1, there was Google's Polymer which was far more elegant and closer to native Web Components (and fixed many of Angular 1's flaws) - I suspect it's because some devs didn't like that you had to use some polyfills for certain non-Chrome browsers.

Anyway now we have Web Components which work consistently without polyfills on all browsers so I don't see any reason not to use plain Web Components or use something more lightweight such as Lit elements.

Re: If Web Components are so great, why am I not using them?

#157

Post by incrudible »

jongjong wrote: post #153
incrudible wrote: post #150

Earlier quoted context omitted.

> You can simply watch for HTMLElement attribute changes You know what's really, really, really slow? Anything involving the DOM, reading, writing, whatever. > often leads to unnecessary double or triple rendering "Renders" on the other hand are very cheap if they don't actually touch the DOM.

In my experience watching for attribute changes is very fast; I suspect in part because you need to explicitly list out the attributes which you're watching for changes and it only triggers the attributeChangedCallback lifecycle hook if one of those specified attributes changes. React renders aren't always cheap. It depends on the complexity of the component and you don't have as much control over the rendering. I've…

>In my experience watching for attribute changes is very fast

Watching for attributes changing is not the whole picture. Why did the attribute change in the first place? Probably because you're doing stuff in terms of DOM attributes, which is slow - not individually, but in aggregate. Death by a thousand papercuts.

> I've worked on some React apps which were so slow due to unnecessary re-renders that my new computer would often freeze during development

I haven't managed to achieve that. If your computer freezes, that almost certainly means you're running out of RAM, not that your CPU is busy. I admit that the React "development build" overhead is considerable.

> I was able to fix it by refactoring the code to be more specific with useState() (to watch individual properties instead of the entire object) but this flexibility that useState provides is a React footgun IMO.

I admit that React has some footguns, but I don't see how the reactive model can be implemented entirely without them. It's a price I'm willing to pay, because it makes most things far easier to reason about. 90% of my components have no state at all. Of those that do, the vast majority have no complex state.

Re: If Web Components are so great, why am I not using them?

#158

Post by styren »

zoom6628 wrote: post #129

Too little too late. My bet is WASM being the Great Leap Forward because everything else that has been done in JavaScript is just layer on layer of abstraction, obfuscation and horrendous complexity. I would rather develop in a mature language and have that transpiled to WASM rather than fight the frameworks (I still remember when Angula 5 was a 15,000 file desktop mom install !). JavaScript has fulfilled an importan…

How would WASM alleviate any of the issues that has led to complex frameworks in JS-land?

Re: If Web Components are so great, why am I not using them?

#159

Post by xtracto »

_xivi wrote: post #115

I heard about web components a lot for years and was looking forward for an opportunity to try them. But for some reason, this is the first time I learn that it's completely reliant on JS. My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Instead, turns out it's doubl…

I read about web components a couple of years ago. What excited me was the prospect of having libraries of ready made UI elements that I could use.

Those of us who programmed in say VB6 or .NET winforms back in the day may remember that you could purchase some "ready made" grid-table editor with lots of functionality and pretty.

But I haven't seen that open source nor commercial.

It's amazing how much the current web frontend dev have to reinvent over and over again.

Re: If Web Components are so great, why am I not using them?

#160

Post by gemstones »

jongjong wrote: post #156
rezonant wrote: post #140

Earlier quoted context omitted.

See that's weird, because the parent comments are about using in HTML template binding, and you seem to have suggested instead that a React-like render function model would be better, while simultaneously bashing React. I am no fan of React, but this comment confuses me.

I don't have a problem with the idea of making each component have a render function which can be called whenever you need to render or re-render the component and I concede that there is some elegance in being able to construct a complex HTML component using a single template string. But you don't need React to do this. This idea of rendering a component whenever its internal state changed existed long before React.…

And yet the adoption shows that plenty of people see reasons not to use plain Web Components.
Post reply on HN