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 whe

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! If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you. If you're rabidly pro-TypeScript and think we're a bunch of luddite numpties, I'm about to disappoint you as well. Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won't affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever (for an example of this, see https://svelte.dev/blog/zero-config-type-safety https://svelte.dev/blog/zero-config-type-safety). I _would_ say that this will result in no changes that are observable to users of the framework, but that's not quite true — it will result in smaller packages (no need to ship giant sourcemaps etc), and you'll be able to e.g. debug the framework by cmd-clicking on functions you import from `svelte` and its subpackages (instead of taking you to an unhelpful type declaration, it will take you to the actual source, which you'll be able to edit right inside `node_modules` to see changes happen). I expect this to lower the bar to contributing to the framework quite substantially, since you'll no longer need to a) figure out how to link the repo, b) run our build process in watch mode, and c) understand the mapping between source and dist code in order to see changes. So this will ultimately benefit our users and contributors. But it will also benefit _us_, since we're often testing changes to the source code against sandbox projects, and this workflow is drastically nicer than dealing with build steps. We also eliminate an entire class of annoying papercuts that will be familiar to anyone who has worked with the uneven landscape of TypeScript tooling. The downside is that writing types in JSDoc isn't quite as nice as writing in TypeScript. It's a relatively small price to pay (though opinions on this do differ among the team - this is a regular source of lively debate). We're doing this for practical reasons, not ideological ones — we've been building SvelteKit (as opposed to Svelte) this way for a long time and it's been miraculous for productivity.

benmccann 3y ago
I was skeptical at first when we made the change in SvelteKit. However, SvelteKit has a large integration test suite and being able to change the code and rerun the tests against the real final version of the code without waiting for any build step to complete has been a big improvement to productivity and I'm now a big fan of having made the change there. The tradeoff may be a bit different in Svelte core where we have more unit tests and fewer integration tests, so we're still investigating and considering the change, but we do have experience with both approaches and at the end of the day great software can be built using either approach.
preommr 3y ago
> 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.

benmccann 3y ago

I was skeptical at first when we made the change in SvelteKit. However, SvelteKit has a large integration test suite and being able to change the code and rerun the tests against the real final version of the code without waiting for any build step to complete has been a big improvement to productivity and I'm now a big fan of having made the change there. The tradeoff may be a bit different in Svelte core where we have more unit tests and fewer integration tests, so we're still investigating and considering the change, but we do have experience with both approaches and at the end of the day great software can be built using either approach.

preommr 3y ago

> 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.