XHP templates in Hack wind up being really nice, letting you create composable XML tags, defining attribute types, etc. And they look a lot like JSX, except with extending classes. I suppose that counts as an "internal DSL."

    //<csrf-form>(...)</csrf-form>
    class :csrf-form extends :x:element {
      attribute :form;
      use XHPHelpers;

      protected function Render(): XHPRoot
      {
          $token=get_csrf_token();

          return <form>
            <input type="hidden" name="token" value={$token}/>
              {$this->getChildren()}
          </form>;
      }
    }

More boilerplate than Twig, but no string concatenation.

  DSL stands for Domain Specific Language. In our story, the
  DSL is HTML. An internal DSL refers to the host programming 
  language’s ability to express that DSL using just the host
  language (with no string building).

  One could argue that Internal DSLs are not really a separate
  technique from #2 (Tree Building) and #3 (Templates). In fact, 
  internal DSLs could be described as a less-crappy tree building
  API. Or as a templating language that is more integral to the
  host language.
  But I think the technique is different enough to deserve it’s own category.

This person is describing Lisp, and I'm flummoxed that they do not appear to be aware of Lisp, given that it is an area where it is so strong! I think both Arc and Closure have the ability to describe HTML documents in lists (I can't remember if it's as s-expressions, or lists of functions).

EDIT: I just noticed that they reference Om :) Never mind!

  (defun button-bar (name)
    (let ((i 0))
      (with-html-output (*page*)
        (:div
         (do-query (button-name)
           (select [button-name]
                   :from [tools]
                   :where [= [bar] name])
           (htm (:button
                 (format nil "~@r. ~a" (incf i) button-name))))))))

"One could argue that Internal DSLs are not really a separate technique from #2 (Tree Building) and #3 (Templates)"

JSX doesn't strike me as that much different from JSP. It's still mixing markup and code together.

There's another #4. That was Apple's WebObjects. WebObjects was unique in that it provided bindings between the two languages. In one file, you have HTML, in another, you have Java. Then in a third, the .WOD file, you had bindings between the two.

The HTML was really XHTML with one extra tag, the webobject tag, and it had one name attribute. Nothing new to learn there.

<webobject name="NameFromHTML"/>

The java file was just a java object that implemented the WOComponent class.

public class WOComponentClassName extends WOComponent {...}

The WOD bound the two together like

NameFromHTML : WOComponentClassName { key1 = value1; }

If you needed to reuse a chunk, you could just reference it twice with another <webobject name="NameFromHTML"/>.

Then at runtime, the webobjects application read in the html templates, and associated the key with a WOComponent getter/setter or field, and the value was either hard coded, or came from the java component as well.

HTML templates quickly boiled down to a handful of <webobject> tags. You could express entire, complex pages with just a few tags.

Later on, developers with bad habits tried to add in things they were familiar with from other lesser solutions. WebObjects slowly degenerated into something that looked more like JSP with bindings being set inline in the html, executable binding values with OGNL, the whole works. It turned something beautiful and still more advanced than any template language in use today, into your standard template language garbage pile.

It's fortunate that server side rendering went out of fashion, Apple promptly dropped support, and WebObjects was allowed to die a somewhat dignified death in obscurity.

Ugh, that's what lisp solves for, that's why folks rave about lisp macros, and prolog solves that too with it's DCG.

If not using those, don't use languages to generate HTML, hand craft it, same with SQL, don't use ORMs, hand craft it.

> OK. Maybe not 80%. Maybe 50%. It’s hard to say.

Saying it's 80% in the headline then immediately saying it might be 50% is clickbaity.