shadcn/ui VS macdriver

Shadcn/ui: I've never tried it before but have always wanted to switch from MaterialUI

Honestly the ergonomics of heavily customizable generic component libraries aren't great. Copy and pasting a simple component to make the specific customizations you want helps reduce JS ecosystem churn and dependency pain. Popularity of libraries like shadcn/ui [1] are good acknowledgements of that.

[1] https://ui.shadcn.com/

shadcn/ui

This model is very similar to the popular shadcn workflow. After files are creating in your local repo, you can modify them and check them into source control.

Link: https://ui.shadcn.com/

One of my biggest fears as a frontend dev is to build UIs that are inaccessible for people. It's easy to take so many things for granted.

The good news is you get a lot of accessibility out of the box using native html. For higher abstractions I love working with accessibility first libraries like Shadcn (which is built on top of Radix): https://ui.shadcn.com/

For development of the UI components, we tried something new. Vercel has this new AI tool called v0.dev that allows developers to take advantage of shadcn/ui and Tailwind using nothing but words, which can then be easily downloaded to your local project using nothing but a simple npx command.

Shadcn stands out among the many UI frameworks and libraries as a helpful resource for developers looking for an open-source, customizable way to create stunning and useful user interfaces. Shadcn is a tool to help you build your component library. These are components that you can copy and paste into your apps.

The first big release of the year was the macdriver project, which got a significant response on Hacker News. It gives us Objective-C and Apple framework bindings for Go, letting you build simple Apple apps entirely from Go. That wasn't possible before, so it was a little exciting, but it was early. The native Go APIs included for commonly used Foundation and Cocoa classes were far from complete. They could still be used if you knew what you were doing, but with an ideal of total coverage of Apple frameworks, that wouldn't be enough. There were also unresolved issues just deciding how to best manage memory and pointers, which I knew would fall on me to figure out and take some time.

Even less common are schemas for non-web APIs. In 2016, Electron started releasing a JSON schema of all their APIs that allowed me to build a bridge to use Electron APIs from Go. I had that prototype in mind when I started the macdriver project that was released a couple months ago. Right now we're manually wrapping Apple framework classes with Go types so you can write native Apple platform applications that look like this:

It started as a demo for macdriver, but over the last week or so I've been making a standalone version. 90% of that time was playing around with it while trying to make demos.

Done https://github.com/progrium/macdriver/issues/12