| (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...? |
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).