From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernd Haug Subject: Re: Org based websites w/o export Date: Tue, 20 May 2014 13:43:20 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmiSO-0006pQ-DB for emacs-orgmode@gnu.org; Tue, 20 May 2014 07:43:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmiSM-0000hq-Is for emacs-orgmode@gnu.org; Tue, 20 May 2014 07:43:44 -0400 Received: from mail-ve0-x232.google.com ([2607:f8b0:400c:c01::232]:60604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmiSM-0000hg-Ba for emacs-orgmode@gnu.org; Tue, 20 May 2014 07:43:42 -0400 Received: by mail-ve0-f178.google.com with SMTP id sa20so414267veb.37 for ; Tue, 20 May 2014 04:43:40 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode list On 19 May 2014 19:58, Ken Mankoff 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=E2=80=A6) and teaching y= our web server that for files x.html, deliver x.html.gz as a pre compressed stream first if available. Cheers, Bernd