Are progressive web apps the future of web dev?

Whether you heard “PWA” in discussions with colleagues and wondered just what a progressive web app is, or you are a seasoned developer curious as to why a growing number of well-known brands like Starbucks, Twitter, Instagram, Pinterest, & Uber have implemented PWA’s in production, you’ve come to the right place. This article aims to demystify the growing trend towards progressive application architectures and what advantages they may provide for your project or company. Let’s dive in.

 Before Ryan Dahl’s NodeJs, frontend and backend engineers occupied two different “worlds”. They didn’t speak the same language. NodeJs solved that by allowing engineers to write full stack applications in Javascript, making it far easier to bring an app to market without the need for as many engineers or as many moving pieces. Not only did it make the development experience more coherent, it also freed up time and resources that were previously “lost in translation”. By embedding the V8 engine outside the browser, JS developers could now write fully functioning backend logic themselves.  Fast forwarding to today, modern teams face a similar problem in the event the company requires both mobile native and web experiences; development resources are tied up juggling multiple repos with completely different technologies, requiring diverse expertise and increasing time to market exponentially. In a nutshell, developing across different stacks for the browser and mobile native apps is hard, it requires diverse expertise and elbow grease.  

In parallel, when envisioning a new project and outlining the tech stack in broad strokes, one of the most important considerations at the outset is the type of device you expect your user to consume your application on. The answer tends to drive the technical roadmap of the product, either pushing developers towards native mobile application technologies like Swift and Objective-C, or driving the team towards their web stack of choice (mainly MEAN, MERN, or JAMStack these days). This is due to the fact that until recently, only mobile native technologies gave you access to device level functionality that was traditionally inaccessible to the web. Until now… 

A progressive web app is essentially a collection of technical implementations that allow developers to get native-like functionality from the web, unifying the stack and eliminating the need for the separation between web and mobile development. PWA’s have many of the sought-after capabilities of native apps, such as system notifications, resource caching, and access to the microphone and camera, all from the web. At a high level, this is done through…

Service workers are programs that get “left behind” when a user closes the browser. What this means is that the Javascript in the service worker sits decoupled from the browser’s execution context, operating on what’s called a different “thread”. In practice, this allows PWA’s to display system level notifications, intercept requests, interface with web push API’s and a whole host of other capabilities previously inaccessible to a traditional web app. Moreover, the user can add the web app to their home screen just like any mobile app downloaded from the app store and will not see the surrounding browser UI. For all intents and purposes, the user will experience the application as if it were native.

Using a PWA has a lot of built-in advantages, the most obvious of which is that your team operates with one stack, with one repo to troubleshoot and debug. This alone is worth the effort to switch with respect to time, energy, and headaches saved. Saving yourself the hassle of implementing enterprise grade CI/CD pipelines, testing suites, and cloud configuration for multiple repos is life-changing.

 There are two types of friction that the PWA solves. The first is the App Store, which puts unnecessary clicks and actions between a user deciding to buy and having your product in their hands. With a PWA, there is no need to visit the App Store, users may add your product to their home screen directly from the website, bypassing the App Store completely. The second is the lengthy and largely arbitrary process of application reviews and approvals by the powers that be. Rigorous application standards and tyrannical guidelines imposed by Apple, Google etc. become a thing of the past. No more sharing a large percentage of your profits simply for the privilege of selling your own product. You are free!

 Offline support, performance, and the meaning of “Progressive”

 The work “progressive” is used for a reason. PWA’s are meant to be gradually implemented over time in keeping with a gradual transition from a traditional website or web app. There is nothing forcing a wholesale conversion into a fully-fledged mobile experience. In the case where a traditional web app or website is all that’s needed, a service worker implementation can do wonders to your first-contentful-paint (FCP) time and other critical aspects of both conversion and the user experience. Content for blogs and other styles of content delivery can be stored for offline use, and large resources that traditionally increase load times such as videos and images can be cached locally for subsequent visits. In short, these are changes that can be made slowly over time without interrupting the service that is currently online. 

 While support for native-like functionality from the browser grows by the day, there are still operations and functionality that are only accessible to native applications. While most any traditional web app or website can certainly benefit from the addition of a service worker and simple caching strategy, there most certainly are use cases where a native application is a necessary evil. One prime example is the complete inability to use Bluetooth, which is necessary for indoor geolocation among other things. Another is the limitations imposed on 3D UI design and some dependence on internet connection for data.

 Like any new technology, there are always associated tradeoffs. I hope that this article proves usefull in understanding how to properly contextualize the use of PWA architectures in your future projects. If I missed something or failed to highlight a key point, please reach out with what you’ve got!

