4 ms·

I don't get it. The ability to source some js and then add a <custom-element> wherever you want just like it was a built in element is one of the best things to

I don't get it. The ability to source some js and then add a <custom-element> wherever you want just like it was a built in element is one of the best things to ever happen to web design. This is what we should have had ten years ago, not the post-jquery framework madness we have now. I do think it was dumb that <style scoped> got removed though.

gildas 7y ago
Is it okay for you if you save a webpage but no contents are saved in fact? Do the test and save in HTML (with the native "Save as" feature) this page [1]. The saved page will be almost empty because it's made of web components. This is an example of issue that should be fixed. [1] https://bugs.chromium.org/p/chromium/issues/list https://bugs.chromium.org/p/chromium/issues/list Edit: This might be fixed, see my first post https://news.ycombinator.com/item?id=22604632 https://news.ycombinator.com/item?id=22604632
- Blackthorn 7y ago
  I don't see how this is a fundamental failure of web components and not an implementation issue of the completely ignored and disregarded save feature.
- asdfasgasdgasdg 7y ago
  Are you sure that's why? It seems possible that the issue is how the data is being loaded. How did you confirm that web components are the issue with loading that page from a saved file?
  - gildas 7y ago
    Yes I'm sure. It was a bug in SingleFile [1] and to fix it (I'm the author), I must add a JavaScript script in the saved page to deserialize the shadow root contents that are missing. It means that JS is required to view this saved page correctly. [1] https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile
    - mattnewton 7y ago
      I mean, JavaScript being required to view pages sounds like Pandora’s already opened box.
      - gildas 7y ago
        I disagree, I develop SingleFile for 10 years. That's the first time I need to include a script in the saved page in order to display it properly. Until the existence of Web Components, JavaScript was not needed to display a saved page. Edit: to be clear, saved pages are HTML snapshots, not full web apps stored in a page.
    - rictic 7y ago
      Work is underway on speccing out declarative shadow doms, which would remove the need for that JS: https://github.com/mfreed7/declarative-shadow-dom https://github.com/mfreed7/declarative-shadow-dom
- fxtentacle 7y ago
  It should be very easy to make the HTML save function also store the contents of those #shadow-root elements, so I don't see much of a problem there once WebComponents support becomes stable.
- cameronfraser 7y ago
  People save web pages?
- smnthermes 7y ago
  YouTube uses WebComponents, and its pages are unviewable with Wayback Machine: http://web.archive.org/web/20200317150441/https://www.youtube.com/ http://web.archive.org/web/20200317150441/https://www.youtub...
Udik 7y ago
I am not convinced. "Built in elements" are really a small part of what makes a web application, and in many cases are replaced anyway by custom solutions. In fact, html tags are now meant to only express the semantic of a portion of document, not a specific behaviour. I'm not sure in what sense web components are different from the components of any other modern application framework, except for the fact that they can be easily imported (probably wrapped) in your framework of choice. But if you're using one of the main frameworks, there is already no shortage of components available for it. Each component will come anyway with a complex behaviour that will need to be wired up with the rest of your application, so the idea of just "source some js then add the element to the page" seems naive. And web components come with their set of problems: more opaque, harder to style, hard to make accessible. They break the paradigm of "everything lives in the same document" that it's part of what defines the web. They can evolve at a slower pace than frameworks because they're native apis that need to go through slow standardisation processes. It sounds like an idea from the '90s: what if we could create those damn widgets ourselves with custom tags and drop them in the html? Well, it's been possible for many years. But it is only useful if you do it in the context of an application framework which already gives you the same feature, with better tooling.
clarry 7y ago
> The ability to source some js and then add a <custom-element> wherever you want just like it was a built in element is one of the best things to ever happen to web design. Web design is the worst thing that ever happened to the web.
- untog 7y ago
  Yeah, screw usable UIs! Bring back marquee tags!
SickOfSlowSites 7y ago
> The ability to source some js and then add a <custom-element> wherever you want just like it was a built in element is one of the best things to ever happen to web design. STOP MAKING YOUR PAGES SO SLOW!!
- Blackthorn 7y ago
  sourcing timezonepicker.js and using <tzpicker> is making our pages slow??
  - zzo38computer 7y ago
    Yes, it does make it slow, and reduces user customizability. I suggested a way that can make it fast and increases user customizability, as well as improving security, and improves backward compatibility, too. Yet, it would seem, they don't like that. (Although, I don't know if the authors of Pale Moon will consider my idea; probably not, but it may be worth a try.)
    - uk_programmer 7y ago
      Have you got any stats to back that up? I've been playing around with it and there is nothing from the profiler in Chrome or Firefox that suggests it might be slow.
