I wonder if this will hobble adoption somewhat on Windows until proper Crystal win32 target support arrives though. You can run Crystal apps in WSL but more steps = less users.
Interesting. I applaud the determination, however I don’t see any mention of how one might leverage existing third-party npm modules. I don’t write SPAs from scratch in a vacuum; I use a framework and several modules that meet the needs of the SPA being built. Things like Vue, Underscore, Moment, and stuff for SCSS, authentication, oauth, REST calls, GraphQL, charting, animation, i18n, l10n. The Mint ecosystem needs to have an answer for these needs, whether community-provided, or a way to use existing npms.
So it might be just a matter of setting up a transpilation pipeline and directly injecting any JavaScript you want. Admittedly I haven’t use Mint so I can’t say for sure.
As to the ecosystem, I think their hope is to spawn a new Mint ecosystem. They’ve set up a package index here: https://www.mint-lang.com/packages
What would be the advantage over using an existing language like ClojureScript. It looks like you could do everything Mint does in a ClojureScript right now. For example, here’s what an SPA would look like. You can specify HTML using regular data structures instead of having additional syntax, and do inline CSS styling. There is robust state management available with re-frame and routing with reitit. In addition, ClojureScript provides hot loading out of the box, code splitting, pruning code down to function level, and robust library management.
If you’re comparing lists of things you can do with different front-end languages and frameworks, I think you’ll find relatively little to distinguish any of them. ClojureScript has been around for a while now and certainly has lots of great things going for it.
However from what I gather on the website, Mint provides a significantly different development experience compared with ClojureScript that some people might prefer. It explicitly takes a lot of inspiration from Elm, and has a similar type system. If you strongly prefer ClojureScript to Elm, and find that the trade-offs of compile-time type checking don’t work well with the way you like to write programs, then I expect you’ll likely also prefer ClojureScript to Mint.
Meanwhile some people enjoy working with a compiler that checks types for them. They like using records and sum types to model data, and enjoy having a compiler that helps them make sure they are using those types the way they were designed to be used. They enjoy how the compiler can guide them in refactoring with confidence. They find that very rarely having to deal with runtime exceptions is worth a lot to them. They like the way that all of these factors change the way that they approach problems.
But maybe they are also not completely satisfied with Elm, ReasonML, PureScript, or whatever other similar front-end languages they may have tried. In that case Mint might be worth investigating as a possible alternative.
ClojureScript is just an example I’m personally familiar with, but as you note there are plenty of statically typed languages that compile to Js as well. If Elm is too restrictive, there’s also Reason, which is basically OCaml, and a few others. At the end of the day I’m just not seeing any differences between these languages that result in significant productivity gains for the developers. Personally, I’d much rather see effort going to improving tooling and overall developer experience for existing languages than seeing yet another language that makes some slightly different trade offs from half a dozen existing ones.
If people feel that the problem Mint is solving is justified who am I to argue though. :)
Nice to see Crystal out in the wild (the compiler is written in Crystal).
As a Rubyist, it’d be nice to see a write-your-own-compiler guide written in Crystal (or Ruby, for that matter).
Like this?
Yes, thanks!
I wonder if this will hobble adoption somewhat on Windows until proper Crystal win32 target support arrives though. You can run Crystal apps in WSL but more steps = less users.
Oh yeah, I forgot that they’re still working on Windows support.
Interesting. I applaud the determination, however I don’t see any mention of how one might leverage existing third-party npm modules. I don’t write SPAs from scratch in a vacuum; I use a framework and several modules that meet the needs of the SPA being built. Things like Vue, Underscore, Moment, and stuff for SCSS, authentication, oauth, REST calls, GraphQL, charting, animation, i18n, l10n. The Mint ecosystem needs to have an answer for these needs, whether community-provided, or a way to use existing npms.
Looks like Mint code can interpolate arbitrary JavaScript: https://www.mint-lang.com/guide/reference/javascript-interop
So it might be just a matter of setting up a transpilation pipeline and directly injecting any JavaScript you want. Admittedly I haven’t use Mint so I can’t say for sure.
As to the ecosystem, I think their hope is to spawn a new Mint ecosystem. They’ve set up a package index here: https://www.mint-lang.com/packages
What would be the advantage over using an existing language like ClojureScript. It looks like you could do everything Mint does in a ClojureScript right now. For example, here’s what an SPA would look like. You can specify HTML using regular data structures instead of having additional syntax, and do inline CSS styling. There is robust state management available with re-frame and routing with reitit. In addition, ClojureScript provides hot loading out of the box, code splitting, pruning code down to function level, and robust library management.
If you’re comparing lists of things you can do with different front-end languages and frameworks, I think you’ll find relatively little to distinguish any of them. ClojureScript has been around for a while now and certainly has lots of great things going for it.
However from what I gather on the website, Mint provides a significantly different development experience compared with ClojureScript that some people might prefer. It explicitly takes a lot of inspiration from Elm, and has a similar type system. If you strongly prefer ClojureScript to Elm, and find that the trade-offs of compile-time type checking don’t work well with the way you like to write programs, then I expect you’ll likely also prefer ClojureScript to Mint.
Meanwhile some people enjoy working with a compiler that checks types for them. They like using records and sum types to model data, and enjoy having a compiler that helps them make sure they are using those types the way they were designed to be used. They enjoy how the compiler can guide them in refactoring with confidence. They find that very rarely having to deal with runtime exceptions is worth a lot to them. They like the way that all of these factors change the way that they approach problems.
But maybe they are also not completely satisfied with Elm, ReasonML, PureScript, or whatever other similar front-end languages they may have tried. In that case Mint might be worth investigating as a possible alternative.
Compared with Elm, Mint’s website makes the case explicitly: https://www.mint-lang.com/guide
Compared with ReasonML, Mint seems to be aiming for a more polished and unified developer experience.
Compared with PureScript, Mint’s type system is much more simplified, like Elm’s, with the usual trade-offs that implies.
As always, if you are happy with your current tools then that’s great!
ClojureScript is just an example I’m personally familiar with, but as you note there are plenty of statically typed languages that compile to Js as well. If Elm is too restrictive, there’s also Reason, which is basically OCaml, and a few others. At the end of the day I’m just not seeing any differences between these languages that result in significant productivity gains for the developers. Personally, I’d much rather see effort going to improving tooling and overall developer experience for existing languages than seeing yet another language that makes some slightly different trade offs from half a dozen existing ones.
If people feel that the problem Mint is solving is justified who am I to argue though. :)
Is there SSR support?