DEV Community


Discussion on: Why I'm not a fan of Single File Components

ryansolid profile image
Ryan Carniato Author

SolidJS is a different UI Framework that while it looks similar to React uses granular reactivity instead of VDOM to handle DOM updates. It's a competitor the libraries mentioned rather than something like a state management tool. It's more similar to taking Vue's composition API and building a full render library from it, (although it predates it by several years). React introducing tuple returns with hooks solved a longstanding API issue I was having so I adopted it. But Solid being based completely on those primitives independent of the Component system has unlimited composability, which I was trying to highlight at the end of the document.

CSS is sort of neither here or there IMHO. The bundler can handle that with CSS Modules or PostCSS, or CSS in JS solutions work as well. You can apply most CSS solutions outside of the framework or not and leave them global regardless of the your choice of framework.

The key take away from my perspective is about the rigidity of most SFC formats compared to a library like React, and even more so compared to a library like Solid. I'm advocating for patterns that organize code to match developer cognitive limits with the ability to extract portions easily as requirements grow. It's a more organic way of looking at component boundaries than firmly placing them for mechanical reasons for change management like React or syntactical limitations due to their respective SFC formats.