I've been interested on dipping my toes in Solid for a while, but I've heard there's a 2.0 coming soon and I don't want to bother learning Solid in detail if there's going to be a lot of breaking changes soon. Does anyone know the status of 2.0?
Solidjs: Simple and performant reactivity for building user interfaces
131–140 of 190 posts
Re: Solidjs: Simple and performant reactivity for building user interfaces
#132Earlier quoted context omitted.
I don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.
We are using PrimeVue at my work and are very happy with it. I'm not super familiar with Mui so can't directly compare. https://primevue.org/
There seems to be a wide gap in feature scope and depth. For example, column grouping in [0] seems to be not available (it is in PrimeVue datagrid, but that misses support for data hierarchy).
___
Re: Solidjs: Simple and performant reactivity for building user interfaces
#133Re: Solidjs: Simple and performant reactivity for building user interfaces
#134Earlier quoted context omitted.
Thanks. If that is the common approach in Svelte to third party components, than I learned something. > You just make whatever it is you want in HTML and make it reactive > ... instead of spending time mastering the API of some component, I am not sure if that would be a win. The API of the component is actually a selling point, because the component gets used in many different ways across the application. Possibly u…
I think the best case for using Svelte or Solid over React is when performance is critical, e.g. in big and/or fast data contexts.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#135Earlier quoted context omitted.
When I researched Tanstack, it looked flexible. But a recurring theme with users was that some options are not compatible with each other, while the documentation is silent about what functionalities are compatible with each other. Did you experience that? For me such a thing is a red flag: incomplete documentation, feature gaps and unpredictability. Also, how difficult is it too fill the feature gap. Even if one suc…
No, but my use of it was fairly simple stuff, so I probably just didn't run into that. I do use react query and their router regularly and haven't had any major issues with it.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#136Re: Solidjs: Simple and performant reactivity for building user interfaces
#137Earlier quoted context omitted.
Funny. To me JSX is a much superior language compared to HTML templating. And I would say it's provably so. You can do JSX-in-JS-in-JSX recursively in a way that is "natural" and "safe" and "maintainable". And with TypeScript you get great IDE support, ability to refactor and whatnot. No need to trust my word, just look at the huge amount of code in JSX that the world is maintaining at the moment. I would say the onl…
JSX is a huge conceptual mistake, IMO. Sure, it gives you expressiveness, flexibility, and templating for "free", but this comes at the expense of the separation of concerns principle, which is a bad tradeoff. HTML is concerned with the content and structure of the page. JS is concerned with behaviour and interactivity. Using JS, or any programming language for that matter, to control how HTML is rendered introduces…
But for most modern SPA UIs, this is actually less useful - because what you output into the DOM and the behavior are so intertwined. With setups like HTMX, for example, easily half of your HTML attributes can be interactivity-related. Yes, someone may be editing those separately - but they hardly will be able to edit them without any care for preserving the attributes, preserving the correct nesting the template needs to support the UI code, and on and on.
Hosting a "component" together with everything it needs to render inside one file is actually very handy, 90% of the time.
Where JSX is an issue is in the language department. The single reason we were forced onto the Webpack bandwagon - with all the years of endless tweaking, debugging and suffering that followed - was JSX, as you would have to jump through hoops to use React without the foreign syntax. A default React component was not valid JS, point.
So - expressing the DOM imperatively inside the component is fine. Shoehorning a syntax (which also requires workarounds like `className`) into another syntax and then requiring a preprocessor just for your code to work is... meh.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#138Has anyone used both Solid and Vue? How do the two compare?
Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime. Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new file…
You can use Vue and JSX, it's mentioned on the official site:
Re: Solidjs: Simple and performant reactivity for building user interfaces
#139Earlier quoted context omitted.
Most of the modern front end frameworks can handle those use cases. Solid, Vue, Svelte all have capable SPA frameworks and component libraries
I don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#140Earlier quoted context omitted.
Well, I guess personal preference is also a thing. But I would say that the "market" doesn't agree with your thoughts on the matter (and I don't also, but my opinion matters way less). You can write MVVM as an unmaintainable mess also. From my experience as a freelancer, I have had much harder time fixing badly written Angular projects (all versions) than such written in React. It seems that people as a whole tend to…
> I would say that the "market" doesn't agree with your thoughts on the matter I'm well aware. :) But it wouldn't be the first time that large-scale groupthink has led an industry or society in the wrong direction. The problem is that there is now an entire generation or two of frontend developers who are "senior" based on years of experience who have only known web development post-React. They're not really aware of…
And no, knockout.js is not better than React :)