The “appification” of the Web is in full swing, and it’s going to solve a lot of headaches for teams that are trying to provide valuable digital services to people who use a wide range of devices. There’s a huge amount of energy behind Progressive Mobile Web Apps, and I think that shows great promise for the Web (the most ubiquitous software run-time on the planet).
But it’s important to note that PWAs must satisfy 3 main criteria: they must be reliable (a.k.a. work offline), they must be fast (by responding quickly to user interactions), and they must be engaging (they need to feel like a real app).
So how do you make your Web App feel fast? How do you make the interactions slick and snappy so that it feels more like software rather than a website?
The Single Page Application
A Single Page Application is basically a website that only has *one* HTML page, even though it may have many different views. In contrast, a regular website is a collection of many different HTML pages.
A regular website feels different from a SPA because users “pogo-stick” from page to page as they interact with the website. You see an intermittent blank page after you click a link and navigate around.
In a SPA, there is no pogo-sticking. That’s because the entire shell of the application is downloaded to the browser when a user first goes to a URL. The application shell can then be cached so that on further requests there is no need to re-download any assets. It’s similar to downloading and installing a mobile application from the App Store for the first time.
To reiterate, on the first request for a SPA, you “install” the app. This is the only time the application shell and all relevant assets are sent down the pipes. All subsequent requests made to a server or third party are for setting or retrieving data only. Subsequent requests don’t wrap the data in an HTML response, they respond with data in JSON format. This makes the app feel fast and it removes the pogo sticking effect that comes with plain websites.
Create Your SPA By Thinking & Developing In Components
One of my favorite software development approaches has been this concept of “thinking and developing in components”. I can’t stress enough how this approach has improved development for me.
Before this approach, there was no consistent way of modularizing sections of a Web application. There were various patterns for making sections of UI more modular (think the Module Pattern). But we were essentially organizing code in separate “scripts” and organizing the front-end in terms of pages, not components. This made reusability significantly more challenging.
Then ES6 came along and gave us real modules that developers using other languages took for granted. Now, you could import and export modules using basic “import” and “export” keywords. As a result, our front-ends were truly becoming more modular.
Eventually, we got access to powerful libraries like React that gave us a standard approach to encapsulating sections of our UI, simultaneously abstracting access to the DOM, and development got even easier.
One of the biggest benefits of developing in components is reusability and it’s going to make the management of your application way more enjoyable once you get the hang of it.
Other Benefits To Thinking & Developing In Components
There’s another benefit to this component-based development approach. When it makes sense, you can package your component and publish it on NPM. If you know you’ll be sharing a component with a number of other apps, this can be a real boon to productivity. This is also a great way of sharing your work so that others may benefit and save time (it’s also a great way of enhancing your portfolio).
For example, I’m in the process of writing a collection of applications that make use of a user’s voice (via the MediaStream Recording API only available on Chrome and Firefox). One of the main UI elements is a component that records a user’s voice while synchronizing it with a visual sine wave. This gives a nice indication to the user that something is being recorded.
Because I’ll be using this component in other applications, and because others may benefit from it, I packaged this component on NPM. It’s called React-Mic and you can use it and style it for your own creative purposes.
(If you want to learn how to create and share UI components, check out my tutorial “Create a React.js Auto-complete Search Bow With Material-UI In< 100 Lines Of Code — Part I”.)
How To Get Started Developing Your SPA
There are several other factors that go into developing a professional SPA. You need to know how to architect and manage the CSS, how to create a production version of your SPA, how to make use of key libraries (like React, Redux, and React-Router 4), how to make it work offline through the Service Worker cache, how to make use of various browser-based storage mechanisms, deployment, and a lot more.
There’s no need to worry about all that just yet. All you need is a preconfigured blank slate and a knowledgable guide to get you bootstrapped correctly.
You don’t even have to worry about the initial design of your SPA if you’re willing to use a pre-made collection of components using the awesome Material-UI library.
How To Develop Professional React Apps
Hey, I work as a Senior Front End Engineer in the industry, and I develop software applications for a lot of successful startups and well known companies using React.
UI Engineering skills are in demand, but you need to have the right skills. And you need the right foundation to set up your code for success.
That’s why I’m teaching developers how to develop professional React Apps in my course “How To Develop A Professional React App”. It’s a step-by-step video course that shows you how to design and architect a professional React app for clients, your employer, or for yourself using an advanced foundational UI boilerplate that has everything you need.
With strong skills comes more choice and greater freedom.