Back to Top

How to Set Up a Customer Loyalty Program for Your Ecommerce Business

Marketplace sites such as Amazon or Etsy can provide a steady income stream for ecommerce entrepreneurs. However, selling on your own website has the potential to generate repeat business from loyal customers and grow your brand. 

A customer loyalty program is a great way to earn the repeat business of your customers and build relationships that can develop into brand loyalty and even referrals. Unfortunately, many ecommerce entrepreneurs consistently get it wrong when they attempt this strategy. 

There are several different types of customer loyalty initiatives and approaches to designing programs that attract the right kinds of buyers for your brand. We’ll help you navigate your options to build a lucrative loyalty program for your ecommerce business. 

What is a customer loyalty program?

A customer loyalty program is a technique that businesses use to build relationships between brands and their customers. 

A business will offer exclusive promotional offers and other perks, and in return customers become steady, long-term buyers. The goal of a customer loyalty program is to attract the right customers for your brand and create long term, profitable relationships with them. After all, 80% of a company’s profits come from just 20% of customers. 

According to recent research, top performing customer loyalty programs have the ability to boost revenue by 15-25% each year. So, creating a customer loyalty program can be a very profitable way to build relationships with customers. 

Steps for creating a customer loyalty program

Are you ready to take the next steps in creating a customer loyalty program? Here are three easy steps to get you started.

Steps for creating a customer loyalty program

1 – Choose the right type of program

There are several types of customer loyalty programs that are suited for different audiences and industries. In order to design a successful customer loyalty program, it’s important that you choose the right type of program to implement. Some of the most popular types of customer loyalty programs include:

Points programs

These popular customer loyalty programs allow customers to accrue points over time that can be redeemed for rewards or free products. Points can be accrued by making purchases, engaging with content, signing up for events, etc. 

Points programs that are based on customer referrals have even more potential, since referred customers have a higher lifetime value than others. 

Spend programs

A popular choice for reducing churn rates, this customer loyalty program gives customers credit depending on the amount of money they spend on products and services. 

For example, for every $150 they spend, they receive a $5 credit towards their next purchase. 

Tiered programs 

A form of points program, tiered customer loyalty programs allow customers to earn points with increasing tiers of rewards, depending on the points they accumulate. Gifts, free products, and exclusive access can all be part of a tiered customer loyalty program. 

Paid programs

These programs require customers to pay a monthly or annual fee to be a part of a “members only” rewards program. Once they are a member of this program they can get access to special events, services, products, deals, and other unique opportunities that other customers don’t get to take advantage of. 

The paid barrier to entry has the potential to draw customers further into your marketing funnel in addition to promoting incentivised opportunities. 

Punch programs 

A well known type of customer loyalty program, punch programs are easy to understand and make earning rewards simple for customers. A digital or physical “card” requires a certain number of “punches” (received by making a purchase) in order to earn a gift or reward. This incentivises customers to continue making purchases in order to build up punches and earn rewards. 

2 – Define the rewards and rules

Now that you’ve decided what type of customer loyalty program you are going to use, it’s time to make the rules and decide what rewards you will offer to your loyal customers. You don’t want to overwhelm your customers with too many options or make the rules too complicated, or customers will lose interest. 

You can also opt to launch your customer loyalty program in bite-sized chunks that are easy to understand and progress naturally. 

At the end of the day, you want rewards that have:

  • a perceived value
  • rules that are easy to understand
  • simple ways to redeem rewards 

Before you get started, make sure that your business is using accounting software that comes with critical features such as integrations, payments, and invoice templates. This way you can take advantage of all of your prospecting and sales opportunities to streamline your customer loyalty program. 

If you use customer relationship management software, you will also have to think about how to integrate the program into your existing classification system. 

3 – Promote your program

Once you’ve established the rules and rewards of your customer loyalty program, it’s time to promote your program to get customers to sign up. 

Start with email promotions sent to your existing customers and current mailing list. Keep in mind that emails that are relevant to customer’s real life experiences with your brand are 38% more likely to be opened, so clearly explain what the email is for in the subject line.

Companies should also utilize social media to promote their rewards program. Focus on platforms where your target audience spend most of their time or where you get the most engagement so you can spread the word to those that are likely to be interested in signing up for your program. 

Don’t forget to use your website to promote your rewards program as well. You have the full attention of consumers that visit your page, so take advantage of that to offer them incentives to join your customer loyalty program. 

You can use chatbots on your website, design a dedicated landing page to get people to sign up, and include a pop up sign up form after they spend a certain amount of time on your site. 

Loyalty Program Examples

Check out this email example from Alamo Drafthouse Cinema, they’re promoting their rewards program to their existing customers. And in the email, they are clearly defining the benefits of the rewards program.

Loyalty program email example from Alamo Drafthouse Cinema

Sephora is another example of a great loyalty program. They have a tiered program incentivizing customers to spend more. The more you spend with Sephora, the better the program benefits get.

Tiered customer loyalty program example from Sephora

Common customer loyalty program pitfalls

Avoid making these mistakes when implementing a customer loyalty program:

  • Only targeting high spenders. Instead, identify the customers that are the most vulnerable to competition and focus your efforts on targeting them with loyalty promotions. 
  • Not keeping track of metrics. It’s crucial to track loyalty measurements such as churn, response, retention, and lifetime value in order to accurately gauge how your loyalty program is performing. 
  • Not listening to your customers. When your customers tell you something they like or dislike about your brand or your program, listen to them. 

For example, you may be trying to be modern by accepting PayPal, cryptocurrencies, or other alternative payment methods. But 71% of customers report preferring to pay using a credit or debit card, so make sure you use a payment gateway that can accept credit and debit with a smooth, secure interface. 

Start your loyalty program today

Creating a customer loyalty program is a great way to build lasting customer relationships and increase profits simultaneously. 

In order to design a successful customer loyalty program, it’s important that companies choose the right type of loyalty program with easy to understand rules and attract the right customers. 

Remember, it’s not all about the money. Keep an eye on crucial metrics to understand the full impact of your customer loyalty program, and focus on providing incentives that your customers will love.

The post How to Set Up a Customer Loyalty Program for Your Ecommerce Business appeared first on AWeber.

Reblogged 1 day ago from

The Pros and Cons of Using Affiliate Marketing to Grow your Business

Business growth is synonymous with creativity. One of the hardest parts of going into business is finding creative ways to let the world know that you are in business (and that you offer something they need). Even companies that have been in business for years can struggle to get their name out into the marketplace…

The post The Pros and Cons of Using Affiliate Marketing to Grow your Business appeared first on Benchmark Email.

Reblogged 1 day ago from

How to Use Keyword Clustering to Seamlessly Optimize Your SEO Content

Keyword clustering is the SEO tactic if you want to seamlessly optimize your SEO content and streamline your workflow at the same time. The best part? Keyword clustering is fairly simple, and Google SERPs give you all the information you need to make an informed decision on exactly how to do it.

It’s a timely process, but trust me, it’s worthwhile. Done well, this tactic will pay dividends to your SEO and marketing strategy for years.

So, how do you do it and why is it important? Let’s find out!

Benefits of keyword clustering

