PWA

History of Mobile Web Development and the rise of PWA

Published Feb 28, 2020

Updated Feb 14, 2023

10 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

If you're in your thirties, like me, or older, you know that mobile phones have not always been so ubiquitous.

In this article, we are going to cover the history of the mobile phone, and more specifically "Web Development", by focusing on the rise and benefits of PWAs.

The article is going to be divided in the following sections:

History of the Mobile Phone
The evolution of Mobile Web Development
The Rise of PWA (Progressive Web App)

History of the Smart Phone

It is hard to remember a time when we all lived without smart phones in our pockets. How about when mobile phones could not be called "smart" since they had a single purpose: to make calls?

Let's travel in time, and cover the main milestones that shaped our beloved handsets.

March 1991

Even if it feels like ancient history, the story of mobile phones starts just shy of the millenium's turn. Phones started to become everyday accessories in the last decade of the 20th Century, with the first ever phone call on GSM network being made on March 1991.

1996

During their first few years of existence, phones rapidly advanced. In 1996, Nokia released the first phone with access to the "mobile web".

1998

1998 did not have any specific technological breakthroughs, but in my opinion, it marks the creation of a new industry: premium downloadable content.

You may be curiuous to know which app was the first to be downloaded, but here, we are not talking about any app, as the phones did not even have web browsers yet. The first content to be sold were ringtones.

This is one of the most succesful (and annoying) ringtone of the early 2000s "crazy frog":

{% youtube awAKzaGrrbY %}

1999

Right before the end of the decade, phones reached another very important milesone. In this year, the first version of a mobile specific web browser was created, and our handsets were connected to the World Wide Web.

2000-2007

If I would have to list all the great phones and enhancements of these few years, this blogpost would become a book.

Phones started to get much smarter. There were multiple improvements, from the size of the devices, to the signal coverage, all the way up to improved services, such as colored screens and cameras.

All of the above made consumers interested in the products, and more and more people started to use them. Making it a very profitable market to invest in.

2007

The fast growth of this market made Apple decide to move into this growing sector. In the year 2007 Steve Jobs release the company's first mobile device: the Iphone.

The Iphone was the first mobile interface to be completely touch-based. This was a big evolution, not only in terms of user experience, but also on the web development side.

2007+

Following the Iphone, all major companies of the time, such as Blackberry, and Nokia, started to emulate the success of Apple, and consumers were inundated with different devices every year.

By the end of this decade, Mobile Phones were common devices for adults and teenagers, and have since developed and improved to what we have today.

The evolution of Mobile Web Development

Now that we have covered the actual evolution of our beloved handsets in terms of hardware, it is time to go back in time again to analyze the evolution of "mobile web development".

As shown from the above section, the "web" made its first apprearance on Mobile phones in 1999.

WML - 1999

I never had a chance to develop a mobile site in the late 90s. If I had, I would have had to use WML (Wireless Markup Language). This language (now obsolete), started to provide powerful features (link, forms, image, etc..), and was based on XML.

Mobile development was specific, as this language was specific to devices that implemented the WAP (Wireless Application Protocol). The use of these sites on desktop was limited, or required the use of browser extensions.

cHTML / iHTML - 1999

The browser capabilities on mobile phones developed quite quickly. Devices started to have access to subsets of HTML (cHTML and iHTML). This allowed developers to be able to create one asset (HTML) and serve a multitude of users, both on mobile and desktop.

M.dot

Mobile phone resolution was quite low, and phones in this period did not have touchscreens, making it difficult to surf the wed.

To help in this matter, the industry respondend by utilizing what was called M.Dot methodology. This allowed a website to have two different entities, on two separate Urls. For example, if your site was myShop.com, when accessed from a mobile phone, you would have redirected users to m.myShop.com.

Having different websites, allowed the developer to "eliminate" surplus content, and create a design that was more suited for the hardware of the time. This "duplication" came, of course, with a big development cost price tag.

Native - 2008

