I’ve come across Elm several times in the past year, but had never given it a serious look. By some thread of YouTube videos starting with funfunfunction, going through some general conference talk about the importance of teaching functional programming to juniors and ending up at Richard Feldman’s excellent, unusually lengthy presentation of Elm.
Enter the treefolk
It was also put to me by @richtier that the “all or nothing” nature of Elm could contribute to its obscurity relative to React, for example, or that mother of all obscenities, Angular.
Elm is a truly holistic beast. It’s a functional reimagining of all or none of the following; buildchain, application framework, testing infrastructure, package manager. That means you can either have all of those from Elm or none of them.
It’s this that planted a seed of doubt in my mind.
What of the future?
My concern is basically about the longevity of a nascent Elm and its budding community. For a picture of longevity, consider the commit history of that most venerable free software project, PostgreSQL. Perhaps it seems a little morbid to be considering the death of a project just as it is coming to into being, but from a practical standpoint one simply must.
Elm’s creator, Evan Czaplicki, spoke about where he saw the project going a few years ago.
I wanted to get a feel for how Elm has developed, and so set about graphing (in a similar way to the PostgreSQL graph linked above) the development histories of the core repos and the community packages. There are few enough repos in the set mentioned to reasonably download all their respective data and whip it up into some coloured lines.
Downloading all the things
Since the community packages for Elm are all listed on a single page, and they are all predictably hosted on GitHub, it’s easy enough to scrape the repo URLs and clone out the actual repos.
A quick df -h to see if I have enough space on my pathetic MacBook SSD:
Filesystem Size Used Avail Use% Mounted on /dev/disk1 112G 109G 3.4G 97% /
Meh, it’s probably enough. Elm’s packages page is an Elm app (of course!) so let’s scrape using CasperJS and grab all the repos using Python. We’ll traverse each repo we’ve got our hands on with Rust and spit out some JSON detailing its history. So, let’s pipe the list of packages through our rickety collection of code.
I’ll do it in three steps to make things clearer, but you can just pipe from one script to the next; errors are reported on stderr.
Running scrape.js with CasperJS gets an outer list of packages.
casperjs --engine=slimerjs scrape.js > packages
Pipe that to update.py which validates package names, then clones or updates each repo repo.
cat packages|python update.py > package_repos
Finally the Rust binary repo-commits reads repository histories and outputs JSON that we can graph against, in package-histories.json. I compile it first.
pushd repo-commits cargo build popd cat package_repos \ | repo-commits/target/debug/repo-commits \ > package-histories.json
So here it is, a graph showing cumulative sum of number of commits grouped by contributor across all Elm repositories; core, community and those listed on http://package.elm-lang.org/
This data was collected on the 6th of September 2016. I will update the data periodically. If you want to see create an issue if you want me to do it sooner.
You can also see the graph out of context here.
|||In particular, putting API change tracking into package management system seemed pretty revolutionary. I don’t think even Rust does that.|
|||As the saying goes; a WebComponent by any other name ...|
|||Mostly spurred on by this treasure of an article, which I notice now features a narrated audio version. Give it a listen. It reminds me of a Red Dwarf audio book; “One word ... Vim.”|
|||Yeah I did!|
|||You can probably see what I mean by nascent by looking at the equivalent graph for one of the Elm repos.|