Keyword clustering has as much commercial value as it does for SEO and marketing. Although its primary purpose is to assign keywords to content pieces and content types in a bid to secure organic ranks, what it also does is lay down the foundation for your marketing team’s efforts in the next six months (or more!).

Through keyword clustering, a business can expect to:

  • Write content that better serves the buyer through a deeper understanding of search/keyword intent through Google’s data.

  • Create a content architecture or plan that feeds into other marketing efforts through content repurposing. Done well, keyword clustering can support PR, PPC, social media, newsletters, marketing automation, and more.

  • Increase productivity within the business by aligning marketing teams. Expect SEO and writing teams to have a plan of action for over six months.

  • Reduce the risk of cannibalization — since you’ve already mapped your keywords, there won’t be any duplicates, and you’ll know what to link where and by what anchor text.

  • Createa clear plan of action for SEO content that provides long-term scalability, since you have keywords to target over time that can be scaled indefinitely.

  • Increase visibility in the SERPs through on-page optimizations.

  • Increase chances of earning featured snippets by analyzing SERPs and finding what other articles rank for, what they cover and, as a result, what you should include within your own content.

How to use keyword clustering to seamlessly optimize your SEO content

1) Cluster alongside SERP analysis

While conducting SERP analysis, the first thing to determine is the content vertical — what’s ranking for your desired keyword? Is it generally home pages, product pages, service pages, collection/category pages, or articles? Whatever it is, that’s the type of content you need to create. If Google SERPs present eight articles and two product pages, then it’s most likely that your site will rank with an article. If it’s ranking product pages and you’re not selling anything, then no matter how relevant it seems, this keyword is not for you.

Once you know what you need to create and you’ve determined that you can create that page on your site, dig a little deeper and find out what type of content is featured within the top pages of websites that are most similar to yours in terms of niche and domain authority. Think about topics covered, headings, images, videos, and GIFs.

This investigative work provides you with an opportunity to understand exactly what your audience wants so you can serve them in the most meaningful way. It also ensures that you always create content with search volume, which has the possibility of ranking.

Pictured: an example of Google SERP for keyword: “how to complete a Rubik’s Cube”.

2) Use keyword clustering to discover new content opportunities

Another tactic for discovering what content to create, as well as new content opportunities, is through the SERP features and the prioritization of them.

Check for features and formatting such as featured snippets, video, images, knowledge panels and “people also ask” (PAA). PAA is especially useful; it’s a trove of questions, many of which can be answered within your content. Other questions may need a new article or page altogether, so you can start building out your content architecture and forming your internal linking strategy.

Additionally, by integrating these features, you’ll be covering more on your chosen topics, thereby increasing keyword density and closing the gap on your competitors. Plus, your content will use the language of your audience as opposed to your assumed keywords.

Keyword clustering is powerful. The graph below shows one article’s journey in Google SERPs. It ranks for 50 clustered keywords and includes questions from PAA. This article quickly achieved a featured snippet, image rankings, 9.37k clicks, 68.9k impressions, 13.6% CTR and an average of six minutes spent on the page. Oh, and this was achieved before a single website back-linked directly to the article.

Snippet taken from Fortune and Frame’s Google Search Console showing an article’s journey in the SERPs from publication. This particular article is about messages to write in a book (see point #3 to understand what I did with this link here).

3) Choose the most appropriate keyword for the content (then use internal linking, naturally)

Keyword clustering presents you with opportunities you may have otherwise overlooked. If you pull together multiple keywords that all sit within one article or web page, you can determine the best angle to write in order to suit your focus keyword and your online presence.

You will have a selection of keywords and you can use their search volume, competition and your website’s domain authority to determine the best keyword for your site to focus on right now.

Additionally, it means that you can write meaningful anchor text as part of your internal linking strategy. Taking the example from the graph above (“This particular article is about messages to write in a book gift…”), the anchor text “messages to write in a book gift” is not the focus keyword. The focus keyword is: “what to write in a book for a gift”, which doesn’t sound natural at all in the context above.

Thanks to a selection of clustered keywords, an internal link using relevant keywords, was easily slotted into a grammatically correct sentence. Ultimately, you can fit your keywords into your content instead of writing your content around your keywords.

4) Say goodbye to cannibalization

You could argue that you can avoid keyword cannibalization without clustering keywords, but can you?

If you know which keywords you’ve used where, then you should, in theory, have no (ok, there might be a little bit) keyword cannibalization. You won’t fall for the mistake of assigning a focus keyword to two content pieces – or more subtly – creating two content pieces for keywords that should’ve been clustered and covered within one article.

By clustering keywords and analyzing SERPs, you might be surprised at what belongs within the same content piece.

Let’s take these two keywords: “Rubik’s Cube method” (260 searches/month) and “How to complete a Rubik’s Cube” (590 searches/month).

Without looking at the SERPs, one might be tempted to assign “Rubik’s Cube method” as a focus keyword for an article that shares different methods, whereas “‘how to complete a Rubik’s Cube” would be a step-by-step guide. Thankfully, Google SERPs is quite clear that these two keywords can be used—and should be used—on the same web page to avoid cannibalization and poor performing articles because they simply don’t cover the topics in full.

5) Keyword clustering streamlines the SEO content plan and improves productivity

There’s no shying away from keyword clustering. Whilst it does add a whole lot of time to the keyword research process, it saves a lot of time long-term. The more keyword research and clusters you can create early on, the more it pays back in Google ranks and seamless marketing strategy.

The main benefit is objective planning for content. If you use keyword clustering to create a clear plan of action for SEO content for every single page on your website and jot down suitable content ideas for the future, you’ll be left with long-term scalability, since you have keywords to target over time that can be scaled indefinitely.

Your team can work from one document detailing which keywords live where, which content needs to be created in order to achieve a rank, and also, how that content can be repurposed for use across the marketing landscape.

Keyword clustering is a crucial and preparatory step

You can think of keyword clustering as the preparatory work that takes place before you execute SEO. An analogy, shared with me by Adriana Stein, is that keyword clustering is like the shopping and preparation of ingredients before cooking. If you skip this crucial step you might find yourself a bit flustered later on with a dinner that wasn’t quite what it could have been.

Ultimately, what keyword clustering does is insist that you take a step closer to your marketing strategy. Through SERP analysis, you will understand your customer on another level—you’ll know the Google SERPs for your desired keywords inside and out and exactly what you need to work towards in order to secure that page one rank.

Then, you’ll be rewarded with a full, scalable content plan, an entire team working in pursuit of the same content goals, and most importantly, seamlessly optimized content!

Reblogged 1 day ago from

Demographic audiences deliver twice the reach of narrow interest audiences, according to Facebook

However, both strategies perform similarly when reach is comparable.

Please visit Search Engine Land for the full article.

Reblogged 1 day ago from

Three Ways to Adapt Your Sales Content for Virtual Selling Success

B2B sales have changed, and so must the sales content that marketers create. What worked for in-person selling may not work in the digital world. Here are three ways to approach the shift. Read the full article at MarketingProfs

Reblogged 1 day ago from

3 SEO metrics to help secure executive-level buy-in

Campaign metrics alone may not accurately represent your team’s work. At SMX Next, Jessica Bowman shared metrics that can help SEOs change the conversation and get executives to recognize their value.

