I mean Sinuous started as a fork of the HyperScript version of Solid. You can use Solid exactly the same way. I just strongly don't recommend using Solid that way. You pay the cost not only in ergonomics, but in performance and size. Sinuous has done work to mitigate the latter but it comes at cost of the first 2.
Unfortunately Im not sure without creating a language for it that you can make reactivity cleaner. That was my goal initially to see if reactivity could be reduced to a point where it had a simple onboarding but all the depth to do what is needed. I decided templating was the awkward part. More potential work on compiled DSLs could maybe take this further but I fear it won't satisfy your goal.
When comparing Solid and Sinuous, the only real concern for me is ergonomics. When it comes to performance and size, they are both in the category of "small and fast" - they are both substantially faster and smaller than mainstream frameworks like React or Vue, so a marginal performance difference of 5-10% isn't a deciding factor for me.
Gen Hames (whom I believe you know as heyheyhello on github) is working on something called haptic, which might improve on the ergonomics of reactive state management, making it more explicit and transparent vs e.g. S.js and Sinuous. We'll see if this goes anywhere, but I'm hopeful.
Although I try out and use many of these frameworks on private/hobby projects, when it comes to "work work", my go-to choice is and remains Preact. I can explain to a junior how this works, end-to-end, in an hour - and while, in some ways, there is non-obvious complexity inherent in a framework like this that you have to deal with, such as JSX expressions returning VNodes rather than Elements, what the framework does is very easily explainable.
That simplicity, to me, in a work setting, has tremendous value. Understanding the inner workings of it is empowering - I get a sense of confidence when I see someone unlocking something like Preact or Sinuous when I explain it to them. Whereas with frameworks like Vue or Angular, I get the sense that most people don't really understand (beyond the superficial "it makes HTML") how these work, and either aren't very confident, or sometimes overconfident and disinterested in how it works.
The latter isn't necessarily a problem, if the main objective is to churn out code. But from personal experience, I find the confident developer, who works with tools they can understand, and who can pass on that knowledge, is generally happier, more motivated, and contributes to the team experience in perhaps less tangible ways than just churning out code.
Choosing software components, to me, is as much about the human experience as it is about the technical.
I'm not saying any of this to say anything about your framework, by the way - I'm just trying to explain where my personal angle on this might be coming from.
The amount of effort you've put into tutorials and documentation alone makes your project much more complete than most of the open-source efforts in this space, and worthy of real consideration. 🙂
I guess I don't get it. Or I agree with you except I see Solid as the example of what you are getting at.
I never saw Sinuous doing anything different than Solid except shaving some size on the HyperScript version. Maybe I haven't made it clear. But they have identical ergonomics if you so choose to use Solid that way (other than reactive API, but that's swappable).
But I actually find the compiled output from Solid's JSX much clearer what's going on as less is hidden inside the library. The DOM operations are out in the open and resemble the input code. Almost as if you weren't using a templating engine at all.
Solid came about from my experience maintaining and training people on a large production Knockout app over most of a decade. And a lot of the same lessons learned. Balancing abstraction with control.
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 mean Sinuous started as a fork of the HyperScript version of Solid. You can use Solid exactly the same way. I just strongly don't recommend using Solid that way. You pay the cost not only in ergonomics, but in performance and size. Sinuous has done work to mitigate the latter but it comes at cost of the first 2.
Unfortunately Im not sure without creating a language for it that you can make reactivity cleaner. That was my goal initially to see if reactivity could be reduced to a point where it had a simple onboarding but all the depth to do what is needed. I decided templating was the awkward part. More potential work on compiled DSLs could maybe take this further but I fear it won't satisfy your goal.
When comparing Solid and Sinuous, the only real concern for me is ergonomics. When it comes to performance and size, they are both in the category of "small and fast" - they are both substantially faster and smaller than mainstream frameworks like React or Vue, so a marginal performance difference of 5-10% isn't a deciding factor for me.
Gen Hames (whom I believe you know as heyheyhello on github) is working on something called haptic, which might improve on the ergonomics of reactive state management, making it more explicit and transparent vs e.g. S.js and Sinuous. We'll see if this goes anywhere, but I'm hopeful.
Although I try out and use many of these frameworks on private/hobby projects, when it comes to "work work", my go-to choice is and remains Preact. I can explain to a junior how this works, end-to-end, in an hour - and while, in some ways, there is non-obvious complexity inherent in a framework like this that you have to deal with, such as JSX expressions returning VNodes rather than Elements, what the framework does is very easily explainable.
That simplicity, to me, in a work setting, has tremendous value. Understanding the inner workings of it is empowering - I get a sense of confidence when I see someone unlocking something like Preact or Sinuous when I explain it to them. Whereas with frameworks like Vue or Angular, I get the sense that most people don't really understand (beyond the superficial "it makes HTML") how these work, and either aren't very confident, or sometimes overconfident and disinterested in how it works.
The latter isn't necessarily a problem, if the main objective is to churn out code. But from personal experience, I find the confident developer, who works with tools they can understand, and who can pass on that knowledge, is generally happier, more motivated, and contributes to the team experience in perhaps less tangible ways than just churning out code.
Choosing software components, to me, is as much about the human experience as it is about the technical.
I'm not saying any of this to say anything about your framework, by the way - I'm just trying to explain where my personal angle on this might be coming from.
The amount of effort you've put into tutorials and documentation alone makes your project much more complete than most of the open-source efforts in this space, and worthy of real consideration. 🙂
I guess I don't get it. Or I agree with you except I see Solid as the example of what you are getting at.
I never saw Sinuous doing anything different than Solid except shaving some size on the HyperScript version. Maybe I haven't made it clear. But they have identical ergonomics if you so choose to use Solid that way (other than reactive API, but that's swappable).
But I actually find the compiled output from Solid's JSX much clearer what's going on as less is hidden inside the library. The DOM operations are out in the open and resemble the input code. Almost as if you weren't using a templating engine at all.
Solid came about from my experience maintaining and training people on a large production Knockout app over most of a decade. And a lot of the same lessons learned. Balancing abstraction with control.