Tom MacWright

> The point is that there is a difference between having
> two APIs that both still work and having one stable API.

This is the direct effect of high levels of backwards compatability. You can't change APIs; you have to create new APIs and then deprecate previous APIs. That's the only way of avoiding a breaking change (other than never changing something and endlessly layering leaky abstractions on top of it).

> Having multiple integrations with different APIs or
> different libraries to do the same job is a form of
> technical debt, and sometimes it can become quite
> expensive.

I disagree. If you don't need to do any work to something it has zero cost. Write tests to its behavior and it can be a blackbox to your team until you truly need to deal with it.

> A lot of modern build processes don't just target
> vanilla ES5 any more. They'll target something like
> the most recent two versions of the evergreen browsers
> and any specific minimum versions of other browsers
> they need for their particular market.

This isn't mainstream yet. Until very recently the majority of companies were targetting IE 11. A lot of companies changed this in 2020 (Microsoft, Atlassian, etc), and additionally due to Node finally supporting ESM and the release of Snowpack and Vite, many open-source developers are finally targetting something greater than ES5. But you're wrong to imply that it's the norm.

> There are also some modern JS APIs that you can't completely…

I appreciate your question and thought it deserved some thought time, in contrast to my initial off-the-cuff comment. I had difficulty putting it into words, but today I was reading another article posted here on HN and it cut to the heart of the problem:

https://macwright.com/2021/01/15/rust.html

"GraphQL basically lets your frontend application define queries, instead of the backend. You give it a range of things it could query, and the application - React or something else - sends arbitrary queries to the backend.

This makes things hard for the backend. Any sort of SQL-level optimization is impossible - your server is writing dynamic SQL, so you rely on the intelligence of your GraphQL server, which is not always high. Juniper, for example: n+1 queries by default. The workaround - a dataloader - is rough and independently maintained. So at the end of the day, you’re going to have a blisteringly-fast application layer that’s spending all of its time inefficiently querying your database."

This is the data coupling problem, allowing the front end to see and arbitrarily query the data model. Yes, you can put a great deal of effort into optimizing the GraphQL server, but then you've just introduced middleware again, and at that point it's hard to see what the GraphQL protocol has over REST.

recommended:

Tom MacWright "Polite Technology"

"This is a book about the social interactions and situations that are the underpinnings of the open source world. It's about how humans collaboratively create software."

https://macwright.com/sites/polite.technology/preview

"Maintaining open source software

Let's talk about everything except for software development. Sometimes the image of a software developer is a person typing, alone, all day long. In most cases, programming consumes less than half your actual work time, even if that's your job description. Some of that is hated busy-work, some of it is social interaction that keeps you sane, some of it is akin to emotional labor.

Technology changes and every project is unique but there are common components to this work, like interacting with people, supporting and critiquing the work of others, and explaining your craft.

Let's find the parts in common and pick ways of expressing them that are both productive and kind."

I'm not sure its FUD, your main page takes 63.5KB + 38.7KB for the gatsby reactified framework? + an extra 39.8KB in some js bundle and another 51.7KB in some other js bundle.

Also you end up thrashing 5MB of browser storage when I hovered a link check out Application -> Storage in Chrome.

Maybe I'm crazy but your page should not need that much, your site is making 20 requests to resources (thankfully you have http2) and the longest request took about 7s on a slow 3g connection. For comparison here is Tom MacWright's page https://macwright.com/ which does 2 requests at 14kB total taking 2.3s on a slow 3g connection.

I will give you the prefetch trick is superslick in the Gatsby framework for blogs but no reason to have a whole React framework around it. Just use https://instant.page/

I say all this and I do love the component nature of React and SPA's (I love Svelte the most at the moment) but it does really not feel like the right tool for 99% of personal blogs.

I love a good font (and try to use one on my own blog), but part of me gets really giddy when I discover a site with very little styling. It's like I've found some secret oasis that's going to have a high signal-to-noise ratio, or at least some more "raw" writing than you'd find on ${popularNewsWebsite}. Some sites that come to mind:

- https://danluu.com/

- https://100r.co/site/home.html

- https://meagher.co/

- https://macwright.org/

Where Times really shines is printed material. I find it (and Garamond) extremely easy to read.

For longform screen reading, I usually prefer Georgia, Freight Text, Source Serif, and Tiempos. San Francisco is a nice sans-serif font for this, too.

I love the explanation in the linked site:

> Writing on the internet can be a two-way thing, a learning experience guided by iteration and feedback. I’ve learned some bad habits from Hacker News. I added Caveats sections to articles to make sure that nobody would take my points too broadly. I edited away asides and comments that were fun but would make articles less focused. I came to expect pedantic, judgmental feedback on everything I wrote, regardless of what it was.

https://macwright.com/2022/09/15/hacker-news

Which is true. Pedantism is the lowest form of pseudo-intelligence.