by Birowsky
Web is ready for you, Elm
Tears of joy from a developer who got to build a PWA
Growing up, being movie director was what my werewolf teeth were made for. Who knew that this front-end thing was gonna consume me like this. But it’s all good because creating art that actually helps people might be the one job to rule them all.
I’ve been enjoying it since the days when Flash was one of two ways to have rounded corners on screen. I was the happiest when I was able to demonstrate that the web can be a source of delight.
And since then it’s only been getting better.
Nowadays however, I’ve observed how companies still prioritize native app development. I need to show how the web, too, is ready for the amazing mobile experiences.
In my own circles, I am known as the guy who invests irrational effort in animations and performance. To me, the prettiest thing in the world is nothing without well crafted transitions narrative that helps guide the visual experience.
Recently I got handed an opportunity that was dear to my heart. It would allow my users feel when using it, the way I felt when creating it.
Meet Dscova.com — the platform that lets us openly share and brag about our experiences worth enjoying.
It grows, it shrinks, it dances, it slides, it gets excited when you touch it. And should you choose to add it to your home screen, it’s gonna follow you forever. It’s your overly attached web app that you are not ashamed to introduce to friends.
One thing that is clear is that it doesn’t blindly follow any design guideline. It has it’s own unique tone. We have mi hombre Diego to thank for that. I love working with designers who bring their own perspective.
Dscova should be the definition of everything I was convinced was possible on the mobile web. It’s my favorite baby thus far. Wish I could call it George.
Do you notice? I too am not following the almost strict guidelines of delivering app shell. Instead, I’m embedding a splash with the initial response from the server. This is how I’m able to let the users know that they’re in the right spot, in a quick, yet smooth way.
OF COURSE I understand that many of the big guys take the app shell approach.
I am convinced that the slowly fading splash prepares the user in a better way for the well known app behavior that always comes after a splash.
Demoing Dscova around, I’ve had casual users forgetting they were on the web. Not surprising, since they care for the experience, not the platform.
So I’d like you to drop everything and come join the wave. Especially if you turn out to be one of the artists that have ever delighted me on my phone.
I’m aware that you might be reluctant to make this transition today. As big and undisputed you think the current app stores are, imagine how sooner or later, the web itself is gonna turn into an app store, without the store part. No landing pages. Just apps that integrate with the OS and with each-other.
If you consider today’s users as lazy and aware of their time, hold your breath for the unexpected complaint:
“I had already opened their app, but then they wanted me to go to some app store and install something else. They said it’s their app. I’m confused.”
Today’s users generally know web when they see it. I have the greatest laughs with them. To understand what I mean, and appreciate the PWA (Progressive Web App) installation process, show it to a non-techy user, and wait for the cutest “um.. [conspicuously looks at you] was that it??” reaction.
We have Google to thank for the efforts they made for us and our users in this regard. Still, the one thing that’s always going to matter more is what’s inside.
Delightful is possible. 60 fps is possible. All the Olympic gymnastics that these views do, as well as being fun, aim to help the user understand what is happening. Where everything went, and where everything came from. But as lovely as they are, they weigh on our heads with their need for complex state management. Look at this beauty:
This is my favorite piece of interaction. It couldn’t be any more seamless for the user. Yet behind the scenes, seemingly unrelated contexts are doing some elegant communication to accomplish this goal. While untrue for OO (Object Oriented) systems, here any view element has access to any piece of app state without ANY consequence. I’ll wait here till it sinks in.
We don’t need to call for an external state, and we don’t need to wait for it. It’s because of the nature of the system. It’s because of how the whole app state is a single bag of data that is available everywhere. And because the state is immutable, only contexts with explicit requirements to update their contextual sub-bags of data are able to do so. What a sentence.
In this example, the developer designs the map state and implements the pan based on location state updating. The jolly fun happens when in the context of experience creating wizard, all the next developer needs to do is:
I mean, I could’ve used words to explain this, but look at it. That’s English.
Notice how currMapCenter is there for the taking. It requires no special strategy of how to React™ when there are new map center coordinates. They are just.. there.
Not only does it make solving this use-case a joke, but the data guarantees that come prepackaged with the immutability allow us to not worry about manipulating the map state outside of it’s context. And what do we call development without worries?
Thats joy, my invisible-bug-squashing friends.
Joy!
I haven’t mentioned that we use Elm yet, have I? Sorry bout that. Well, I run this small team that somehow, after Elm, became a lot bigger, even tho the number of people remained. We can’t pass the free plan on Sentry. We don’t have any testing work left for our family members either. And we ship features like алва[1]. So pardon me when I assume that EVERYONE is on the Elm train or getting there.
Look, I don’t know how much this matters to you, as no number measures user’s delight, but let’s see anyway:
Consider how this app, with it’s 37K lines of Elm, and it’s 280KB gzipped size, 40% of which are libraries, generally has a first load in 4 seconds. I have no idea when the hell would I ever need to even think about splitting and loading modules lazily. Something that is imperative with the other platforms.
Dark story time: last year we were working on an Angular 2 project. Started with the early betas. When we completed it, NG was stable, but it took the app 20 seconds to start. It was because it needed to compile the views on the device on every start. First, it took us time to realize that. Then, we had to wait for the ahead of time compiler to get released before we released the app. As I said, a dark story. Go play it with friends. Start with: “A product launch got delayed”. [2]
I believe you can feel my relief when in the first run of this test we got
100, 98, 98. We then enabled long-term caching and.. well you see the hundreds.
I am keeping distance from implementation details throughout this article because in the end, this is what matters. This feeling that I have.. it’s.. let me try it this way: have you been noticing how popular it is for a front-end guy to feel stressed out? How much effort needs to be invested to be on top of the game? Has there ever been a bigger tools and techniques explosion compared to what’s happening now on the front-end? As self-abusive as it sounds, If I didn’t actually love this craze, I wouldn’t have discovered functional reactive programming. I wouldn’t have discovered Elm. [3]
I finally live in a world where technicalities are irrelevant. For any challenge there is an obvious approach to solving it. I’m just focused on what I love the most: fading and blurring and moving things around.
Not only do I not suffer the impostor syndrome anymore, but I feel something that rests comfortably on the opposite side on that spectrum. Ever since the days I started following Elm, every time I see a massive new feature roll-out in any of the popular frameworks or tools, I usually think: “Oh look, another idea taken from Elm.”, either Redux or immutability or stateless view components. Or even better, I realize that it’s a solution to a problem that is nonexistent in Elm Town.
I want you to realize the advantage Elm gives you. They can go nutz in trying to improve JS. But they’ll never be able to fix it unless they change it. And you know that I know that you know that they cannot do that. So instead of endlessly learning how to build stuff, you’ll start building stuff, endlessly. Pulitzer please!
Elm is totally new and different. It couldn’t be this good any other way. The hardest thing you’ll have to do is unlearn all the OO patterns you use to handle problems that are (together!) nonexistent in Elm. Seriously.
Have you started using underscore to transform data? Have you been moving away from classes and use modules as encapsulation contexts? These are great first steps that would ease you in into the productivity boost in Elm’s pure functional world.
But, if you are already using React or Angular in a functional reactive way, you’ll find that Elm is where everybody got their ideas from and how they look like in their purest form. You alone will be able to replace 20 of the you before you became Elm.
Here’s the hard question: Who’s gonna help you once you get stuck? I know this is what you are afraid of. It’s a small community, so the support is questionable. How do I put this.. you will nowhere find more dedicated and more capable group of people in one room. I don’t know how they breathe in there! Everyone trying to beat everyone else for who gets to help the newcomer first!
He fights about everything with everybody.But when you ask something on Slack, chances are, he’ll be there to help you.
And then get this, there is a weekly thing called “No dumb questions” on Reddit. What? They didn’t use that name?? Oh well..
So what was I saying.. oh yes, delight users with PWA, enjoy doing so with Elm. And if you absolutely need to be present on the app stores, for extra 5% effort, Cordova will take you there. We spent the extra time because one of the core features of Dscova is notifying users as they move around when something awesome is nearby. And since background geolocation is still not conceptualized for the Web, we did it in the hybrid versions. That, and the fact that Apple doesn’t love Safari the way Google loves Chrome.
Let’s start wrapping up. This is too much not writing Elm for me.
Resources: When we were following beginner material, these were the greatest ones:
- Book: Elm in Action by Richard Feldman (a great great guy. just. great.)
- Video course: Elm for Beginners by James Moore
- Video course: Building Web Apps with Elm by The Pragmatic Studio
- Go make some noise on Slack
- Listen to our spiritual leader on Elm Town
- I wanna put a special note here for the folks who like me, when I was starting, want to begin on a production app right away. Go learn Webpack. We were used to Gulp chains, but now our build process is nice and tight thanks to the great tools that exist for Webpack.
Hold the applause fellas, special props are coming:
The kind of guy that holds your hand and helps you cross the road.
The only guy who could ever outwork me.
And because of it, he now has to fight every other smart person who knows which direction Elm should take.
[1] Something that my country used to ship a lot.
[2] Angular is solid today. The AOT compiler can easily be plugged in your Webpack config, or even simpler, you might just wanna use their CLI.
[3] Elm is actually not a reactive platform anymore. It became something way more intuitive than that.