Soon... there are 15 competing standards.
Show HN: SmallDocs – Markdown without the frustrations
31–40 of 53 posts
Re: Show HN: SmallDocs – Markdown without the frustrations
#32> Markdown files are slightly annoying to read/preview
Maybe I’ve missed the intentions of markdown, but the ability to easily read the plain text version has always been the killer feature.
Rendering as html is a nice bonus.
I understand there are plenty of useful things to say “but what about…” to, like inline images, and I use them. But they still detract from what differentiated markdown in the first place.
The more of that you add, the more it could have been any document format.
Re: Show HN: SmallDocs – Markdown without the frustrations
#33Cool project. Heads up - there’s a commercial company with a very similar name that might decide to hassle you about it: https://www.sdocs.com/
Thanks + thanks for the heads up. I will see what happens. It's a domain-name war out there!
In the spirit of r/IllegallySmolCats, perhaps SmolDocs is a possible option.
Re: Show HN: SmallDocs – Markdown without the frustrations
#34Using fragments for secure data has been discussed before on hn: https://news.ycombinator.com/item?id=23036515. Tldr: it may not go directly to the server (unless you are using a buggy browser or web client) but the fragment is captured in several places.
Re: Show HN: SmallDocs – Markdown without the frustrations
#35> Markdown files are slightly annoying to read/preview Maybe I’ve missed the intentions of markdown, but the ability to easily read the plain text version has always been the killer feature. Rendering as html is a nice bonus. I understand there are plenty of useful things to say “but what about…” to, like inline images, and I use them. But they still detract from what differentiated markdown in the first place. The m…
I feel like things have changed as the main interface for code has (for some) become an agent running in the cli. I feel like we (certainly I) check my code editor way less frequently than before. Because of that (for me) easily reading/rendering Markdown files has become more of a pain than it used to be.
Re: Show HN: SmallDocs – Markdown without the frustrations
#36Earlier quoted context omitted.
Thanks. The question has made me wonder about the value of some sort of real time verification service.
If it's possible to isolate that part of the code, and essentially freeze it for long periods. At least people would know it wasn't being tweaked under them all the time. That is my half of a bad idea.
I have something coming out soon (just working on it). Your client (browser) has hashing algos built into it. So the browser can run a hash of all the front end assets it serves. Every commit merged into main will cause a hash of all the public files to be generated. We will allow you to compare the hashes of the front end files in your browser with the hashes from the public GH project. Interested to know what you think...
Re: Show HN: SmallDocs – Markdown without the frustrations
#37URL data sites are always very cool to me. The offline service worker part is great. The analytics[1] is incredible. Thank you for sharing (and explaining)! I love this implementation. I'm a little confused about the privacy mention. Maybe the fragment data isn't passed but that's not a particularly strong guarantee. The javascript still has access so privacy is just a promise as far as I can tell. Am I misunderstand…
For the "prove the server doesn't touch the data" problem — the realistic path today is probably reproducible builds + published bundle hashes. Concretely: the sdocs.dev JS bundle should be byte-for-byte reproducible from a clean checkout at a given commit. You publish { gitSha, bundleSha256 } on the landing. Users (or agents) can compute the hash of what their browser actually loaded (DevTools → Sources → Save As →…
That's basically exactly what I'm working on now actually. We will let you compare all the publicly served files with their hashes on github
Re: Show HN: SmallDocs – Markdown without the frustrations
#38Nice implementation — the URL fragment trick for privacy is clever. Related pattern I've leaned into heavily: treating .md files as structured state the agent reads back, not just output. YAML frontmatter parsed as fields (status, dependencies, ids), prose only in the body. Turns them from "throwaway outputs" into state the filesystem enforces across sessions — a new session can't silently drift what was decided in t…
I think the next thing I want to do (but not sure how to implement yet) is to make it easy for your agent to go from SDocs url to content. I don't know if that's via curl or a `sdoc` command, or some other way... That could include the styling Front Matter / the agent could specify it.
At the moment the most efficient way to get sdocs content into an agent is to copy the actual content. But I think that's not too beautiful.
Re: Show HN: SmallDocs – Markdown without the frustrations
#39> Markdown files are slightly annoying to read/preview Maybe I’ve missed the intentions of markdown, but the ability to easily read the plain text version has always been the killer feature. Rendering as html is a nice bonus. I understand there are plenty of useful things to say “but what about…” to, like inline images, and I use them. But they still detract from what differentiated markdown in the first place. The m…
I feel like things have changed as the main interface for code has (for some) become an agent running in the cli. I feel like we (certainly I) check my code editor way less frequently than before. Because of that (for me) easily reading/rendering Markdown files has become more of a pain than it used to be.
If you problem is that you don't have a text editor open...just open it to read the file? When I click on a Markdown file, it opens in my code editor with the preview pane already open. Then I close it when I'm done. How is that different from any other file on a computer?
If your problem is that you don't want to use a text editor, there are many markdown viewers out there, both dedicated (MarkLite), as part of a larger tool (Obsidian) or even in an office suite (LibreOffice Writer).
If your problem is that you don't want fo leave the terminal, there are many command line markdown "renderers", at least as far as that is even technically possible (glow is markdown-specific, bat is more of a general fancy text file viewer).
I fail to see how any of these problems are even partially solved by a web app and a CLI tool that launches it, let alone any better than the existing solutions.
Re: Show HN: SmallDocs – Markdown without the frustrations
#40I can't believe I'm saying this, but this should be an Electron app. Or Tauri or whatever.
Seriously, it's a really nice Markdown app, but the "launch a CLI to urlencode your file" flow is such a messy way of doing this. Just open the file like any other app. Sure, the web version is convenient for demonstrating to people or one-off use, but it's no way to work day to day.
As for the motivation... "Fiddly to send/receive"?? Just send the file like you would any other. Don't you have to send other files? So you already have a way of doing this. Just do that. Bonus points for being able to easily receive an edited file, make diffs, etc., as well as the person on the other side being able to use whatever viewer/editor they prefer, not the one you pushed onto them.
How is sending a GIGANTIC link any better? If your file is nearly as long as the shit my LLMs write, you'll reach the chat character limit on most platforms, even though the file itself is well within file upload limits. And now there's a link shortener to solve this problem, which just defeats the purpose of it being offline and independent of a cloud service.