Yeah, Reading it clearly in the editor - Probably MD to HTML happens in the editor anyway. So what we are dealing with here are a battle between ease of writing, readability and various cost dimensions.
A) Enterprises for one, e.g Rendering of an HTML page vs MD in an AI IDE or even tokens (compounding costs for a communication doc may be billions in a year)
B) True, its a subset, nobody is arguing against it. HTML has overheads in terms of stylings. MD in essence is just a straight arrow.
If there is a communication between two points with ultimate low latency way with readability and threshold just enough to have the idea, MD passes that mark. As tokens needs to conserved
What do you mean by the cost of rendering an HTML page in an IDE? You know those markdown previews are almost always rendered by converting them to an HTML snippet first, right? Also HTML does not need to be styled, the tags have their own semantic meanings just like the various semantic structures of markdown. The styling “overhead”, which gets added so the document is easier to visually interpret for a human, is exactly the same. The only time when styling doesn’t come into the equation is when you directly view markdown source.
If cost of showing HTML and MD are same in the CPU level for UI, but generation of them costs uneven at AI level (as it should be mathematically), shouldn't the equation be what is the lowest cost to represent something considering the token usage
> Rendering of an HTML page vs MD in an AI IDE or even tokens
MD is usually converted to HTML and then rendered by a webview, which means MD is more expensive.
> compounding costs for a communication doc may be billions in a year
Lol absolutely not. It would be surprising if the "compounding costs for a communication doc" reached $1 a year. I don't think you understand how efficient computers are and how optimized HTML rendering has become.
> As tokens needs to conserved
Not really. No large org is really optimizing for fewer tokens yet.
Thats a complete reductive idea of MDs. MD was long spawn before LLMs as a need for light weight formatting and easy conversion to different formats. No one used at that scale doesnt mean the absence of the utility for it, as the primary adopters were tech community and that was a layer below the consumer market. Utility obviously stands, the question is, can HTML supersede on that utility side of it in all developer work components.
With AI IDEs, Personally I had to generate a tons of md files for planning a task, analysis on the code for something or other, a task doc for a feature - a summary to paste into the clickup ... and I saw many devs keeps on generating them, and all tucked away into folders. Good, okay.
For the company I'm currently working I had made a VSCode extension where I can sync the task doc with clickup via frontmatter.
I decided to take it to next level as a side project. I built a CI integrated, git-native, agent template transformable syncing pipeline with git MD files to any project management tools. That means, either you can save your md files vanilla in your wiki (thus using the clickup AI search to dig up later, get insights etc) or you can use a AI agent template transformer to turn it into a task template (Background, acceptance criteria, functional requirements etc.) and update or create a task on a board.
I've been working on it now. I don't know how it will fare, but I feel like product is coming up nice.
I was actually working on last weekend with something that has similarities. I am working on USM.tools, which allows specifying your services in structured way.
There is a need to specify some of the data in semi-structured way, and I am using markdown for that.
So there is this interesting relationship between unstructured, semi-structured and structured data, and markdown hits that middle ground.
Can I suggest you make some Jira etc. templates on your landing page clickable, so a visitor can grasp your idea more easily? For me it was not clear whether the specs are just plain markdown, or do you have some additional tagging there.
Service management is business oriented, what is the service we are providing and how do we deliver it, and how do we agree with the customer what we deliver. And when the data is structured, other interesting oppurtinities become possible.
This particular use case is people working together to collect data in a workshop. 10 people don’t want to see somebody searching for the right place in a form, it interrupts the flow of the meeting. You need to capture the ideas raw, and then structure later. That is where question anout how unstructured data is captured in strucured format pops up.
It is a workflow I directly support in my tool, not a generic tool like yours.
