4 ms·

I feel like Gleam's ability to compile to BEAM and JS is underutilized. With how many people in the React/Typescript ecosystem are super excited about full sta

by h14h 2y ago

I feel like Gleam's ability to compile to BEAM and JS is underutilized. With how many people in the React/Typescript ecosystem are super excited about full stack type safety, this feature of Gleam feels like it's flying under the radar. The pieces are there to have an unparraled DX for building everyday web apps, but the pieces haven't been assembled in a way that "clicks" for most people. At least, not that I've seen.

AzzieElbab 2y ago
It is counterintuitive, but this feature did not do much for the Scala ecosystem. I wrote some toy projects but have not seen any in the real world.
- lanthissa 2y ago
  some of the largest scala codebases under active development make heavy use of this feature.
  - hocuspocus 2y ago
    Sure but but the argument here is that Scala.js failed to grow the ecosystem. It doesn't convince people who aren't already.
greener_grass 2y ago
This already exists with F#, OCaml, Scala, Haskell... it doesn't seem to be a big draw.
- h14h 2y ago
  Somehow didn't know this --I can't help but wonder why. The effort to make JS work on the server has been much more successful than any attempt to make server languages work on the client. Nothing jumps out to me as an obvious technical reason this is the case -- maybe it's moreso an imbalance in effort & attention?
  - ameliaquining 2y ago
    DOM APIs are only available in JavaScript, so doing things in the browser in a non-JavaScript language requires FFI—and it's a general truism of programming that FFI tends to be a pain point. Languages that target client-side web development try to compensate for this by offering language-native DOM abstractions of higher or lower quality, but usually you end up having to do something that these abstractions didn't anticipate, and/or incorporate a third-party library from npm, which forces you back into FFI. On the server it's much rarer for some critical piece of functionality to be available only in one language, because the server environment itself is language-agnostic.
    - greener_grass 2y ago
      F# allows you to use React pretty much directly, but it has still been only a modest success.
      - ch4s3 2y ago
        I think F# suffers from being a second class citizen to C# inside of Microsoft. If it ran on a different VM or got more attention it may be more popular. It seems quite nice.
        greener_grass 2y ago
        Without access to the .NET ecosystem it would be dead in the water
      - deleted 2y ago
        [deleted]
    - grndn 2y ago
      As another comment said, you can write client side code in F# which gets transpiled to JS, just like Typescript or CoffeeScript. This approach allows you to use JSX components directly from your F# code. It's very cool. Other FP languages have something similar. https://www.compositional-it.com/news-blog/fsharp-react-series-feilz/ https://www.compositional-it.com/news-blog/fsharp-react-seri...
- hamandcheese 2y ago
  Choosing not to use JS on the frontend is much riskier than choosing to use JS on the backend, IMO.
hinkley 2y ago
I thought when I moved from Springboot + JavaScript to NodeJS I would enjoy the lack of context switching. What I didn’t know about myself is that I hate JavaScript a little bit more than I hate Java and for different reasons. So I was volunteering for stories in one when I was feeling frustrated with the other. Now it’s just more JavaScript unless I work on CLI, CI/CD pipelines, or telemetry bugs, which are still almost half JavaScript. I cannot get away from it enough and every time I do that takes someone else’s opportunity to do the same. I worry that all Gleam all the time would arrive at the same conclusion.
- skydhash 2y ago
  IMO, JavaScript is fine for scripting. Same with Python, Lua, and others. Great for glue code or a small feature, when the bulk of the system is written is in a saner language with proper libraries.
  - hinkley 2y ago
    Any time you drag a language out of its sweet spot is gonna be a bad time. Javascript is out of its sweet spot quite a bit, which is how we end up with typescript. However statically strongly typed code is out of its sweet spot where prototyping and to an extent refactoring are concerned. And mercifully we now have progressively typed languages trying to fill that space.

by h14h 2y ago

AzzieElbab 2y ago

It is counterintuitive, but this feature did not do much for the Scala ecosystem. I wrote some toy projects but have not seen any in the real world.

lanthissa 2y ago
some of the largest scala codebases under active development make heavy use of this feature.
- hocuspocus 2y ago
  Sure but but the argument here is that Scala.js failed to grow the ecosystem. It doesn't convince people who aren't already.

greener_grass 2y ago

This already exists with F#, OCaml, Scala, Haskell... it doesn't seem to be a big draw.

h14h 2y ago
Somehow didn't know this --I can't help but wonder why. The effort to make JS work on the server has been much more successful than any attempt to make server languages work on the client. Nothing jumps out to me as an obvious technical reason this is the case -- maybe it's moreso an imbalance in effort & attention?
- ameliaquining 2y ago
  DOM APIs are only available in JavaScript, so doing things in the browser in a non-JavaScript language requires FFI—and it's a general truism of programming that FFI tends to be a pain point. Languages that target client-side web development try to compensate for this by offering language-native DOM abstractions of higher or lower quality, but usually you end up having to do something that these abstractions didn't anticipate, and/or incorporate a third-party library from npm, which forces you back into FFI. On the server it's much rarer for some critical piece of functionality to be available only in one language, because the server environment itself is language-agnostic.
  - greener_grass 2y ago
    F# allows you to use React pretty much directly, but it has still been only a modest success.
    - ch4s3 2y ago
      I think F# suffers from being a second class citizen to C# inside of Microsoft. If it ran on a different VM or got more attention it may be more popular. It seems quite nice.
      - greener_grass 2y ago
        Without access to the .NET ecosystem it would be dead in the water
    - deleted 2y ago
      [deleted]
  - grndn 2y ago
    As another comment said, you can write client side code in F# which gets transpiled to JS, just like Typescript or CoffeeScript. This approach allows you to use JSX components directly from your F# code. It's very cool. Other FP languages have something similar. https://www.compositional-it.com/news-blog/fsharp-react-series-feilz/ https://www.compositional-it.com/news-blog/fsharp-react-seri...
hamandcheese 2y ago
Choosing not to use JS on the frontend is much riskier than choosing to use JS on the backend, IMO.

hinkley 2y ago

I thought when I moved from Springboot + JavaScript to NodeJS I would enjoy the lack of context switching. What I didn’t know about myself is that I hate JavaScript a little bit more than I hate Java and for different reasons. So I was volunteering for stories in one when I was feeling frustrated with the other. Now it’s just more JavaScript unless I work on CLI, CI/CD pipelines, or telemetry bugs, which are still almost half JavaScript. I cannot get away from it enough and every time I do that takes someone else’s opportunity to do the same. I worry that all Gleam all the time would arrive at the same conclusion.

skydhash 2y ago
IMO, JavaScript is fine for scripting. Same with Python, Lua, and others. Great for glue code or a small feature, when the bulk of the system is written is in a saner language with proper libraries.
- hinkley 2y ago
  Any time you drag a language out of its sweet spot is gonna be a bad time. Javascript is out of its sweet spot quite a bit, which is how we end up with typescript. However statically strongly typed code is out of its sweet spot where prototyping and to an extent refactoring are concerned. And mercifully we now have progressively typed languages trying to fill that space.