
Mint: A programming language for writing single page applications - Vinnl
https://www.mint-lang.com/
======
pkulak
My first thought: an entirely new language for one domain?

But then I started looking at the examples and how styles and an xml-like
syntax are given first-class support and it makes sense. It really is a hard
problem to shove into an existing language, evidenced but all the transpiling
that goes on now. Thanks for sharing!

~~~
hencq
Agreed. I browsed through the guide and at least at first glance it looks very
well designed. Things like naming a node or a component (<Item as item>) that
can then be used elsewhere look really clever. I'm curious what the actual
code looks like for an example app like todomvc.

Edit: coffee -> code

~~~
dgb23
> I'm curious what the actual coffee looks like for an example app like
> todomvc.

I've never seen the term 'coffee' used in this context. Is this a typo or some
kind of slang/reference?

~~~
xwowsersx
That was a typo and he meant covfefe.

~~~
dgb23
I appreciate the joke :) but I really didn't get the obvious at first (code =>
coffee autocomplete). I was distracted by the fact that this language
transpiles to JS so coffee might be a reference or something.

~~~
xwowsersx
oh haha, I thought he was referring to coffeescript for some reason. code =>
coffee autocomplete makes much more sense

------
smehtaca
I don't really see a major advantage of this over using create-react-app with
Typescript and libraries like Styled components for styling and react-router
for routing. All of the batteries-included features can be easily handled by
libraries and tools that are already well developed.

~~~
gdotdesign
Author of the language here, I think it is a major advantage for several
reasons:

\- the documentation is in one place instead of several places

\- the dependencies of a Mint project is usually a few megabytes since
everything is included instead of hundreds of megabytes (I have a production
app that does not have any dependencies at all)

\- only need to learn one (compact) thing, instead of many complex things
(complex since there is no compiler to make it simple)

\- only need to update the code once there is a new version of the language
not every time there is a new version of a dependency

On top of the libraries mentioned the language also includes a formatter,
package manager, builder/dev server and testing environment, also for which
you would need to add dependencies.

All of these add up to less cognitive load so I can focus on building the
product instead of managing the development environment.

(edit: formatting)

~~~
sdegutis
(Not GP.) You've clearly put a lot of work into this, a lot more than a lot of
people could.

I think a lot of people will gloss this over, but I thought about what I would
want if I put the same amount of time and effort into something, and I would
want honest feedback.

> \- the documentation is in one place instead of several places

For developers with a few years experience, they don't generally have trouble
finding documentation for disparate frameworks and languages. The bigger
trouble is usually finding out the latest best practices.

> \- the dependencies of a Mint project is usually a few megabytes since
> everything is included instead of hundreds of megabytes (I have a production
> app that does not have any dependencies at all)

