4 ms·

It's cute but I can't recommend it for a project with more than one developer. Lack of TypeScript support and the hacky component model (specifically, Svelte's

by ng12 7y ago

It's cute but I can't recommend it for a project with more than one developer. Lack of TypeScript support and the hacky component model (specifically, Svelte's equivalent of React props) are the two big deal-breakers.

vivekseth 7y ago
I haven’t done much React, but I’ve played around with svelte a bit recently and I haven’t found any severe issues with the props model. What don’t you like about it?
- ng12 7y ago
  Since Svelte props are just variables it's pretty easy to do weird things. Also it's kind of a pain to need to open up a file and read through a dozen lines of code to figure out what the props are. The most important thing is it makes it difficult to build the same tooling that other frameworks have. For example, in React you can either define your props as a TypeScript/Flow interfaces or use the `prop-types` library. This gives you an easy way to automatically validate props outside of the context of component instantiation. For example, you can do: import MyComponent, {MyComponentProps} from "./MyComponent" const props: MyComponentProps = {...} Or you can do things like composing props (using prop-types here): import {propTypes} from "./MyComponent" import {propTypes as otherPropTypes} from "./MyOtherComponent" const MyNewComponent = () => {...} MyNewComponent.propTypes = {...propTypes, ...otherPropTypes} All this is possible since props is just a single object that is baked into the React API. In my own Svelte project I've been toying with the idea of only having a single prop called `props` although I'm sure this affects Svelte's rendering performance.
  - thebosz 7y ago
    You could just use the undocumented but totally available $$props object.
mvolkmann 7y ago
I understand if you really want TypeScript support, but why do you feel the component model is hacky? I find it beautifully simple.
- ng12 7y ago
  I elaborated below. A mix of the strict one component per file rule and the definition of props as a sequence of independent variables prevents a lot of patterns I use on larger projects.
wirahx 7y ago
As somebody who doesn't want typescript support, at all, I relish the lack of typescript support! Also the component model isn't "hacky". It's logical, unopinionated and straight-forward. I don't know how much you know about Rich Harris but he's not one for producing "hacky" public APIs.
- ng12 7y ago
  > As somebody who doesn't want typescript support, at all, I relish the lack of typescript support! That's a pretty strange statement. TypeScript support does not mean you have to use TypeScript. It's purely additive by design. By hacky I mean "define some global variables and the compiler will do some checks to make sure you don't do anything untoward". You can see my other post in this thread for examples where this model falls apart.

by ng12 7y ago

vivekseth 7y ago

I haven’t done much React, but I’ve played around with svelte a bit recently and I haven’t found any severe issues with the props model. What don’t you like about it?

ng12 7y ago
Since Svelte props are just variables it's pretty easy to do weird things. Also it's kind of a pain to need to open up a file and read through a dozen lines of code to figure out what the props are. The most important thing is it makes it difficult to build the same tooling that other frameworks have. For example, in React you can either define your props as a TypeScript/Flow interfaces or use the `prop-types` library. This gives you an easy way to automatically validate props outside of the context of component instantiation. For example, you can do: import MyComponent, {MyComponentProps} from "./MyComponent" const props: MyComponentProps = {...} Or you can do things like composing props (using prop-types here): import {propTypes} from "./MyComponent" import {propTypes as otherPropTypes} from "./MyOtherComponent" const MyNewComponent = () => {...} MyNewComponent.propTypes = {...propTypes, ...otherPropTypes} All this is possible since props is just a single object that is baked into the React API. In my own Svelte project I've been toying with the idea of only having a single prop called `props` although I'm sure this affects Svelte's rendering performance.
- thebosz 7y ago
  You could just use the undocumented but totally available $$props object.

mvolkmann 7y ago

I understand if you really want TypeScript support, but why do you feel the component model is hacky? I find it beautifully simple.

ng12 7y ago
I elaborated below. A mix of the strict one component per file rule and the definition of props as a sequence of independent variables prevents a lot of patterns I use on larger projects.

wirahx 7y ago

As somebody who doesn't want typescript support, at all, I relish the lack of typescript support! Also the component model isn't "hacky". It's logical, unopinionated and straight-forward. I don't know how much you know about Rich Harris but he's not one for producing "hacky" public APIs.

ng12 7y ago
> As somebody who doesn't want typescript support, at all, I relish the lack of typescript support! That's a pretty strange statement. TypeScript support does not mean you have to use TypeScript. It's purely additive by design. By hacky I mean "define some global variables and the compiler will do some checks to make sure you don't do anything untoward". You can see my other post in this thread for examples where this model falls apart.