Web is ready for you on line Elm
Joys of tear by a developer who got to build a PWA
Growing up, being movie director was what my werewolf teeth were made of. Who knew that this frontend thing was gonna consume me like this. But it’s all good because creating art that actually helps people practically, 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, above all, can be a source of delight.
And it’s only been getting better, ever-since.
Nowadays however, observing how companies still prioritize native app development, I feel responsible to show how the web, too, is ready for amazing mobile experiences.
In my own circles, I am known as the guy who invests irrational effort in animations and performance. The prettiest thing in the world, to me 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, that would allow me to make users feel using the thing, the way I feel creating it.
Greet Dscova.com — the platform that lets us openly share and brag about 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 apparent 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 user know that she’s 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. But if you are like me, you are almost pissed off too when you’re faced with a useless/broken UI for seconds at a time.
I am super convinced that the slowly fading splash prepares the user in a way nicer manner 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. Unsurprisingly, 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, just imagine how sooner than 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 today’s users are considered lazy and aware of their time, hold your breath for the unsuspected 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, to fully appreciate the PWA installation process, just go 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.
Well inside, we have this thing, and this thing, and this over here:
Delightful, is possible. 60fps, is possible. All the olympic gymnastics that these views do, aside from 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 whey on our heads with their need for complex state management. Look at this beauty:
My favorite piece of interaction. Couldn’t be any more seamless for the user. Yet, behind the scenes, a seemingly unrelated contexts need to do some elegant communication to accomplish this goal. While true for OO 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 the example, the first developer designs the map state and implements the pan based 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 just look at it. That’s english.
currMapCenter is just 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 usecase 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.
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 possibly pass the free plan on Sentry, we don’t have any testing work left for our family members either, and we ship features like алва. So pardon me when I just assume that EVERYONE is on the Elm train or getting there.
Look, I don’t know how much this matters to you, but I’ll show you anyway:
Just a little something that comes as a bonus with Elm builds.
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. So 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”. 
I believe you can feel my relief when in the first run of this test we got
100, 98, 98.
We then just enabled long-term caching and.. well you see the hundreds.
I am deliberately keeping distance from implementation details throughout this article because in the end, this right here 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 frontend guy to feel stressed out? How much effort needs to be invested in order 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 frontend? 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. 
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.
That thing that is well known as impostor syndrome, not only do I not have it 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 rollout in any of the popular frameworks or tools, I usually think: Oh look, another idea taken from Elm (Redux, immutability, 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. On the other hand, if you are already using React or Angular in functional reactive way, all you’ll find in 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 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, therefore 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!
This guy ^ I don’t understand this guy. Constantly 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 thanx to the great tools that exist for Webpack.
Hold the applause fellas, special props are coming:
The Somebody from the Elm community that I really hope you find for yourself. The kind of guy that holds your hand and helps you cross the road.
The associate you can dream of. The only guy who could ever outwork me.
Some dude that is too smart for his own good. And because of it, now has to fight every other smart person who knows which direction Elm should take.
— — — — —
 Something that my country used to ship a lot.
 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.
 Elm is actually not a reactive platform anymore. It became something way more intuitive than that.