There are a lot of use-cases where the bloat of the web app isn't really an
issue. But for those who do (and I'm not sure who they are), it's still a
somewhat unsolved problem.

> \- only need to learn one (compact) thing, instead of many complex things
> (complex since there is no compiler to make it simple)

I don't think that's necessarily true. They would have to learn all the same
_concepts_ which exist within Mint. (And if not all the same concepts exist
within Mint, then it's not up to par.) What's different is the syntax, and the
semantics of how these concepts glue together _within Mint_. This generally
means it's actually _harder_ to learn a new all-on-one language than it is to
learn React + TypeScript + styled-components for someone who already knows JS.

> \- only need to update the code once there is a new version of the language
> not every time there is a new version of a dependency

Then how are the dependencies getting updated when there's a new version? If I
use a currency library in my Mint app, how can I update it, and test it
locally to make sure the updated library still works with my app? At some
point we have to deal with dependencies and updating them...?

~~~
gdotdesign
Thanks for the feedback! I really appreciate this ;)

All of your counter points have merit, I think it boils down to preference at
this point, but what I can tell you that after doing Elm for a while getting
back to the JavaScript ecosystem is a nightmare and Mint is my way out of that
(for SPAs).

> I don't think that's necessarily true. They would have to learn all the same
> concepts which exist within Mint. (And if not all the same concepts exist
> within Mint, then it's not up to par.) What's different is the syntax, and
> the semantics of how these concepts glue together within Mint. This
> generally means it's actually harder to learn a new all-on-one language than
> it is to learn React + TypeScript + styled-components for someone who
> already knows JS.

I'm not entirely convinced that that is the case, TypeScript can be it's own
language in itself. Not really a problem now but a few years back people
struggled to even learn new versions of JavaScript in itself, let alone a the
libraries with their different paradigms.

Also to get where Mint is you would probably need to learn: TypeScript, React,
styled-components, Jest, prettier, Webpack, Redux (or one of the
alternatives), Babel and that's just from the top of my head.

> Then how are the dependencies getting updated when there's a new version? If
> I use a currency library in my Mint app, how can I update it, and test it
> locally to make sure the updated library still works with my app? At some
> point we have to deal with dependencies and updating them...?

There will be dependencies sure and you will take care of them as usual, what
I am saying is that with Mint you will only need a few.

The application I've been developing ([https://www.base-
api.io/](https://www.base-api.io/)) and the front-end is in Mint and it has 0
dependencies (other than the standard library which is built in).

~~~
sdegutis
> I'm not entirely convinced that that is the case, TypeScript can be it's own
> language in itself. Not really a problem now but a few years back people
> struggled to even learn new versions of JavaScript in itself, let alone a
> the libraries with their different paradigms.

I think that's just a coincidence. We happen to know people who are starting
to learn JavaScript (and learning new languages is always a struggle), and so
naturally they also struggle to learn TypeScript when faced with those
concepts for the first time. But this is more The Evolution of a Programmer
kind of thing.

> Also to get where Mint is you would probably need to learn: TypeScript,
> React, styled-components, Jest, prettier, Webpack, Redux (or one of the
> alternatives), Babel and that's just from the top of my head.

A lot of these (Babel, prettier, Webpack) just need a good starter
configuration and can be mostly ignored afterwards. The rest mostly boil down
to concepts: Jest stands in for any testing framework, there's nothing special
about it; TypeScript for a mostly-basic type system; React for a basic
declarative UI framework; styled-components for mostly-just CSS encapsulation.

> There will be dependencies sure and you will take care of them as usual,
> what I am saying is that with Mint you will only need a few.

Ah I understand better now what you meant: the concepts that come built into
Mint are ones you don't have to worry about getting an external dependency
for.

~~~
IggleSniggle
> A lot of these (Babel, prettier, Webpack) just need a good starter
> configuration and can be mostly ignored afterwards.

Hilariously, the more difficult, time-consuming work I've done over the last
couple of years has been getting these kinds of configurations setup
appropriately for my org. It always feels like an enormous cost with hidden
tech debt.

------
mintplant
Mint appeals to me a lot. The two bits that have stopped me from diving in
past times it's cropped up are:

\- No way to render a page outside of a browser. It'd suffice to be able to
run a CLI tool or import Mint as a library and generate static HTML for a
given component and input data.

\- The fact that two record types can't coexist with the same key names and
type signatures. I worry this will lead to all kinds of headache dealing with
dependency compatibility: any change to a record definition, even an internal
one, becomes a breaking API change, and some libraries may not be usable
together due to coincidental naming. I would much rather the compiler require
that I annotate record literals with explicit type names to disambiguate, ie:

    
    
        record Todo {
          label : String,
          done : Bool
        }
        ...
        foo = Todo { label = ..., done = ... }
    

Haskell dealt with a similar problem for a long time and it meant that best-
practice code gave all its data type keys unwieldy prefixes to disambiguate
between data types that were imported together (todoLabel and todoDone vs
issueLabel and issueDone). In Mint I guess you'd also want to stick the
project name in, too (so myLibTodoLabel).

------
Vinnl
Note: I learned about this from a comment here [1] by gdotdesign, who appears
to be the main contributor [2].

[1]
[https://news.ycombinator.com/item?id=22245742](https://news.ycombinator.com/item?id=22245742)

[2] [https://github.com/mint-
lang/mint/graphs/contributors](https://github.com/mint-
lang/mint/graphs/contributors)

------
lbj
Having read through this, I fail to see any benefits over using existing tools
like Clojurescript+React. What am I missing?

~~~
Scarbutt
Clojurescript is unmaintained and full of bugs, the same for the cljs parts of
core.async.

~~~
iLemming
Fake news. Clojurescript today is a much more pragmatic and production ready
option, more popular than Elm, Reason and Purescript, better than Scalajs and
KotlinJs and definitely much better than JavaScript and Typescript.

------
0xff00ffee
Mint needs to up their "we are better than X because..." message because they
are stepping into a pond with lots of big fish.

From what I can see: it has zero incremental development. You must start with
Mint and haul in other new tools, or it doesn't work. That's a nonstarter, and
part of the reason why VueJS was so easy to integrate.

I read the Guide (briefly) and don't see any advantages. It looks like they
thought-out the most trivial scenarios, and that's it. Recursive components?
Data sharing? Messaging?

~~~
gdotdesign
Author here, yeah noted. I should do a better job on selling the language but
it's not easy doing this as a single individual.

I can however elaborate on the points raised:

\- Recursive components: you can do it, the type-checker allows it and it
works, or goes into an infinite loop if you don't exit correctly.

\- Data sharing: I don't know what you mean by this. If it's data sharing
between components you can do that by creating a store and connect as many
components to it as you like.

\- Messaging: I don't know what you are referring to? Websockets? Http?
between components?

The fact is that there is some many things built in that it is hard to fit it
on a single page above the fold, that's why I would say it's advantages is:
it's the only thing you should need.

> You must start with Mint and haul in other new tools, or it doesn't work.

Could you elaborate on this?

~~~
palerdot
I think GP means that you cannot try out Mint in existing toolchain/codebase
without rewriting it from scratch with Mint, which is a deal-breaker. The main
selling point of VueJS and Elm (if I remember correctly) is that you can try
it out in your existing code (even though with non-trivial setup).

Another problem with a framework especially for UI, is that you need a network
effect, that is really a good chunk of people who had tried it in production
and could vouch for it, so that other folks can atleast give a thought about
giving it a try. This is important given the rate of UI framework churn and JS
fatigue that people have gone through in recent times.

Personally, as an UI engineer who has familiarity with almost all of the
existing libraries/frameworks/toolchains this looks refreshing and would not
mind trying it out.

~~~
hashbig
VueJS and Elm are not the same thing. Vue is just a JS library. Elm is a an
entire language with its own tools and ecosystem.

~~~
palerdot
Yet, they are same when it comes to the value proposition of trying it out in
the existing code base right? Since my original comment revolved around that I
took those two examples (instead of say React and Vue)

------
giancarlostoro
I'm waiting to see Single Page Applications that just use Web Components from
the browser.

[https://developer.mozilla.org/en-
US/docs/Web/Web_Components](https://developer.mozilla.org/en-
US/docs/Web/Web_Components)

~~~
untog
A lot of people are waiting for Web Components folks to answer how you're
supposed to render them without JS (i.e. server-side renders)

~~~
giancarlostoro
Yeah, I am too, although I'm not entirely opposed to using them with JS, it
would be nice. I always wondered why you can't reuse HTML code. I think
Components are the obvious way forward.

------
AndrewSChapman
I'm curious. A question for the author: What is it that you're aiming to
improve over Vue + Typescript? Vue is opinionated and comes with single file
components, a router, a store etc.

~~~
gdotdesign
What I am aiming for is to move away from writing JavaScript or minimize it to
the level where it's more controllable.

I've come from Elm where it is done in a very good way, but it's too
restrictive, and I like react and it's expressiveness so I wanted to combine
the two.

Vue is really good but at the end you are still writing JavaScript which is
really hard to do in a safe way. And from my experience Typescript isn't 100%
safe as well.

~~~
a_wild_dandan
> What I am aiming for is to move away from writing JavaScript or minimize it
> to the level where it's more controllable.

Why is this a goal? Could you elaborate?

> And from my experience Typescript isn't 100% safe as well.

Does it need to be? In my experience, enforcing reasonable standards (don't
allow escape hatches like the `any` type, or the `// @ts-ignore` comment band-
aid) fosters pretty strong interfaces. I haven't really needed more from the
type system. Has your experience been different?

~~~
hellofunk
JS is on an extreme end of the spectrum of language inconsistencies, and a lot
of developers with extensive experience in other languages strongly prefer not
to use it. That's partly why there are so many languages that transpile to JS
so you don't have to suffer though actually _writing_ it.

Further, UI development is an area where things can get messy very quickly.
"Safe" languages often greatly minimize the kinds of bugs that are very easy
to write in JS. This is one reason why Elm and Clojurescript have had years of
adoption -- they by default make values immutable (and their entire
programming paradigm doesn't actually require mutating most values ever) which
removes a large class of common UI errors. There are other benefits as well.

------
ryanar
I really dislike the choice of `fun` to represent function, `func` is
acceptable, `fn` is acceptable, I don't even mind `def` in Python, but `fun`
is a widely used english word that is making me do mental gymnastics while
reading mint source code.

~~~
mbo
Walder's Law states that:

    
    
          In any language design, the total time spent discussing
          a feature in this list is proportional to two raised to
          the power of its position.
               0. Semantics
               1. Syntax
               2. Lexical syntax
               3. Lexical syntax of comments
    

In future, I would suggest not nitpicking the most trivial, irrelevant detail
of a language's design. Please consider the level of effort it has taken to
create this language.

~~~
nkrisc
Small details are off-limits to criticism?

~~~
mbo
Yes

------
neurotrace
I actually love this. I don't foresee it replacing JS|TS for major app
development but this looks like the perfect fit for a certain subset of SPAs.
The syntax does a wonderful job of describing exactly what is needed for that
subset of applications

~~~
gdotdesign
Thanks :) I love reading comments like this ;)

------
pushpop
If the authors are reading this: The home page has some weird width issues
going on for me where content starts somewhere off the left of the screen and
ends somewhere off the other end. To compound the issue, I cannot scroll to
the left.

Device: iPhone XS (fully updated)

~~~
gdotdesign
Thanks for reporting this, will look into it!

~~~
pushpop
Thank you

For additional reference, it seems to be alternating sections starting below
the fold (man I hate that phrase)

------
codesections
This appears to be a compile-to-js language with a compiler/related tools
written in crystal.

An interesting use for a DSL.

------
oweqruiowe
Not imaginative enough IMO, I'm assuming since it's a new language you can
design it without the limitations we've had to design around in JS.

The magic sauce for me is a global state data structure where all my app state
goes into. And it should just be data. I don't need to wrap it in 'semantic'
constructs.

And then I need an easy way to query that, something more expressive than
`get-ins` like `state.path1.path2.value`.

However the state is accessed the component should just update. I don't want
to provide or connect.

~~~
bob1029
Global state in one happy place is basically what we've done with Blazor.

Instead of using cascading parameters and other ridiculously complex ways of
passing state around, we inject stateful services as scoped dependencies per
client request. These are effectively just POCO models with a functional
interface for mutating state. Then, we take dependencies on these throughout
the web application (I.e. within each component or page). An example of one of
these used heavily throughout would be UserSessionService. Certain aspects of
the application may have their own dedicated state machines like LoginService
(which is utilized only during the login process). LoginService takes a CTOR
dependency on UserSessionService and it all plays together really nicely via
Microsoft's DI.

We've even wired events from server-side directly into these services so its
not just for handling the client-specific interactions either. Integrating
server-side events is trivial. It felt a little weird at first, but it seems
we are moving in a much more sustainable direction now. I can actually test my
UI state machines in complete isolation from an actual browser. Also, because
they are simply .NET implementations, we can reuse these for other aspects of
the application.

~~~
adamkl
This sounds very similar to what we've been doing with XState[1] and React.

We have a "service layer" for React made up of state-machine-based services
(although reactive services based on RxJS observables works as well). We also
created associated custom hooks that allow developers to easily "inject" a
service into their React component (use use React's Context API for our "DI
container"). From there they can read the service state, or send events to it
to trigger behaviour that is encapsulated in the service itself.

We even have the same "most used" service; a UserSession service manages OAuth
based login flow and session management.

The best part of this approach is that our service layer started in an Angular
based proof-of-concept before we lifted-and-shifted it all into React.

[1] [https://xstate.js.org/](https://xstate.js.org/)

~~~
IggleSniggle
How much does the react wrapper do? Ie how easy would it be to support Angular
or Vue? I imagine just aligning syntactic conventions?

~~~
adamkl
React wrapper doesn’t do much, and it is very easy to port to other UI
frameworks.

Here’s a follow-up post with a gist of what the React integration looks like.

[https://news.ycombinator.com/item?id=22294087](https://news.ycombinator.com/item?id=22294087)

------
ghego1
From a - admittedly superficial - first look I couldn't understand if mint is
able to produce a static file as well.

If it Didi I think it would be a major advantage over react, angular and Vue.
Of course all these support the creation of a static file, but it's not
trivial and it feels like an hack more than a feature.

Therefore if mint has/had the option to produce (also) a static website, I
think it would have very nice use cases

------
nojvek
Mint looks nice, but I am worried about the tooling. It feels it’s trying to
do too many things.

Don’t get me wrong. I really applaud the effort and it’s great. I’m just
telling you why I wouldn’t use it. I’ve been building SPA’s for over a decade
and have had my lessons. Things are complex for a reason when it comes to
large code bases contributed to by a large team.

At a previous workspace we used pug(jade). Great language but it’s just not
about the language. The tooling around the language really matters. You want
linters, prettifiers, typecheckers, sourcemaps, dependency analyzers, good ide
code completion, auto doc generators, etc to work with it.

Making a language with good ecosystem is really hard.

That’s why I prefer to stick to well supported proven basics.

Typescript, prettier, jsx, eslint, webpack, stylint, scss, css modules etc

Small well supported tools that do one thing really well and work with other
tools. (Unix philosophy)

------
jsf01
I like the idea of being able to use the same variables in css, js, and the
rendered components, like you’ve achieved in this language. It seems like a
problem everyone’s trying to solve in different ways but there still isn’t
anything that feels just right. My gut reaction, without having tried this
language yet, is that lacking finer grained control over everything the
browser is capable of, there will come a use case that this language can’t
handle (or can’t handle as nicely) as native browser languages would and such
limitations will be major in any sort of complex application. That said, I’m
excited to give this a try. Always appreciate novel approaches to the problems
I face in my everyday work.

Side note—your site doesn’t render well on a mobile device. The whole left
side of the page is cutoff. Might want to look into that.

------
max0563
Before I start this rant I want to say that I appreciate authors who put work
into trying to solve hard problems. These are hard problems and I think at
least trying to make a step in the right direction is a good step.

I feel like we are approaching the problem of frontend development complexity
the wrong way. These new frameworks and domain specific languages fail to cut
through the complexity of the real problem and instead mask the complexity
with shiny new frameworks. These frameworks still all suffer from the same
problems.

There are deeper issues that need to be addressed. The fact that their landing
page doesn’t work well on mobile is evidence of that. Assuming it was created
using Mint.

~~~
gdotdesign
I think you are right about that. Mint is not a solution of the whole front-
end development but a part of that, it tries to solve the problem of single-
page applications specifically.

> There are deeper issues that need to be addressed. The fact that their
> landing page doesn’t work well on mobile is evidence of that. Assuming it
> was created using Mint.

Actually it's not created in Mint and that it doesn’t work well on mobile is
the evidence that I didn't tested it thoroughly :D

------
lenkite
Clojurescript solves the impedance mismatch for front end apps elegantly. An
all-in-one framework like Fulcro also solves the analysis-paralysis issue of
making effective library choices for everything

------
joekinley
Looks like a similar idea to Elm

~~~
robotron
The Mint Guide page (Learn link) discusses Elm and it being one of the roots
of this language.

> What is wrong with 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.

------
lwb
Looks pretty cool. I'd love to see a side-by-side comparing the same
application in say, React/Vue/Angular/Elm and Mint.

~~~
gdotdesign
I've done an article about comparing it with React it a while back, the code
shown there might be outdated but not much:

[https://dev.to/gdotdesign/mint-vs-javascript-
stack-15id](https://dev.to/gdotdesign/mint-vs-javascript-stack-15id)

~~~
lwb
That's pretty compelling. If mint sticks around for a while I will definitely
consider it for future projects.

------
venuur
Tried to read on mobile (iOS) but the second code block, maybe called state
management, is clipped and not readable.

------
taco_emoji
From the install page:

> To easily install Crystal on MacOSX you can use Homebrew.

I think "Crystal" should be "Mint"...

~~~
channel_t
Uh, Mint is written Crystal.

~~~
taco_emoji
I realize that, but look at the page. It's pretty clearly a typo.

EDIT: it's been fixed now.

------
burlesona
Being able to declaratively write CSS properties based on the component state
is pretty sweet. Ie you can put “if active” in your CSS instead of putting
conditional logic on the markup. That’s the first thing that jumps of the page
for me with this project.

------
SlowRobotAhead
This aims to solve all the problems that Flutter already does. Except now with
XML syntax.

I didn’t like how “uncommon” Dart and Flutter were until I used them. But I’ve
really come around on both after starting to use them.

This though, cool, but I see no possibility of traction.

------
oliverx0
Wow this is very cool!! I really like the syntax and how the components are
structured

------
chmaynard
I tried to learn something about who or what is behind this language/platform.
The mint-lang website is not very revealing. Someone named Szikszai Gusztáv
appears to be a core contributor to the GitHub repo.

~~~
gdotdesign
I'm the author and main contributor of the language, let me know if you have
any questions, happy to answer :)

~~~
pier25
So how does it work? Does it use a virtual dom? How is the performance? What
about the bundle size?

The answers to those questions should be on your home page.

Also it would be great if you included it here:
[https://github.com/krausest/js-framework-
benchmark](https://github.com/krausest/js-framework-benchmark)

~~~
gdotdesign
Mint uses React as the view layer anything else is done by either the compiler
or the runtime(1).

So the bundle size should be around the same as react or smaller (the compiler
can output optimized code) and the performance is the same.

[1][https://github.com/mint-lang/mint-runtime](https://github.com/mint-
lang/mint-runtime)

~~~
pier25
Thanks. I skimmed over the docs but didn't find that mentioned anywhere.

Why not use something faster and smaller than React though like Preact or
Inferno?

~~~
gdotdesign
It is possible, but it turns out they are not a 100% compatible.

~~~
pier25
Not 100% compatible but much faster and lightweight:

[https://krausest.github.io/js-framework-
benchmark/current.ht...](https://krausest.github.io/js-framework-
benchmark/current.html)

------
couchand
I don't see any mention of server rendering. I would expect that to be a
necessary and fundamental concept for a language/toolchain specifically
designed for building single-page apps.

~~~
oweqruiowe
I agree, but do want to say that server-side rendering is a lot more
complicated than just "be able to render my app on the server as well". We
went down that road with a large app and the team was stoked and promising how
awesome it would be, but it turns out it just slowed down the experience and
users hated it.

I'm a lot more hesitant about SSR now. Users don't mind spinning wheels as
long as they can see something happening.

~~~
couchand
In a world faced with a climate crisis, client-side code faces the burden of
proving that it is worth the value. Unfortunately, today companies are free to
externalize their energy use by forcing users to run compute for them, in a
significantly less efficient environment, and repeatedly. This insanity should
not be allowed to continue.

A new language is in the perfect position to structure components so that they
can be cleanly rendered on a server first, and rehydrated on the client as-
needed. Trying to do that backwards will always result in less developer and
user satisfaction. That doesn't mean it's right to just keep doing things the
bad old way.

------
adgasf
This doesn't look sufficiently different to JavaScript with JSX.

~~~
untog
Being similar enough to the technology a huge number of people use doesn't
strike me as a _bad_ thing.

I don't think this is for me, but it's an interesting experiment and I could
immediately grok what it was doing.

~~~
adgasf
If the differences are only minor then what does it enable that the more
popular alternative does not?

You're right the familiarity is a good thing though - just look at TypeScript!

~~~
untog
> If the differences are only minor then what does it enable that the more
> popular alternative does not?

Fair point. I think there's a tradeoff in there somewhere. The fact that you
need to do things like wrap JavaScript in order to use it within Mint sets off
all kinds of alarm bells for me. I still like the concept, but justifying an
entirely new language (to myself, to my higher ups, to the company at large)
is a high bar.

------
dang
A thread from 2018:
[https://news.ycombinator.com/item?id=17161533](https://news.ycombinator.com/item?id=17161533)

------
_fullpint
Some of the stuff does t fit correctly on an iPhone 6-8 screen.

------
JDiculous
This actually looks pretty cool. It's extraordinarily ambitious to create
one's own language for frontend development, but I think you did a decent job.

------
arjunbajaj
Can you comment on the differences/advantages compared to Elm in terms of type
safety, helpful error messages, no runtime errors, and other features?

~~~
gdotdesign
Since I used Elm before and after I lost interest I wanted have the same
experience, so I created Mint.

It has a similar type system (HM) nice error messages, ADTs and if you don't
do JS interop then no runtime errors.

~~~
arjunbajaj
I am considering using Elm soon. Can you talk about why you lost interest?
Somethings that are better done in Mint than Elm?

~~~
gdotdesign
Rounting, styling and data storage is much better and easier to do.

I lost interest beacuse I wanted to help/influence it's the development but my
ideas weren't welcome and after two? years since then the problems are still
the same without a solution in sight.

~~~
arjunbajaj
Thanks! I'll give Mint a try too! :)

------
JulianWasTaken
What happens if you want an entirely different kind of e.g. routing -- say
traversal-based routing instead of simple matching-based routing?

------
luord
Seems kind of like QT for the web (obviously very different, but the same
general idea). I like it, shall try it out.

------
bluebasket
seems to be written in the crystal programming language, which i am
discovering here too. looks very much like ruby to me.

------
thelittlenag
This looks like a DSL on top of React.

------
viach
Wondering how could I use my favourite React calendar and paginated table
components with it.

~~~
gdotdesign
Actually Mint uses React under the hood, I haven't figured out how to work
with existing packages but it should be very possible.

------
jslakro
All evolution to get at this moment we realize an HTA's were not too wrong

------
jstrong
one thing that confused me, why does incrementing an integer require returning
a future?

------
holtalanm
would be neat to see an implementation of the realworld app with Mint.
[https://github.com/gothinkster/realworld](https://github.com/gothinkster/realworld)

~~~
gdotdesign
There you go: [https://github.com/mint-lang/mint-
realworld](https://github.com/mint-lang/mint-realworld) ;)

It maybe a little bit outdated but it should get the point across, also the
demo seems to be offline, I'll check in the morning and get back to you :)

------
holtalanm
suggestion for your documentation page: add id's to your h2 elements so it is
easy to send a link directly to the section you're looking at to a
friend/coworker.

~~~
gdotdesign
Thanks for pointing it out, will do ;)

------
holtalanm
no windows installer :(

I'll have to try out the docker container solution, I suppose. I uninstalled
the WSL a while back, and don't really want to go back down that rabbit hole.

------
Lapsa
Can I use backtics for inline CoffeeScript code easily?

------
AllegedAlec
Not to be confused with:

\- Mint, the Linux distro

\- Mint, the web-analytics tool

\- Mint, the motion controller programming language

~~~
dudul
The Elixir HTTP client [https://github.com/elixir-
mint/mint](https://github.com/elixir-mint/mint)

What is so great about the word "Mint"?

~~~
chrisseaton
> What is so great about the word "Mint"?

It is English slang for something very good, very neat, very clever, very
sharp.

~~~
jmkni
[https://www.urbandictionary.co/define.php?term=That%27s%20mi...](https://www.urbandictionary.co/define.php?term=That%27s%20mint)

------
jb3689
This feels like a repackaging of ideas that have been around for awhile. I'm
not sure I see the value prop of this over stitching together more loosely
coupled solutions that have more of a support base. This looks more cohesive
overall, but that cohesion doesn't seem worth the headache of the (likely)
possibility of this losing favor in a few years

------
jmull
A new language might be fun to work on, but it's a massive negative in terms
of anyone adopting a framework based on it, and in terms of the resources
needed to maintain and improve the framework.

Likewise, it would be more efficient to embed one of the many existing "better
CSS"s than do another one.

It's sad to say so, given how much work seems to have gone into this, but it
looks DOA to me.

