Timeline

minilatex is an Elm package for converting a subset of LaTeX into Html – a way to put LaTeX into the browser. We will talk about the design and implementation of the parser and renderer, and how the package is used in a web app to create and publish technical documents. The package itself is pure Elm and relies on Evan Czaplicki’s elm-tools/parser. It uses a diffing strategy suggested by Ilias van Peer which make performance in a day-to-day editing environment extremely fast (yay!)

The app ( under development at http://www.knode.io) will also process mathematical text. For this, it uses ports, since to process mathematical text, one must use the MathJax.js package as a kind of rendering server. We will briefly touch on this part of the design, and describe some of the technical challenges and performance issues.

I’m a (co-)founder of Syncrypt, an open source, zero-knowledge, client-side & end-to-end encrypted file backup and sharing service. We started out with a CLI client & daemon written in Python, that does all encryption and uploading. Later we started working on a GUI written in JS, React and Electron. Since we’re all mostly backend engineers by trade, we got tired of using JS (& React to be honest) after a short while of using it and decided to look for alternatives. I found out about Elm due to researching alternatives to React. It took me about 3 days to fully get the hang of the language but I felt productive from day 1. I’ll talk about the learning curve, about how great the development tools are in learning the language itself and how I ended up with a working prototype (including JSON parsing!) after the first 3 days of working on the Elm based rewrite. The Elm UI talks to the python daemon via HTTP & JSON.

Imagine Alice and Bob editing the same text document at the same time from different devices – but both being offline. How could their changes be merged eventually so that both ends yield the same result and the intention of both probably conflicting editions is preserved? Conflict-free replicated data types (CRDTs) to the rescue! In a mobile world with unreliable network connectivity, CRDTs allow for distributed offline-first applications integrating concurrent changes in a lightweight way. Data replicas are guaranteed to be eventually consistent among peers while keeping the context and order of merged operations. In this talk I will briefly describe CRDTs in general and why they matter to reactive Web development. Furthermore, I will present an Elm implementation of LSEQ - a CRDT for sequential data like text - and its binary serialization format. Finally, I will demo a collaborative Web app built on top of it.

Have you wanted to publish a package, but don’t know where to begin? The Elm package ecosystem is filled with wonderful and useful packages, and it can be intimidating to try and add to that. But while it can take real effort to create something good, it doesn’t have to feel so overwhelming! In this talk, I’ll show you small, concrete steps to take so you can finally publish that code you’ve been sitting on. You’ll leave with the confidence that you can make something really nice!

We are drawn to Elm for many reasons: ‘compiler as assistant’, friendly error messages, pedagogic documentation, static typing, immutable data structures, pure functions. Yet the whole is more than the sum of its parts resulting in a programming philosophy that is declarative, task focussed and beginner-friendly. This talk considers how that philosophy influenced the design of elm-vega and the adoption of Elm as the primary language to illustrate Literate Visualization (LitVis).

LitVis combines declarative specification of a visualization with a narrative that justifies its design. Elm and Vega are ideal languages for expression of the design and we describe how we integrated them with markdown to create a LitVis environment in Atom and VS Code. We describe how the Elm philosophy has influenced the design of LitVis and lessons learned. This has relevance not only for those interested in visualization with Elm but also anyone designing new packages and programming environments.

This talk will look at some of the lessons learned from migrating the codebase of the elm-geometry package from its object-oriented origins in C++ and Scala to its current implementation in Elm.

We’ll show how to take code that depends on various features found in object-oriented languages and rewrite that code in idiomatic Elm. For example, in a language without overloading or implicit conversions, how do you write functions that work with both vectors and unit vectors? Without inheritance, how do you share 3D transformation functionality between different types of geometry? Answering these questions carefully can require some significant “conceptual refactoring”, but often results in Elm code that is simpler, clearer and more flexible than the original! We’ll show how to take code that depends on various features found in object-oriented languages and rewrite that code in idiomatic Elm. For example, in a language without overloading or implicit conversions, how do you write functions that work with both vectors and unit vectors? Without inheritance, how do you share 3D transformation functionality between different types of geometry? Answering these questions carefully can require some significant “conceptual refactoring”, but often results in Elm code that is simpler, clearer and more flexible than the original!

Regardless of your knowledge level, writing a course is a good way to improve your skills. Explaining a concept lets you watch it under a different point of view, out of habits based on practice! Shall we wait to be an “expert” to publish a tutorial? How to explain what seems so simple or, by contrast, so complicated? Come to discover it!

We get a lot for free from using the web platform. Rendering text is one of such things that browsers do well. But what if we wanted to implement this ourselves from scratch? Then we would not only have to learn typographic terms, but also understand their true behavior.

Having implemented the rendering of a typeface, that my wife designed, I would like to share the challenges of modelling the text flow in Elm. Even though this has a limited practical applicability, my hope is that you would not only get some insights into typeface properties, but also learn to appreciate the tools we have. And of course you will see how good it fits with Elm!

In this talk we will use the amazing powers of Elm to live code a Mondrian Art Generator. We will do a deep dive on building complex random generators and see how we can combine them to generate conceptual art. After that, we will go through a proof of concept that uses recursive random generators to achieve a similar effect.

Having total type-safety within an application in Elm makes working on projects a joy, especially long term when things get increasingly complicated and changing requirements abound.

However what about type safety between versions of our apps?

Once our applications are out in the wild, how do we get our users from version A to version B without throwing everything away in the transition? Could we use Elm’s guarantees somehow to help us make this process smooth and enjoyable?

This talk will explore 12 months of research and prototyping on turning “decidious” Elm deployments into an “evergreen” affair.

The UI client of our ARIC Fraud Hub product is a 100k LOC Elm app. Over the last 18 months we ported it from Agnular 1 to Elm, and added many new features. On the way we learned a lot. We’ll present a summary of that story: How we chose and adopted Elm. How we made Elm and Angular play nice together during the migration. What we learned from using Elm with a team of ~6 engineers on a large complex project. And what we want in the future: from Elm and from ourselves.

Elm helps us to think in terms of algorithms, not just in terms of “let’s make it work”. We can focus on one task at a time, without having the overhead of having to think in terms of “the whole app”.

And it allows us to pick highly complex subjects and tackle them for fun and profit.

Creating a date picker like https://developer.apple.com/documentation/uikit/uidatepicker is very complex. We have to model the display with inline css 3d and requestanimationframe, the touch with touch events, the physics of the date picker with some physics theory. And doing that is javascript would mean handling every aspect of it in a “global” way.

Creating a native looking date picker in elm means we can concentrate on the bigger vision (the date picker), one little function at a time, and it means we can do it in a reusable manner.

This talk will outline how we did it and what the result looks like, and it’ll emphasise how we designed it.

In this talk, I will share how my team at Second Spectrum went from the first group that was using Elm in production to how we spread excitement for Elm to other groups within our organization. Through the talk, I will share lessons learned in terms of the challenges involved in onboarding those new to Elm (and functional programming) and the benefits we saw on our team after we started using Elm, as well as suggestions for those looking to use Elm in their organizations. Finally, I’ll explain how, once we had lots of folks within our company using Elm, we leveraged that energy to start Elm LA, a local meetup that we started last year in Los Angeles, CA. The audience will come away from the talk with actionable strategies on how to get buy-in within their organizations to start using Elm.

One of the selling points of Elm is that you cannot get null errors. Maybe is what allows Elm to avoid this billion-dollar problem entirely. It’s a beautiful solution.

But it doesn’t take too long before your code is one long ugly nested case statement checking Maybes at every level. Surely this can’t be right. There must be a better way.

We have an array of tools at our disposal to solve this problem, from simple convenience functions all the way to eliminating Maybe altogether in favor of other constructs. Join me on a whirlwind tour of these solutions and take back control of your codebase.

Some things can’t be done with Elm. It’s a young language with so much potential to be realized in the years ahead. If a program you are writing today falls outside of Elm’s capabilities, like writing a server, it can better to choose a different language. When it comes to fancy UI features, though, you might be able to have your cake and eat it too. In this talk you will learn about when and how to use web components in your Elm views. The most common inquiry we’ll cover is interop with fancy JS UI packages that are not economically viable to replicate in Elm, like rich text editors. We’ll also talk about components that make visual changes outside of the Elm update cycle for performance-critical UI behaviors, and more. The examples covered in this talk are based on production experience, fully compatible with Elm and all WHATWG specs, and can be polyfilled at least as far back as IE 11 and Safari 9.

There are a lot of hidden and forgotten gems in Smalltalk. One of them is the System Browser: the main way to develop Smalltalk, and a way to explore and evolve the environment. elm-browser explores the usability of such tool in the Elm ecosystem, hopefully allowing for a faster and more to-the-point development cycle.

Elm’s basis in immutability presents a unique set of challenges to animators.

In a language that allows mutation we can get away with hiding all our details behind local state, but in Elm we have to capture every detail in our model. This means many of the APIs we may be familiar with in languages like Javascript don’t translate directly over to Elm in the nicest way. Or they do translate, but require a lot of manual wiring and record keeping.

However immutability is an incredible advantage and there’s no reason that advantage doesn’t translate into the realm of animation. The main challenge is adjusting our thinking around animation in Elm. So, what does an immutable animator’s toolkit look like?

By slightly shifting our thinking and embracing Elm’s design decisions we can arrive at a unique set of tools and techniques that provides high level control over our animations and feels unique to the Elm language.

Github is a vast collection of code which could give us insights into how people are using Elm. The problem is that all the code is represented as text which limits our ability to analyze it automatically. In this talk, you will learn how we can leverage Elms statically typed nature to parse all public elm code on Github into a structured form which allows us to ask interesting questions like:

• Give me examples how to use a specific library function?
• How many people would be affected by changing some library functionality?
• Is this library still used in recent code?