Please visit Search Engine Land for the full article.

Reblogged 1 day ago from

It’s That Time Of The Year (December 2021 Desktop Wallpapers Edition)

Slowly but surely, 2021 is coming to an end. And, well, could there be a better way to celebrate the last few weeks of the year than with some cheerful desktop wallpapers? To get you in the right mood for December — and the holiday season, of course — artists and designers from across the globe once again got their ideas bubbling and created festive and inspiring wallpaper designs for you.

All wallpapers in this post are created with love and come in versions with and without a calendar for December 2021 — so no matter if you want to count down the days to a deadline (or to Christmas morning, maybe?) or prefer to enjoy your new wallpaper without any distractions, we’ve got you covered. And if you’re up for some extra holiday cheer, you’ll also find some favorites from our wallpapers archives compiled at the end of this post. Happy December!

  • You can click on every image to see a larger preview,
  • We respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience through their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.

Submit a wallpaper!

Did you know that you could get featured in our next wallpapers post, too? We are always looking for creative talent! Join in! →

Winter Holidays

“Enjoy the Christmas and New Year holidays with your loved ones!” — Designed by LibraFire from Serbia.

King Of Pop

Designed by Ricardo Gimenes from Sweden.

On To The Next One

“Endings intertwined with new beginnings, challenges we rose to and the ones we weren’t up to, dreams fulfilled and opportunities missed. The year we say goodbye to leaves a bitter-sweet taste, but we’re thankful for the lessons, friendships, and experiences it gave us. We look forward to seeing what the new year has in store, but, whatever comes, we will welcome it with a smile, vigor, and zeal.” — Designed by PopArt Studio from Serbia.

Seville Has A Special Color

“The year is over and we celebrated it in Seville! Happy Christmas and a happy new year!” — Designed by Veronica Valenzuela from Spain.


Designed by Ricardo Gimenes from Sweden.

Catchiest Christmas Song Ever

Designed by ActiveCollab from the United States.

December In Sunny So Cal

“Oh dear! I mustn’t forget my parasol.” — Designed by Reena Ngauv from Los Angeles.

Oldies But Goodies

The frosty winter weather, the joy of a glass of eggnog by the Christmas tree, or, well, Bathtub Party Day — these are just a few of the things that inspired the community to design a December wallpaper in the more than ten years that we’ve been running this monthly series. Below you’ll find a selection of December favorites from our wallpapers archives. Please note that these designs don’t come with a calendar.

Dear Moon, Merry Christmas

“Please visit Vladstudio website if you like my works!” — Designed by Vlad Gerasimov from Russia.

Winter Landscape

Designed by Morgane Van Achter from Belgium.

Happy Holidays

Designed by Ricardo Gimenes from Sweden.

Getting Hygge

“There’s no more special time for a fire than in the winter. Cozy blankets, warm beverages, and good company can make all the difference when the sun goes down. We’re all looking forward to generating some hygge this winter, so snuggle up and make some memories.” — Designed by The Hannon Group from Washington D.C.

It’s Christmas

“The holiday season is finally here, which means it’s time to deck the halls, bring out the figgy pudding and embrace all things merry and bright. It’s Christmas!” — Designed by Divya (DimpuSuchi) from Malaysia.

Cardinals In Snowfall

“During Christmas season, in the cold, colorless days of winter, Cardinal birds are seen as symbols of faith and warmth! In the part of America I live in, there is snowfall every December. While the snow is falling, I can see gorgeous Cardinals flying in and out of my patio. The intriguing color palette of the bright red of the Cardinals, the white of the flurries and the brown/black of dry twigs and fallen leaves on the snow-laden ground fascinates me a lot, and inspired me to create this quaint and sweet, hand-illustrated surface pattern design as I wait for the snowfall in my town!” — Designed by Gyaneshwari Dave from the United States.

The House On The River Drina

“Since we often yearn for a peaceful and quiet place to work, we have found inspiration in the famous house on the River Drina in Bajina Bašta, Serbia. Wouldn’t it be great being in nature, away from the civilization, swaying in the wind and listening to the waves of the river smashing your house, having no neighbors to bother you? Not sure about the Internet, though…” — Designed by PopArt Studio from Serbia.

Joy To The World

“Joy to the world, all the boys and girls now, joy to the fishes in the deep blue sea, joy to you and me.” — Designed by Morgan Newnham from Boulder, Colorado.

Christmas Time!

Designed by Sofie Keirsmaekers from Belgium.

Ice Flowers

“I took some photos during a very frosty and cold week before Christmas.” Designed by Anca Varsandan from Romania.

Sweet Snowy Tenderness

“You know that warm feeling when you get to spend cold winter days in a snug, homey, relaxed atmosphere? Oh, yes, we love it, too! It is the sentiment we set our hearts on for the holiday season, and this sweet snowy tenderness is for all of us who adore watching the snowfall from our windows. Isn’t it romantic?” — Designed by PopArt Studio from Serbia.

Christmas All Around The Globe

“Christmas is celebrated all around the globe — in the winter as well as the summer. From north to south, east to west: Merry Christmas everyone!” — Designed by Ricardo Gimenes from Sweden.

Tongue Stuck On Lamppost

Designed by Josh Cleland from the United States.

All That Belongs To The Past

“Sometimes new beginnings make us revisit our favorite places or people from the past. We don’t visit them often because they remind us of the past but enjoy the brief reunion. Cheers to new beginnings in the new year!” Designed by Dorvan Davoudi from Canada.

Enchanted Blizzard

“A seemingly forgotten world under the shade of winter glaze hides a moment where architecture meets fashion and change encounters steadiness.” — Designed by Ana Masnikosa from Belgrade, Serbia.

’Tis The Season To Be Happy

Designed by Tazi from Australia.

Christmas Woodland

Designed by Mel Armstrong from Australia.

’Tis The Season (To Drink Eggnog)

“There’s nothing better than a tall glass of Golden Eggnog while sitting by the Christmas tree. Let’s celebrate the only time of year this nectar of the gods graces our lips.” — Designed by Jonathan Shears from Connecticut, USA.

Gifts Lover

Designed by Elise Vanoorbeek from Belgium.

Bathtub Party Day

“December 5th is also known as Bathtub Party Day, which is why I wanted to visualize what celebrating this day could look like.” — Designed by Jonas Vanhamme from Belgium.

Christmas Cookies

“Christmas is coming and a great way to share our love is by baking cookies.” — Designed by Maria Keller from Mexico.

Robin Bird

“I have chosen this little bird in honor of my grandfather, who passed away. He was fascinated by nature, especially birds. Because of him, I also have a fascination with birds. When I think of winter, I think of the birds, flying around searching for food. And why a robin? Because it is a cute little bird, who is also very recognizable.” — Designed by Engin Seline from Belgium.

’Tis The Season Of Snow

“The tiny flakes of snow have just begun to shower and we know it’s the start of the merry hour! Someone is all set to cram his sleigh with boxes of love as kids wait for their dear Santa to show up! Rightly said, ’tis the season of snow, surprise and lots and lots of fun! Merry Christmas!” — Designed by Sweans Technologies from London.

Happy Birthday Rudyard!

