Right now I believe the cost is directly related to what it costs to run the number of queries offered in each plan. Charging less would have them running at a loss.
For creating requests the GUI of postman is way over the top. HTTP is so simple, why not just write that directly in a literate format you can checkin to a repo? For actually running the requests though I agree a gui is nice. I actually use dot-http as an embedded tool in a browser extension. They're still alternatives, just not in the style you're used to.
I'm curious which part you find deficient? It's biggest downside is probably being Turing complete but that doesn't make it deficient, rather it's too easy for devs to code incomprehensible types with it.
Another poster pointed out I was probably misremembering cobol. Either way, your example was google searches. You don't search millions of times a day so you have to be talking about backend functions? The banking system could easily hit a million function calls in a day related to you or data you care about.
I bet you're right and that I'm misremembering. I learned about it in the context of fronting mainframes with graphql so I wasn't thinking too much about the backend language.
Ligatures don't change the spacing. Those 2 monospaced characters still take up 2 spaces but are rendered as 1 glyph. Your code is still monospaced in all the ways that matter.
So I spent some more time reading through using HOCs in React and I think I'll have to give functional components more of a try. The specific example I was thinking of is https://github.com/graphql/graphiql/blob/50674292c55eadf0e61... but this component will probably always be complex because of the Codemirror interaction.
Kagi has been amazing: verbatim mode that actually works, blocking sites you don't want to see, boosting sites you always want to prioritize, and lists of sites you can customize for specific searches.