Can we use Elm?

[nelsonic]

My plan for tomorrow morning is to attempt to answer the question:

Can we use elm-lang for DWYL projects/products? What are the costs/benefits?

http://elm-lang.org/
https://medium.com/wraptime-io/after-react-elm-152bd6559cb1
http://elm-lang.org/blog/how-to-use-elm-at-work

CC: @SimonLab @nogainbar @sofiapoh @des-des @krosti @jrans @eliasCodes @Shouston3 @rjmk @sohilpandya @mk4111 @jackcarlisle @harrygfox @naazy & anyone else interested ...

relates to: #18

[samhstn]

@andrewMacmurray @ivanmauricio I think you guys might be interested in seeing this

[andrewMacmurray]

thanks @Shouston3 would definitely be interested to hear what people have to say on this!

[nelsonic]

@andrewMacmurray / @ivanmauricio, apologies, I did not mean to "exclude" anyone...
I usually try not to "spam" people with notifications. But if you gent are interested, please vote: https://twitter.com/nelsonic/status/795164336834617344 (thanks!)

And if you don't mind helping to "spread the word" please re-tweet ♻️ ❤️

[sohilpandya]

@nelsonic @andrewMacmurray @ivanmauricio I would love to hear why? Isn't it another thing to learn on top?

Have a look at this http://stateofjs.com/2016/flavors/

I thought there was a reason we were sticking with the plain old vanilla JS. Although I'm open to hear more

[andrewMacmurray]

@nelsonic no worries. @ivanmauricio and I had a play around with elm yesterday and loved ❤️ it. We're gonna build a web app that lets people keep track of how much they've contributed back to FAC using elm for the UI.

[sohilpandya]

@andrewMacmurray that's great to hear.

A few of us (including @iteles & @nogainbar) were thinking of making that a week 9/10 16 man project for the current cohort. But if you guys are already working on it then we'll get them to work on another one of the tools that'll make certain other things easier at FAC. 😻

[andrewMacmurray]

@sohilpandya ah I didn't realise that was a project for FAC9. We could come up with something different, we just want an excuse to get stuck into using it and thought it would be nice to make something that would be useful for FAC.

[andrewMacmurray]

@sohilpandya as far as why we were interested using it, we're functional programming nerds 🤓 Lol but there are some pretty compelling reasons to use it beyond that. This vid is worth a watch

https://youtu.be/R2FtMbb-nLs

[sohilpandya]

@andrewMacmurray I think you guys should go ahead with this, We are just in the very initial stages and pivoting is a big possibility for us 😳

[des-des]

https://github.com/elm-lang/virtual-dom/issues/29

[iteles]

@andrewMacmurray @ivanmauricio @sohilpandya Whilst this isn't the place to discuss the FAC stuff, I would mention that if we're building something that's useful for FAC (or anyone), my main concern is allowing it to be easily extendable by future cohorts/volunteers (essentially this - other issues in that repo well worth a read).

[andrewMacmurray]

@iteles I totally hear that, but what about its utility as a potential learning resource? I'm happy to discuss this elsewhere but not sure where to!

[nelsonic]

@andrewMacmurray discussing building a useful app with elm-lang is a perfect candidate for this thread! I deliberately left the question as open as possible to encourage/invite discussion! 🎉

The last thing I want to do is "shut down" an constructive discussion because it's "off topic" (the standard reason/excuse why questions are "closed" on StackOverflow) ... I'm encouraged by the fact that 38 people have _voted_ on the Twitter Poll!! (please help get everyone to vote so we have as much representation as possible!) even though there are few people who "don't like" or "not interested"... I'm trying to remain "neutral" to not "influence" the Vote while the poll is still open. 😉

our objective at this stage is to "first seek to understand" the sentiment. 🙊
I want to be 100% Clear that I would _never_ "force" anyone to learn something they were not at least a little "curious" about learning ... so we need to gauge how people feel!

To be clear: in terms of having a "stack" that is well-defined and unambiguous, I'm way more interested in going from ES6 straight to Elm in "Week 7" without wasting time on the noise that is (let's be honest) the Facebook-(Franken)-Stack ... The reason I haven't (personally) "embraced" elm in the past is captured here: dwyl/learn-elm#2