“December 30th is the birthday of Rudyard Kipling, the writer of the Jungle Book. To celebrate, I decided to create a very festive jungle scene with some of the characters from the story.” — Designed by Safia Begum from the United Kingdom.

Christmas Owl

“Christmas waves a magic wand over this world, and behold, everything is softer and more beautiful.” — Designed by Suman Sil from India.

Trailer Santa

“A mid-century modern Christmas scene outside the norm of snowflakes and winter landscapes.” Designed by Houndstooth from the United States.

The Matterhorn

“Christmas is always such a magical time of year so we created this wallpaper to blend the majestry of the mountains with a little bit of magic.” — Designed by Dominic Leonard from the United Kingdom.

Christmas Selfie

“In this year of selfies, I’ve imagined Santa Claus doing the same.” — Designed by Emanuela Carta from Italy.

Christmas With The Digies

“Merry Christmas from The Digies at” — Designed by Rachel Sulek from Wales.


“A simple wallpaper for the cold month December. Nothing more, nothing less.” — Designed by Frédéric Hermans from Belgium.

Christmas Mood

Designed by MasterBundles from the United States.

Reblogged 1 day ago from

Smashing Podcast Episode 44 With Chris Ferdinandi: Is The Web Dead?

In this episode, we’re asking if changes to best practises over the last year have negatively impacted the web. Is it all downhill from here? Drew McLellan talks to expert Chris Ferdinandi to find out.

Show Notes

Weekly Update


Drew McLellan: He’s the author of the Vanilla JavaScript Pocket Guide series, creator of the Vanilla JavaScript Academy Training Program and host of the Vanilla JavaScript Podcast. We last talked to him in July 2020, where we asked if modern best practices about for the web. So we know he’s still an expert in Vanilla JS, but did you know he’s solely responsible for New Zealand being missing from 50% of world maps? My smashing friends, please welcome back, Chris Ferdinandi. Hi Chris, how are you?

Chris Ferdinandi: Oh, I’m smashing. Thanks for having me Drew. Interesting thing. I actually make sure New Zealand is not on maps because it’s probably my favorite country in the whole world and I don’t want too many people to know about it.

Drew: You want it to remain unspoiled.

Chris: Indeed.

Drew: So welcome back to the podcast. Last time we talked, we posed this question of if modern best practices, the use of reactive frameworks and these sorts of things were actually bad for the progress of the web. And I don’t know whether it was a controversial episode or it just struck a chord with a lot of listeners, but that conversation has been one of the most shared and listened to episodes that we’ve put out that smashing.

Chris: Oh, that’s awesome.

Drew: It’s actually been more than a year now, 15 months since we recorded that, which at the pace the web moves is like literally forever. So I wanted to ask, has anything changed? Is the web still in a terminal decline? Has the needle shifted at all?

Chris: Yeah, quite a bit has changed quite a bit has not. So I think, it’s so weird. The web technology changes so fast, but the web itself tends to move a little bit slower just in terms of developer trends and habits. And so you see these slightly longer arcs where you’ll have a bunch of technology pile up around one approach and then it’ll slowly start to swing the other way and then change all at once. And so last time we talked, I think one of the big kind of… Well, I had two big points related to the modern web. The first was, we’re using a lot of tools that give developers convenience, but we’re using those tools at the expense of the user. So we’re throwing a ton of client-side JS at people, and that introduces a ton of agility and performance issues.

Chris: The other big point that I was really hammering on was that these tools don’t necessarily improve the developer experience as much as I think people think they do. They do for some people. And I think for another segment of the front end professionals it actually can make things a little bit worse. But what I’m starting to see happen now, and one of the things I’d love to dig into a little bit more is I think we’re seeing a new, it’s almost like a second generation of tools that take a lot of the developer benefits that these client-side frameworks bring and strip away the punishing effects that we put on our users as a result. So it’s taking those same concepts and tools and packaging them a little bit differently in a way that’s actually better for the front end.

Chris: So one of the things I’ve been talking about with people lately is this idea that modern development has broken the web, but it’s also starting to fix it. And so we can definitely dig into that in a bunch of different angles, depending on where you want to take this conversation.

Drew: Sure. What sort of things have you seen in the last year that really stand out from that point of view?

Chris: Yeah, so the two biggest trends I’ve noticed are the rise of microframeworks. So where we saw a lot of really big all encompassing libraries for a while React, Vue before that angular, which is just a massive beast at this point, we’ve started to see smaller libraries that do the same thing come into their own. So for example, I think the king of this hill is probably Preact, which is a three kilobyte alternative to React that uses the same API, ships way less code and actually runs orders of magnitude faster on safe updates than React does too. So you’ve got things like that.

Chris: For a while you had… Well, it’s still out there, but Alpine JS, which was inspired by VJS and then actually inspired Evan You who built Vue to release Petite Vue, which is a 5.5 kilobyte subset of Vue that’s optimized around progressive enhancement. So these are still client-side libraries, but the intent behind them is that they ship less code, include fewer abstractions and ultimately work faster and put less of that cost on the front end user. So that’s been one angle.

Chris: And then the second trend I’ve seen that I think is personally more compelling is a shift from libraries to compilers. And so the one that kicked this whole trend off was felt by Rich Harris, which takes the idea of state based reactivity. But instead of having this be a thing that runs in real time in the client, you author your code with the same general pattern that you might with React or Vue, and then you run a build tool that compiles all that into plain old HTML and vanilla JavaScript, and that’s what gets shipped to the browser. And so you’ve stripped out almost all of the abstractions in the client and you deliver something that’s way closer to what you might hand write with old school DOM manipulation, but with the developer convenience of state based EI. So that was really interesting.

Chris: More recently there’s a new tool called ASTRO that builds on what Rich did with Svelt, and also allows you to pull in components from your favorite libraries so you can mix and match Vue, React, FELT, Vanilla, JavaScript, all in one package, compile it all out into Vanilla JavaScript and ship orders of magnitude, less code without the abstractions. And so it would run way faster in the browser as well. And those are, I think for me, really the two big things that are like standing on the shoulders of giants and producing a front end that will hopefully start to be a little bit faster. The compilers in particular are interesting because they take us away from rendering HTML in the browser as much as possible. You still render your HTML or you still author it with JavaScript if you want, but the outputted result is more static HTML and less JavaScript, which is always a good thing.

Drew: Do you think this is the ecosystem’s response to this quiet developer dissatisfaction about the weight of modern frameworks? Is it just a natural heave and ho?

Chris: Yeah, it is. Although to be honest, I’m not entirely sure how much of this was driven by… Well, there’s some definitely some performance minded developers out there who have been very vocal about how these tools are bad for the user. I don’t know that that’s necessarily representative of the general population though. I mean, certainly a subset of it given how the last time we talked that episode did, but I think one of the things that none of these tools for me get at is… Or the thing that I’m most bothered by by the modern web that I don’t think these tools address is that I personally feel like just the development process in general is over complicated.

Chris: This is where I get into the whole like, I don’t think the developer experience is actually better with these tools, but I think for a lot of developers in maybe a team environment, it can be. For me as a largely solo developer, I find these tools more trouble than they’re worth, but I know a lot of folks disagree with me there, so I don’t want to dismiss that as invalid. If you find these tools useful great, but yeah, I think this is maybe a natural pendulum swing back in the other direction.

