Live data from Hacker News

Solidjs: Simple and performant reactivity for building user interfaces

solidjs.com

131–140 of 190 posts

Re: Solidjs: Simple and performant reactivity for building user interfaces

#131
post #3

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?

[flagged]

Re: Solidjs: Simple and performant reactivity for building user interfaces

#132
post #126

Earlier 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/

Thank you. I remember I had a look at that. Made a quick look now at PrimeVue treetable [0], to compare it to MUI datagrid [1].

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).

___

0. https://primevue.org/treetable/

1. https://mui.com/x/react-data-grid/features/

Re: Solidjs: Simple and performant reactivity for building user interfaces

#134

Earlier 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.

Good point. I don't know how much of the gap remains if one can settle for Preactjs, but Reactjs is not the fastest.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#135

Earlier 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.

Good to hear, thanks for sharing.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#136
The frameworks never care to show about what the debugging experience is like. When my code fails in an unusual way (or usual) way, am I going to have to crawl up the ass of some framework? Will I be knee deep in some crazy stack race that was run from an event loop, that hides my original event or action and forces me to retreat back to the stone ages of console.log statements? Do sourcemaps even work? Hell, have you even tried to debug your own thing? What's that like?

Re: Solidjs: Simple and performant reactivity for building user interfaces

#137
post #83
post #69

Earlier 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…

I agree that JSX is a mistake, but I disagree with the "separation of concerns" part. The "separation" is useful when we know that separate people are going to be editing and changing the presentation versus the UI code. A bit like the .obc vs .h vs .nib files of older MacOS versions - you can carefully edit the .nib, and with any luck you don't want to touch the "actual" code.

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

#138
post #61

Has 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…

> Vue uses single-file components, SolidJS uses JSX.

You can use Vue and JSX, it's mentioned on the official site:

https://vuejs.org/guide/extras/render-function

Re: Solidjs: Simple and performant reactivity for building user interfaces

#139
post #110

Earlier 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.

https://www.shadcn-svelte.com/

https://www.skeleton.dev/docs/get-started/introduction

https://flowbite-svelte.com/

https://www.melt-ui.com/

Re: Solidjs: Simple and performant reactivity for building user interfaces

#140
post #112
post #101

Earlier 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…

Well, you can be a purist, or you can be practical. I write code, users run it, I get paid... While you are fixing the "modern web technologies". And I give you this, things are getting much better and I hope one day we'll run JSX natively in the browser without a build step ;)

And no, knockout.js is not better than React :)

Post reply on HN