but, the fact that elm (currently) has Zero support for server-side-rendering (and we still think progressive enhancement matters!!) is not going to be an issue for much longer which is one of the reasons I opened this thread...! Hopefully that will change soon as noted by @des-des above and indeed by @evancz himself recently at elm-conf so I'm excited that the only remaining "barrier" to me leaving the 💩 behind is almost ready.

Until the Poll closes tho we need to contain our excitement and just encourage people to Vote!

[andrewMacmurray]

@nelsonic @iteles I'd definitely prefer to build something in Elm that's going to be used by people but irregardless of whether it's something that's directly useful to FAC (or anyone), I feel there may be a special case for learning here.

I'm aware that Elm is "one more thing to learn" but compare that with learning something like React - where learning React comes with a huge ecosystem of things to learn like webpack, babel, es6, jsx, flow, redux, immutable. Elm's design seems to incorporate a lot of the benefits of these in a cohesive package (redux was even inspired by the elm architecture).

At first glance, Elm reminds me a little bit of Hapi, it's a "batteries included" approach with a clear design philosophy based on some very sound principles, and not to mention a little bit "left of field"!

on a side note - If we're talking about building software that's easy for people to extend and inexpensive for clients to hire devs to do this, Hapi (which we embrace fully at dwyl and fac) is not exactly a standard choice. Whilst it's arguably easier to pick up than something like elm it still covers a large surface area of plugins and apis.

But I feel the big opportunity here is to embrace functional programming. Functional Programming is HARD, but that "one more thing" that you learn is more foundational than any of the JavaScript that we learn. You can apply widely it in many other programming languages and it's a very important trend in modern programming. It's knowledge that won't be thrown away any time soon.

As far as using it for the DWYL stack, I'm not nearly experienced enough to say (there's a lot more to consider than just learning). But, my gut feeling is I think it would be a missed opportunity if future fac people or volunteers weren't encouraged to get stuck into an elm project, at least if they were a bit curious about it.

(Sorry if this is a bit off topic but really wanted to share my thoughts on this.)

[rjmk]

Great comments in this thread (and in dwyl/learn-elm#2). I think all of the concerns carry some heft.

I think Elm is in a good place in terms of maturity, but some of the complaints around that do seem pretty forceful. First, server-side rendering. No reason why that should continue to be an issue, but I also couldn't predict when it will stop being one. Second, handing Elm code over to clients. If I were hiring a bunch of devs to build a product, I would not hesitate in choosing a "weird" language and investing in the hires. But handing over Elm code to (non-technical) clients does leave them with a logistical problem.

I think the only complaint I don't think is telling is that it's another thing to learn. The Martin Fowler article Nelson linked to made a pretty good case that learning a language vs any other tool is not particularly different.

Also, consider the amount of knowledge and learning you have to repeatedly acquire about your own codebase whenever something unexpectedly breaks in JavaScript. You have to learn so much about how the code you and your team wrote weeks ago just to make small changes, and the knowledge disappears. Yes, you can try and follow "best practices" in your code, but that's of limited use. It can be much less effort to learn a new language and a new way of working than just trying to learn that new way of working in a language that doesn't support it very naturally.

In my experience, enough competence with a language to contribute to a codebase is one of the easiest things a dev will be asked to learn (apart from the first time).

[nelsonic]

@andrewMacmurray, agreed. don't apologize when what you are saying/writing is all relevant! 👍

@rjmk @Yes, I agree that delivering elm-lang code to clients is a tricky one especially for an NGO or Local Council/GOV ... through no fault of their own they are (technology) "risk-averse" and don't care about "performance benchmarks" or blog posts about "tech stack" ...
And we have to be cautious on client's behalf (until we have a comprehensive learn-elm tutorial we can share with people to help get them up-and-running fast...) to re-assure everyone.

I can debate both "sides" of this conversation convincingly with plenty of supporting material. 💬
And I intend to take this discussion to it's logical conclusion (don't worry, you will 😍 the outcome!) the #NextAction is to produce a comprehensive "from-scratch" tutorial that will allow everyone to make up their own minds if they want to commit to elm or stick with the tools @andrewMacmurray listed above... 🔨

We are up to 45 Votes on the Poll: https://twitter.com/nelsonic/status/795164336834617344 please ensure everyone you know has voted! 🗳

We will know the outcome of the elm-lang vote at the same time as the US Election result;
hopefully both go the way of ❤️ not 😨

