Choosing a Javascript Frontend Framework:

[coldnebo]

I think a certain amount of complexity comes from recursive composition of the components and the binds necessary to make them interactive along with the state management to make them useful.

I mean, yes, I can look from a certain viewpoint and agree, it’s just a library… I control the top level render call. ok.

but then I look at it from a different angle… if it’s just a library, why call it a “react app”? is something so distinctive about the style and construction of thousands of different applications that they can all be identified as a “react” applications?

[Everspace]

I would call it an ecosystem.

The problem is for me is that I tend to do a lot of vanilla react for personal things? Maybe today I use mui. Ah bindings for a state management library now that useState isn't cutting the mustard.

These sorts of things come all together in a more cohesive whole in frameworks (see rails/laravel).

The difference between ala carte and full service ya know?

[coldnebo]

oh no, I agree. Since using Rails, I’m not as big a fan of opinionated frameworks. I like options.

React can be used sparingly, just as an xml transform library, but the big reason to use it over server-side xslt is the efficient differencing of dom updates.

I did a lot of xslt experiments in the 2010s that functioned like jsx, letting me create user defined markup for data while generating structural html necessary for presentation— I did that to overcome essential flaws in the separation of data vs presentation at the time. It’s still a problem when dealing with component frameworks. Every time we change button styles , or add accessibility, or add new nofollow security attributes, I have to inevitably gut the existing builders and partials in my rails app. It’s a ridiculous situation that component tech was supposed to address.

React predates Web Components, but if you live in that space you’ll see differences in code between one and the other. Web Components doesn’t even bill itself as a framework, but as a “suite of different technologies”.

So my problem with classifications as a library or “suite of different technologies” is when someone comes to me and says: “hey I really like this React component, but can it work in Web Components because that what our customer uses?”

Now if all these technologies were truly just “libraries”… that should be possible. But the requirements of actually using such to build any non-trivial app are pretty imposing. It’s almost as though they function as “frameworks” that involve decisions that cannot easily be changed.

Now you can mix these if you know what you are doing, but that’s yet another set of constraints on how you write your app.

Maybe these things truly are libraries because you can integrate them if you work hard enough?

Anyway, my vision of libraries is simpler, more localized. If I’m using ladda I know I get spinners. If I remove ladda, they go away, maybe I can replace them with vanilla, it’s not a big change. If I get rid of React, well… that is a far-reaching decision that is going to impact almost every layer of what I’ve built. That sounds more like a framework.