Timeline

.

Brief overview of the available technologies for visualizing data. We’ll dive deep into elm-visualization and show how we can use its features to create rich and interactive data visualization apps.

There are many products today that need drag and drop. Variants of drag and drop include: dragging and dropping between buckets, reordering in 1D, and reordering in 2D. We’ll focus on reordering along one axis.

Questions with reordering include:

Does the user need a styled preview of the drop zone? Should the dropping action animate the placeholder into its drop destination? Do the reorderable items resize dynamically? Does the placeholder resize while dragging? Can the reorderable axis change between x and y while dragging?

Can we account for all or most of the above with a clean API?

I will answer the above questions with small examples, build audience knowledge, and then demo a very complex reorderable feature!

Graphics programming is hard. That’s definitely the case when you try to use WebGL in plain JavaScript. Elm can make graphics programming on the web easy and robust in the same way as it made building UI’s easy.

The WebGL library got a new home in the Elm Community organization. Version 2.0 came with lots of new features and improvements to the API. It’s now much more friendly for newcomers.

I’ll show you cool graphics demos as well as explain some of the basics. My hope is that you leave feeling inspired to start some of your own WebGL projects using our new library.

What could the future of styling look like with elm?

Writing CSS is still one of the biggest challenges for front end development. CSS can be written that’s valid, but produces unexpected and hard-to-debug results.

But it doesn’t have to be that way.

We can take all the mental discipline that good, organized, well behaved CSS requires and make the compiler responsible for it, instead!

By describing our styles in elm, we can be nuanced about what CSS we allow to be written. Surprisingly, completely disallowing some CSS properties can make our styles much more predictable with no practical loss in functionality.

We can use elm to limit access to the brittle parts of CSS, and make it easier to write the best parts (like flex-box, animations, and media queries). We can make best-practices the compiler’s job.

Let’s make style and layout as refactorable, productive, and typesafe as elm itself.

We all already know that Elm is a great language for building reliable web apps, but it turns out it’s also great for prototyping Domain Specific Languages. Recently I’ve combined two of my hobbies by using Elm to begin creating a reusable data format for cooking recipes.

All recipes can be broken down into a number of raw ingredients which, when combined with various techniques, form a dish. In this talk I will explain why Elm’s straightforward yet robust type system is a perfect use case for modeling out these recipes. Thanks to Elm’s knack for taking a data model and translating it into HTML, it’s easy to generate a human-readable version of any one recipe.

But wait, there’s more! Elm’s decoder system makes it super easy to translate Elm models to and from JSON, allowing us to import and export them.

Finally, I’ll show a few examples leveraging this framework to generate both pretty, human-readable recipes and interesting visualizations of them!

I began using Elm in the spring of 2016 and pushed my first commit to Elm-plot in June. Being new to functional programming, I was fighting the old habits of my component-based mindset, which over time resulted in several complete rewrites of the library and many aha!-moments. In this talk, I will tell the story of Elm-plot, including the issues resolved, the compromises made and the challenges yet to be overcome.

About a year ago, I used Elm to make a simple multiplayer word game called Lettero. It worked alright, but more importantly, it left me wondering: is Elm awesome enough to allow me to abstract the game into a framework so we can churn out other multiplayer games in a matter of hours?

In this talk, I’ll present the way the original game was refactored to split out its wordgame-specific parts from its core framework, discovering ever more flexibility within Elm’s typed functional rigor. I will also walk through the way game state is reconciled by one of the clients designated as host, allowing the app to run on generic realtime backends such as Google Firebase, without any custom server-side code.

In this talk i will talk about Year and a half building a software with 80% Elm based code and a team commited to ELm. From the experimentation to the production going through Elm communities and recruitement, i will share experience about how we ended with a almost full Elm stack from client to server and compares to the rise of scala and play i was involved in.

In this talk, we’ll discuss how we manage to unblock ourselves whenever we encounter an edge in Elm at NoRedInk. I’ll discuss many of the experiments that I have done, and how best to go about being a productive member of a Elm workforce to enable others to use it. I’ll also explain how our custom testing tooling works, and how you can do it too. I’ll also briefly go over some potential problems you might face, and how to avoid them.

The State of Elm 2017 Survey is over and the results have been collected. Let’s look at them together! Where are new people in the community coming from? Where are they going? What’s great about Elm, and what could use improvement? In this talk, we’ll discuss these questions and what they mean for the Elm community at large.

Four months ago at ElmConf2016, I debuted my interactive story-telling framework, the Elm Narrative Engine. I spoke of the challenges of building a framework, and how it took full control away from the client code after being initialized.

Since then, after using the framework more, getting feedback from both developers and story writers, and an api-design session with Evan, I have completely inverted the framework, allowing for some really cool things.

