Live data from Hacker News

The Svelte Compiler Handbook

lihautan.com

111–120 of 139 posts

Re: The Svelte Compiler Handbook

#111
post #106

Earlier quoted context omitted.

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.

Have you written a significant amount of C? I ask this because you said you don't write any of it in a comment in which you suggested its problems could be avoided by following best practices and being disciplined. There are a set of problems that languages have that just cannot be solved by humans adopting better discipline or best practices. C's type system is unsafe, and its memory handling is an adjacent and related problem. Tools like Valgrind exist and they are considered best practices when writing C, but they do not claim and cannot hope to make it memory safe. Fixing that problem requires language-level intervention, and this has been solved most of the time with better static type systems. Anyone who writes a lot of C will tell you this, it is an inherent pitfall of the language's design and one to be avoided when designing new languages.

Re: The Svelte Compiler Handbook

#112
post #108

Earlier quoted context omitted.

> 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

> STLC

Software Testing Life Cycle? That is not a type system, that is a software development methodology. Thought you'd mention atleast TypeScript or Elixir, but no, you went for the a whole software development methodology. Which kind of puts you in a bind now, since you also said: "..it is guaranteed to be free of type errors provided the type system is sound". So where does that leave us if you cannot confidently give an example of a sound type system?

> That level of confidence in types is just not possible in a dynamic language.

Not possible with static languages either, unless ofcourse you use the whole "Software Testing Life Cycle". Do you know what I like most about STLC? It advocates what I have been saying all along: discipline and best practice!!!

And you can use STLC with dynamic languages to and get the same benefits.

Re: The Svelte Compiler Handbook

#113
post #108

Earlier quoted context omitted.

STLC

> STLC Software Testing Life Cycle? That is not a type system, that is a software development methodology. Thought you'd mention atleast TypeScript or Elixir, but no, you went for the a whole software development methodology. Which kind of puts you in a bind now, since you also said: "..it is guaranteed to be free of type errors provided the type system is sound". So where does that leave us if you cannot confidently…

[deleted]

Re: The Svelte Compiler Handbook

#114
post #108

Earlier quoted context omitted.

STLC

> STLC Software Testing Life Cycle? That is not a type system, that is a software development methodology. Thought you'd mention atleast TypeScript or Elixir, but no, you went for the a whole software development methodology. Which kind of puts you in a bind now, since you also said: "..it is guaranteed to be free of type errors provided the type system is sound". So where does that leave us if you cannot confidently…

> Software Testing Life Cycle?

No.

Re: The Svelte Compiler Handbook

#115

Earlier quoted context omitted.

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.

Do you have specifics?

Re: The Svelte Compiler Handbook

#116

How did Rich Harris, a "graphics editor," write Svelte? So many designers hardly know JavaScript at all. This one wrote one of the most advanced JavaScript frameworks I've ever seen. It's not just JavaScript. He wrote a compiler that takes a custom, declarative syntax and converts it to imperative JavaScript to surgically update the DOM.

He probably was interested in it. Not everyone has a traditional background or even day job in the area they're passionate about. One of our neighbours growing up in a small village was a nice old retired man who barely had any formal education, years later I found out he was publishing original maths research online. There's also a guy from Finland who IIRC was a bus driver who is putting great C++ low level graphic…

The bus driver is bisqwit https://www.youtube.com/watch?v=3bIcbnDXSRg

Re: The Svelte Compiler Handbook

#117
post #21

Earlier quoted context omitted.

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs I'd say it depends on your teams skill set and level of disciple. The best defence against a buggy codebase isn't a programming language or framework, its good all fashioned discipline.

It's not just about bugs. Static typing is crucial for productivity whenever the codebase overflows your brain's working memory. Navigating through code, refactoring, or simply figuring out what to pass as function input can become a challenge in the absence of types.

That's why god invented comment blocks. But some people view them as code smell, which i find very strange. And no, good naming is not always enough.

Re: The Svelte Compiler Handbook

#118

I like Svelte very much. My biggest struggle is with tooling, especially the lack of proper IDE support. I know there are several IDEs with plugins for Svelte, but they're either obsolete or lacking essential features. That's why I won't use it for me next project, just not worth it going against the wind. Now, I am looking at Flutter. Seems to match my needs, and it's also actively maintained. Never underestimate th…

Flutter web support is in beta. I've never heard of anyone using it. Don't you think you are swimming upstream there too?

For applications it's actually quite good, if you use the WASM renderer instead of the DOM based one. I say for applications and not websites as this method will not have any SEO since it renders onto a canvas element. It does have accessibility as Flutter constructs a separate semantic tree on top that accessibility devices can read.

So Flutter Web is pretty nice if you're not making a forum for example but moreso any type of CRUD or business app where text is not a big factor. Of course, since it's Flutter you can then build mobile and desktop apps as well from your application for those who want more control.

Re: The Svelte Compiler Handbook

#119
post #114

Earlier quoted context omitted.

> STLC Software Testing Life Cycle? That is not a type system, that is a software development methodology. Thought you'd mention atleast TypeScript or Elixir, but no, you went for the a whole software development methodology. Which kind of puts you in a bind now, since you also said: "..it is guaranteed to be free of type errors provided the type system is sound". So where does that leave us if you cannot confidently…

> Software Testing Life Cycle? No.

> STLC

>> Software Testing Life Cycle?

> No

Ok. Since you were saying things like "..that’s enabled by an extensive test suite, as well as type specs" I assumed it must be something to do with testing. Must be a programming language I've never heard about then.

Re: The Svelte Compiler Handbook

#120
post #21

Earlier quoted context omitted.

The problem with Svelte is it doesn't support Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs. Vue has a similar problem (it sort of supports Typescript, but not properly and templates aren't type checked). I've not used Elm so maybe that is better. React has good support for type checking. I would use that.

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs I'd say it depends on your teams skill set and level of disciple. The best defence against a buggy codebase isn't a programming language or framework, its good all fashioned discipline.

I think you mean “old fashioned”... which goes to show that even skilled, disciplined, knowledgeable folks can make simple mistakes. When the stakes are high, it’s important to use tools to augment human judgement.
Post reply on HN