colinmcd

You seem to be reacting against the term "privileged" in a way I didn't intend. I don't mean to say that they have some unfair advantage. They just have a more foundational role in the tech stack of the products built on top of them, so companies have a bigger incentive to keep the wheels turning.

One of the projects I had in mind when writing this post is the "color" module on npm. It's a fantastic utility for reading in colors in different formats (hex, decimal, CMYK), applying transformations, and getting a modified color back (in your format of choice).

For all intents and purposes this module is "done". It's extremely mature and has already implemented everything it set out to do. It has 3.3k stars and 8M monthly downloads.

When I look at your list of proposals, none of them really apply to "color". The projects you have in your head are big, ambitious projects, not the smaller utility projects I describe in the article.

You also have to factor in the opening-line hyperbole phenomenon!

This is something else I've been thinking about! Caleb Porzio's post from last month describes a Patreon-style "insider access" service built on top of GitHub Sponsors. I think it's a phenomenal idea. Ideally GitHub would also implement something like that "natively" as part of the Sponsors program.

That page argues (convincingly!) that open source is growing faster and faster in terms of contributors, projects, commits, etc. This is definitely the case, despite the fact that the funding problem is unsolved. But who knows how much faster OSS would be growing if it was solved?

OP here. I'd love to see something like this exist. Let me know if it does already, or if someone is trying, and I'll link it below.

EDIT: This model is used by Flattr [0]. Unfortunately Flattr isn't targeted at open-source software; an OSS-specific approach (ideally implemented by a highly visible, established player) is (probably) necessary for something like this to reach its potential.

[0] https://flattr.com/

That was Jessi Combs, Scottie's still around.

"Hard" is the wrong term. But I'm certainly not alone in being rusty on this stuff. Uncontrolled components, form actions, imperatively reading all the <input> values, `x-www-form-urlencoded` data, etc. If you use this stuff on a daily basis, then I'm sorry for your suffering. I haven't touched it since 2015.

Thanks for the measured response here.

I address the fact that the site, as it currently exists, doesn't need any of this currently. I tried to be clear in my "criteria list" that I'm designing for power and flexibility; I don't want to limit myself down the road.

I definitely could have verbalized my stance on headless CMSs better. I'm very aware that there are ways to use them without requiring two round trips. But in the very next paragraph I say "I want every page of my site to be pre-rendered to a set of fully static assets". The solution you allude to (a headless CMS with server-side rendering) requires a server and doesn't meet that criteria.

I also know you can do generate a static site with Next/Gatsby + a headless CMS that's integrated into your build step. I didn't do that way because it seemed overkill - I'm happy using my file system as my CMS.

You mention that I reject using "MD along with React". Which bit of the post are you alluding to? I do reject the idea of putting React components inside of `<script>` tags inside of a Markdown file. Based on my criteria, the "React + a sprinkling of Markdown" makes more sense than "Markdown + a sprinkling of React". Otherwise it's an uphill battle (with a fair bit of boilerplate) to use React Hooks, import styling libraries, etc.

I'm not sure I follow your logic w.r.t this being a damning condemnation of React. There a build step (either Babel or TypeScript) required to use cutting-edge React. That additional layer of separation is what makes it so hard to do React+TS inside of these Markdown-centric CMSs. I don't think that impedance mismatch reflects poorly on either React or the SSGs - they each have their uses.

Could you elaborate on the "other, simpler options even within the TS ecosystem"?

Post isn't a satire, the title is tongue-in-cheek (and a huge miscalculation).

True. I briefly mentioned Headless CMSs but didn't really give them the time of day. I didn't want to do anything that required a server/db/CMS, but I didn't do a good job of justifying that decision.

I do think the term "tech stack" has come to be used more broadly than your definition.

Thanks John! Not discouraged (or surprised) by the reaction. I think using the word "ideal" in the title was a fatal mistake - lesson learned :)

What do you mean exactly? Are you referring to adding a comments section to my blog? I didn't even consider doing that, but if you want that then Wordpress makes a lot of sense.

It's all I've ever known.

More concretely: I try to address that in my list of criteria section under "React + TypeScript". I couldn't shake the feeling that doing anything complex in the future was going to be even more complicated if I have to fight against an SSG framework to do it. I also address the fact that currently this is wildly overengineered currently :D

All my dependency versions are pinned, and I'm not using any global CLIs that may change under me. Valid concern though if you don't take precautions.

I recommend reading through some of my criteria (ability to use npm modules, TypeScript React components, etc). May be possible with Wordpress (haven't tried it) but sounds like an uphill battle.

Haven't been banned from GitHub yet but the "shunned by community" is coming together nicely.

Also, to be fair, it's my second post.

Thanks Dan :)

