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

81–90 of 139 posts

Re: The Svelte Compiler Handbook

#81

Post by txdv »

Barrin92 wrote: post #69
combatentropy wrote: post #56

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…

that guy works as a school bus driver so, after work he codes all day

Re: The Svelte Compiler Handbook

#82

Post by spankalee »

nojvek wrote: post #73

I really like that Svelte does compiler time dependency analysis such that there is less work to do runtime. Can we bring this ideas to react and Vdom based frameworks? I imagine Babel/typescript can analyze jsx to find which attribute are bound to a variable and which are just static. The static ones don’t need to be diffed, only the dynamic ones.

You don't need a compiler to do that. lit-html does this at runtime, and the benefit from not diffing static content is large.

Re: The Svelte Compiler Handbook

#83

Post by spankalee »

xellisx wrote: post #29

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.

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.

Re: The Svelte Compiler Handbook

#84

Post by Stratoscope »

hinkley wrote: post #72
dragosmocrii wrote: post #54

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…

I felt like there was a sort of sea change when JetBrains started producing multiple IDEs. IDEA always struggled to handle supporting everything at once and third party plugins are always incomplete. They don’t support all of the functionality and you have to keep that active in your mind while developing, which saps resources for solving hard problems. I just wish they could support more languages and tool chains, a…

> I wish an IDEA subscription entitled you to all other versions of the editor.

They do offer that; it's called the All Tools subscription. It costs more than the IntelliJ subscription, but you get all the IDEs, ReSharper, etc.

Re: The Svelte Compiler Handbook

#85

Post by rgoulter »

hitekker wrote: post #80
xupybd wrote: post #3

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

Prezi, the original company that backed Elm, laid-off the maintainer and then deprecated Elm in their codebase.

I wasn't aware of that context.

Though evancz now works at NoRedInk. https://www.noredink.com/about/team

Re: The Svelte Compiler Handbook

#86

Post by xupybd »

adelarsq wrote: post #50
xupybd wrote: post #3

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

Try F#. Has good tooling and its possible to use the ELM arch. See https://zaid-ajaj.github.io/the-elmish-book

Thank you this looks great. Okay now another tool to try. This is tricky business when you're looking for the tool set you want to invest in for the next 2 to 5 years and there are so many promising options.

Re: The Svelte Compiler Handbook

#87

Post by 0az »

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.

IIRC, Vue 3 uses Typescript.

Re: The Svelte Compiler Handbook

#88

Post by madeofpalk »

orange8 wrote: post #35
CapsAdmin wrote: post #26

Earlier quoted context omitted.

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 st…

> "Just don't write bugs", "just write perfect code", etc You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code. > you could still argue that type checking the codebase in your head is time consuming This again, depends on the particular history an…

As a “life long” web/JavaScript developer, ESLint is nowhere near comparable to Typescript. One is a language, and the other is an (overused and over configured) linter. They’re two different things.

I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language.

Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exceptionally similar because it’s literally the same, just with types added on top.

Re: The Svelte Compiler Handbook

#89

Post by orange8 »

madeofpalk wrote: post #88
orange8 wrote: post #35

Earlier quoted context omitted.

> "Just don't write bugs", "just write perfect code", etc You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code. > you could still argue that type checking the codebase in your head is time consuming This again, depends on the particular history an…

As a “life long” web/JavaScript developer, ESLint is nowhere near comparable to Typescript. One is a language, and the other is an (overused and over configured) linter. They’re two different things. I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language. Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exc…

I have worked with two compile to JS languages, CoffeeScript and TypeScript.

> One is a language, and the other is an (overused and over configured) linter.

You could also say that one is an extremely opinionated linter and the other is just a linter.

Re: The Svelte Compiler Handbook

#90

Post by orange8 »

jolux wrote: post #71
orange8 wrote: post #32

Earlier quoted context omitted.

The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !! That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new p…

You're making a false dichotomy here. There's a lot of light between something being a magical silver bullet that solves all your problems and every programming language being equally bad. If that weren't the case we would probably have never progressed from unstructured programming. In general the greatest progress in software engineering practice at the level of programming languages is made when something that was…

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs.

This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.

> ...and every programming language being equally bad.

I simply did not say that.

Post reply on HN