If you’ve written CSS for any length of time, you recognize that being able to “write CSS” in the modern tech ecosystem means much more than simply understanding and regurgitating the syntax. Developers today are increasingly expected to have a rich understanding of the dynamic ecosystem that is poised to take CSS from a somewhat boring and clunky necessity, to a truly transformative source of competitive edge. A lot has changed in the world of CSS lately so without further ado, let’s get up to speed…

More and more codebases are beginning to utilize some sort of pre-processor when writing CSS to make the development experience more intuitive and less repetitive (more DRY). Gone are the days of monolithic, unmaintainable stylesheets draining development resources; supersets of CSS3 such as SCSS (and it’s ancestor “SaSS” or “indented syntax”) have revolutionized the way CSS is written with a host of features not currently available in the CSS main spec. Put simply, they give you access to tomorrow’s CSS, today. Here are a few noteworthy pieces of functionality: 

By allowing developers access to variables when writing stylesheets, it is possible to create central sources of truth that lend themselves naturally to theming and other global config required for a given design system. We can now extract our color palettes, typography preferences, spacing defaults and more for rapid vibe changes on-the-fly! But wait, if we have variables…..do we have….functions? Why yes we do.

Functions in CSS work much the way they do in JavaScript, or any other object-oriented programming language. Why do they matter? Well, modern web development requires responsive design which….isn’t easy. Consumers are increasingly consuming content on their mobile devices which means mobile-first design that must account for layout shift and screen size compatibility is a necessity. Creating designs that work well across various screen sizes presents lots of implementation challenges that are solved by allowing developers to use mathematical calculations in SCSS. Layout shifts, dark modes, animations, and transitions are just some of the ways in which functions make our lives oh so much easier. Functions allow developers to account for window resizing and a whole host of situations that were either impossible or very difficult to handle with traditional CSS syntax.

If you are a fan of the readable, nested structure of HTML, have you ever wondered why CSS was so…wide? You are not alone. SCSS lets you write your CSS in a logically nested fAshion; it works exactly as you think it does. Furthermore, mixins and the Extend/Inheritance functionality of SCSS allow you to treat your classes as you might treat prototypal inheritance and the spread operator from ES6 syntax in JavaScript (but not quite the same). Placeholder classes work to reduce bloat by allowing developers to create utilities that are only transpiled if used. This takes care of cleanup of unused classes (we all lose track at some point) and makes writing CSS a pleasure. By the same token, mixins further improve the experience by behaving as a function where the operant variable passed by default is the browser context, making your stylesheets much easier to maintain and reducing the complexity of cross-browser compatibility for you at least somewhat.

Ever gone toe-to-toe with a monolithic beast of a stylesheet? No fun. Partials and modules allow developers to refactor ludicrously long stylesheets into logically separated, manageable chunks that can be scoped as needed. Fundamentals of writing good code (separation of concerns, modularity, maintainability, DRYness etc) are not only good hygiene but essential to maintaining our sanity, why wouldn’t the rules apply to CSS? They do now! 

