I think people should stop presenting JavaScript == operator as some kind of black magic, it's not helping anyone. The standard is online and you can read it here [1]. It is complex and unintuitive, no doubt about that, and you should prefer === most of the time. However, rejecting any attempt at understanding it is counter productive.

[1]: https://262.ecma-international.org/11.0/#sec-abstract-equali...

If the author of Mint sites Elm as an inspiration, it might be worthwhile to explain the ways Mint differs from Elm? It seems like, if the things Mint offers are things a dev is interested in, they'd be better off using Elm, as I would hazard a guess Elm is better supported/maintained than something Elm-like?

The ability to inline arbitrary JS seems like a big difference.

From the Learn section: Why choose Mint over Elm?

Elm has great developer experience, but it being a purely functional language leads to some boilerplate code and makes it harder to learn. Also, it's not possible to contribute or influence the language in any meaningful way.

It says in the article that everything is immutable, which I found intriguing, but then I see this in the example at mint-lang

fun increment { next { counter = counter + 1 } }

Something doesn't add up.

I don't know Mint but want to give a data point about that.

The `=` is rebinding, what that mean is the original value doesn't change. If you pass that counter variable somewhere, it has its original value. the `count = counter + 1` here mean that a new memory block is allocated, get a value, and the `counter` in this scope is point to it. The old value in the original memory block won't change.

At least, that's the case of Erlang/Elixir.

That's horrible... and yet I see exactly why it is needed for multi-threaded, multi-core systems.

Question: When is it safe to throw the old value away?

Knowing zero about Mint, from the claim and snippet, I assume that “assignments” in a next-block set up bindings for a future state in terms of bindings for the current state. If so, it's not mutation where something could have a reference to the the old counter and have it swapped to the new one.

ha, that made me chuckle

Curious if anyone here has tried mint? Looks to be a few years old and still at version 0.11.00. Looked at elm but still going down the web component rabbit hole on my next project. I guess I need to stop looking and just keep building

Web components aren't really a stand-in for a framework, though. They have no concern with DOM templating nor reactivity, which are the main problems solved by modern frameworks

Good point, thanks.

Hey, let's remediate the overwhelming amount of JS app frameworks with a new programming language.

That totally won't encourage an overwhelming amount of JS transpiled languages.

Cute idea, but this is a maintainability nightmare scenario.

Why?

We need to come up with a different name. MintSim, Intuit Mint, this, gets confusing lol

My mind automatically goes to the XKCD comic - https://xkcd.com/927/

I do agree that the number of tools and solutions out there for creating web applications is overwhelming at times. I just don't know if this a valid approach, especially when people keep churning out tech to replace old tech instead of improving on said old tech.

Mine as well.

We don't need this.

There are the big 3 (react vue angular), there are the old and great (meteor, angularjs, elm, polymer)

Do not want.

Ha. They even share that xkcd at the bottom of the post.