The App store, and the Google Play store, were release in 2008. These events marked the beginning of a completely new industry.

Internet speed on phones was very slow, and the price of data usage was still quite high. This enabled many companies to specialize in Native App development. These apps provided a quick and smooth experience to users, but with a great cost factor in terms of development and specialization.

The distinct programming languages, and methodology needed to create Native Apps, was so wide across different devices, that many companies decided to specialize in a specific platform (Android, Apple or Windows).

Native applications had the possibility to "connect" with the device, in unique ways, by having access to a huge set of APIs (eg. Push notification, background sync, use device space, etc..)

Responsive Web design - 2008

But with the rise of Native App, another methodology started to gain traction: Responsive Web Design.

This approach allowed the same website to render well on a variety of devices. Using this approach made the use of M.Dot methodology obsolete, and helped many companies save thousands of dollars in Native development.

Unfortunately, "web apps" built this way would just be simple websites, and would require the user to access the internet, and specifically access the site URL.

Hybrid App development - 2010

Responsive web design never managed to fully respond to customer requests. This was most likely due to the look and feel of the app being somehow different from a Native app. As phones developed, the gap between Native and Web Based widened, as the latter was not able to use many of the in-built features.

In 2010, PhoneGap was revealed (currently known as Apache Cordova). This sofware enabled the development of applications using known web skills (html, css, javascript) to build Native Applications.

More software followed this trend, enabling companies to start in-house development of Native Apps, without the need to incur high costs.

PWA - NOW

The last decade has been a roller coaster, as companies were torn among the use of Native app, Hybrid solutions, and responsive designs.

In recent years, a new contender, or more precisely described as an upgrade of the Web App, entered the ring. This is known as the Progressive Web App (PWA).

The primary intent of PWAs is to reduce the gap between web development and Native apps, by enchancing the user experience.

In the next section, we are going to cover why the industry is responsing so positively to PWAs, and provide you useful insight to help you get up to speed with this methodology.

The Rise of PWA (Progressive Web App)

As you may have probably noticed from the way I speak about PWAs, I am personally really excited about this methodology, and in this section, we are going to explain the reason behind my interest in this technology.

Feels like "home"

First and foremost, the main advantage of PWAs is the ability for our websites/web application to be downloaded as real applications.

When a website is fully setup as a PWA, mobile users are prompted with a "install now" action. Doing this will allow specific content (manually set as part of the PWA setting) to be downloaded directly on the phone, by allowing extremely quick load times and more.

Furthermore, installing a PWA will also add it directly to the main mobile interface (homescreen), making it feel like a Native App.

Be connected

If you own a business, you are fully aware that connecting with the customer is essential. Therefore, if your customers are using your services online, being able to interact, and catch their attention, is vital.

One of the main benefits of Native and Hybrid apps, as previously mentioned, was the ability to access the multitude of APIs offered by our handset.

Thanks to PWAs, and more specifically to the use of a service worker, we will be able to make use of this powerful feature.

Two of the most important features available on Web applications are:

Sync notification: Ability to sync your data, even if the app is not running. This is essential to provide quick content to your user.
Push notification: Ability to provide an alert to the customer, even if the app is not running ( eg. New notification in a specific app, or a reminder to use the app)

It is true that the list of avaialble APIs is still small compared to that of Native implementation, but the community is working extremely hard to reduce this gap.

Write for Web, serve on mobile

When we previously covered RWD, we highlighted one ot its biggest advantages: being able to develop one single interface to serve a multitude of devices.

PWAs offer the same advantages, with the added feature of providing the ability to display fullscreen like a "real app".

This feature (part of the display setting of PWA) allows your app to take the full screen. This not only increases the space available to your app, but it also enhances the User Experience, by making sure the customer is not distracted by the "url" bar, by providing a "native look and feel".

Additionally, we should highlight that the front end industry has seen a big rise in the use of frameworks, such as Vue, React, and Angular.

The development of applications with "component based" architectures has supported the rise of theUI component library which is:

