Live data from Hacker News

Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

dailydrip.com

31–40 of 76 posts

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#31
post #26

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

Elm is very new in the grand scheme of things and it was considered experimental for quite a while. The recent changes show that its developers are still willing to make big changes. But I do believe it's stabilizing quickly and I wouldn't be surprised to start seeing it used a lot more, though still mostly in smaller hobbyist projects simply because even if it stabilizes it's still so new that you can't expect large…

FWIW, I don't think Cisco counts as a hobbyist shop: https://github.com/CiscoCloud/mantl-ui-frontend

:D

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#32

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

I've been playing with it over the last couple of days. Having dabbled in Haskell in the 90s it all feels familiar and clean. Really quick to get up and running and the compiler / messages definitely give a lot of guidance.

I'm not deep enough into it to really assess yet, but I suspect the difficulty is how you integrate it with existing JS code. It feels like maybe it's an all-Elm or nothing world, which makes it hard for organisations to take it for a test run when they have an existing codebase to play nice with.

My exploration is an ongoing activity to figure out which framework / methodology is best to continue building our existing product on. We're currently using Angular (1) and some react components. I did some prototyping with Redux (including investigating Sagas) and familiarised myself with RxJS and MobX. I found the boilerplate in Redux distracting some I'm still looking to see what else is out there – would love to hear how others are assessing these tools.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#33
post #32

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

I've been playing with it over the last couple of days. Having dabbled in Haskell in the 90s it all feels familiar and clean. Really quick to get up and running and the compiler / messages definitely give a lot of guidance. I'm not deep enough into it to really assess yet, but I suspect the difficulty is how you integrate it with existing JS code. It feels like maybe it's an all-Elm or nothing world, which makes it h…

You can easily "sprinkle a little elm component in" for what it's worth to try it out in production. I know NoRedInk pulled it into a heavy React-based project. You basically set up intercommunication between components via ports. It's a fantastic solution once you grok it.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#34
post #33
post #32

Earlier quoted context omitted.

I've been playing with it over the last couple of days. Having dabbled in Haskell in the 90s it all feels familiar and clean. Really quick to get up and running and the compiler / messages definitely give a lot of guidance. I'm not deep enough into it to really assess yet, but I suspect the difficulty is how you integrate it with existing JS code. It feels like maybe it's an all-Elm or nothing world, which makes it h…

You can easily "sprinkle a little elm component in" for what it's worth to try it out in production. I know NoRedInk pulled it into a heavy React-based project. You basically set up intercommunication between components via ports. It's a fantastic solution once you grok it.

And the other way around? What if you had a big existing submodule in JS that you wanted to make use of within an Elm app? Is that doable?

One of the things that's really attractive about React is that there are already a lot of components you can drop in to handle behaviours for you. If I could somehow utilise those within Elm, it would lower the entry barrier for me.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#35
post #34
post #33

Earlier quoted context omitted.

You can easily "sprinkle a little elm component in" for what it's worth to try it out in production. I know NoRedInk pulled it into a heavy React-based project. You basically set up intercommunication between components via ports. It's a fantastic solution once you grok it.

And the other way around? What if you had a big existing submodule in JS that you wanted to make use of within an Elm app? Is that doable? One of the things that's really attractive about React is that there are already a lot of components you can drop in to handle behaviours for you. If I could somehow utilise those within Elm, it would lower the entry barrier for me.

You could just create a communication scheme between the two parts. They're basically 2 sides of the same coin. I promise it's easy and great!

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#36
post #21

Earlier quoted context omitted.

I've heard that interpolation with existing JS libs is painful.

This is because in Elm a runtime error is a compiler bug. If you want no runtime errors, interoperating blindly with JavaScript is a great way to fail :-\ Another great thing about the community is a goal of a single great library for every use case, rather than a lot of half-baked competing libraries. So expect there to be a single great modal library. Etc.

That last part sounds pretty cool, how is this sort of thing being encouraged?

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#37

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

