arek_nawo

Are you looking specifically for Markdown or e.g. a WYSIWYG with Markdown shortcuts support?

I’m building something in this space and I’m curious what’s the appeal of the former vs the latter?

I'm working on something similar (i.e. a content editor for developers) with Vrite, that's already open-source: https://github.com/vriteio/vrite

It's not the same as acreom (leaning more towards a CMS-like platform with API, real-time collab, etc.), but is well-suited for e.g. creating knowledge bases.

Why is it a "huge asterisk"?

I'm also working on a WYSIWYG editor and using TipTap. It's great, but on its own, it's not a ready editor, but a great framework.

There's a lot you can do with TipTap (and ProseMirror) to make your editor stand out and fit your use case better than others.

MDX, with the custom content involved, is though. I've been working on a hybrid WYSIWYG editor for MDX at Vrite (https://vrite.io).

Currently supports custom block elements and JSON-serializable attributes. Now looking into inline content and building an extension system to render custom previews for the nodes.

Check it out if you're interested - it's also open-source.

I want to think of marketing as a way of providing valuable content and explaining why your product might be just what the consumer needs (potentially helping them with their problems).

What's described above really doesn't fit into this view, but is definitely how I've seen people "play the game". ChatGPT-generated fluff, copied content, and the same tips & tricks, inspirational stories, etc. you see repurposed all the time on different platforms - especially LinkedIn.

I hope marketing can be good and value-adding but, the way it's going right now, we're due for a change.

Happy to see the SIM card go away. eSIM provides just so much better experience.

This also enables easier installation and setup for basically any carrier. Just download the app, configure eSIM and you're good. Maybe the easier switching is why adoption is kind-of slow on the carrier side? Easier to keep you locked-in with more obstacles in place.

Seen some comments mention potential issues with it vs physical SIM, but I hope these get resolved with time or standard solutions are developed. Personally I had no issues with it, using it for over 2 years now.

I've seen quite a few Postman alternatives pop up recently (quite curious what's the reasoning behind that?). Currently I'm mostly using Hoppscotch - also open-source with pretty sweet UI, and Thunder Client in VS Code.

That said, I'd consider switching for type-safety (or more specifically auto-completion) if there was an ability to e.g. import existing OpenAPI schema and automatically pick up the types.

Love it! Good looking, polished UI. I'm probably most impressed by the easy integration and React API. Congrats.

Pretty cool.

I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely beneficial for web development.

Not the "JavaScript killer" some where hoping for, though it was never meant to be one. Instead it integrates pretty nicely within the existing ecosystem, optimizing existing use-cases and allowing new ones when heavy computations are required. Net benefit for all web devs - faster libraries, impressive dev tools and more portable node binaries.

I think I remember seeing this (or a similar thing) in Solid.js Playground: https://playground.solidjs.com/

The fact that it’s available on mobile and that it allows for “embedding” a good-enough dev tools into your web app, does enable interesting use-cases.

Of course, it’s not the go-to for complex or extended debugging sessions but still impressive.

Also fair points :)

I think it all depends on the project’s scale, type (is it part of your infrastructure like a database or all-in-one solution like a CMS, etc.), goals and other factors.

It’s difficult to make the right choice at the very start, as something that might have worked then might not work when you’re at a scale of competing with AWS.

Thanks for clarifying. I should indeed explain better what I had in mind.

You are correct that under AGPL-3.0 people still can provide the software as a service, but they’ll have to disclose any changes to the source code they’ve made.

This, in my mind, effectively discourages doing so as, if all you do is change the branding, people will eventually know and, depending on their ethics and the provided offering, they might choose not to use the “official” service.

In theory people still could distribute the product as-is or just be fine with the open-sourcing and actually add something of value to their fork. However, as I’ve seen in practice, this doesn’t seem to happen at a meaningful scale and people usually prefer to contribute directly to the original project.

Like you’ve said, there are other licenses that aren’t really open-source, prohibiting this from happening at all.

Most interesting options from these, for me, were SSPL (which puts the open-sourcing requirement on other elements of your stack, like hosting provider, making it a non-starter), or ELv2 (which just prohibits SaaS use entirely).

But again, not being recognized as official open-source licenses, using these puts the project more in the camp of source-available software rather than open-source.

So true. I have no problem with using and paying for a hosted, "cloud" version of the product if a self-hosting option is available. It reassures me that I can rely on this product, while not being vendor-locked.

I've certainly seen many different licenses used in COSS projects, including different mixes of them. E.g.: for my latest project I've decided to use mainly AGPL-3.0 (a pretty strong copyleft license) with specific parts licensed under MIT.

That said, my goal wasn't to limit the usage, but to be open-source, and provide self-hosting option (the 2 fundamental advantages you can provide to your users by being open-source, IMHO), while making sure nobody just runs the product on their servers, rebrands it, and sells it to others as a service (which, while possible with other licenses, is simply unethical in my book).