A cloud-based folder that consists of all the designed/styled parts of a website or piece of software. It helps designers to work in a consistent way and becomes very time efficient when executed correctly.

The use of these libraries (most available for free), have supported the development of nice looking applications across multiple devices, without the need to develop all individual elements from scratch.

Ready for shopping

In recent months, the Google Play Store has supported PWAs as shown by this article.

This service, though still in its early stages of implementation, provides a reassuring signal for the future of PWAs.

You may be thinking, what about the Apple Store? Unfortuantely, Apple has not disclosed any information about PWA adoptation, but recent signals, highlighted in this medium article, show Apple's support of PWA development.

At a fraction of the cost

Unfortuantely, when it comes to business, cost is usually the most important factor.

To further emphasise the above point, where we shared the introduction and use of "component based" architecture for speed, we also need to talk about development cost.

There are three main aspects of PWAs that help reduce cost:

Existing skills
Development speed
Re-usability

Existing skills

Apart from some tinkering, and the introduction of the service worker, PWAs are just simple websites. They would allow a multitude of in-house development teams to be able to carry out development and/or support mobile apps, reducing the need to pay third party companies.

Development speed

As already mentioned above, component based achitectures, and the multitude of available community based components, have provided frontend developers the ability to quickly build performant PWAs in record time.

Re-usability

Many companies fail to quantify the financial savings produced by being able to re-use existing features. In a recent project I was involved with, we were able to transition from a Native App (supported by a third party company), to a fully in-house build PWA in record time, all thanks to the reusability of their Vue domponents!

Versioning

I have read many different articles that introduced PWAw, but I have personally learned this last point though experience.

Until now, you would have never associated the word "versioning" with a website, but thanks to PWAs, this ability is also possible for web based applications.

The main reason behind the need for versioning is purely technical, but its existence within PWAs is surely favorable to the many "Native" developers wanting to swap.

Conclusion

The war for Mobile Application domination is still on, but I personally believe that PWAs will hold a big share of the market within the next few years.

Most of the advantages that support Native and Hybrid development, such as APIs, Native-look and feel, and the ability to publish within the big stores, are slowly being added to Web App.

Even if Native applications are not going anytime soon, as there are many use cases that require its full control of the handset API,I believe that in the next few years, PWAs will become the standard choice for most in the mobile industry.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Simone Cuomo
Software Architect, Mentor, Speaker and Writer. Passionate about all aspect of web development, with a special love for VueJs
@zelig880 @zelig880

Getting Started with Angular: A Mobile Developer’s Approach

