I'm iffy on this kind of thing. Markdown has the advantage of looking roughly like what you'd do in plain text and is completely readable in plain text with no processing. It also has the advantage of being nearly standard; it is used on thousands of sites, including some very large ones (e.g. reddit, github, etc.). If I wanted my users to memorize HTML tags I would have just gone with HTML.
This seems to have the negatives of both Markdown and HTML, and no unique advantages over either. It's a little less verbose than HTML, but you have to know HTML tags (and Sundown syntax) to use it, and I have my doubts it can avoid the quirks Markdown has because converting any "friendly" markup to a formal syntax like HTML is always prone to quirks. It has the alleged advantage over Markdown of being able to use HTML and Sundown together...but, some Markdown processors also allow mixing MD and HTML, so this is not a unique benefit (this is quirky in Markdown, but I suspect it's quirky in Sundown, too).
Maybe I'm missing the benefit here, but it seems like a technical solution to a people problem, and that almost never works.
Also, as an aside, it's got the same name as a Markdown processor that is even mentioned in the article! That seems bound to cause confusion, given the similarities in purpose.
Comparing this to markdown just seems completely off the, er, mark. It's more like a simplified version of HTML, which has been done many times before, e.g. https://github.com/padolsey/SIML
And then call your new tag using the HTML syntax or Sundown:
<note>Sundown is awesome ;)</note>
:note Sundown is awesome :)
Result:
<div style="color:red">Note: Sundown is awesome :)!!</div>
Sundown is just an HTML preprocessor (like Markdown) once it is transformed to HTML it's the SunSed language that compiles all the custom HTML tags to executable format.
I can see the use case you're going for. As others have mentioned though, this value is not coming as an alternative to markdown but rather an enhancement to HTML in a different use case.
Feels kind of like Sundown:HTML::SCSS:CSS. If you can communicate this (vs being an improvement on markdown), you'll probably get people to take a closer look.
Honestly I see no reason to even mention markdown. Sundown really has nothing to do with it. Just state why it's an improvement over HTML in various scenarios.
... which makes Markdown even _less_ like your software. Also less relevant to marketing efforts as people up-thread are saying. Some of the use-cases that you're covering with your software were never covered by Markdown, nor were they ever intended to be use-cases for Markdown. So you're not going to find people that are currently using Markdown that will need Sundown for those use-cases.
This makes it very different from Markdown to the point of it not making sense to compare the two, I think. Markdown is not a programming language or a template language (though people often overlay some sort of template processing after processing the Markdown into HTML in order to apply styles to the resulting HTML, e.g. for many static site generators this is the case...but the Markdown processor has no knowledge of that or concern for it).
I feel like this is more much comparable to, as others note, something like Jade/Pug, than Markdown. And, it may be a very good competitor to those sorts of tools, I dunno.
Seems like Sundown is a programmers tool; Markdown is an end user tool (often used by programmers in contexts where they don't want to program, like commenting on forums and tickets and such). But, I guess they are all just taking some sort of input and spitting out some HTML. It just seems like Markdown isn't the right thing to compare it to.
Yeah, I was also confused by using a project that's been unmaintained for several years as the pinnacle of Markdown performance, but I have never once thought about the performance of Markdown parsers (I can imagine someone on the scale of reddit or github would care about performance of the MD parser, but I never have for my projects) so I don't know enough to argue about whether performance has improved since then.
At SunSed we provide a cloud IDE to our users so they can easily update their website. Every time they make a change the IDE automatically saves the file and on the server we had to compile Markdown -> HTML+SunSed(custom HTML tags) -> Executable. Not to mention bulk website upload, backups and restores (a website could have thousands of pages). Markdown was the slowest part with the most resource usage.
I actually bench marked all of the Markdown implementatinos back in 2016 (or early 2017). https://github.com/vmg/sundown was by far the fastest!
Aside from the difference in syntax (which is huge), I would say convenience.
SunSed = Hosting + IDE + CDN + a new programming language + Layout and Template system (like Jekyll and Hugo) + Many built-in tags to abstract things like embedding Youtube videos in a responsive way (which is not easy -- requires so many div wrappers).
You can also create your own tags and share it with others. I have started the process of creating tags for useful and popular libraries:
If you know HTML, you already know the syntax of SunSed programming language, and can create fast dynamic websites with ease by abstracting your website content in custom HTML tags!
After all, SunSed is a programmable website builder.
I think when people are saying, “why not use X?” They mean, why not adopt X as your templating language system integrated into SunSed, instead of making your own.
I am fine with a new markup if it's quick and to the point. I believe that we need to give the markdown/reStructuredText things a fresh look. At the very least, we may come up with ideas to improve existing languages.
Are you planning on opening the source to Sundown? What's the current implementation running in? (golang, python, c, etc?)
Some of the other commenters are mentioning markdown being fast. This is probably true. Since there are processors for markdown in C. Actually, when I first glanced the title, I thought it was https://github.com/vmg/sundown.
In any event, that's just a naming issue. The bigger point is, I think the overall project at SunSed looks pretty cool. Simple markup turns into a nice website. Congratulations on having the website up!
> Are you planning on opening the source to Sundown?
Sundown is just a HTML preprocessor implemented in a few lines of regular expressions! I actually planned to open source it before writing the article but did not have the time.
However, I'm not planning on open sourcing the SunSed language compiler (the part that allows you to create custom html tags). But I will open source all the tags and libraries here:
Markdown is being critized because it doesn't allow markdown syntax within HTML blocks, and because the HTML vocabulary recognized isn't customizable. Both problems were basically solved by SGML over 30 years ago.
In SGML, you can define arbitrary tokens (character sequences) that the parser replaces into something else, typically into start-element or end-element tags. Replacement text rules are defined in a context-sensitive way depending on the parent element wherein token(s) to replace appear as child content. For example, an asterisk could be mapped to <i>, and within an <i> element could be mapped to </i>, terminating it, and thereby implementing a small fragment of markdown.
This, together with tag omission/inference rules on a fully custom DTD vocabulary powerful to cover HTML5, gives you quite a formidable technique for markdown customization, based on an ISO standard.
He specifically addresses the name too, in the article, maybe he doesn't realize the confusion:
Solution[0] = "A good name"
First, I cameup with "SML" (SunSed Markup Language) but eventually decided to go with "Sundown" (SunSed Markdown) because it's a cooler name that almost describes itself.
You are right about the name confusion! It has been several years since the last commit to the /vmg/sundown and even if it was active it's not a very common Markdown implementation (although it's one of the best).
> even if it was active it's not a very common Markdown implementation
First, even if this was true, it's still _not_ OK to name your project Sundown.
Second, _my_ Sundown is the most used Markdown engine in the world. It has powered all Markdown rendering in GitHub.com and Reddit.com for more than 5 years, and it has rendered billions more documents than all other Markdown parsers out there.
Could you please not be an asshole and rename your project? It's really not that hard to come up with a name for a parser. Don't steal mine.
> ... create a platform that makes it super easy for developers to create awesome websites without forcing them to learn new stuff (language, syntax, platform, framework and more)
And yet:
> I explain what was wrong with Markdown and why I finally had to create my own Markdown alternative
I do not think a new, custom HTML template language solves the original goal.
SunSed is for developers with HTML knowledge. You can use SunSed language to create custom HTML tags (abstract HTML, CSS and JavaScript) and then Sundown to abstract your HTML.
I think Sundown is very easy to learn and SunSed language has very little learning curve because it follows the exact syntax of HTML:
I already answered this. Let me copy and paste it from my other comment:
Aside from the difference in syntax (which is huge), I would say convenience.
SunSed = Hosting + IDE + CDN + a new programming language + Layout and Template system (like Jekyll and Hugo) + Many built-in tags to abstract things like embedding Youtube videos in a responsive way (which is not easy -- requires so many div wrappers).
You can also create your own tags and share it with others. I have started the process of creating tags for useful and popular libraries:
If you know HTML, you already know the syntax of SunSed programming language, and can create fast dynamic websites with ease by abstracting your website content in custom HTML tags!
After all, SunSed is a programmable website builder.
I think there's lots of opportunity for a markdown alternative, but I worry that this starts in the wrong place. It seems like it's built around code, whereas Markdown is built around writing.
A friend of mine who works at a newspaper noted that it was really hard to get a lot of people in the mindset of Markdown, because it requires users to think about their writing in terms of HTML, which is harder than it sounds for some. This seems like it pushes things further in a direction where people who aren't code-savvy can't get on board.
The other thing to keep in mind: The reason why Markdown is great is because it's readable even without being rendered. This is not, because it simplifies the HTML without abstracting it. That's a tough hurdle to get past for a lot of folks.
I don't think his point was that Markdown even sucks. I think, rather, it's that a lot of people don't know HTML and find rich text much more intuitive, despite its weaknesses. It's sort of the 90/10 rule; Word is good for 90 percent of people, but the other 10 percent are driven nuts by it.
Great solution. Given the problem statements that lead to this, i was pleasantly surprised by the elegance of the syntax.
There are the obvious arguments about plain-text readability and additional standards, I would suggest thinking about this not as a Markdown replacement but rather a different use-case entirely. I understand the author framed it as a replacement. While that may have been the impetus to the project, i think the result is something entirely it's own.
Markdown has a place when a document stands to be published/shared in multiple formats. I use it regularly for blog posts that i also email to others for feedback in plaintext. Sundown looks to me like a light-weight, text-focused haml. Usable when something is intended to only be published in HTML, but where you want to be freed from that markup.
> I would suggest thinking about this not as a Markdown replacement but rather a different use-case entirely.
You are right! I'm thinking about the same thing here! I could even give it no name and instead present it as part of the SunSed programming language (the part that lets you create custom HTML tags).
The post just seems like a verbose post hoc justification for wanting to reinvent something. Which is fine, a lot of good learning comes out these toy domain languages. I just don't see any technical benefits or conceptual leaps here other than to say "I built this".
It's like back in the day when someone would proclaim smarty to be a disaster and then release their template system that was conceptually exactly the same baring some syntactic sugar
> A lot of good learning comes out these toy domain languages.
I agree with the learning part but SunSed is not a toy language. I could be wrong about how valuable it's going to be but it's definitely more than a toy.
Sundown is a very simple preprocessor that plays well with the SunSed language. With SunSed, you can create your own HTML tags (that run server-side) and abstract HTML, CSS and JavaScript.
Sundown is just the icing on the cake that lets you easily use your custom tags. SunSed language is a complete programming language, you can checkout the tags here:
> Our promise to you ul.[sic] We are dedicated to supporting our products forever (or until the last customer turns off the lights). ul.[sic] If we create a new version of SunSed that breaks backward compatibility we will support the older version forever. p.[sic]
Started reading with interest, but then everything started to look really similar to HAML [0] after a bit. With the exception that HAML also lets you add CSS classes to your tags...
As a product marketer, I have to say that the name is very unfortunate.
1. Sundown is the name of a Markdown library written in C: https://github.com/vmg/sundown. That Sundown is pretty widely known and used among Markdown implementers. As such, when/if the OP's project takes off, it is going to be confusing (for awhile).
2. Also, the name itself doesn't strongly suggest that it's an alternative to Markdown. Do recall that Markdown's etymology comes from "(HTML) markup". For the Markdown-implemented-in-C Sundown, the name worked because it evoked its relationship with Markdown. In this case, that's not what the project is about. If the intention was to evoke Markdown, then they should have kept the "Mark" part of it, not the "down" part of it.
This looks very promising. While I do not see this as a replacement for Markdown this has some potential for use cases where Markdown is less suitable, like messaging.
The explicit use of the colon makes things a bit saner for users - we’ve all written some ‘unexpected’ markdown before; between the many different flavors (especially line breaking behavior), numerous symbols, and numerous ways to do the same thing (like underlining, bullet points and images). I can see this being a big relief for end-users for certain use-cases.
I’d love to try it out if I could see some source code (or a live demo I don’t have to sign up for). Do you plan on setting up a specification?
> I feel like Jeff Atwood and his friends abandoned the Commonmark project that tried to create a universal specification of Markdown. Even if they did, I don't think that Github, Stackoverflow, Reddit and other major Markdown users would ever convert.
Came here to say that. Also Discourse just moved to a CommonMark compliant markdown parser this release, so between GitHub and Discourse the user base is already huge.
I really like it. I was just thinking of writing a markdown to custom HTML parser for my own needs and found markdown syntax to be lacking to express my HTML tags.
I can choose SunDown format for it.
Do you have a parser that converts SunDown to HTML already?
I can build it as my first project in Rust while attempting to learn it.
> for my own needs and found markdown syntax to be lacking to express my HTML tags
This is a little strange tbh. The majority of markdown parsers will allow inline html elements too.
If you're trying to do a large structured document, which will need block specific styling, try Pug. (Formerly Jade.) HAML & Slim also solve similar problems and have the benefit of a pretty significant userbase. (All support embedded Markdown)
Sundown is looking very much like a naive and poorly thought out also ran.
I don’t think this feels like it’s solving any problems that Markdown isn’t already solving. If I’m reading it right, I have to do all this just for some italics?
: There is some <i>italic</i> text in this line.
This is seven more characters than the equivalent Markdown! And two more than the equivalent HTML. And includes at least five characters that are a bitch to type on most screen keyboards.
You are absolutely right! There is a trade-off. Some tags are easier in Markdown (e.g. bold, italic, inline code and a few others). But you cannot extend markdown with your own custom elements can you?
Sundown by itself is not that useful. It gets really useful when you use it as a preprocessor for your own custom HTML tags.
Here I explain how you can create your own server-side HTML tags:
This seems to be aiming for completely different goals though.
People use markdown as a text and word formatting system that is readable in plain text and easily transforms into HTML.
The the main point you are driving to people in this thread are the custom tags which goes against the plain text readability and adds extra complexity in this scope. You are competing against HTML preprocessors that are primarily used for that reason - to be converted into fully fledged HTML. Markdown is not in this scope by any means.
This is fine, but isn’t really an alternative to markdown. It’s not good for what markdown is good for, which is writing and reading plain text that can also be transformed to HTML.
It looks like it’s an alternate syntax for HTML angle-bracket tags. (Personally, I see no value in that. I can see it’s arguably “cleaner”-looking, but not by much and at the substantial cost of a non-standard syntax.)
I'm not sure the world needs a new markup syntax, especially an awkward mix of HTML and Markdown. But I could be missing the point, since I just base this on my own needs.
But thing is, talking about performance and scale goes exactly against your project's credibility. These are pretty much the two dumbest criterias when it comes to markup syntaxes.
FYI: I've started work on an alternative to markdown called texti (text with instructions). It's really more of an evolution e.g. some deletions, some additions, some changes. See some examples at the project site - https://texti.github.io
Some feedback: As someone who types 30 articles in Markdown per week, # is the deal breaker for me here. It's at a spot on the keyboard that is easy to type. The = sign is not. You should consider a symbol on the left side of the keyboard that is easy to reach. The equals sign just doesn't encourage the kind of muscle memory that the hashtag does.
There are some good ideas here, though. I would like to suggest that there has to be a good way to implement class and id tags in a language like this. That is the only real issue I have with the Markdown spec.
Thanks for your feedback. Greatly appreciated. The reason for `=` is to welcome the Wikipedia writer crowd and `#` in the unix world is always used for comments (and "classic" markdown has no comments). What's a human writer-friendly markup convention without comments? Anyways, thanks again for your comments.
Just because someone is going to link it, I might as well do it first: https://xkcd.com/927/
But yeah, "Too many implementations of Markdown" is not an issue a new markup language is going to solve.
"Markdown is slow!" is nonsensical: its implementations are slow (it seems the author tested this, but the link supposed to supply evidence doesn't -- I find it hard to believe that aren't fast implementations of Markdown, but perhaps). Nothing in the language makes it inherently slow.
> cmark can render a Markdown version of War and Peace in the blink of an eye (127 milliseconds on a ten year old laptop, vs. 100-400 milliseconds for an eye blink). In our benchmarks, cmark is 10,000 times faster than the original Markdown.pl, and on par with the very fastest available Markdown processors.
Definitely. I worked for a while on a Markdown-based CMS. Markdown renderers vary widely in performance, probably because a) it's pretty easy to write a basic renderer, and b) performance doesn't matter for many use cases. But I did a bake-off, found some decently fast ones, and was confident they could be made faster if it mattered.
The HTML part of this spec is strange. Most of the practical point of markdown has been to allow a limited set of user-controlled formatting without requiring an HTML parser in the browser. Furthermore, HTML has non-significant whitespace whereas markdown does, so mixing the two will give weird results.
This doesn't seem to solve any issues that markdown has and also fails to see how fast most modern Markdown implementations are. Using an unmaintaned 5 year old perl script for benchmarking is ignorant.
I remember when I moved off Wordpress to Jekyll, all my Wordpress stuff was in Textile using a Textile plugin. When I migrated off, I used a plugin that ran everything through the HTML rendered and exported it.
My new stuff is in Kramdown, and my old stuff is HTML with some Jekyll headers at the top. I did have to go back through some of it and clean it up too.
If I move to something new, I'd just render everything I have with Kramdown into HTML and move on to the next thing.
That's sadly how we have to deal with these engines.
I liked jade but stopped using because of jsx, and disliking having to research solutions during unique use cases. I also have learned markdown fairly quickly, and like it more now, but I personally don’t think it is as good of an experience reading plain text files as my own “plain text hacks” that I would use to format docs destined to be read in plain text. I feel that it clutters a nicely organized personal note, which adds to mental overhead.
Does anyone think that there should be an alternative to markdown with a more natural syntax, that is text first? Something that is meant to be viewed in plain text most of the time, looks good in text, and easy to type in text, and has nice syntax highlighting.
Markdown isn't very aesthetically pleasing in plain text IMO. It's awkward to type, and it doesn't handle indenting the way people would normally create lists and indents in text. (## H2, ### H3 .. really??)
I thought this is the famous Markdown parser by Vicent Martí. [1] It was the most popular Markdown implementation before CommonMark, and is used by GitHub (via RedCarpet, its Ruby binding) before they switch to CommonMark a while ago. The name choice is a bit unfortunate, but I guess it’s too late to change it now.
It's a classic problem with markdown: it's a minimal markup language, which is ok for comments and super simple documents, but requires extensions for pretty much anything else.
This is why every week you see a new markdown implementation which is just ever-so-slightly different than the other, with every service and tool implementing it's own. I dread markdown, because I know there will be extensions. And the extension syntax doesn't look nice/simple. Syntactically, asciidoc or rst is much more thought-of than any markdown-like syntax I've seen.
This is also the main reason I really discourage markdown for anything but a comment system. Just start with something more complete if you plan on documentation.
I was strongly against md on the documentation for julia for exactly these reasons. Not even one year later, md in julia is already contains extensions which are oh-just-very-similar-to-but-not-quite the others.
Edit: you've continued to post uncivil/unsubstantive comments for quite a while now. We ban accounts that do that. If you can't or won't fix this, we're going to ban you, so please fix this.
This seems to have the negatives of both Markdown and HTML, and no unique advantages over either. It's a little less verbose than HTML, but you have to know HTML tags (and Sundown syntax) to use it, and I have my doubts it can avoid the quirks Markdown has because converting any "friendly" markup to a formal syntax like HTML is always prone to quirks. It has the alleged advantage over Markdown of being able to use HTML and Sundown together...but, some Markdown processors also allow mixing MD and HTML, so this is not a unique benefit (this is quirky in Markdown, but I suspect it's quirky in Sundown, too).
Maybe I'm missing the benefit here, but it seems like a technical solution to a people problem, and that almost never works.
Also, as an aside, it's got the same name as a Markdown processor that is even mentioned in the article! That seems bound to cause confusion, given the similarities in purpose.