Merlin, a Hyperapp alternative

[marcodpt]

The Merlin JS framework

Raj + Superfine + Tint + SPA Router = ❤️

This is my framework following the teachings of hyperapp.

It uses:

• superfine: Minimalistic vDom.
• raj: View layer agnostic state management.
• tint: Logicless template engine that uses valid HTML.

I'm a big fan of functional interfaces and Jorge Bucaran's minimalist approach.

Furthermore, I really like template engines and separating design from logic.

I created a template engine that allows you to use HTML instead of hyperscript and wrote a wrapper for the hyperapp.

[jorgebucaran]

This looks great! I've checked out Raj before and found it cool too, nice job. My only gripe would be with Tint itself... I'm not a fan of template languages. Using artifacts like each:, not:, and value: feels clunky, and enveloping variables and functions like "todos" or "AddTodo" is unfortunate. That said, I can't suggest an alternative that's as vanilla as h() and looks as good as Tint or JSX for that matter.

Thanks for sharing! Maybe I should give string template engines a second chance after all. 👍

[marcodpt]

Tint has a clear difference from JSX or Vue syntax.

It does not allow javascript.

So I really don't see any reason to use JSX the way it is given (hyperscript is preferable).

But my goal in creating Tint is different:

What should a template engine be like that allows you to modify the layout without coming into contact with logic?

How should it be to modify the logic without coming into contact with the layout?

Tint doesn't even allow dot syntax.

And it is a valid extension of HTML for clarity.

In any case, I appreciate the openness given, even though it's not the type of philosophy you like.

I'm a big fan of your work, keep giving us these wonderful tools.

[jorgebucaran]

I appreciate that you intentionally included those limitations in Tint. I hope you try to stick to them, as it's often easier to just pile on features. From your description, it sounds really minimal.

[marcodpt]

Since I finished tint I have never modified it again.

The only thing I did was add Deno support.

All syntaxes were carefully thought out to apply the DRY principle in the layout, including a minimum of logic.

There is a switch, custom tags and bind operator, but it is a mistake to think that this is logic, it is just a way to make templates more elegant.

If you think that mustache has dot syntax, lambdas and partials, I guarantee you that it has more logic.

My goal is to separate the logic from the layout as much as possible and any new feature goes against that goal.

All your answers were a true masterclass, and I really admire your minimalist way.

It's a lesson that I will take with me for life, thanks again for the comments, the tools and your philosophy.

[marcodpt]

Just one thing I would like to add is that:

The way I built the hyperapp wrapper, I am forced to use state in the template.

And the way the raj was done, I can use the view function to format the state without modifying it.

Due to the nature of Tint's lack of logic, this construction with the Raj proved extremely convenient.

[marcodpt]

I will try to create a version of it using hyperscript.

You lose a little in readability and ease of use for designers, but you gain a lot in power and simplicity.

A single language is the best of all worlds.

But hyperscript presupposes a mental conversion to html.

I don't have an answer, I use hyperscript, and I use non-functional interfaces.

In this work I tried to do something pleasant without trying to solve all the UI problems I face.

[jorgebucaran]

Yes, I understand. The issue with designers is real, as teams aren't always composed entirely of developers. I wouldn't want to be limited by that regardless. I agree that h() isn't as readable, but one can get used to it.

[marcodpt]

An alternative that I like and that greatly improves the clarity of the hyperscript is this:

import app from "https://unpkg.com/hyperapp"

const AddTodo = (state) => ({
  ...state,
  value: "",
  todos: state.todos.concat(state.value),
})

const NewValue = (state, event) => ({
  ...state,
  value: event.target.value,
})

app({
  init: {
    todos: [],
    value: ""
  },
  view: ({
    todos,
    value
  }, {main, h1, input, ul, li, button, text}) =>
    main({}, [
      h1({}, [
        text("To do list")
      ]),
      input({
        type: "text",
        oninput: NewValue,
        value
      }),
      ul({}, todos.map((todo) => 
        li({}, [
          text(todo)
        ])
      )),
      button({
        onclick: AddTodo
      }, [
        text("New!")
      ]),
    ]),
  node: document.getElementById("app"),
})

If I were the creator of the hyperapp I would have done it this way.

You add size due to html tags (which in a minimalist library counts) but you gain in simplicity without introducing global variables.

If I'm going to follow your advice and remove Tint I would do it this way.

With the following rules:

• every list of children must be an array.
• all properties of an object on a new line.

[jorgebucaran]

Remember there's @hyperapp/html and @hyperapp/svg exactly for that purpose. I imagine some people will still find it inferior to JSX or similar tools, though.

[marcodpt]

Maybe this is the best approach, because it allows you to write templates outside the app.

import {app, html} from "https://unpkg.com/hyperapp"

const AddTodo = (state) => ({
  ...state,
  value: "",
  todos: state.todos.concat(state.value),
})

const NewValue = (state, event) => ({
  ...state,
  value: event.target.value,
})

app({
  init: {
    todos: [],
    value: ""
  },
  view: ({
    todos,
    value
  }) => html(({main, h1, input, ul, li, button, text}) => 
    main({}, [
      h1({}, [
        text("To do list")
      ]),
      input({
        type: "text",
        oninput: NewValue,
        value
      }),
      ul({}, todos.map((todo) => 
        li({}, [
          text(todo)
        ])
      )),
      button({
        onclick: AddTodo
      }, [
        text("New!")
      ]),
    ])
  ),
  node: document.getElementById("app"),
})

[jorgebucaran]

I like this too. Pretty sure we tinkered with something like that at some point, but ended up sticking with that other approach you mentioned.