At many points in your career, you will find yourself picking up a new framework, platform, language, or (most likely) some combination of all three. In my case, I recently found myself looking for a change of pace, and ended up switching from working in native iOS as a Mobile Engineer to the world of JavaScript as a Front-End Engineer. Specifically, I started out with Angular. No matter how you slice it, learning something brand new can feel daunting — regardless of whether it is mid-career or otherwise. Luckily, Angular is extremely simple and quick to get set up . . . but getting an environment and project set up really is only a small part of the path to learning a platform, isn’t it? As I challenged myself to attempt to learn Angular as quickly as possible, I aimed to first break apart the approach by understanding: * What Angular is * What Angular's goal is * What the fundamental pieces of Angular are So, before we jump straight into some code, let's grasp these concepts first. What *is* Angular? First of all, Angular is not AngularJS. This was slightly confusing for me at first, and I made the mistake of mixing them up initially. Oops. At a macro level, Angular is a modern JavaScript framework that’s built on TypeScript, giving it access to static types, classes, and other elements provided by ES6. This allows code to organize and structure properly so it can be Object-Oriented, and allow for long-term maintenance at any scale, which will be important for the next fundamental concepts. What does Angular aim to achieve? Angular provides a platform to make single-page applications. I think it's important to point out the usage of the word platform, as Angular comes with quite a bit more to help us scale applications to any point we need. It ships with many integrated libraries (more on that in a bit), integration with numerous third-party libraries, and, maybe most importantly, the Angular CLI (command line interface), which gives us access to build, serve, test, and even ship our application. "Application" is also a very important distinction- that is, Angular (like many modern frameworks) aims to provide the tools to create responsive, smooth user experiences. What are the essential building blocks of Angular? To understand Angular, you have to understand what a Component is. But first, it may be easier to first visualize what makes an application: navbars, buttons, tables, table cells, and every other separately distinct building block you can visually see. In Angular, every single one of these is a Component, and everything else that exists is in service of these Components. For me, this is where it really started to click, since in iOS, the same fundamental principle exists: every single object on the screen *must* conform to UIView, including any View Controller. Angular, of course, is no different — the root view of the app itself is also a Component. Templates define the appearance of the Component via HTML. Angular extends the functionality of templates quite a bit through direct text interpolation, directives, and property/event binding. These, combined with CSS, can achieve essentially anything you need it to without having to entangle your Component's business logic with the presentation of said Component. The final core piece of the Angular paradigm is dependency injection. Essentially, dependency injection helps keep your Components extremely light, modular, and maintainable. So, say you have a table that needs data from a request sent to an API endpoint. You *could* just have the inner workings of a server fetch right there all in the component, but you likely have multiple places all over your application where you'll be making API requests, and have to duplicate that code. Instead, Angular lets you define a Service object that can handle that API request, and return the data directly to your component. You don't even need to instantiate the Service since Angular will just automatically do that for you once you inject the dependency to keep things even cleaner. Dependency injection, services, routing, etc. can feel daunting, but I think as long as you view everything else that isn't a Component solely existing to work *in favor* of Components, things become a lot clearer and you can start building apps the Angular way. Speaking of, let's do a bit of project setup, take a look at the structure, build it, and add a component. Prerequisties Now that we know what Angular is, we can finally start our first project. A couple things we will need first: * Visual Studio Code * NodeJS and NPM with at least a basic proficiency with a terminal * Some basic understanding of HTML and JavaScript/TypeScript Creating and running your first project With Node and NPM installed, we can install the Angular CLI with the following command: ` Then we create our first project with: ` Note: The above command will have a couple prompts for you. Answer yes to add Angular routing, and the style sheet format is up to you (I chose SCSS). You can just press enter on both prompts for the default setup as well. And finally, building and serving our new app locally: ` Open http://localhost:4200/ on your favorite browser to see what we just made. One note about ng serve is its ability to pick up code changes and update live — no waiting for build times just to see very small changes here. Nice. Project Structure Of course, it's helpful to know what the CLI just built out for us. Looking at our project structure in VS Code, we can see quite a bit of config files set up in the root directory. Of course, these are all important, but for now, let's focus on getting familiar with a few: * angular.json — This is the configuration file for CLI, so it knows how to build, serve, and test your app. Should be good to go right out of the box. * package.json — The file where the list of all your NPM dependencies live, the package-lock.json specifies the versions for these files (for my iOS friends, this is very similar to the podfile or build.gradle for my Android friends!). Whenever you install a Node package, the tool will automatically update these for you. * node_modules — With all the above dependencies installed, the .gitignore should be ignoring this directory by default, but it's good to know everything is there. Now that we're familiar with the housekeeping of the app, we can dig into the most important part: the code. In the src/app directory, we can see our first module, component, and the files that make it up. Let's ignore those files for now, and create our very first Component. Creating The First Component Within your terminal, we'll run the following command: ` With that, CLI should have made a directory in src/app/my-first-component and the following files: 1. my-first-component.component.ts — This is the file where the data and logic needed to update your Component's Template live. 2. my-first-component.component.html — The associated Template for the Component, where the HTML is defined to actually render our Component. 3. my-first-component.component.scss — The associated style sheet for the Template, where styles scoped only to this Component are defined. 4. my-first-component.component.spec.ts — The very first unit test for the Component, automatically generated by CLI. How nice! Within the component.ts file, let's take special note of the following: ` Here we can note the Template and style sheet URLs, but of particular note is the selector, in our case called app-my-first-component. This is the custom HTML tag we can now use anywhere our Component is imported in our project. The reason app is prepended to the front of the name is because we defined this Component within the app module, but you can absolutely change the name if you want. If we look back to the root app directory in src/app (taking special note of the exact same file structure we just created in my-first-component), let's open app.module.ts. The CLI has already created a declaration for our Component in the NgModule decorator, and imported MyFirstComponentComponent automatically for us. Let's actually get our newly created Component on the screen somewhere. Let's open app.component.html. There's quite a bit of HTML already in here, but we can leave it mostly alone for now. Really, we can throw our Component just about anywhere, but let's search for the following: ` And replace it with: ` Save your changes, and check your browser to see the following: Now that we've got it up on the screen, let's do some slight modification to get data from the logic to the Template. First, add the following inside the class definition of my-first-component.component.ts: ` Then, inside my-first-component.component.html, replace the Template definition with the following: ` The double bracket notation tells Angular to interpolate the value within, and dynamically pull the text defined in our class. Save both files, and you should see the following: Neat, right? Conclusion Whenever someone asks me how easy it is to get started doing native iOS app development, it's easy for me to boast that you can start a project, throw something in Interface Builder, and run it — all within a few minutes' time. Now, I (and hopefully you) can easily say the exact same about Angular. Of course, this is just a very small taste of what Angular has to offer, but hopefully instead of feeling initially lost in a sea of documentation, the relative simplicity of the platform will seem a lot more clear from the essence of what I described here from my journey of also having to learn Angular. From here, I think it's valuable to look through the incredible official Angular docs, and I'd recommend running through some of their tutorials as well....

Aug 26, 2021

8 mins

Mobile Web DevelopmentAngular

WebGL Morph Targets and Ginger: Modernizing for Today's Web

WebGL Morph Targets and Ginger: Modernizing for Today's Web Ginger is a morph target demo that was initially written in 2011 for chrome experiments, and then rewritten to work as progressive web app in early 2016. In essence, Ginger is a customizable head that uses a slider to tweak various facial features, much like a character customization system one would find in a video game. It also supports taking screenshots, and generating share links that can be used to share your creation with others. The rewrite in 2016 focused on improving performance, and supporting modern web features. Notable improvements were made in the following areas: 1. Utilizing HTTP/2 multiplexing to load model data concurrently, and efficiently. 2. Utilize manifest.json for "Add to Homescreen" capability. 3. Offering a full offline experience with service workers. 4. Performance improvements from the previous version. We inherited the project with our recent acquisition of Stickman Ventures, and thought it appropriate to showcase. Since it was rewritten in 2016, Ginger hasn't been touched, and has fallen into neglect, though it still worked fine in modern browsers. It was using an old version of Polymer 2 which has long since fallen out of use. The Refactor The first order of business was replacing Polymer 2 usage with something more modern. Polymer 2 was bleeding edge at the time, and used many proposed browser features that have since been adopted or dropped in favor for other standards (modules vs HTML imports). Replacing Polymer with lit-html To reduce friction, we opted to refactor Ginger's web components to use lit-html from the Polymer Project. Lit isn't a framework necessarily, it just makes it easier to write standard web components that are efficient, and work across all major browsers. Transitioning from Polymer to lit was not a very complicated process, as they both use the same element lifecycle. The most notable difference was the transition from HTML imports to modules. With Polymer 2, elements are defined inside of HTML files, and are imported directly using HTML imports; however lit-html allows defining elements using a modern class-based approach. ` With lit-html, it's very easy to define custom elements by extending off of the LitElement class, and registering it using either customElements.define or the decorator. We then use rollup.js and babel to create a bundle that works well across browsers. Using Workbox to Support Offline Usage Ginger is able to work completely offline thanks to its use of service workers. The previous iteration of Ginger used a service worker that came from platinum elements. Platinum elements made it possible to add offline capabilities to an application with very little effort. However, they've been deprecated in favor of workbox and sw-toolbox. We chose to go with workbox as it supports all of the features that we need, and I was already familiar with it. The service worker uses caching strategies to cache images, fonts, code and model data. Data that won't change often or at all uses the "cache first" strategy, while code uses the "stale while revalidate" strategy. The cache first strategy will grab the requested file from the cache if it exists, and do nothing else. The stale while revalidate strategy will return the cached data similar to the cache first strategy; however, it will also download a newer version from the server in the background. Here's some basic examples taken directly from Ginger. ` You can find out more about other caching strategies that workbox offers in their docs. Closing You can find Ginger's source code on Github, and it's available under an Apache 2 license. The Ginger model was created, and is copyright of David Steele. This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License....

Jul 17, 2020

3 mins

PWAHTMLJavaScript

Getting started with Vitepress

Getting started with Vitepress to create your blog site Have you heard about Vitepress, but you have not checked it out at it yet? Well, in this article, we are going to cover the basic setup and share what all the fuss about this new fantastic static site generator. If you are looking for something that would allow you to quickly create a static site with Markdown support, search, Light/Dark theme, advertisement, navigation, and much more, then Vitepress is what you are looking for. Suppose you want some proof of Vitepress's power without having to invest any further time, I suggest you head over to the main Vitepress site (vitepress.dev) and experience what Vitepress can do, as the official site is built on Vitepress! What is Vitepress Vitepress is a powerful Static Site Generator powered by Vite mainly used for Documentation and Blogs with the default theme, and open to customization to be used for anything you may need it to with custom themes and theme overrides.. Vitepress power comes from its low learning curve, powerful configuration settings, and the ability to easily customize it. For example, internationalization is built-in, Theme toggling is built-in and even full-site searches require a single line in the config to be set up. What makes Vitepress so powerful is its extensive configuration and the fact that it can be customized by overriding the existing theme, creating your theme, or simply enhancing pages with custom Vue code. Prerequisites To successfully run the following demo, you will need: - Node.js version 18 or higher. - Terminal for accessing VitePress via its command line interface (CLI). - Text Editor with Markdown syntax support. - VSCode is recommended, along with the official Vue extension. Create your project To create the project, we will follow the steps shown in the official Getting Started guide. If you want to set up a Vitepress project quickly, run the following steps: - Create a new folder mkdir vitepress-tutorial - Access the folder cd vitepress-tutorial - Install Vitepress npm add -D vitepress - Run the Wizard npx vitepress init - Answer the questions: - Where should VitePress initialize the config? - Site title - Site Description - Theme - Do you want Typescript support? - run npm run docs:dev - Enjoy your site. After you run the above steps, your Vitepress will be ready and running as shown below What is available out of the box The site comes fully set up with enough to get you started. Let's see what features are available within the software: - Navbar: The site comes with a Navbar that already includes links to our blog pages - Light/Dark theme: Out of the box theming - Home page: Basic Homepage layout - Blogs: Two different blog posts with sidebar navigation All of the above is available with just 4 files! Let's move forward and see how to customize our app. Overriding the homepage It is time to modify our site by accessing its folders. What you will probably notice when opening the site, is that Vitepress follows a very simple file structure, in fact, a new installation just includes 4 extra files on top of the expected package.json and node_modules. Let's update our homepage to make it more unique. Because Vitepress follows a "file-system based router" we can find this file within the root of the project within a file called index.md. This file will be accessible at "/" or "/index.html" of your site. The content of the file is the following: ` As you can see, the file has no code in it, and it is just driven by configuration, or more specifically in this case Markdown frontmatter, that is a set of configurations accepted by markdown files that help you set up your options such as title, description, og:image. We will describe frontmatter in more detail later in the article. Before we jump into modifying the configuration of the file, you should know that Vitepress has a very extensive and well-detailed documentation site where you can find help if you are stuck or would like to learn more. In this case, we are overriding the "home" page, so the documentation can be found here: Home Page Default Theme configuration. If you read the current file within the homepage, you will notice that it defines a "layout" of "home". This layout displays a main header with CTAs and a set of feature blocks. There are three different layouts available in the Default theme: "home", "doc" and "page". The title and description have already been set from the information we provided from the installation wizard. But the rest is just a basic boiler template. Let's see what we can change: 1) Add a hero image. This image can either be externally sourced or saved within the repository. ` 2) Update the action buttons. ` As shown above, Action buttons have two themes "brand" or "alt" and can accept internal or external links. Vitepress is clever enough to set the external links to open in a new tab and set the rel="noreferrer". 3) Change the feature blocks: Features blocks are great for engaging with the user and telling them what makes your site special. This accepts an icon and some text, so let's change ours with the following: ` The homepage is now completed and updated and it should look like this: Please note that what we did on the homepage is just changing the markdown front matter of the "home" layout. What this means is that if you want to, you can easily customise the page further by either adding more blocks to the layout file or actually by writing and styling the rest of the page as normal. Site configuration In this step, we are going learn about the main site configuration and how we can use it to customize our site. The configuration file can be found in the .vitepress folder under the name of "config.mjs". Just like the homepage layout, the configuration used in the preset file is self-explanatory: ` This file is very important and you are probably going to have it open at all times as it is going to be responsible for the layout of the sidebar navigations of your site. In this section, we are going to learn how to use the Vitepress configuration file to achieve the following: - Modify the sidebar navigation - Enable Search - Add Favicon to your site Modify the sidebar navigation The sidebar is the component displayed on the left-hand side of the blog pages. This is not automatically generated, but it is manually set in this file. You can have more than one navigation, so, for example, you could specify sidebar navigation that shows in pages that have "/blog/" within their path and another one for all markdown pages that have "/tutorials/". Let's see how to implement this: ` With the above code, there will be 2 different sidebars. One will just show if the URL includes "/blog" and the other will be displayed if the path includes "tutorials". Clicking on the above items will give a 404 error as we do not have any pages in that specific location. Still, we can easily fix the issue by creating the two folders "blog" and "tutorial" and creating the required files within these folders in our case are "index.md" and "one.md" for the blog and "index.md" and "two.md" for tutorials. The sidebar has further settings like the ability to create a nested tree or create collapsable menus. You can learn more by checking out the the official documentation on default theme sidebar. Enable Search No documentation or blog site is complete until a search is fully implemented on it. Luckily for us, enabling a site-wide search is extremely simple with Vitepress. Vitepress supports two different search types: a full-text search using minisearch and Algolia based search. In this tutorial, we are going to enable the full-text search. This is fully built-in and requires no external accounts. To enable search, we need to add a "Search" parameter within our themeConfig and set the provider to "local". We can add this right below the socialLinks. ` With just a simple config change, our site will now have a full site search working as shown below: The official search documentation has further information about the look and functionality of the search. Add Favicon to your site Even if the site configuration is very extensive, there are times when you will need to add something within the site-wise page that is not available. In this section we are going to learn how to add specific attributes to the of our site, and specifically how to add a favicon. To add custom values to the head, we are going to use the "head" properties available with the Vitepress configuration. The "head" configuration is an array that accepts an array with the element type (eg. link, script, meta), and an object including all the attributes for that specific element. So for example to replicate the following HTML: ` we would define the following head config: ` We can use this technique to set up metadata and even load fonts or Google Analytics. More info in the site-config head Writing your post In the last section of this article, we are going to learn how to actually write a blog post and also learn how to customize the pages with JS and styles. Writing your first page In the previous section, we created a couple of markdown files, but they are currently empty. Let's see how to create beautiful documentation using the built-in feature of Vitepress. In this section, we are going to work on the file stored in /blog/index.md. This file can be accessed in your browser by accessing "http://localhost:5174/blog/index.html". Blog Frontmatter Every file needs to have a frontmatter defined. This is used to define basic information on the page, such as the title, description, and more. For best SEO results, it is best practice to always define a title and description for a new page. We can do this by adding the following code at the top of our file: ` Frontmatter in Markdown files are delimited by the "---". In the above code, we set our title and description. Vitepress frontmatter supports further config like lastUpdates, sidebar, outline, and more. You can find info on the frontmatter-config documentation. Frontmatter has some global configuration, such as title and description, but also "layout specific" settings that are just available on specific layouts. This is clearly explained in the documentation. Blog Markdown Now that our post frontmatter is set, it is time to write the content of it. This is done using a very extensive markdown engine. Let's start with the basics and write a heading with some text and a link as shown below: ` After saving, our development environment will show the following results: Let's add a couple of headings and a table of contents to our document using [[toc]] to the top of our page: ` The above will produce an unordered list with all our links. The last feature that I want to share about the Vitepress markdown engine is the code editors. The markdown engine used in Vitepress offers extensive features when it comes to code rendering. Features available are "code highlight", "code focus", external snippets loading and much more. The full list of features can be found in the markdown docs. Let's implement a simple code snippet with a line of code focused. This can be achieved by adding "// [!code focus]" at the end of our row. Let's give it a try: ` The output of this will be: Customize your blog with Vue In this last section, we will learn how to customize our code by adding js logic, style, and external components. Before we begin, it is important to understand that when you use the default template of Vitepress, your pages are going to be rendered with Vue. This means that we can expand the individual page's functionality by rendering other vue components and/or writing logic and styles directly on the page. To better explain this concept, we are going to create a team page. Create a file called team.md within the root of our repository. This file will be accessible on "http://localhost:5174/team.html" and will be just a simple Markdown file. First, we set up the frontmatter as before. In this case, we have to specify an additional config called "layout". This will ensure the page has no style or components loaded such as sidebar or aside. ` Then we will have to create our team variable, just like a normal Vue component; we can do so by defining a script setup tag and defining the constant there. ` In the above code, we have imported the VPTeamMembers component from the vitepress/theme and defined an array of members. The values used in the members array are hardcoded, but as you may expect, you can load this information directly from an API. We now have to use the "members" variable within our file. We can do so by writing normal JavaScript. The markdown file will evaluate the JavaScript and render it, so in the following example it will render a specific component. ` Before we move forward we need to define some style as the page is unstyled since we have loaded the layout of "page". Just like we did with the tag, we can load a tag and update our styles: ` The completed file will look like this: ` The file above now includes: - A frontmatter that specifies a "page" layout - A script tag that loads an external component and defines a variable - Styles to make the page pretty - Markdown with a custom component The completed team page would render the following: Conclusion Vitepress is an extremely flexible static site generator. Its default theme provides you with everything you need to get started quickly. The ability to load external themes, enhance the current theme, and or write custom code within your page makes this tool extremely powerful. In future articles, we will discover what components are available within the Default Theme and see how you can make the most of your Vitepress site but keep on coding....

Dec 21, 2023

12 mins

VueViteVitepress

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

History of Mobile Web Development and the rise of PWA

History of the Smart Phone

March 1991

1996

1998

1999

2000-2007

2007

2007+

The evolution of Mobile Web Development

WML - 1999

cHTML / iHTML - 1999

M.dot

Native - 2008

Responsive Web design - 2008

Hybrid App development - 2010

PWA - NOW

The Rise of PWA (Progressive Web App)

Feels like "home"

Be connected

Write for Web, serve on mobile

Ready for shopping

At a fraction of the cost

Existing skills

Development speed

Re-usability

Versioning

Conclusion

Simone Cuomo

You might also like

Getting Started with Angular: A Mobile Developer’s Approach

WebGL Morph Targets and Ginger: Modernizing for Today's Web

Getting started with Vitepress

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

Getting Started with Angular: A Mobile Developer’s Approach

WebGL Morph Targets and Ginger: Modernizing for Today's Web

Getting started with Vitepress

Introduction to Zod for Data Validation