DEV Community

loading...

Discussion on: Components are Pure Overhead

Collapse
kspeakman profile image
Kasey Speakman • Edited

Our toolchain (F#/Elmish/Fable) had another option for rendering. But with a preponderance of React developers I think it didn't make sense for the maintainer to keep it. The important point here is that our developers don't have to know or care what the renderer is. We had to use keyed in some cases to make React do the right thing, but otherwise it just looks like HTML (as F# functions) to us. Our organization/abstraction strategy is at the language level rather than the UI library level. And it is possible to switch renderers if an alternative presents itself and the need arises.

We could use React bells and whistles (some projects do), but we choose not to. We don't want to get pulled into over-abstracting.

Thread Thread
ryansolid profile image
Ryan Carniato Author

In a sense, you've bought in on a different framework. Instead of betting on the renderer, you are betting on your business logic which is a good bet to make. What is interesting to me is that frameworks are continuing to develop new techniques like Svelte's animation or React's Concurrent mode or Server Components which are unique to them.

Obviously, we can opt not to use these features but to me, this is very much a different type of framework choice. Keyed is one thing, but there is a reason I'm convinced this isn't easily universalizable as much as I support research in the area even in things like Marko (idea is that HTML with some extensions as language could map to any framework).

I'm very interested in what the renderer is doing since only through its primitives do we have the ability to have the knowledge to fully leverage things like compiler analysis. There are benefits to separation but that always comes with a tradeoff in terms of optimization.

Thread Thread
kspeakman profile image
Kasey Speakman

I assume we might have to make some React-specific tweaks if performance becomes an issue. But we're still waiting for that day. I suspect it has to do with following FP, which should only create pure components.

Thread Thread
kspeakman profile image
Kasey Speakman • Edited

I wrote about it here. Edit: Well, just the organization part. I suppose the tech is glossed over a bit.

Thread Thread
ryansolid profile image
Ryan Carniato Author

I think client-side is plenty optimal in general. We are getting the limit of what we can do here. Honestly I think this is the last overhead to remove in the browser rendering part of the equation. And we are only getting to those last dozen percentage points or so. I like solutions like what you are proposing because if you ever do hit the need your decision will be more empirical. You will go with the smallest/fastest choice as you aren't that dependent on the renderer's features.

But as an author here I'm always going to be looking to do better. The real push here I imagine will be coming from Server Side rendering and isomorphic solutions. I didn't really touch on this but that same ability to analyze state can improve bundling. Tooling is the next frontier of JS frameworks. Fatigue is ending, now it's time to battle complexity.

Forem Open with the Forem app