On 1/22/21 10:22 PM, Michael Uplawski wrote:
> Good morning
Hi,
> I discovered again what made me fall foul of Arachnophilia and
> might be my problem with downright website generators: Psychology.
> I am initially overwhelmed with all the functionality and – in the
> effort to benefit from it – the way that my actual code and the
> editor window are losing interest.
Ah. Ignore the things that you don't need. Don't try using things just
because they are there.
> When I diminish the weight of convenience functions, toolbars,
> menu-commands – e.g. by assigning keyboard-shortcuts –, in the
> end, all looks terribly like the vim-editor that I am anyway used to
> right now.
I too prefer the simplicity of vi et al. Fewer distractions on screen.
I see my code / text and know how to do the things that I want to do.
The rest of the features -- read distractions -- are out of my view and
do not bother me.
> I ventured that there must be something that appeals to die-hard
> static web-site authors and justifies the existence of so many website
> generators.
I expect it's quite similar to why I like SSIs. In a word, laziness.
> Otherwise, these people could just as well edit their pages by
> hand.
Why in the world would someone want to edit every single page on a site
that includes a given menu when adding an item to the menu? For example.
> Automation is something a creative person wants to master her-/himself,
> normally, and the reasons for replacing your own work by that of a
> software should be a valuable revelation to me.
I want automation because I'm lazy and don't want to make the same edit
to hundreds of pages.
> If there is no such argument, and I am confirmed in the end that
> nothing of this is worth an effort, what rests is a déja-vu: Learning
> the conventions of a helper-program – or downright markdown-syntax,
> like in current CMS – is preferred over learning basic HTML. This
> may appear natural to some, it does not to me.
I supported a site that used a static site generator years ago. At it's
heart it behaved much like make. If a source file that a given page
used was updated, the static site generator would re-generate the page.
So when you added an item to the menu, all pages that included that menu
would automatically be updated. The static site generator went through
the pages making the edits in bulk and then optionally uploaded the new
pages to the web server.
I use SSI to do quite similar, save for the fact that it's one on the
server and on the fly.
Insert old comment about fried (on demand) vs baked (ahead of time)
websites. SSI is fried. SSG is baked. With SSI, the web server needs
to do some amount of work when serving the pages. With SSG, the web
server simply needs to read the page from disk and serve it out the
network. SSG is less overhead on the web server.
> I am still open for suggestions. ;)
Many fat / heavy Content Management Systems are extremely dynamic and
typically pull content from a database. As such, CMSs tend to be quite
heavy weight on a web server.
SSI is read this page from disk and write it to the network while
looking for SSI directives, if / when an SSI directive is found, read
that page from disk and write it to the network while looking for SSI
directives in it. Rinse, lather, and repeat.
SSG is read this page from disk and write it to the network. Done. End
of story.
Static sites are how a 486 with 32 MB of memory could serve up hundreds
of sites / thousands of pages. You might think that this isn't
important now, but it does take time to process SSI and CMS. So, static
sites can be served slightly faster than SSI or CMS. Is the difference
enough to matter? I don't know. That's up to you.
> TY anyway
¯\_(ツ)_/¯
To each their own.