4 ms·

I'm curious what Elm offers that cannot be done in TypeScript.

by mikece 8y ago

christophilus 8y ago
Much stronger type guarantees. TypeScript's strength and weakness is how it fits JavaScript like a glove. Elm is a different language entirely, so it can provide much better soundness. It's also a simpler language than JS / TS. TypeScript, being a superset of JS, has a lot of baggage. Elm is pretty small and conceptually simple. Elm is also a framework, not just a language, so it guides your team into building things in one, consistent way (for better or for worse). Finally, the Elm compiler is very good. It produces small, fast build artifacts. Compare the bundle sizes of Elm with the other competing frameworks here[0]. [0] https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld
weavie 8y ago
You can do way less in Elm than you can do in TypeScript. Counterintuitively this makes your code much more robust. Elm is far more opinionated. There is only one framework you can use. The type system is much stronger with no escape hatches. It is impossible to mutate variables. Interfacing to javascript is much harder, and there is only one way to do it, and any results coming back from javascript have to be checked and handled to ensure it is as you expect.
roadbeats 8y ago
You don't need to choose bunch of frameworks and spend hours getting them work together. Elm basically provides the perfect language and abstractions for building UI.
shados 8y ago
As mentioned, the type system is much, MUCH stronger (you basically can't get runtime errors at all unless you put debugging statements in). The redux-like (well, more like redux is elm-like) is baked into the type system so you know it will be done "right". And thanks to the above, there's less bikeshedding within the team from people who want to reduce boilerplate for bad reasons and make the app worse.
spookylukey 8y ago
Could you do the following in TypeScript? Can you, for any button in your interface, at any point in time, reliably calculate at runtime what your page's data model would look like, and if there were going to be any side effects, if you were to click on that button - but without clicking on it or invoking its callbacks (which could potentially change all kinds of things)? You can do that with Elm (more info here - https://lukeplant.me.uk/blog/posts/two-experiences-with-elm/ https://lukeplant.me.uk/blog/posts/two-experiences-with-elm/ ), due to The Elm Architecture and everything being immutable. (In theory you could do this in TypeScript, but it would be a lot of work and its reliability would depend on everyone coding everything a certain, very unnatural way, with no help from the compiler). I'm using Elm in production, version 0.18, it is an extremely robust way to make front end code. You just don't have runtime issues. However, like IBM folks (mentioned in another reply) who said in the their post they didn't know how they would upgrade to 0.19, I also don't know how I will be able to upgrade. Specifically, 0.19 adds some cripple-ware restrictions (you can't use native modules unless you are contributing to certain projects). So, if you want to use something like Intl - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - not only is there no wrapper provided, the restrictions in 0.19 attempt to stop you from writing your own wrapper. Only the core team can do it, which requires them having both the expertise and motivation to do so. Plus Elm has essentially a closed-source development process. In fact, there is no 'process' for contributing, and the fact that there is no process is deliberate, as far as I can tell. So for me, if I can't find a way around the restrictions, they may kill my ability to being able to keep my code nicely architectured (i.e. using The Elm Architecture). I may be forced to switch to something like ReasonML with bucklescript-tea - https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea
- mcheely 8y ago
  I think most of the Intl api could work reasonably well with ports and custom elements. The formatters in particular, which make up most of the API, would probably work quite nicely as custom elements. It's really only string comparison that I can imagine needing ports for, outside of some particularly unusual use case.

I'm curious what Elm offers that cannot be done in TypeScript.

by mikece 8y ago

I'm curious what Elm offers that cannot be done in TypeScript.

Much stronger type guarantees. TypeScript's strength and weakness is how it fits JavaScript like a glove. Elm is a different language entirely, so it can provide much better soundness. It's also a simpler language than JS / TS. TypeScript, being a superset of JS, has a lot of baggage. Elm is pretty small and conceptually simple. Elm is also a framework, not just a language, so it guides your team into building things in one, consistent way (for better or for worse). Finally, the Elm compiler is very good. It produces small, fast build artifacts. Compare the bundle sizes of Elm with the other competing frameworks here[0]. [0] https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld

weavie 8y ago

You can do way less in Elm than you can do in TypeScript. Counterintuitively this makes your code much more robust. Elm is far more opinionated. There is only one framework you can use. The type system is much stronger with no escape hatches. It is impossible to mutate variables. Interfacing to javascript is much harder, and there is only one way to do it, and any results coming back from javascript have to be checked and handled to ensure it is as you expect.

roadbeats 8y ago

You don't need to choose bunch of frameworks and spend hours getting them work together. Elm basically provides the perfect language and abstractions for building UI.

shados 8y ago

As mentioned, the type system is much, MUCH stronger (you basically can't get runtime errors at all unless you put debugging statements in). The redux-like (well, more like redux is elm-like) is baked into the type system so you know it will be done "right". And thanks to the above, there's less bikeshedding within the team from people who want to reduce boilerplate for bad reasons and make the app worse.

spookylukey 8y ago

Could you do the following in TypeScript? Can you, for any button in your interface, at any point in time, reliably calculate at runtime what your page's data model would look like, and if there were going to be any side effects, if you were to click on that button - but without clicking on it or invoking its callbacks (which could potentially change all kinds of things)? You can do that with Elm (more info here - https://lukeplant.me.uk/blog/posts/two-experiences-with-elm/ https://lukeplant.me.uk/blog/posts/two-experiences-with-elm/ ), due to The Elm Architecture and everything being immutable. (In theory you could do this in TypeScript, but it would be a lot of work and its reliability would depend on everyone coding everything a certain, very unnatural way, with no help from the compiler). I'm using Elm in production, version 0.18, it is an extremely robust way to make front end code. You just don't have runtime issues. However, like IBM folks (mentioned in another reply) who said in the their post they didn't know how they would upgrade to 0.19, I also don't know how I will be able to upgrade. Specifically, 0.19 adds some cripple-ware restrictions (you can't use native modules unless you are contributing to certain projects). So, if you want to use something like Intl - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - not only is there no wrapper provided, the restrictions in 0.19 attempt to stop you from writing your own wrapper. Only the core team can do it, which requires them having both the expertise and motivation to do so. Plus Elm has essentially a closed-source development process. In fact, there is no 'process' for contributing, and the fact that there is no process is deliberate, as far as I can tell. So for me, if I can't find a way around the restrictions, they may kill my ability to being able to keep my code nicely architectured (i.e. using The Elm Architecture). I may be forced to switch to something like ReasonML with bucklescript-tea - https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea

mcheely 8y ago
I think most of the Intl api could work reasonably well with ports and custom elements. The formatters in particular, which make up most of the API, would probably work quite nicely as custom elements. It's really only string comparison that I can imagine needing ports for, outside of some particularly unusual use case.