[lpghatguy]

New JS frameworks always make for compelling hello world examples.

Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty!

As an example of this point, check out the "Simple Todos" example for Solid.js[1].

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've been writing React and React-alike code for a long time. I think that fine-grained updates avoiding reconciliation are a good idea, especially for performance. At one point, I built a React-like library for Roblox and Lua whose most novel feature ended up being "Bindings"[2], which look sorta like Solid.js state containers. They create little hot-path data dependencies, but the bulk of your components still use normal React-like rendering.

  [1]: https://www.solidjs.com/examples/todos
  [2]: https://roblox.github.io/roact/advanced/bindings-and-refs/

[alskdjflaskjdhf]

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

[sbergot]

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.

[madeofpalk]

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.

[nicoburns]

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.

[jbreckmckye]

> 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?

[tshaddox]

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

[chrismorgan]

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

Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of the matter is that if you care about performance at all, the simple ways are just insufficient, and the native language constructs were designed for procedural programming, not reactive interface rendering, which requires fundamentally incompatible semantics. It’s not even fair to claim that React uses regular JavaScript idioms—VDOM, hooks, the entire shebang is all about eschewing regular JavaScript idioms because they don’t scale. (OK, so there’s also the matter of transient state like scroll positions, element focus, and form field values; it’s not fair to say that React does all these things purely for performance’s sake, as the naive immediate mode approach would also break such functionality.)

[mwcampbell]

> virtualised rather than fully-materialised lists

I want to push back somewhat on this practice. Our computers are fast enough now, and the browser implementations optimized enough, that they should be able to handle thousands of materialized list items without breaking a sweat. Sometimes you really need virtualization, e.g. if the underlying data source has millions of records. But if the data can be fully materialized, then the implementation is simpler, and the user can take advantage of things like find in page. Virtualization is a convenient way to avoid the inefficiency of unoptimized VDOM-based rendering (e.g. with React, and yes, I know there are other optimizations available in React), but fine-grained updating (as in Solid) is even better.

[suction]

What JS framework would you choose to work with big datasets like, e.g. a data grid with half a million rows that should have a "filter as you type" functionality?

[tambourine_man]

>…much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language.

I'm right there with you, but when React invents a whole markup language inside of JavaScript, it's not in much of a standing to make purity criticisms.

[BigJono]

Well you've obviously completely missed the point of JSX then. The "whole markup language" that they invented is literally a line for line transform. Optimisation aside, there's no reason why line 58 of a file with JSX in it won't be line 58 of the transpiled JS file, and read exactly the same. All JSX is is a custom function call syntax.

It's about as pure as you can get while having any sort of html-ish 'templating' whatsoever.

So, I'd say it's exactly in the right place to be making purity criticisms. They've taken the only approach that preserves the integrity of the code and doesn't involve build time magic.

[masklinn]

That is an utterly bizarre rejoinder. JSX has always been (and afaik still is) optional and extremely thin syntactic sugar. It’s little more than a convenience macro (so that views can look a little more like the markup equivalent).

It has no intrinsic semantics, and maps pretty much directly to actual javascript (which you can write directly or use an alternative helper for — hyperscript being a common one).

[toastercat]

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

This argument is silly because it inevitably becomes a pissing contest of who can be most like vanilla JavaScript. In that case, why use JSX? Just write hyperscript calls instead. Why use React Router/React Context helpers? Just wrap your components using vanilla function providers instead. Why use React Hooks, which inevitably look like magic to a JavaScript veteran because the library inherently hides away some global state? I hope you can see what I'm getting at here.

[iyc_]

> 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 had/have your bias, but from playing with it I found a couple things:

1) Like React, you can swap out the template feature for a function call (or subcomponent). e.g. instead of

  return (
    <button...>
    ... 
    </button>
    <For each={state.todos}>
    ... 
  );

you can use functions and loops:

  function displayTODOs<T>(todos: T[]): any {
    let arr: any[] = [];
    for(let [i, todo] of todos.entries()) {
      const { done, title } = todo;
      let elem = (/\* JSX \*/);
      arr.push(elem);

    }
    return arr;
  }
  ... 
  return (
    <button ...>
    </button>
    {displayTODOs(state.todos)}   
  );

2) Even with my bias, I must admit I found the `<For...` syntax to be surprisingly easy to read and fast to eye-parse; much more so than other 'templating' (using your term) languages/macros/syntax I've used over the years.

[jbreckmckye]

Likewise I simply don't empathise with the author's complaints. Hooks make sense if you think in closures. Hooks are isolated so you can think about them in isolation.

What I like about the React monoculture is that it's one less thing I have to care about. I can focus on the other aspects of my programs, beyond turning JSON into HTML.

I haven't used SolidJS so I'm not going to put it on blast. However, hearing people compare its reactivity model to Knockout JS gives me the heebie-jeebies, because Knockout projects were horrific to reason about (and test) beyond a certain scale.

[pier25]

> we get a construct like <For> that reinvents a concept that's already in the language

Isn't this optional? Can't Solid use regular JSX loops?

[latchkey]

https://www.solidjs.com/docs/latest/api#control-flow

For reactive control flow to be performant, we have to control how elements are created. For example, with lists, a simple map is inefficient as it always maps the entire array.

This means helper functions.

[AgentME]

JSX doesn't have loops. When using React, you use regular not-React-specific Javascript tools to do loops and create lists of React elements.

[leonardopainter]

>The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty!

Actually, that is only half the reason. You can do whatever you want in my library (github.com/thebinarysearchtree/artwork) and it doesn't have any kind of virtual DOM or whatever Lit does, because you just create elements with JavaScript. The second reason, that everyone just assumes is the default, is that React has to use HTML-like templates and not just JavaScript.

[Kaze404]

JSX is a purely optional part of React. You can use it with just Javascript and no bundlers just fine.