Chris: The third thing that I didn’t talk about that your question actually makes me think about though is, there is almost a natural cycle in the web where you start to throw a lot of JavaScript at solving problems as the web and the capabilities of it grow. And eventually those JavaScript libraries get absorbed by the platform itself, but it’s a much slower process than creating a new JavaScript library is, because it’s standard processes and how important those are. So we saw the same thing happen with jQuery, right, where the amount of JavaScript being used on the web swelled with jQuery and jQuery plugins.

Chris: And then eventually the web platform realized that these ways of doing things are really smart and we started to get native ways to do it. And then there was this really long, slow petering off of the shift away from jQuery. So I think these libraries, as much as they’ve done a lot of… That’ll be a little controversial here and say, they’ve done a lot of damage to the web. They’ve also served an important function in paving cow path for what native APIs could look like it could do. So I don’t want to completely dismiss them as terrible.

Drew: It’s interesting that you mentioned ASTRO just a little bit earlier. I’ve actually recorded an interview with Matthew Phillips. I’m not sure if it goes out before or after this one. He’s one of the core developers on ASTRO. And it certainly is a very creative and an interesting approach to the problem. I do wonder as you saying how much this is. We’ve created a set of problems for ourselves and so now we’ve created a new solution, which patches over those problems and gives us something even better. But are we just stacking the bricks on top of each other and still ending up with a very wobbly tower because of it? Are we just going down the wrong path?

Chris: It depends. So I, as the hair on my head has started to disappear and my beard has gotten whiter, I’ve started to talk in fewer absolutes than I did. And so five years ago, I would’ve said, “Absolutely yes.” I don’t want to diminish the value of these tools in a team environment. And the other thing, I honestly think a lot of libraries really have the potential to at least patch fix in the interim is accessibility problems with the web around complex UI components. So in short, if I were to give this just a one sentence, yes, I do think in many ways we’re creating a really delicate house of cards that collapses very easily. And I think one of the nicest things about using mostly or almost entirely platform native to build for the web, so just authoring an HTML, CSS and JavaScript is, you cannot touch that code for five years and come back to it and you don’t have any dependencies to update. You don’t have any build tools to run, to start working with it again. It just works. And that’s really great.

Chris: But I think the thing I see with libraries is a lot of them come into creation to fill gaps in what the platform can do. And what I’ve noticed happens is after the platform catches up, the libraries stick around for a really long time. And so the thing I always try to do is be a little bit deliberate about what I add to the things I build, because it’s really easy to add stuff and really hard to take it away once it’s there. And just, I think to ground these heady abstract concepts, I’m talking about for a sec, every year, web aim, Web Accessibility consultancy firm does a survey of the top million sites on the web. And they run an audit, just automated audits. They’re not doing a detailed inspection of all these sites. So just stuff that, simple like robot tasks and pickup. And historically, one of the things they’ve always found is that sites that use UI rendering libraries have more accessibility issues than sites that don’t.

Chris: This year they found the same trend with one exception. Sites that use React actually have fewer accessibility issues than sites that don’t. And that is a notable trend or noticeable departure, rather from the year before when React sites had more accessibility issues.

Chris: I noticed a lot of focus on accessibility in the React community over the last year, building more accessible components, accessible routing, things of that nature. And for complex components, things like tabs and disclosure widgets, and sliders and things like that, it is really hard to do those accessibly with just HTML and Vanilla JavaScript. Trying to keep track of which ARIA attributes you need to add on, which elements and how to change them based on different behaviors and how to shift focus and announce different things is really complex. And I think these libraries as much as they can be a very delicate house of cards, I see a huge potential there to fill these gaps. Where I’d ultimately love to end up though, is in a place where the platform, the web, browsers offer native components that do those things so that you don’t need the libraries. And I think the details and summary elements provide a really nice model for what that could look like.

Chris: So if you’re listening to this and you don’t know what those are, the details element is an HTML element that you wrap around some content, and then inside it you nest a summary element with like a little description of what’s in that content. And by default, this element will be a collapsed bit of content. And when you click on the stuff in the summary, it expands and then when you click it again, it collapses and it shows a little arrow when it’s open or closed to indicate what’s happening here. It’s accessible out of the box. If the browser doesn’t support it, it shows all the content by default. So it’s just automatically progressively enhanced. You don’t need to do anything special there.

Chris: It can be styled with CSS. You can even change what the icons that display when it’s expanded and collapsed are, just with CSS. You don’t need to write any JS for it, but if you wanted to extend the behavior in some way you can, because it also exposes a JavaScript event that fires whenever it’s toggled open or closed. And I would love to see more stuff like that for tabs, for image sliders or carousels or photo galleries, which just… We have so many different interactive components now on the web that may or may not always be appropriate, but they’re in the designs and people are building them and having a way to do those things where you didn’t have to fumble through how to make them accessible or lean on a 30 kilobyte library would be awesome.

Chris: And so for me, that’s, I think, the next evolution of the web. That’s where I really want to see things start to go. And I think that’s the big need that these libraries address today in addition to some other stuff like changing the UI based on state changes and interesting use cases like that.

Drew: Yeah. Modern browsers are just so capable now and they automatically update themselves and they include many of the features natively that we’ve previously relied on, on big frameworks and build tools for. Is the requirement of a build process to deploy a project a red flag in 2021? Should HTML and CSS and JS just be deployable as it is?

Chris: So technically they are. I don’t think for most build processes that’s real or for most apps or sites or companies that’s necessarily realistic today. I don’t know that I’d call it a red flag as much as a resigned I wish it wasn’t like this, but I understand why it is, for me. Even for myself, my site has several thousand pages on it now. I think I’m up to three or four thousand pages and there’s no way I am just hand coding all those. I use a static site generator and I think tools like that can be really great.

Chris: I think there’s some challenge there in that they become things that have to be kept updated and maintained. And so I like to keep mine as lean as possible, but I think build tools that put more of the run time on you, the developer, and thus allow you to ship less to the browser are a good thing, especially as the things we build become more complex. So I don’t know that I would necessarily say it’s just by default a red flag. I think a lot of it depends on how you’re using it. If you need to run a build to ship a one or two page marketing site or brochure site, yeah, that’s a red flag. But if you’re building some complex applications and these allow you to author in a way that’s more sensical for you and then ship less stuff to the browser, that’s not a bad thing. And that’s why I find tools like ASTRO really, really interesting because there is still a build step there, but it’s a build step in the service of providing a better end user experience.

Drew: Yes. It’s shifting all that computation onto the server to build time or pre deferred time and not on page request time.

Chris: Yeah. And so for me, I almost break build steps into… Like for me, the gold standard is if I can ship it without any build step at all, that’s awesome. But even for myself, the vanilla jazz guy, that’s not how I do things a hundred percent today. And so I think the next step up is compilers that reduce your code to as much HTML and plain old JavaScript as possible, versus those that create even more JavaScript, like the ones that take a bunch of little files and make an even bigger file. So more of the former, less of the latter if possible is always a good thing, but not always possible.

