The price of an iphone has remained constant over the past ~20 years. It's arguably already fairly cheap for a device that is so important for everything we do (especially considering that there is marginal benefit to upgrading every year these days and an iphone from 5 years ago still functions fine)
supabase has the most schizoid brand. They should just embrace the fact that mobile devs don't want to do backend for their crud app rather than trying to be the "everything backend".
why are they releasing a web component library when React Native doesn't even have a decent UI library? Like who are supabase's customers again??
Despite the title "UI library", this is more like a "component registry" for developers to bootstrap their applications and it will work for everything from Web & Mobile, to database scaffolding. Perhaps some poor naming/positioning on our part.
If you aren't familiar with shadcn, it works by dumping a bunch of files into your application which you can modify at your leisure. This is a different from something the "Bootstrap" approach where you could only do minimal tweaks to the theming.
The distribution person in me commends you for cashing in on the "component registry" hype in such a creative way. And that's not a backhanded use of the word creative: the moment it clicked was great, really just a smart application of something people are hyped about right now!
But the developer in me, who realizes how bad we are at design realizes shadcn/ui is terrible for 99% of people using it. They don't have a design system, don't know what that even means, and their sinful hands should not be tweaking any UI libraries, at most being limited to modifying a rich set of theme tokens that force consistency... not touching individual components or copying in random cruft with hard coded gaps between elements.
And so for all that (and also tl;dr) I wish you'd have just shipped actual versioned, buttoned-up components that are well thought out and themeable through tokens, just like your existing auth UI.
You could have even made the default theme shadcn-like to satisfy all the people lying to themselves that one day they'll actually modify that ui folder.
> They don't have a design system, don't know what that even means, and their sinful hands should not be tweaking any UI libraries, at most being limited to modifying a rich set of theme tokens that force consistency
I feel like the majority of shadcn users doesn't tweak it whatsoever though. In fact - I bet you a large percentage has never even considered the ability to tweak it, just seeing it as a plug-and-play set of UI components. Think old Android and iOS apps, where almost everyone just used the default components.
> You could have even made the default theme shadcn-like to satisfy all the people lying to themselves that one day they'll actually modify that ui folder.
That's why shadcn is so terrible: you're resorting to diffs and a loose convention instead of a stable API and a package manager, for the promise that one day you can definitely probably modify it into something else... yet if you're the kind of person to start with shadcn/ui instead of Radix, you shouldn't be modding components in the first place.
Even if you get real designers later, they're not going to try and "evolve" shadcn into your brand, they're going to start from scratch and you're back at Radix again.
> satisfy all the people lying to themselves that one day they'll actually modify that ui folder.
What I'm saying - they're not lying to themselves that they'll do that. They've never even considered it as being something to potentially do! They consider it as a package to use as-is. "A re-design later on? Who knows, by that time we'll have people who know their UI stuff, they'll figure it out. Whether that will be based on shadcn? Who cares, not important." I bet the premise that all these people are using shadcn with the idea of some day modifying it just isn't the most common reality.
So you're just not familiar with shadcn then, that clears things up!
The main selling points and source of shadcn's meteoric rise...
- It's not a component library!
- It's easy to customize!
- You just Ctrl + C, Ctrl + V!
- You can just edit it in your project!
- No more fighting themes!
- It's a kickstarter for your design system! (contrary to my words that you're repeating, many people choose shadcn/ui thinking it is going to make a meaningful difference in starting their own design system, people who have no business starting design systems especially)
> I bet the premise that all these people are using shadcn with the idea of some day modifying it just isn't the most common reality.
The thing is literally distributed via copied files and updated via diffs instead of being a package. The entire cargo cult that lead up to that is 100% the idea they'll modify it. It's just either don't out of apathy (and should have just used a component library), or do and do so terribly (and should have just used a component library).
I am. I'm saying that what you see as its main selling point:
> It's easy to customize!
May be very overstated, with lots of users not caring or even knowing about that as a selling point. They just use it for all of the other selling points.
> The thing is literally distributed via copied files and updated via diffs instead of being a package. The entire cargo cult that lead up to that is 100% the idea they'll modify it. It's just either don't out of apathy (and should have just used a component library), or do and do so terribly (and should have just used a component library).
It definitely started out that way. Just like sports brands started out selling trainers for, you know, sports. And now 99.9% of the minutes-worn for them is during non-sports activities. But they're meant for sports! That's their selling point! Sure, most people couldn't care less though, and don't even buy them with the idea of using them for sports.
None of the other selling points are any more applicable to the average dev...
And it didn't just start out that way, the only package is still a cli tool that will then diff your files.
Overall, it really doesn't make sense to paint this all as some now discarded origin story, especially when you're in the comment section of a major launch that's based on shadcn and selling itself on the exact same story.
But if that's how you see it, let's agree to disagree.
I am not much of a philosopher and don’t have strong opinions about these things. I argue mostly from a utilitarian point of view. I think it is fair to say most people find shadcn useful hence its popularity. As to whether it is the “right” way to build/compose UI will depend on the context.
For the absence of design tokens for instance, shadcn is remarkably themable using the main css file.
Also, most people using it are probably prototyping or building a school project or something - most are not businesses making big bucks.
So from a utility point of view, it is great. The rest, I leave to the philosophers
Well either you can be a philosopher for yourself, or you can be one of their subjects, consuming what they throw down on you. The way I see it, you might as well understand the muck they're leading you to under the guise of utility.
But if you're never aiming for anything more than prototypes and school projects, I agree, do whatever.
That depends entirely on how you implemented your middleware.
This vulnerability also isn't explicitly about auth: it's about attackers being able to send a colon separated list of middleware to skip. That could affect applications in all kinds of unexpected ways depending on what they are using middleware for and how they designed their application.
That's the beauty of the current chaos-driven model. No explicit marching orders required. Just let it be known that inconvenient facts/actions can be punished at any time. Self-censorship takes care of the rest.
Half-disagree: Firings aren't their goal (nor, demonstrably, are cost-savings.)
The goal is coercive power over a culture. Firings are just one tool in the toolbox.
______________
Tangentially, loyalty-oaths are another case where the purpose goes beyond the immediate effect.
Fascists presenting an allegiance-or-else choice aren't extending any of their own trust to affirmative pledges. They know it's coerced, and the fact that everybody else knows it too is a feature, not a bug.
Why? Because the real goal is not to create trust for themselves, but to destroy it for everyone else. To survive the purge, victims must scar their own reputations, making it harder for anybody--even other victims--to trust them in the future.
Ex: Even if I'm totally certain Mr. Smith was lying to the fascists when he pledged loyalty to keep his job, there's a "damaged goods" aspect: Would he lie to me if his job was threatened again? What other compromises might he make to other threats from authority?
Despotism does not lead to greatness. Instead we will have big Corps (oil, pharma...) owning, benefiting, and hiding public knowledge. Even China does better these days
From the dates on https://www.climate.gov/news-features/blogs it looks like this is / was a roughly weekly post, so it might take a while if you're waiting for them specifically.
We actually found Aurora to be about 3x slower than community PG for small queries. That was back then, maybe things are better now. Migrating to another database (and Aurora is Postgres-compatible, it's not Postgres) is very risky when you've been using yours for years and know where the edge cases are.
I’ve consistently found Aurora MySQL and PG to be slower than everything, including my 12 year old Dell R620s. You can’t beat data locality, and the 4/6 quorum requirement of Aurora combined with the physical distance kills any hope of speed.
Aurora is postgres but with a different storage layer, no? It uses the postgres engine, which other postgres-compatible databases like cockroach do not, right?
Thanks for this! I didn’t know this library existed. I’ve used a couple of other small libraries to get rust-like error handling and patterns into my Typescript projects. But this is way more comprehensive.
I like ideas from effect, I use my custom result type all over my application as well as my custom tryCatch & promise.allSettled wrappers.
Issue comes down to you need to wrap all of your code in effect/results. Something like rust has that built in so you're not really 'jamming' it in there.
It adds a bunch of boilerplate. Still better than the mess that is exception throwing.
reply