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.
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.
agreed - learning the full react/redux stack is something that's viewed as "hard" for sure by many. with justification. this looks cognitively much simpler. thank you.
Thanks for replying. I hope I didn't come off as too arrogant or bashful. I do see your point with having tiny dependencies and reducing cognitive load. I have projects balloon up in size. I think the small dependency is a point you should highlight on your website. With regards to the JS interoperability, does Mint play well with libraries from the JS ecosystem?
(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...?
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 valid points, but as another data point for my personal use case - creating a single web app - all the points the creator writes resonate.
I've no interest in going to documentation in various places and dislike large dependencies so if the app works as mentioned the value proposition resonates.
Will check it out later this weekend!
I think Mint is easier to be learnt for people who don't know both Mint and the Javascript world.
If people already knows Javascript, it's not a fair comparison.
This story is similar to Elm. I tried to teach people without programming experience at all, they don't have bias or preference so those 'alternative languages' looks good to them. But to convince the 'legacy world' is a tough work. Anyway, appreciate the work of Mint :)
Just to play devil's advocate, you may not see the advantage, because you already know about all of those options.
There's a fair amount of library discovery/evaluation overhead needed to get a fresh start in the React ecosystem, and the people who have to do it often don't have the perspective/context to make good choices efficiently.
I started learning react a few weeks ago and I've been using react-router and thinking about learning styled components or something similar. I have a few years of "experience" with toy <5000LoC "webapps".
I don't think they're that hard to discover, although I spent a while trying other Google searches before I realized react-training's react-router was the real router everyone mentions. Somehow their website seemed quite scammy, and I was very surprised routing wasn't in some sort of core/stdlib.
It's also important to note that not all developers have the same constraints.
If your employment prospects don't depend on using the major frameworks that everyone else is using, you're probably going to choose (or even create) a framework that best fits with the way you think and the way you like to work.
It would be nice if there were a way to re-think what we have built on top of Node, and NPM or Yarn, to have a great front end framework built using a language with a standard library, rather than a jaw-dropping hierarchy of dependencies.
There are already at least two languages like this I can think of with good standard libraries, and good frontend support (Elm and Dart). But adoption of both is low. I don't think it's a coincidence, nor do I think it's just a product of circumstances. People are still going to use JavaScript, no matter how many better things are out there.
My favorite part about Create A React App is the tens of thousands of reported bugs/issues, hidden black box magic configuration, 38,000 files, nearly 300MB of code for a hello world and the one way eject feature.
My favorite part about CRA is none of those things ever being an issue for me or my users, so I can prototype feature-rich apps in like a couple hours.
The syntax is a little cleaner (and presumably more constrained). Only a little bit, but scaled across a large project maintained by multiple people I could imagine it being a real benefit over JS/React's syntactic overhead and dependence on conventions.
You might like dev.to which is a blog platform/community for developers. Users can choose which topics they are interested to and see content relevant to those.
I find Wire(wire.com) to be well designed and usable, especially their mac client. Only issue I have with Wire is having no anonymous sign up and having to rely on a central server to add contacts but the former can be worked around by using a temporary email.
I take issue with having to provide a cell phone number for Signal. I just hope Tox clients get more polished and more usable as every client I've used except toxic has been terribly buggy.
In addition, their server-side code is open-source and they claimed that federation support is something they are considering to add: https://github.com/wireapp/wire/issues/160
Just want to add onto this that pretty much everything Wire makes is open source. The backend (written in Haskell no less, which continues to amaze me), the desktop app and the mobile apps.
I would also recommend FreeCodeCamp(https://www.freecodecamp.org/) which partners with charities that need developer help. FCC also has great tutorials that you may find helpful.
