My first impression was that we have moved from "what is that markup doing in my code?" to "why is my code scattered over all these tags?" Then I scrambled back to Introducing the Marko Tags API Preview to get a better sense of this effort's vision. Once I got a twinkle of an insight my first compulsion was to introduce this refactoring:

<!-- file: TodoStore.marko -->
import {
  updateTodo,
  clearCompleted,
  removeTodo,
  toggleAllTo,
  addTodo,
} from './store';

<let/nextId=1/>
<let/todos=[]/>
<let/filter="all"/>

<return = {
  todos,
  filter,
  setFilter(f) {
    filter = f;
  },
  updateTodo(todoId, newProps) {
    todos = updateTodo(todos, todoId, newProps);
  },
  clearCompleted() {
    todos = clearCompleted(todos);
  },
  removeTodo(todoId) {
    todos = removeTodo(todos, todoId);
  },
  toggleAllTodosCompleted(completed) {
    todos = toggleAllTo(todos, completed);
  },
  addNewTodo(todoData) {
    todos = addTodo(todos, nextId++, todoData);
  }
}/>

// file: store.js
function updateTodo(todos, todoId, newProps) {
  return todos.map(updateProps);

  function updateProps(todo) {
    return todo.id !== todoId ? todo : { ...todo, ...newProps };
  }
}

const keepActive = (todo) => !todo.completed;

function clearCompleted(todos) {
  return todos.filter(keepActive);
}

function removeTodo(todos, todoId) {
  return todos.filter(keepOthers);

  function keepOthers(todo) {
    return todo.id !== todoId;
  }
}

function toggleAllTo(todos, completed) {
  return todos.map(syncCompleted);

  function syncCompleted(todo) {
    return todo.completed === completed ? todo : { ...todo, completed };
  }
}

function addTodo(todos, id, { title }) {
  return [
    ...todos,
    {
      title,
      id: 'c' + id.toString(),
      completed: false,
    },
  ];
}

export { updateTodo, clearCompleted, removeTodo, toggleAllTo, addTodo };

This brings me to my concern which is expressed in UI as an Afterthought (and by extension Architecture the Lost Years ):

State is the root of all revenue.

Or put differently: Why is my core client-side application logic complected with the UI (framework)?

Now obviously the lets and return are necessary for the reactive system to track connections and dependencies — however the role of templates is to express structure via containment (and substitution), not interfaces for internal application communication and collaboration. On a different level while the UI depends on parts of application state, managing application state isn't its responsibility. So while the UI needs access to application state and perhaps even manage it's own, minor derived state it shouldn't be in the business of actually managing application state.

To elaborate on my perspective:

Conflation vs Separation

I'm familiar with Plank's Principle — especially the last part:

What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning: another instance of the fact that the future lies with the youth.

The whole "innovation progresses one funeral at a time" perspective is often used to dismiss established insights justifying "out with the old, in with the new" failing to account for the fact that so called "innovations" have to stand the test of time to retain that title.

I believe one could make a convincing case that the introduction of JSX wasn't an "innovation" but in fact a regression. Even the Vue documentation perpetuates the faulty assumption that its premise is based on:

One important thing to note is that separation of concerns is not equal to separation of file types.

It never was about the separation of file types. Typically at this point I go into the how the separation relates to the web's approach to fault tolerance and resilience - however in this context it's not relevant as the compiler can be used to ensure the necessary post-compile separation.

The Vue documentation goes then further to claim:

In modern UI development, we have found that instead of dividing the codebase into three huge layers that interweave with one another, it makes much more sense to divide them into loosely-coupled components and compose them. Inside a component, its template, logic and styles are inherently coupled, and collocating them actually makes the component more cohesive and maintainable.

It's this type of argument that managed to get object-orientation programming into the mainstream - but over that past decade or so the cracks in that argument have become more and more noticeable. The argument has an undeniable allure which often enough fuels the popularity of the approach which in turn is then fielded as evidence of the original argument's validity.

Apart from failing to correctly identify the original motives behind the "separation of file types" it also doesn't address additional motivations in favour of maintaining separation deemed beneficial by practitioners:

