DEV Community

Cover image for Taking Marko's Tags API for a Test Drive
Ryan Carniato for This is Learning

Posted on

Taking Marko's Tags API for a Test Drive

Marko recently released a preview for its upcoming Tags API. This is pretty exciting as it adds a minimal API layer over Marko's state management that allows us to express complicated ideas in a more terse way than ever before.

So what's a good place to start. Well, I looked at Marko's TodoMVC example and decided it needed sprucing up. So this simple list managing example feels like the perfect place to get started and introduce this new approach.

In this article, we will build a TodoMVC application using Marko's Tags API. So let's get started.


Setting up our project

It's easy to get set up with a new Marko project using the Tags API.

> npm init marko --template tags-api
Enter fullscreen mode Exit fullscreen mode

It prompts us to name the project and gives instructions to get started.

Alt Text

Next, let's open our project in our code editor. I am using VSCode. And we see a simple folder structure.

Alt Text

We are going to keep this folder structure for our TodoMVC app but we will be replacing all the code. Before that, if you want to run npm run dev to see this example open in your browser.

Remove all the files under the src/pages and src/components folders and then we are good to get started with a clean slate.


Building our Page

Marko is a Multi-Page Framework but TodoMVC is a simple single-page example. We won't worry too much about that since our starter project here will take care of all the details. So we start the same as any application and our index page. Create a index.marko file under your src/pages folder.

Let's add some markup to it. .marko files are basically HTML documents so to start we just add the following:

<!doctype HTML>
<html lang="en">
  <head>
    <meta charset="UTF-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
    <meta name="description" content="Marko TodoMVC"/>
    <title>Marko - TodoMVC</title>
  </head>
  <body>
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

And there we have a working app. Just run npm run dev and you should see a blank page with a title. You could add as much markup you want to this page. But let's add our first components.


Creating a Store

TodoMVC is driven off a central store very much in line with Model View Controller from which it gets its name. In our case, Marko isn't an MVC framework but it still makes it easiest to abstract our logic into a template that we will use as a data store.

Create TodoStore.marko under components folder and copy in this code:

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

<return={
  todos,
  filter,
  setFilter(f) { filter = f },
  updateTodo(todoId, newProps) {
    todos = todos.map(function(todo) {
      if (todo.id !== todoId) return todo;
      return { ...todo, ...newProps }
    })
  },
  clearCompleted() {
    todos = todos.filter(function(todo) {
      return !todo.completed;
    });
  },
  removeTodo(todoId) {
    todos = todos.filter(function(todo) {
      return todo.id !== todoId;
    });
  },
  toggleAllTodosCompleted(completed) {
    todos = todos.map(function(todo) {
      if (todo.completed === completed) return todo;
      return { ...todo, completed };
    });
  },
  addNewTodo(todoData) {
    todos = [...todos, {
      title: todoData.title,
      id: 'c' + (nextId++),
      completed: false
    }];
  }
}/>
Enter fullscreen mode Exit fullscreen mode

There is a lot going on in this file but really we are just seeing 4 tags being used in the template. The first 3 define state in our Marko Templates using Marko's <let> tag. The <let> tag allows us to define variables in our template. In this case, an id counter, the list of todos, and a variable to hold are filter state.

This leverages Marko's tag variable syntax where we can define a variable by putting it after a slash after the tag name, and Marko's default attribute syntax that lets us pass a value without an attribute name by assigning it to the tag directly.

The <return> tag is how we expose tag variables to a parent template. We are assigning an object that contains our state and some methods to mutate that state.

This template does not render any DOM elements itself but serves as a convenient way to encapsulate the behavior we'd like to use in other templates. We will be using this to drive the rest of our application.


Creating the App

So let's start wiring this together. We're going to create a new <TodoApp> tag because I want to keep my top-level page document clean but this is completely unnecessary. So create TodoApp.marko under the components folder. Also, create a TodoHeader.marko file under the components folder as well since we will need that in a minute.

Let's start by dropping the following into TodoApp.marko:

<TodoStore/{
  todos,
  addNewTodo
}/>
<section.todoapp>
  <TodoHeader addNewTodo=addNewTodo />
  <if=todos.length>
    <section.main>
      <ul.todo-list>
        <for|todo| of=todos by=(todo => todo.id)>
          ${todo.title}
        </for>
      </ul>
    </section>
  </if>
