adamscybot
"All blog posts mentioning feature Y published after September...[more examples]...The three most recent case studies in the finance category...[etc]"
Fairly simple queries. If you're willing to build an MCP server (as they did for their solution), you could just as well build one that reads structured front matter.
"You can't. You'd need to parse frontmatter, understand your date format, resolve the category references, handle the sorting, limit the results. At which point you've built a query engine."
Well that's a scoped problem. Looks like it already exists (e.g., https://markdowndb.com/) and doesn't require moving away from Markdown files in GIT if you want.
Or use something like content collection in astro (https://docs.astro.build/en/guides/content-collections/). Hell, looks like that lets you have the MD files somewhere else instead of git if you please.
The AI-generated points aren't as compelling as the prompter thinks. A new common problem.
Yes, you don't need flatfile-committed raw text for AI tools to work properly, in part because of things like MCP servers. Yes, semantically linked content with proper metadata enables additional use cases.
The next point to make would be "if you use our thing, you don't need to think about this", but instead goes into a highly debatable rant about markdown in git not being able to fulfil those additional use cases on a practical level.
This distracts from the what I imagine is the real intent: "git and markdown files don't come automagically with a snazzy collaborative UI. And yes you can still use AI, and use it well out of the box. If someone tells you you need markdown in git to do x,y,z with AI they are wrong."
Personally, I can get over the "AI writing style", but only if the content still nails the salient point...
type thing =
| String(string)
| Bool(bool);
let arr: list(thing) = [];
let add = (item: thing, dst: list(thing)): list(thing) => {
switch (item) {
| String(s) => dst @ [String(s)]
| Bool(b) => dst @ [Bool(b)]
};
};
let newList = add(String("asd"), arr);
But you'd be surprised about the "react for the front end of the CLI" part. I used this thing a whole six years ago in a complex interactive CLI and it came off great to use, maintainable and ergonomic. React is just one framework that proscribes to the "UI as declaritive/composable trees" pattern. And that UI doesn't have to be web based. That pattern works for all UI's I've come across.
Its the pattern that is a good reason to do this. And not react/js landscape. That part is probably a bonus for many though.
Probably, other Ui frameworks could also map, seeing as the declarative/composable tree pattern is ubiquitous now. So it's important to note it's that pattern which enables this, and not a specific framework.
But React is one of the ones that is also more removed from the web target than others.
However, regularly it's not the case -- especially with people moving from nominal systems.
TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.
Iframes need a full web context whilst CSP cant target individual code blocks. For example, I might want my code to be able to do alerts, but I dont want dependency x to be able to.
EDIT: Ah I think thats what you meant by your "code in a sandboxed iframe thing". Fair.
- It being web based means you can target this kind of software for maximum "impact"
- NPM dep trees are massive and you generally have thousands of tiny libs. The chance of something like this happening and being noticed goes up therefore.
- NPM ecosystem is a bit more wild west which again leads to increased chance of something like this being able to occur in the first place.
Of course certain things change this balance. Hopefully nuclear power plants dont have NPM in their toolchain. And I believe financial orgs already have quite heavy auditing of dependencies.
Your API should match semantic actions on your client like the UI and it needs to do this in such a way that it happens in one database transaction.
With REST, new UI requirement that needs to save 2 objects together across multiple entity types...? GG.
In general, the tooling/spec has thousands of open bugs, isnt going anywhere, moves very slowly and is missing fundamental features.
https://github.com/OAI/OpenAPI-Specification/issues/1998 heres the ticket where it will inevitably be ignored and die. But even if it was supported in the spec, the open source generators wont support it anyways.
Said generators also uses "logic less" templates to generate something that very much needs logic. As a FE dev, I love nothing more than to fork a an archaic Java based generator to get the client gen working...not.
GraphQL has first class support for this scenario.
In my experence therefore, the tooing (code gen, doc gen) etc around OpenAPI is piss poor in comparison to gql. Just look at GraphIQL compared to postman.
Yes I agree, I think this is the answer. Video streaming is allowed since they already lost -- no one wants to download the whole video as an app first because the experience would suck.
That's not true of games...yet. They are scared it will be. As an enthusiast, I'm a little scared too!
It's exactly the same logic.
Also the tooling is next level . GraphIql alone is miles ahead of any REST tooling offerings. Also, typescript generation. Truly improved my workflow.