Mobile and Web Working Together
Mobile and web apps are both client-facing technologies, but when I tried to research what they have in common, I noticed that they are often presented as rivals:
This notion became even more intense with the recent introduction of frameworks allowing web developers to build applications with a native appearance, using web-based technologies like React Native or NativeScript.
But instead of rivalry, maybe developers on both sides can learn from each other and work for the greater good of users!
I can’t recall spending much time collaborating since starting mobile development 10 years ago. Sure, we had meetings, we aligned features for the next releases and so on, but we almost never consulted with each other regarding technology: they had their world, we had our own. There was little interest in each other’s way of working and we tended to see each other only through the eyes of stereotypes:
Mobile in the eyes of web developers was all about archaic languages combined with frameworks coming from the late 2000s.
Mobile devs thought of web products as small, static websites written in dynamic languages that aren’t maintainable in large-scale applications.
Knowing each other
You might have read this entertaining blog post about web development in 2016.
It brought a smirk to faces of web developers and had their heads nodding in agreement, but for me as a mobile developer, my mind filled with concern.
Recently, I was lucky enough to get an opportunity on a project in React Native and then continue with React.js. I thought it was about time to actually learn what’s over the other side of the hedge.
It’s a bit daunting to be a junior developer again, but also a breath of fresh air.
Here’s how my learning process looked:
What differs between our platforms
Framework or Library
One of the most striking things that I encountered was the amazing number of dependencies used when developing for web. This is because people like the flexibility; you can implement everything in multiple ways and many libraries both complete and complement each other.
For example, routing — navigation from one URL to another. Using React and Redux, there are various libraries that you can pick from to implement this feature.
In mobile you don’t have a choice: you have to use what the system framework and its API give you.
In mobile we use libraries too: JSON parsing, database, asynchronous actions etc, but in the end, we are bound to those massive device frameworks: Android or iOS.
Language
When we talk about web languages we think of JavaScript, which is a dynamically typed language.
For mobile, we think of Java/Objective-C or Kotlin/Swift. These are statically typed languages, and mobile developers like it that way!
JavaScript looks really chaotic to us — multiple null types, object comparison. This video sums up our fears quite neatly!
Mobile developers want support from the compiler to tell them when they are doing something stupid. Of course, sometimes the compiler might be overly restrictive and not allow us to do something that we know is right, but we are willing to make this sacrifice.
That’s why some web devs prefer dynamic typing; they want to prototype quickly, and that’s faster without those annoying squiggles under your code.
Project size
A big market for a web development is the creation of landing pages, profiles, blogs etc.
These are not typically big projects, so it’s not uncommon to have a project that lasts only a month.
Mobile projects, on the other hand, usually take longer. I have not yet seen a client requesting a mobile application that has only one screen, but this used to be common with web projects.
What Mobile can learn from Web
How the Stack works
In last few years, developers with the title “Full Stack” started to pop up. There are reasons for this:
- Web developers often work on single-person projects, so they don’t have DevOps support to help set up their hosting servers and the infrastructure — they need to do it themselves
- Node.js became popular because it’s really performant in handling large user volumes and, of course, because you can write in JavaScript. For web developers who’ve been doing JavaScript for years, the language was no longer an issue when starting backend development
Web developers hate to be blocked. Their pace of work is usually quick. I’ve worked with great Web developers who had no problems quickly setting up CI, hosting websites, configuring CDN, or setting up databases or reverse proxies.
They have a much better overview how the Internet works in comparison with mobile developers.
Rapid Prototyping
Software development is expensive. Before we commit to the creation of a service we would like to validate the idea.
For mobile, creating the UI is slow. On Android you need to change your layout XML file, push the app to a device and see that you were few pixels off and then repeat the process ad nauseam until you are done. This is getting better with Instant Run or recent versions of the Layout Editor tool, but it still doesn’t work perfectly.
In web, the time between saving the layout and seeing it on screen is usually less than a few seconds. If even this is too slow for you, you can change the UI in Chrome Dev Tools and see the difference instantly.
Pushing the new changes to the users is also less painful without needing to go via the stores
You might say that web can’t do all the things that mobile can,but you might be surprised what web can do today.
What Web can Learn from Mobile
Static typing
FlowType and TypeScript add compile time types on top of plain old JavaScript.
They are becoming more popular in the web dev world, and the web developers that I’ve worked have with really enjoyed it. With dynamic typing you need to always remember or check what a function accepts or returns. Static typing takes away some of that burden.
However, I’ve found that for some people who have worked primarily with JavaScript, getting used to this might take some time. In my case, despite having significantly less JavaScript experience than my web dev project colleagues, I found that I was the go-to person when they had TypeScript questions.
For me working with types comes naturally, but for people who worked with JavaScript, getting used to it might take some time.
Reactive Programming
Android application architectures are made from top to bottom with RxJava. There are entire-application templates (like Reark) that teach developers how to reason about Reactive code.
Web is using RxJS more and more nowadays but not yet to the extent of mobile applications. I believe that we can work together to make it even more widespread.
Memory and Performance
When I asked a web developer how they track memory leaks, the response was that they don’t, because they so rarely occur. Even if they do, the user can press refresh and the problem will go away.
This is changing — web pages now are becoming web applications, and complexity therefore increases.
Considering memory and performance characteristics will become an increasingly important part of developing these applications.
In mobile, we’ve been tackling those issues for years and we’ve gotten pretty good at solving them. With the limited resources we used to have on mobiles, we had to learn how to properly manage them.
Should you get to know web?
If you can find the time, definitely!
The hardest part is the overwhelming choice of technologies.
If you come from mobile you are probably comfortable with working with opinionated frameworks that have usually only one way of doing things.
My personal recommendation is to try out Angular, because:
- It’s shipped with TypeScript by default
- It extensively uses RxJS out of the box
- It has built in support for Dependency Injection
- It has an advanced Command Line Interface (CLI) tool to set up projects
- It’s created and supported by Google
- It resembles native application development so mobile developers will have an easier time learning
I would also recommend checking out the Academind YouTube channel. They have a really nice introduction to web frameworks and libraries.
Web and Mobile do amazing things. It is a pity that we do not share our experience. Let’s learn from each other!