</section>
<style>
  @import url("https://unpkg.com/todomvc-app-css@2.2.0/index.css");
</style>
Enter fullscreen mode Exit fullscreen mode

We will be coming back to this file a few times in the course of this tutorial but this is the skeleton of our app. The first tag is our <TodoStore> we created in the previous section. We can access the values returned as a tag variable we are destructuring. So far it is just the todos and addNewTodo.

This is the bulk of our template. We are including the <TodoHeader> component we are yet to implement. One of the great things about Marko is it can find tags in your local project automatically saving the need to import them.

Next, we see a conditional <if> tag that only displays the list if todos.length. Marko uses tags for control flow. These use all the same syntax and capabilities you can use in your custom tags.

Inside this block, there is also the <for> tag that iterates over our todos. Each iteration of the loop receives its values via Tag Parameters which we denote with enclosing pipes | |. This allows us to do scoped child templating similar to Render Props in React.

Finally, there is a <style> tag that imports the official TodoMVC CSS from their CDN. Marko automatically strips out the style tag out into its own .css files on build.

We can add our <TodoApp> to the body of our index.marko page and we should now see a grey background when we run it with npm run dev (you can keep this running in the background and it will refresh as we add changes).

<!doctype HTML>
<html lang="en">
  <head>
    <meta charset="UTF-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
    <meta name="description" content="Marko TodoMVC"/>
    <title>Marko - TodoMVC</title>
  </head>
  <body>
    <TodoApp />
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

Adding Todos

Right now our app doesn't do very much so let's start working on the <TodoHeader>. This is where we will enter our new Todos.

Copy this into your TodoHeader.marko file:

<attrs/{ addNewTodo } />
<header.header>
  <h1>todos</h1>
  <form onSubmit(e) {
    const titleInput = title();
    addNewTodo({ title: titleInput.value });
    titleInput.value = "";
    e.preventDefault();
  }>
    <input/title
      class="new-todo"
      placeholder="What needs to be done?"
    />
  </form>
</header>
<style>
  .header form {
    margin: 0;
  }
</style>
Enter fullscreen mode Exit fullscreen mode

The first thing you will notice is the <attr> tag. This is how we define the input that comes into our template. We passed addNewTodo in from the <TodoApp> template and now we can use destructuring to get it here.

You can see Marko's shorthand class syntax on <header.header> which applies the header class to the <header> element. From there we create a <form> with an <input>.

The tag variable on the input element returns an Element Reference Getter. This is a function that when called retrieves the native DOM reference to that tag. We use it in our Submit handler.

Marko supports a shorthand for functions that we are using here that is very similar to JavaScript object methods. This is the equivalent of assigning the function to an attribute of the same name. Our Submit handler calls the addNewTodos method from our store.

Try it in the browser. You should see a large input field, and you should be able to enter some text and click enter and see it added to our page. Right now they all just get appended in a long line of text but we will add more functionality to our Todos in the next section.

Alt Text


Making our Todos Functional

Well, it works but it ain't pretty. Let's now add our <TodoItem> component. So go ahead and add TodoItem.marko under your components folder and copy in the following.

<attrs/{ todo, updateTodo, removeTodo }/>
<let/isEditing=false />
<let/editingTitle="" />
<const/saveEdit() {
  if (isEditing) {
    const el = title();
    updateTodo(todo.id, { title: el.value });
    isEditing = false;
  }
}/>

<li
  class={ completed: todo.completed, editing: isEditing }>
  <div.view>
    <input.toggle
      type="checkbox"
      checked=todo.completed
      aria-label="Toggle todo completed"
      onChange(e) {
        var completed = e.target.checked === true;
        updateTodo(todo.id, {completed});
      }/>
    <label onDblClick() {
      isEditing = true;
      editingTitle = todo.title;
    }>
      ${todo.title}
    </label>

    <button.destroy
      onClick() { removeTodo(todo.id) }
      aria-label="Delete todo"
    />
  </div>

  <input/title
    class="edit"
    title="Enter the new todo title"
    type="text"
    value=editingTitle
    onBlur=saveEdit
    onChange=saveEdit
    onKeydown(e) {
      if (e.keyCode === 13 /* ENTER */) {
        saveEdit();
      } else if (e.keyCode === 27 /* ESC */) {
        isEditing = false;
      }
    }/>
