top | item 40141980

Show HN: Podlite - a lightweight markup language for organizing knowledge

142 points| zagap | 1 year ago |podlite.org

Unbound by any specific domain, programming language, or concept, Podlite stands out as a universal markup language

In addition, the support for Markdown markup as a standard block adds convenience and allows for the use of familiar syntax for text formatting

It's perfect for documentation, educational materials, blogging, and much more for organizing knowledge.

One of the key features of Podlite is its extensibility. This allows for defining unique and domain-specific blocks and expanding the language's functionality according to the requirements of your project.

The Podlite specification is published under the Artistic license 2.0.

Site: https://podlite.org Thank You!

47 comments

order

bachmeier|1 year ago

While I think this is worth exploring, at a certain point you end up doing so much that you could just write raw HTML, and then you'd have the advantage of being able to display it directly in the browser and using Javascript's powerful querying features.

zagap|1 year ago

Good question!

To meet modern requirements and make documents dynamic, we need a flexible API and integration with contemporary frameworks. Simple HTML just isn't up to the task. Although this was the approach during the early implementation (https://github.com/zag/js-pod6), it turned out to be a dead end.

thank you

kkfx|1 year ago

Please, anytime you try to imitate parts of org-mode, consider org-mode, markup and abilities.

exe34|1 year ago

I had all kinds of plans for my knowledge management for over a decade. Then I started using org-roam and now the activation energy to consider anything else is so high that I'm stuck in a local minimum.

lyu07282|1 year ago

also if you find yourself inventing a new complex syntax for yet another markup language... consider doing something else instead

WA|1 year ago

What's the main advantage over AsciiDoc?

Although it's already on your roadmap, but it definitely needs more complex examples. Fiddled around a bit with links to same-doc references. Got it to work, but took a while.

asystole|1 year ago

I'm still upset that Markdown ended up getting all the mindshare. AsciiDoc is so much nicer.

chj|1 year ago

Isn't it the way perl scripts write their documentation? I don't know what makes it good for personal knowledge systems from reading the introduction

apgwoz|1 year ago

Perl's POD, yes. But you're right! The spec authors are Perl folx, and this is clearly derivative. What's kind of interesting is that POD stands for "Plain Old Documentation" and then there's a "lite" version of it... so "lite-r Plain Old Documentation" --- I don't see a clear summary of the differences, though.

ThinkBeat|1 year ago

Reading through the source for the specifications was interesitng. There is a lot of good stuff here, but there is so much to learn but I dont see enough benefits to push me to learn it when I already have Latex,Markdown and straight HTML in my toolbox.

I would like to be proven wrong though.

PixelEngineer|1 year ago

Podlite indeed looks promising, especially with its extensibility and support for Markdown. I agree that if a markup language gets too complex, using raw HTML might be more advantageous. However, I think the strength of Podlite lies in its universality and flexibility, allowing it to adapt to various project requirements.

I'm particularly interested in the extensibility of Podlite. This feature allows the language's functionality to be expanded according to the specific needs of a project, which could be a huge plus in many cases. I look forward to seeing how Podlite evolves.

As for using raw HTML and JavaScript, while they indeed provide powerful querying features, Podlite might be simpler and more intuitive for those who are not familiar with these technologies. I think that's another strength of Podlite.

All in all, I think Podlite is a project worth watching. I'll keep an eye on its progress and look forward to seeing what changes it can bring in the future. Thanks for sharing this project!

fabianholzer|1 year ago

Interesting approach.

I would love to have a notation to get a various ways of representing of intellectual tasks into a single document. A real killer feature in my eyes would be if a kind of umbrella markup language would support a convenient two-way binding for creating and manipulating notations, so for example that diagrams could not only be rendered in a desktop app, but also be manipulated with the markup being automatically being updated. I guess the problem is that light-weight implies too little structure to make such a thing easy to implement...

john2095|1 year ago

I think you've lost the point of Markdown: it's readable as raw text.

I was excited that this was an extension of markdown but now I that see it I react with horror: markdown is not a programming language. This looks rather like a programming language.

randomguid|1 year ago

Wow. This is so good. For reference: It is 4 times smaller than HTML. It is 29.5 times smaller than PDF. It has a really good structure and is more readable than Markdown (sometimes).

alexisread|1 year ago

Looks nice, I have a couple of questions:

Does this use a single pass for the parser? Is there an EBNF spec? What sort of diagrams does it support?

Thanks

zagap|1 year ago

The existing typescript implemetation builds a complete AST (Abstract Syntax Tree), over which middlewares are run in several passes. Yes, there are multiple passes over the tree. This is necessary, among other things, to build a table of contents (TOC). thank you

pixelcodev|1 year ago

Hey, I'm Lee! I like this, nice work! :)

TrueDuality|1 year ago

Ouch. IMHO the reason markdown became so popular is because how simple it is, how well the syntax generally stays out of the way of the content, and its almost entire lack of mixing formatting with document structure.

This is VERY heavy, and VERY invasive. The entire lack of opinion in "use whatever markup you like as long as its wrapped in our markup" seems like an extra awful complication. I'd be curious to hear about what concrete problems the authors of this spec were trying to solve and why they went so far.

the_real_cher|1 year ago

I thought the same thing when I saw the example page. Its closer to html than markdown.

dash2|1 year ago

Damian Conway… a name to conjure with.

What are the advantages of the Podlite design?

zagap|1 year ago

It's extensible and not tied to any specific programming language, allowing for constructs like this ( mix chunks of markdown and build TOC ):

---

=toc head1, head2, head3

=begin markdown

  # header from markdown
  ## second level
  
 =end markdown
 
 =head1 This is header from Podlite 
---

https://pod6.in/#p=%3Dtoc+head1%2C+head2%2C+head3%0A%0A%3Dbe...