switz

I generally agree. Naming things is among the hardest problems in computer science

So here's the kicker: React Server Components don't need a server. They are completely compatible with a static bundle and still provide major benefits should you choose to adopt them (dead code elimination, build-time execution). This is effectively the design of Astro Islands, natively in React Server Components. Letting you write static and client-side dynamic code in a single paradigm through componentization and composition.

If you are curious, my most recent blog post is all about this concept[0] which I wrote because people seem to be misinformed on what RSCs really are. But that post didn't gain any traction here on HN.

Is it more complex? Sure–but it is also more powerful & flexible. It's just a new paradigm, so people are put off by it.

[0] Server Components Give You Optionality https://saewitz.com/server-components-give-you-optionality

I would agree with you that as of late it has been bordering on excess, but comparing to the other large touring acts they're still cheaper. The most egregious thing has been leaning into platinum tickets, which Ticketmaster purports as a way to avoid scalping, but all it does is create an artificial scarcity that drives up false demand. For the last few years, there's rarely been a Phish concert where you couldn't find a face value ticket (or much cheaper) the day of the show despite every show selling out instantly. So it's all a facade designed to rent-seek the more wealthy fans, while keeping the less motivated fans away from the concert and encouraging people to buy up as many tickets as possible to use for trades, even if they have no intention of attending that concert.

As someone who could reasonably be considered an expert in Phish, as well as someone who built their own indie business, I can confidently say no book, business, or entity influenced my business more than Phish. Phish is a business, but they are more accurately defined as a creative conduit for the four members to sustainably make music. Their goals were to work incredibly hard (both in front of an audience and away from them), grow sustainably, and perform live music. They, by and large, treat their fans right and focus on crafting incredible live experiences. Their interviews are gems for those pursuing creative work who are obsessed with process, intent, and improvement.

Their business changed drastically in 2009, when they came back from an extended hiatus. The business side of things had burned them out and they pared down their internal organization to ~3-4 people and outsourced most of it to some close friends (an external management team), so they could focus on the music and their families. Whereas in their first 20 years they were far more fan-friendly and even anti-consumerism (they regularly covered up the advertisements in hockey arenas when playing there), the band's business has since become far more profitable and extracting, though not necessarily to an obscene extreme. The band members have mostly removed themselves from the business side and focus on the creative - a role that lets them keep rolling, but sometimes at the cost of fan-friendliness. It's worth noting that they are incredibly philanthropic, and have donated immense money to environmental, educational, and drug-treatment efforts.

Overall they are a masterclass in running a well-balanced organization that is both a capitalistic business as well as a down-to-earth creative organization and I have no doubt each and every one of us could glean a lesson or two from the way they built their structure over years.

200,000 units is a far cry from just a 'minor hit' - congratulations!

During the project, what was the biggest instinct you had that was ultimately validated by its success, but still surprised you? What was a lesson you learned that you didn't expect? How was working with a publisher? What did they do right and what did they do wrong?

This is a truly excellent post, thank you for sharing. I learned a lot and will take a few more reads to fully unpack it. Thanks for taking the time, I know articulating all of these ideas can be a heavy undertaking.

This post makes a few detours, but the section about their own work is always interesting to me. I've always been a "pull on the threads and then pattern match"-kinda worker, rather than a "productivity-chaser" or "advice-seeker". I just pull on the threads that interest me, and over time these threads always have a way of coming back together. It's the difference between being goal oriented and process oriented. This is a much slower, much longer arc to building your taste, skills, and reaching some semblance of your abstract goals, but the other way just wasn't fun to me.

When I was in undergrad I remember reading a lot of blogs and hoping to live up to their idealistic views (shoutout pg), because I hadn't quite yet identified what career I wanted to lead. I dropped out, and then around 24/25 the desire for those goals really shattered. I pursued a very self-directed path that has thankfully worked out (so far-still ample time for it to falter). As this post points out, the only advice that is universal on the internet is that there is no universal advice. Find what rings true to you and lean into it.

it's been a term of art for a long time

> React Server Components strikes me as React solving a React-caused problem with yet more React.

This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it.

Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability.

I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites.

> There are too many devs out there only expert in the way React does things and can’t step outside of it.

This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day.

> But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.

For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.

I have no experience to share on the creator side, but as a user I am ever fearful of extensions getting rugpulled. Many popular but fading extensions sell out to nefarious companies just looking for users to adspam. Please don't do that.

The simplest way to grow it is to share the link to it in this thread – you have eyes on you, take advantage of them.

It doesn't have to exist - I run next.js self hosted and it's arguably better than hosting on vercel (no cold starts, dedicated cpu, next to my api server/db).

I can't speak to the trend, but for me, it's this idea that invalidates tastemakers and shows that good ideas inevitably stand on their own. Tony Hawk is widely respected, and yet, he's enamored with this forgotten photo of a young girl skateboarding in the rain. And she's holding an umbrella. We all agree-it's a wonderful photo.

Turns out, the girl–in the most respectful way–is just an ordinary person, and the photographer asked her to hold an umbrella, because he felt it would be a good idea. It was a good idea, and many years later the creative result has risen to the surface.

