I'm glad to see continued experimentation in this space. I'd hate to think that React is the best we can come up with.
Solid – A declarative JavaScript library for building user interfaces
91–100 of 178 posts
Re: Solid – A declarative JavaScript library for building user interfaces
#92At this stage, web components is no more than a glorified template string + a way to fill it, it seems?
Now only name it template separate it out into its own file, and build an "engine" around it. Then we are almost back, where we came from with backend rendering, which we should be doing anyway.
I've yet to see the JS framework that takes usability seriously and outputs a noscript block (during development) for me to copy paste and get the functionality for anyone disabling JS.
As it stands many web devs only see the JS enabled side of things and then are too lazy to, or not capable of implementing the noscript part. Or they are not even aware of the white page one gets for their oh so cool React apps, once JS is deactivated. It is very unprofessional amd exclusive, I must say.
Re: Solid – A declarative JavaScript library for building user interfaces
#93The negativity in this comments section is astounding. Personally, I was originally introduced to it by someone in the Mithril.js gitter chat, and think it's a great project. I wish the Solid team the best and look forward to trying out Solid in my next toy project. The performance benchmarks and relatively clean API are truly impressive.
Thank you for your kind words. It can a difference to have the kind words of a few strangers. I'm used to these sort of responses now. And welcome it to a certain degree. Insightful comment can lead to interesting discussion. Ignorant ones gives me a platform to educate.
But it wasn't always like this. Leo Horie from Mithril was always supportive early days when it seemed I only was receiving this sort of "feedback" on reddit if any at all.
Re: Solid – A declarative JavaScript library for building user interfaces
#94Maybe 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.
Re: Solid – A declarative JavaScript library for building user interfaces
#95Is there dedicated DevTools support for Solid like there is for React, Vue, Svelte, and co.? If not, is there a convenient way to inspect state, props, and the component hierarchy?
I actually think this is extremely important. One downside of these compilation-driven frameworks is that they would, I assume, make it much more difficult to track with exactly how your code manifests at runtime, and would therefore make it harder to debug. Even setting that aside, I'm a strong believer that "frameworks" (contrasted with "libraries") have a responsibility to bring their own tooling, because existing tooling is less likely to be useful against the new concepts they introduce.
Re: Solid – A declarative JavaScript library for building user interfaces
#96https://github.com/ryansolid/dom-expressions/tree/master/pac... Looks great!
Yeah JSX has its clear advantages. But I wanted to offer runtime only solutions as well. Tagged Template Literals is still the best runtime only solution for Solid, but I've got HyperScript too. Just remember it's reactive so wrap expressions in functions. JSX compilation sort of hides this detail from you.
Re: Solid – A declarative JavaScript library for building user interfaces
#97Explain the big picture abstraction differences between this and React in two sentences? I don't care about compiler vs interpreter implementation details.
With React your Component re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Component is a basic function that executes once closing over state getters with its Hooks, which are the only thing that run over and over as needed when state changes.
Re: Solid – A declarative JavaScript library for building user interfaces
#98Maybe 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 layou…
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?
Re: Solid – A declarative JavaScript library for building user interfaces
#99Maybe 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 layou…
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.
Re: Solid – A declarative JavaScript library for building user interfaces
#100Maybe 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 layou…
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 JSO…
Well in React the rendering logic could still just be plain functions, though I guess technically those are considered "functional components".