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.
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.
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.
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.
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?
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.
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.
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.
> Somehow didn't know this --I can't help but wonder why.
JS being the monolithic tyrant that other tyrants see with envy doesn't help.
In the server and elsewhere you have several major langs with big enough sub-cultures and a stablished ethos of sharing, even if that mean the second biggest tyrant of C.
JS developers overshadow any other tribe, so that mean that population could have much less exposure to polyglot alternatives.
And then all that libraries, that are made to make sad any FFI you can trow at it.
There are probably tens of thousands of developers waiting in line to switch out JS. The reason they can’t is not even that it can’t run in the browser (many can) but that it interacts with the DOM natively, which makes it the only language that can be used in the browser without masochism. In turn, the DOM is the only UI that is truly cross platform, which makes it the by far best and cheapest option because everything else is either hobby or proprietary in 10 different flavors depending on which fiefdom you build your product in. Basically, JS isn’t popular because of ability, but its interoperability.
The effort & money that has been poured into tech after JS was created would dwarf anything beforehand. Yet, we live today by the open standards that were developed before Bezos etc started purchasing private islands. So I’m a little hesitant to blaming JS for being backwards when the rest of the world couldn’t come up with an alternative despite having 1000x (not an exaggeration I think) more time and money to do so.
Server application development is just much different than UI/client development.
It's easy to make JS work on the server like it's easy to make anything viable on the server: it's just one machine running your code, and the runtime only has to interoperate with a well known interface (the OS) that barely changes. And then consider that a web server's interface to the "user" is over a single, abstract port.
In a browser application, you have to interface with JS to drive the UI building blocks (DOM and company). And the web API is async. And you have to build an interactive UI. And abstractions on top of all this are extremely leaky because they are hard to simply paper over and pretend they don't exist like you can on the server.
Often when I see a JS replacement on the browser, it seems to offer very little over JS beyond "hey look, it's not JS" which just isn't enough to justify the penalty.
Finally, the hard part of UI development is stuff like state management and deciding when things should rerender. Switching to a different language alone doesn't give you that. Figuring out a solution in JS, like MobX + React for example, probably does more for you than trying to make a whole new language work.
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.