21 replies

1. westbrook 11 min later

   @zachleat It all starts from realizing they're not something you can "work around", they're a thing you "work with" (like events, or promises, or <select> elements) and if you're not or can't then it could be says that your abstraction might just be wrong...

   Just sayin. 😏

   1. Zach Leatherman 16 min later

      @westbrook *exactly* web primitives don’t have to be a burden if you work with the grain of the web

      1. Konnor Rogers 54 min later

         @zachleat @westbrook

         Yea, but how do you expect my compiler default event delegated frontend framework with partial prerendering hydration hubbabaloo to work if my assumptions of the platform are no longer true?

         1. Luke 1 hr later

            @konnorrogers @zachleat @westbrook But my synthetic performance benchmarks show I can get more bigger numbers by breaking how events work!

2. Florens Verschelde 17 min later

   @zachleat Facts.

3. Micah 1 hr later

   @zachleat I wonder if there's a truth to the paradigm of compilers being too [critical, necessary, vital, ???] for web developers to avoid using the DOM directly?

   Using Custom Elements as Web Components inside of the popular libraries, almost all of which rely on a compilation step to convert everything to HTML, CSS, and JS, doesn't seem to provide enough benefits in those paradigms.

   What incentives do JS library focused developers have to use WCs in a compile-necessary language?

   1. Micah 1 hr later

      @zachleat Said in another way, React provides everything developers need in a React environment to create custom elements, and all of that code will be compiled down to a snapshot to diff.

      Trying to get in the head of devs loyal to their JS libraries and frameworks, I'm struggling to make enough arguments for Web Components for any compiled language.

      1. Zach Leatherman 1 hr later

         @asuh it’s a good thought experiment! I consider it a limitation when when a compiler is required to own everything. Especially if the goal is to accommodate use cases with limited capability for build steps (which exist whether a framework supports them or not)

4. Emilis 🇺🇦 15 hr later

   @zachleat wake me up when web components start working without javascript instead of breaking the website for visitors with JS off.
   Also can you have multiple different versions of the same custom element on a page?
   IMO web components should have never got the full browser support.

5. pierstoval 16 hr later

   @zachleat years ago I was like "Web components are the future!", now I see the clumsy API, the time it took for browsers to adapt...

   I mean, I can compile a Svelte component into JS with zero harm and it's compatible with any web browser already, even old ones if I want, and the flexibility I have while coding it is immense, and more user-friendly than Web Components 😞

   It's sad to me, but so far, it's still harder to work with Web Components than Svelte 😕

6. Joe Gaffey 19 hr later

   @zachleat Then it's not a web framework.

7. mb21 1 day later

   @zachleat Strong “If your web framework doesn’t support XHTML and XSLT, it doesn’t support the web platform” vibes here.

   I’m usually all for using web-native tech without intermediary tools. But that’s because it brings me benefits like easier debuggability, better performance, more control, etc. As much as I’d like to say that of web components unfortunately I can’t…

   1. Zach Leatherman 1 day later

      @mb21 you took a thing I said and changed it to be a different thing 🫠 Do you want to talk about XSLT? I have a fair bit of experience with it!

      1. mb21 1 day later

         @zachleat I’ve had my share of experience with XSLT as well. I liked XQuery better, but that never made it into browsers. Anyway, my point was more that just because something is built into all browsers doesn’t necessarily mean it’s a good idea to use it.

         1. Zach Leatherman 1 day later

            @mb21 whew, XSLT might be the wrong tree to be barking up on this point specifically 😅. It was wicked fast in IE8 for templating—way speedier than DOM methods. Used to love it for that 🏆

            1. mb21 1 day later

               @zachleat Exactly. And I think we’ll see whether web components are going to feel stale like XSLT in >10 years.

               1. Zach Leatherman 1 day later

                  @mb21 Maybe that’s the root of the issue here. Folks are so tied up in how something *feels* (easily influenced by blog posts) and not the value it brings to real production use cases

                  anyway XSLT is still working fine for real use cases—eleventy-base-blog has one for Atom feed styling: https://eleventy-base-blog-git-v9-11ty.vercel.app/feed/feed.xml

                  Related: https://rknight.me/blog/styling-rss-and-atom-feeds/

                  1. mb21 2 days later

                     @zachleat Haha, well… beyond that one use-case, do you feel XSLT brings value to real production use cases?

                     1. Zach Leatherman 2 days later

                        @mb21 do we acknowledge the goal posts moving here or no 😅

                        1. mb21 2 days later

                           @zachleat no, I was saying that just because something is a native web tech doesn’t guarantee that it will be used forever, by drawing an analogy from web components to xslt and you responded with that perhaps people should worry about use-cases more, seemingly implying that xslt still has use-cases.

8. Private reply 1 day later