Mithril.js: Which do you use more in mithril? JSX or Hyperscript?

[tonyalaribe]

I'm about starting my first project in mithril, and i'm trying to decide what approach to take that won't hurt in the long run. Especially in terms of maintainability and bringing others along. Please share your mithril workflow. Thanks

[v4n]

We compared both options and made our decision based on:

• how easy it is to parse a long html structure (not short 10-30 lines example)
• what syntax would be most comfortable for an entire team (designers , developers, growth hackers, interns...)

In our company we decide to go with JSX. I would recommend that you try reading/writing both and pick the one that feels the most natural:

m('div', [
  m('button', {class: `button ${color}`, id: 'add-button'}, 'Add')
  m('div', {class: 'container'}, [
    m('h3', 'Total')
    m('span' [
      totalAmount
    ])
  ])
])

<div>
  <button class={`button ${color}`} id="add-button">Add</button>
  <div class="container">
    <h3>Total</h3>
    <span>{totalAmount}</span>
  </div>
</div>

We have the setup described in http://mithril.js.org/jsx.html . babel-plugin-transform-react-jsx is likely to be maintained.

[orbitbot]

I haven't used mithril in a team setting (yet), but it's been my go-to frontend framework for about a year now. Coming from angular I set up a workflow with JSX to start with since it felt more familiar and I wasn't aware of how much there was to learn with mithril (it clicked fairly quickly), but moved on to hyperscript after maybe a month or so and currently prefer it.

Both worked more or less fine, but there are (were?) some inconsistencies wrt JSX and HTML (closing <img> and <link> tags etc.) that are annoying, and occasionally it was quite unclear what the correct JSX syntax for something would be (or what kind of hyperscript the parser would create, perhaps). I agree with @v4n that babel tools are likely to be well maintained.

If you find the need for it, there's a conversion tool linked at the end of the JSX page in the docs that converts HTML to hyperscript. IME hyperscript took a while to understand (larger initial learning curve), but later on it feels more natural to embed f.e. ternaries or forEach statements in normal javascript code.

[bruce-one]

Initially we used the JSX-like syntax, but since moved to just the hyperscript one.

I think the hyperscript syntax felt more jarring initially, hence the decision to go JSX originally (it felt less "odd").

Having used both I prefer the hyperscript syntax, and if I had my time again wouldn't go JSX (some things become a bit less clean, and it's a bit less obvious that "it's just javascript" and hence can be used more "cleverly").

Just my 2c :-)

[leeoniya]

👍 for hyperscript.

• no tooling, less headaches
• don't need complex IDE-level parser support/plugins, just any plain JS syntax coloring.
• free debugging
• cleaner, more obvious templates using obvious plain-JS semantics

one drawback to hyperscript is in huge templates that run across multiple screens where it's a pain to tell which element is closing, but this is easily solved by breaking up templates into smaller helper sub-templates, which is more readable in practice anyhow. that or code-folding.

another drawback may be lack of good hinting/auto-completion in IDEs. this never really bothered me personally.

@v4n:

m('div', [
  m(`button#add-button.button.${color}`, 'Add'),
  m('.container', [
    m('h3', 'Total'),
    m('span', totalAmount),
  ])
])

[jacksonrayhamilton]

I use Hyperscript; or, as I prefer to call it, "JavaScript." I also use JavaScript (rather than JSX) when writing applications that include React as a dependency.

JSX and Hyperscript are basically the same thing - they both provide tree nodes with names, attributes and children. The only difference is that one of the syntaxes kind of looks more like the syntax commonly used to represent the tree that it generates, and the other is significantly easier to use (the last three commenters provide all the points I would have made). I can also attest to having attempted to implement automatic indentation and static analysis in an IDE for JSX. It was quite difficult, and still needs more work.

I find it ironic that the documentation both provides instructions for how to set up JSX with Mithril, but subsequently provides several arguments seemingly against the use of JSX, here and here. In particular:

While complex toolchains are also possible with Mithril and other frameworks alike, it's _strongly_ recommended that you follow the KISS and YAGNI principles when using Mithril.

This issue also highlights what I would consider to be another issue: Providing instructions on how to use Mithril with JSX (and furthermore, with ESNext transpilation) puts into question what an "idiomatic" Mithril project looks like.

