It has server-rendered mdx, client components, inline footnotes, layout bleeding, server-rendered code syntax highlighting, content-collections, and opengraph image generation. It can be rendered fully static or from a server. If you choose to deploy it as static, the "server"-rendering just happens at build-time.
It's a really decent starting point for someone who wants an efficient, lean, powerful, and flexible blog.
I'm sure this is some MBA 101 stuff, but I'm slowly learning that all sales come from a sense of urgency.
A two-week long trial ends and you're not even on the computer? Oh well.
You're recording something longer than 15 minutes that you want completed _right now_ and the only way is to upgrade? Instant purchase.
That doesn't mean that urgency has to come from a place of in-authenticity. In this case, I think the trial time limit is fair. People still get real value (actually for even longer than just two weeks), but if you want the full-offering you have to pay for it. It's a decent balance.
Bingo. The best trials are those that allow the user to determine whether the product is capable of solving the user’s immediate problem without actually solving it unless the product is purchased.
It's a shame that HN doesn't appear to have a "save comment" feature beyond just upvoting, because this is a neat and succinct statement I'd like to remember.
all coerced sales come from a sense of urgency. Not the same thing.
> That doesn't mean that urgency has to come from a place of in-authenticity
In-authenticity is a subjective term here, but are there competing incentives against offering a "use only once" price alongside the full product or a subscription model? You bet.
Most people who desire to build a company alone are not in the pursuit of a billion dollar outcome. They’re pursuing a path of somewhat orthogonal incentives. That said, of course it’s possible - but it’s also not that interesting.
I say this as someone who spend the last decade building a business with zero employees. I’m nowhere near a billion: by design & the patent absurdity of that “goal”.
To the contrary, far less cognitive load. I don’t have to internalize a class name and where it lives in a style sheet and then context switch between the two.
No one does. You either use the web inspector if you need a global view or do a grep to find where the class is being defined.
Tailwind is only useful if you have some kind of templating system where you can define components. And in this case, it’s very easy to scope your css.
Nuqs[0] does a very good job at parsing and managing search params. It's a complex issue that involves serialization and deserialization, as well as throttling URL updates. It's a wonderful library. I agree, though, that it would be nice to see more native framework support for this.
Forms are also hard because they involve many different data-types, client-side state, (client?) and server validation, crossing the network boundary, contextual UI, and so on. These are not simple issues, no matter how much the average developer would love them to be. It's time we accept the problem domain as complex.
I will say that React Server Components are a huge step towards giving power back to the URL, while also allowing developers to access the full power of both the client and the server–but the community at large has deemed the mental model too complex. Notably, it enables you to build nuanced forms that work with or without javascript enabled, and handle crossing the boundary rather gracefully. After working with RSCs for several years now, I can't imagine going back. I've written several blog posts about them[1][2] and feel the community should invest more time into understanding their ideas.
I have a post in my drafts about how taking advantage of URL params properly (with or without RSCs) give our UIs object permanence. How we as web developers should be relying on them more and using it to reflect "client-side" state. Not always, but more often. But it's a hard post to finish as communicating and crystalizing these ideas are difficult. One day I'll get it out.
Don’t get me wrong, I never meant it was easy to solve, just that things could be better if search parameters didn’t somehow become this niche legacy thing with minimal appetite to fix.
Thanks for the point on RSC, probably the first argument I’ve heard that helps me contextualise why this extreme paradigm shift and tooling complexity is being pushed as the default.
The reason to write code is to solve a problem. If the problem domain is complex, then the code to solve said problem will be inherently complex. He solved a problem.
It's because inevitably there comes a time where you want some pages (or even sub-pages) to be static, and other pages (or parts) of your application to be dynamic. If the question is "why" the inverse is "why not"?
Dan's blog is rendered as static, works without javascript and still lets him write complex client-side components when he calls for it. And if one day he decides to add a page that renders content dynamically, he can do so in the same patterns and framework that he's already using.
The goal is developer-choice. No need to pick static or dynamic holistically, have access to both when you need them. No need to pick between hydrating the entire website vs. rendering exclusively on the server. No need to pick between writing client-side amenable code or server-only code.
How many platforms have a "marketing" website for / and a platform website for /dashboard? No need to split them, just use a framework that accommodates both seamlessly. It's more powerful, even though it does come with a learning curve.
To give a concrete example, I’ll probably add some dynamic stuff at some point in the future, like commenting with Bluesky or such. It’s nice not to switch tools for that.
It is certainly not true that the point you describe is inevitable. Lots of sites will never reach the point where they need dynamic content. As to "why not" - because simplest is best until such time as you have a genuine need for the complexity. YAGNI is a maxim for a reason.
Really feels like this generation of devs do not see the value in YAGNI, mostly appear to chase complexity because that's how you peddle courses, talks, books, etc.
I think the reason to split the marketing page from the dashboard one is that you can deploy one without the other. I would actually prefer to have all the marketing stuff in its own repo away from any dashboard code.
It's unfortunate that there is so much misinformation about what react server components really are, but it's not necessarily the fault of either party. The name is confusing (names are hard), the architecture is new (people don't want to learn it), and it lends itself to conspiracy theories (that aren't true).
But it really is a magnificent piece of technology. Because they're called "Server Components" people think that "server" means run-time, but as a friend pointed out, 15 years ago people were running wordpress servers and caching pages ahead-of-time. As Dan mentions here: "server" doesn't imply it has to execute at run-time.
But there are also massive advantages to running a server at run-time that seem lost on people. I do think over time the concepts behind RSCs will filter out into most web frameworks because they are so powerful. It's the best functionality of the old-world SSR languages (PHP, rails) combined with the best functionality of the new-world client frameworks (React). You get to pick and choose when to lean on either, and they work together through composition.
I wish people were a bit more patient and spent a bit more time trying to understand these concepts before bashing them. Part of that is the fault of names, communication, and lack of documentation. But the underlying technology is rigid and strong. It's here to stay, even if it arrives in other forms.
I think it’s fair to say that a lot of the negative reception was also due to
1) No easy way to try outside a framework (now there is with Parcel RSC, but eventual first-class support in Vite will likely be the real tipping point).
2) Poor developer experience in the only official integration (Next.js). Both due to build performance problems (which Turbopack helps with but it still hasn’t fully shipped), due to bad error messages (massively improved recently), and due to confusing overly aggressive caching (being reworked to much more intuitive now but the rework won’t ship for some time yet).
Time will tell but I’m optimistic that as there are more places to try them, and the integrations are higher-quality, people will see their strong sides too.
Thanks for pointing out Parcel RSC. I just read through the docs and they do a great job of explaining RSCs from a place I can understand. In contrast to NextJS where it’s unclear where the framework stops
I'll add to the confusing caching: Next deciding to monkey patch fetch() to add their caching, and Next relying on a React Canary version left in some (surely in me) a taste that RSC were half baked, which is weird since they've been around for like, five years?
> It's the best functionality of the old-world SSR languages (PHP, rails) combined with the best functionality of the new-world client frameworks (React).
And one of my pet peeves is people seeing the former and dismissing it as "everything old is new again" without considering the gains we've made in the meantime with the latter.
> I do think over time the concepts behind RSCs will filter out into most web frameworks because they are so powerful
I don't think that is true. React had one great feature that gives it its name: reactivity. People kept using it despite the bad abstractions added later like hooks, graphql and now RSC. The difference is that now react fatigue is way bigger than the hype, nobody loses a job by stating that RSC is terrible.
Too many devs rely on a single tool to try to do everything, at the cost of complexity. The amount of knowledge you need to use any Javascript framework is IMO, insane, let alone try to keep up with the latest and greatest.
The enshittification of the web partly is shipping giant JS bundles for no reason. (Developer needs > Consumer)
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.
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.
>the band's business has since become far more profitable and extracting, though not necessarily to an obscene extreme.
At this point, it is getting extreme. With ticket sales and couch tour (live streams of concerts you can pay for) they are absurdly rich. Their ticket prices have climbed to a crazy amount and they allow all the fuckery that ticketmaster is hated for. Phish is my favorite band of all time and I have completely stopped seeing them live. I hope they enjoy their money.
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.
I don't understand why world famous acts are expected to have cheap tickets. No one is saying the price of any other scarce/limited non-essential products or resources should have price controls.
I don't have an issue with high prices, in the general sense, I have an issue with artificially inflated prices via dark patterns and other unethical means, which Ticketmaster has built their entire business around.
As a customer who earns a tech salary, mostly I want to be able to go on the site, find the "best available" seats, and buy them. Done.
What Ticketmaster instead forces you to do is go through an artificial queuing system, lies to you about what's best available, has widely ranging dynamic pricing, doesn't allow you to purchase all seat classes available at any given moment and releases them randomly, and does all sorts of other horrid fuckery and at the end as an extra middle finger charges you a "convenience fee" for having you print your tickets yourself or scanning them from your phone after you went through the least convenient, pleasant, and reasonable process every to get overcharged for the tickets.
And let's be clear, we're talking about overcharging. The face value of a ticket can be high for a world-famous act. So let's say the face value of a typical seat is $250 for a concert. Ticketmaster will absolutely charge you $700 for that same ticket.
You're contradicting yourself here. You want tickets to be both cheaper and easier to buy.
They can't be both. The value of the ticket is just high. Either you pay in time, or money. Your enemy isn't ticketmaster, it's the 100,000 people who want to go to a 1,000 person venue.
I don't mind paying $700 if $700 is the face value of the ticket. You're acting like I'm against first-come, first-serve. I am not. I am fine with it. I'm fine waking up at 3AM to buy a ticket. What I'm not okay with are bots and bullshit.
Scalping is an after-the-fact action, which by the way Ticketmaster directly enables (they own Stubhub and have built-in scalping tools in their app). While I find scalping distasteful, that is not the reason why Ticketmaster's pricing and practices suck.
And just to complete myself sounding like a grumpy old man - just open ReListen App or Phish.in and choose any show from 1993-1997 and you'll get something 10x better.
I haven't been to a show in a long time but was obsessed as a young person. I heard some people I know were planning to go to Riviera Maya. I did not expect it to be cheap, but the prices were eye watering. It bummed me out.
I saw them last year live for the first time in over 20 years. I was surprised tickets were available and weren’t totally ridiculous.
We used to go see them a lot in the 90s. A friend was in the fan club and would always get a bunch of new years tickets, and some of those camping out festivals in Maine and New York.
I saw them at the sphere and it was crazy expensive. But I met people there that had gotten cheap tickets through a lottery that Phish had done to allow fans to access the show for a reasonable cost. I thought that was really cool.
You might enjoy my friend’s upcoming book (from St Martins Press in July) - Sharing in the Groove. Talks about the rise of the jam band explosion in the 90s - he interviewed artists, managers and more including Trey, John Popper so many…
I haven't kept up much over the last 15 years or so. What is the situation these days with ticket lotteries and the taping section? Are people still allowed to tape, and do they still do a lottery for tour runs?
You can see it here: https://rsc-mdx-blog.saewitz.com
It has server-rendered mdx, client components, inline footnotes, layout bleeding, server-rendered code syntax highlighting, content-collections, and opengraph image generation. It can be rendered fully static or from a server. If you choose to deploy it as static, the "server"-rendering just happens at build-time.
It's a really decent starting point for someone who wants an efficient, lean, powerful, and flexible blog.
It is open sourced here: https://github.com/switz/rsc-mdx-blog-starter
[0] https://saewitz.com