MaxArt2501

I can't, for the sake of me, understand how some frontend devs still complain about CSS' global scope when style encapsulation exists and is widely adopted in a form or the other, either native (Shadow DOM) or emulated.

You don't like global styles? Don't use global styles, period.

Even without adopting Nue and staying on React, CRA and Next comes out with CSS Modules out of the box. Angular and Vue have their own equivalent.

That's an interesting hybrid approach, thanks Andrea.

Is this what Svelte will use? (Asking anybody that knows, of course.)

Anyway, to me the main problem in using TS with libraries is that we have 3-4 major releases per year, and they're just too many. Unless one takes a very restrained approach, releasing very generic (and thus less helpful) types that won't (presumably) break future (or past) versions of TypeScript, we need to release with `typesVersions` targetting n different versions of TypeScript. That's an ever-growing bother indeed for maintainers as time passes.

And I fear the hybrid approach above won't escape this issue. So using "pure" JSDoc or JSDoc with just a sprinkle of TypeScript actually makes sense... But I'd expect this workflow to be winning with smaller projects, and that's why this announcement for Svelte has been surprising to me.

> it starts to add up both in bandwidth, and in storage taken

Are we really talking about disk space in 2023? Seriously?

And bandwidth? Like we don't have several cache systems - including npm's - that can help?

> how to make your software easier to change in the future

Ok, is there someone who can explain in details how would that help?

> JSDoc _is_ TypeScript

No. At least, it didn't used to be. JSDoc had its own syntax, but now you can piggyback its format and put TypeScript inside. So now you can write `@type {Record<string, number>}` instead of the "classic" `@type {Object.<string, number>}`, and use some more TypeScript goodies.

You can even kind of use generics with JSDoc, still thanks to TypeScript, but then again... you're not really leaving TypeScript, you'll still have to deal with TS versions, and probably with some of the not-clearly-explained "papercuts" from above.

And finally, I'm not sure that JSDoc+TypeScript is perfectly equivalent to TypeScript. I have a hunch that some of the advanced strategies, e.g. involving `infer` or `extends`, aren't really replicable in JSDoc - or at least I have no clue how to do that in JSDoc - so we'll have to settle for weaker definitions in some cases. So, I'll have to see if it's actually "the same outcome".

I admit I'm no JSDoc guru, so maybe if somebody is compelled to try harder they might actually find a solution for a transition from TypeScript to a completely equivalent alternative. I'm all ears... but surely, if you try too hard the point will be lost.

All of this just to help the Svelte community to contribute - I'll have to take Rich' word for it. For now, it's the only community I've heard that switched from TypeScript in favor of JSDoc. They'll have to deal with a more verbose and less readable codebase for sure, I think there's no doubt about it. Is it really helping the contributors?

It may work for an open source project with a strong governance, maybe. I have a very different experience with projects that decided to use JS instead of TS. Unless we're talking about a very small project, it always turned out to be an ungodly mess.

> it doesn't have to be built to run

If this is a problem, then you have other problems...

For me, the main problem is that TS doesn't follow semantic versioning and this leads to a fragmentation of libraries support - unless they also provide multiple type definitions (some of them actually do) - and migrating to newer versions is usually harder, because breaking changes happen so often. So I guess point i) is correct.

Let's see the others.

ii) It's true that many libraries don't have type definitions, but the most used ones have an externally-maintained corresponding @types/### package that solves the problem. And even if they don't, how is it the fault of TS? The alternative is no type documentation at all - is that better for you?

iii) Yes, error messages are something that can be improved, but then again, the alternative is no static error and eventually an even more laconic runtime error. Would that be better? At least, TS catches that there's a problem before you run the code.

iv) Compilation adds a burden to the CPU, not the developer. But anyway, it's a one-time process, and unless it takes 30 minutes it shouldn't be a problem. There are new, much faster compilers nowadays, like esbuild and SWC, plus other tooling tricks like module caching, that makes your local development almost feel like there's no compilation at all.

I won't discuss the merits of the adoption of TypeScript. Since I started using it - except for very simple projects - I always felt like I'd be way less productive without it. And I actually had the confirm recently, when I had to work on a Loopback@3 BE that somehow is in JavaScript (even though Loopback 3 does support TS).

It's been a mess. Trying to understand the models, the signature and the sense of all the entities has been a nightmare. The documentation for LB v3 is badly maintained and sometimes broken, and this adds even more difficulty. Some dev tried to add some JSDoc info here and there, but it's not nearly sufficient to understand what's going on without investing hours of study of the existing code.

This is part of the cause that prevented the team to upgrade to LB@4, so much that I even suggested to redo the BE altogether in Nest (save for the core business logic parts), rather than trying to make a sense of it.

So yeah, I'll stick to TS for the foreseeable future, and strongly suggest all the teams I'm going to work with to do the same.

I'll have to deal with npm and bower too, though. I guess I'll have to release a new package and deprecate the old one.

Yeah, someone already pointed that out on Reddit :( Let's see how it develops.

I agree, that's somewhat annoying, but that's also something developers and commissioners want.

But the good news is that the DOM skeleton is so minimal that you can create a stylesheet that does exactly what you said. Given the reference to the selection, positioning the popover is up to the developer.

Are you using Firefox, perchance? It has a "bug" (not sure about that, but surely it's the only one that shows that behavior) relating to SVGs, so it used to size incorrectly the fouth icon. I worked it around some minutes ago and it should be fine.

The first icon should be Twitter, so maybe it's really Adblocker. I've tested it with uBlock Origin and it shows the same behavior but, honestly, I don't want to tamper with that.

In fact, the sharers that are provided are meant to be examples, and not part of the core library. I guess simply changing the name attribute of the sharer would end up in showing the button.

I'm pretty sure there's a lot of prior art for their "design", so I'm kind of safe there.

Edit: unless you were referring to the whole aspect of the page. In that case, it's just a presentational page for an open source project, so it has nothing to do with blogging platforms. That should be ok, I guess.

Strange. The selection itself isn't handled by the library itself, rather than the browser/OS. The library only reacts when a selection is made.

Does it happen to you in other cases as well?

I actually used the sharing functionality provided by the library to post this link here.

Suggestions are well accepted.

It's definitely VS Code and it's quite mind-blowing thinking that they're the guys behind Atom, and the blog's domain is electron.atom.io.