Drew: I think getting off the dependency treadmill, as it were, it’s got to be a big draw to a Vanilla JavaScript approach, not having a million dependencies to be updating all the time, but I guess one of the advantages to some of these bigger frameworks is that they sometimes dictate and sometimes facilitate a uniform way of working, which is really important with larger teams. Is there a danger of a project going a bit off the rails without those standards and procedures in place that a framework imposes?

Chris: Yes. Yeah. I think that’s fair. I used to downplay, I think, the significance of this for a while. And I think that is valid. That is a fair benefit of these tools. I think that maybe the small counter argument here is if you Google, “How to do X with React,” you’re going to get half a dozen different approaches to doing that thing. So there are conventions, but there’s not necessarily hard and fast, like if you don’t do it this way, everything breaks kind of rules. One of the appeals of these tools is that they have a lot of flexibility. Certainly they do enforce more standard approaches though than just green fields, browser native things do. And so I think there’s maybe a bit of a balance, even if you don’t have a strong team lead who’s driving internal code standards.

Chris: I have seen even framework based projects go off the rails with hodgepodge approaches before. So it’s not like these tools automatically give you that, but they definitely give you some guidelines, maybe some rails that nudge you in the right direction. And I know some people need that. If that is something you need, this is where I really like that we’re seeing more of these smaller libraries that use the same conventions, like Petite Vue or Preact and compilers that also… Like FELT has some very rigid rails around it, certainly more so than you would see with ASTRO and so if you really need that, I think you have some options that don’t punish users for that need as much as what we had been doing a few years ago.

Drew: In the work that I do, we use Vue and the Vue single file components are a really compelling case for this in that we have engineers writing front-end code, who aren’t necessarily front-end specialists who say here’s a way to create a skeleton single file component. Your template goes here, your Java script goes here, your CSS goes here. And just naturally as a result of that, we end up with a very consistent code base, even though it’s been created by a very diverse set of people. And so the conventions like that can really have a big benefit to teams who aren’t necessarily all headed in the same direction because the engineering department’s so massive or whatever.

Chris: Yeah, for sure. Where I think you sometimes get into trouble with that… And I agree. I absolutely like the ability to make a code base look consistent with a bunch of different people working on it is really, really important because the people writing the code today are not necessarily going to be the ones maintaining it later. And that can get messy fast. The flip side is, if you are someone who is not comfortable or really well versed in JavaScript, a lot of the modern tool set is really geared towards JavaScript. And there are a lot of people on teams who specialize primarily in HTML or CSS or accessibility. And for them, JavaScript is not a core competency nor do I think it’s fair to expect it to be. And just like you don’t expect all your JavaScript developers to be experts in CSS.

Chris: And so it can make their job a lot harder. And this is for me, always that like that give and take with these tools is they can do some really awesome things, but they can also gate keep a lot of people out of the process. And I feel like that balance is different from team to team, but for me, one of the big arguments for leaning more on browser native stuff, or ditching as many of those dependencies as possible is that you open up your development process to a lot of people who are not as JavaScript heavy.

Drew: There’s always this undercurrent within the industry that suggests there’s the current way of doing things, the latest and there’s the outdated way. And if you’re not up to date with whatever the latest is, you’re somehow not as good an engineer or whatever.

Drew: In your estimation does taking a Vanilla JavaScript approach enable you to swim free of all that is Vanilla JS like an evergreen approach that stands apart from those techniques.

Chris: Yeah. Yeah. There’s a few threads in what you just mentioned, Drew. So one of them is, if you understand the fundamentals of the web, I have found that it’s a lot easier to like a bee, just bounce from different technology to different technology and understand it enough to like… Even if you don’t use it, look at it and be like, “Okay, I can see some benefits to this or not, and evaluate whether it’s the right choice.” If you need to dive into a new technology based on client needs or shifting direction in the company, you can. I think it’s a lot harder to do that if you only know a library and you’ve only learned the web in the context of that library.

Chris: Now the caveat here is, I learned JavaScript in the context of jQuery and then backed my way into Vanilla JavaScript, and then moved on to a bunch of other things too. The more I think about how that process went for me though, I think I was able to do that as easily as I did in large part because by the time I made that jump, ES5 had come out and had taken a bunch of its conventions from jQuery. And so there was a lot of these real one for one map. Mental map things I could do. I don’t know if we’re quite there yet with some of the state based UI libraries, but we’re definitely headed in that direction and I think that’s great. But the other thing here, there is this real pressure, as you mentioned in the industry to always keep up to date with all these new technologies, in large part because people who develop these technologies and people who work at the big companies are the ones who get invited to speak at conferences and talk about all the cool things they’ve built.

Chris: But the reality is that a lot of our web, like I’d say a majority of our web, runs on boring old technology that hasn’t been updated in a while, or has been updated, but in just a patch fix process. A lot of really important applications run on Python or PHP, or as a backend with just some sprinkling of lightweight HTML, CSS, and JavaScript on top. jQuery is still used on a lot of important stuff to the exclusion of other libraries. And it doesn’t always feel like it because I feel like most job descriptions that you see talk about wanting experience in React or Vue or something these days. But my experience from working in bigger technology companies or older product companies, is that there are a lot of jobs to be found working on old stable technology. And a lot of times it’s not always the most exciting work, but a lot of times they’re jobs that pay well and have really great hours and a lot of work life balance in a way that you won’t get in a really exciting tech company working on the latest stuff.

Chris: And so there’s these trade offs there. It’s not always a bad thing. Yeah, I think it’s one of those, like the new, new, new thing is potentially a very vocal minority of the web that’s not representative of as the web as a whole.

Drew: And there seems to be along with this idea that you should be adopting everything new and immediately casting away everything that you’ve been using for the last 12 months. There’s also this idea that you should be engineering things that are enterprise grade of engineering, but you ought to be doing every small project the way that an enormous company with 400 engineers is building things. And those two ideas actually aren’t compatible at all. It’s the big companies with all these hundreds of engineers who are using the old crusty technology, because it’s reliable and they’ve got far too much momentum. They hate to be dropping it and picking up something new. So those two ideas are indirect conflict, I think.

Chris: Yeah. It’s funny. You always see the whole like, “Well, will it scale, will it scale,” kind of thing all the time. And does it need to? Are you building things for a Facebook sized audience? I’m sure you’ll get there at… Well, you’ll get there, but it would be wonderful if you got there at some point, but like, if you’re not there today, maybe that’s not necessarily how you need to start out. Like those aren’t your needs today. You’re pre-engineering for a problem that you don’t have to the detriment of some problems that you do.

Chris: I think the other thing here is there’s this presumption that because Facebook or Google or Twitter do things, it’s a good idea, or it’s a good idea for everybody. And that’s not necessarily the case. Those companies do a lot of things right. But they also do a lot of things poorly and they do them that way because of engineering trade offs they’ve had to make because of how their teams are structured or very specific internal problems they had at the time that they made this decision or because some executive somewhere felt really strongly about something and made the internal team do it, even though it wasn’t necessarily best at the time. And then these things stick around. And so, yeah, I think one of the biggest things I see happen in our industry to our own detriment is looking at those few really big visible technology companies and thinking, “If they do it this way, I have to too,” or “That’s the right call for everybody.”

Chris: It’s that old, like no one got fired for hiring IBM kind of thing, but applied to if it’s good enough for Google or if it’s good enough for Twitter or whatever, so yeah. I agree. I think we do a lot of that and maybe that we shouldn’t.

