6 ms·

I programmed with Elm for 3 years and love it - best programming experience I’ve ever had. I had to stop because I started working on some educational game proj

by d13 5y ago

I programmed with Elm for 3 years and love it - best programming experience I’ve ever had. I had to stop because I started working on some educational game projects that had incredibly short timelines and frequent, large change requests and depended on some WebGL 3D and game libraries. Nothing beats the super productivity of JS for hacking something together fast, and despite JS being far less reliable, the productivity and flexibility made up for that. Yes, there were run-time errors, but they were really a minor problem. JS, whatever it’s many faults may be, is fast and fun. What slowed me down with Elm was JSON parsing, which needs to be done manually and can take hours or days whereas the same thing in JS takes about 2 seconds to type an import statement. And the other thing was using BabaylonJS and Phaser - you can certainly use them with Elm but you’ll need to commit to months of extra work to build port-based interfaces to them. And, games live in the world of side-effects, which is a chore in Elm. I needed to get finished games out in days - which I was able to hacking my way through with JS. Having used Elm for such a long time, I’m baffled by the success of Typescript - it’s hardly more reliable than JS while adding another dependency and much more complexity. For anyone sincerely interested in writing reliable code, not just wanting another toy to play with (Typescript) I can’t image writing front end code in anything other than Elm.

cercatrova 5y ago
> I’m baffled by the success of Typescript You're baffled, really? The core pitch is that JS developers don't have to learn a whole new language or paradigm such as in the case of other compile-to-JS languages. They can write JS, sprinkle on some TS, and gradually migrate to full TS while learning it along the way. The amount of developer friction is much lower, so that's why it succeeds to a much higher extent (in terms of usage) than other compile-to-JS languages like Elm, PureScript, ReasonML/ReScript, etc.
skrebbel 5y ago
Reliability isn't really part of Typescript's pitch though. It's maintainability.
- yakshaving_jgt 5y ago
  Those two qualities aren't mutually exclusive.
- dustingetz 5y ago
  typescript is for maintainability inside midsize to enterprise scale companies with the management and hiring challenges associated with that scale (100 to 1000s of engineers), In other words Typescript theoretically solves the problem of how do you catch errors before production when all you have is an army of junior devs?
  - arcticfox 5y ago
    I find Typescript to be a huge blessing even for my solo work. It's just better than vanilla JS and I can't be convinced otherwise at this point, the evidence is overwhelming.
- azangru 5y ago
  How do you get one without the other? If typescript weren't (sufficiently) reliable, large projects written in typescript wouldn't be (sufficiently) maintainable.
christophilus 5y ago
JS and Elm are at two ends of the spectrum. Typescript is a very nice middle ground. It’s nearly as fast as JS for prototyping, but is much nicer for maintaining. It’s not 100% type safe, but it’s good enough for me. Refactoring and tooling (autocomplete, etc) are really nice in Typescript and beat the pants off JS.
- cies 5y ago
  Looking from Elm's side I find TS to be much closer to JS than to the middle ground. ReasonML/ReScript or F#+Fable or Kotlin.js maybe more closer to what I consider the middel. JS (which TS is a superset of) if just not a very well designed language.
idoubtit 5y ago
> I had to stop because [...] and depended on some WebGL 3D and game libraries. There's a limitation of Elm hidden in there. If your code needs to interoperate with some JavaScript libraries, you need to define an Elm port for each action (i.e. define how Elm sends/receives "messages" to JS). If the Elm-JS messages are few, it's OK, but if not, the process is painful to code and slow to execute.
- cies 5y ago
  This is true for interaction between pure functional code and the "outside world". It forces you to state all out assumptions about said interaction up front and often deal explicitly with all possible errors that may arise from your assumptions failing. Once that is done you can stay mostly in "pure land", which is quite a blissful experience.
- kadoban 5y ago
  This seems more like a network effect than a limitation of Elm. A bunch of libraries are written in JS so of course that's going to be the least friction and fastest way to use them.
  - dhucerbin 5y ago
    That's only half of the story. Elm prohibits glue code. You can't take well tested JS library, write FFI definitions (like Rescript/Purescript) or typings (like TypeScript) and publish it. You can only publish pure Elm packages. That also means that you can't use WebAPIs if they are not wrapped in packages whitelisted by Elm core team. There are only two methods to interop with javascript and they both have massive downsides. WebComponents are WebComponents and even then Elm is very picky how you can write those. Ports are nice for heavy/async work but are unusable with small functional-ish APIs like Intl.

by d13 5y ago

cercatrova 5y ago

> I’m baffled by the success of Typescript You're baffled, really? The core pitch is that JS developers don't have to learn a whole new language or paradigm such as in the case of other compile-to-JS languages. They can write JS, sprinkle on some TS, and gradually migrate to full TS while learning it along the way. The amount of developer friction is much lower, so that's why it succeeds to a much higher extent (in terms of usage) than other compile-to-JS languages like Elm, PureScript, ReasonML/ReScript, etc.

skrebbel 5y ago

Reliability isn't really part of Typescript's pitch though. It's maintainability.

yakshaving_jgt 5y ago
Those two qualities aren't mutually exclusive.
dustingetz 5y ago
typescript is for maintainability inside midsize to enterprise scale companies with the management and hiring challenges associated with that scale (100 to 1000s of engineers), In other words Typescript theoretically solves the problem of how do you catch errors before production when all you have is an army of junior devs?
- arcticfox 5y ago
  I find Typescript to be a huge blessing even for my solo work. It's just better than vanilla JS and I can't be convinced otherwise at this point, the evidence is overwhelming.
azangru 5y ago
How do you get one without the other? If typescript weren't (sufficiently) reliable, large projects written in typescript wouldn't be (sufficiently) maintainable.

christophilus 5y ago

JS and Elm are at two ends of the spectrum. Typescript is a very nice middle ground. It’s nearly as fast as JS for prototyping, but is much nicer for maintaining. It’s not 100% type safe, but it’s good enough for me. Refactoring and tooling (autocomplete, etc) are really nice in Typescript and beat the pants off JS.

cies 5y ago
Looking from Elm's side I find TS to be much closer to JS than to the middle ground. ReasonML/ReScript or F#+Fable or Kotlin.js maybe more closer to what I consider the middel. JS (which TS is a superset of) if just not a very well designed language.

idoubtit 5y ago

> I had to stop because [...] and depended on some WebGL 3D and game libraries. There's a limitation of Elm hidden in there. If your code needs to interoperate with some JavaScript libraries, you need to define an Elm port for each action (i.e. define how Elm sends/receives "messages" to JS). If the Elm-JS messages are few, it's OK, but if not, the process is painful to code and slow to execute.

cies 5y ago
This is true for interaction between pure functional code and the "outside world". It forces you to state all out assumptions about said interaction up front and often deal explicitly with all possible errors that may arise from your assumptions failing. Once that is done you can stay mostly in "pure land", which is quite a blissful experience.
kadoban 5y ago
This seems more like a network effect than a limitation of Elm. A bunch of libraries are written in JS so of course that's going to be the least friction and fastest way to use them.
- dhucerbin 5y ago
  That's only half of the story. Elm prohibits glue code. You can't take well tested JS library, write FFI definitions (like Rescript/Purescript) or typings (like TypeScript) and publish it. You can only publish pure Elm packages. That also means that you can't use WebAPIs if they are not wrapped in packages whitelisted by Elm core team. There are only two methods to interop with javascript and they both have massive downsides. WebComponents are WebComponents and even then Elm is very picky how you can write those. Ports are nice for heavy/async work but are unusable with small functional-ish APIs like Intl.