I walked away from Elm still being very enthusiastic about it and watching its progress. I started coming to Elm hackathons in 2014, did a few helloworlds of increasing complexity, eventually tried to write a portion of my app in Elm; there were ups and downs and then one of my (very few) customers asked me to create an API call to something that was happening in the browser. This code was written in Coffeescript, and I had to clean it from DOM dependencies (it builds a complex SVG and then just inserts it into the DOM, so that was relatively easy) and integrate with Express. Auth, cookies, all the usual stuff and the prototype was ready. And then I realized that if I had this code already rewritten in Elm, I'd have been busted. I could easily imagine someone else wanting to have the portion I was writing in Elm as an API call (it was another complex SVG) and for that, I would have no known course of action.

Elm is not just a language, it's a language + frontend UI framework. It is theoretically possible to run Elm code under Node, but the relative level of craziness is similar to "writing a C++ compiler in Angular", please let me exaggerate a bit :-)

After this adventure, I realized that having the ability to share code between server and client is too indispensable for me to trade for lack of runtime errors.

Native interface - I use a lot of js code already written by somebody else. I have a very extensive data manipulation library developed in Coffeescript for my application. It's proven, tested, documented and presents a solid foundation for whatever I decide to write using the data I have. I want to use this code freely. In Elm native interface is frowned upon and the official way is to use ports, which is quite cumbersome, especially for procedural libraries.

As an OSS project, Elm is too centralized for my taste. I'm fine writing helloworlds, toys, learning projects, etc in the language that is being designed and developed by a single person not accepting contributions from the public, besides probably a very small curated list (not sure about that part). But for the business, it's just too much risk yet.

I moved to Purescript. I haven't yet started writing for the browser yet :-) but so far Node and Google Apps Script were doing pretty well. In a sense as a language Purescript is both more demanding (it's much closer to Haskell than Elm) and more forgiving, more javascripty in a good sense of this word, just a part of the toolchain, not pretending to be an ultimate answer to everything. The native interface is best in class.

Frankly, for the category theory idiot like me, Purescript is easier than Elm, while Elm is considered much simpler exactly due to many compromises with "The Math". Almost every decent beginner-friendly Haskell book will work for Purescript, you don't need to break your head over "Elm doesn't have monads, but it does have Effects and Maybe and what not, which are technically monads, but we don't call them monads, etc...". Maybe for others it's different. I can recognize design decisions Evan made and why he made them and I'd like to see how it goes. But I'll watch from the sidewalk for now.

Just my 2 cents.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#38

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

Elm is the coolest, best programming language ever made for practical purpose and adoption by the mass...that cannot be used for practical purpose and the mass because the FFI for libraries is a private API (the "public" FFI only let's you interop within your own application/world, making it hard to wrap libraries or build libraries that do interop).

So it's basically a language we desperately want to use, but can't.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#39
post #35
post #34

Earlier quoted context omitted.

And the other way around? What if you had a big existing submodule in JS that you wanted to make use of within an Elm app? Is that doable? One of the things that's really attractive about React is that there are already a lot of components you can drop in to handle behaviours for you. If I could somehow utilise those within Elm, it would lower the entry barrier for me.

You could just create a communication scheme between the two parts. They're basically 2 sides of the same coin. I promise it's easy and great!

:) Ok, I'm going to take your word for it! Hopefully I should get to that stage tomorrow and it will all become clear.

It's not that I even have a clear picture of what I need to achieve but with each of these different tools I'm trying to poke at them to see where they fall down. So far, Elm feels the nicest, but it's the smaller ecosystem / lack of libraries that's the most obvious shortcoming so I'm trying to understand what the options are for interoperability on that front.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#40
post #21

Earlier quoted context omitted.

This is because in Elm a runtime error is a compiler bug. If you want no runtime errors, interoperating blindly with JavaScript is a great way to fail :-\ Another great thing about the community is a goal of a single great library for every use case, rather than a lot of half-baked competing libraries. So expect there to be a single great modal library. Etc.

That last part sounds pretty cool, how is this sort of thing being encouraged?

I'm no Elm expert, but as far as I understand, the "native library" APIs, the kind that are used to actually wrap browser APIs and interface with javascript in a way that can be published and made reusable, is "private". I mean, you can look at the source and make your own, but you're playing in undocumented, unstable territory.

The only "official" interop channel is the "port" system, which only lets you do a publisher/subscriber type thing with your application at runtime, and cannot be used in a library.

So you basically cannot make a "blessed" library that uses native browser APIs.

Post reply on HN