21–30 of 44 posts
Typescript people pretend to love type system and its benefits while ignoring languages like this which has type designed from ground up. If Elm had some ways to easily preserve object reference (something like `mut` something or reference type like in Webassembly), that would unlock a lot of js interop stories rather than just `port`.
Typescript people pretend to love type system and its benefits while ignoring languages like this which has type designed from ground up. If Elm had some ways to easily preserve object reference (something like `mut` something or reference type like in Webassembly), that would unlock a lot of js interop stories rather than just `port`.
I've introduce TypeScript to multiple teams already, and if the transitions were not frictionless, they were always extremely fruitful in the end.
And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded, because people using high-level languages don't want to know about low-level CPU/memory details, they just need to build things and have something that is "fast-enough" (and safe-enough, if possible).
Typescript people pretend to love type system and its benefits while ignoring languages like this which has type designed from ground up. If Elm had some ways to easily preserve object reference (something like `mut` something or reference type like in Webassembly), that would unlock a lot of js interop stories rather than just `port`.
TypeScript has always been very explicit it's trading soundness for productivity. And don't assume "typescript people" only do TypeScript. I've introduce TypeScript to multiple teams already, and if the transitions were not frictionless, they were always extremely fruitful in the end. And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded, because people usin…
Both Rust and Elm have a much simpler type system than TS.
Well, for Rust it can maybe be argued to have its complexities but Elm is dead simple. In fact the most common criticism of Elm is that it it lacks more complex features that people from the Haskell world are used to.
Allowing for the gradual typing of a dynamic language like JS is extremely challenging requiring stuff like structural typing which is not at all common in most mainstream programming languages. I don't thing there are many mainstream languages that have a more complex type system.
The value TS offers is ease of gradual adoption and access to the huge JS-ecosystem and for that you absolutely pay a price in complexity. It is absolutely trivial to design a language with a much simpler, sound type system that offers higher productivity and a smaller learning curve than TS but that wouldn't have much value for most people as the access to the JS stuff and gradual adoption.
Typescript people pretend to love type system and its benefits while ignoring languages like this which has type designed from ground up. If Elm had some ways to easily preserve object reference (something like `mut` something or reference type like in Webassembly), that would unlock a lot of js interop stories rather than just `port`.
No, we ignore Elm because it has a bus-factor of one.
Can anyone more knowledgeable on Elm comment on the "statelessness" as there still is a state. There isn't an explicit type alias for the state nor is there an explicit update though. Maybe "implicit state" would be a more fitting name here. Also, given that they write about web technologies, then their static site returns a blank page when js is not enabled..
The state is completely handled by the parent. So the component itself is indeed stateless. Basically, the message is: Avoid having components with local state, especially if it needs to be synchronized with the parent. Instead have one central place to handle state. Which is generally good advice and not really that Elm specific.
By the way, can anyone suggest a good zero-to-Elm tutorial/course/book/whatever for people with no web frontend experience (coming from desktop GUI dev) to get on board with Elm web GUI apps development quickly?
Before you commit too much time to learning Elm, please understand that Elm has somewhat unique cultural values. The Elm leadership team has a very specific vision for how Elm should be used and actively discourage alternate visions (in particular for JavaScript interop). In addition, it's difficult to know how the language will change or propose changes to the language. There is no public roadmap and GitHub issues (…
By the way, can anyone suggest a good zero-to-Elm tutorial/course/book/whatever for people with no web frontend experience (coming from desktop GUI dev) to get on board with Elm web GUI apps development quickly?
Before you commit too much time to learning Elm, please understand that Elm has somewhat unique cultural values. The Elm leadership team has a very specific vision for how Elm should be used and actively discourage alternate visions (in particular for JavaScript interop). In addition, it's difficult to know how the language will change or propose changes to the language. There is no public roadmap and GitHub issues (…
Typescript people pretend to love type system and its benefits while ignoring languages like this which has type designed from ground up. If Elm had some ways to easily preserve object reference (something like `mut` something or reference type like in Webassembly), that would unlock a lot of js interop stories rather than just `port`.
No, we ignore Elm because it has a bus-factor of one.
And now most of the design patterns that get dialectic attention in the Elm community are aimed at addressing the problems we inflict upon ourselves by trying to adapt TEA to inappropriate use cases.
Earlier quoted context omitted.
The state is completely handled by the parent. So the component itself is indeed stateless. Basically, the message is: Avoid having components with local state, especially if it needs to be synchronized with the parent. Instead have one central place to handle state. Which is generally good advice and not really that Elm specific.
Being restricted to only one central place means you have to wire everything to that central place. This usually results in writing manually mapping boilerplate between X different message types, which is one of the worst parts in every Elm(-inspired) project I've seen.
At least this works well for us when building a web client, but I can't speak to how easy it is if you're using that architecture for other purposes.