5 ms·

I keep having mixed feelings about web components... Why can't we have templates, custom elements and scoped CSS without JS?

by jopsen 5y ago

incrudible 5y ago
https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
- jimmont 5y ago
  that's arguable, the encapsulation web components affords is built into the system and simply being exposed by way of this bucket of technologies When compared with React and similar solutions doing the same and similar thing(s) it runs circles around them... or am I misunderstanding the comment and is the position asserted that container queries (not web components) are the effect? What is the inner-platform effect comment applied to specifically?
  - incrudible 5y ago
    > What is the inner-platform effect comment applied to specifically? Adding more flexibility to CSS/HTML without requiring Javascript would eventually turn CSS and HTML into to the equivalent of a general purpose programming language, which we already have in the form of Javascript.
    - atatatat 5y ago
      Right, but maybe later versions of CSS won't be indistinguishable from malware for basic web browsing purposes.
jrochkind1 5y ago
I am not very familiar with the technology. Under current standards, is it possible to choose to write a web component that does not have any JS, it just uses CSS to take advantage of these things?
- qbasic_forever 5y ago
  No, a web component by definition must be a class that inherits from a HTMLElement base class and implement some basic rendering functions. In addition you must make the browser aware of the component by calling a CustomElementRegistry.define function with your class and the desired component name. So at a minimum there's about 5-10 lines of boilerplate JS necessary to define and register a basic component.
  - e111077 5y ago
    You described a Custom Element a Web Component is a branding phrase for component that uses the four following specs: * Custom Elements * Shadow DOM (seems to be optional in practice) * HTML Template Elements * ES Modules (formerly HTML Imports)
runarberg 5y ago
If I remember correctly some WHATWG members are trying to settle on a syntax for declarative shadow DOM[1]. I personally wouldn’t hold my breath for it though, I don’t know how enthusiastic the rest of WHATWG is about this. In the meantime I would look for technology which applies server side rendering to your web components. 1: https://web.dev/declarative-shadow-dom/ https://web.dev/declarative-shadow-dom/
- jimmont 5y ago
  Why server side rendering? Content that needs rendering just put in the tree and target a slot. My perception was this is the best practice. I haven't used the lit included intl translation and am curious if and how these concerns work.
  - runarberg 5y ago
    Doesn’t that still require JavaScript? As I understand it (and I might not; I don’t have servers to do SSR) people want SSR for two reasons. a) To allow users that don’t have JavaScript for some reason to at get good UX, and b) to prevent the styles from kicking in after the initial render. There are ways to author your components in a way that fixes (b), but I’m not aware of any technique other then SSR that will fix (a).
    - e111077 5y ago
      I don't think anyone is really targeting JS-less users. It's mostly for faster first renders and the examples of JS-less is to typically show something has been SSR'd and not yet hydrated / not loading anything that isn't needed for first render.
    - jopsen 5y ago
      Isn't SSR also attractive because it's simple? For things that aren't web apps, like blog/wiki/docs/news-site the primary content is text + images + links. Is it not attractive to avoid JS where not needed? And only use it for the tiny bits that really do need it.
- 5y ago
qbasic_forever 5y ago
There's no generic HTML import function yet. Right now you can only have a page pull in javascript (through a script tag or ES module import) or CSS files, but critically not component HTML files. So it's hard to have a component defined by HTML and CSS that can be shared and imported in other pages. There's no "grab this HTML page and give me the DOM to insert/clone/use how I please" in pure HTML. The closest thing is iframe but it's not really a general component tool. For better or worse JS is currently the way to share logic and fragments between HTML pages. There was a working group looking at HTML imports but I think it all got spun down.
- e111077 5y ago
  HTML Imports did exist and was the general authoring idea for web components, but it didn't work exactly as you described and Apple and Mozilla shut it down. Polymer had to release a new version that was JS focused and caused a huge painful migration for users.

