Compilation and runtime should not coexist, which will make the framework more messy and mediocre.
I'm not sure you ever had a look at the code resulting from Solid.js – it's anything but messy, rather what you'd write yourself if you would manipulate DOM nodes for a living.
Quite on the contrary, Solid's way of not re-running components all the time reduce the mess they make greatly
But there are not two mental models here, just one: purely reactive DOM handling. Your mental requirement to split that up probably stems from thinking in models like react.
If anything, Solid's use of JSX is much more straightforward than those of vDOM libraries: you write <div/> and get a HTMLDivElement instead of some abstraction. It's basically WYSIWYG, but for the DOM.
I'm just giving an example. Solid needs to compile and runtime reactivity at the same time. Users have to think from the perspective of "what is the generated code like".
But you have to basically do the same with any framework using JSX or any other DSL, regardless if it is fully compiled or only partially. The main difference is that instead of some obscure pragma call, you get understandable DOM operations that are even easily debugged (try that with react without using the react dev tools, just to give one example).
What I dislike about Solid is the fact that it pretends to be JavaScript - but changes the semantics. You look at that code and go, "hey, how could this possibly work?" - and you'd be right, it can't work, and I am just not a fan of changing the meaning of existing language constructs to get what you want.
Svelte has lost my interest as well, since that's the avenue they started to pursue as well - overloading the meaning of ambiguous goto labels... Not a fan.
I think differently about JSX in that regard, because it's a new language construct - it doesn't meddle with existing language semantics.
I wish we would see more activity in the largely unexplored space of true reactivity and precise updates without a compile step. Sinuous is underrated in that space:
This avenue of UI libraries isn't getting enough love, by far. Working within the language constraints and achieving precise DOM updates to me is the next frontier. 😄
How is Solid changing the semantics? From a developer perspective, you get JSX, which compiles to predictable DOM manipulations, and you get a fine-grained reactive system that just works without any transformations whatsoever. You can use template literals or hyper-dom-expressions as well with Solid if you want to forego the JSX compilation step and still get true reactivity and precise updates, like you said about sinuous.
In any case, the conscious choice for JSX made in Solid.js has some reasons including existing tooling and performance.
It seems that sinuous escapes compilation by translating JSX into htm, and this technique is also applicable to fre.
Solidjs does change some semantics. For example, it does not rely on function execution to generate a new view, which violates the immediate mode, which is inconsistent with semantics.
However, so far, I have not found a compilation route that fully conforms to semantics.
It seems that sinuous escapes compilation by translating JSX into htm
How does "translating" differs from "compilation"? Also, from what I can see, sinuous is using the exact same templating mechanisms that Solid.js does, which is tagged template literals, hyperscript or transpiled JSX.
For example, it does not rely on function execution to generate a new view, ...
Sure it does, either by setting a reactive signal or writing into a setter function of a mutable store. It really seems to me that you haven't really looked into solid.js recently, but have a lot of false preconceptions about it.
I am very clear about solidjs. Its fine-grained update is completely inconsistent with the semantics of JSX's immediate mode. The semantics of hooks is to obtain new values every time it is rerender, and solidjs is completely distorted.
Think carefully and don't rush to defend.
Yes, hooks do that because a reconciler requires it, but it's not a law that you must obtain new values all the time even if nothing changed and certainly a deviation from reactive patterns – which is why doing things different makes for great performance and even more control in your reactive code. There's a reason solid's primitives are called differently than react's hooks: to avoid confusion.
The issue I see here is that you have some preconceived notions about how things should work that are clashing with the improvements made by solid and therefore you don't like it. That's fine, everyone is entitled to an opinion. But that's all it is.
I clearly know the good and bad of each framework. Neither solidjs nor svelte can guarantee the absolute unity of semantics. This is a fact, not my preconception.
In addition, even so, solidjs has made remarkable improvements in many aspects, which I don't deny.
Good and bad are merely subjective value judgements. And as I already remarked, you see a division where there is none because you are used to a different concept. Neither your judgement nor your views are a fact.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure you ever had a look at the code resulting from Solid.js – it's anything but messy, rather what you'd write yourself if you would manipulate DOM nodes for a living.
Quite on the contrary, Solid's way of not re-running components all the time reduce the mess they make greatly
This has nothing to do with the generated code, but within the framework. If there are two sets of mental models, you need to pursue one of them
But there are not two mental models here, just one: purely reactive DOM handling. Your mental requirement to split that up probably stems from thinking in models like react.
If anything, Solid's use of JSX is much more straightforward than those of vDOM libraries: you write
<div/>and get a HTMLDivElement instead of some abstraction. It's basically WYSIWYG, but for the DOM.I'm just giving an example. Solid needs to compile and runtime reactivity at the same time. Users have to think from the perspective of "what is the generated code like".
But you have to basically do the same with any framework using JSX or any other DSL, regardless if it is fully compiled or only partially. The main difference is that instead of some obscure pragma call, you get understandable DOM operations that are even easily debugged (try that with react without using the react dev tools, just to give one example).
What I dislike about Solid is the fact that it pretends to be JavaScript - but changes the semantics. You look at that code and go, "hey, how could this possibly work?" - and you'd be right, it can't work, and I am just not a fan of changing the meaning of existing language constructs to get what you want.
Svelte has lost my interest as well, since that's the avenue they started to pursue as well - overloading the meaning of ambiguous goto labels... Not a fan.
I think differently about JSX in that regard, because it's a new language construct - it doesn't meddle with existing language semantics.
I wish we would see more activity in the largely unexplored space of true reactivity and precise updates without a compile step. Sinuous is underrated in that space:
github.com/luwes/sinuous
I am also closely following a project called Haptic, which derives from Sinuous and attempts to remove the magic from reactive state management:
github.com/heyheyhello/haptic
This avenue of UI libraries isn't getting enough love, by far. Working within the language constraints and achieving precise DOM updates to me is the next frontier. 😄
How is Solid changing the semantics? From a developer perspective, you get JSX, which compiles to predictable DOM manipulations, and you get a fine-grained reactive system that just works without any transformations whatsoever. You can use template literals or hyper-dom-expressions as well with Solid if you want to forego the JSX compilation step and still get true reactivity and precise updates, like you said about sinuous.
In any case, the conscious choice for JSX made in Solid.js has some reasons including existing tooling and performance.
It seems that sinuous escapes compilation by translating JSX into
htm, and this technique is also applicable to fre.Solidjs does change some semantics. For example, it does not rely on function execution to generate a new view, which violates the immediate mode, which is inconsistent with semantics.
However, so far, I have not found a compilation route that fully conforms to semantics.
How does "translating" differs from "compilation"? Also, from what I can see, sinuous is using the exact same templating mechanisms that Solid.js does, which is tagged template literals, hyperscript or transpiled JSX.
Sure it does, either by setting a reactive signal or writing into a setter function of a mutable store. It really seems to me that you haven't really looked into solid.js recently, but have a lot of false preconceptions about it.
I am very clear about solidjs. Its fine-grained update is completely inconsistent with the semantics of JSX's immediate mode. The semantics of hooks is to obtain new values every time it is rerender, and solidjs is completely distorted.
Think carefully and don't rush to defend.
I think you should have a look at Ryan's reply.
Yes, hooks do that because a reconciler requires it, but it's not a law that you must obtain new values all the time even if nothing changed and certainly a deviation from reactive patterns – which is why doing things different makes for great performance and even more control in your reactive code. There's a reason solid's primitives are called differently than react's hooks: to avoid confusion.
The issue I see here is that you have some preconceived notions about how things should work that are clashing with the improvements made by solid and therefore you don't like it. That's fine, everyone is entitled to an opinion. But that's all it is.
I clearly know the good and bad of each framework. Neither solidjs nor svelte can guarantee the absolute unity of semantics. This is a fact, not my preconception.
In addition, even so, solidjs has made remarkable improvements in many aspects, which I don't deny.
Good and bad are merely subjective value judgements. And as I already remarked, you see a division where there is none because you are used to a different concept. Neither your judgement nor your views are a fact.