• Separating behavior and structure Peter-Paul Koch, 2004 inspired by Unobstrusive DHTML Stuart Langridge, 2002
• Behavioral Separation Jeremy Keith, 2006

Ultimately this was popularized as Unobstrusive JavaScript. In retrospect that moniker was unfortunate because it made it all too simple to dismiss it as irrelevant in the age of CSR frameworks which operate entirely in JavaScript. But that unjustifiably dismisses the core tenet and the benefits of:

    Separation of behaviour and structure

One may also be tempted to defend the likes of Vue and Svelte because internally (single file) components do have "separation of behaviour and structure" because markup and behaviour exist in separate sections - but ultimately that separation is meaningless as all of that simply compiles to pure conflated client-side JavaScript rather than generating server-side code capable of emitting fully formed markup that can smoothly rendezvous client-side with the JavaScript necessary for interactivity.

In terms of metaphor's one can look towards printing and graphical design. Their artefacts are often authored and produced in layers - often necessitating the use of registration marks to ensure correct alignment during production.

Similarly structure and behaviour are separate layers that have to be "in alignment".

It is easier, at least in the small, to conflate structure and behaviour because there are no "registration marks" to keep track of - however the component approach makes one fundamental assumption - that structural and behavioural boundaries coincide.

The simple approach keeps things separate and boundaries may or may not coincide - it just doesn't matter.

One blatant example of "boundary ambiguity" is a list; <ul>/<ol> vs <li>. List elements and list item elements are separate tags but are tightly coupled given that:

• List elements should only have list item elements as direct child elements and
• List item elements should only have a list element as their direct parent

That coupling could indicate that both <ul> and <li> should be both managed by the "List component" and that there is no need for an "Item Component" as that responsibility is covered by the "List Component".

At the same time there could be an argument that there can be behavioural aspects of a list item component that are more related to it being an "item" rather than being part of (and being positioned within) a list - at which point part of the <li> behaviour resides with the "List Component" while the remainder resides with a "List Item Component". Consequently the "behavioural boundary" doesn't occur cleanly between the "List Element" and <li> but right on top of the <li> element (unless one moves the "item" role to the child element which doesn't necessarily make semantic sense).

Inline event handlers to EventTarget.addEventListener() was an early move towards better separation of behaviour and structure.

One issue here from the structural (HTML) perspective is that there is no indication when and where added behaviour can be expected. This is exacerbated by the fact that there are no clear "registration marks" for any behaviour as the implementation could target a specific element through the rather broad means of any type of selector, e.g. by ID, Class or any other prominent feature in the overall document structure.

Contrast this with the clear separation of data and structure in a template, for example, in Nunjucks:

var tmpl = new nunjucks.Template('Hello {{ username }}');

tmpl.render({ username: "James" }); // -> "Hello James"

• At template design time the data's identity is clear as well the location(s) where it will be injected
• At runtime the context (data) object is only concerned with mapping data values to the correct data identities independently of how that data may structured for display inside the template.

In their own way the double braces and variable names act as registration marks between the structural layer (template) and the data layer (context object).

Supporting a looping construct makes sense for supporting structural repetition; similarly conditional structures; perhaps even parametric structures;

That doesn't mean that Nunjucks (or Jinja) is some kind of gold standard. It (and many other templating languages) offers filters. In the context of their domain this makes sense as there is no behavioural layer.

Templates are primarily crafted to transform data structured for information processing to data structured for display. In the absence of a dedicated behavioural layer it is an accepted trade-off to conflate (some minor) data conversion within the structural template while accepting the consequence of increased complexity of the of the templating system — rather than forcing the wholesale adoption of a "to display data" transformation layer for all templates.

However introduction of any minor conflation is often just the "thin edge of the wedge" of which PHP serves as a historical example:

… and I tried to convince people that you should write the business logic in C and use my templating system, … Nobody agreed with me. Everybody just wanted to write their business logic in the templating system and it was very discouraging to me for years … Eventually I had to sort of give in and say, OK, fine, yes, …

In many ways the same thing has happened with JSX; people liked it because it's easy even though it conflates matters; JSX elements are neither markup nor DOM elements but are simply a representation of a component instance's position in the component tree (for better or worse).

CommitStrip

