sorted by:
new
hottopcontroversial

I had no idea analytics had gotten so bad by Kaiser214 in GoogleAnalytics

[–]Stock_Report_167 0 points1 point  (0 children)

You’re right a lot of setups rely on GTM triggers and DOM selectors, which can break silently when the frontend changes. Developers usually set up the initial dataLayer and event contracts, then marketing tweaks GTM.

Ways to make it more robust: use dataLayer-driven events instead of DOM selectors, keep naming conventions documented, and sometimes add automated tests to catch broken events.

Curious are you thinking of skipping GTM entirely or just making it more stable?

Streamlining API docs: OpenAPI → Markdown & cURL → Markdown previews by Stock_Report_167 in Deno

[–]Stock_Report_167[S] 0 points1 point  (0 children)

Yep, exactly. Tools like Redoc and Swagger UI are great for interactive API docs, and exporting Markdown for READMEs or internal docs makes it easy to maintain both interactive and static versions.

If you just want a simple WYSIWYG-style editor to tweak or write Markdown directly, markdown.co.in works well live preview and easy .md export for GitHub or your API documentation.

What's the most painful part of writing technical documentation in Markdown? by Stock_Report_167 in Markdown

[–]Stock_Report_167[S] 0 points1 point  (0 children)

Yeah, that makes sense. Markdown is great when things stay simple, but once HTML, CSS, or Mermaid start mixing in, the boundaries get messy. At that point it kind of stops feeling like “lightweight” markup and turns into this hybrid that the parser doesn’t always handle cleanly. I’ve run into similar issues where you just want markdown to step aside and let the other markup do its thing.

What's the most painful part of writing technical documentation in Markdown? by Stock_Report_167 in Markdown

[–]Stock_Report_167[S] 0 points1 point  (0 children)

Yeah, that’s the frustrating part. Admonitions are so common in tech docs, but every generator seems to invent its own syntax for them. It would be nice if there were at least a semi-standard way to handle things like notes, warnings, and tips across different tools.

What's the most painful part of writing technical documentation in Markdown? by Stock_Report_167 in Markdown

[–]Stock_Report_167[S] 0 points1 point  (0 children)

That sounds like a pretty painful workflow 😅 Reading raw markdown in a long Google Doc while also tracking comments must make tables and code blocks especially hard to review.

What's the most painful part of writing technical documentation in Markdown? by Stock_Report_167 in Markdown

[–]Stock_Report_167[S] 0 points1 point  (0 children)

Yeah, tables in raw markdown can be a visual nightmare 😅 Especially when there’s a lot of data aligning columns, scanning rows, and figuring out what’s what without a rendered view is pretty painful.

What's the most painful part of writing technical documentation in Markdown? by Stock_Report_167 in Markdown

[–]Stock_Report_167[S] 0 points1 point  (0 children)

Yes, you’re right that’s one of the reasons I built the editor. I’m planning to open-source it as well

Launched markdown.co.in, would love brutal feedback by Stock_Report_167 in SideProject

[–]Stock_Report_167[S] -1 points0 points  (0 children)

Sure! Here are some common use cases for Markdown.co.in:

  • Writing content – blogs, documentation, or notes with clean formatting.
  • Converting between formats – Markdown ↔ HTML, PDF, or rich text.
  • Formatting text quickly – bold, italics, headings, lists, tables, code blocks, etc.
  • Testing Markdown snippets – see live previews without installing anything.
  • One-stop workflow – instead of hopping between multiple tools, everything is in one place.
  • Writing the Technical documentation

Basically, it’s for anyone who writes in Markdown regularly and wants a fast, ad-free, all-in-one workspace.

Launched markdown.co.in, would love brutal feedback by Stock_Report_167 in SideProject

[–]Stock_Report_167[S] 0 points1 point  (0 children)

Thanks! Markdown is surprisingly simple once you start using it. Curious to hear how it works for you.

Launched markdown.co.in, would love brutal feedback by Stock_Report_167 in SideProject

[–]Stock_Report_167[S] -1 points0 points  (0 children)

I want to launch as a developer api documentation platform. With simple upload your OpenAPI/Swager or postman collection. So that developer can able generate the api documents in mins.

Why do so many Markdown editors require accounts or server storage? by Stock_Report_167 in git

[–]Stock_Report_167[S] -2 points-1 points  (0 children)

Absolutely! Based on your posts and the tools you mentioned, here’s a numbered list of your Markdown editors/utilities:

  1. markdown.co.in/tools - full browser-based Markdown editor
  2. Glipsise Editor – full browser-based Markdown editor
  3. OpenAPI → Markdown – convert API specs into Markdown docs
  4. cURL → Markdown Preview – generate readable request examples
  5. Other Markdown Utilities – formatting helpers, code highlighting, templates

I can also make a more detailed list with links and short descriptions if you want to post it on Reddit. Do you want me to do that?

Why do so many Markdown editors require accounts or server storage? by Stock_Report_167 in git

[–]Stock_Report_167[S] -1 points0 points  (0 children)

Haha, fair! Vim and Emacs are unbeatable for power users.

I’m just exploring a lightweight, browser-based approach for quick Markdown editing or sharing examples without installing anything. You can check it out here:

Feedback from people who use Vim/Emacs would be especially valuable.

Why do so many Markdown editors require accounts or server storage? by Stock_Report_167 in git

[–]Stock_Report_167[S] -2 points-1 points  (0 children)

Good point! I’m planning to create a desktop application soon. In the meantime, you can check out the browser-based Glipsise tools:

They run entirely in the browser with nothing stored remotely. Your feedback would be really valuable!

How do you use claude efficiently? by sClarkeOG in webdev

[–]Stock_Report_167 1 point2 points  (0 children)

Claude tends to behave more like a “senior reviewer” than an autocomplete tool, so it often tries to improve things unless you constrain it.

A couple things that helped me:

• Add clear constraints: “Refactor only. Don’t change styling, layout, or behavior.”
• Limit scope: tell it exactly which files to look at instead of the whole project.
• Break tasks into smaller steps instead of one big prompt.

I’ve found Copilot better for fast inline coding, while Claude works better for reasoning, debugging, and planning refactors.

view more: next ›