My take is that JSX and ESNext transpilation have nothing to do with Mithril. My theory: The React engineers decided to promote JSX. Since ECMAScript 2015 was standardized around the time that React started gaining traction, and since React users were already transpiling code, many figured they "might as well transpile ESNext too." Mithril 1.x happens to share some characteristics with React. Because of this, users migrating from React to Mithril try to apply the same mindset with respect to syntax. But, as the documentation demonstrates, users don't need all that complexity.

I think the instructions for setting up JSX and ESNext build pipelines should be removed from the documentation. It would narrow the focus of the documentation to simply "how to use the API." To remove those instructions would also make the image of "idiomatic" usage clearer, while at present, providing the instructions creates some ambivalence about those KISS and YAGNI principles.

[v4n]

I see a pattern where people with strong JS background prefer Hyperscript. I think it's healthy to see things from multiple perspectives.

For us we had to consider that we are a startup with team members of different professions and level of experience.

• For a designer working on a complex long layout for a landing page: hyperscript can be hard to parse with so many nested elements and a lot of ]) closing marks.
• For a growth hacker (more marketing knowledge) that sometimes has to do simple changes to a page: there is higher familiarity on dealing with HTML.
• For interns: the likelihood they've worked with HTML and tried out React/JSX is high. From day one there is familiarity in the project

I think if we want to make Mithril adopted by more companies & startups we need to take into consideration the amount of knowledge and interest in JS within a team. Not just an individual or small group of JS "pros" working on a project.

[jacksonrayhamilton]

I suppose the usefulness of an HTML syntax (with respect to supporting those only familiar with HTML) depends on the use case.

In a more traditional website with lots of static content, there would be more opportunities for those with less technical experience to contribute source code.

In a "web app", there will be more dynamic content, which will require much more technical involvement, e.g. classes / attributes dedicated to transitions and event handlers and tests, knowledge of functional programming patterns to generate lists, etc. In both cases, when writing HTML for modern websites, there are maintainability advantages to writing HTML in a manner that serves the intersection of several screen sizes and browsers. This often requires quite a bit of background in web quirks and tends to convolute HTML. So much change would be required to transform some static HTML mock-ups to dynamic web app screens that I think it would be easier to design screens in an image manipulation program and then translate the design directly to application code.

I'd like to say that tools like Mithril should be delegated to the "application" cases, and that static content sites actually be served as HTML without JavaScript. But there certainly will be some sites with a fair share of both static and dynamic content; e.g., the blog on isiahmeadows.com has a search feature. So to pigeonhole Mithril may be unwise, if those cases are frequent enough.

[leeoniya]

IMO there are websites and there are web apps. a blog with a search is 100% the former. a js dropdown menu, accordion or ajax autocomplete doesnt justify writing a website in js - just sprinkle some jquery or plain js. i have encountered exactly zero properties where the distinction was not clear or at least divisible into the "app" section (usually after login) and a site section that benefited from SEO indexing. there is a certain threshold of complexity that needs to be reached before using a js framework becomes justified.

[tivac]

We're always 100% hyperscript. It's completely subjective but I find the rules for correct usage of JSX annoying to remember and still think it looks really ugly.

[barneycarroll]

I use hyperscript. It's plain Javascript so benefits from a standard syntax, can abide by your existing style constraints and build pipeline (or no pipeline at all), it works in the browser, you can debug it and get runtime logs, breakpoints and errors that match up directly to your code without ambiguity.

It's also more flexible in that it's unconstrained by the arbitrary restrictions of the JSX parser — you don't need to worry about build vs runtime parsing, or where the JS/JSX boundaries need to be; you can return arrays from views, you can nest fragments, you can write namespaced elements & attributes.

Hyperscript doesn't require Javascript expertise: no special Javascript syntax or logic is necessary in order to use it, the API is small and intuitive. When you do need Javascript interpolation or logic you can do it in whatever format you need without wondering about how it will be interpreted by an intervening parser.

If you like JSX, use JSX. You may well face some extra work & trouble over configuring your build system or running into build time ambiguities, or it could be plain sailing and a syntax everybody likes more.

Regarding the benefit of making things nicer for 'growth hackers' who like HTML: if you feel this is a strong win, then great. But it feels very similar to me to the CMS fallacy, whereby an application and codebase are optimised for the lowest common denominator in a way that introduces complexity, restrictions and potential for error for a deceptive perceived benefit. Making your codebase more inviting and manipulable by the people who understand and use it least yields a whole new class of problems that are often best solved by requests to / conversation with programmers.