It's like when you go to a concert and witness a special moment that rocks you, and then years later you find out it has millions of views on YouTube. It's democratic validation that we are experiencing beautiful moments all the time, and that we don't need a Tony Hawk to validate them. You could argue that this wouldn't be seen without Tony, or you can reflect upon the many moments that aren't validated, and yet are filled with beauty.

For anyone that wants access just shoot me an email (it's on my HN profile).

I spent a week building a website that is a repository of timeless content. It generally consists of old magazine articles (though not exclusively) that you can pick up at any time and will bring value to your life. I notice most of what we consume on daily basis is ephemeral and not all that valuable outside of the moment, whereas ever-present content is always valuable.

The unique angle here is that each article includes a hand-written summary explaining why the article was meaningful to the curator. This gives you a quick window into the piece without being overwhelming.

Since this is a free website mostly to be shared with friends and family, I implemented user login via "phone number" to save and submit articles, but without a one-time token. So it's "password-less" for now; a trust-based system.

It's basically 'done' - but I'm not sure that I want to share it publicly for the aforementioned reasons. I've been using it on my subway rides to read more interesting stuff. So far so good.

screenshot - https://i.imgur.com/8kIrgBt.png

I enthusiastically agree - and really all that matters is that you feel good about it. As a software engineer who's built (and shut down) many projects, I have always been envious of art forms in which the artist gets to create a piece of work and then "finish" it. We are often at the mercy of perpetual maintenance.

Well done and nice execution.

Nope, we don't take donations. If you want to contribute back, we recommend donating to Archive.org as they do the bulk legwork that makes this all possible and are a valiant internet library worthy of the support. And of course, we always accept pull requests!

All of these bands have agreed to allow people to tape and distribute their concerts for free. This is most popular in the jam band community, but you’ll find a plethora of other bands that allow it as well.

Hey! I created this website and have been maintaining it along with my friend Alec for the last decade. Fun seeing it pop up here on HN. Thanks for sharing!

The innovation here is not bundling, it’s owning the code in your codebase instead of relying on external packages. If you want to make changes to components, icons, etc. it is better to have the raw files and be able to change them, than have to wrap or manipulate them via other methods. That’s the difference here.

I want my own button component, not one that requires upgrades, changes, or a million hidden deps.

I'm not OP, but I appreciate the earnestness of your question so I'll try to answer.

I believe the answer comes from this line:

> Custom Registry Support

This is effectively the shadcn CLI, but with the ability to add custom sources of content in the form of registries. Imagine you want to add a shadcn component, a fontawesome icon, or another custom library component. Wouldn't it be nice to have it all accessible via one unified interface.

Anything that promotes more code-owning and fewer dependencies for lower level items (components, icons, etc.) is a win in my book.

Similar prior art is sly-cli: https://sly-cli.fly.dev

@OP: I'd consider renaming your project to avoid co-opting the shadcn name, though. For your benefit and for shadcn's.

I’m using parts of Shadcn on a real product making real money. It’s really just a combination of cva, radix, and tailwind that you can copy into your app and customize/extend.

Shadcn, radix, and tailwind are all FOSS so they are not “high-priced”.

Your analysis is shallow and unfounded.

This has long been a dream data stack of mine. Best of luck.

If you desperately want good libraries, but aren't willing to pay for them then what is the real problem here?

Also, as far as I can see, the library shared here is completely free.

I'm blown away that this is being upvoted. The lack of effort and critical thought here is appalling.

> it’ll just turn into the disaster that is react server components: feature development driven by corporate interests (eg vercel)

if you've followed along with the react team's discussions on server components, it is very clear that vercel implemented the react team's vision and less so the other way around.

as someone who has been using them extensively, I understand why. they're delightful.

vercel does control next.js which is the only framework to completely implement RSC, but as other frameworks catch up, RSC will have a wider surface area.

will the podcast break when it covers itself tomorrow?

> "We did have a data platform for Life360, which we believe did no harm"

I'm confused. Life360 was found selling precise user location data to third party data brokers[0]. It doesn't take a creative mind to see the harm (or even potential harm) caused here. I could never trust you or your company.

[0] https://themarkup.org/privacy/2021/12/06/the-popular-family-...

> A former X-Mode engineer said the raw location data the company received from Life360 was among X-Mode’s most valuable offerings due to the sheer volume and precision of the data. A former Cuebiq employee joked that the company wouldn’t be able to run its marketing campaigns without Life360’s constant flow of location data.

...

> Two former Life360 employees also told The Markup that the company, while it states it anonymizes the data it sells, fails to take necessary precautions to ensure that location histories cannot be traced back to individuals. They said that while the company removed the most obvious identifying user information, it did not make efforts to “fuzz,” “hash,” aggregate, or reduce the precision of the location data to preserve privacy.

> The former X-Mode engineer said that the company also received raw data from Life360. The company relies on its customers to obfuscate that data based on their specific applications, Hulls added.

it’s not a stack, but you can toggle to the prior branch with `git checkout -`

Or to move back N branches you can do: `git checkout @{-N}`

Taxes and fees should be mandated for all prices up front.

This is how it works in most of the world, there's no good reason it shouldn't work that way here in the US.

Someone will come along and point out an edge case, but for the vast majority of retail situations this is doable.

I use this site every day. Thank you for making it!