gdotdesign

Just a few days ago the apartment above ours burned down alledegly because of an explosion of an ebike battery. They left it charging overnight and exploded in the morning. Fortunately nobody got hurt, but it was really scary experience.

I've done something similar for the Mint, and it's try page: https://mint-lang.com/sandbox/try (and all interactive snippets).

The client (CodeMirror) connects to the language server though WebSocket to offer semantic highlighting and some custom LSP actions related to compiling and serving the project.

> have you thought about including Form Validation to the core lib?

There is a module for that in the standard library (https://mint-lang.com/api/Validation). Moving the functionality into the language level is intriguing.

Thank you! And it's written in Mint :D

With Mint (https://mint-lang.com/) I'm trying to move away from frameworks in a language to the language being the framework — having abstractions for things which are done by packages and frameworks like components, localization, routing, etc... done in the language itself.

This means that in theory the backend/runtime can be replaced (and was replaced ones from React to Preact (0.7.0 -> 0.8.0) then to use hooks and signals instead of class components (0.19.0 -> 0.20.0), and the code will remain the same.

This has one drawback which deters framework creators from choosing the language since there is no reason to innovate on something that is already "done", which leads to fewer people using it in general and hinders adoption, but I'm still optimistic.

Technically you can yes, but the language doesn't support it out of the box, you need to jump through hoops to make it work.

But you are right, I'll change TypeScript to say it's partially supported.

- The type system documentation is here: https://mint-lang.com/reference/types/type-system - in short it's a functional language at heart with a Hindley–Milner type system

- TypeScript syntax comparison is here: https://mint-lang.com/from/typescript

- The feature matrix which compares languages features is here: https://mint-lang.com/feature-matrix

I hope you find those helpful :)

In the last 8 years, we had two kids and I have a full-time job, so Mint was/is a side project with virtually no marketing.

Yes, it is a bit of torture :) however I'm getting there. Context (https://mint-lang.com/news/context) was the last bigger feature before 1.0 which I'm planning to release this year.

If you want something that is similar but looks better and more mature, check out Mint (mint-lang.com - I'm the author)

Hi! I've created this page to showcase the features of Mint (since there are so many) and their corresponding versions in other similar languages.

I'll keep expanding this with other languages in the space.

The compiler can inject information at compile time so no runtime reflection is necessary.

It depends on the thing you want to create. The browser UI controls are limited at best, keep your expectations low.

Writing Vanilla JS is error-prone unless you are very disciplined, writing "Vanilla" CSS is OK for the most part, Vanilla HTML is fine. It's best to use some tooling, but there are dozens to choose from.

You are right :) I'm planning on adding a lot more features in the future though, like the ones you said.

I'm working on it in my spare time, so things are going slow.

Check out DevBox https://www.dev-box.app/ (I'm the developer) It has most of the utilities of DevUtils and actually more :)

Thank you for reminding me :)

If you are not on macOS and like something similar check out DevBox https://www.dev-box.app/ It has most of the utilities as DevUtils.

It's available on macOS, Windows, Linux and as Chrome and Firefox extensions. (edit) I'm the developer of DevBox.

If you want something like that, check out Mint (www.mint-lang.com) :)

It's not a framework per se, but you can give Mint (www.mint-lang.com) a try :)

It's specially created for SPAs.

> This looks very cool.

Thanks :)

> Do you have a roadmap?

It's no written roadmap yet, currently I'm working on a UI library which is written in Mint, and these are things which the majority of people want which I'll work on next:

- Language Server

- Server Side Rendering

- Interfacing with NPM libraries

- Some new language features and cleanup of some of the existing ones

- A proper Time module

After those I think we can release 1.0 and focus on bugfixes and optimizations.

> I would like something like Elm, but Elm doesn't interoperate with JS.

You can try Mint: https://www.mint-lang.com

I've created it because I wanted something like Elm but with easier JS interop and less boilerplate :)

I've build the backend of Base API, and the Mint programming language in it.

Base API runs on Heroku and it's memory consumption is really low (around 20Mb on average) also it's slug size is 3.3MB.

I think it's a really good language, the syntax is way more clearer then any of the other similar languages (Go, Rust, Nim).

It has two problems currently as far as I can tell: - Windows support - when it hits there is no reason for me to use anything else, I'll be able to write desktop applications in it with a Webview or CLI apps - Lack of mature libraries - in time I think this will remedy itself

Base API: www.base-api.io Mint: www.mint-lang.com

Thanks :)

Mint has what Svelte doesn't:

- consistent language with a good type system - at its base it is a functional language - styling is built in - https://www.mint-lang.com/guide/reference/components/styling... - routing is built in - https://www.mint-lang.com/guide/reference/routing - language constructs for error handling - language constructs for asynchronous tasks - compiles to Preact so the build output is small - easy JavaScript interopability

Svelte has what Mint doesn't:

- it is basically JavaScript compiler - different syntax for template (HTML) vs code - code is just mostly JavaScript and can use NPM packages (I think) - have their own runtime without virtual DOM - transitions and animations are built in - reactive by default (without the need for language constructs)

I haven't really played around with Svelte though so I might be a bit biased. I suggest that you try both a see what you like more.

Let me know if I can help with that :)

I've invested a lot of time in Elm about two-to-three years ago, the two main things was elm-ui [1] and elm-github-install [2]. At the time elm-ui was impossible to build without "native code" so I used it and built elm-github-install to make it work.

Suffice to say, I've run into the exact same issues as the author. Had they allowed me to contribute in a meaningful way Elm now would have a nice UI library and probably a much nicer package website which I've developed as well [3] (no longer running, but I've turned maintenance mode off for a few days so you can take a look).

I stopped using and contributing to Elm when 0.19 came out. If you are interested how much effort I put in just check the Elm related repositories in my Github profile [4].

After that I missed the developer experience and I created Mint [5], so in the end some of knowledge I gathered during that time have been put to good use :)

I just can't understand how they could ignore all the work I've put in, if someone would invest that much time and effort into Mint (or any open source project of mine) I would welcome it and or at least start a dialog on how we could integrate their work into the language.

Anyway, I thought I share my Elm story with you (although probably a bit late :))

Cheers

[1] https://github.com/gdotdesign/elm-ui

[2] https://github.com/gdotdesign/elm-github-install

[3] http://elm-directory.herokuapp.com/ https://github.com/gdotdesign/elm-directory

[4] https://github.com/gdotdesign?tab=repositories&q=elm-&type=s...

[5] https://www.mint-lang.com/ https://github.com/mint-lang/mint

Rounting, styling and data storage is much better and easier to do.

I lost interest beacuse I wanted to help/influence it's the development but my ideas weren't welcome and after two? years since then the problems are still the same without a solution in sight.

It is possible, but it turns out they are not a 100% compatible.

Since I used Elm before and after I lost interest I wanted have the same experience, so I created Mint.

It has a similar type system (HM) nice error messages, ADTs and if you don't do JS interop then no runtime errors.

Mint is written in Crystal when they finish their implementation it will be possible to compile to Windows.

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

It steps the sate forward, think of it as `this.setState`.

Mint uses React as the view layer anything else is done by either the compiler or the runtime(1).

So the bundle size should be around the same as react or smaller (the compiler can output optimized code) and the performance is the same.

[1]https://github.com/mint-lang/mint-runtime