So, About That Official Blog...

[Nick Sabalausky via Digitalmars-d]

On 05/06/2016 03:48 AM, maik klein wrote:
> On Friday, 6 May 2016 at 03:01:07 UTC, Dicebot wrote:
>> On 05/06/2016 04:26 AM, Jack Stouffer wrote:
>>> Also, I can just include a simple JS library for the same
>>> auto-highlighting functionality.
>>
>> Please prefer static generators and pygment-like highlighters to JS
>> whenever possible. Demanding JS enabled for simple programming blog to
>> be rendered decently it simply outrageous.
>
> I would also recommend a static site generator, I currently use Hugo
> https://gohugo.io/ though it is written it Go haha. Jekyll got really
> slow after 30 blog entries, especially if you want to do the syntax
> highlighting offline.

I've been moving the direction of hybrid approaches. Kinda like static 
site generating, but the regenerating is done automatically as-needed, 
can receive updates via HTTP GET/POST and do other real-time processing 
during certain requests, etc. I don't know much about off-the-shelf 
website tools out there (or whether there are any that work this way), 
but it's what I did for the travis d compiler list ( 
https://semitwist.com/travis-d-compilers ):

It's fully dynamic templated, driven by Vibe.d and a database, new 
entires are added automatically via HTTP POST, etc, it has REAL 
server-side logic running. But instead of regenerating the HTML page on 
every request (or dynamically regenerating a JSON/XML description of the 
data on every request for client-side JS to then render - an approach I 
never really understood), the Vibe.d-based site simply regenerates a 
static HTML page when the *data* changes, which on most web pages is 
much less frequent than actual page requests.

There are other ways to adjust static/dynamic balances too. There's 
usually a LOT of components on even a fully-dynamic page that ARE 
pre-cachable, even if the page as a whole isn't:

For example, a classic case where a static site generator wouldn't work: 
An online shopping search results page. You can't predict ahead of time 
what queries will be run and pregenerate entire results pages, but you 
CAN pregenerate divs for how each individual item will be displayed when 
it does appear in someone's results page. Then when someone runs a 
search you just write the appropriate pre-built divs to the output 
stream, one after the other.

In short: Hybrid site generating :) Only generate on-the-fly what NEEDS 
to be on-the-fly. Only regenerate things when they change, not every 
time they're viewed (unless they change more than they're viewed, like 
maybe an admin-only site webstats page, but such cases are rare).