If you’ve kept your ear to the ground, you’ve no doubt heard of PostCSS; I had many misconceptions about what this library actually did in the beginning, but when I finally understood its function and place in the stack, it blew open doors I my head I didn’t even know existed. I initially thought PostCSS was some kind of preprocessor and left it at that. Man was I wrong. PostCSS is not a preprocessor, even though it can act like one if you want it to. 

PostCSS converts your CSS into a data object you can then manipulate with JavaScript!

In a sense, PostCSS sets the stage for limitless possibilities regarding manipulation and processing of your stylesheets. It abstracts your syntax into something you can write plugins for called an abstract syntax tree. C’mon, that just sounds cool. Functionally, this allows you to process your stylesheets in any way you see fit with the help of popular build tools and task runners such as Webpack, Grunt, and Gulp. The most famous of these plugins (which you probably use without knowing it) is Autoprefixer, the processor plugin used to append browser prefixes to all your CSS classes, handling the dreaded task of cross-browser compatibility in one pass! PostCSS has a diverse and rapidly growing ecosystem of plugin packs which do everything from simulate color blindness for accessibility testing of your UI to the now popular Lost grid system by Cory Simmons. Suffice to say, if you ever meet Andrey Sitnik, Ben Briggs, or Bogdan Chadkin in person, buy them a beer! This stuff is awesome! 

Moving forward, the future of CSS is bright and has no doubt accelerated over the last couple years. If you write any PostCSS plugins let me know! I’ll do my best to contribute where I can!

When learning web development, there is a lot going on, so much so that it is easy to get lost in the sea of moving pieces to the puzzle. One antidote to such chaos is to contextualize each new technology into a cohesive framework at a high level so as to build upon previous knowledge and add to your understanding. By stepping up to 50,000 feet and understanding the ‘machine’ as a whole, ancillary aspects of putting a new website or application out into the world become much more digestible. The aim of this article is to do exactly that, first delving into the role DevOps plays in modern web dev and second, outlining the key aspects of modern DevOps as areas worthy of further inquiry. Let’s get started…

Modern websites and applications have unique characteristics from a business perspective. They are one of the only places where mistakes are simultaneously unforgivable and inevitable. Users expect zero downtime and robust functionality to the point of perceived perfection, while developers and business owners necessarily make mistakes daily, if not hourly. The point of DevOps as a practice is to balance this mismatch of expectations and reality and bridge the gap between fallible systems and an enjoyable user experience. To be sure, there are three key aims of successful DevOps…

DevOps is the equivalent of preparing to send your child off to college. It’s the thing that takes the proof of concept that works fine on your development machine, and gives it legs to go off and do great things in the hands of users everywhere. Indeed, when making the transition from using software locally on your laptop to providing it as a service to the world, one of the first challenges we face is making sure that it is reliable. This means that no matter what, our services work 24/7/365 with no exceptions. Users quickly lose faith in software even after just one unexpected error making uptime non-negotiable as a pillar of a successful software business (cite research). In addition, there is the problem of scalability. Having your software work for five people is a very different proposition from making it work reliably for 5 million people. The sheer volume of requests and computing resources needed complicates matter considerably. Furthermore, any great software product or website needs to evolve with its users’ needs over time. As with any sort of complex system, iterating and deploying thousands of changes will necessarily introduce errors into the mix. The issue of seamless iteration becomes clear when you understand that tech companies are deploying dozens of times a day and that most production codebases are hundreds of thousands if not millions of lines of code, the certainty of introducing fatal errors into your applications and the necessity of a system for handling them becomes clear.

The term DevOps refers to the collection of systems and practices that combine software development (hence ‘Dev’) and IT operations (hance DevOps) for the purposes of shortening the systems development lifecycle and providing continuous integration and delivery. In essence, it makes sure that you can deliver on your value prop continuously and mitigates the probability of someone on your team introducing fatal bugs into production code.

While the implementation details of the following products are no doubt involved and time consuming, I think you will find that a broad overview of some choice areas will give you the ammunition you need to start taking on the task of bringing your DevOps practices into the 21st century.

