6 ms·

> Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions w

> Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions whenever this stuff comes up! Because people want to follow in the footsteps of big projects that have gained specialized knowledge through experience. It's also a really contrarian viewpoint about typescript which is really popular. tbh, this seems pretty far out there. Sourcemap file size is a non-issue, they're not gigabytes, and editors like vscode now support going to the source definition for projects that support it. To completely switch over to js and then set types that way seems regressive. Just so that people can modify the source code directly a little bit easier? There are all kinds of tools ranging from ts-node-dev that make watching typescript files easy, with options to skip type checking for better speed. Honestly seems kind of backwards.

capableweb 3y ago
> tbh, this seems pretty far out there. Sourcemap file size is a non-issue, they're not gigabytes Sure, by themselves, but replicate that across everyone repeatedly downloading the library in various build processess, in various projects and with different versions. Sure, by itself a sourcemap might not add up to much. But then there is various projects with different versions, who download the library repeatedly in different build steps. Then it starts to add up both in bandwidth, and in storage taken. Luckily, there are still package and library maintainers who care about making things less, instead of more, both in architectures and size. > Just so that people can modify the source code directly a little bit easier? This is a real thing that is useful to think about, how to make your software easier to change in the future, while just solving the current concern without over-engineering the solution.
- MaxArt2501 3y ago
  > 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?
  - capableweb 3y ago
    > Are we really talking about disk space in 2023? Seriously? Well, it adds up, if you're doing multiple projects. Doing a quick scan of my work desktop, I find 43,237 filenames matching ".js.map". The biggest is at ~10,000 KB, the smallest at 1KB. If we assume the average is just 200KB, in total they represent ~8.6 gigabytes (200 kilobytes 43237). That's not nothing. > And bandwidth? Like we don't have several cache systems - including npm's - that can help? Being conservative with bandwidth is a good thing for most. Not only will everything download faster because less is needed, but it'll probably be cheaper for you to run your application as serving less bandwidth either gives you a small bill if you use cloud, or requires less hardware if you're going the dedicated route. Not to mention not everyone sits with the latest maxxed out Apple hardware for working, especially outside the SV bubble. These people deserve to be able to have a good development environment as well. Overall, everything gets faster and cheaper if you save bandwidth. > Ok, is there someone who can explain in details how would that help? It's easy, the lesser moving parts your application has in the abstraction ladder, the safer and easier it gets to change things in the future. Transpiling from one language to another to get a benefit you can also get by not transpiling a language from one to another, seems like a no-brainer to me in most cases.
_gruntled 3y ago
> It's also a really contrarian viewpoint about typescript which is really popular. I really, really don't get the controversy here. JSDoc _is_ TypeScript, just with a syntax that's valid JavaScript (on account of it living in comments). This means it doesn't have to be built to run, but still gets all of the typing goodies regular TypeScript does. The end-user code authoring experience is the same or better. > To completely switch over to js and then set types that way seems regressive. "It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take.
- deprecative 3y ago
  > "It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take. To be fair, "We are so invested in TypeScript we're dropping it!" is an equally astonishing take. It's language I'd expect from Google about any of their projects.
  - _gruntled 3y ago
    But that's the thing, it's _not astonishing_. It _would_ be astonishing if we were abandoning typing Svelte. We're not. We're not even abandoning TypeScript -- the whole project will still run `tsc` and enforce complete type-safety, it just won't use the compiled output. This is _abandoning one syntax for another_ because one syntax doesn't require a build step and a huge toolchain to run and debug.
- MaxArt2501 3y ago
  > 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...

capableweb 3y ago

> tbh, this seems pretty far out there. Sourcemap file size is a non-issue, they're not gigabytes Sure, by themselves, but replicate that across everyone repeatedly downloading the library in various build processess, in various projects and with different versions. Sure, by itself a sourcemap might not add up to much. But then there is various projects with different versions, who download the library repeatedly in different build steps. Then it starts to add up both in bandwidth, and in storage taken. Luckily, there are still package and library maintainers who care about making things less, instead of more, both in architectures and size. > Just so that people can modify the source code directly a little bit easier? This is a real thing that is useful to think about, how to make your software easier to change in the future, while just solving the current concern without over-engineering the solution.

MaxArt2501 3y ago
> 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?
- capableweb 3y ago
  > Are we really talking about disk space in 2023? Seriously? Well, it adds up, if you're doing multiple projects. Doing a quick scan of my work desktop, I find 43,237 filenames matching ".js.map". The biggest is at ~10,000 KB, the smallest at 1KB. If we assume the average is just 200KB, in total they represent ~8.6 gigabytes (200 kilobytes 43237). That's not nothing. > And bandwidth? Like we don't have several cache systems - including npm's - that can help? Being conservative with bandwidth is a good thing for most. Not only will everything download faster because less is needed, but it'll probably be cheaper for you to run your application as serving less bandwidth either gives you a small bill if you use cloud, or requires less hardware if you're going the dedicated route. Not to mention not everyone sits with the latest maxxed out Apple hardware for working, especially outside the SV bubble. These people deserve to be able to have a good development environment as well. Overall, everything gets faster and cheaper if you save bandwidth. > Ok, is there someone who can explain in details how would that help? It's easy, the lesser moving parts your application has in the abstraction ladder, the safer and easier it gets to change things in the future. Transpiling from one language to another to get a benefit you can also get by not transpiling a language from one to another, seems like a no-brainer to me in most cases.

_gruntled 3y ago

> It's also a really contrarian viewpoint about typescript which is really popular. I really, really don't get the controversy here. JSDoc _is_ TypeScript, just with a syntax that's valid JavaScript (on account of it living in comments). This means it doesn't have to be built to run, but still gets all of the typing goodies regular TypeScript does. The end-user code authoring experience is the same or better. > To completely switch over to js and then set types that way seems regressive. "It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take.

deprecative 3y ago
> "It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take. To be fair, "We are so invested in TypeScript we're dropping it!" is an equally astonishing take. It's language I'd expect from Google about any of their projects.
- _gruntled 3y ago
  But that's the thing, it's _not astonishing_. It _would_ be astonishing if we were abandoning typing Svelte. We're not. We're not even abandoning TypeScript -- the whole project will still run `tsc` and enforce complete type-safety, it just won't use the compiled output. This is _abandoning one syntax for another_ because one syntax doesn't require a build step and a huge toolchain to run and debug.
MaxArt2501 3y ago
> 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...