1. 17
  1.  

  2. 7

    So, we start with

    When I released emoji-picker-element, I made the decision to bundle its framework (Svelte) directly into the component.

    and then this:

    If you’re already using Svelte in your project, then you can import ‘emoji-picker-element/svelte’ and get a version that doesn’t bundle its own framework, ensuring de-duplication.

    Let me get this straight:

    1. If I import emoji-picker-element I get the Svelte-bundled version.
    2. If I import emoji-picker-element/svelte I do not get the Svelte part.

    Well, this is… horrible! The entire world out there works in exactly the opposite way. Everyone expects your library to have as few dependencies as possible, and any framework-related enhancements to be found in framework-specific modules like mylib/svelte. I’d rather just name the package svelte-mylib and spare myself and everyone else tons of grief.

    I could go on, but @soc summed it up quite nicely.

    1. 5

      True, this is the way most packages on npm work. But I tend to agree with posts like this one by Lea Verou arguing that web components are too newbie-unfriendly. A lot of developers are more comfortable with <script> tags than bundlers and build pipelines. They want something that “just works.”

      As-is, I can ship the same code for Node/npm and the browser using ES modules and sites like unpkg.com and jsdelivr.com. This JS file can be directly consumed in the browser, no bundler required. That wouldn’t be true if it had import 'svelte'.

      As mentioned in the post, though, Skypack is shaping up to be a good alternative: ship things in the npm/Node style, but then consume them on-the-fly in a pre-bundled format. I might switch to that.

      Again though, we’re talking about 1.4 kB of framework code out of 13.9 kB total, so it’s really tiddlywinks.

      1. 5

        The point is that with the standard import, the Svelte dependency is bundled and invisible. You do not need to even know Svelte exists as a framework to use it.

        The /svelte import is short for “I already have Svelte hanging around, so use that one instead”. It implies that the consumer is aware of and has set up Svelte.

        Makes perfect sense to me.

        1. 2

          The /svelte import is short for “I already have Svelte hanging around, so use that one instead”. It implies that the consumer is aware of and has set up Svelte.

          To me it implies the opposite. Why not say /without-svelte if you’re talking specifically about what you exclude?

      2. 3

        Because “web components” are a marketing term for a solution in search of a problem.

        1. 1

          Why? I think they are rather useful when it comes to cleanly separating functionality and enabling easier styling.

          1. 1

            I wrote up my thoughts here: https://blog.carlmjohnson.net/post/2020/web-components/

            Since then I will say I’ve gotten slightly more appreciation for the context having a dumb CMS in which you want to drop snippets of HTML and not have them clash. For that, I guess WC are as good as anything else (they can still clash but you have to be bad at naming for that to happen). But it’s sort of assuming a context where you have no control. If you have any control, you should just build the thing you want, and the top level tag can just be <div data-my-component> and it’s just as “semantic” as <my-component>. So for example, in my CMS at work, I write up shortcodes and so I can control what the shortcodes do exactly and have them hook into the main CSS and JS on the page instead of needing to isolate them in their own bubbles. If I had to use a CMS but was not able to write my own shortcodes, it might make sense as a strategy to use WC. But it doesn’t buy you much and it brings in a lot of problems: for example, the same blog as this story has a post about what a pain it is to do focus tricks with the shadowDOM.

        2. 1

          No.

          That said, I think the article is surprisingly nuanced, but I fear that the laissez-fair attitude shown in posts like this is a reason many people equate web developers with junior developers.

          1. 17

            Did you even read the post? The framework takes 1.4 kB out of 13.9 kB total, and as a result you get a self-contained component you can insert in any page. He also provides a framework-less package for those who already have the Svelte package in their dependencies. That seems a like a well thought out and reasonable approach.

            Also I would argue that either you use an existing framework or you need to reinvent one, or parts of it. You might end up with less than 1.4 kB overhead but probably with some subtle bugs and performance issues that have already been solved in other frameworks, not to mention the wasted time.

            1. 5

              In addition to all the problems other people mentioned already, it’s also a matter of longevity.

              Do users really want to have a component that invisibly bundles some framework, which they only become fully aware of when the framework ends up being abandoned after one JS hype cycle (~18 months) and the security issues start piling up?

              1. 1

                And if don’t you use a framework, the component will remain secure forever? Of course it wouldn’t, it still requires maintenance work and whether it means updating the framework, or switching to a better framework, or updating bespoke code, it’s maintenance work. Things don’t remain miraculously bug free and vulnerability free just because you don’t use a framework.

                If you are arguing that maintaining bespoke code from a random developer (who might have moved on) is easier than updating a widely used framework, then I guess we simply disagree. I know I’ll pick any time a framework rather than reinventing my own.

                Also that “JS hype cycle” meme is getting a bit old, and I wonder where you pull that 18 months from. Svelte has been around for 4 years, React for 8 years, etc.

              2. 1

                wouldn’t it be more reasonable to defer to the browser/OS for selecting input characters? unless I’m misunderstanding the purpose of the emoji picker.

                1. 9

                  The framework takes 1.4 kB out of 13.9 kB total, and as a result you get a self-contained component you can insert in any page.

                  And this is precisely how your app ends up with 15 versions of Svelte built-in with say 9 of them having security bugs. Or weird bugs where version N+1 of the library destroys version N’s global state.

                  1. 2

                    I think you meant to reply to /u/lau

                  2. 2

                    For sure, I would love for browsers to standardize on some kind of emoji picker, or to just delegate to the OS’s built-in picker. I wrote down some thoughts here on that.

                    1. 2

                      In theory yes.

                      But in practice a lot of sites these days want custom “emoji” which would be difficult to design into an OS/browser picker.

                      For example look at Android where just about every keyboard has an emoji picker but many apps (especially messaging apps) have their own button to add emoji.

                      1. 1

                        custom emoji would not be present in a pre-packaged web component anyway