@commitstrip

A theory about PHP
commitstrip.com/2021/02/03/a-t…

18:11 PM - 03 Feb 2021

Many attempts at humour have a kernel of truth to them.

In the presence of a behavioural layer it makes sense to not support data conversion inside the structural layer (template) but instead delegate it to the behavioural layer even if this leads to the introduction of "template adaptors" which are solely responsible for the conversion of "behavioural data/types" to "structural (display) data/types" (and vice versa).

Conflation also makes tooling more complicated. Server-side markup is all about "strings". Typically optimal server-side performance is achieved by pre-compiling templates to functions that transform their inputs into markup via extremely optimized string concatenation. Similarly because HTML is text-oriented the majority of DOM properties are string based. As a result the benefits of "typing" templates should be minimal given that the majority of data handled is string based anyway. Along comes JSX introducing an "XML-like syntax to ECMAScript":

• Unlike HTML, ECMAScript is typed (even if it is dynamically typed)
• Unlike HTML, XML can be typed, though of course that isn't the style of typing JSX uses.

… all for the sake of replacing

ReactDOM.render(
  React.createElement(
  React.Fragment,
    null,
    React.createElement('div', null),
    React.createElement('div', null)
  ),
  document.getElementById('root')
);

or

import { createElement as h, Fragment } from 'react'

ReactDOM.render(
  h(
    Fragment,
    null,
    h('div', null),
    h('div', null)
  ),
  document.getElementById('root')
);

with

ReactDOM.render(
  <>
    <div></div>
    <div></div>
  </>,
  document.getElementById('root')
);

… just because it's easier on the eyes?

When TypeScript gained popularity (for better or worse) JSX increased the burden of adoption that either the "enthusiasts" or the tooling ecosystem had to somehow bear (including popular IDEs — though there is an entirely separate conversation lurking there).

So when I saw TodoStore.marko the first thought that went through my mind was:

How is ESLint going to get at this code, what new rules will be required …

where the typical answer is more plugins, loaders, etc. The point is that this type of conflation tends to act as a deterrent to adoption as it doesn't fit into existing workflows and necessitates the creation of additional complex tooling, potentially redirecting effort that could be spent more constructively elsewhere.

Keeping things separate usually means that existing tooling can still be leveraged to maximum effect. For example, before Svelte supported Typescript OOB it was still possible to simply move any component code that Svelte didn't have to be aware of out into a standard module which could then be processed as per usual by the standard tool chain (and micro-tested) — if one was so inclined.

I'm well aware of the Priority of Constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

The way I see it, preferring separation over conflation isn't a case of preferring purity over practicality but choosing simplicity over easiness. While separation in the short term may create authoring inconveniences it should on the whole lead to "parts" that are internally simpler which interact with one another in much simpler ways, reducing system complexity and requiring less complex tooling (leaving more room to invest complexity in other, higher value avenues).

In some ways the current obsession in the web industry with short term DX (and how it's perceived to improve productivity) parallels the development process indulgences prior to the agile manifesto — in particular:

Working software over comprehensive documentation

i.e. the additional complexity cost of some forms of DX needs to be carefully assessed against the potential (opportunity) cost on the UX end (and in terms of long term maintainability) — I believe the myth of the "trickle-down economics" from DX to UX has been well and truly debunked. Without that kind of assessment DX efforts often are more about "press of a button, comfy chair development" rather than improving (long-term) product quality.

Thanks for this helpful step-by-step code with familiar TodoMVC example. This makes it much easier for me to get familiar and play around with Marko new tags API 👍 I was surprised that you can't mix it with the old <if()>, or maybe I did something wrong with my code 😅

Anyhow, I have some questions.

On the example, you use Marko component for the TodoStore. Is it possible to replace TodoStore.marko with just JS? Not sure if you implement the store as a Marko component just for an example, or it's a must in order to make it work.

Another thing, how can we lint JS code inside Marko template, do we have eslint plugin for Marko? My impression with Marko Tags API that it seems we are putting more and more JS code inside the template. Without linting tool, it would be harder to know if there's syntax error on the code. It seems Marko compiler can catch some but maybe you know better tool to handle this problem.

Thanks!