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?
315 karma · joined May 17, 2023
I’m building something in this space and I’m curious what’s the appeal of the former vs the latter?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
Either way, seems like I'll have to check out Obsidian.
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.
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
How does it differ from Obsidian? Out of curiosity.
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.
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).
- 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.
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.
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.