The framework still works like a “run-time,” but now it is embedded in a “component” inside of the client’s app, and control flows between the two every update cycle. A framework as a component? Yes, it works, and surprisingly, it is much more versatile and makes for great separation of concerns.

This talk will look at the conceptual differences and implications, touch on some of the big-ticket technical refactors necessary to make the switch, and explore some fun and interesting demos that would not have been possible before.

Choosing the right technologies when starting a project is super important. It’s almost impossible to change the stack later on. Betting on Elm is therefore a bit risky. Right?

Not anymore! Now we can use frontend microservices to pick the right tool for every job!

Traditionally, single page apps are monoliths. Here’s a React app, that’s an Angular app and this one is in Vue.js. This way, early stack choices turn into a strong tie-in as the project grows. It’s pretty tricky to introduce Elm to a mature project running on a different technology.

In this talk, we’ll see how web components change the game. Finally, we can use the right tool for every job! We can introduce Elm bit by bit to any JavaScript app – or neatly embed JavaScript UI nuggets in an Elm app.

We’ll learn from the ups and downs of regular microservices, catch a glimpse of the culture that this approach has brought about at Kalo and leave with a strong toolset to make things happen.

Manipulating Dates can quickly become a problem, even for simple things like getting the current Date, obtaining the start of the week (especially with different date systems). How can we manage these problems with Elm, keeping our sanity in check.

This talk will try to give an overview of the standard pitfall that can occurs when dealing with dates and how to overcome them with the Elm ecosystem.

In Elm world we have both unit tests and fuzz (property based) tests - this is great! But both of these often focus mainly on the small helper functions that create your app (and single Msgs at best). But there’s a whole lot of untested long-term scenarios the user could get into using multiple Msgs.

In this talk I’ll tackle this idea: testing your app more thoroughly using sequences of Msgs and finding unexpected “loopholes” in your system, using techniques first envisioned by Quviq’s QuickCheck.

On Elm’s website Prezi is featured for using Elm. However, as of December 2016, Prezi presentations are still based on Flash. So in this talk I introduce Dive, a programming framework written in Elm for building visual and animated presentations like Prezi’s. After explaining the API, I describe the internals of the framework and compare two rendering approaches, Canvas vs. SVG. Along the way, I also demonstrate why it was easy to create Dive with Elm, since the core of the framework took me just a couple of hours. And of course, the presentation slides of this talk are built with Dive itself.

Most applications, in any language, requires the use of collections. Elm has several collection types built-in: Lists, Arrays, Sets and Dicts. When is it better to use a List instead of an Array, and when do you use Sets? In this talk, Robin explains how the different collections are implemented under the hood, with the hope that this knowledge will make it painfully obvious when to use the different collection types.

This talk is about music but is not restricted to musicians!

When playing an instrument in a jam session, musicians sometimes need to see the chords of the tune they are playing. A chords chart is a convenient way to represent a music tune as a table, containing chord names in “Jazz notation”, but not music notes. Chords charts are scattered on forums, are static images most of the time, and there are many versions of which some are wrong.

These drawbacks led me to start the Open Chords Charts project. The backend is a centralized and collaborative database of chords charts. The frontend, written in Elm, allows to browse charts, add/edit them, fork other users charts, fix errors and make links between charts. I’ll show some features such as changing the key in which the song is displayed – a killer feature for musicians who dislike to do the transformation in their head. The frontend is responsive and offline-first, so that musicians can build a set-list and follow the songs on their

In Gizra, we run an unusual stack that helps us reach blazing fast websites - Drupal runs our backends, Elm in the front, and most recently Yesod (a Haskell framework).

There’s a certain mindset in choosing these technologies - it’s about the idea of “correctness”; making sure we can move quickly without breaking stuff.

In this session, I’ll explain in depth about this mindset both from the development perspective, and the business one.

thoughtbot has launched the first ever production Elm Native UI app! In this talk, I’ll discuss my journey building the app and contributing back to Elm Native UI, the benefits of using Elm Native UI over other technologies, and the existing hurdles. I’ll also compare using the library to Swift/Cocoa Touch and React Native. Hopefully, the talk will inspire others to start playing with Elm on mobile.

Presentations are one-sided by design. Someone talks, people listen, a lucky confident few might pipe up to ask questions at the end. Speakers struggle to read the audience without disrupting to ask questions, and the audience has no way to give feedback without disrupting the speaker.

Presentations are slow, single-threaded and syncronous affairs!

What if we could improve these problems with Elm?

This talk will involve the audience in a live experiment in having realtime engagement using Elm. We’ll engage in dialogue concurrently, we’ll have instant relevant and screen-visible feedback.

Aside from a scene-setting introduction, the audience will democratically determine, in realtime, both the order and selection of talking points, allowing the presentation to mould itself to be the most relevant it can be for this particular audience and point in time.

We’ll use Elm, to talk about using Elm, to talk about Elm. It will be Elm all the way down!