AsciiDoc (AD) being one of the easiest ways to write rich-text markups as plaintext sources, we see a trend of bloggers moving to AD-based platforms rather than HTML-based ones. This brings the great advantage of ubiquitous blogging, as the hand-typed source can often be published without additional formatting, in addition to the elimination of most of the "garbage" HTML introduced by rich-text editors.
Unfortunately, since browsers understand only HTML, viewing the blog ultimately requires conversion of the aforementioned AD source to HTML at some point. Existing AD blogging platforms do this on server-side, meaning that what you ultimately receive on the browser is not AD but bloated-up HTML.
Given the widespread support for Javascript in almost all modern browsers, we can instead load the AD source directly on the client side, and parse it into HTML using Javascript. In addition to reducing the loading overhead, this eliminates the need for a dedicated backend or a conversion process for transforming the publisher-submitted AD content to HTML.
As none of the existing platforms seemed to support this client-side blog parsing ability, I decided to implement a simple PoC on my own. You can clone it from here and try it out.
In order to publish a blog post using it, you can simply upload the AD source to the hosted content location and update menu.json to include the new post (the entry key and value set to the relative path and title of the post respectively). Thereafter, when the root page (index.html) is loaded in a browser, a list of articles (defined in menu.json) will be displayed, and clicking on an article name would result in the AD source being fetched, parsed to HTML, and displayed in the post viewer. Of course, the tool requires a good touch of styling and 'landscaping' (layout changes) before it can take the shape of an appealing blog.
The app is completely driven by JS, including the parsing of fetched articles. AD parsing is achieved through a custom-made JS library (as the official AsciiDoctor.js library is still fairly bulky) that covers only a commonly-used subset of the AD spec; e.g. it does not currently support tables or [NOTE] fragments. Suggestions and improvements are always welcome, given that they maintain the simplicity and streaming (line-by-line parsing) nature of existing code.
I'm not entirely sure of how this type of dynamic rendering would affect SEO; unless the search engine is really intelligent, it will probably not be able to dynamically load and index the articles. Hence if you are looking for SEO or article visibility, this might not be the best option for you. Anyway, I'm soon going to try it out on my own soon, and I'll keep you posted regarding my progress, at least with the Almighty Google Bot.
No comments:
Post a Comment