On 19 May 2014 19:58, Ken Mankoff <mank...@gmail.com> wrote:
> Jr works by having javascript render the markdown to HTML. That is, you
> write markdown, upload markdown w/o running a generator, and the
> generator runs in the browser of the viewer.
>
> This is efficient for the server (simpler pages) and author (no need to
> run a static site generator), but may be globally inefficient for a
> popular site (many browser doing rendering).
I'd phrase this point more strongly:
The whole concept of intensive client-side rendering
is fashionable, but an eminently bad idea from a
number of perspectives.
I ran my list past Ken and he encouraged me to post them (thanks), so here goes:
1) UX:
Rendering in the browser's rendering engine is always faster than
rendering in JS and then in the browser's rendering engine. Speed
matters.
2) Engineering ("l'art pour l'art"):
Not caching the most eminently cacheable thing on Earth, the rendering
of static web pages, makes baby Dijkstra cry.
3) Economics (egoistical):
Search engines are optimized for interpreting and presenting HTML. If
you want to be found, have your content in HTML.
4) Economics (global):
Electricity ain't free; why spend it many times over even if it's not
you doing the spending?
5) Ecology
There are impacts to wasting power beyond its monetary price.
----
So, enough with the criticism. How to constructively approach this?
If the size difference between HTML and MD makes a difference for
your bandwidth cost, maybe consider just precompressing your files
offline (this, too, can be done prior to uploading…) and teaching your
web server that for files x.html, deliver x.html.gz as a pre
compressed stream first if available.
Cheers, Bernd
