To me Reagent is the ultimate answer to the markup/code mix. A single language, ClojureScript. Nothing is done in strings except text. I absolutely love it, but haven't been able to use on a production project yet.

[0] https://github.com/reagent-project/reagent#examples

I really like clojurescript in theory, but have a dumb practical reason for not being able to use it. I do a lot of programming in common lisp, and am way too used to a lisp-2.

I literally can't write more than 100 lines of clojure without accidentally shadowing a function binding with a variable binding. I think the only way to break the habit would be to abstain from common lisp for 6 months or longer.

I have the opposite issue trying to write in emacs-lisp after doing lots of clojure. I try to:

  (mapcar my-func my-list) 

and it throws void-variable and then I remember that I have to add the #' reader macro to have it read as a function not a variable.

  (mapcar #'my-func my-list)

It just takes some time to switch the mental model over each time. Clojure did get me in the habit of using unique names for all functions and values because accidentally shadowing a function binding is that more difficult mistake to debug.

In practice I haven't missed the flexibility of a lisp-2, if anything it's just made my code more readable because my names are forced to be more descriptive

the bummer about reagent is that it allocates so many immutable data structures on render. I've not figured out a way to ergonomically write hiccup without paying this constant performance tax, which is felt on a lot of large reagent apps.

using hiccup to write html has been a godsend. I find it much easier to visualize the html that hiccup will generate vs JSX, and I can do arbitrary manipulations on it just like I can with any other clojure data structure.

> I find it much easier to visualize the html that hiccup will generate vs JSX,

Can you elaborate on this? On first glance it seems the same, just with a syntax that uses different symbols than HTML?

It's been the way Elm describes its components; and I believe Andre Staltz has been criticizing jsx in favor of hyperscript since forever [0], and included hyperscript in cycle.js.

Lit-html, which is using template literals, is another good option.

[0] - https://staltz.com/some-problems-with-react-redux.html

I love Mithril but I find hs to be noisy to read and tedious to write.

It's probably because I've been reading and writing HTML for +20 years though.

(mithril author here)

hyperscript is about as close to a middle ground as we can get. It's compatible with JSX for the folks that really really want to see angled brackets, while still being uniform javascript like other API variations (div(), html`<div></div>`, etc). The lit-html syntax is not bad either, but template strings did not have as widespread support back when mithril originally came out.

Is there a roadmap for mithril? As in, what are the current pain points, where development is headed, etc.

I've given stewardship of the project to the community. At this point, it's largely in maintenance mode. Most changes are tightening up loose semantics and the like. IIRC the last major was only a major by technicalities; it didn't really break anyone unless they were relying in weird obscure behaviors.

Since the framework isn't interested in chasing trends and since it provides extension points via lifecycle methods, there's really nothing novel that needs to come from the framework itself.

I know some of the more popular frameworks make it seem that webdev is constantly in churn/evolving, but if you look at React for example, other than the hooks paradigm shift etc, it hasn't really changed all that much in scope over the years either (the same can be said about other libraries as well).

For example, Mithril could easily be used w/ coffeescript when that was still a thing, and people use it with typescript these days too without much fuss since TS is also a project that decouples well. And this is with zero changes to the framework. You can integrate dragula or plupload or google maps or whatever via lifecycle methods as you always could too.

So, TL;DR: I think the focus still remains on making it as stable and robust as possible

Does mithril provides typescript function signatures for its API?

They're on definitely-typed

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/87f2...

This was helpful. Thanks!

Yeah but why isn't it just HTML?

Why isn't what just HTML?

Yes, probably. I started using haml (then slim) a very long time ago and the hyperscript / elm type syntax is fairly intuitive to me.

What is the point of templating HTML? I really don't understand it. Just write HTML or HTML-like APIs like JSX. Is there some theoretical reason why this is wrong?

Subjective I guess. For me it’s just a reduction in noise and I prefer to read code with significant white space. Perfectly ok writing HTML, but given the option, and if it doesn’t screw with others, I prefer not too.

JSX is HTML templating

I've done a few projects in mithril, and having used both jsx and hyperscript, I tend to lean jsx.

That comes with some very real downsides - mostly getting jsx to work requires a bunch of extra (ugly) tooling. On the other hand, very complex components look very clean.

Hyperscript when you have a relatively nested dom element gets quite messy and hard to visually parse for me.

Back when jsx was introduced people said so too but they weren't as loud as the other group. When you look at a completely new language, reasonml where they're still of the mindset that jsx bring familiarity it makes nosense. Just an excuse for some abitrary preference.

Someone might find these issues interesting on flutter regarding jsx:

https://github.com/flutter/flutter/issues/11609

https://github.com/flutter/flutter/issues/15922

I remember getting excited learning that I could do Xamarin Form in plain function calls in F#. Android is going similar journey simplify UI programming with Jetpack Compose. Jsx is backward and purely stylistic.

Combined with coffeescript it's even nicer since you can ditch the parentheses and have a very clean indented syntax.