Live data from Hacker News

The Svelte Compiler Handbook

lihautan.com

101–110 of 139 posts

Re: The Svelte Compiler Handbook

#101
post #99
post #97

Earlier quoted context omitted.

> You appear to assume I like your choice of words, but no. I disagree with that assumption.

Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.

And I will observe, once again, that all that means nothing without best practice and discipline.

Re: The Svelte Compiler Handbook

#102
post #98
post #96

Earlier quoted context omitted.

I get it. You like TypeScript, it works for you. You like and firmly believe in static types, also great. No one is asking you to stop using them, or suggesting that they are bad. They are all just tools, use the ones that work for you. Personally, I do not need TypeScript, ESlint gets me there, but then again I'm not you. Just like I'm not going to assume your code is completely perfect and bug free because you use…

I’m not assuming it’s bad and buggy code. My day job is writing Elixir, albeit with full type spec coverage, and the code is fine. But that’s enabled by an extensive test suite, as well as type specs. Do we need these things, strictly speaking? No. But we don’t really need any of the tools we build and use, yet we build them because they make certain things easier and more reliable. My code is not perfect and bug fre…

> it is guaranteed to be free of type errors provided the type system is sound

Give me an example of a sound type system.

Re: The Svelte Compiler Handbook

#105

Earlier quoted context omitted.

lit-html is written in TypeScript, so has great typings. There are TypeScript plugins to statically analyze the templates, like lit-analyzer and the lit-plugin VS Code extension. LitElement provides TypeScript decorators for declaring reactive properties and more.

While it is writen in typescript, it's still aimed towards JS first.

I'm not exactly sure what you mean then.

TypeScript doesn't in general change its emit based on types, so its runtime feature set is exactly the same as JavaScript.

lit-html has a TypeScript compiler plug-in which provides template type=-checking, and LitElement provides decorators, like I said. How would something be more aimed at TypeScript, and not JavaScript?

Re: The Svelte Compiler Handbook

#106
post #99

Earlier quoted context omitted.

Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.

And I will observe, once again, that all that means nothing without best practice and discipline.

It doesn't mean nothing without those things though. It means exactly the same whether or not you follow best practices or have discipline, that's the entire point. It will not ensure your code is good, it will merely ensure it does not have those problems.

Re: The Svelte Compiler Handbook

#107

Earlier quoted context omitted.

While it is writen in typescript, it's still aimed towards JS first.

I'm not exactly sure what you mean then. TypeScript doesn't in general change its emit based on types, so its runtime feature set is exactly the same as JavaScript. lit-html has a TypeScript compiler plug-in which provides template type=-checking, and LitElement provides decorators, like I said. How would something be more aimed at TypeScript, and not JavaScript?

The project front page talks all about JavaScript, and no mention of TypeScript. So to me it's not aimed primarily toward developing against it in TS.

Re: The Svelte Compiler Handbook

#108
post #98

Earlier quoted context omitted.

I’m not assuming it’s bad and buggy code. My day job is writing Elixir, albeit with full type spec coverage, and the code is fine. But that’s enabled by an extensive test suite, as well as type specs. Do we need these things, strictly speaking? No. But we don’t really need any of the tools we build and use, yet we build them because they make certain things easier and more reliable. My code is not perfect and bug fre…

> it is guaranteed to be free of type errors provided the type system is sound Give me an example of a sound type system.

STLC

Re: The Svelte Compiler Handbook

#109

Earlier quoted context omitted.

While it is writen in typescript, it's still aimed towards JS first.

I'm not exactly sure what you mean then. TypeScript doesn't in general change its emit based on types, so its runtime feature set is exactly the same as JavaScript. lit-html has a TypeScript compiler plug-in which provides template type=-checking, and LitElement provides decorators, like I said. How would something be more aimed at TypeScript, and not JavaScript?

"Good Typescript Support" and "Technically Written in Typescript" are very different things.

Re: The Svelte Compiler Handbook

#110
post #106

Earlier quoted context omitted.

And I will observe, once again, that all that means nothing without best practice and discipline.

It doesn't mean nothing without those things though. It means exactly the same whether or not you follow best practices or have discipline, that's the entire point. It will not ensure your code is good, it will merely ensure it does not have those problems.

If its about clean code, all that means nothing without discipline and good practice. Clean code is something humans do, not linters, compilers or languages.
Post reply on HN