[nordfjord]

We've been using mithril since 0.1 and have used hyperscript from the start.

The hyperscript api makes it easier for me to look at code and css side by side in my editor, since there's almost always a 1-to-1 correlation between the hyperscript string and the css selector used for the element.

I also find writing JSX pretty weird, I like to use one language in one file :)

[isiahmeadows]

I use the hyperscript mainly because I've always found JSX to be awkward. Hyperscript is just a DSL in JS, while JSX requires a more complex setup, and HTML just looks weird with my JS. Just my opinion.

[tonyalaribe]

Thanks for the insight. I eventually used hyperscript for the project, and in the beginning, it felt very unnatural (infinite nesting of functions), but I'm getting used to it now, and gradually more productive.

[ludbek]

I use hyperscript. I find JSX to be an overhead. Below is a snippet of a form from one of my project.

// ... 
o(fields, {fieldCount: 3},
    o(field,
        { type: "text"
        , model: this.model.identity_number
        , validate: "onchange"
        , update: "oninput"
        , label: "Identity number"
        , placeholder: "Identity number"}),
    o(select,
        { model: this.model.issued_from
        , label: "Issued from"
        , search: true
        , options: genOptions(store().districts.data)}),
    o(field,
        { type: "text"
        , model: this.model.issued_date
        , validate: "onchange"
        , update: "oninput"
        , label: "Issued date"
        , help: "Date must be in AD."
        , placeholder: "YYYY-MM-DD"})),
        o(divider),
    o(button,
        { color: "green"
        , type: "submit"
        , loading: this.processing},
        "Update"))

[tonyalaribe]

Wow @ludbek, thats some really neat hyperscript formatting.

[ludbek]

@tonyalaribe I mixed formatting from elm and lisp :D

and o from ospec. lel

Update

let o = m;

[orbitbot]

@ludbek Is this test code of some form, or are you actually using ospec clientside?

[ludbek]

I assigned m to o. :)

[isiahmeadows]

Closing, since this issue has not been updated in over a month. If you feel something in Mithril needs added or changed, please file a new issue.

[foxdonut]

I like both. Another plus for JSX in my opinion is that you could use it not to tie your views to the vdom library that you are using. Then, if you ever need to switch, you would only have to change your JSX configuration (one change in one place). Depending on the vdom library change, you would need to consider whether onclick needs to be changed to onClick and so on.

[PierBover]

I'm pretty new to Mithril and I'm using JSX. Markup is a lot easier to read for me since I've been writing HTML for almost 25 years. To be honest, if Mithril hadn't had support for JSX I simply wouldn't have used it.

Someone else has commented that hyperscript alienates non JS devs from the codebase which is totally true. Heck, even JSX is alienating for non JS devs. I've found that Vue and Svelte are the better options when designers or PHP/Go/Python backend-devs need to poke around the front end project.

I'd go as far as saying that hyperscript is probably the reason why Mithril is not much more popular in front end circles considering how great it is. I really believe the majority of front end devs prefer HTML/JSX as an abstraction to the scene graph that the DOM is. No hard data but it seems obvious if we consider the most used libs/frameworks either use JSX or use templates (React, Vue, Angular, Svelte, etc). If there is interest in increasing Mithril adoption I think a good first step would be to make JSX a first-class citizen in the Mithril docs which are 99% hyperscript only.

Don't get me wrong, I totally understand that hyperscript has its advantages. I love the idea of not needing a build process, unfortunately the cognitive load of reading hyperscript is too high for me. Instead of reading "oh here's an H1 with these properties" I read "oh here's a Mithril node that actually represents an H1 that has these properties and then this object with these HTML attributes". It's an abstraction on top of an abstraction. It's not too bad when it's a small widget but when you want to just quickly scan the markup of a more complicated component (like a page, or a form) I find it takes too much deciphering.

Maybe if instead of m(...) there was a syntax with less "noise" I would consider trying it. I've also considered making a theme for my editor that somehow puts the relevant parts more visible and turns down what my brain considers "noise". But so far I'm happy with JSX and I haven't dedicated any effort to solving this.

Anyway, please don't take this as a personal attack to hyperscript. I think it's awesome that anyone can use what they prefer.