Suspense is all about defining the boundaries. Similar to how Error boundaries work. While it's possible hide certain transition behavior generally speaking the end user is best to understand what should and shouldn't load together. What needs to be displayed sooner, or what takes longer to load.
It isn't about showing localized loading spinners. That part is easy. It's about controlling loading states to reduce unintentional waterfalls. So I don't see it just get masked everywhere. Someone could build Suspense into their component system like a Router. But that isn't the full story.
It has some big benefits too in that it acts like a net so once in place, as you add or augment async interactions they will continue to just work as you expected. Some downstream data suddenly becomes Async or some new nested component now relies on Async data that didn't before, you don't need to go edit a bunch of places.
The control flow is Solid specific and there are docs here:
https://github.com/ryansolid/solid/blob/master/documentation/rendering.md#control-flow. And they are completely essential in that again Solid works completely different than React. In Svelte they use {#each} or Vue v-for etc.. Solid shares more in common with these other reactive implementations than React.
The reason is list.map always iterates over everything. If you are mapping to JSX elements in Solid you are recreating the DOM nodes everytime, whereas in React you are recreating VDOM nodes everytime. That's unacceptably not performant. In so Reactive libraries tend to use special helpers that do memoized creation ie only run the callback the first time when they add items. This involves creation special data types to add a `.map` which I don't particularly like since that brings array types which adds overhead. Or just have a special map helper. Components felt like a natural fit here since they are extensible and custom createable too. It's incredibly powerful.
I felt that way too a bit at first but these control flows are part of the visual representation. Like it or not in every framework they are always there to govern UI display. I don't find this contradictory. They might not always look like components, but they are part of the template. There are cases of things that shouldn't be components perhaps. What comes to mind are things that purely deal in data, but if there is a hierarchical concern using the template as the injection point actually serves to enforce the contract.
This takes it from the opposite side but Dan Abramov's article on "Why isn't X a Hook?"( https://overreacted.io/why-isnt-x-a-hook/) sort of explains this idea. I mean people like what they are comfortable with so people will make their own abstractions etc... I mostly like where things have been heading, and I recognize that puts me in a bit of a minority as someone in web developing for 20+ years. I was there, I remember how we got here. I don't think all ideas are great. JS in CSS is a bit of a mess. But I've worked in enough MVC code bases to appreciate why we are attempting to solve the problem differently.