pdr2020 7y ago
Nope. If I use Youtube as a smoke signal for what an authoritative web components-based implementation should look/feel like, then it's definitely not in my 'ready-to-adopt' category. Youtube has significantly regressed as of late, with strange bugs/quirks throughout. I'll stick to frameworks that emit standard HTML thanks.

gildas 7y ago

Is it okay for you if you save a webpage but no contents are saved in fact? Do the test and save in HTML (with the native "Save as" feature) this page [1]. The saved page will be almost empty because it's made of web components. This is an example of issue that should be fixed. [1] https://bugs.chromium.org/p/chromium/issues/list https://bugs.chromium.org/p/chromium/issues/list Edit: This might be fixed, see my first post https://news.ycombinator.com/item?id=22604632 https://news.ycombinator.com/item?id=22604632

Blackthorn 7y ago
I don't see how this is a fundamental failure of web components and not an implementation issue of the completely ignored and disregarded save feature.
asdfasgasdgasdg 7y ago
Are you sure that's why? It seems possible that the issue is how the data is being loaded. How did you confirm that web components are the issue with loading that page from a saved file?
- gildas 7y ago
  Yes I'm sure. It was a bug in SingleFile [1] and to fix it (I'm the author), I must add a JavaScript script in the saved page to deserialize the shadow root contents that are missing. It means that JS is required to view this saved page correctly. [1] https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile
  - mattnewton 7y ago
    I mean, JavaScript being required to view pages sounds like Pandora’s already opened box.
    - gildas 7y ago
      I disagree, I develop SingleFile for 10 years. That's the first time I need to include a script in the saved page in order to display it properly. Until the existence of Web Components, JavaScript was not needed to display a saved page. Edit: to be clear, saved pages are HTML snapshots, not full web apps stored in a page.
  - rictic 7y ago
    Work is underway on speccing out declarative shadow doms, which would remove the need for that JS: https://github.com/mfreed7/declarative-shadow-dom https://github.com/mfreed7/declarative-shadow-dom
fxtentacle 7y ago
It should be very easy to make the HTML save function also store the contents of those #shadow-root elements, so I don't see much of a problem there once WebComponents support becomes stable.
cameronfraser 7y ago
People save web pages?
smnthermes 7y ago
YouTube uses WebComponents, and its pages are unviewable with Wayback Machine: http://web.archive.org/web/20200317150441/https://www.youtube.com/ http://web.archive.org/web/20200317150441/https://www.youtub...

Udik 7y ago

I am not convinced. "Built in elements" are really a small part of what makes a web application, and in many cases are replaced anyway by custom solutions. In fact, html tags are now meant to only express the semantic of a portion of document, not a specific behaviour. I'm not sure in what sense web components are different from the components of any other modern application framework, except for the fact that they can be easily imported (probably wrapped) in your framework of choice. But if you're using one of the main frameworks, there is already no shortage of components available for it. Each component will come anyway with a complex behaviour that will need to be wired up with the rest of your application, so the idea of just "source some js then add the element to the page" seems naive. And web components come with their set of problems: more opaque, harder to style, hard to make accessible. They break the paradigm of "everything lives in the same document" that it's part of what defines the web. They can evolve at a slower pace than frameworks because they're native apis that need to go through slow standardisation processes. It sounds like an idea from the '90s: what if we could create those damn widgets ourselves with custom tags and drop them in the html? Well, it's been possible for many years. But it is only useful if you do it in the context of an application framework which already gives you the same feature, with better tooling.

clarry 7y ago

> The ability to source some js and then add a <custom-element> wherever you want just like it was a built in element is one of the best things to ever happen to web design. Web design is the worst thing that ever happened to the web.

untog 7y ago
Yeah, screw usable UIs! Bring back marquee tags!

SickOfSlowSites 7y ago

> The ability to source some js and then add a <custom-element> wherever you want just like it was a built in element is one of the best things to ever happen to web design. STOP MAKING YOUR PAGES SO SLOW!!

Blackthorn 7y ago
sourcing timezonepicker.js and using <tzpicker> is making our pages slow??
- zzo38computer 7y ago
  Yes, it does make it slow, and reduces user customizability. I suggested a way that can make it fast and increases user customizability, as well as improving security, and improves backward compatibility, too. Yet, it would seem, they don't like that. (Although, I don't know if the authors of Pale Moon will consider my idea; probably not, but it may be worth a try.)
  - uk_programmer 7y ago
    Have you got any stats to back that up? I've been playing around with it and there is nothing from the profiler in Chrome or Firefox that suggests it might be slow.

pdr2020 7y ago

Nope. If I use Youtube as a smoke signal for what an authoritative web components-based implementation should look/feel like, then it's definitely not in my 'ready-to-adopt' category. Youtube has significantly regressed as of late, with strange bugs/quirks throughout. I'll stick to frameworks that emit standard HTML thanks.