I write code, front-end and back-end, and like deploying it on AWS. Software Developer for 20 years, and still love it. Amateur Powerlifter & Parkourist.
If you're just using React + JavaScript and raw Elm, both seem to be same. I like how both compile pretty fast at high Lines of Code. TypeScript gets really slow with a lot of code.
What I don't like is when JavaScript grows, it gets really dangerous to make changes. However, this then requires a lot of unit tests. Not just code tests, but possibly a variety. These are painful to maintain, and hard to get right. Using something like Jest isn't great because it's slow, and swallows your console log statements. Using Mocha is really nice, especially 8 which concurrency there is much easier to use. Problem with that is you're breaking from create-react-app norms, and that has a huge development and maintenance cost. Adding TypeScript can help a lot here.
It's also easy to allow juniors to play, but hard to provide guardrails. They may create larger than needed components. Generally that's ok, until that component becomes the cornerstone of your application. Unless they learn how to create public API's early, it becomes hard to safely refactor, or test some of this code. I've had the same problem in Angular 1 and 2.x.
Redux can become verbose, but manageable. The issue there, is unless your team understands pure functions, many have no idea why they're using Redux and would just rather use Context. The defeats the whole purpose of using a state management, but I acknowledge Context is a lot easier to grok for many. Pretty soon you have these "Context Pole Stakes" that are firmly rooted, and you can't easily move. You can work around, no doubt, but once you use more than 2 it can be frustrating. Combine this with both classes and Hooks calling for encapsulation "except for Context", for larger apps, you just have to learn how they work before you're productive.
Elm doesn't have any of these problems. It does have 4 new ones, though.
First, race conditions. Since there are no side effects, occasionally you'll get race conditions. Many developers do not understand how to handle multiple HTTP calls, say, wired up to a button in Elm or React. Do you always take the first? The last? Accept all? Does the visual design handle this? Those questions are often not asked, and you get weird bugs that only manifest in manual or smoke tests. This is why I'm pretty bullish on Cypress in both React and Elm because it can sus these out, quickly. The same happens when you start "obeying the URL" when implementing routing. A bit easier to debug this in Elm vs. React, but still wracks your mind. Bottom line, distributed architectures are hard on the front-end, too 😁!
The second problem is modeling the above. There are some interesting patterns that the Elm compiler can just type to "not make them a problem anymore". While awesome, this a skill, and the articles on it are few or academic. They don't need to be; simple patterns do exist, but you have to learn and practice. Not just async, but anything. This is a challenge for both new and experienced developers. Documenting this so others can understand it takes practice, too.
Third, ports are dangerous. Usually developers who are coding Elm already write pretty Functional and safe JavaScript, but still, you need to be super wary here. The best approach is to use Maybeseven if you're bullish on Optional Chaining or Lodash getOr / Ramda props in JavaScript and secondly, liberally use try/catch.
Fourth, Functional Programming is harder than Imperative and Object Oriented Programming. Elm has thrown out the insane parts like Category Theory and Monad side effects, making it much more approachable, fun, and a valuable problem solving tool. Still, this learning curve is not to be underestimated. Functional Programming by its current employable nature is a lonely endeavor, and having a team learn together is better.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you're just using React + JavaScript and raw Elm, both seem to be same. I like how both compile pretty fast at high Lines of Code. TypeScript gets really slow with a lot of code.
What I don't like is when JavaScript grows, it gets really dangerous to make changes. However, this then requires a lot of unit tests. Not just code tests, but possibly a variety. These are painful to maintain, and hard to get right. Using something like Jest isn't great because it's slow, and swallows your console log statements. Using Mocha is really nice, especially 8 which concurrency there is much easier to use. Problem with that is you're breaking from create-react-app norms, and that has a huge development and maintenance cost. Adding TypeScript can help a lot here.
It's also easy to allow juniors to play, but hard to provide guardrails. They may create larger than needed components. Generally that's ok, until that component becomes the cornerstone of your application. Unless they learn how to create public API's early, it becomes hard to safely refactor, or test some of this code. I've had the same problem in Angular 1 and 2.x.
Redux can become verbose, but manageable. The issue there, is unless your team understands pure functions, many have no idea why they're using Redux and would just rather use Context. The defeats the whole purpose of using a state management, but I acknowledge Context is a lot easier to grok for many. Pretty soon you have these "Context Pole Stakes" that are firmly rooted, and you can't easily move. You can work around, no doubt, but once you use more than 2 it can be frustrating. Combine this with both classes and Hooks calling for encapsulation "except for Context", for larger apps, you just have to learn how they work before you're productive.
Elm doesn't have any of these problems. It does have 4 new ones, though.
First, race conditions. Since there are no side effects, occasionally you'll get race conditions. Many developers do not understand how to handle multiple HTTP calls, say, wired up to a button in Elm or React. Do you always take the first? The last? Accept all? Does the visual design handle this? Those questions are often not asked, and you get weird bugs that only manifest in manual or smoke tests. This is why I'm pretty bullish on Cypress in both React and Elm because it can sus these out, quickly. The same happens when you start "obeying the URL" when implementing routing. A bit easier to debug this in Elm vs. React, but still wracks your mind. Bottom line, distributed architectures are hard on the front-end, too 😁!
The second problem is modeling the above. There are some interesting patterns that the Elm compiler can just type to "not make them a problem anymore". While awesome, this a skill, and the articles on it are few or academic. They don't need to be; simple patterns do exist, but you have to learn and practice. Not just async, but anything. This is a challenge for both new and experienced developers. Documenting this so others can understand it takes practice, too.
Third, ports are dangerous. Usually developers who are coding Elm already write pretty Functional and safe JavaScript, but still, you need to be super wary here. The best approach is to use
Maybeseven if you're bullish on Optional Chaining or LodashgetOr/ Ramdapropsin JavaScript and secondly, liberally use try/catch.Fourth, Functional Programming is harder than Imperative and Object Oriented Programming. Elm has thrown out the insane parts like Category Theory and Monad side effects, making it much more approachable, fun, and a valuable problem solving tool. Still, this learning curve is not to be underestimated. Functional Programming by its current employable nature is a lonely endeavor, and having a team learn together is better.