Live data from Hacker News

The Svelte Compiler Handbook

lihautan.com

131–139 of 139 posts

Re: The Svelte Compiler Handbook

#131
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…

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

TS may compile down to JS, but that does not make it the same language. TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way. How you structure your code using a dynamic, functional language should be very different from how you structure your code in a static, object oriented language. If your code structure looks more or less just the same between the two, then you are doing one of them wrong.

> you have to remember that its type system is optional

Doesn't opting out of the type system defeat the purpose of using TYPE-script in the first place?

Re: The Svelte Compiler Handbook

#132

Earlier quoted context omitted.

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

TS may compile down to JS, but that does not make it the same language. TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way. How you structure your code using a dynamic, functional language should be very different from how you structure your code in a static, object oriented language. If your code structure looks more or less just the same between the two, then…

> TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way.

Where do you get the idea that Typescript code should be structured like a static object oriented language? Is it because it's a Microsoft product?

Letting Typescript try and figure out the types while coding in a "dynamic and functional way" is what works best for me. Is this wrong?

Re: The Svelte Compiler Handbook

#133
post #70

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…

Svelte support in the Jetbrains family of tools is great (IDEA, Webstorm etc). There are a few issues, but they're all minor. Started using Svelte for serious work a few months ago, very happy with it, best frontend framework I've worked with thus far.

I'm just starting to play with Svelte, but have very little JS background. Which flavor of the jetbrains tools are you actually using; webstorm or IDEA? I have the all-tools sub, so could use either but is one better than the other?

Re: The Svelte Compiler Handbook

#134
post #3

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

If you haven't yet, find and read the lengthy "why I'm leaving elm" post; there's a big discussion here also. May provide some impetus one way or the other for you.

Re: The Svelte Compiler Handbook

#135
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.

I'd say Elm has support for types, yes =D

Re: The Svelte Compiler Handbook

#136
post #117

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.

"not always enough" is still better than "none". This feels like a classic "good being the enemy of the perfect" issue.

Re: The Svelte Compiler Handbook

#137

Earlier quoted context omitted.

TS may compile down to JS, but that does not make it the same language. TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way. How you structure your code using a dynamic, functional language should be very different from how you structure your code in a static, object oriented language. If your code structure looks more or less just the same between the two, then…

> TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way. Where do you get the idea that Typescript code should be structured like a static object oriented language? Is it because it's a Microsoft product? Letting Typescript try and figure out the types while coding in a "dynamic and functional way" is what works best for me. Is this wrong?

https://github.com/gcanti/fp-ts

Re: The Svelte Compiler Handbook

#138
post #117

Earlier quoted context omitted.

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?

No, I said no such thing. If you happen to be in a dynamic environment, then yes, I see no foul in describing inputs to a function inside a comment above function declaration. Use comments to describe your intents on non trivial parts of your code. There is no amount of code readability that will help your colleague, if she doesn't understand your thought process at the time of writing the code.

Re: The Svelte Compiler Handbook

#139
post #70

Earlier quoted context omitted.

Svelte support in the Jetbrains family of tools is great (IDEA, Webstorm etc). There are a few issues, but they're all minor. Started using Svelte for serious work a few months ago, very happy with it, best frontend framework I've worked with thus far.

I'm just starting to play with Svelte, but have very little JS background. Which flavor of the jetbrains tools are you actually using; webstorm or IDEA? I have the all-tools sub, so could use either but is one better than the other?

Webstorm. I use the different tools mostly to naturally categorize all the different kinds of projects that I work on, even though I think IDEA brings (most of?) the relevant features from the other IDEs.
Post reply on HN