</li>
Enter fullscreen mode Exit fullscreen mode

This is our biggest code snippet by far and it's because the Todos do a lot of stuff. You can check them, uncheck them, and double click to edit.

We are seeing the <const> tag for the first time here. It is useful for defining things in our template that do not get reassigned. In this case a function we use in multiple places. We also see nice usage of Marko's support of object syntax for applying classes.

If you add the necessary methods to the store and replace the contents of <for> in TodoApp.marko you should now have a basic working Todo application.

<TodoStore/{
  todos,
  addNewTodo,
  updateTodo,
  removeTodo
 }/>
<section.todoapp>
  <TodoHeader addNewTodo=addNewTodo />
  <if=todos.length>
    <section.main>
      <ul.todo-list>
        <for|todo| of=todos by=(todo => todo.id)>
          <TodoItem todo=todo updateTodo=updateTodo removeTodo=removeTodo />
        </for>
      </ul>
    </section>
  </if>
</section>
Enter fullscreen mode Exit fullscreen mode

Alt Text


Filtering and Other Features

We aren't quite done yet. The rest of our features are going to be focused on TodoApp.marko. First, let's add a toggle all checkbox. We need to add toggleAllTodosCompleted to our list of properties we are pulling out of <TodoStore> and then we can replace the line <section.main> tag with this.

<const/remainingCount=todos.length - todos.filter((todo) => todo.completed).length />
<section.main>
  <id/toggleId />
  <input.toggle-all
    id=toggleId
    type="checkbox"
    checked=(!remainingCount)
    onChange(e) {
      toggleAllTodosCompleted(e.target.checked);
    }>
  <label for=toggleId />
Enter fullscreen mode Exit fullscreen mode

We introduce another new tag here <id>. This one gives us a unique identifier that is stable across server and browser execution and a perfect way to create an id to link our input to its label. And now we can toggle on and off all our todos.

The last feature we need to add is filtering the list by whether they are completed or not. Instead of trying to explain I'm going to just post the final TodoApp.marko:

<TodoStore/{
  todos,
  filter,
  setFilter,
  addNewTodo,
  updateTodo,
  removeTodo,
  toggleAllTodosCompleted,
  clearCompleted
 }/>
<section.todoapp>
  <TodoHeader addNewTodo=addNewTodo />
  <if=todos.length>
    <const/remainingCount=todos.length - todos.filter((todo) => todo.completed).length />
    <const/filteredTodos = todos.filter(todo => {
      if (filter === "active") return !todo.completed;
      if (filter === "completed") return todo.completed;
      return true;
    })/>
    <const/handleFilter=((filter) => (e) => {
      setFilter(filter);
      e.preventDefault();
    })/>
    <section.main>
      <id/toggleId />
      <input.toggle-all
        id=toggleId
        type="checkbox"
        checked=(!remainingCount)
        onChange(e) {
          toggleAllTodosCompleted(e.target.checked);
        }>
      <label for=toggleId />
      <ul.todo-list>
        <for|todo| of=filteredTodos by=(todo => todo.id)>
          <TodoItem todo=todo updateTodo=updateTodo removeTodo=removeTodo />
        </for>
      </ul>
    </section>
    <footer.footer>
      <span.todo-count>
        <strong>${remainingCount}</strong> ${remainingCount > 1 ? "items" : "item"} left
      </span>
      <ul.filters>
        <li>
          <a
            href="#/"
            class={ selected: filter === "all" }
            onClick=handleFilter("all")>
            All
          </a>
        </li>
        <li>
          <a
            href="#/active"
            class={ selected: filter === "active" }
            onClick=handleFilter("active")>
            Active
          </a>
        </li>
        <li>
          <a
            href="#/completed"
            class={ selected: filter === "completed" }
            onClick=handleFilter("completed")>
            Completed
          </a>
        </li>
      </ul>
      <if=(remainingCount !== todos.length)>
        <button.clear-completed onClick=clearCompleted >
          Clear completed
        </button>
      </if>
    </footer>
  </if>
</section>

