> If the differences are only minor then what does it enable that the more popular alternative does not?
Fair point. I think there's a tradeoff in there somewhere. The fact that you need to do things like wrap JavaScript in order to use it within Mint sets off all kinds of alarm bells for me. I still like the concept, but justifying an entirely new language (to myself, to my higher ups, to the company at large) is a high bar.
Yeah Vuejs was super similar to angular 1.0 that at first I thought why the heck would anyone use this clone framework. But just after using it once I realized how it had taken everything good from ang 1, dropped everything that sucked (di, decorator,etc) creating a super awesome version of it.
So yeah it isn't bad if it looks similar to something lots of people already use.
Yeah, I am too, although I'm not entirely opposed to using them with JS, it would be nice. I always wondered why you can't reuse HTML code. I think Components are the obvious way forward.
You won't be able to do that in the forseeable future.
Multiple reasons why:
- Rich Harris (author of Svelte): eager (when laziness is preferable), styling is problematic, add confusion to attributes vs. props with disastrous ergonomics, leaky design, bad underlying model (DOM), global namespace [1]
- Serhii Kulykov (building Vaadin, a Web Components library): no form participation, broken autofill, broken accessibility, breaks SVG references, cannot extend built-in elements, handling focus, handling selection [2]
- Sarah Mei (Salesforce UX): Web Components break accessibility and assistive technology [3]
On top of that, you will always need a library/framework on top of them to orchestrate them, pass data around etc.
I tried to learn something about who or what is behind this language/platform. The mint-lang website is not very revealing. Someone named Szikszai Gusztáv appears to be a core contributor to the GitHub repo.
I know it's pretty amazing that this was created by by a small group of contributors. So many of the languages and tools these days are from enterprise giants like Flutter.
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.
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.
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.
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.
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.
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.
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.
(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).
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.
> 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?
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 :)
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?
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.
Lamenting the name of a thing is a Hacker News pastime. It’s a great way to get karma without contributing substantively to the discussion, or even reading the submission.
It’s often offered as if it’s good advice and the author was somehow completely unaware that other things might share the name, or that it will make SEO hard for a thing the commenter is likely to never want to search for.
I used to keep bookmarks of these comments, but then that became my Hacker News pastime and instead of enjoying the submissions and celebrating creators and hackers, I found I spent more time looking for people complaining about the names of things, it was hell, and I was almost at name-rage catalog sobriety, until now.
If the authors are reading this: The home page has some weird width issues going on for me where content starts somewhere off the left of the screen and ends somewhere off the other end. To compound the issue, I cannot scroll to the left.
The Mint Guide page (Learn link) discusses Elm and it being one of the roots of this language.
> What is wrong with Elm?
> Elm has great developer experience, but it being a purely functional language leads to some boilerplate code and makes it harder to learn. Also, it's not possible to contribute or influence the language in any meaningful way.
Not imaginative enough IMO, I'm assuming since it's a new language you can design it without the limitations we've had to design around in JS.
The magic sauce for me is a global state data structure where all my app state goes into. And it should just be data. I don't need to wrap it in 'semantic' constructs.
And then I need an easy way to query that, something more expressive than `get-ins` like `state.path1.path2.value`.
However the state is accessed the component should just update. I don't want to provide or connect.
Global state in one happy place is basically what we've done with Blazor.
Instead of using cascading parameters and other ridiculously complex ways of passing state around, we inject stateful services as scoped dependencies per client request. These are effectively just POCO models with a functional interface for mutating state. Then, we take dependencies on these throughout the web application (I.e. within each component or page). An example of one of these used heavily throughout would be UserSessionService. Certain aspects of the application may have their own dedicated state machines like LoginService (which is utilized only during the login process). LoginService takes a CTOR dependency on UserSessionService and it all plays together really nicely via Microsoft's DI.
We've even wired events from server-side directly into these services so its not just for handling the client-specific interactions either. Integrating server-side events is trivial. It felt a little weird at first, but it seems we are moving in a much more sustainable direction now. I can actually test my UI state machines in complete isolation from an actual browser. Also, because they are simply .NET implementations, we can reuse these for other aspects of the application.
Holy, this is the first time I've heard of it, but it sounds really great.
> Instead of using cascading parameters and other ridiculously complex ways of passing state around
So much this! There are too many folks stuck in the 'container' component pattern when really you should never pass a prop that can be queried from state. Working like this results in a sustainable application that's flexible, like you _state_ xD
I'm going to give this a really close look, thank you.
We found similar frustrations with having state flow with the HTML structure. From a novice perspective I can see how that might seem desirable, especially considering how concise it looks for sample implementations when you are doing 2-way binding.
But, once you get into really complicated scenarios where structurally-unrelated components are statefully-related (e.g. navbar interacts with some component in an entirely unrelated modal), things get very nasty without some common arbiter of state being shared between these components. You can usually solve this in some way with all the SPA frameworks I've worked with, but Blazor is the first case where building these state machines as C# services has knock-on benefits that simply can't be ignored anymore IMO.
Overall, separation of state machines from the UI seems the be the theme, and certain technologies can do this a lot better than others.
This sounds very similar to what we've been doing with XState[1] and React.
We have a "service layer" for React made up of state-machine-based services (although reactive services based on RxJS observables works as well). We also created associated custom hooks that allow developers to easily "inject" a service into their React component (use use React's Context API for our "DI container"). From there they can read the service state, or send events to it to trigger behaviour that is encapsulated in the service itself.
We even have the same "most used" service; a UserSession service manages OAuth based login flow and session management.
The best part of this approach is that our service layer started in an Angular based proof-of-concept before we lifted-and-shifted it all into React.
I long for such a solution as well. There’s got to be a simpler way to essentially access a global singleton object without the culture set by something like Redux (and I’m using the word culture in a weird way, but I’m trying to avoid trite explanations such as ‘lots of boilerplate’ and ‘unintuitive/tedious wiring’ on an app architecture level).
I don't see any mention of server rendering. I would expect that to be a necessary and fundamental concept for a language/toolchain specifically designed for building single-page apps.
I agree, but do want to say that server-side rendering is a lot more complicated than just "be able to render my app on the server as well". We went down that road with a large app and the team was stoked and promising how awesome it would be, but it turns out it just slowed down the experience and users hated it.
I'm a lot more hesitant about SSR now. Users don't mind spinning wheels as long as they can see something happening.
In a world faced with a climate crisis, client-side code faces the burden of proving that it is worth the value. Unfortunately, today companies are free to externalize their energy use by forcing users to run compute for them, in a significantly less efficient environment, and repeatedly. This insanity should not be allowed to continue.
A new language is in the perfect position to structure components so that they can be cleanly rendered on a server first, and rehydrated on the client as-needed. Trying to do that backwards will always result in less developer and user satisfaction. That doesn't mean it's right to just keep doing things the bad old way.
I'm curious. A question for the author: What is it that you're aiming to improve over Vue + Typescript? Vue is opinionated and comes with single file components, a router, a store etc.
I've been wishing for a clean way to write a render function using JSX for every Vue component. Once I tried out React I fell in love with using ordinary JavaScript array methods instead of v-for directives and so on.
(I'm a student, hate webpack, and don't want to learn it's nuances for a few years. I know from googling this can be done with sufficient webpack config).
What I am aiming for is to move away from writing JavaScript or minimize it to the level where it's more controllable.
I've come from Elm where it is done in a very good way, but it's too restrictive, and I like react and it's expressiveness so I wanted to combine the two.
Vue is really good but at the end you are still writing JavaScript which is really hard to do in a safe way. And from my experience Typescript isn't 100% safe as well.
> What I am aiming for is to move away from writing JavaScript or minimize it to the level where it's more controllable.
Why is this a goal? Could you elaborate?
> And from my experience Typescript isn't 100% safe as well.
Does it need to be? In my experience, enforcing reasonable standards (don't allow escape hatches like the `any` type, or the `// @ts-ignore` comment band-aid) fosters pretty strong interfaces. I haven't really needed more from the type system. Has your experience been different?
I don't think there's any need to sealion the author on this.
To your first question: JS's warts are well understood. You must already acknowledge this if you're a TS fan.
To your second: TS isn't 'actually' safe, to the extent something like Elm is (i.e. very small chance of runtime errors). This is also no secret - there are lots of examples out there if you care to search for them.
JS is on an extreme end of the spectrum of language inconsistencies, and a lot of developers with extensive experience in other languages strongly prefer not to use it. That's partly why there are so many languages that transpile to JS so you don't have to suffer though actually writing it.
Further, UI development is an area where things can get messy very quickly. "Safe" languages often greatly minimize the kinds of bugs that are very easy to write in JS. This is one reason why Elm and Clojurescript have had years of adoption -- they by default make values immutable (and their entire programming paradigm doesn't actually require mutating most values ever) which removes a large class of common UI errors. There are other benefits as well.
I actually love this. I don't foresee it replacing JS|TS for major app development but this looks like the perfect fit for a certain subset of SPAs. The syntax does a wonderful job of describing exactly what is needed for that subset of applications
My first thought: an entirely new language for one domain?
But then I started looking at the examples and how styles and an xml-like syntax are given first-class support and it makes sense. It really is a hard problem to shove into an existing language, evidenced but all the transpiling that goes on now. Thanks for sharing!
Agreed. I browsed through the guide and at least at first glance it looks very well designed. Things like naming a node or a component (<Item as item>) that can then be used elsewhere look really clever. I'm curious what the actual code looks like for an example app like todomvc.
I appreciate the joke :) but I really didn't get the obvious at first (code => coffee autocomplete). I was distracted by the fact that this language transpiles to JS so coffee might be a reference or something.
JSX is a straight translation to JS functions/objects, this goes several steps further: The styling section is using imperative logic based on the component's current state.
Right. And the person they were responding to was evaluating Mint on the basis of "first class support" for declarative UIs in XML, where ostensibly Mint defeats React/Vue because they "require transpilation".
UI implementation (especially for the web) is a very hard problem. We've been trying to get it right for decades. This is a problem domain in need of attention. The CURRENT frontend paradigm (React/Redux SPA) is using a mix of technologies, which might benefit from consolidation and streamlining.
Being able to declaratively write CSS properties based on the component state is pretty sweet. Ie you can put “if active” in your CSS instead of putting conditional logic on the markup. That’s the first thing that jumps of the page for me with this project.
Fake news. Clojurescript today is a much more pragmatic and production ready option, more popular than Elm, Reason and Purescript, better than Scalajs and KotlinJs and definitely much better than JavaScript and Typescript.
That's false. In Clojure pretty much every single line of code has a minimum of two parenthesis (opening and closing). You can get all defensive about it, and of course one's perception of it is entirely subjective, but it's the main reason I don't use it.
> In Clojure pretty much every single line of code has a minimum of two parenthesis (opening and closing).
Its a rare line of JS that doesn't include at least one of a conditional, a function call or definition, or grouping parens, outside of declarations. If you use "parens" broadly to include square, angle, and curly braces, JSX and declarations have plenty, too (and if you don't use "parens" that inclusively, Clojure/ClojureScript doesn't have all that many, because of its use of different delimiters for different purposes, unlike classical Lisp-family languages.)
It's okay. A few years ago, I was in the same boat. Even if I completely believed that eating cocaine for breakfast is somehow beneficial for your health, that still would not be on the same level of how wrong was my prejudice against Lisp. Oh boy, I was so wrong about Clojure.
I was working for a startup, building a .Net project with Angular 1.x. And I was on a failing trajectory - code was full of holes, I was struggling to finish things on time, I was stressed, I started to hate things for no apparent reason. Finally, after years of writing software, I just wanted to quit and learn something else - woodworking, photography, cooking, landscape design - whatever. Deep down, I knew - it was not due to the technology choice. The same project could've been re-written in other languages I knew and still be as frustrating.
Long story short - I started learning Haskell. That improved my coding skills tremendously. But there was some hump I couldn't get over - Haskell was still extremely difficult, I was not even near to the level of being able to write production-ready Haskell code. Besides, I wanted to write web apps. And Haskell's options were not great at the time. After using Typescript, Coffeescript, LiveScript, IcedCoffescript, Gorillascript, Traceur, Babel, Fay, Haste, GHCJS, I finally decided to try Clojurescript. And suddenly, everything I've struggled with Haskell started making more sense. And unlike Haskell, Clojure turned out to be a much more pragmatic choice - I am more productive today than I ever was before. Even more than I was with Python, Ruby, or Go. Today, even if I have to write something in another language, I would first prototype it in Clojure and then translate it to another language. It may sound stupid, but that is the fastest way for me to build things.
Learning Clojure opened a whole new world for me. Logic programming, generative testing, dependent types, concurrency and parallelism, distributed and numerical computing, probability, etc. I never knew all these things are approachable even by a lazy and simpleminded idiot like me.
Learning Clojure improved my work, my relationship, my confidence, my health.
The only regret I have - I carried my unfounded prejudice for years, but the door was there all the time, I kept ignoring it. I just needed to walk through that doorstep.
Don't hate parentheses of Lisp - they may look ugly to you today, but trust me, there's a lot of beauty and elegance that you may not be seeing.
> There are actually fewer parentheses in Clojurescript than in the similar code in JS+JSX.
Side by side sample or it didn't happen. (EDIT: see below) I would imagine ClojureScript has more parens in the narrow sense, but I can imagine it being "morally correct" if one considers angle brackets, curly braces, square brackets, and parentheses per se as "morally equivalent".
function component() {
return (
<div>
"Hello, world!"
</div>
);
}
the JS has two pairs of parens in the strict sense vs. one pair in the ClojureScript, and 5 pairs of balanced delimiters vs. 3 for the ClojureScript, and the JS doesn't minimize parens (but is idiomatic, so it better represents realistic code than minimizing parens would.) So, yeah, while this is a dirt simple example, it does demonstrate that it can be the true.
suggestion for your documentation page: add id's to your h2 elements so it is easy to send a link directly to the section you're looking at to a friend/coworker.
196 comments
[ 2.9 ms ] story [ 226 ms ] threadI don't think this is for me, but it's an interesting experiment and I could immediately grok what it was doing.
You're right the familiarity is a good thing though - just look at TypeScript!
Fair point. I think there's a tradeoff in there somewhere. The fact that you need to do things like wrap JavaScript in order to use it within Mint sets off all kinds of alarm bells for me. I still like the concept, but justifying an entirely new language (to myself, to my higher ups, to the company at large) is a high bar.
So yeah it isn't bad if it looks similar to something lots of people already use.
The first thing I thought was that it reminds me of Svelte, which I have been using and like a lot.
Like you, I'm not sure it's for me, but I also think it's interesting.
It does look like a cleaner and more convenient coding experience.
An interesting use for a DSL.
https://developer.mozilla.org/en-US/docs/Web/Web_Components
Multiple reasons why:
- Rich Harris (author of Svelte): eager (when laziness is preferable), styling is problematic, add confusion to attributes vs. props with disastrous ergonomics, leaky design, bad underlying model (DOM), global namespace [1]
- Serhii Kulykov (building Vaadin, a Web Components library): no form participation, broken autofill, broken accessibility, breaks SVG references, cannot extend built-in elements, handling focus, handling selection [2]
- Sarah Mei (Salesforce UX): Web Components break accessibility and assistive technology [3]
On top of that, you will always need a library/framework on top of them to orchestrate them, pass data around etc.
[1] https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
[2] https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wron...
[3] https://twitter.com/sarahmei/status/1198069119897047041
The answers to those questions should be on your home page.
Also it would be great if you included it here: https://github.com/krausest/js-framework-benchmark
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
Why not use something faster and smaller than React though like Preact or Inferno?
https://krausest.github.io/js-framework-benchmark/current.ht...
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.
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.
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.
- 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.
(edit: formatting)
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).
Anyway, nice job! The language looks really clean.
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.
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.
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 :)
I will try Mint our later today.
It can be fun implement but I doubt this will be adopted.
- Mint, the Linux distro
- Mint, the web-analytics tool
- Mint, the motion controller programming language
- MiNT, old school operating system for... Atari?
What is so great about the word "Mint"?
It is English slang for something very good, very neat, very clever, very sharp.
https://news.ycombinator.com/item?id=22098891
It’s often offered as if it’s good advice and the author was somehow completely unaware that other things might share the name, or that it will make SEO hard for a thing the commenter is likely to never want to search for.
I used to keep bookmarks of these comments, but then that became my Hacker News pastime and instead of enjoying the submissions and celebrating creators and hackers, I found I spent more time looking for people complaining about the names of things, it was hell, and I was almost at name-rage catalog sobriety, until now.
https://mint-takeawayonline.co.uk/
https://themint.net/
Device: iPhone XS (fully updated)
For additional reference, it seems to be alternating sections starting below the fold (man I hate that phrase)
[1] https://news.ycombinator.com/item?id=22245742
[2] https://github.com/mint-lang/mint/graphs/contributors
> What is wrong with Elm?
> Elm has great developer experience, but it being a purely functional language leads to some boilerplate code and makes it harder to learn. Also, it's not possible to contribute or influence the language in any meaningful way.
The magic sauce for me is a global state data structure where all my app state goes into. And it should just be data. I don't need to wrap it in 'semantic' constructs.
And then I need an easy way to query that, something more expressive than `get-ins` like `state.path1.path2.value`.
However the state is accessed the component should just update. I don't want to provide or connect.
Instead of using cascading parameters and other ridiculously complex ways of passing state around, we inject stateful services as scoped dependencies per client request. These are effectively just POCO models with a functional interface for mutating state. Then, we take dependencies on these throughout the web application (I.e. within each component or page). An example of one of these used heavily throughout would be UserSessionService. Certain aspects of the application may have their own dedicated state machines like LoginService (which is utilized only during the login process). LoginService takes a CTOR dependency on UserSessionService and it all plays together really nicely via Microsoft's DI.
We've even wired events from server-side directly into these services so its not just for handling the client-specific interactions either. Integrating server-side events is trivial. It felt a little weird at first, but it seems we are moving in a much more sustainable direction now. I can actually test my UI state machines in complete isolation from an actual browser. Also, because they are simply .NET implementations, we can reuse these for other aspects of the application.
> Instead of using cascading parameters and other ridiculously complex ways of passing state around
So much this! There are too many folks stuck in the 'container' component pattern when really you should never pass a prop that can be queried from state. Working like this results in a sustainable application that's flexible, like you _state_ xD
I'm going to give this a really close look, thank you.
But, once you get into really complicated scenarios where structurally-unrelated components are statefully-related (e.g. navbar interacts with some component in an entirely unrelated modal), things get very nasty without some common arbiter of state being shared between these components. You can usually solve this in some way with all the SPA frameworks I've worked with, but Blazor is the first case where building these state machines as C# services has knock-on benefits that simply can't be ignored anymore IMO.
Overall, separation of state machines from the UI seems the be the theme, and certain technologies can do this a lot better than others.
We have a "service layer" for React made up of state-machine-based services (although reactive services based on RxJS observables works as well). We also created associated custom hooks that allow developers to easily "inject" a service into their React component (use use React's Context API for our "DI container"). From there they can read the service state, or send events to it to trigger behaviour that is encapsulated in the service itself.
We even have the same "most used" service; a UserSession service manages OAuth based login flow and session management.
The best part of this approach is that our service layer started in an Angular based proof-of-concept before we lifted-and-shifted it all into React.
[1] https://xstate.js.org/
Here’s a follow-up post with a gist of what the React integration looks like.
https://news.ycombinator.com/item?id=22294087
I'm a lot more hesitant about SSR now. Users don't mind spinning wheels as long as they can see something happening.
A new language is in the perfect position to structure components so that they can be cleanly rendered on a server first, and rehydrated on the client as-needed. Trying to do that backwards will always result in less developer and user satisfaction. That doesn't mean it's right to just keep doing things the bad old way.
(I'm a student, hate webpack, and don't want to learn it's nuances for a few years. I know from googling this can be done with sufficient webpack config).
I've come from Elm where it is done in a very good way, but it's too restrictive, and I like react and it's expressiveness so I wanted to combine the two.
Vue is really good but at the end you are still writing JavaScript which is really hard to do in a safe way. And from my experience Typescript isn't 100% safe as well.
Why is this a goal? Could you elaborate?
> And from my experience Typescript isn't 100% safe as well.
Does it need to be? In my experience, enforcing reasonable standards (don't allow escape hatches like the `any` type, or the `// @ts-ignore` comment band-aid) fosters pretty strong interfaces. I haven't really needed more from the type system. Has your experience been different?
To your first question: JS's warts are well understood. You must already acknowledge this if you're a TS fan.
To your second: TS isn't 'actually' safe, to the extent something like Elm is (i.e. very small chance of runtime errors). This is also no secret - there are lots of examples out there if you care to search for them.
Further, UI development is an area where things can get messy very quickly. "Safe" languages often greatly minimize the kinds of bugs that are very easy to write in JS. This is one reason why Elm and Clojurescript have had years of adoption -- they by default make values immutable (and their entire programming paradigm doesn't actually require mutating most values ever) which removes a large class of common UI errors. There are other benefits as well.
But then I started looking at the examples and how styles and an xml-like syntax are given first-class support and it makes sense. It really is a hard problem to shove into an existing language, evidenced but all the transpiling that goes on now. Thanks for sharing!
Edit: coffee -> code
I've never seen the term 'coffee' used in this context. Is this a typo or some kind of slang/reference?
UI implementation (especially for the web) is a very hard problem. We've been trying to get it right for decades. This is a problem domain in need of attention. The CURRENT frontend paradigm (React/Redux SPA) is using a mix of technologies, which might benefit from consolidation and streamlining.
Its a rare line of JS that doesn't include at least one of a conditional, a function call or definition, or grouping parens, outside of declarations. If you use "parens" broadly to include square, angle, and curly braces, JSX and declarations have plenty, too (and if you don't use "parens" that inclusively, Clojure/ClojureScript doesn't have all that many, because of its use of different delimiters for different purposes, unlike classical Lisp-family languages.)
I was working for a startup, building a .Net project with Angular 1.x. And I was on a failing trajectory - code was full of holes, I was struggling to finish things on time, I was stressed, I started to hate things for no apparent reason. Finally, after years of writing software, I just wanted to quit and learn something else - woodworking, photography, cooking, landscape design - whatever. Deep down, I knew - it was not due to the technology choice. The same project could've been re-written in other languages I knew and still be as frustrating.
Long story short - I started learning Haskell. That improved my coding skills tremendously. But there was some hump I couldn't get over - Haskell was still extremely difficult, I was not even near to the level of being able to write production-ready Haskell code. Besides, I wanted to write web apps. And Haskell's options were not great at the time. After using Typescript, Coffeescript, LiveScript, IcedCoffescript, Gorillascript, Traceur, Babel, Fay, Haste, GHCJS, I finally decided to try Clojurescript. And suddenly, everything I've struggled with Haskell started making more sense. And unlike Haskell, Clojure turned out to be a much more pragmatic choice - I am more productive today than I ever was before. Even more than I was with Python, Ruby, or Go. Today, even if I have to write something in another language, I would first prototype it in Clojure and then translate it to another language. It may sound stupid, but that is the fastest way for me to build things.
Learning Clojure opened a whole new world for me. Logic programming, generative testing, dependent types, concurrency and parallelism, distributed and numerical computing, probability, etc. I never knew all these things are approachable even by a lazy and simpleminded idiot like me.
Learning Clojure improved my work, my relationship, my confidence, my health.
The only regret I have - I carried my unfounded prejudice for years, but the door was there all the time, I kept ignoring it. I just needed to walk through that doorstep.
Don't hate parentheses of Lisp - they may look ugly to you today, but trust me, there's a lot of beauty and elegance that you may not be seeing.
Side by side sample or it didn't happen. (EDIT: see below) I would imagine ClojureScript has more parens in the narrow sense, but I can imagine it being "morally correct" if one considers angle brackets, curly braces, square brackets, and parentheses per se as "morally equivalent".
EDIT: so, I found https://www.toptal.com/clojure/clojurescript-tutorial-react-... which has this simple example:
vs. }the JS has two pairs of parens in the strict sense vs. one pair in the ClojureScript, and 5 pairs of balanced delimiters vs. 3 for the ClojureScript, and the JS doesn't minimize parens (but is idiomatic, so it better represents realistic code than minimizing parens would.) So, yeah, while this is a dirt simple example, it does demonstrate that it can be the true.
- Clojurescript code is easier to edit, e.g: if you want to wrap the string in <h1> tag there's a lot less typing you have to do.
- Cljs code is also "data", it can be send over the network without any modifications or encoding, sent to the REPL for evaluation, etc.
- You can "eval" every single part of it:
What happens if you copy-paste any part of the JSX into JS REPL?I didn’t like how “uncommon” Dart and Flutter were until I used them. But I’ve really come around on both after starting to use them.
This though, cool, but I see no possibility of traction.