Hacker News Reader

Comment by snarfy | Hacker News Reader

> <div data-query="each(products)">

Well, one problem is declarative programming has never been as expressive as imperative programming. In React you'd use JavaScript for this iteration. This is why I like React over say Angular, with ng-each, ng-if, etc. Flow control does not belong in markup. I cringed the first time I saw an XML schema with an IF element.

View on HN

Flow control does not belong in markup.

My favourite templating system is enlive[1] (or enliven[2]). You use CSS-style selectors to select snippets of HTML to manipulate and then use code to duplicate, remove, move or replace these snippets, insert content, set attributes etc.

The "template" is pure HTML without any additional markup and without any logic. The code then says "repeat this snippet for every item in this list and insert it over there" (or whatever you need). Markup does what its good at, code does what its good at. Works out really nicely.

Although nowadays I use reagent and hiccup-style markup and write everything in code (but keep my components as pure and dumb as possible).

[1] https://github.com/cgrand/enlive

[2] https://github.com/cgrand/enliven

What do you think about OneScript - https://github.com/astoilkov/OneScript?

Can't say I'm a fan honestly. Reminds me too much of PHP, I guess.

The thing about reagent/hiccup is that the markup is just a clojurescript data structure and can be composed and manipulated like one. This also means that you can easily write pure functions to generate the UI (data in, markup out).

The thing about enlive/enliven is that the markup and the logic are completely separated.

OneScript has neither of the things that I like about enlive or reagent.

EDIT: I should probably add that I'm not particularly a fan of JSX either, so I'm probably the wrong person to ask for an opinion on this.

How do the frontenders and CSS folk feel about you making assumptions about what CSS selectors there should be in order to render a template on the backend? Its hard enough to get dedicated frontend folk to stick to an adaptable/maintainable CSS architecture like SUITCSS, let alone backenders too. I've always thought Enlive seems to create a brittle co-dependency between frontend and backend codebases, ok for small projects with 1 or 2 devs with skills that span front and backend, but surely a nightmare for larger project with lots of people working on them?

Genshi [1] is (was?) wonderful in a similar respect. Although the "code" was itself an html document, it allows master templates to fully select and manipulate nodes from child templates.

[1] http://genshi.edgewall.org/

In the beginning we mixed style with content. Now we're mixing logic which, IMO, is an even worst mistake.

I would argue that React is a declarative style as well, the difference between it and the above example being that JS is far more expressive than HTML.

You are right. Flow control does not belong in markup. But what if I redefined the logic and called them instead relationships.

Could relationships be declared in markup? Could behaviors be declared in markup? Then we would expect the browser and the script to play with the relationships according to the behaviors.

The other-side of the argument is that JavaScript is much harder to tool than HTML.

If I heard such statement in a debate I would stress that word harder.

A lot of stupid arguments in your message, the biggest being :

> Well, one problem is declarative programming has never been as expressive as imperative programming

Haskell is declarative, are you saying Haskell isn't expressive ?

> Flow control does not belong in markup

> In React you'd use JavaScript for this iteration

There is no flow control in HTML , but some frameworks use DSLs in the HTML. If you are saying frameworks shouldn't be using DSLs yet you praise React which uses JSX which contains a declarative DSL in form of XML markup ... your point is a big contradiction.

    <div data-query="each(products)"> ... </div>

The React (or Mithril, or Mercury, or other virtual DOM libraries - just change the function being called) equivalent would be:

    products.map(product => React.createElement('div', null, ... ))

Which you can use JSX (again in any virtual DOM library, via Babel) to sugar as:

    products.map(product => <div> ... </div>)

The flow control is outside the DSL, not part of it.

A DSL for logic inside of a declarative markup language is very different from a DSL for declarative markup inside a programming language.

Reply on news.ycombinator.com