still think _Riot_ is both conceptually + practically simpler than React: http://riotjs.com/compare/
And if people stick to the JS _goodparts_ (fewer language features focused on unambiguous code) we can build simple apps that are _easy_ for others to _maintain_. But, the more I look into the elm ecosystem the more I am convinced that it's a viable option for us and the people/organisations we serve. 😉

tl;dr ^{(when I were a lad ...)}

Rewind the clock back to 2011 when I was still writing code full-time (instead of reviewing other people's work and helping hire/help other team members ... #nostalgia) We were writing (relatively) "boring" E-commerce web apps and it did not feel particularly "exciting"...

When I started using CoffeeScript and could write white-space significant, compile-to-JS functional expressions, optimised ("good parts"-only) code with the brevity of Lisp I was elated! 🌈 🦄

A few people @groupon were "concerned" that we wouldn't be able to "hire" good people if we picked an "unknown" language ... however using our internal "learning" docs we could teach people who had never written a line of .coffee in their lives CoffeeScript from-scratch and get them up-and-running-and-productive in less than a day on a vast codebase written by hundreds of devs... with the right (simple/focused) language the "on-boarding" can be pretty smooth.
(sadly the learning docs were closed source because they included lots of references to the actual codebase, otherwise dwyl would have a kickass learn-coffeescript repo...!!)

The "proof" that CoffeeScript, Node.js & WebSockets is a "Winning Recipe" came from our friends at Fog Creek, who you may know for their insanely successful "SAAS" Product: Trello: https://trello.com/ see: https://www.fogcreek.com/blog/the-trello-tech-stack/ written in Jan 2012 long before Node.js was "cool" or "trendy" ...
PDF in case the blog post moves: The-Trello-Tech-Stack.pdf

Around the same time I watched Bret Victor's - Inventing on Principle and it made me "believe in magic" and I regret not following my instinct of quitting my "day job" to go do a PhD in Reactive coding based on @worrydream's work https://github.com/worrydream/Tangle ... but mortgage, bills-to-pay, yada yada ...

If I had the luxury of focussing exclusively on building tools & a single product (instead of client-projects which are good for keeping the lights on...) the elm ecosystem is almost exactly what I would want to build:

• Time-travelling (re-playable!) Reactive Debugger: http://debug.elm-lang.org/
• Pure Functions with No-side-effects: https://en.wikipedia.org/wiki/Pure_function (way simpler to understand than "OOP")
• Immutable Data with Predictable State: The case for Immutability learn-react#6

Long-story-short, fast-forward to 2016, the Elm ecosystem makes me feel like this
And I think it would be foolish to waste the enthusiasm a few people have expressed for learning/using elm-lang. ❤️ ✅ 🚀

[nelsonic]

The Twitter Poll Final results are in: dwyl/learn-elm#10 ⚖
And people are elm-curious so we need to write a decent intro guide to help get them excited. 💃

Note: we are still far from answering the original Question, but I'm confident we will have an answer soon. ⌛️
If you have time please help by commenting on the issues or raising new ones you think of: https://github.com/dwyl/learn-elm/issues (thanks!) ❤️ ✅ 🎉

[des-des]

@nelsonic
I am still quite confused about why elm is the right tech for dwyl.

From looking at other dwyl projects, it seems like server-side rendering has been a priority. Assuming that this is still important I see two major problems.

Firstly Elm does not currently support server-side rendering. This is a problem that will eventually go away, but right now it does not seem easy.

The second problem seems much bigger to me. Elm seems like the wrong tech choice to do progressive enhancement. eg:

1. We have a todo list, served as html.
2. The user wants to sort a list of todos. If the client has js disabled then it will request a sorted todo list from the server.
3. In the case where the client has js, we have two options.
   1. Make ajax request for json, create a sorted list of todos, render them. In this case we would need to re-write the view layer in elm. We will have a template for a todo item in elixir, and we will have a view function written in elm, this duplication feels inferior to old stack, where we could reuse handlebars templates.
   2. Shuffle the dom nodes. As far as I understand you would not mess directly with the dom in elm..

As far as I can see, elm + elixir are much nicer pieces of tech than node + js, but it seems like a weird choice for dwyl.. Basically elm is great for building client side apps, but right now, this is all that it is meant to do. Considering that dwyl has always favoured ssr over client side rendered apps, this decision leaves me totally confused.. 😢

[nelsonic]

@des-des You're right to be "confused". Until we have a canonical "Chat" example, it won't be clear how Phoenix and Elm can work together.

Yes, elm does not support Server-Side-Rendering and that is still our priority for ensuring that our Web Apps render and are served as fast as possible for Mobile clients.

What I will say to you and anyone else reading this is: focus on Phoenix for the next couple of months and ignore the Elm in "PETE" for now. PETE PET! 👍

Where Elm comes into play for us is when there is Frontend functionality such as what you built on "ART" and what @Conorc1000 / @roryc89 & @naazy are building for "OA" where the UX lends itself to in-browser validation, calculation, transparent server requests and re-rendering.
In that respect Elm offers us an order-of-magnitude better "developer experience" (nicer to write, reason about and maintain) than the equivalent code in another "front-end framework".

Elm is going to play a major role in the dwyl Products from about April 2017 onward ...
we are going to use Elm to progressively enhance or "Super Charge" our server-side-rendered apps.
The code written for the client does not (should not) be rendered on the server.
If/when Elm has server-side-rendering we will embrace it like a long-lost-loved-one!
But until then we can use "PETE" with Phoenix views and use Elm for specific enhancements.

Yes, that might occasionally mean re-doing certain components in Elm that have already been built in Elixir Templates, but we can "mount" these Elm components in specific DOM elements and let Elm "handle" re-rendering just that element.

You won't need to think about Elm until you need to do "complex" interaction.
A Todo list does not require client-side JS or Elm for that matter.
A Phoenix-based Todo List App with a reasonably low-latency internet connection will do round-trips to the server in under 400ms which is (more than) "fast enough"
We can get that interaction down to 50ms with Elm but that is not the focus of a "Beta" or "MVP" App ... the focus of an MVP is having enough functionality to Test/Validate the idea, no Front-end JS is required for this.

I don't think Phoenix is going to be everyone's "cup of tea" and that's 100% fine.
But it's definitely mine for so many reasons.

The fact that the Phoenix and Elm communities have so much overlap
see/watch: https://www.youtube.com/watch?v=XJ9ckqCMiKk
gives me a lot of hope that Elm will be server-side-rendered in Phoenix quite soon. 🔜
.then it will be "Full Stack Elm" and the whole world will shift to "PETE"!! 🎉

For the people on the Founders & Coders "Course" we need to keep their learning "stable",
there is a lot to learn just with JS, Testing, Node, APIs, PostgreSQL, WebSockets, Heroku, Design, UX etc ... getting them to learn "PETE" would be seriously overwhelming.

I think we should get F&C people to learn Elm and use it with a Node.js "backend".
This is a very legitimate Elm use-case.
Once people have finished the F&C "core program" we should introduce them to Phoenix as a "Level Up" for their "Backend Skills".

To summarise, all DWYL apps can be built with Just "PET".
We will bring in Elm later. 👍

[iteles]

I think I mentioned this in the PR actually - there's definitely a need to clarify that Elm is for client-side enhancements and server-side rendering is still key for what we do @des-des, thanks for the reminder!

[des-des]

@nelsonic Thanks for the awesome answer + video! This makes sense. I agree that Elm is a much nicer + all round better experience than react so I am excited for the future! Also loving Pheonix so far.

[des-des]

Here is an example of elm / phoenix: https://github.com/CultivateHQ/seat_saver

[nelsonic]

@des-des the related blog post for that repo is: http://www.cultivatehq.com/posts/phoenix-elm-11/ 😉

[des-des]

Yeah looked at seat-saver its a rubbish example you could replace elm with js and would not have to make a single change to the server

[nelsonic]

@des-des yeah, I don't think it's meant to be a "this is why Elm is 'better' than JS" post/example ...
more of a "look what we can do without writing JS..."
I Agree that we can do a better example. 😉

[des-des]

ops jus saw it was your link is what I was rubbishing, sorry for the negative language, meant to be rubbishing my link..

We know that we can include js as an asset, the elm here could just as well be angular .. Obvs since elm and phoenix both play nicely with sockets / real time there is some synergy here.

[nelsonic]

closing.
see: https://github.com/dwyl/learn-elm-architecture-in-javascript and https://github.com/dwyl/learn-elm 🎉