Drew: I asked on Twitter earlier on that what frustrated people about modern web development best practices and from the responses I got, there’s certainly a lot of dissatisfaction with the current state of things. One trend, which over the last few years is getting momentum is like the Jamstack approach to building sites. And it seems on the surface that this going back to just client-side apps and nothing complex on the server, it sounds like it’s going back to basics, but is it doing that? Is it or is it just masking the complexity of the stack in a different way?

Chris: It depends. I’m a little biased here because I love the Jamstack personally, but I have also seen… Well, I shouldn’t say I have seen. I think what I’m trying to say here is the Jamstack is a term that can apply to a wide range of approaches up to and including a really large two megabyte of JavaScript single page app that has no server side rendering on one end. And then on the other end, flat HTML files that use absolutely no JavaScript at all, and instantly loading your browser and just happen to be shipped from a CDN or something like that. And technically speaking, both of those are Jamstack and are not the flat HTML thing. So Jamstack is not inherently better than server rendered, but in many cases it can be.

Chris: So for those of you who don’t know, Jamstack used to be an acronym that stood for JavaScript, APIs and markup, and they’ve since changed the spelling and changed the definition a little bit there. And it really encompasses an approach to building the web that doesn’t rely on server side rendering. So anything you’re serving, you’ve already compiled and put together and that’s what ships in the browser. And if there’s any other processing or scripting that happens, that happens in the client. Doesn’t have to, but often does. And so what I think is awesome about Jamstack if done a certain way, is it can dramatically improve the performance of the things that you’re building.

Chris: If you’re not just shipping like a metric ton of JavaScript to the client and having all the stuff that you used to do on the server happen in the browser instead, because the browser will always be less efficient at all that scripting than the server would be, but where this really comes to shine, and so I’ll use like WordPress as an example. I love WordPress. I built my career on WordPress. It’s the reason why I was able to become a developer, but every time someone visits a WordPress site out of the box, it has to make a call to a database, grabs some content, mash it into some templates, generate HTML and ship that back to the browser.

Chris: And there are some plugins you can use to do some of that ahead of time, but it is a very slow process, especially on a shared inexpensive web host. A Jamstack approach would be to have that HTML file already built, and you cut… You don’t cut the server out, but you cut all of that server processing completely out. So the HTML file already exists and gets shipped. And in an ideal world, you would even push that out to a bunch of CDNs so it sits as close to the person accessing it as possible. And what that can do is take a load time from a couple of seconds on an inexpensive host to less than half a second, because of how little computing time it takes to actually just request a file, get the file back and load it, if it’s mostly HTML.

Chris: And so, yeah, I really like rambling in long winded response to your question, Drew, but I think the answer is, if you’re using it with something like a static site generator, it can be amazingly more performant than some of the other things we’ve done in the past. And it allows you to get that same WordPress experience where I’m authoring content and I have some templates and I don’t have to hardcode HTML, but the performance is way better on one end.

Chris: And then on the other end, you could theoretically define a React app as Jamstack as well and it can be really slow and buggy and terrible. And so it depends. The other thing I’m seeing happen that’s really, really funny and interesting is we just keep reinventing PHP over and over and over again as an industry in various ways. So-

Drew: We still have PHP as well. It’s not gone.

Chris: Right? And yet PHP still exists and still works great. And so we’ve got… Like I remember when Next.js came out. There was all these kind of, “And here’s all the things you can do with it.” And I was like, “Oh, that’s like PHP,” but a decade later. And then my friend Zach Leatherman who built Eleventy which is an amazing static site generator has been experimenting with some compiling in real time on the server stuff with Eleventy.

Chris: So it’s like just in time Jamstack and he even jokes that he’s essentially recreated PHP in node and JavaScript, but it’s slightly different because there’s like a serverless build that happens that then instant deploys it to a CDN and it’s like a little weird. So it’s still a house of cards. You’re just shifting around where those cards live and who’s responsible for them, but yeah, yeah. Jamstack is cool. Jamstack is problematic. It’s also not. It’s awesome. It’s potentially overused both as a term and a technology. Yeah. It’s a whole lot of things and I love it in the same way that I love PHP. It’s great and it has problems and every technology and approach is a series of trade-offs.

Drew: Do you think we’re going through some industrial revolution in web development? What used to be skilled painstaking work from individual arts and is now high volume, high production factory output. All the machines have been brought in and the frameworks and the build tools and have we lost that hand rolled touch?

Chris: Well, I mean, yes, to an extent, but we don’t have to. I mean, that analogy is appropriate in many ways, because a lot of the ways we do things today produce… I like to call them front end pollution in the over-reliance on JavaScript, but also in the very literal sense. We have so many heavy build processes now that they generate more actual literal pollution as well. But I think the counter argument here is with a… I will use farming, right? You could go out and hand mill your wheat with a scyther. I forget what you call those. The crescent shaped tool that you use to chop your wheat, or you could use an oxen drawn machine that will pull that off, or you can use a big tractor.

Chris: And I think there’s a clear argument that at some point, factory farming is this big industrial complex that has lost a little bit of that close to the Earth touch, but I don’t think I necessarily need my farmers to be hand chopping their wheat. That is wildly inefficient for very little benefit. And there’s probably a balance there. And I feel the same thing with what we’re doing here. Some of these tools allow us to do more artisan work faster and more efficiently. And sometimes they just turn it into generating a bunch of garbage and turn it out as fast as possible. And there’s not necessarily a clear cut delineation for where that crossover happens. I think it’s a little fuzzy and gray and like a you know it when you see it kind of thing. Sometimes not always. But yeah, I think it’s a little bit of both. The commercialization of the web is both a really terrible thing and also a really great thing that has allowed folks like myself to have a living working on the platform that I love full time.

Chris: That’s awesome. But it’s also produced a lot of problems and I think that’s true for any technology. There’s good and bad that comes with all of it.

Drew: And maybe sometimes we’re just producing really fat pigs.

Chris: Yeah. I’ve gotten a lot more like, it depends as I’ve gotten older. This stuff used to really, really upset me from a purist standpoint. And I still really hate the fact that we’ve forced our users to endorse such a fragile and easily broken web. The web in general has gotten four to five times faster in the last decade. And the average website has only gotten a hundred milliseconds faster in terms of load time, because we just keep throwing more and more stuff at our users. And we could have a really fast resilient web right now if we wanted one, but we don’t. And part of that is a natural trade off for pushing the capabilities of the web further and further and that’s awesome, but I feel like sometimes we do things just because it’s shiny and new and not because it adds real benefit to folks. So I’d love to see a little bit more balance there.

Drew: Is part of the problem that we’re expecting the web to do too much? I mean, for many years we didn’t really have any great alternatives. So we enhanced and maybe over-stretched the high tech document system to behave like a software application. And now we’ve all got really powerful phones in our pockets, running a range of network connected apps. Is that the appropriate outlook for this functionality that we’re trying to build into websites? Should we just all be building apps for that case and leaving the document based stuff to be on the web?

