This is a common criticism of Elm, and I've never understood it.
The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous."
Like, what's the alternative? More JavaScript?
[@bs.val] external pi : float = "Math.PI";
let tau = pi *. 2.0;
[@bs.val] external alert : string => unit = "alert";
alert("hello");
That is why I use Elm, and not some other compile-to-JS language that allows me more freedom.
I don't want freedom. I want constraints.
Freedom is the rope with which I can hang myself.
Constraints keep my bug tracker silent.
> Freedom is the rope with which I can hang myself.
If you'd like to, why not? It's up to you. You're not forced to do, though.
On the other side, being a hostage of some secret plans in "people in power" minds, you might be forced to do any kind of staff. New constraints are here and they're enforced on anyone. That's a catch with constraints, you can be OK with existing, but you'll never know what comes tomorrow.
Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident.
It's also not a valid criticism for you to say that you've found Elm doesn't "follow the common sense". This is too vague to be any kind of constructive criticism.
That's exactly what I'm talking about. I'd also like to pick up some "silver bullet", like Elm(if I got you right), for any new project.
Unfortunately, real world is usually a little bit more complicated than "I'm free to pick up any technology that I want. All browsers are the same, their behavior is consistent, mobile web is pure joy and all of our users know their plugins might cause an issue to our app, therefore they're disabling them when they launch our app".
Anybody who does webdev knows that. Different projects, different requirements(sometimes very, very strange), brand new requirements right before the release, deadlines, etc. There're lots of things you have to deal with to end up with a good website\app. Picking a language with nice "correctness guarantees", is not going to help you much.
There were times, long time before 0.19, when there were at least discussions on effect managers, extending the type system, native modules were a nice escape hatch to fix your problem at hand with nasty browser bug or even Elm runtime issue. Those were times when I was so excited to use Elm, did some tiny (sub)projects in it, did a workshop at the office.
Since then, many things have changed to the worse, imho. Some features were removed, not even deprecated. No public discussions, no roadmap, no bugfix releases, no escape hatches for special cases. But who cares what some random guy on the internets thinks :)
Don't get me wrong, I think Elm is a great experiment in the land of static languages, lots of great stuff is getting into mainstream languages(like Elm architecture, error msgs). I still hope we'll see the 1.0 version and things might get better in terms of feature stability, feedback and building things a little bit more complex than counter apps without hitting even more pain points than we have with modern JS\TS.
Nothing is a silver bullet. Never claimed it was.
> Anybody who does webdev knows that.
I am a web developer, and I disagree with you.
> Picking a language with nice "correctness guarantees", is not going to help you much.
That hasn't been my experience.
> Since then, many things have changed to the worse, imho
Exactly — it's your opinion. Removing surface area for runtime areas is a change for the better, in my opinion.
> building things a little bit more complex than counter apps
My businesses are more complex than counter apps.
That said, you could add effects and a JavaScript FFI using monads or algebraic effects. You could also get rid of a lot of boilerplate in the Elm architecture using existential types. It's a safe bet that the Elm developers know this. But all of these extensions would make the language less approachable. I think one of the reasons why Elm is doing so well is because it's not Haskell. :)
Your code will produce runtime errors which will be rendered into console with ReasonML runtime guts in it. I would disagree that this is in any way superior to Elm's promise of no runtime errors, and JS via ports having no runtime in its errors.
Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill.
> Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
That's a fair point, and I agree, however this somewhat negates your previous point:
> Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill.
I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. They might feel intimidated by that, and discouraged from working with the technology at all. I'm using "team" in a more abstract sense here too; it could be all the collaborators (existing or potential) of an open source project.
I'm not arguing the anti-intellectual position that everything should be dumbed-down. I just believe — as you said — there is some middle ground, which also isn't universally applicable.
Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.
Elm disguised as a beginner friendly language for web front-end, which is not true with the case of ports. Where you need to be fairly familiar with Javascript.
The Elm community also advertise a lot on the advantage of development happiness of Elm over Javascript, and mention the Javascript fatigue a lot. But the truth for a beginner is that you can't escape the Javascript ecosystem when using Elm, and sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided.
If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm.
I don't understand. You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript.
This seems self-evidently false.
> If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm.
Seems like the argument is Elm isn't ideal if you're not a programmer, because you can't cargo-cult it.
I think I'm ok with that.
A codebase of 100% Javascript does not usually mean 100% written by the app developer. If you are coding in react for some basic app, like some basic crud with react using existing backend with Firebase, it almost only require you to learn the some basics of react and Javascript syntax, and fill in the template. You can also use other modules by just follow their documentation when you need some extra functionality.
However in Elm Ports we are required to pass async messages for everything which is much harder. I am OK with the boilerplate for the JSON encoder and stuff, but I have to wrap around my head for how to write a port for lots of basic web APIs.
Port is hard even for people that familiar with Javascript. There are plenty of experienced Javascript programmers willing to dive into the source code of Elm to write native modules to avoid ports even. https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_m...
In addition, even the 5% of Javascript will eventually leads to the full Javascript stack, where Elm, without an official recommend JS stack, feels more like additional choice as a part of the JS fatigue. Beginners ends up looking up on browserfy/gulp/webpack etc and figuring out a way to integrate Elm in.
> Seems like the argument is Elm isn't ideal if you're not a programmer
I program daily for machine learning, and I have used many programming languages. But Javascript is not the language that I want to dive in too much, which it is the main reason I learn Elm. If your requirement of being a programmer is having a job as a software developer, then I am not. But I think a language with an aim of going into education and scientific computing shouldn't limit itself to that. https://www.youtube.com/watch?v=uGlzRt-FYto
I enjoy Elm. It is one of my favourite programming language. But I have not gotten anything done with it mainly because of ports. If I am pursuing a career in front-end related development, I would dive into Javascript and build stuff. I understand the decisions from Evan and friends and I am just thankful for Elm as it is, there is no right for me to demand anything anyway.
[edit: formatting]