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/) and the front-end is in Mint and it has 0 dependencies (other than the standard library which is built in).
> 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.
> 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.
a quick comment on base-api, the API in other languages are readable but not so in js, you used long (unamed) argument instead of (keyed) object, which is a bad practice IMO, also why is the `key => value` pair in the form submit using array-function?
As I was reading the page, I kept thinking this feels very similar to Elm, but without the functional programming part. I assume that was on purpose to not scare people away.
Anyway, nice job! The language looks really clean.
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/) and the front-end is in Mint and it has 0 dependencies (other than the standard library which is built in).