The site looks good. On a side-note, it’s really great to see that more and more Comercial OSS and other open-source projects become viable businesses. I think this is one of the best way to actually make open-source sustainable.

Not yet. That’s in the pipeline.

Vrite as a whole can be referred to as a headless CMS, though it’s different compared to other tools in this category.

Essentially it’s a toolkit intended primarily for technical content (like programming blogs or docs), with multiple features in one:

- WYSIWYG editor focused on good UI/UX (including good support for code), and collaboration;

- Kanban dashboard (and other views in the future) for managing the content and its production process; Especially useful for larger teams;

- The “headless CMS” part for hosting and delivering content and related assets; This includes API and Extension system; (in the future planned additions are asset optimization and Git integration)

So, tl;dr; it’s a lot more than the mention tools and I’m still looking for a way to categorize it clearly.

Not yet, but if you like what you see and would like to see the diagrams added, please open an issue or discussion on GitHub. This will help manage things better.

In this case, yeah. That's not my goal. However, if a "raw" preview in MD (or other format) is available and editable), plus maybe a Git integration then I think this could be on a compareable level.

Either way, seems like I'll have to check out Obsidian.

The main output is JSON ProseMirror format. Other formats are processed from this JSON using Transformers and Vrite SDK: https://github.com/vriteio/vrite/tree/main/packages/sdk/java...

In the GFM transformer I try to follow GitHub Flavored Markdown spec, which technically doesn't support embeds. Since I didn't find any "common" syntax to use for the embeds, I just left them out. They're still there in JSON and HTML outputs.

That's one of the drawbacks of MD. That said, I plan to add an option like Markdoc, which has clearly defined spec for implementing custom blocks like embeds.

That said, for now, if you sign up for the full Vrite CMS, you can create a custom Transformer and process the output so that embeds are included in your desired format. That's what I'm doing for auto-publishing extensions for platforms like Dev.to and Hashnode. I don't know what your use-case is, but I thought it's worth noting.

TipTap is built on ProseMirror. Basic elements of the editor are made in TipTap, while for more advanced use (tables, menus, integrating code editor) I had to tap into ProseMirror.

I'm not really familiar with Milkdown so I can't say.

The entirety of Vrite is open-source under AGPL-3.0 license (with parts under MIT): https://github.com/vriteio/vrite

I'm a bit confused about that. I have heard of but haven't really tried Obsidian. How does what you're describing differs from so-called "Markdown shortcuts" (implemented in my editor and other popular ones like Notion)? You can type in most inline markdown and it's automatically converted to WYSIWYG-styled text. All these shortcuts are described here: https://docs.vrite.io/content-editor

How does it differ from Obsidian? Out of curiosity.

That's so true! I have a really hard time categorising what Vrite Editor, let alone the entire Vrite is. I can't really describe it in detail as it'd be too long and, to keep it short, some messaging is lost in the process. "WYSIWYG Markdown editor", "headless CMS for technical content" are just some of my latest tries. I think I'm getting better at it, but it's not easy.

I can see how this would be useful, though there are some options already available that can do that, e.g. Editor.js or BlockNote.js.

Vrite's goal is to be more like a self-hostable writing platform/tool, so making the editor into custom element isn't really on the roadmap. If anything, it would be embeddable but not customizable, which limits possible use-cases.

Yeah, generic embeds aren't allowed - only CodePen, CodeSandbox, and YouTube. In Vrite, all the embeds are actually processed separately when auto-publishing to different platforms (e.g. Medium, Dev.to, Hashnode), that's why I don't want to allow generic iframes.

That said, I do plan to add some more embeds to the core (e.g. Twitter) but others will likely be supported through custom content blocks and extensions.

That said, definitely report any feedback or feature request you have (if not as an issue then possibly as a discussion).

- I don't quite understand what "metadata" you're referring to?

- Makes sense. These are the kind of edge cases to figure out with special blocks like code. In theory, the selection you have before enter is a block selection, which would usually remove the block when anything is inserted (enter is specifically handled to move focus to the code editor). Will consider making other characters do the same.

I'd like to encourage you to check out Vrite as a whole. I'm actively working on this to make it better for documentation and knowledge base management. Good UI and UX are among my top priorities.

There's already Kanban for better management of content production process and I'd say the editor is comparable to Outline. Other views and more editor features are on the way.

Still, as I'm updating it almost daily, self-hosting isn't easy right now. I plan to have a stable version sometime in Q3 of this year, with self-hosting and more features so keep an eye out on that if you're interested.

If you decide to sign up for Vrite, it provides a JSON output accessible through the API. You can then process it to any format you want using JS SDK and Transformers.

MDX doesn't make a lot of sense though as, with the supported features, it's basically the same as pure MD. That said, custom content blocks are in the pipeline and once that's added, MDX, MarkDoc and other formats will work really nicely with Vrite.