<style>
  @import url("https://unpkg.com/todomvc-app-css@2.2.0/index.css");
</style>
Enter fullscreen mode Exit fullscreen mode

No new functionality. Just builds on what we have been doing this whole time.

Alt Text


Conclusion

And that is it. We have our TodoMVC app with Marko. There are a few more things we can do. Like add persistence to local storage or database but I will leave that as an exercise for the reader. You can see the repo with our project here.

Hopefully, through this tutorial, you gained an appreciation for how Marko and the new Tags API allows us to easily make stateful templates with some simple extensions over HTML to produce isomorphic apps.

That's right. The app we just made is fully server-rendered and dynamic in the browser. It doesn't get much easier than that.

Discussion (6)

Collapse
peerreynders profile image
peerreynders

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);
  }
}/>
Enter fullscreen mode Exit fullscreen mode
// 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 };
Enter fullscreen mode Exit fullscreen mode

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:

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"
Enter fullscreen mode Exit fullscreen mode
  • 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).

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')
);
Enter fullscreen mode Exit fullscreen mode

or

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

ReactDOM.render(
  h(
    Fragment,
    null,
    h('div', null),
    h('div', null)
  ),
  document.getElementById('root')
);
Enter fullscreen mode Exit fullscreen mode

with

ReactDOM.render(
  <>
    <div></div>
    <div></div>
  </>,
  document.getElementById('root')
);
Enter fullscreen mode Exit fullscreen mode

… 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.

Collapse
ryansolid profile image
Ryan Carniato Author

Admittedly the store example is probably where this is the most involved. But I wonder how far it goes beyond this in Marko apps. This is a simple form. And these sort of pieces are probably the extent of state management in most MPAs.

Still as you may have noted I'm big on aggressive co-location. Mostly looking at if we can bridge the gap between the small and the largest apps better. You've probably noticed this trend in refactoring or software scaling. But where we start on the small side is closer to where we end up on the enormous side than all the steps in between. In Marko's case I think this article better captures our goals that the release announcement for the preview, and especially look at the code example at the bottom and the refactoring story.

I like that example a lot because it mirrors the pattern that I constantly see as we scale things. Every framework would have benefitted going from version 1 directly to version 3 if we knew we were going to version 3 ultimately, but introducing boundaries prematurely is not great. Only Marko in that example seamlessly goes through the 3 versions as a natural progression rather than a bunch of rewriting and refactoring.

When we are small we have everything in a single container. It's easier to see it all in front of us. The complexity is not at a point that this is hard to manage. As we grow this structure it becomes harder and we break it apart. Our first instinct is to group by like things. Whether that is as far as separating out state management from view, or simply reorganizing our component code to make it easier to add more features. Eventually though it scales beyond our ability to scale people or process. And we need to slice things the opposite way. At 90 degrees so to speak. More often this involves undoing what we did in the first step. And funny enough it often looks like having more of the initial thing rather than the intermediate step.

Now to be fair we go through this cycle over and over again. As now each of those pieces will do the same alignment over time and eventual split. That cycle I think is what a lot of the work is looking to address.

Now in my opinion this is all about the old game of hot of potato so to speak of who is left holding the state. When we moved to the client side we brough MVC with us, which was terrible because it didn't account for local state. This is what killed Angular1 etc, and lead to the rise of React. React wasn't the first one though to understand this. The whole MVVM thing was poking the holes in MVC. And Angular and Ember were trying to add a bunch of stuff to MVC to account for the fact they were missing something so vital in their model. It was the complication they added to an architecture that didn't want it that sunk those V1 versions. People probably could have kept using the awkward pattern as the fix was worse than the problem in a sense, but we moved on.

Now what we've been seeing recently is the continuation of that. Global State management has been a source of a lot of friction for frontend development. Well it is a bit more complicated than that. It's more that pulling everything local obviously doesn't exactly work in a naive sense. More boundaries have a cost as we scale. But since frameworks control the change mechanism instead of some externalized controller we end up playing a bit of an awkward game as we try to move certain things out of the components back into something shared. And this is basically where I've felt this whole "UI as an Afterthought" started gaining steam again.

