The color variables are HORRIBLY thought out. I’m having to go back and fix them which is tedious and defeats the point of a headless block library which I am supposed to be able to use in conjunction with my global color variables for faster development.
The button variants are laughably bad with how they are integrated with the color variables. They are literally inaccessible from a color standpoint just using the default implementations.
Was there zero Q/A done before release? These are day 1 issues that a junior can fix.
You also have zero written documentation on the color variables. Everything I have had to comment myself to understand it.
The library’s layout for its components is great but I am shocked how incompetently designed the color variables and button colors are in general.
You also have differently structured import statements for each component, making fixing the file paths to go from your obfuscated node module button component to my fixed manual one even more tedious.
I’m sure you never intended anyone to actually download these in bulk and attempt to use all 1400 components.. that’s probably why you are heavily obfuscating all of your code both in your node modules distribution and on your website’s front-end. It was pretty trivial to remove all of the spans you wrap around your code in the HTML, but come on, really guys? You surely know you can render different components based on logged in state, why not give logged-in paid users the ability to get the components via API/programmatically? Leave the obfuscation for the free tier/not logged-in users. One of your big selling points is how big your library is, yet you actively attempt to restrict users to only manually copy and pasting?
You started out so well and I was so hyped to use this library, then I realize I have to copy/paste each one individually, all of the color variables are fucked under the hood, the global container horizontal padding is a pain to fix globally and requires manual revisions if you want to customize, there is zero documentation on some of the most crucial aspects, and if you do want to fix the UI elements manually, the import paths are all structured slightly differently, meaning you have to do 4-5 replace searches for each UI primitive, instead of just one. Which adds up when you are having to fix the colors of EVERY UI primitive, since they were fucked from the start. You literally have 4-5 of the colors in your example tailwind config that are flat-out not used in a single component, and another 2-3 color variables are only used in like 50 components combined. Meaning you have 1250-1300 components integrated with like 3-4 color variables. Great for wire framing in just a couple of colors, horrible for building a production site with color variables as the basis.
Add on top of that the 40-50 components that are plain inaccessible and show errors when you click them in the dashboard.
Sigh, yet another component library fallen to enshittification.
Here’s a hint, the AAA gaming studio model of releasing alpha versions into production and having your users be paid testers, is not a winning strategy to emulate.
I am more than happy to be a paid Q/A tester if you offer, but unpaid you can forget it. Putting this out there so anyone else wanting to use this library in production can understand the work that will need to go into it before it’s ready.
It’s definitely a quality library, but there’s clearly some decisions being made behind the scenes hampering it. Whether from the CEO/founders or someone else (maybe P.E. backers?). These fixes are too trivial to assume they come from incompetence, there is something else causing them.
Hi Madison,
I understand your frustration around the color variables. We are in the process of refactoring these to align with the new Styleguide builder. It will make it easier to go from wireframe to more detailed design without any customization.
Can you provide an example of the differently structured import statements, Its not clear how this is a pain point. But keen to see if we can fix it.
What is the issue with obfuscation, this one’s a surprise to me. You can copy/paste the unobfuscated code for each component from the library page. It’s the same approach as Shadcn which we’ve overwhelming heard from our users is the preferred approach.
We are aware of some components leading to 404 pages and are working to get this fixed.
Please let me know what documentation was missing for you, and I’ll see if we can improve that.
Its helpful if you keep your feedback constructive.
Your other comments about incompetence and enshittification are not appreciated. Our team worked really hard to build this library and there is no corporate conspiracy here to enshittify them. Take a deep breath.
The blocks are production ready. There are thousands of people using them every day.
Rob, I appreciate the reply, and you are right, I was harsh. Here is my feedback in a more constructive format. I apologize for the harshness. Here is what I would change: 1) There is no clear documentation the color variables as to what color variable is tied to what UI component. 2) As for obfuscation, what I meant is that there is no easy way to import all components into a project. As far as copy and pasting, this works well on a one by one basis, but a website or web application is probably going to need around 50-100 blocks minimum for good variety in components to build distinct pages. If you need to make changes to each component, applying them globally is much easier when you have all components already in your project directory. The way I accomplished this way by writing a python script with Puppeteer to get all the URLs from the component changelog page, then create my component directory by formatting the URLs to match the component names, then getting the code from each individual component page by looking for the embedded react component, then getting the innerText without all the wrapped spans. that obfuscate it. It worked, and I have all the components in my project now where I can edit them globally, but you can see how that process is a bit convoluted and would be much easier with a zip file or NPM installation. 3) as far as the specific components which are broken on the website, not really a big deal, just frustrating to see the exact component I need be 404'ed. 4) As far as the import statements, the specific items are in different order. E.g. import { button, buttonprops, accordion } vs. import { accordion, button, buttonProps }. This makes it much more difficult to make global changes to paths such as inserting my own UI primitives like if I want to use the ones you offer manually, instead of from the node_modules package. You end up tediously using CTRL + F, or writing a convoluted regex, or writing a custom python/javascript script to change them.
Your team has definitely worked hard and I appreciate it, you are one of the only ones who have taken the time to build a library of headless blocks specifically for marketing sites and not SaaS sites, so I appreciate your hard work immensely. As far as them being production ready, I guess I should clarify. They are production ready on an isolated, per-component basis. Globally, as an entire library being imported and being plug-and-play and able to be globally changed easily, still a little rough around the edges. So when I look at it, if you have 1400 components then I want to use all 1400 components, that offers immense dynamic content capabilities. However setting 1400 components up manually is too much for one person. I also cant just roll out the components 'as-is' since specific customizations are needed to both abide by your licensing, as well as making it match my site branding and theming. So without QoL changes for global customizations, you are restricted to building out a component at a time. You are completely right that each individual component is fit for production. I guess it's a bit unfair to say the library as a whole isn't just because it doesn't fit my specific criteria.
Your hard work is appreciated, and again I apologize @U06J3G4BCAJ, I should be more mindful of the work put into it before I criticize. I will see if I can find specific code examples to outline what I've said above to make it easier to visualize.
