On: Solid – A declarative JavaScript library for build...

[_bxg1]

Maybe I just need to spend more time studying the material, but I struggle to see how these precompiled frameworks can handle any arbitrary state change one might write into their JS rendering logic.

For example: suppose I want to take an arbitrary JSON structure, walk the entire JSON tree, and render it on the page as a tree of nested elements - i.e. a new subtree of divs for each array or object. None of that layout is known ahead of time, and it can take any shape - be any depth, breadth, etc. Intuitively it seems like very little can be known ahead of time for compilation purposes. Can Solid handle this case? Genuinely curious.

[ryansolid → _bxg1]

At that point you remove the benefit of the compiler but that is fine. You are essentially writing a builder script like VDOM HyperScript. But it isn't like there isn't a runtime portion, it just that it can be smaller due to treeshaking and that the change mechanism is generic (used for everything). I imagine this just falls into the classic Reactive vs VDOM scenario, where VDOM is more performant on creation and reactive is more performant on update. The compiler is just something a reactive library can use to its benefit given it does most of its work at creation.

So if this is your primary use case where there aren't really pre-existing templates, a fast VDOM is probably slightly better if you aren't doing much in the way of updating. But hard to say. There is a runtime HyperScript version of Solid that is still blazing fast, but it is probably slightly slower overall than Inferno since it can't leverage the pre-compilation of JSX or JIT compilation the Tagged Template Literals.

[_bxg1 → ryansolid]

That makes sense. Thanks! I do still think this new wave is very exciting and I think it will dramatically improve a lot of cases where people have been (IMO) inappropriately using React thus far. Particularly when it comes to the mess that is hybrid server/client reactive rendering.

[have_faith → _bxg1]

It's my understanding that regardless of the complexity of your custom JSON data at some point while parsing the tree you have a line that says "if obj is of this type, then render this component for this node", all Svelte/Solid etc need to know is that this is the line where a Component is being assigned to a variable that is going to be rendered in the template.

Or are you saying you want a layout rendered from JSON without first defining the possible components as Svelte/Solid/React components etc? As I think that defining components explicitly is a central part of all of the front-end frameworks, compiler or otherwise?

[amelius → have_faith]

Consider the following pseudo-code:

    list2 = bubble_sort(list1)
    render(list2)

Now suppose the user deletes one item in list1.

The question is now:

Will the update trigger a new bubble sort?

Will the update do something smarter, like just delete the DOM element?

[have_faith → amelius]

There's usually no render function to call in these types of frameworks as far as I understand (my experience being a little Svelte).

I imagine in your scenario the psuedo code to achieve what you want would be written.

  list2 = bubble_sort(list1)
  removeItem = () => delete list2[random index]
  ...
  <for each list2 render div>

The compiler will see a change to the list2 variable anywhere that removeItem is called and annotate the code to make the appropriate changes to the dom in the function call and the bubble_sort line will never be re-run unless it was explicitly added to the removeItem function.

[ryansolid → have_faith]

Correct. The idea is that the derived state only updates when the underlying state updates. And the mapping to the DOM is just derived from that derived state. So list updates.. triggers bubble sort, triggers DOM reconciliation. The difference with Svelte is it sees it and the compiler writes the reactive code in the background. In Solid you just write the reactive code yourself.. ie.. `setState` etc. But it more or less works similarly.

It's like Svelte without abstracting the update mechanism. Which makes it a little more to get into at first but very similar to a library like React. The difference from React is that Solid knows exactly what you are updating so it doesn't bother with the other stuff.

[amelius → have_faith]

Note that the item is deleted from list1. The framework should (I suppose) track that list2 depends on list1 through bubble_sort(). Are the dependencies implicit? Or should they be declared explicitly?

[ryansolid → amelius]

Generally implicitly either through proxy or get method read. Solid provides an explicit API as well.

[_bxg1 → have_faith]

Well in React the rendering logic could still just be plain functions, though I guess technically those are considered "functional components".