NetlifyCMS looks really cool. It definitely took me a while to come around to writing MD directly (basically until I discovered VSCode's hot-reloading Preview), but I understand the appeal of a rich editor.

I'd definitely get rid of the word "ideal" if I could post this again It attracted a little (read: lot) more vitriol than I expected. I submitted this right before going to bed so by the time I woke up it was too late to edit the title.

I appreciate it! Too late to edit the title unfortunately (I posted this right before going to bed...bad move).

You lost me at "plugins" I'm afraid. I looked into ways to mix in React + TypeScript into both Hugo and Jekyll and it just seemed like an uphill battle. Based on my criteria (which I'm realizing aren't very popular on HN!) the best approach is to build everything "React-first" with Markdown mixed in, instead of the other way around.

One of my goals is to maintain that same authoring simplicity. All I need to do is create a new `.md` file in the right directory and a new blog post is created - just like you. I just don't want to fight an uphill battle every time I want to leave that lane.

I did, but I wasn't satisfied with that option.

I'd like the ability to embed arbitrary React+JSX into my Markdown, something which can theoretically be done (i.e. with the Hugo Babel plugin). But then I immediately realized I would have issues with importing my styling libraries (I used a custom-built Tailwind-esque set of emotion[0] classes) and using React Hooks.

As you can probably tell I have a hard time letting go of the power/flexibility of the React/SPA approach since it's all I've used for several years now.

I'm not using "static" to imply "non-interactive", just that there shouldn't be a server that does any rendering/data loading.

What kinds of rich content? React + TypeScript, or something else? Have you used the Hugo babel plugin?

Just published an update to Zod that overhauls the error reporting. Now you can get the exact location in your complex/nested object where each validation error occurred. Plus all detected validation errors are reported simultaneously instead of just throwing an error at the first sign of trouble.

If you decide to switch to Zod keep me posted and don't hesitate to reach out with any feature ideas

Been meaning to respond to this properly.

I tried this exact approach initially but gave up after experiencing a series of frustrations.

1. I'm operating in a highly-connected, relation-heavy data domain (medical) where the queries I needed to do required a LOT of joins. I wasn't good enough at SQL to make the queries performant in my resolvers. I ended up switching to Neo4j and all the performance problems went away. Unfortunately Neo4j doesn't enforce ANY field level schema whatsoever Zod provides the type enforcement for the whole data layer. I

2. I had a lot of trouble getting the codegen pipelines to work properly, and I got really sick of using codegen to create types for my queries. I also just don't like defining my queries as strings in the first place. There were scenarios where I would run slightly different variants of a query depending on some conditional logic and I had to define these queries separately. I'd much prefer to use a client-side query builder that can be used in conjunction with conditional logic but I couldn't find something to that effect (this was 15 months ago, perhaps things are different now).

3. This is far dumber but I've enjoyed building my own schema definition tooling so I can include whatever metadata on my types without needing to split up my definitions in one place. For instance, on every property of a given model, I'm able to include a name (e.g. "First name") that I can use to auto-generate forms and the like. With GraphQL I would define the model properties in GQL and the other metadata in a separate file. Again, it's dumb but it's a preference I have.

4. I don't like that you have to define relations on both sides in GQL. I'd rather "register" a bi-directional "edge" in one place, instead of splitting it into its two unidirectional "components". Again, just a (rather nitpicky) personal preference. I'm building some schema definition and querying tooling on top of Zod to this effect.

5. Typing the mutations was a huge PITA. Many mutation parameters are a slightly modified version of an already-defined type (e.g., a `createUser` mutation will accept a User instance but without the `id` property). But because all the definitions are in GQL, there isn't an easy way to represent this without highly duplicative typings, like this from the GraphQL docs:

  input MessageInput {
    content: String
    author: String
  }

  type Message {
    id: ID!
    content: String
    author: String
  }

  type Mutation {
    createMessage(input: MessageInput): Message
    updateMessage(id: ID!, input: MessageInput): Message
  }

I'm planning to look back into this given the upcoming release of Prisma 2 and the maturation of prisma-nexus, which I think solve some of these complaints.

I guess it's something in the air! Given the popularity of the other libraries, it's surprising that there's isn't an optimal one.

And yeah, unless you've gone down the rabbit hole of type safety obsession, it's hard to understand the necessity of this. I like that you specifically call out REST API validation in your docs...the difficultly of type safe API implementation was what drove me to build zod.

I'm using Zod plus a hand-rolled codegen tool to implement an end-to-end type safe RPC API that validates all data at runtime AND generates a statically typed Typescript SDK for use on the client.

PS If people like the sound of that I might publish that too. Let me know if it sounds interesting.

Fixed! I'd done exactly zero testing on mobile (built the site from scratch yesterday).

Consider the thread derailed :P

Just fixed this! I'd done exactly zero testing on mobile (built the site from scratch yesterday).

Ah I see I misread your comment.

You're right, Cujo also shouldn't have validated. In a previous version of the post `neutered` was nullable and `age` was optional, but I decided to save the discussion of nullables/optional until later so I changed it. Good catch!!