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

121–130 of 139 posts

Re: The Svelte Compiler Handbook

#121

Post by Casperin »

Trufa wrote: post #31
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.

I'm actually working on one. I don't know what will come out of it, but it's an interesting endeavor. As soon as it's shareable I will share it on Github. I'm basically trying to do a superset of typescript where you create elements so: const root = c({ el: 'div', children: [ `hello, ${store.user.name}` ], attr: { class: 'bold smart', id: 'abc', bla: true, }, evts: { click: () => { console.log("Clicked") } } }); And…

Is there any framework that explicitly allows me to set properties instead of just attributes? It doesn't play nice with web components when the object you passed in comes out as a string "[object Object]".

Re: The Svelte Compiler Handbook

#122

Post by bufferoverflow »

wolfadex wrote: post #62
bufferoverflow wrote: post #43

Earlier quoted context omitted.

That is awfully verbose.

What's wrong with being verbose?

You need to write more, you need to read more, and whoever maintains your code will need to read more. More chances for typos. That means more time wasted for everyone.

Why do you think we have async/await now instead of manually typing out all the promise syntaxic mess every time?

Re: The Svelte Compiler Handbook

#123

Post by madeofpalk »

orange8 wrote: post #89
madeofpalk wrote: post #88

Earlier quoted context omitted.

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.

No, I would not say that a type system is an "extremely opinionated" linter because TypeScript is about proving correctness and safety, not enforcing style guidelines.

A linter and a type system are two extremely different things. The only thing they have in common is that they statically analyse code.

Re: The Svelte Compiler Handbook

#124

Post by tekknik »

bufferoverflow wrote: post #122
wolfadex wrote: post #62

Earlier quoted context omitted.

What's wrong with being verbose?

You need to write more, you need to read more, and whoever maintains your code will need to read more. More chances for typos. That means more time wasted for everyone. Why do you think we have async/await now instead of manually typing out all the promise syntaxic mess every time?

because handling a promise using .then/.catch creates a new block? verbosity isn’t an issue as much as being too terse, especially with macros

Re: The Svelte Compiler Handbook

#125

Post by donohoe »

arkanciscan wrote: post #77
pts_ wrote: post #44

Earlier quoted context omitted.

Elaborate please.

It was a Twitter exchange that's been deleted so I can't remember the details. Suffices to say he was rude to me and that's colored my opinion of Svelte ever since.

Well, as someone who has met him several times I found him witty, kind, and a very friendly fellow.

I'm sure you are a very nice person but it is possible someone out there thinks you're a jerk despite that.

Re: The Svelte Compiler Handbook

#126

Post by Trufa »

Casperin wrote: post #121
Trufa wrote: post #31

Earlier quoted context omitted.

I'm actually working on one. I don't know what will come out of it, but it's an interesting endeavor. As soon as it's shareable I will share it on Github. I'm basically trying to do a superset of typescript where you create elements so: const root = c({ el: 'div', children: [ `hello, ${store.user.name}` ], attr: { class: 'bold smart', id: 'abc', bla: true, }, evts: { click: () => { console.log("Clicked") } } }); And…

Is there any framework that explicitly allows me to set properties instead of just attributes? It doesn't play nice with web components when the object you passed in comes out as a string "[object Object]".

What do you mean? how would it look?

Re: The Svelte Compiler Handbook

#127

Post by nojvek »

spankalee wrote: post #82
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.

at compiler time, you can type check and statically validate. Doing things at runtime with lit-html where things are in a string, quickly falls apart in a large project. One of my biggest griefs with Angular was that you could miss an ending tag in the template and it would work fine until it blows up in production when a customer accesses that specific scenario.

I stay away from magic templates compiled at runtime. I've been bitten way too many times. Plus it's not good for load performance when you have to ship a string compiler with your code.

Re: The Svelte Compiler Handbook

#128

Post by spankalee »

nojvek wrote: post #127
spankalee wrote: post #82

Earlier quoted context omitted.

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.

at compiler time, you can type check and statically validate. Doing things at runtime with lit-html where things are in a string, quickly falls apart in a large project. One of my biggest griefs with Angular was that you could miss an ending tag in the template and it would work fine until it blows up in production when a customer accesses that specific scenario. I stay away from magic templates compiled at runtime.…

How do you think lit-html templates would fall apart? There's nothing magic about them. They has as defined semantics as HTML or JavaScript - both of which are languages written as strings.

We use lit-html in thousands of components at Google with very strict type-checking and linting. You simply aren't allowed to miss an end tag, or bind to a non-existent attribute or property. The performance and code size are excellent, beating every major framework including those using compilers. The "compiler" we use is simply the HTML element and a tree-walk. It's very, very fast and very, very small.

Re: The Svelte Compiler Handbook

#129

Post by CapsAdmin »

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…

> I do not believe that you can write perfect code or avoid bugs.

I don't think anyone (including you) does. I don't think typescript pretends to be a perfect programming language that magically creates clean code either, but I think it gets us closer to that unrealistic goal.

> This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familiar with C#.

I very much disagree with this.

If you want to compare Typescript with another language, you have to remember that its typesystem is optional. So all you are left with basically Javascript. How much of the typesystem you want to use is up to you and your team.

Personally I try to let typescript infer the types as much as possible. I only explicitly annotate function arguments and foregin data. Sometimes there are cases where the typesystem won't work. Usually it's because I want to dynamically create something instead of verbosely defining everything. If the dynamic way is easier to maintain I choose that way and may lose some type information. (often you can tell the typesystem that "this dynamic blob" results in "this explicit type" though)

I'm not very fond of C# but I enjoy Typescript. I think the reason I don't like C# is because it forces you to make classes of everything which to me adds a lot of friction.

Re: The Svelte Compiler Handbook

#130

Post by IshKebab »

smnplk wrote: post #117
branko_d wrote: post #45

Earlier quoted context omitted.

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.

So you're saying it's a good idea to write what your types are in your code, but rather than writing them in a form that can be automatically checked by a computer and used for code completion and refactoring, you prefer to write them in a comment?
Post reply on HN