5 ms·

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templat

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's templating language with {#if} and {#each}. Who cares? What is so wrong, exactly, with "reinventing a concept that's already in the language"? It does not make code any harder to understand or to write, and it does not harm performance (in this case, quite the opposite). I would much rather have a reactivity model where I plug in completely standard concepts and patterns (a for loop) than one where I have to deal with a bunch of framework-specific, complicated ones (hooks). That Solid's reactivity primitives are familiar is an advantage, not a disadvantage.

nicoburns 5y ago
I've not used Svelte, but when I've used such DSLs the problem tends to be that they're not very flexible, and as soon as you step outside of the provided helpers you're stuck and you just can't do the thing.
- pier25 5y ago
  It's true, but the counterpoint is that DSLs make your life much easier in 90% of the cases (if not more). Personally I've never found a problem I wasn't able to solve in Svelte.
- shrew 5y ago
  Do you have an example you've run into where a DSL such as Svelte's or Vue's has actually stopped you from doing something? Would be genuinely interested to see it as I've never run into such a situation myself.
sbergot 5y ago
Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse error messages, more surprising issues, etc. You need to understand the scoping mecanisms and if things go wrong hope there is a debug tool available. And in the end those templating languages do not prevent you from mixing UI responsibilities from the rest of your code. If you want a reactive model you can have one. I personally prefer explicit messages like calling setState.
- tjchear 5y ago
  Haven't used solidjs before, but I paid the doc section a quick visit and saw that it's basically <For each={foobar}> where foobar can be whatever javascript code you want. So you can certainly do filter/sort/project on your data before rendering.
  - Aeolun 5y ago
    You’d probably not want to project inside that loop though, but before it, in a reactive effect.
- shrew 5y ago
  > Because you sometimes want to filter, sort or project your data. The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases. By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should happen at the point of data change and then it shouldn't happen again until the data changes again. The simplistic templating languages in Vue/Svelte/Alpine/whatever-comes-next force you to pull your data manipulation back to somewhere more appropriate, with Vue even throwing a warning if you try to filter within v-for construct. Because React is JS, people are let loose to do wildly inefficient operations and do them over and over and over whenever _anything_ in that component changes.
  - code_runner 5y ago
    I love vue’s concept of computeds. It makes me think back to knockoutjs when things felt like they “just worked” as long as you knew where the ES5 footguns were. It’s nice to have a concept “ground truth” in data and props and then computeds that sort of tie it all together.
    - shrew 5y ago
      My feelings exactly, it makes for a satisfying separation of concerns, and if you understand what's going on under the hood it makes for cleaner templates and more obvious component code.
madeofpalk 5y ago
A react feature that I appreciate is that it is "just javascript". It's easier to learn how to loop or have conditionals in React because it uses native JS features. It makes it easier to understand, for me. Having templating DSLs in other frameworks isn't a deal breaker, but it's a pro of React that I appreciate.
- recursive 5y ago
  But I mean, it's not really. A hook invocation looks exactly like a javascript function invocation. Except it's subject to hook rules. Those don't come from javascript. Those are language rules that come from react. And even worse, the syntax for invoking a hook is exactly the same as the syntax for calling a function.
zero_shift 5y ago
> It does not make code any harder to understand or to write, Well, what can you tell me about TypeScript type inference for this custom DSL?
- kjleitz 5y ago
  Have you used Vue 3? There is fantastic TypeScript support in templates, including comprehensive intellisense for the templates in VS Code with the Volar extension. Surprisingly, _refreshingly,_ good.
- toqy 5y ago
  I wouldn't call <For> in Solid a custom DSL anymore than any given React component. And Solid looks to have good TS support. https://www.solidjs.com/docs/latest/api#%3Cfor%3E https://www.solidjs.com/docs/latest/api#%3Cfor%3E
tshaddox 5y ago
> What is so wrong, exactly, with "reinventing a concept that's already in the language"? Nothing, inherently. Just like there's nothing inherently wrong with having extremely clear and simple rules for how to use hooks, and lint rules to identify when you're not following those rules. Nothing inherently wrong with either, some people just have strong distaste for one or the other.

nicoburns 5y ago

I've not used Svelte, but when I've used such DSLs the problem tends to be that they're not very flexible, and as soon as you step outside of the provided helpers you're stuck and you just can't do the thing.

pier25 5y ago
It's true, but the counterpoint is that DSLs make your life much easier in 90% of the cases (if not more). Personally I've never found a problem I wasn't able to solve in Svelte.
shrew 5y ago
Do you have an example you've run into where a DSL such as Svelte's or Vue's has actually stopped you from doing something? Would be genuinely interested to see it as I've never run into such a situation myself.

sbergot 5y ago

Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse error messages, more surprising issues, etc. You need to understand the scoping mecanisms and if things go wrong hope there is a debug tool available. And in the end those templating languages do not prevent you from mixing UI responsibilities from the rest of your code. If you want a reactive model you can have one. I personally prefer explicit messages like calling setState.

tjchear 5y ago
Haven't used solidjs before, but I paid the doc section a quick visit and saw that it's basically <For each={foobar}> where foobar can be whatever javascript code you want. So you can certainly do filter/sort/project on your data before rendering.
- Aeolun 5y ago
  You’d probably not want to project inside that loop though, but before it, in a reactive effect.
shrew 5y ago
> Because you sometimes want to filter, sort or project your data. The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases. By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should happen at the point of data change and then it shouldn't happen again until the data changes again. The simplistic templating languages in Vue/Svelte/Alpine/whatever-comes-next force you to pull your data manipulation back to somewhere more appropriate, with Vue even throwing a warning if you try to filter within v-for construct. Because React is JS, people are let loose to do wildly inefficient operations and do them over and over and over whenever _anything_ in that component changes.
- code_runner 5y ago
  I love vue’s concept of computeds. It makes me think back to knockoutjs when things felt like they “just worked” as long as you knew where the ES5 footguns were. It’s nice to have a concept “ground truth” in data and props and then computeds that sort of tie it all together.
  - shrew 5y ago
    My feelings exactly, it makes for a satisfying separation of concerns, and if you understand what's going on under the hood it makes for cleaner templates and more obvious component code.

madeofpalk 5y ago

A react feature that I appreciate is that it is "just javascript". It's easier to learn how to loop or have conditionals in React because it uses native JS features. It makes it easier to understand, for me. Having templating DSLs in other frameworks isn't a deal breaker, but it's a pro of React that I appreciate.

recursive 5y ago
But I mean, it's not really. A hook invocation looks exactly like a javascript function invocation. Except it's subject to hook rules. Those don't come from javascript. Those are language rules that come from react. And even worse, the syntax for invoking a hook is exactly the same as the syntax for calling a function.

zero_shift 5y ago

> It does not make code any harder to understand or to write, Well, what can you tell me about TypeScript type inference for this custom DSL?

kjleitz 5y ago
Have you used Vue 3? There is fantastic TypeScript support in templates, including comprehensive intellisense for the templates in VS Code with the Volar extension. Surprisingly, _refreshingly,_ good.
toqy 5y ago
I wouldn't call <For> in Solid a custom DSL anymore than any given React component. And Solid looks to have good TS support. https://www.solidjs.com/docs/latest/api#%3Cfor%3E https://www.solidjs.com/docs/latest/api#%3Cfor%3E

tshaddox 5y ago

> What is so wrong, exactly, with "reinventing a concept that's already in the language"? Nothing, inherently. Just like there's nothing inherently wrong with having extremely clear and simple rules for how to use hooks, and lint rules to identify when you're not following those rules. Nothing inherently wrong with either, some people just have strong distaste for one or the other.