While sometimes overlooked, the importance of choosing a cloud provider for your computing resources cannot be overstated. While maintaining servers and managing custom hardware is certainly what’s called for in some specialized situations, cloud providers will no doubt be your best bet in the vast majority of cases. There is simply no way for small to medium sized businesses to manage their hardware more effectively. The costs associated with constructing and maintaining the requisite infrastructure necessary to compete is absolutely astronomical. Learning to leverage the agility and scalability of cloud infrastructure is absolutely crucial to securely scaling your services.

Managing dependencies is tough enough by itself. By moving your software from your local dev environment to the cloud, the added complexity is enough to make anybody’s head spin. Managing system compatibility quickly becomes intractable as you move to cloud infrastructure over on-premise hardware. The solution? Containerization. By wrapping your applications in ‘containers’ you can effectively remove a layer of complexity and assure yourself your app will run no matter the hardware (within reason of course). This is done by taking a ‘snapshot’ of your dev setup and wrapping it up with a pretty bow so you can port it anywhere you’d like. Simple, effective, and absolutely crucial to keeping wtf’s/minute at a minimum.

Once your application is running in containers in the cloud, there comes a time when you will need to make sure your services are healthy and operating cohesively as a unit. Container orchestration software and ‘Infrastructure as code’ solutions enable you to effectively administrate running containers without the need to ssh into ‘hot’ services in production. Additionally, you will need to ensure that your containers restart autonomously when they fail, allowing your cloud native container infrastructure to re-generate by itself without your involvement. Having a robust container orchestration and administration setup is a must, especially in small teams where an experienced sysadmin hire is not yet an option.

Tools of choice: Kubernetes, AWS EKS, eksctl & Flux 

We’ve established that one of the key functions of DevOps is to ensure that fatal errors do not make their way into production code. In order to do that, testing your code before transitioning it into production seamlessly is the order of the day. A comprehensive testing suite is a staple in the CI/CD pipeline and cannot be overlooked a s key piece of successful DevOps within an organization. TDD, or test driven development, is something worth looking into, the intricacies of which are beyond the scope of this article. Suffice to say, up your testing game as soon as possible!

Tools of choice: NightmareJs, Jest, Selenium, Mocha

 CI/CD stands for continuous integration & continuous delivery. These tools serve to orchestrate the entire DevOps pipeline step by step in an autonomous fashion so that you can ‘push to master’ and have your system do the rest of the work. When your CI/CD pipeline is finally up and running, it really is a thing of beauty. Instead of manually executing every step in the process of testing your updated code, pushing to master, ‘sshing’ into a hot server, using linux screen or another command line utility to pull your updated repo and making the transition between live endpoints across numerous servers and orchestrating the whole thing yourself, it is all done by your army of integrated workers! Your CI/CD pipeline will save you immeasurable time and headache, get it handled.

Tools of choice: CircleCI, Travis, Github Actions, Semaphore

While the magic and tangible benefits of a sophisticated DevOps pipeline are clear, there are most certainly tradeoffs. For one, understanding and implementing each piece of modern DevOps takes time. While the upfront investment is well worth it in the long run, the decision to implement it depends entirely on the vision you have for your project and whether the scale of the application requires the level of robust organizational systems engineering that enterprise grade software necessitates. Making that decision is up to you, it is a matter of right tool right job. If you are building a billion dollar company with a vision of having teams upon teams of engineers working on a multitude of codebases, then DevOps is an absolute necessity. If you are making proof of concepts for side projects, it’s really just a nice to have.  Be judicious with your time! I will say however, that once you set it up once and experience the peace of mind and simplicity associated with a well-oiled DevOps machine, there is no going back!

Are PWA's the Future of Web Dev?

Are PWA's the Future of Web Dev?

Style Points – CSS in 2021

DevOps - A Beginner's Guide

Latest

Are PWA's the Future of Web Dev?

Style Points – CSS in 2021

DevOps - A Beginner's Guide