But I just see 2 extremes with misalignment. Client frameworks don't really want global state, but are somewhat doomed to be inefficient without it. And classic server side mentality doesn't want local state. They want to be stateless. So who the hell is left holding the bag. That is why GraphQL has been a big deal, and things like ReactQuery in React ecosystem. Frameworks want to treat all state as local, and backend want to treat all things as stateless, the solution it feels is not to try to force either side to do what it doesn't want to. Just to abstract out the adapter. There is complexity here but there is a surprising amount of alignment.

Now, where does business logic live is the resulting question, because I'm basically advocating for smart backends, smart UIs, and dumb stores, (instead of the proposed smart stores and dumb UIs). The answer is mostly on the backend. Instead of viewing our architectures as 2 distinct MV___ that feed into each other I think we need something else. Classic server mechanics have us go from smart(business layer) to dumb(presentation layer) as we serve out our content. Classic app mechanics have us go from dumb (database) to smart (interactive UIs). So to me this about connecting and wrapping up those dumb parts. Ironically I call them dumb but they consist of some of the hardest problems like caching.

So what does this have to do with anything? I think we need to set ourselves up be able to best slice things the other way. And the way we do that is collapse the client/server model. It's not to say the results end up being that different than UI as an Afterthought but in a world where we offload the "global" state logic outside of our whole frontend mindset leaves the frameworks and UI tools the flexibility to optimize for their usage. Where aggressive co-location is a good thing.

TodoMVC example is fundamentally at odds because our model a client side one. Whereas ideally the store would look more like your refactor except we wouldn't need the separate JS file.

Collapse
peerreynders profile image
peerreynders

Thank You for your response!

I've revisited

from 2020-Nov-23 as that seems to be the point where you got the most public feedback. Some questions:

<h1>${input.headerText}</h1>
<div/el />
<mount=() => {
  const chart = new window.Chart(el, input.data);
  return () => chart.release();
}/>
Enter fullscreen mode Exit fullscreen mode

Given that Chart uses a native DOM reference is it safe to assume that it is purely a client-side widget?

Consequently what actual HTML is sent from the server to the client? Something like:

<h1>Chart Header</h1>
<div></div>
Enter fullscreen mode Exit fullscreen mode

Side note: Good thing eBay doesn't plan on adopting Tailwind CSS.

Thread Thread
ryansolid profile image
Ryan Carniato Author

Yeah <mount> was an early version of our <lifecycle> tag. So this is all client side. So the server HTML would be what you wrote and when hydrated in the browser the chart would be created in this example. The refactor story equally applies to nested state, but nested side effects(browser only) I felt were the most obvious for this example.

Collapse
abiyasa profile image
Abiyasa Suhardi

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!

Collapse
ryansolid profile image
Ryan Carniato Author

Yeah mostly that since we are streamlining composability we are replacing the () (default arguments) with = (default attribute). In this way we can extend this capability out to custom tags you might author. Default attribute has some benefits in that it only accepts a single argument.

So <if(condition)> is now <if=condition>. How we handle backwards compatibility is still open but we wanted the preview to only contain future facing syntax to get a feeling for what the intended experience.

As for the store, you could do it with just JavaScript to a point. The unit of change, the equivalent to React's useState or Vue's ref or Svelte's let is Marko's <let> tag. So you could set and update that with JS from the outside but it wouldn't be granular. In the same way you need to update their core primitives you need to do so with Marko. So using the primitives in file makes it easier to make it more performant.

It's a bit of a departure but we have primitives for Context API, etc for more advanced patterns, and more interestingly is tags let you colocate in the markup. Nest data exactly where you need to use it without additional imports etc. Not saying you would but when Marko 6 comes along you could make a whole app in a single template with no performance degradation. Components no longer are a limiting factor.

In some ways it's like the diagram when React Hooks came out that showed how we reduced the interweaving of logic compared to class Components. This takes it even further. Basically single cut and paste refactoring. Almost like dealing with plain HTML.

That being said it only raises the bar on tooling in templates. And on this we agree. Work in the last year from Vue and Svelte have given us a pretty clear trajectory in getting TypeScript, Prettier, and ESLint support. Things that these custom DSLs have always struggled a bit with. So this is definitely something being worked on. But as you can imagine with something so big coming around the corner it didn't make the most sense to develop that out with these changes coming down the pipeline.