I like dev.to's markdown editor and especially the variety of the liquid tags it provides, so I usually start my articles in their markdown editor until completion and use that same text on my website's editor.
To get almost like results as on dev.to I updated my site's markdown editor to include Front matter support and on top of it I added a couple of liquid tags I frequently use on my dev.to posts.
Yeah, I also find the liquid tags as the best way for Markdown embeds. I don’t agree on the Dev.to editor though. It’s just a plain <textarea>. Liquid tags are part of the supported syntax / format - not the editor per se.
In CodeWrite I support Markdown as input rules - i.e. they’re directly converted to rich, formatted content. I also support a syntax similar to liquid tags, which also automatically converts to interactive WYSIWYG embeds.
All this results in semantic HTML which can then be processed for Dev.to, Hashnode and Medium compatibility and auto-filling.
Planned support for direct Markdown exports and GitHub pages auto-filling is intended to allow for different Markdown output formats e.g. using liquid tags for embeds vs normal links, or underscores vs asterisks. I want CodeWrite to become a true “write once publish everywhere” tool which won’t require any copy-pasting and will automatically deal with platform incompatibilities.
I know that dev.to's editor is a plain textarea, the editor I created is also not an editor per se, it's just a plain textarea. I implemented it this way since I prefer doing the heavy lifting on the back-end rather than at the front-end level.
It's the same reason why I'm not a big fan of the WYSIWYG Javascript editors that I have been using for quite a while on other projects.
I like creating things on my own since it helps me understand what goes on underneath the tools I use and overall it helps me grow as a developer.
All the best with CodeWrite, it sounds like a interesting editor and one that I might enjoy using since it goes beyond being just an editor with the “write once publish everywhere” philosophy, that will sit well with people who cross-post their content like me.
If you are interested to have a look I wrote the following article explaining these changes I made to my editor.
Thanks!
I've checked out your blog post - a nice guide for anyone "sourcing" their personal blogs from Dev.to - I've seen it's being done a lot lately. I personally run my blog on Ghost, so, for me, Dev.to is yet another platform to cross-post to.
As for creating projects on your own - I know how it is, I guess most devs do. For me, that's where my piles of (mostly unfinished) side projects come from. 😅
If you end up giving CW a try, check out the auto-filling (on Medium) demo tweet, and join the Discord server if you've got any questions.
CodeWrite
@codewriteio
Improve your code-blogging experience on Medium with CodeWrite. Great editor, and auto-filling with built-in GitHub Gist code conversions and handling of incompatible formatting! All for just $3/month🤗 codewrite.io#webdev#100DaysOfCode#programming#blogging#VSCode
I like dev.to's markdown editor and especially the variety of the liquid tags it provides, so I usually start my articles in their markdown editor until completion and use that same text on my website's editor.
To get almost like results as on dev.to I updated my site's markdown editor to include Front matter support and on top of it I added a couple of liquid tags I frequently use on my dev.to posts.
Yeah, I also find the liquid tags as the best way for Markdown embeds. I don’t agree on the Dev.to editor though. It’s just a plain
<textarea>. Liquid tags are part of the supported syntax / format - not the editor per se.In CodeWrite I support Markdown as input rules - i.e. they’re directly converted to rich, formatted content. I also support a syntax similar to liquid tags, which also automatically converts to interactive WYSIWYG embeds.
All this results in semantic HTML which can then be processed for Dev.to, Hashnode and Medium compatibility and auto-filling.
Planned support for direct Markdown exports and GitHub pages auto-filling is intended to allow for different Markdown output formats e.g. using liquid tags for embeds vs normal links, or underscores vs asterisks. I want CodeWrite to become a true “write once publish everywhere” tool which won’t require any copy-pasting and will automatically deal with platform incompatibilities.
I know that dev.to's editor is a plain textarea, the editor I created is also not an editor per se, it's just a plain textarea. I implemented it this way since I prefer doing the heavy lifting on the back-end rather than at the front-end level.
It's the same reason why I'm not a big fan of the WYSIWYG Javascript editors that I have been using for quite a while on other projects.
I like creating things on my own since it helps me understand what goes on underneath the tools I use and overall it helps me grow as a developer.
All the best with CodeWrite, it sounds like a interesting editor and one that I might enjoy using since it goes beyond being just an editor with the “write once publish everywhere” philosophy, that will sit well with people who cross-post their content like me.
If you are interested to have a look I wrote the following article explaining these changes I made to my editor.
Use Custom Liquid Tags and Highlight Code Blocks in Your Blog
James Sinkala ・ Apr 4 ・ 6 min read
Thanks!
I've checked out your blog post - a nice guide for anyone "sourcing" their personal blogs from Dev.to - I've seen it's being done a lot lately. I personally run my blog on Ghost, so, for me, Dev.to is yet another platform to cross-post to.
As for creating projects on your own - I know how it is, I guess most devs do. For me, that's where my piles of (mostly unfinished) side projects come from. 😅
If you end up giving CW a try, check out the auto-filling (on Medium) demo tweet, and join the Discord server if you've got any questions.
I guess unfinished side projects are a common thing amongst devs 😅.
Hopefully I'll get to give CodeWrite a try in the future, all the best adding the support to the remaining platforms on its roadmap.