Chris: I would argue the other direction. I think the bigger problem is… So maybe there are certain things for which I even personally I prefer like a native app over something in the web. But I think having the web do more frees you from app ecosystems and allows you as a team to build a thing and be able to reach more people with it, not have to download an app before you can access the thing you want. That’s a really cool thing. And I would argue that potentially the bigger problem is that browsers can’t keep up with the pace of the thing that we want the web to do. And that’s not a knock on the people behind the standards processes. I would not want to go back to every browser just does their own thing and the hell with it. That was awful to develop for.

Drew: It was, yeah.

Chris: We do have some of those similar problems though, just based on how the standards process works. So sometimes you’ll see Google get frustrated because they have so much in-house development power, get frustrated with other browsers that are part of that process not wanting to go along with something or not moving fast enough. And so they just… Leeroy Jenkins it and just run off and go do whatever they want to do. On the flip side you sometimes see Apple moving very, very slow because they don’t put as much investment into the web as they do other parts of their business, which is hopefully, maybe starting to change a little bit with some of the more recent hires they’ve made. But I think one of the things you run into is just the web tends to move a little slowly sometimes.

Chris: Technology moves fast, but the browsers themselves and the technologies they implement don’t always keep up. And so I don’t believe we demand too much of our browsers. I just think you get this natural ebb and flow where we demand a lot. We build a bunch of libraries to polyfill the things that we want and then when the browser eventually catches up, there’s this really slow, petering off as library usage for that particular stuff drops off.

Chris: Yeah. But I don’t know that I would say we demand too much of the web. Yeah, I don’t know. I actually, I love all the things the web can do. I think it’s really, for me, it’s what’s so exciting about the web. I think my frustration is more just with how slow some of these technologies are to come out, particularly on iOS devices. And I say this as someone who, I love my iPhone, but progressive web apps continue to be a second… They just don’t get as much priority as native apps do on that platform, which is disappointing.

Drew: So looking to the future on that note, what should we, as a development community be working on to fix some of these issues? Where should we be placing our efforts?

Chris: Yeah. So I think there are a few different things. And I think some of the tools we’ve talked about, I don’t think they’ll ever necessarily go away. They might change in form a little bit, but so I already see some cool things on the horizon. One of the things people love about single page apps that we’ve never been able to do with, I call them multistage apps, but they’re really just plain old webpages is like the nice transitions that happen between views where you might like fade in, fade out, or something like that.

Chris: There’s a native API in the works that’s going to make that a lot easier. That’s awesome. There’s also a native API in the works for HTML sanitization. So one of the big things that libraries do for you is they, when you’re rendering HTML from third party data, they have some libraries baked in that will help reduce your risk of cross-site scripting attacks.

Chris: There’s not really a good, just native way to do that, but there’s one in the works that will make that a lot easier. And even if you continue to use state based libraries, that should allow them to strip a bunch of code out and that would be an awesome thing.

Chris: One thing that the native web can’t do yet that would be really cool, is a way to handle DOM dipping so that if you want to build some HTML based on a JavaScript object and then update it as the object changes, it would be really cool if you didn’t have to rely on a library for that. And that there was maybe a performant out of the box way to do that in the browser. I think that would solve a lot of problems. As well as more accessible interactive components. I absolutely love when HTML and CSS can replace something I used to need JavaScript for. Doesn’t need to be as rigorously tested, way more fault tolerant, less likely to break, more performant all around. It’s a net win. And so I’d love to see more of those come to the platform.

Chris: So from a browser native thing there’s that. And then the other big thing I think we’re going to start to see more of is a shift away from client-side libraries and a shift to more pre-compiled stuff. Whether that’s static side generators, something like ASTRO that still uses JavaScript libraries, but pre renders them instead of making the browser do it. But those are the, I think, the big things I’m seeing start to happen and I think we’re going to see more and more of.

Drew: So you saying maybe it’s not all doom and gloom and perhaps we can fix this? There’s a way out?

Chris: No, yeah, I see us emerging from the dark ages slowly. And what I think is going to happen is we’re going to hit a point where much like where today people are like, “Why does everybody still use React?” I can imagine in 7 to 10 years time, we’re going to be like, “Why does anybody…” I’m sorry. Not React. jQuery. “Why does everybody still use jQuery?” We’re going to see the same thing with React and Vue. Like, “Why does everybody still start a project with those?” And there’s going to be some new libraries that are starting to emerge to solve a whole new set of problems that we haven’t even dreamed of today.

Drew: One comment from Twitter that I really identified with was from Amy Pellegrini, who said, “Every time I update something, everything gets broken.” Yep. I just think we’ve all been there, haven’t we?

Chris: Yeah. I unfortunately don’t think that will ever fully go away because even in the non-build tool era of jQuery, we used to just load it with a script element. You would run into situations where different versions would be incompatible with each other. And so you’d drop a plug in into your site and it would be like, “Sorry, you’re running jQuery 1.83, and this requires 1.89 or higher because it added this new…” And so there’s always been some version of that. I think it’s a lot more pronounced now because so much of it happens in the command line and spits out all these terrible errors that don’t make sense. But yeah, that unfortunately I don’t think will ever go away. I feel the pain though. That one, it’s a big part of the reason why I try and use as few dependencies as possible.

Drew: Me too. Me too. So I’ve been learning all about the lean web or learning more about the lean web than our conversation. What have you been learning about lately, Chris?

Chris: Yeah. Great question. So I have been going deep on service workers in part because I love their ability to both make the web faster, or even if you’re not building a progressive web app, they’re just really, really cool. One of the things I’ve absolutely loved them for though is they allow me to build a single page app like experience in terms of performance, without all the complexity of having to handle JavaScript routing and stuff. So I can have a multipage app, cache my API calls for a short period of time without having to cache them in memory. And so I’ve been able to do some really cool things with them. And then the other thing I’ve been learning a lot about lately is serverless, which allows me to get the benefits of having some server-side code without having to actually manage a server, which is great.

Chris: And so I went really, really deep on those, put together a couple of courses on both of those topics as well, but they have benefited me immensely in my own work, in particular service workers, which has been amazing. I’m obsessed with them. Recommend them for everybody.

Drew: That’s amazing. And where can people find those courses that you put together on?

Chris: So if you go to, you can dig into those and a whole bunch of other courses as well.

Drew: Amazing. If you dear listener would like to hear more from Chris, you can find his book on the web at and his developer tips newsletter, which I believe now gets over 12,000 subscribers-

Chris: Yeah. Up a little bit from the last time we chatted.

Drew: Yeah. That’s at Chris is on twitter @chrisferdinandi. And you can check out his podcast at or wherever you usually get your podcasts from. Thanks for joining us today, Chris. Do you have any parting words?

Chris: No, that was a really great summary, Drew. Thank you so much. You hit all the key links. So thanks so much for having me. This was great.

Reblogged 1 day ago from

Google December 2021 product reviews update is rolling out now

The update will take about three weeks to fully rollout, Google said.

Please visit Search Engine Land for the full article.

Reblogged 1 day ago from

Google Merchant Center now shows relative visibility, page overlap rate and higher position rate metrics

The new Competitive visibility report can help merchants get a more defined view of their reach across Shopping ads and free listings, who their competitors are and how visible their offers are compared to their competitors.

Please visit Search Engine Land for the full article.

Reblogged 2 days ago from