Skip to content
loading...

Mint - A refreshing programming language for the front-end web

Szikszai Gusztáv on July 11, 2018

TL;DR: Mint is a typed programming language which compiles to JavaScript for building single page applications. https://www.mint-lang.com ... [Read Full]
markdown guide
 

You forget Dart in the list of typed language. Furthermore dart is the language of flutter.io therefore you will learn to develop progressive web app, web components and native application for Android and iOS. Conclusion it is better to learn Dart if you want to learn a strong types language.

 

Is Flutter gaining much popularity these days? Dart was just a blip on the radar the last I checked. 😣

 

It's gaining a lot of popularity. Flutter especially is gaining a lot of popularity.

Hi, I did check out Dart and was blown away how well designed it was! Now, my concern is, if I start messing with Flutter, I'll run into many problems of missing libraries, etc., which will be a pain in the behind. So, I guess Flutter is nice to explore and all, but for solid business work one should stick to native stuff?

Choosing to use a hybrid app platform can be a tough decision, especially with how many choices developers have now adays: Cordova, Ionic, NativeScript, React Native, Flutter... The list goes on and on.

There are going to be pros and cons with all of these options if you compare them to true native apps: managing 2 sources vs 1 (which, if you're lucky, won't turn into 3), the amount of support you can get, the tools and libraries available to you, etc.

Here are some perspectives from individuals who have used these frameworks professionally:

youtu.be/MeBNODUCLfc
medium.com/airbnb-engineering/suns...

A good comparison of hybrid app frameworks:

youtu.be/rb8smP_xTTY

Very instructive. Now I'm even more sold on using "boring", established technologies, no matter how bland they seem.

 

Solid press release.

Seems legit. Only thought it this seems like language-as-framework, strongly integrated and tooled for mv*, web components. There's nothing wrong with this model, it has worked for other technologies and I don't see the fundamental concepts evaporating anytime soon.

That said, some questions:

How open are its constructs to extension to support future patterns and strategies?

Are you looking at a wasm compiler target as well?

Do you have a bnf grammar for the language?

 

Thanks for the comment!

How open are its constructs to extension to support future patterns and strategies?

The language and the compiler is structured to be easily extendable, so supporting future patterns should be easy.

Are you looking at a wasm compiler target as well?

It's not likely, as WASM is still very young, maybe once it matured enough. Check out this issue for further information: github.com/mint-lang/mint/issues/4...

Do you have a bnf grammar for the language?

No, if there is enough interest one can be created.

 

I love to see Innovation and wheel reinvention (not saying it in a bad way). People often like to say why to create something that has already been created, but that's precisely how we arrived to the loved angular/react/vue mainstream combo today, the three reinvented someone else's wheel and I'm pretty sure people often said that when these things were very new.

I think new concepts, langs like these are the reflection of how our actual wheels are going, and this seems a fine and precise work on how to correct some issues that people are still facing today.

Question

I would just ask if there's the intention of using mint to compile web component projects (something like what polymer tries to do), I think this is a good place where Mint can target and be succesfull taking in mind that components are already the building blocks of the language.

 

Thank you for that comment!

It could certainly be compiled to web components, it's technically possible, but I don't think it's the right way to go:

  • the spec is not very well supported: caniuse.com/#search=web%20components it can be polyfilled but that's not ideal.

  • if components would be reused outside of the language then we would lose type safety or we would need to implement runtime type checking on the boundaries.

  • there is no spec as far as I am aware for virtual DOM to be implemented in a browser, dropping this requirement would mean that either the implementation still have to be in the application or we would lose performance rendering with innerHTML.

 

We need to add this to the vast list of existing javascript frameworks. en.m.wikipedia.org/wiki/List_of_Ja...

Keep'em coming. It is never enough.

 

A couple of other languages, that compiled to JS sort of "died" in the past year, yet you create a new one. So the most serious questions are:

  1. You are about to compete with TypeScript - do you believe you can catch up? They are many years ahead plus they are very very close to JS and people with JS background can start using it right away with minimal changes in their habits.
  2. Your decentralised package manager is going to compete with npm and it's enormously big codebase. Will you build some sort of package import and how do you plan to attract developers?
 

Thank you for the comment, here are my answers:

  1. As you wrote TypeScript is very similar to JavaScript and Mint is very different from both, it has more things in common with Elm or Reason so that can be one of the factors. I think that the main reason people might use Mint is that it's compact, it has all the tools needed in one single binary, only one thing to learn.

  2. The idea for a decentralized package manager is actually coming from the Crystal programming language (which the compiler is written in), it seems to be working for them so far. It really simplifies things because any Git repository can be a package so there are no servers to manage, and for private packages the only thing needed is an SSH key.

Will you build some sort of package import

NPM packages are not compatible with Mint packages, it's easy to include external JavaScript files in a package so porting popular libraries should not be a big issue.

how do you plan to attract developers?

It will be difficult for sure. I am planning to write many posts about the parts of the language for education purposes, posts about how it compares to an other language, and Mint packages and applications for demonstration purposes.

 

What language Mint is similar to is irrelevant. If the language is superior to another is also irrelevant. Take for example PHP - it's not superior to any language. It's actually a big pile of crap, yet it became popular.

If you will compete with other languages you need to consider all other pieces of the ecosystem like NPM packages and compatibility with already existing software. TypeScript is very close to JS and it can use existing NPM packages without any effort. With minimal effort they get type information too.

JS is very very popular at the moment, not so sure about Elm and definitely not Crystal or Reason (I had to google these and I have over 20 years of experience and I tend to keep the pace and know what is going on around here).

My point is, that choosing this language over JS or TypeScript for a project seems to be a hard business decision and only a few companies may risk investing in it...

 

Okay, so why not Elm? A fairly well established strongly typed language that compiles to JS and does most things that you mention ...

 

Thanks for the comment!

I'm going to write a more lengthy post about it, but in short:

I used Elm for a while, it is a nice developer experience. It made me realize that there is a better way to develop things. I tried to expand that ecosystem and contribute to the community (check out my Github repositories if like) but it didn't turn out well, since my vision is different then their core teams.

But in my experience (and opinion) it's really restricting (both development and community wise), it has a lot of unnecessary boilerplate an doesn't address the main issues well:

  • there are no components, everything is a function
  • there is no local state so reusing logic is difficult
  • styling, routing, testing is done with a third party package
  • it is more academic then useful, for example there are more data structure packages and less UI / component like packages
  • it is constantly changes with every release, things that are working fine are refactored for reasons I cannot fathom
  • interacting with Web APIs which don't have an official package is a hard

I could probably go on for a while but so I'll stop now :)

 

Umm, and how does Mint overcome these, especially the small ecosystem challenge? It's worth noting that Elm can be incrementally added to your application in <script> tags, so I'm not sure if there are big issues with Elm.

 

Elm is a pure FP language, which is clearly not for everyone, that's probably the issue. Thanks for this incredible project (Mint lang), putting together a completely new programming language with all of the tooling around it ... impressive!

Question: how does this work with things like React, Virtual DOM, etcetera? Could you write React apps in Mint?

(however it's not recommended yet for production purposes? "Mint is currently in alpha stage, although it's usable for testing purposes")

 

Looks cool ! I'll keep an eye on this for sure 🤔

 

Lol to be honest those steps mentioned above sounds just like my process with frameworks/libraries like Angular or React.....

 

ROFL! Yes, I felt the same. It's not the ideal but the norm. 😂 But I think the author didn't sell the language correctly. It'd be worthwhile to check it out and see why he considers it a better developer experience.

 

Going to check this out. Looks refreshing - hence a really good name. :)

code of conduct - report abuse