I keep having mixed feelings about web components... Why can't we have templates, custom elements and scoped CSS without JS?

by jopsen 5y ago

I keep having mixed feelings about web components... Why can't we have templates, custom elements and scoped CSS without JS?

incrudible 5y ago

https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

jimmont 5y ago
that's arguable, the encapsulation web components affords is built into the system and simply being exposed by way of this bucket of technologies When compared with React and similar solutions doing the same and similar thing(s) it runs circles around them... or am I misunderstanding the comment and is the position asserted that container queries (not web components) are the effect? What is the inner-platform effect comment applied to specifically?
- incrudible 5y ago
  > What is the inner-platform effect comment applied to specifically? Adding more flexibility to CSS/HTML without requiring Javascript would eventually turn CSS and HTML into to the equivalent of a general purpose programming language, which we already have in the form of Javascript.
  - atatatat 5y ago
    Right, but maybe later versions of CSS won't be indistinguishable from malware for basic web browsing purposes.

jrochkind1 5y ago

I am not very familiar with the technology. Under current standards, is it possible to choose to write a web component that does not have any JS, it just uses CSS to take advantage of these things?

qbasic_forever 5y ago
No, a web component by definition must be a class that inherits from a HTMLElement base class and implement some basic rendering functions. In addition you must make the browser aware of the component by calling a CustomElementRegistry.define function with your class and the desired component name. So at a minimum there's about 5-10 lines of boilerplate JS necessary to define and register a basic component.
- e111077 5y ago
  You described a Custom Element a Web Component is a branding phrase for component that uses the four following specs: * Custom Elements * Shadow DOM (seems to be optional in practice) * HTML Template Elements * ES Modules (formerly HTML Imports)

runarberg 5y ago

If I remember correctly some WHATWG members are trying to settle on a syntax for declarative shadow DOM[1]. I personally wouldn’t hold my breath for it though, I don’t know how enthusiastic the rest of WHATWG is about this. In the meantime I would look for technology which applies server side rendering to your web components. 1: https://web.dev/declarative-shadow-dom/ https://web.dev/declarative-shadow-dom/

jimmont 5y ago
Why server side rendering? Content that needs rendering just put in the tree and target a slot. My perception was this is the best practice. I haven't used the lit included intl translation and am curious if and how these concerns work.
- runarberg 5y ago
  Doesn’t that still require JavaScript? As I understand it (and I might not; I don’t have servers to do SSR) people want SSR for two reasons. a) To allow users that don’t have JavaScript for some reason to at get good UX, and b) to prevent the styles from kicking in after the initial render. There are ways to author your components in a way that fixes (b), but I’m not aware of any technique other then SSR that will fix (a).
  - e111077 5y ago
    I don't think anyone is really targeting JS-less users. It's mostly for faster first renders and the examples of JS-less is to typically show something has been SSR'd and not yet hydrated / not loading anything that isn't needed for first render.
  - jopsen 5y ago
    Isn't SSR also attractive because it's simple? For things that aren't web apps, like blog/wiki/docs/news-site the primary content is text + images + links. Is it not attractive to avoid JS where not needed? And only use it for the tiny bits that really do need it.
5y ago

qbasic_forever 5y ago

There's no generic HTML import function yet. Right now you can only have a page pull in javascript (through a script tag or ES module import) or CSS files, but critically not component HTML files. So it's hard to have a component defined by HTML and CSS that can be shared and imported in other pages. There's no "grab this HTML page and give me the DOM to insert/clone/use how I please" in pure HTML. The closest thing is iframe but it's not really a general component tool. For better or worse JS is currently the way to share logic and fragments between HTML pages. There was a working group looking at HTML imports but I think it all got spun down.

e111077 5y ago
HTML Imports did exist and was the general authoring idea for web components, but it didn't work exactly as you described and Apple and Mozilla shut it down. Polymer had to release a new version that was JS focused and caused a huge painful migration for users.