It appears that the only things that can replace JS are a superset language which will work with existing libraries( e.g. TypeScript) or any lang that compiles to WASM when it gets DOM access.
@@TechBuddy_ @pookiepats Haha! I hear there is a lot of drama in the Rust community recently. Leave it to humans, and they'll always manage to mess everything up...
I worked with Elm a few years ago. It's pretty nice as a language, but there were two things which I didn't like: First, as you mentioned, the templating. After working with JSX, it really feels like a big step back, it's far less readable and unintuitive to write. Second, the interoperability with JS. Even though it compiles to JS, plugging in third-party libraries requires a lot of work. What I liked better was ReasonML/ReScript. It solves similar problems, but it comes with JSX and integrates perfectly with React (React was even originally designed in OCaml, which resulted in ReasonML) and supports many React libraries. And adding new ones is pretty straightforward. It works best with React but it's not tied to it, there are also bindings for e. g. SolidJS. But it seems like ReScript, Elm and other alternative compile-to-JS languages have lost a lot of momentum in the last couple of years, TypeScript is just everywhere. I really preferred ReasonML's and Elm's type system and language features over TypeScript, but integrating untyped JS is just far easier with TypeScript, and the learning curve is much flatter when coming from JS. And sadly it's very hard to compete with such a massive ecosystem.
Elm is a very nice little language that I think is just not well-enough supported. For ML in the browser, I’m leaning toward F# compiled to JavaScript with Fable.
Wouldn't call it a little language. It's a lot more complicated than javascript. It's also immensely more powerful. Not easy to learn unless you have prior experience in functional programming.
The last elm release was almost 4 years ago (October 2019). I don't know if the project is still in development. But the official elm twitter seems to be active though.
As far as I can tell, Elm, when compiled into JavaScript, resembles like a React/Vue SPA application (Elm has its own virtual DOM). As you know SPA (client-side-rendering) applications have big problems with SEO and achieving good results in Google Lighthouse. 1. Does Elm have support for server-side-rendering? 2. What is the reactivity model of an application written in Elm (is there a classic hydration like in React, or maybe something similar to resumability from Qwik)? 3. Can Elm be used to write backend in Node/Deno?
Elm was intended as a frontend language. What it really achieves, is being a really nice alternative to front-end JavaScript. While it is *technically* possible to run it on node, since it compiles to JavaScript, it does not have built-in access to the Node API. For example, it cannot read files etc.
@@kintrix007 I tested this on my own - for the last 10 months I've been learning Elm and writing a clone of a commercial application I was developing for my client. Conclusion - Elm is a cool toy if you want to play with functional programming, but this language is not suitable for writing commercial applications - it lacks integration with modern tools used on the frontend, and working with the ecosystem and JavaScript libraries (where it all is) is a nightmare. Elm in the field of languages that compile to JavaScript, which could be used production-wise, is probably the worst. By far a better choice is Rescript or PureScript. And it's a shame - because Elm had the potential to conquer the world of frontend...
If we are going to work with languages that compile to Javascript later, why not stick to strongly backed languages like Dart or Kotlin instead? Those languages can also write actual web apps, without needing to use React Native, so it's also beneficial to your career if you want to move away from the mess that pure Javascript is.
This is a good point. I think there are advantages to diversity though. Even though Elm might not end up gaining the same type of popularity / community as some other established tool, it is still interesting to see alternatives and different takes on the same problem.
elm is a DSL for writing webapps and it has nothing to do with React Native, I suggest you try it and compare the ease of use with Dart or Kotlin for webapps. elm is truly delightful to work with and experience with the language translates well to other functional languages.
Thank you for your feedback! Elixir and Phoenix are "on my list" for quite a while now. The reality is that I'm not that familiar with this stack yet, so I'm not confident enough to make a proper video on this one at the moment 😅
Haskell managed to ruin quite few weekends for me :)) If you don't have enough experience, It's a struggle to switch to Lisp languages until things "click".
I doubt it, Elm seems to have been having problems growing its community. I've never used it myself so I don't really know why. I'm just all in on Javascript/Typescript now lol
I think it has a slower adoption because of: 1 - it's Lisp like syntax which really looks weird for those familiar with the a C / C++ programming style; 2 - building views is a really bad developer experience compared to HTML or JSX. However, Elm was a major influence in frontend development, and inspired some of the initial FLUX / Redux architecture proposals.
9 months later, I still dont think there is a huge value prop for this if it just compiles down to Javascript. Has there been another use for ELM that isn't just an abstraction of Javascript??
The main use is that is has significantly more guarantees than JS. If you write your frontend in Elm the chance that you will ever encounter a runtime error is VERY low. Edit: You can probably get a similar level of guarantees with TypeScript with nearly all of the strict compiler options enabled. Compared to TypeScript what is can offer is: safe JSON decoding. It ensures the schema of the JSON is what is expected. And it has a very uniform ecosystem. There is no question about how you do state management. No question of what library/framework to use with it. There is one default option and it works best in general.
Also worrying is the fact that looking at Elm's repository - there hasn't been a commit there for several years. The website of the language itself hasn't been updated for several years either. Could it be that the project has simply died?
If you look into elm you'll find that it has a really slow development cycle done mostly by a single person in private. Some people are put off by this, others view it as a sign of reliability and a testament to how stable and well designed elm is. There hasn't been updates to elm in years but it still functions very well. That being said the project is definitely not dead, Evan just had a somewhat secretive talk about elm on the backend and we will most likely see a big update soonish.
@@terryriley6410 Elm on backend (node/deno/bun I suppose - will be amazing) but still Elm on frontend is a few years behind actual modern frontend which is focused on server side rendering/seo friendly/lighthouse scorring sensitive. I'm afraid that pure SPA solutions like Elm are just not enough after 2020...
@@coder_one It depends on what you are building. For the core of webapps you might not care much about seo friendliness and can benefit way more from the reliablility of elm. For websites you probably care more about seo. You can also combine elm and other stuff and just use it where you want to. I also suspect that elm on the backend might have an answer to seo questions as well. I don't think it will just be as basic as "now you can run elm inside node". Evan has a tendency to come up with awesome stuff after careful considerations.
yes if it actually works the same without maintanence, ie it is truly "stable". Also, it is maintained just not as fast as other languages and frameworks with more messy designs
@@terryriley6410I think you have a point, these updates of every month/minute suck. You may feel like you're off-trend/off-track yet you can use the same resources from 6 years back and achieve the same thing.
clearly elm wasn't the solution, but i believe that it is the direction that we need to further explore. as far as building a language that is designed around a specific pattern and also designed specifically for ui's. there was not much foresight when they designed javascript. it is illogical to continue banging our heads against the wall attempting to fix something that simply cannot be fixed. all of these "solutions" are only workarounds. the workarounds become abstractions and we are left with abstractions built on top of abstractions. until it reaches a point where javascript is hardly recognizable, which i believe we are in now.
@@awesome-coding for me it's mostly that there's too much boilerplate and repeated code. if you don't have state, you still need to define an empty model and message. even with minimal state it's overkill. there's a lot of repeated code in general. so while it's nice to have that structure it can also be a negative.
I'll tell you what I'm tired of... You using that same yellow sweater girl stock footage. 💀 edit: Just realized, you use the same stock footage across all your videos. 💀
JS is not the problem it's all these dumb frameworks that reinvent the wheel every single change they get. Truth is you really don't need a framework and if you do use one, you don't need all the fancy features keep it simple. MAYBE 10% of companies are using the most new Next.js features. For the most part your going to see, legacy codeish stuff, solid large companies are not going to rewrite code bases just because a new feature comes out.
lol it is dead and the author is unresponsive, the community is delusional; it is foolish to bank on a DSL. Rescript, Imba, Purescript, Svelte, Marko, Elm etc, all are just needless technical debt
You are comparing the best language to an offspring of the worst language. I'd write C over any other language ( even rust, my next fav language after C ) but it would take forever to shup any new feature lol 😂
@@TechBuddy_elm is not an offspring of javascript, if anything it is an offspring of Haskell (it started as a thesis project Haskell subset lang). It uses JS as it's runtime which means little, it like saying any compiled language is an offspring of machinecode.
@@terryriley6410 you know that's not a bad idea actually. "Every programming language is an offspring of binary" lmfao 🤣. Jokes aside Elm is not my problem js is. I know elm and js are almost completely different. I used the term offspring very very lightly there 😅
brother, he wrote more lines of javascript in the past 10 years than you will in your entire life. if you don't know what a joke is, please go hang around humans more often
Right, it was meant as a joke. The joke being that JavaScript is a funny language with a lot of quirks such as the Array.prototype.sort() method non intuitively comparing UTF codes even for arrays of numbers.
short answer is no.
That is the first word of the long answer too
It's been 5 years I work with elm.
Never got any runtime error
I love it :)
This pretty much sums it up.
It appears that the only things that can replace JS are a superset language which will work with existing libraries( e.g. TypeScript) or any lang that compiles to WASM when it gets DOM access.
shoutout Rust!
@Awesome don't get sued
@@awesome-coding not endorsed by the rust foundation btw lmao 🤣
@@TechBuddy_ @pookiepats
Haha! I hear there is a lot of drama in the Rust community recently. Leave it to humans, and they'll always manage to mess everything up...
@@awesome-coding But Rust the language is amazing
I worked with Elm a few years ago. It's pretty nice as a language, but there were two things which I didn't like: First, as you mentioned, the templating. After working with JSX, it really feels like a big step back, it's far less readable and unintuitive to write. Second, the interoperability with JS. Even though it compiles to JS, plugging in third-party libraries requires a lot of work.
What I liked better was ReasonML/ReScript. It solves similar problems, but it comes with JSX and integrates perfectly with React (React was even originally designed in OCaml, which resulted in ReasonML) and supports many React libraries. And adding new ones is pretty straightforward. It works best with React but it's not tied to it, there are also bindings for e. g. SolidJS.
But it seems like ReScript, Elm and other alternative compile-to-JS languages have lost a lot of momentum in the last couple of years, TypeScript is just everywhere. I really preferred ReasonML's and Elm's type system and language features over TypeScript, but integrating untyped JS is just far easier with TypeScript, and the learning curve is much flatter when coming from JS. And sadly it's very hard to compete with such a massive ecosystem.
Thank you for the detailed answer!
Reason looks interesting!
@@awesome-coding its now glt seperated into another language called rescript and the reason community is dying XD
@@kyonas6047 Jeez... it's hard to keep track of all these :))
What's the difference between ReasonML/ReScript and which choose to achieve all this amazing interoperability with React & other JS labraries?
Thanks. Any comment on ClosureScript?
I hope it does, Elm is such a friendly a pleasant place to be. As opposed to the chaos of JavaScript, though, some prefer the chaos. To each their own
Elm is a very nice little language that I think is just not well-enough supported. For ML in the browser, I’m leaning toward F# compiled to JavaScript with Fable.
Are you using F# backend as well or another language? I'm interested in using Fable Elmish frontend for an Elixir app 🤔
@@irfannurhadisatria2540 why not use phoenix framework in elixir? :D
Wouldn't call it a little language. It's a lot more complicated than javascript. It's also immensely more powerful. Not easy to learn unless you have prior experience in functional programming.
@mariobroselli3642functional languages Haskel, f#, and scala. OOP java, c# and others
@mariobroselli3642Haskell or ocaml or any ML syntax language.
The last elm release was almost 4 years ago (October 2019). I don't know if the project is still in development. But the official elm twitter seems to be active though.
You'll see activity in their git repo as well.
@@awesome-coding Oh yes.
Can you give alink? I wasnt able to find the activity :/@@awesome-coding
Elm is known for slow release schedule on purpose, it's not dead since the community is still quite active
As far as I can tell, Elm, when compiled into JavaScript, resembles like a React/Vue SPA application (Elm has its own virtual DOM). As you know SPA (client-side-rendering) applications have big problems with SEO and achieving good results in Google Lighthouse.
1. Does Elm have support for server-side-rendering?
2. What is the reactivity model of an application written in Elm (is there a classic hydration like in React, or maybe something similar to resumability from Qwik)?
3. Can Elm be used to write backend in Node/Deno?
Elm was intended as a frontend language. What it really achieves, is being a really nice alternative to front-end JavaScript. While it is *technically* possible to run it on node, since it compiles to JavaScript, it does not have built-in access to the Node API. For example, it cannot read files etc.
@@kintrix007 I tested this on my own - for the last 10 months I've been learning Elm and writing a clone of a commercial application I was developing for my client. Conclusion - Elm is a cool toy if you want to play with functional programming, but this language is not suitable for writing commercial applications - it lacks integration with modern tools used on the frontend, and working with the ecosystem and JavaScript libraries (where it all is) is a nightmare. Elm in the field of languages that compile to JavaScript, which could be used production-wise, is probably the worst. By far a better choice is Rescript or PureScript. And it's a shame - because Elm had the potential to conquer the world of frontend...
Thanks!
Thank you!
What do you think about F#? Either on the backend or frontend?
Fable is the goat
If we are going to work with languages that compile to Javascript later, why not stick to strongly backed languages like Dart or Kotlin instead? Those languages can also write actual web apps, without needing to use React Native, so it's also beneficial to your career if you want to move away from the mess that pure Javascript is.
This is a good point. I think there are advantages to diversity though. Even though Elm might not end up gaining the same type of popularity / community as some other established tool, it is still interesting to see alternatives and different takes on the same problem.
elm is a DSL for writing webapps and it has nothing to do with React Native, I suggest you try it and compare the ease of use with Dart or Kotlin for webapps.
elm is truly delightful to work with and experience with the language translates well to other functional languages.
Fantastic video. Can you do a similar one on Elixir?
Thank you for your feedback!
Elixir and Phoenix are "on my list" for quite a while now. The reality is that I'm not that familiar with this stack yet, so I'm not confident enough to make a proper video on this one at the moment 😅
web development am i right
Yh! but this is only one thing.
😅 it never gets boring...
Hell yeah! This is amazing. I love Haskell and this makes me 😊
Haskell managed to ruin quite few weekends for me :))
If you don't have enough experience, It's a struggle to switch to Lisp languages until things "click".
@@awesome-codingStop conflating Haskell/elm with Lisp. These are different languages with different syntax.
I didn't understand anything case I didn't try any functional language before, but they should've just stick to HTML, something like JSX
I agree with that. Their view system is a major deal breaker for me.
I smell elixir here
✌️
I'm interested in a good comparison between Elixir, Elm and Clojurescript - and the mainstream way to do things with Typescript and Bun.
it 's a way more close to Haskell (and ML languages) than to Erlang/Elixir family
Great explanation of things!
Glad it was helpful!
I doubt it, Elm seems to have been having problems growing its community. I've never used it myself so I don't really know why. I'm just all in on Javascript/Typescript now lol
I think it has a slower adoption because of:
1 - it's Lisp like syntax which really looks weird for those familiar with the a C / C++ programming style;
2 - building views is a really bad developer experience compared to HTML or JSX.
However, Elm was a major influence in frontend development, and inspired some of the initial FLUX / Redux architecture proposals.
@@awesome-codingelm syntax is more akin to Haskell than Lisp.
9 months later, I still dont think there is a huge value prop for this if it just compiles down to Javascript. Has there been another use for ELM that isn't just an abstraction of Javascript??
The main use is that is has significantly more guarantees than JS. If you write your frontend in Elm the chance that you will ever encounter a runtime error is VERY low.
Edit: You can probably get a similar level of guarantees with TypeScript with nearly all of the strict compiler options enabled. Compared to TypeScript what is can offer is: safe JSON decoding. It ensures the schema of the JSON is what is expected. And it has a very uniform ecosystem. There is no question about how you do state management. No question of what library/framework to use with it. There is one default option and it works best in general.
Too short. I think we would benefit from diagnosing some example medium-size app.
I think you are right. I might work on a second video on the topic.
remember Dart. with all the power of Google, still didn't get anywhere.
gladly it found its home with flutter
Right... I had high hopes for Dart at some point :)
Probably only wasm can replace javascript when it gets direct dom access
That will be a game changer for certain.
Also worrying is the fact that looking at Elm's repository - there hasn't been a commit there for several years. The website of the language itself hasn't been updated for several years either. Could it be that the project has simply died?
You are right - there is little to no movement in the repos these days.
If you look into elm you'll find that it has a really slow development cycle done mostly by a single person in private. Some people are put off by this, others view it as a sign of reliability and a testament to how stable and well designed elm is. There hasn't been updates to elm in years but it still functions very well.
That being said the project is definitely not dead, Evan just had a somewhat secretive talk about elm on the backend and we will most likely see a big update soonish.
@@terryriley6410 Elm on backend (node/deno/bun I suppose - will be amazing) but still Elm on frontend is a few years behind actual modern frontend which is focused on server side rendering/seo friendly/lighthouse scorring sensitive. I'm afraid that pure SPA solutions like Elm are just not enough after 2020...
@@terryriley6410 on the other hand one-person development almost always end in some kind of disaster...
@@coder_one It depends on what you are building. For the core of webapps you might not care much about seo friendliness and can benefit way more from the reliablility of elm. For websites you probably care more about seo. You can also combine elm and other stuff and just use it where you want to.
I also suspect that elm on the backend might have an answer to seo questions as well. I don't think it will just be as basic as "now you can run elm inside node". Evan has a tendency to come up with awesome stuff after careful considerations.
Not if no one is maintaining it...
Fair enough.
yes if it actually works the same without maintanence, ie it is truly "stable".
Also, it is maintained just not as fast as other languages and frameworks with more messy designs
@@terryriley6410I think you have a point, these updates of every month/minute suck. You may feel like you're off-trend/off-track yet you can use the same resources from 6 years back and achieve the same thing.
clearly elm wasn't the solution, but i believe that it is the direction that we need to further explore. as far as building a language that is designed around a specific pattern and also designed specifically for ui's. there was not much foresight when they designed javascript. it is illogical to continue banging our heads against the wall attempting to fix something that simply cannot be fixed. all of these "solutions" are only workarounds. the workarounds become abstractions and we are left with abstractions built on top of abstractions. until it reaches a point where javascript is hardly recognizable, which i believe we are in now.
i have not used elm directly but i have used a gui framework in another language inspired by it and i wasn't much of a fan.
I know it's tough if you have no familiarity with this programming style.
@@awesome-coding for me it's mostly that there's too much boilerplate and repeated code. if you don't have state, you still need to define an empty model and message. even with minimal state it's overkill. there's a lot of repeated code in general. so while it's nice to have that structure it can also be a negative.
320 Clint Isle
elm bad clojurescript good
😂
I have to decide between those, and I like Lisp anyways. Thanks. Clojurescript isn't even in my Arch based distro's repo, though. Elm is there...
No way, that's too much thinking for JS developers
😂
rust 🦀
I'll tell you what I'm tired of... You using that same yellow sweater girl stock footage. 💀
edit: Just realized, you use the same stock footage across all your videos. 💀
😅 I'll look for a different girl.
edit: hence the name - stock footage
I'm fine with the stock footage! 😉
love it.
sorry but why is there always a space in-between "Java" and "Script" in your thumbnails? It's a little offending
trying to not get sued by Oracle, that holds the Javascript patent
@YuriG03042 haha this is a funny reason! and to some extent it might be true 😅
@codeodyssey6729 I'm sorry - you are right. It's just a bad habit I guess.
JS is not the problem it's all these dumb frameworks that reinvent the wheel every single change they get. Truth is you really don't need a framework and if you do use one, you don't need all the fancy features keep it simple. MAYBE 10% of companies are using the most new Next.js features. For the most part your going to see, legacy codeish stuff, solid large companies are not going to rewrite code bases just because a new feature comes out.
no thanks, typescript is fine for me
lol it is dead and the author is unresponsive, the community is delusional; it is foolish to bank on a DSL. Rescript, Imba, Purescript, Svelte, Marko, Elm etc, all are just needless technical debt
Sadly you are mostly right 🫠
@ luckily we have you & fireship for quick dopamine hits 💉 🧠 mmmm yea, alternate Syntax straight to the dome 😤
@@pookiepats Haha I'm more of a poor's man dopamine hit 😅
I'd rather write C😅
You are comparing the best language to an offspring of the worst language. I'd write C over any other language ( even rust, my next fav language after C ) but it would take forever to shup any new feature lol 😂
C is okay but outside of embedded, it's pretty much useless.
The syntax is nice though, way nicer than rust but the lack of STL is a huge con.
@@TechBuddy_elm is not an offspring of javascript, if anything it is an offspring of Haskell (it started as a thesis project Haskell subset lang). It uses JS as it's runtime which means little, it like saying any compiled language is an offspring of machinecode.
@@terryriley6410 you know that's not a bad idea actually. "Every programming language is an offspring of binary" lmfao 🤣. Jokes aside Elm is not my problem js is. I know elm and js are almost completely different. I used the term offspring very very lightly there 😅
The best language is a procedural one. I don't want to do just fp or oop, I will use the right tool for the job so NO I don't care about it
Good point!
spoiler: no
😅 fair
Lol, you don't know JS , BRUH, you pass in a comparator function in sort to sort numbers
brother, he wrote more lines of javascript in the past 10 years than you will in your entire life. if you don't know what a joke is, please go hang around humans more often
Right, it was meant as a joke. The joke being that JavaScript is a funny language with a lot of quirks such as the Array.prototype.sort() method non intuitively comparing UTF codes even for arrays of numbers.
This video is nonsense. It's just gifs and memes.
No
😂
fair enough
Crap
😅