31–40 of 44 posts
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..
> Also, given that they write about web technologies, then their static site returns a blank page when js is not enabled.. Seems like a log management company that mostly writes about security and devops, not really a "web technology" site
Anyway, it probably isn't much of an issue to them, but, to hide the bottom popup Firefox's reader mode didn't work, so tried disabling js and discovered the issue. Gatsby does seem to have SSR though, so perhaps it's easily doable should they want to.
Earlier quoted context omitted.
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…
> And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded 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 ty…
I both agree and disagree with this. I think if you're coming from a statically typed language, and you're familiar with features in those language - Typescript is a very complex type system, where it can often be difficult or frustrating to express common paradigms.
That said... if you're coming from something like Ruby/JS, typescript has a pretty simple path to convert your existing code, and it doesn't get too fussy about letting you punt on the problem for a bit (start with very loose rules and lots of "any" - get more strict over time).
Earlier quoted context omitted.
> And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded 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 ty…
> I don't thing there are many mainstream languages that have a more complex type system. I both agree and disagree with this. I think if you're coming from a statically typed language, and you're familiar with features in those language - Typescript is a very complex type system, where it can often be difficult or frustrating to express common paradigms. That said... if you're coming from something like Ruby/JS, typ…
There is a confusion on terminology though. You are arguing about ease of use which is a different measure from complexity. That might have caused a misunderstanding.
Complexity is an objective measure while ease of use is subjective and based on your previous experience. For example the language Brainfuck is very simple (conceptually) but very difficult to use for most humans.
TS is objectively complex but also easier to use for Ruby/JS devs as you wrote.
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`.
Earlier quoted context omitted.
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 (…
If one leans toward using Elm for its various excellent qualities, but shares your concerns about it, what should one use instead?
Earlier quoted context omitted.
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 (…
There's essentially an F# implementation now that's under active development right? I haven't used it and forget the name, but last time I looked into it it, it seemed well-regarded and the people using it like it.
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`.
"Stateless components", aka if you're not trying to make things sound more complicated than they are, "functions"
b) it's easy to have a function producing HTML that isn't ready for re-use in your application.
Saying "It's just functions!" is really selling it short.