Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Svelte Compiler Handbook

lihautan.com

Post reply on HN
Print view View original

21–30 of 139 posts

Re: The Svelte Compiler Handbook

#21

Post by orange8 »

IshKebab wrote: post #14
xupybd wrote: post #3

Having a hard time choosing between Svelte and Elm. For a lone in house dev, any recommendations?

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.

Re: The Svelte Compiler Handbook

#22

Post by bambataa »

orange8 wrote: post #21
IshKebab wrote: post #14

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.

Don’t need to catch bugs if you just don’t write them! taps head.

It is still worthwhile imo to have something that catches mistakes even great people make.

Re: The Svelte Compiler Handbook

#23

Post by k__ »

amelius wrote: post #15

I skimmed through it, but couldn't find a description of the distinguishing feature of svelte, i.e. how the incremental updates are performed.

I think the idea is to provide the programming model that React allows via its virtual DOM, but compile all that code away, so you end up with code das works without a virtual DOM.

Direct DOM interactions are faster and you don't have to bring a whole VDOM library.

Re: The Svelte Compiler Handbook

#25

Post by maps7 »

xupybd wrote: post #3

Having a hard time choosing between Svelte and Elm. For a lone in house dev, any recommendations?

I picked up Svelte recently and I am happy with it. There is good documentation and examples and any questions I had were already answered online.

I haven't used Elm yet.

Re: The Svelte Compiler Handbook

#26

Post by CapsAdmin »

orange8 wrote: post #21
IshKebab wrote: post #14

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 we all agree on this, but we don't all agree that "just be disciplined" works in practice.

"Just don't write bugs", "just write perfect code", etc

Given that you and your team has all the discipline you need, you could still argue that type checking the codebase in your head is time consuming and is better spent on higher level concepts.

A typesystem can get in the way and slow down development if it's too strict of course, but I feel typescript does a good job of keeping it optional enough.

There is no clear answer here, but at least refactoring is much easier and safer given that your types are sound.

Re: The Svelte Compiler Handbook

#27

Post by orange8 »

bambataa wrote: post #22
orange8 wrote: 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.

Don’t need to catch bugs if you just don’t write them! taps head . It is still worthwhile imo to have something that catches mistakes even great people make.

I completely agree. That something is a linter, of which TypeScript is just one of the many options available. This whole idea of you cannot write a big app in JS is just peddled by those who do not understand, or hate JS. A good linter, proper programming practices, discipline will get you there. Anytime someone peddles a language or framework as a magic bullet to clean code, they're either selling you some snake oil or have drunk too much of some koolaid, imho.

Re: The Svelte Compiler Handbook

#28

Post by jiofih »

PudgePacket wrote: post #18
amelius wrote: post #15

I skimmed through it, but couldn't find a description of the distinguishing feature of svelte, i.e. how the incremental updates are performed.

It's actually really easy to read the svelte compiler output! You'll see exactly how it works :P

I assume people downvoting this comment are not familiar with Svelte?

You can in fact see how it works by looking at the output. Go to the REPL at https://svelte.dev/repl/hello-world and select “JS output”.

Re: The Svelte Compiler Handbook

#29

Post by xellisx »

I'm surprised Apprun nor Solid have been mentioned yet.

Are there any TypeScript reactive frameworks? I know you can use TS with the others, but finding tutorials can be a pain since it all these are JS first frameworks.

Re: The Svelte Compiler Handbook

#30

Post by giantDinosaur »

orange8 wrote: post #27
bambataa wrote: post #22

Earlier quoted context omitted.

Don’t need to catch bugs if you just don’t write them! taps head . It is still worthwhile imo to have something that catches mistakes even great people make.

I completely agree. That something is a linter, of which TypeScript is just one of the many options available. This whole idea of you cannot write a big app in JS is just peddled by those who do not understand, or hate JS. A good linter, proper programming practices, discipline will get you there. Anytime someone peddles a language or framework as a magic bullet to clean code, they're either selling you some snake oi…

This is the kind of attitude that has resulted in a million code vulnerabilities in C because the idea that it's inherently unsafe is just an idea 'peddled by people unskilled in its application' (to re-express nicely). It's the kind of attitude which will ignore the many inconsistencies in languages which were the result of historical accident instead of good design because it's just a blind acceptance of the way things turned out to be rather than what they _could_ be. Many who go on about 'discipline' are often creating error prone applications and, ironically, peddling 'discipline' as that very magic bullet to cure all ills.

I don't know if I've even seen discipline defined beyond some self-referential 'avoid doing these bad things that our language/environment allows by knowing that they're bad before you make the mistakes that show you they're bad'. Do developers just shrug and accept it as a fundamental design constraint to good programming languages when their booleans add with their integers and concatenate with their strings and give essentially random results? Do they not wonder: is there a system, more fundamental than linting, which can solve many of these issues in a general case?

Post reply on HN