Create a New Content Compiler Using Hestia Library

[hollowaykeanho]

Description

Please provide a short description of what feature you're looking forward to
add into the existing repository below. Please include the story behind your
idea as well to give a better visualization of your idea.

Currently, Hugo has been a burden for sanitizing data and formulating content page data structure to the point hestiaHUGO theme module has to pick up some of the work. Due to this, the entire theme module is slowing down to the point where millisecond tasks becomes minute. That's not acceptable.

Since most of the data computing efforts was mainly due to to hugo's intercommunications efforts, we will have to produce a new content compiler someday, where we can also implement no-code feature if possible (See Issue #5).

Expected Behavior

Please specify the expected behavior of your requested feature. Some great and
helpful pointers are your expected interface (e.g. command patterns, simple
sketches of the user interface, etc).

A new independent content compiler is built and re-use hestiaHUGO theme module if possible.

Current Absent Behavior

Please specify the current behavior (e.g. workaround, blockage, etc).

Using hugo with hestiaHUGO theme module is too slow.

Attachment

Please drag and drop the necessary data files (e.g. screenshot, logs, etc)
below.

[hollowaykeanho]

Removed wish list because the current Hugo design can't handle more than >10 pages (~5mins) in a very short time mainly caused by the string data type integrity initialization. We have to develop a new compiler to get rid all redundant safety checking and enforce hestia's page data structure in the content compiler.

[hollowaykeanho]

Confirmed.. Unless we do not want to comply to new standards (e.g. PWA, WASM, thumbnails, favicons generator, etc.), we don't have a choice. For now, we will tolerate with Hugo's overdrive until hestiaGO and hestiaRUST achieve usable states for development.

[hollowaykeanho]

Removed criticality since the hestiaHUGO had been completely refactored for performance gain. Commit: a90901d9b7535c1c9caeb0f28fa8fe909383b5cd

Mainly caused by recursive scan of PWA's cache data files; and sitemap.xml and 404.html hugo native generators.

Perfromance improved from ~5mins compilation to ~32s. metric-stage-0.ods metric-stage-1.ods metric-stage-1.txt

[hollowaykeanho]

Further reduces down to ~30s with 7ce088a6c342bc9b79877f837ffb4602a8b8b16a. Optimization arrived at maturity. Back to development. metric-stage-2.ods metric-stage-2.txt metric-stage-3.ods metric-stage-3.txt

[hollowaykeanho]

Further reduced to pinpoint page oriented changes from ~30s down to the usual <5s timeline.

Hugo is still usable so we will be using it.

Among the changes:

1. Ditched every hugo features (multiple output formats, shortcodes, etc etc). Only use the very basic functions like those version <50 ones. Those were the cause of the major delays for every recompilations.

metric-stage-4.ods metric-stage-4.txt

[hollowaykeanho]

Commit: 28e01114feadd8adb79c973d43d09ce2e3c4c0e4