not a bad idea - not at all;
but all I initially wanted - was to afford the user some “hangers” / wrappers to apply their classes (and attributes) to, and perhaps offer Surface @click effects - but my stupid decision to attach a screendump of one of the TailwindUI designs totally sidetracked this entire idea;
guess I’ll just crawl back to my little stone in Detroit (Beverly Hills Cop) 
The problem you’ll have there is that there is no tailwind UI npm package. Well there is one called that but it’s deprecated by tailwindcss 2.
The idea of a Surface tailwind was discussed on GitHub previously.
You can go ahead and make your own component library (like tailkit.com) for Surface but you gotta make it without looking at your tailwind UI purchase for inspiration 
@msaraiva Phoenix Component with Slots is released with LiveView 0.17. LiveView calls them Function Components - and - encourages to group multiple components into one module. The reason given is reduction of compilation time. Instead of 100 modules - it is better to have 10 modules with 10 function components each. However, in Surface, we adopt one module per component. Though Surface provides a lot more features and DX - For simple stateless components - what is the best possible way forward? Writing Function Components and using them in Surface or going ahead with Surface.Component?
Not that I am handling a very big project where compilation time is a concern - it is just to pick your mind on the Future of Stateless Components in both LiveView and Surface!
Why? I’d imagine most of the time the compiler is working on the templates, and it is the same amount of template one way or the other. If anything, large amount of smaller modules can be compiled in parallel, so it should favor smaller modules?
It is typically best to group related functions into a single module, as opposed to having many modules with a single render/1 function.
From https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.Helpers.html
Generally speaking compiling a module with 100 functions will be faster than compiling 100 modules with one function each. This is very easy to verify yourself and you can try locally. The multiple modules version is 80-90% slower in my quick experiment. And if we are talking about a project, each module is likely a separate file, so there are more disk reads, more mtime checks, etc.
That said, I don’t think folks should generally be worried about creating modules and files. But if most of your modules are single file functions, it may be that you are having the wrong abstraction.
Until we have a declarative API for LV (which we’re already working on), if you want compile-time checks and use features like named slots or context, you need to define a module as vanilla function components do not provide any metadata required for those features.
So my take for now is to define modules for larger components with many of props/data/slots (where compile-time checks are more valuable) and vanilla function components for either private or smaller/simpler components.
Regarding slots, the next version of Surface will replace its original custom slot implementation for the recently introduced built-in slots, so this is not going to be an issue anymore and as soon as we have a unified declarative API, there will be no more limitations as all metadata we need for most (or maybe all) of the other features will also be available.