Can Good UX Protect Older Users From Digital Scams?
Can Good UX Protect Older Users From Digital Scams? Can Good UX Protect Older Users From Digital Scams? Carrie Webster 2025-06-25T12:00:00+00:00 2025-06-25T15:04:30+00:00 A few years ago, my mum, who is in her 80s and not tech-savvy, almost got scammed. She received an email from what […]
Accessibility
Meet Accessible UX Research, A Brand-New Smashing Book
Meet Accessible UX Research, A Brand-New Smashing Book Meet Accessible UX Research, A Brand-New Smashing Book Vitaly Friedman 2025-06-20T16:00:00+00:00 2025-06-25T15:04:30+00:00 UX research can take so much of the guesswork out of the design process! But it’s easy to forget just how different people are and […]
Accessibility
What I Wish Someone Told Me When I Was Getting Into ARIA
What I Wish Someone Told Me When I Was Getting Into ARIA What I Wish Someone Told Me When I Was Getting Into ARIA Eric Bailey 2025-06-16T13:00:00+00:00 2025-06-25T15:04:30+00:00 If you haven’t encountered ARIA before, great! It’s a chance to learn something new and exciting. If […]
Accessibility
The End Of My Gatsby Journey
The End Of My Gatsby Journey The End Of My Gatsby Journey Juan Diego Rodríguez 2024-03-06T08:00:00+00:00 2025-06-25T15:04:30+00:00 A fun fact about me is that my birthday is on Valentine’s Day. This year, I wanted to celebrate by launching a simple website that lets people receive […]
Accessibility
The End Of My Gatsby Journey
Juan Diego Rodríguez 2024-03-06T08:00:00+00:00
2025-06-25T15:04:30+00:00
A fun fact about me is that my birthday is on Valentine’s Day. This year, I wanted to celebrate by launching a simple website that lets people receive anonymous letters through a personal link. The idea came up to me at the beginning of February, so I wanted to finish the project as soon as possible since time was of the essence.
Having that in mind, I decided not to do SSR/SSG with Gatsby for the project but rather go with a single-page application (SPA) using Vite and React — a rather hard decision considering my extensive experience with Gatsby. Years ago, when I started using React and learning more and more about today’s intricate web landscape, I picked up Gatsby.js as my render framework of choice because SSR/SSG was necessary for every website, right?
I used it for everything, from the most basic website to the most over-engineered project. I absolutely loved it and thought it was the best tool, and I was incredibly confident in my decision since I was getting perfect Lighthouse scores in the process.
The years passed, and I found myself constantly fighting with Gatsby plugins, resorting to hacky solutions for them and even spending more time waiting for the server to start. It felt like I was fixing more than making. I even started a series for this magazine all about the “Gatsby headaches” I experienced most and how to overcome them.
It was like Gatsby got tougher to use with time because of lots of unaddressed issues: outdated dependencies, cold starts, slow builds, and stale plugins, to name a few. Starting a Gatsby project became tedious for me, and perfect Lighthouse scores couldn’t make up for that.
So, I’ve decided to stop using Gatsby as my go-to framework.
To my surprise, the Vite + React combination I mentioned earlier turned out to be a lot more efficient than I expected while maintaining almost the same great performance measures as Gatsby. It’s a hard conclusion to stomach after years of Gatsby’s loyalty.
I mean, I still think Gatsby is extremely useful for plenty of projects, and I plan on talking about those in a bit. But Gatsby has undergone a series of recent unfortunate events after Netlify acquired it, the impacts of which can be seen in down-trending results from the most recent State of JavaScript survey. The likelihood of a developer picking up Gatsby again after using it for other projects plummeted from 89% to a meager 38% between 2019 and 2022 alone.
Although Gatsby was still the second most-used rendering framework as recently as 2022 — we are still expecting results from the 2023 survey — my prediction is that the decline will continue and dip well below 38%.
Seeing as this is my personal farewell to Gatsby, I wanted to write about where, in my opinion, it went wrong, where it is still useful, and how I am handling my future projects.
Gatsby: A Retrospective
Kyle Mathews started working on what would eventually become Gatsby in late 2015. Thanks to its unique data layer and SSG approach, it was hyped for success and achieved a $3.8 million funding seed round in 2018. Despite initial doubts, Gatsby remained steadfast in its commitment and became a frontrunner in the Jamstack community by consistently enhancing its open-source framework and bringing new and better changes with each version.
So… where did it all go wrong?
I’d say it was the introduction of Gatsby Cloud in 2019, as Gatsby aimed at generating continuous revenue and solidifying its business model. Many (myself included) pinpoint Gatsby’s downfall to Gatsby Cloud, as it would end up cutting resources from the main framework and even making it harder to host in other cloud providers.
The core framework had been optimized in a way that using Gatsby and Gatsby Cloud together required no additional hosting configurations, which, as a consequence, made deployments in other platforms much more difficult, both by neglecting to provide documentation for third-party deployments and by releasing exclusive features, like incremental builds, that were only available to Gatsby users who had committed to using Gatsby Cloud. In short, hosting projects on anything but Gatsby Cloud felt like a penalty.
As a framework, Gatsby lost users to Next.js, as shown in both surveys and npm trends, while Gatsby Cloud struggled to compete with the likes of Vercel and Netlify; the former acquiring Gatsby in February of 2023.
“It [was] clear after a while that [Gatsby] weren’t winning the framework battle against Vercel, as a general purpose framework […] And they were probably a bit boxed in by us in terms of building a cloud platform.”
— Matt Biilmann, Netlify CEO
The Netlify acquisition was the last straw in an already tumbling framework haystack. The migration from Gatsby Cloud to Netlify wasn’t pretty for customers either; some teams were charged 120% more — or had incurred extraneous fees — after converting from Gatsby Cloud to Netlify, even with the same Gatsby Cloud plan they had! Many key Gatsby Cloud features, specifically incremental builds that reduced build times of small changes from minutes to seconds, were simply no longer available in Netlify, despite Kyle Mathews saying they would be ported over to Netlify:
“Many performance innovations specifically for large, content-heavy websites, preview, and collaboration workflows, will be incorporated into the Netlify platform and, where relevant, made available across frameworks.”
— Kyle Mathews
However, in a Netlify forum thread dated August 2023, a mere six months after the acquisition, a Netlify support engineer contradicted Mathews’s statement, saying there were no plans to add incremental features in Netlify.
That left no significant reason to remain with Gatsby. And I think this comment on the same thread perfectly sums up the community’s collective sentiment:
“Yikes. Huge blow to Gatsby Cloud customers. The incremental build speed was exactly why we switched from Netlify to Gatsby Cloud in the first place. It’s really unfortunate to be forced to migrate while simultaneously introducing a huge regression in performance and experience.”
Netlify’s acquisition also brought about a company restructuring that substantially reduced the headcount of Gatsby’s engineering team, followed by a complete stop in commit activities. A report in an ominous tweet by Astro co-founder Fred Schott further exacerbated concerns about Gatsby’s future.
Lennart Jörgens, former full-stack developer at Gatsby and Netlify, replied, insinuating there was only one person left after the layoffs:
You can see all these factors contributing to Gatsby’s usage downfall in the 2023 Stack Overflow survey.
Biilmann addressed the community’s concerns about Gatsby’s viability in an open issue from the Gatsby repository:
“While we don’t plan for Gatsby to be where the main innovation in the framework ecosystem takes place, it will be a safe, robust and reliable choice to build production quality websites and e-commerce stores, and will gain new powers by ways of great complementary tools.”
— Matt Biilmann
He also shed light on Gatsby’s future focus:
- “First, ensure stability, predictability, and good performance.
- Second, give it new powers by strong integration with all new tooling that we add to our Composable Web Platform (for more on what’s all that, you can check out our homepage).
- Third, make Gatsby more open by decoupling some parts of it that were closely tied to proprietary cloud infrastructure. The already-released Adapters feature is part of that effort.”
— Matt Biilmann
So, Gatsby gave up competing against Next.js on innovation, and instead, it will focus on keeping the existing framework clean and steady in its current state. Frankly, this seems like the most reasonable course of action considering today’s state of affairs.
Why Did People Stop Using Gatsby?
Yes, Gatsby Cloud ended abruptly, but as a framework independent of its cloud provider, other aspects encouraged developers to look for alternatives to Gatsby.
As far as I am concerned, Gatsby’s developer experience (DX) became more of a burden than a help, and there are two main culprits where I lay the blame: dependency hell and slow bundling times.
Dependency Hell
Go ahead and start a new Gatsby project:
gatsby new
After waiting a couple of minutes you will get your brand new Gatsby site. You’d rightly expect to have a clean slate with zero vulnerabilities and outdated dependencies with this out-of-the-box setup, but here’s what you will find in the terminal once you run npm audit:
18 vulnerabilities (11 moderate, 6 high, 1 critical)
That looks concerning — and it is — not so much from a security perspective but as an indication of decaying DX. As a static site generator (SSG), Gatsby will, unsurprisingly, deliver a static and safe site that (normally) doesn’t have access to a database or server, making it immune to most cyber attacks. Besides, lots of those vulnerabilities are in the developer tools and never reach the end user. Alas, relying on npm audit to assess your site security is a naive choice at best.
However, those vulnerabilities reveal an underlying issue: the whopping number of dependencies Gatsby uses is 168(!) at the time I’m writing this. For the sake of comparison, Next.js uses 16 dependencies. A lot of Gatsby’s dependencies are outdated, hence the warnings, but trying to update them to their latest versions will likely unleash a dependency hell full of additional npm warnings and errors.
In a related subreddit from 2022, a user asked, “Is it possible to have a Gatsby site without vulnerabilities?”
The real answer is disappointing, but as of March 2024, it remains true.
A Gatsby site should work completely fine, even with that many dependencies, and extending your project shouldn’t be a problem, whether through its plugin ecosystem or other packages. However, when trying to upgrade any existing dependency you will find that you can’t! Or at least you can’t do it without introducing breaking changes to one of the 168 dependencies, many of which rely on outdated versions of other libraries that also cannot be updated.
It’s that inception-like roundabout of dependencies that I call dependency hell.
Slow Build And Development Times
To me, one of the most important aspects of choosing a development tool is how comfortable it feels to use it and how fast it is to get a project up and running. As I’ve said before, users don’t care or know what a “tech stack” is or what framework is in use; they want a good-looking website that helps them achieve the task they came for. Many developers don’t even question what tech stack is used on each site they visit; at least, I hope not.
With that in mind, choosing a framework boils down to how efficiently you can use it. If your development server constantly experiences cold starts and crashes and is unable to quickly reflect changes, that’s a poor DX and a signal that there may be a better option.
That’s the main reason I won’t automatically reach for Gatsby from here on out. Installation is no longer a trivial task; the dependencies are firing off warnings, and it takes the development server upwards of 30 seconds to boot. I’ve even found that the longer the server runs, the slower it gets; this happens constantly to me, though I admittedly have not heard similar gripes from other developers. Regardless, I get infuriated having to constantly restart my development server every time I make a change to gatsby-config.js, gatsby-node.js files, or any other data source.
This new reality is particularly painful, knowing that a Vite.js + React setup can start a server within 500ms thanks to the use of esbuild.
Running gatsby build gets worse. Build times for larger projects normally take some number of minutes, which is understandable when we consider all of the pages, data sources, and optimizations Gatsby does behind the scenes. However, even a small content edit to a page triggers a full build and deployment process, and the endless waiting is not only exhausting but downright distracting for getting things done. That’s what incremental builds were designed to solve and the reason many people switched from Netlify to Gatsby Cloud when using Gatsby. It’s a shame we no longer have that as an available option.
The moment Gatsby Cloud was discontinued along with incremental builds, the incentives for continuing to use Gatsby became pretty much non-existent. The slow build times are simply too costly to the development workflow.
What Gatsby Did Awesomely Well
I still believe that Gatsby has awesome things that other rendering frameworks don’t, and that’s why I will keep using it, albeit for specific cases, such as my personal website. It just isn’t my go-to framework for everything, mainly because Gatsby (and the Jamstack) wasn’t meant for every project, even if Gatsby was marketed as a general-purpose framework.
Here’s where I see Gatsby still leading the competition:
- The GraphQL data layer.
In Gatsby, all the configured data is available in the same place, a data layer that’s easy to access using GraphQL queries in any part of your project. This is by far the best Gatsby feature, and it trivializes the process of building static pages from data, e.g., a blog from a content management system API or documentation from Markdown files. - Client performance.
While Gatsby’s developer experience is questionable, I believe it delivers one of the best user experiences for navigating a website. Static pages and assets deliver the fastest possible load times, and using React Router with pre-rendering of proximate links offers one of the smoothest experiences navigating between pages. We also have to note Gatsby’s amazing image API, which optimizes images to all extents. - The plugin ecosystem (kinda).
There is typically a Gatsby plugin for everything. This is awesome when using a CMS as a data source since you could just install its specific plugin and have all the necessary data in your data layer. However, a lot of plugins went unmaintained and grew outdated, introducing unsolvable dependency issues that come with dependency hell.
I briefly glossed over the good parts of Gatsby in contrast to the bad parts. Does that mean that Gatsby has more bad parts? Absolutely not; you just won’t find the bad parts in any documentation. The bad parts also aren’t deal breakers in isolation, but they snowball into a tedious and lengthy developer experience that pushes away its advocates to other solutions or rendering frameworks.
Do We Need SSR/SSG For Everything?
I’ll go on record saying that I am not replacing Gatsby with another rendering framework, like Next.js or Remix, but just avoiding them altogether. I’ve found they aren’t actually needed in a lot of cases.
Think, why do we use any type of rendering framework in the first place? I’d say it’s for two main reasons: crawling bots and initial loading time.
SEO And Crawling Bots
Most React apps start with a hollow body, only having an empty <div> alongside <script> tags. The JavaScript code then runs in the browser, where React creates the Virtual DOM and injects the rendered user interface into the browser.
Over slow networks, users may notice a white screen before the page is actually rendered, which is just mildly annoying at best (but devastating at worst).
However, search engines like Google and Bing deploy bots that only see an empty page and decide not to crawl the content. Or, if you are linking up a post on social media, you may not get OpenGraph benefits like a link preview.
<body>
<div id="root"></div>
<script type="module" src="/src/main.tsx"></script>
</body>
This was the case years ago, making SSR/SSG necessary for getting noticed by Google bots. Nowadays, Google can run JavaScript and render the content to crawl your website. While using SSR or SSG does make this process faster, not all bots can run JavaScript. It’s a tradeoff you can make for a lot of projects and one you can minimize on your cloud provider by pre-rendering your content.
Initial Loading Time
Pre-rendered pages load faster since they deliver static content that relieves the browser from having to run expensive JavaScript.
It’s especially useful when loading pages that are behind authentication; in a client-side rendered (CSR) page, we would need to display a loading state while we check if the user is logged in, while an SSR page can perform the check on the server and send back the correct static content. I have found, however, that this trade-off is an uncompelling argument for using a rendering framework over a CSR React app.
In any case, my SPA built on React + Vite.js gave me a perfect Lighthouse score for the landing page. Pages that fetch data behind authentication resulted in near-perfect Core Web Vitals scores.
What Projects Gatsby Is Still Good For
Gatsby and rendering frameworks are excellent for programmatically creating pages from data and, specifically, for blogs, e-commerce, and documentation.
Don’t be disappointed, though, if it isn’t the right tool for every use case, as that is akin to blaming a screwdriver for not being a good hammer. It still has good uses, though fewer than it could due to all the reasons we discussed before.
But Gatsby is still a useful tool. If you are a Gatsby developer the main reason you’d reach for it is because you know Gatsby. Not using it might be considered an opportunity cost in economic terms:
“Opportunity cost is the value of the next-best alternative when a decision is made; it’s what is given up.”
Imagine a student who spends an hour and $30 attending a yoga class the evening before a deadline. The opportunity cost encompasses the time that could have been dedicated to completing the project and the $30 that could have been used for future expenses.
As a Gatsby developer, I could start a new project using another rendering framework like Next.js. Even if Next.js has faster server starts, I would need to factor in my learning curve to use it as efficiently as I do Gatsby. That’s why, for my latest project, I decided to avoid rendering frameworks altogether and use Vite.js + React — I wanted to avoid the opportunity cost that comes with spending time learning how to use an “unfamiliar” framework.
Conclusion
So, is Gatsby dead? Not at all, or at least I don’t think Netlify will let it go away any time soon. The acquisition and subsequent changes to Gatsby Cloud may have taken a massive toll on the core framework, but Gatsby is very much still breathing, even if the current slow commits pushed to the repo look like it’s barely alive or hibernating.
I will most likely stick to Vite.js + React for my future endeavors and only use rendering frameworks when I actually need them. What are the tradeoffs? Sacrificing negligible page performance in favor of a faster and more pleasant DX that maintains my sanity? I’ll take that deal every day.
And, of course, this is my experience as a long-time Gatsby loyalist. Your experience is likely to differ, so the mileage of everything I’m saying may vary depending on your background using Gatsby on your own projects.
That’s why I’d love for you to comment below: if you see it differently, please tell me! Is your current experience using Gatsby different, better, or worse than it was a year ago? What’s different to you, if anything? It would be awesome to get other perspectives in here, perhaps from someone who has been involved in maintaining the framework.
Further Reading On SmashingMag
- Gatsby Headaches And How To Cure Them: i18n (Part 1)
- Gatsby Headaches And How To Cure Them: i18n (Part 2)
- Gatsby Headaches: Working With Media (Part 1)
- Gatsby Headaches: Working With Media (Part 2)
(gg, yk)
A Designer’s Accessibility Advocacy Toolkit
A Designer’s Accessibility Advocacy Toolkit A Designer’s Accessibility Advocacy Toolkit Yichan Wang 2024-02-26T18:00:00+00:00 2025-06-25T15:04:30+00:00 Web accessibility can be challenging, particularly for clients unfamiliar with tech or compliance with The Americans With Disabilities Act (ADA). My role as a digital designer often involves guiding clients toward […]
Accessibility
A Designer’s Accessibility Advocacy Toolkit
Yichan Wang 2024-02-26T18:00:00+00:00
2025-06-25T15:04:30+00:00
Web accessibility can be challenging, particularly for clients unfamiliar with tech or compliance with The Americans With Disabilities Act (ADA). My role as a digital designer often involves guiding clients toward ADA-compliant web designs. I’ve acquired many strategies over the years for encouraging clients to adopt accessible web practices and invest in accessible user interfaces. It’s something that comes up with nearly every new project, and I decided to develop a personal toolkit to help me make the case.
Now, I am opening up my toolkit for you to have and use. While some of the strategies may be specific to me and my work, there are plenty more that cast a wider net and are more universally applicable. I’ve considered different real-life scenarios where I have had to make a case for accessibility. You may even personally identify with a few of them!
Please enjoy. As you do, remember that there is no silver bullet for “selling” accessibility. We can’t win everyone over with cajoling or terse arguments. My hope is that you are able to use this collection to establish partnerships with your colleagues and clients alike. Accessibility is something that anyone can influence at various stages in a project, and “winning” an argument isn’t exactly the point. It’s a bigger picture we’re after, one that influences how teams work together, changes habits, and develops a new level of empathy and understanding.
I begin with general strategies for discussing accessibility with clients. Following that, I provide specific language and responses you can use to introduce accessibility practices to your team and clients and advocate its importance while addressing client skepticism and concerns. Use it as a starting point and build off of it so that it incorporates points and scenarios that are more specific to your work. I sincerely hope it helps you advance accessible practices.
General Strategies
We’ll start with a few ways you can position yourself when interacting with clients. By adopting a certain posture, we can set ourselves up to be the experts in the room, the ones with solutions rather than arguments.
Showcasing Expertise
I tend to establish my expertise and tailor the information to the client’s understanding of accessibility, which could be not very much. For those new to accessibility, I offer a concise overview of its definition, evaluation, and business impact. For clients with a better grasp of accessible practices, I like to use the WCAG as a point of reference for helping frame productive discussions based on substance and real requirements.
Aligning With Client Goals
I connect accessibility to the client’s goals instead of presenting accessibility as a moral imperative. No one loves being told what to do, and talking to clients on their terms establishes a nice bridge for helping them connect the dots between the inherent benefits of accessible practices and what they are trying to accomplish. The two aren’t mutually exclusive!
In fact, there are many clear benefits for apps that make accessibility a first-class feature. Refer to the “Accessibility Benefits” section to help describe those benefits to your colleagues and clients.
Defining Accessibility In The Project Scope
I outline accessibility goals early, typically when defining the project scope and requirements. Baking accessibility into the project scope ensures that it is at least considered at this crucial stage where decisions are being made for everything from expected outcomes to architectural requirements.
User stories and personas are common artifacts for which designers are often responsible. Use these as opportunities to define accessibility in the same breath as defining who the users are and how they interact with the app. Framing stories and outcomes as user interactions in an “as-when-then-so” format provides an opening to lead with accessibility:
As a user, when I __________, then I expect that __________, so I can _________.
Fill in the blanks. I think you’ll find that user’s expected outcomes are typically aligned with accessible experiences. Federico Francioni published his take on developing inclusive user personas, building off other excellent resources, including Microsoft’s Inclusive Design guidelines.
Being Ready With Resources and Examples
I maintain a database of resources for clients interested in learning more about accessibility. Sharing anecdotes, such as clients who’ve seen benefits from accessibility or examples of companies penalized for non-compliance, can be very impactful.
Microsoft is helpful here once again with a collection of brief videos that cover a variety of uses, from informing your colleagues and clients on basic accessibility concepts to interviews with accessibility professionals and case studies involving real users.
There are a few go-to resources I’ve bookmarked to share with clients who are learning about accessibility for the first time. What I like about these is the approachable language and clarity. “Learn Accessibility” from web.dev is especially useful because it’s framed as a 21-part course. That may sound daunting, but it’s organized in small chunks that make it manageable, and sometimes I will simply point to the Glossary to help clients understand the concepts we discuss.
And where “Learn Accessibility” is focused on specific components of accessibility, I find that the Inclusive Design Principles site has a perfect presentation of the concepts and guiding principles of inclusion and accessibility on the web.
Meanwhile, I tend to sit beside a client to look at The A11Y Project. I pick a few resources to go through. Otherwise, the amount of information can be overwhelming. I like to offer this during a project’s planning phase because the site is focused on actionable strategies that help scope work.
- Web Accessibility: The Ultimate Guide (Kristen Baker)
- Learn Accessibility (web.dev)
- Inclusive Design Principles (Swan, Pouncy, Pickering, and Watson)
- The A11Y Project
- WebAIM Resources
- Accessibility Resources GitHub Repository (Ian Routledge)
Leveraging User Research
User research that is specific to the client’s target audience is more convincing than general statistics alone. When possible, I try to understand those user’s needs, including what they expect, what sort of technology they use to browse online, and where they are geographically. Painting a more complete picture of users — based on real-life factors and information — offers a more human perspective and plants the first seeds of empathy in the design process.
Web analytics are great for identifying who users are and how they currently interact with the app. At the same time, they are also wrought with caveats as far as accuracy goes, depending on the tool you use and how you collect your data. That said, I use the information to support my user persona decisions and the specific requirements I write. Analytics add nice brush strokes to the picture but do not paint the entire view. So, leverage it!
The big caveat with web analytics? There’s no way to identify traffic that uses assistive tech. That’s a good thing in general as far as privacy goes, but it does mean that researching the usability of your site is best done with real users — as it is with any user research, really. The A11Y Project has excellent resources for testing screen readers, including a link to this Smashing Magazine article about manual accessibility testing by Eric Bailey as well as a vast archive of links pointing to other research.
That said, web analytics can still be very useful to help accommodate other impairments, for example, segmenting traffic by age (for improving accessibility for low vision) and geography (for improving performance gaps for those on low-powered devices). WebAIM also provides insights in a report they produced from a 2018 survey of users who report having low vision.
Leaving Room For Improvements
Chances are that your project will fall at least somewhat short of your accessibility plans. It happens! I see plenty of situations where a late deadline translates into rushed work that sacrifices quality for speed, and accessibility typically falls victim to degraded quality.
I keep track of these during the project’s various stages and attempt to document them. This way, there’s already a roadmap for inclusive and accessible improvements in subsequent releases. It’s scoped, backlogged, and ready to drop into a sprint.
For projects involving large sites with numerous accessibility issues, I emphasize that partial accessibility compliance is not the same as actual compliance. I often propose phased solutions, starting with incremental changes that fit within the current scope and budget.
And remember, just because something passes a WCAG success criterion doesn’t necessarily mean it is accessible. Passing tests is a good sign, but there will always be room for improvement.
Commonly Asked Accessibility Questions
Accessibility is a broad topic, and we can’t assume that everyone knows what constitutes an “accessible” interface. Often, when I get pushback from a colleague or client, it’s because they simply do not have the same context that I do. That’s why I like to keep a handful of answers to commonly asked questions in my back pocket. It’s amazing how answering the “basics” leads to productive discussions filled with substance rather than ones grounded in opinion.
What Do We Mean By “Web Accessibility”?
When we say “web accessibility,” we’re generally talking about making online content available and usable for anyone with a disability, whether it’s a permanent impairment or a temporary one. It’s the practice of removing friction that excludes people from gaining access to content or from completing a task. That usually involves complying with a set of guidelines that are designed to remove those barriers.
Who Creates Accessibility Guidelines?
The Web Content Accessibility Guidelines (WCAG) are created by a working group of the World Wide Web Consortium (W3C) called the Web Accessibility Initiative (WAI). The W3C develops guidelines and principles to help designers, developers, and authors like us create web experiences based on a common set of standards, including those for HTML, CSS, internationalization, privacy, security, and yes, accessibility, among many, many other areas. The WAI working group maintains the accessibility standards we call WCAG.
Who Needs Web Accessibility?
Twenty-seven percent of the U.S. population has a disability, emphasizing the widespread need for accessible web design. WCAG primarily focuses on three groups:
- Cognitive or learning disabilities,
- Visual impairments,
- Motor skills.
When we make web experiences that solve these issues based on established guidelines, we’re not only doing good for those who are directly impacted by impairment but those who may be impaired in less direct ways as well, such as establishing large target sizes for those tapping a touchscreen phone with their hands full, or using proper color contrast for those navigating a screen in bright sunlight. Everyone needs — and benefits from — accessibility!
Further Reading
- Disability Impacts All of Us (Center for Disease Control and Prevention)
- Inclusive persona extension (Kaz Tsuchiya)
- Situational Disabilities: Why Web Accessibility Impacts Everyone (Bureau of Internet Accessibility)
How Is Web Accessibility Regulated?
The Americans with Disabilities Act (ADA) is regulated by the Civil Rights Division of the U.S. Department of Justice, which was established by the Civil Rights Act of 1957. Even though there is a lot of bureaucracy in that last sentence, it’s reassuring to know the U.S. government not only believes in web accessibility but enforces it as well.
Non-compliance can result in legal action, with first-time ADA violations leading to fines of up to $75,000, increasing to $150,000 for subsequent violations. The number of lawsuits for alleged ADA breaches has surged in recent years, with more than 4,500 lawsuits filed in 2023 against sites that fail to comply with WCAG AA 2.1 alone — roughly 500 more lawsuits than 2022!
Further Reading
- Information and Technical Assistance on the Americans with Disabilities Act (ADA.gov)
- Five years of ADA web and app lawsuits — key observations and trends (UsableNet)
- ADA Website Compliance Lawsuit Tracker (UsableNet)
- National Federation of the Blind v. Target Corporation (Southeast ADA Center)
How Is Web Accessibility Evaluated?
Web accessibility is something we can test against. Many tools have been created to audit sites on the spot based on WCAG success criteria that specify accessible requirements. That would be a standards-based evaluation using WCAG as a reference point for auditing compliance.
WebAIM has an excellent page that compares different types of accessibility testing, reporting, and tooling. They are also quick to note that automated testing, while convenient, is not a comprehensive way to audit accessibility. Automated tools that scan websites may be able to pick up instances where mistakes in the HTML might contribute to accessibility issues and where color contrasts are insufficient. But they cannot replace or perfectly imitate a real-life person. Testing in real browsers with real people continues to be the most effective way to truly evaluate accessible web experiences.
This isn’t to say automated tools should not be part of an accessibility testing suite. In fact, they often highlight areas you may have overlooked. Even false positives are good in the sense that they force you to pause and look more closely at something. Some of the most widely used automated tools include the following:
- WAVE (free)
- WebAIM Contrast Checker (free)
- axe (paid)
- Polypane (paid)
These are just a few of the most frequent tools I use in my own testing, but there are many more, and the WAI maintains an extensive list of available tools that are worth considering. But again, remember that automated testing is not a one-to-one replacement for testing with real users.
Checklists can be handy for ensuring you are covering your bases:
- WCAG 2.1 and 2.2 AA Checklist (Raghavendra Satish Peri)
- How to Meet WCAG (Quick Reference) (W3C)
- WCAG 2.2 Checklist with Filter and Links on CodePen (Web Overhauls)
Accessibility Benefits
When discussing accessibility, I find the most effective arguments are ones that are framed around the interests of clients and stakeholders. That way, the discussion stays within scope and helps everyone see that proper accessibility practices actually benefit business goals. Speaking in business terms is something I openly embrace because it typically supports my case.
The following are a few ways I would like to explain the positive impacts that accessibility has on business goals.
Case Studies
Sometimes, the most convincing approach is to offer examples of companies that have committed to accessible practices and come out better for it. And there are plenty of examples! I like to use case studies and reports in a similar industry or market for a more apples-to-apples comparison that stakeholders can identify with.
That said, there are great general cases involving widely respected companies and brands, including This American Life and Tesco, that demonstrate benefits such as increased organic search traffic, enhanced user engagement, and reduced site load times. For a comprehensive guide on framing these benefits, I refer to the W3C’s resource on building the business case for accessibility.
What To Say To Your Client
Let me share how focusing on accessibility can directly benefit your business. For instance, in 2005, Legal & General revamped their website with accessibility in mind and saw a substantial increase in organic search traffic exceeding 50%. This isn’t just about compliance; it’s about reaching a wider audience more effectively. By making your site more accessible, we can improve user engagement and potentially decrease load times, enhancing the overall user experience. This approach not only broadens your reach to include users with disabilities but also boosts your site’s performance in search rankings. In short, prioritizing accessibility aligns with your goal to increase online visibility and customer engagement.
Further Reading
- The Business Case for Digital Accessibility (W3C)
- Barclays Bank Case Study (W3C)
- 6 companies that boosted business with accessibility (Scope)
- Great Customer Service is Accessible: Help Scout’s Audit Journey with Deque (Deque)
- How Microsoft Unlocked Inclusivity To Drive Growth And Innovation (Forbes)
- This American Life: A Case Study on How Transcription Boosts Podcast SEO and Engagement (3Play Media)
- When it comes to accessibility, Apple continues to lead in awareness and innovation (TechCrunch)
The Curb-Cut Effect
The “curb-cut effect” refers to how features originally designed for accessibility end up benefiting a broader audience. This concept helps move the conversation away from limiting accessibility as an issue that only affects the minority.
Features like voice control, auto-complete, and auto-captions — initially created to enhance accessibility — have become widely used and appreciated by all users. This effect also includes situational impairments, like using a phone in bright sunlight or with one hand, expanding the scope of who benefits from accessible design. Big companies have found that investing in accessibility can spur innovation.
What To Say To Your Client
Let’s consider the ‘curb-cut effect’ in the context of your website. Originally, curb cuts were designed for wheelchair users, but they ended up being useful for everyone, from parents with strollers to travelers with suitcases. Similarly, many digital accessibility features we implement can enhance the experience for all your users, not just those with disabilities. For example, features like voice control and auto-complete were developed for accessibility but are now widely used by everyone. This isn’t just about inclusivity; it’s about creating a more versatile and user-friendly website. By incorporating these accessible features, we’re not only catering to a specific group but also improving the overall user experience, which can lead to increased engagement and satisfaction across your entire customer base.
Further Reading
- Google’s Latest Accessibility Feature Is So Good, Everyone Will Use It (Fast Company)
- How Designing for the Disabled is Giving Google an Edge (Fast Company)
- Make Space For All: Digital Accessibility Benefits Everyone (Forbes)
- 4 Digital Accessibility Features That Benefit Everyone (Bureau of Internet Accessibility)
SEO Benefits
I would like to highlight the SEO benefits that come with accessible best practices. Things like nicely structured sitemaps, a proper heading outline, image alt text, and unique link labels not only improve accessibility for humans but for search engines as well, giving search crawlers clear context about what is on the page. Stakeholders and clients care a lot about this stuff, and if they are able to come around on accessibility, then they’re effectively getting a two-for-one deal.
What To Say To Your Client
Focusing on accessibility can boost your website’s SEO. Accessible features, like clear link names and organized sitemaps, align closely with what search engines prioritize. Google even includes accessibility in its Lighthouse reporting. This means that by making your site more accessible, we’re also making it more visible and attractive to search engines. Moreover, accessible websites tend to have cleaner, more structured code. This not only improves website stability and loading times but also enhances how search engines understand and rank your content. Essentially, by improving accessibility, we’re also optimizing your site for better search engine performance, which can lead to increased traffic and higher search rankings.
Further Reading
- The Impact of Website Accessibility on SEO (ADA Site Compliance)
- Web Accessibility and SEO (WebAIM)
- The ROI of Accessibility in SEO (Moz)
- Accessibility and SEO: Where they overlap and how to optimize for both (Search Engine Watch)
Better Brand Alignment
Incorporating accessibility into web design can significantly elevate how users perceive a brand’s image. The ease of use that comes with accessibility not only reflects a brand’s commitment to inclusivity and social responsibility but also differentiates it in competitive markets. By prioritizing accessibility, brands can convey a personality that is thoughtful and inclusive, appealing to a broader, more diverse customer base.
What To Say To Your Client
Implementing web accessibility is more than just a compliance measure; it’s a powerful way to enhance your brand image. In the competitive landscape of e-commerce, having an accessible website sets your brand apart. It shows your commitment to inclusivity, reaching out to every potential customer, regardless of their abilities. This not only resonates with a diverse audience but also positions your brand as socially responsible and empathetic. In today’s market, where consumers increasingly value corporate responsibility, this can be a significant differentiator for your brand, helping to build a loyal customer base and enhance your overall brand reputation.
Further Reading
- How accessibility strengthens your brand (Accessibility.com)
- Why Digital Accessibility Should Be Part of Your Brand (ADA Site Compliance)
- How to Make Your Branding Accessible (Tailor Brands)
Cost Efficiency
I mentioned earlier how developing accessibility enhances SEO like a two-for-one package. However, there are additional cost savings that come with implementing accessibility during the initial stages of web development rather than retrofitting it later. A proactive approach to accessibility saves on the potential high costs of auditing and redesigning an existing site and helps avoid expensive legal repercussions associated with non-compliance.
What To Say To Your Client
Retrofitting a website for accessibility can be quite expensive. Consider the costs of conducting an accessibility audit, followed by potentially extensive (and expensive) redesign and redevelopment work to rectify issues. These costs can significantly exceed the investment required to build accessibility into the website from the start. Additionally, by making your site accessible now, we can avoid the legal risks and potential fines associated with ADA non-compliance. Investing in accessibility early on is a cost-effective strategy that pays off in the long run, both financially and in terms of brand reputation. Besides, with the SEO benefits that we get from implementing accessibility, we’re saving lots of money and work that would otherwise be sunk into redevelopment.
Further Reading
- Making the Case for Accessibility (Susanna Zaraysky)
- 5 Steps to Creating an Accessibility Strategy (Frank Spillers)
- Digital Accessibility is an Investment, not a Cost (Bureau of Internet Accessibility)
Addressing Client Concerns
Still getting pushback? There are certain arguments I hear time and again, and I have started keeping a collection of responses to them. In some cases, I have left placeholder instructions for tailoring the responses to your project.
“Our users don’t need it.”
Statistically, 27% of the U.S. population does have some form of disability that affects their web use. [Insert research on your client’s target audience, if applicable.] Besides permanent impairments, we should also take into account situational ones. For example, imagine one of your potential clients trying to access your site on a sunny golf course, struggling to see the screen due to glare, or someone in a noisy subway unable to hear audio content. Accessibility features like high contrast modes or captions can greatly enhance their experience. By incorporating accessibility, we’re not only catering to users with disabilities but also ensuring a seamless experience for anyone in less-than-ideal conditions. This approach ensures that no potential client is left out, aligning with the goal to reach and engage a wider audience.
“Our competitors aren’t doing it.”
It’s interesting that your competitors haven’t yet embraced accessibility, but this actually presents a unique opportunity for your brand. Proactively pursuing accessibility not only protects you from the same legal exposure your competitors face but also positions your brand as a leader in customer experience. By prioritizing accessibility when others are not, you’re differentiating your brand as more inclusive and user-friendly. This both appeals to a broader audience and showcases your brand’s commitment to social responsibility and innovation.
“We’ll do it later because it’s too expensive.”
I understand concerns about timing and costs. However, it’s important to note that integrating accessibility from the start is far more cost-effective than retrofitting it later. If accessibility is considered after development is complete, you will face additional expenses for auditing accessibility, followed by potentially extensive work involving a redesign and redevelopment. This process can be significantly more expensive than building in accessibility from the beginning. Furthermore, delaying accessibility can expose your business to legal risks. With the increasing number of lawsuits for non-compliance with accessibility standards, the cost of legal repercussions could far exceed the expense of implementing accessibility now. The financially prudent move is to work on accessibility now.
“We’ve never had complaints.”
It’s great to hear that you haven’t received complaints, but it’s important to consider that users who struggle to access your site might simply choose not to return rather than take the extra step to complain about it. This means you could potentially be missing out on a significant market segment. Additionally, when accessibility issues do lead to complaints, they can sometimes escalate into legal cases. Proactively addressing accessibility can help you tap into a wider audience and mitigate the risk of future lawsuits.
“It will affect the aesthetics of the site.”
Accessibility and visual appeal can coexist beautifully. I can show you examples of websites that are both compliant and visually stunning, demonstrating that accessibility can enhance rather than detract from a site’s design. Additionally, when we consider specific design features from an accessibility standpoint, we often find they actually improve the site’s overall usability and SEO, making the site more intuitive and user-friendly for everyone. Our goal is to blend aesthetics with functionality, creating an inclusive yet visually appealing online presence.
Handling Common Client Requests
This section looks at frequent scenarios I’ve encountered in web projects where accessibility considerations come into play. Each situation requires carefully balancing the client’s needs/wants with accessibility standards. I’ll leave placeholder comments in the examples so you are able to address things that are specific to your project.
The Client Directly Requests An Inaccessible Feature
When clients request features they’ve seen online — like unfocusable carousels and complex auto-playing animations — it’s crucial to discuss them in terms that address accessibility concerns. In these situations, I acknowledge the appealing aspects of their inspirations but also highlight their accessibility limitations.
That’s a really neat feature, and I like it! That said, I think it’s important to consider how users interact with it. [Insert specific issues that you note, like carousels without pause buttons or complex animations.] My recommendation is to take the elements that work well &mdahs; [insert specific observation] — and adapt them into something more accessible, such as [Insert suggestion]. This way, we maintain the aesthetic appeal while ensuring the website is accessible and enjoyable for every visitor.
The Client Provides Inaccessible Content
This is where we deal with things like non-descriptive page titles, link names, form labels, and color contrasts for a better “reading” experience.
Page Titles
Sometimes, clients want page titles to be drastically different than the link in the navigation bar. Usually, this is because they want a more detailed page title while keeping navigation links succinct.
I understand the need for descriptive and engaging page titles, but it’s also essential to maintain consistency with the navigation bar for accessibility. Here’s our recommendation to balance both needs:
- Keyword Consistency: You can certainly have a longer page title to provide more context, but it should include the same key terms as the navigation link. This ensures that users, especially those using screen readers to announce content, can easily understand when they have correctly navigated between pages.
- Succinct Titles With Descriptive Subtitles: Another approach is to keep the page title succinct, mirroring the navigation link, and then add a descriptive tagline or subtitle on the page itself. This way, the page maintains clear navigational consistency while providing detailed context in the subtitle. These approaches aim to align the user’s navigation experience with their expectations, ensuring clarity and accessibility.
Links
A common issue with web content provided by clients is the use of non-descriptive calls to action with phrases and link labels, like “Read More” or “Click Here.” Generic terms can be confusing for users, particularly for those using screen readers, as they don’t provide context about what the link leads to or the nature of the content on the other end.
I’ve noticed some of the link labels say things like “Read More” or “Click Here” in the design. I would consider revising them because they could be more descriptive, especially for those relying on screen readers who have to put up with hearing the label announced time and again. We recommend labels that clearly indicate where the link leads. [Provide a specific example.] This approach makes links more informative and helps all users alike by telling them in advance what to expect when clicking a certain link. It enhances the overall user experience by providing clarity and context.
Forms
Proper form labels are a critical aspect of accessible web design. Labels should clearly indicate the purpose of each input field, whether it’s required, and the expected format of the information. This clarity is essential for all users, especially for those using screen readers or other assistive technologies. Plus, there are accessible approaches to pairing labels and inputs that developers ought to be familiar with.
It’s important that each form field is clearly labeled to inform users about the type of data expected. Additionally, indicating which fields are required and providing format guidelines can greatly enhance the user experience. [Provide a specific example from the client’s content, e.g., we can use ‘Phone (10 digits, no separators)’ for a phone number field to clearly indicate the format.] These labels not only aid in navigation and comprehension for all users but also ensure that the forms are accessible to those using assistive technologies. Well-labeled forms improve overall user engagement and reduce the likelihood of errors or confusion.
Brand Palette
Clients will occasionally approach me with color palettes that produce too low of contrast when paired together. This happens when, for instance, on a website with a white background, a client wants to use their brand accent color for buttons, but that color simply blends into the background color, making it difficult to read. The solution is usually creating a slightly adjusted tint or shade that’s used specifically for digital interfaces — UI colors, if you will. Atul Varma’s “Accessible Color Palette Builder” is a great starting point, as is this UX Lift lander with alternatives.
We recommend expanding the brand palette with color values that work more effectively in web designs. By adjusting the tint or shade just a bit, we can achieve a higher level of contrast between colors when they are used together. Colors render differently depending on the device and screen they are on, and even though we might be using colors consistent with brand identity, those colors will still display differently to users. By adding colors that are specifically designed for web use, we can enhance the experience for our users while staying true to the brand’s essence.
Suggesting An Accessible Feature To Clients
Proactively suggesting features like sitemaps, pause buttons, and focus indicators is crucial. I’ll provide tips on how to effectively introduce these features to clients, emphasizing their importance and benefit.
Sitemap
Sitemaps play a crucial role in both accessibility and SEO, but clients sometimes hesitate to include them due to concerns about their visual appeal. The challenge is to demonstrate the value of site maps without compromising the site’s overall aesthetic.
I understand your concerns about the visual appeal of sitemaps. However, it’s important to consider their significant role in both accessibility and SEO. For users with screen readers, a sitemap greatly simplifies site navigation. From an SEO perspective, it acts like a directory, helping search engines effectively index all your pages, making your site more discoverable and user-friendly. To address the aesthetic aspect, let’s look at how major companies like Apple and Microsoft incorporate sitemaps. Their designs are minimal yet consistent with the site’s overall look and feel. [If applicable, show how a competitor is using sitemaps.] By incorporating a well-designed sitemap, we can improve user experience and search visibility without sacrificing the visual quality of your website.
Accessible Carousels
Carousels are contentious design features. While some designers are against them and have legitimate reasons for it, I believe that with the right approach, they can be made accessible and effective. There are plenty of resources that provide guidance on creating accessible carousels.
When a client requests a home page carousel in a new site design, it’s worth considering alternative solutions that can avoid the common pitfalls of carousels, such as low click-through rates, increased load times, content being pushed below the fold, and potentially annoying auto-advancing features.
I see the appeal of using a carousel on your homepage, but there are a few considerations to keep in mind. Carousels often have low engagement rates and can slow down the site. They also tend to move key content below the fold, which might not be ideal for user engagement. An auto-advancing carousel can also be distracting for users. Instead, we could explore alternative design solutions that effectively convey your message without these drawbacks. [Insert recommendation, e.g., For instance, we could use a hero image or video with a strong call-to-action or a grid layout that showcases multiple important segments at once.] These alternatives can be more user-friendly and accessible while still achieving the visual and functional goals of a carousel.
If we decide to use a carousel, I make a point of discussing the necessary accessibility features with the client right from the start. Many clients aren’t aware that elements like pause buttons are crucial for making auto-advancing carousels accessible. To illustrate this, I’ll show them examples of accessible carousel designs that incorporate these features effectively.
Further Reading
- Usability Guidelines For Better Carousels UX (Vitaly Friedman)
- A Step-By-Step Guide To Building Accessible Carousels (Sonja Weckenmann)
Pause Buttons
Any animation that starts automatically, lasts more than five seconds, and is presented in parallel with other content, needs a pause button per WCAG Success Criterion 2.2.2. A common scenario is when clients want a full-screen video on their homepage without a pause button. It’s important to explain the necessity of pause buttons for meeting accessibility standards and ensuring user comfort without compromising the website’s aesthetics.
I understand your desire for a dynamic, engaging homepage with a full-screen video. However, it’s essential for accessibility purposes that any auto-playing animation that is longer than five seconds includes a pause button. This is not just about compliance; it’s about ensuring that all visitors, including those with disabilities, can comfortably use your site.
The good news is that pause buttons can be designed to be sleek and non-intrusive, complementing your site’s aesthetics rather than detracting from them. Think of it like the sound toggle buttons on videos. They’re there when you need them, but they don’t distract from the viewing experience. I can show you some examples of beautifully integrated pause buttons that maintain the immersive feel of the video while ensuring accessibility standards are met.
Conclusion
That’s it! This is my complete toolkit for discussing web accessibility with colleagues and clients at the start of new projects. It’s not always easy to make a case, which is why I try to appeal from different angles, using a multitude of resources and research to support my case. But with practice, care, and true partnership, it’s possible to not only influence the project but also make accessibility a first-class feature in the process.
Please use the resources, strategies, and talking points I have provided. I share them to help you make your case to your own colleagues and clients. Together, incrementally, we can take steps toward a more accessible web that is inclusive to all people.
And when in doubt, remember the core principles we covered:
- Show your expertise: Adapt accessibility discussions to fit the client’s understanding, offering basic or in-depth explanations based on their familiarity.
- Align with client goals: Connect accessibility with client-specific benefits, such as SEO and brand enhancement.
- Define accessibility in project scope: Include accessibility as an integral part of the design process and explain how it is evaluated.
- Be prepared with Resources: Keep a collection of relevant resources, including success stories and the consequences of non-compliance.
- Utilize User Research: Use targeted user research to inform design choices, demonstrating accessibility’s broad impact.
- Manage Incremental Changes: Suggest iterative changes for large projects to address accessibility in manageable steps.
(yk)
Vanilla JavaScript, Libraries, And The Quest For Stateful DOM Rendering
Vanilla JavaScript, Libraries, And The Quest For Stateful DOM Rendering Vanilla JavaScript, Libraries, And The Quest For Stateful DOM Rendering Frederik Dohr 2024-02-22T18:00:00+00:00 2025-06-25T15:04:30+00:00 In his seminal piece “The Market For Lemons”, renowned web crank Alex Russell lays out the myriad failings of our industry, […]
Accessibility
Vanilla JavaScript, Libraries, And The Quest For Stateful DOM Rendering
Frederik Dohr 2024-02-22T18:00:00+00:00
2025-06-25T15:04:30+00:00
In his seminal piece “The Market For Lemons”, renowned web crank Alex Russell lays out the myriad failings of our industry, focusing on the disastrous consequences for end users. This indignation is entirely appropriate according to the bylaws of our medium.
Frameworks factor highly in that equation, yet there can also be good reasons for front-end developers to choose a framework, or library for that matter: Dynamically updating web interfaces can be tricky in non-obvious ways. Let’s investigate by starting from the beginning and going back to the first principles.
Markup Categories
Everything on the web starts with markup, i.e. HTML. Markup structures can roughly be divided into three categories:
- Static parts that always remain the same.
- Variable parts that are defined once upon instantiation.
- Variable parts that are updated dynamically at runtime.
For example, an article’s header might look like this:
<header>
<h1>«Hello World»</h1>
<small>«123» backlinks</small>
</header>
Variable parts are wrapped in «guillemets» here: “Hello World” is the respective title, which only changes between articles. The backlinks counter, however, might be continuously updated via client-side scripting; we’re ready to go viral in the blogosphere. Everything else remains identical across all our articles.
The article you’re reading now subsequently focuses on the third category: Content that needs to be updated at runtime.
Color Browser
Imagine we’re building a simple color browser: A little widget to explore a pre-defined set of named colors, presented as a list that pairs a color swatch with the corresponding color value. Users should be able to search colors names and toggle between hexadecimal color codes and Red, Blue, and Green (RGB) triplets. We can create an inert skeleton with just a little bit of HTML and CSS:
See the Pen [Color Browser (inert) [forked]](https://codepen.io/smashingmag/pen/RwdmbGd) by FND.
Client-Side Rendering
We’ve grudgingly decided to employ client-side rendering for the interactive version. For our purposes here, it doesn’t matter whether this widget constitutes a complete application or merely a self-contained island embedded within an otherwise static or server-generated HTML document.
Given our predilection for vanilla JavaScript (cf. first principles and all), we start with the browser’s built-in DOM APIs:
function renderPalette(colors) {
let items = [];
for(let color of colors) {
let item = document.createElement("li");
items.push(item);
let value = color.hex;
makeElement("input", {
parent: item,
type: "color",
value
});
makeElement("span", {
parent: item,
text: color.name
});
makeElement("code", {
parent: item,
text: value
});
}
let list = document.createElement("ul");
list.append(...items);
return list;
}
Note:
The above relies on a small utility function for more concise element creation:function makeElement(tag, { parent, children, text, ...attribs }) { let el = document.createElement(tag); if(text) { el.textContent = text; } for(let [name, value] of Object.entries(attribs)) { el.setAttribute(name, value); } if(children) { el.append(...children); } parent?.appendChild(el); return el; }You might also have noticed a stylistic inconsistency: Within the
itemsloop, newly created elements attach themselves to their container. Later on, we flip responsibilities, as thelistcontainer ingests child elements instead.
Voilà: renderPalette generates our list of colors. Let’s add a form for interactivity:
function renderControls() {
return makeElement("form", {
method: "dialog",
children: [
createField("search", "Search"),
createField("checkbox", "RGB")
]
});
}
The createField utility function encapsulates DOM structures required for input fields; it’s a little reusable markup component:
function createField(type, caption) {
let children = [
makeElement("span", { text: caption }),
makeElement("input", { type })
];
return makeElement("label", {
children: type === "checkbox" ? children.reverse() : children
});
}
Now, we just need to combine those pieces. Let’s wrap them in a custom element:
import { COLORS } from "./colors.js"; // an array of `{ name, hex, rgb }` objects
customElements.define("color-browser", class ColorBrowser extends HTMLElement {
colors = [...COLORS]; // local copy
connectedCallback() {
this.append(
renderControls(),
renderPalette(this.colors)
);
}
});
Henceforth, a <color-browser> element anywhere in our HTML will generate the entire user interface right there. (I like to think of it as a macro expanding in place.) This implementation is somewhat declarative1, with DOM structures being created by composing a variety of straightforward markup generators, clearly delineated components, if you will.
1 The most useful explanation of the differences between declarative and imperative programming I’ve come across focuses on readers. Unfortunately, that particular source escapes me, so I’m paraphrasing here: Declarative code portrays the what while imperative code describes the how. One consequence is that imperative code requires cognitive effort to sequentially step through the code’s instructions and build up a mental model of the respective result.
Interactivity
At this point, we’re merely recreating our inert skeleton; there’s no actual interactivity yet. Event handlers to the rescue:
class ColorBrowser extends HTMLElement {
colors = [...COLORS];
query = null;
rgb = false;
connectedCallback() {
this.append(renderControls(), renderPalette(this.colors));
this.addEventListener("input", this);
this.addEventListener("change", this);
}
handleEvent(ev) {
let el = ev.target;
switch(ev.type) {
case "change":
if(el.type === "checkbox") {
this.rgb = el.checked;
}
break;
case "input":
if(el.type === "search") {
this.query = el.value.toLowerCase();
}
break;
}
}
}
Note:
handleEventmeans we don’t have to worry about function binding. It also comes with various advantages. Other patterns are available.
Whenever a field changes, we update the corresponding instance variable (sometimes called one-way data binding). Alas, changing this internal state2 is not reflected anywhere in the UI so far.
2 In your browser’s developer console, check document.querySelector("color-browser").query after entering a search term.
Note that this event handler is tightly coupled to renderControls internals because it expects a checkbox and search field, respectively. Thus, any corresponding changes to renderControls — perhaps switching to radio buttons for color representations — now need to take into account this other piece of code: action at a distance! Expanding this component’s contract to include
field names could alleviate those concerns.
We’re now faced with a choice between:
- Reaching into our previously created DOM to modify it, or
- Recreating it while incorporating a new state.
Rerendering
Since we’ve already defined our markup composition in one place, let’s start with the second option. We’ll simply rerun our markup generators, feeding them the current state.
class ColorBrowser extends HTMLElement {
// [previous details omitted]
connectedCallback() {
this.#render();
this.addEventListener("input", this);
this.addEventListener("change", this);
}
handleEvent(ev) {
// [previous details omitted]
this.#render();
}
#render() {
this.replaceChildren();
this.append(renderControls(), renderPalette(this.colors));
}
}
We’ve moved all rendering logic into a dedicated method3, which we invoke not just once on startup but whenever the state changes.
3 You might want to avoid private properties, especially if others might conceivably build upon your implementation.
Next, we can turn colors into a getter to only return entries matching the corresponding state, i.e. the user’s search query:
class ColorBrowser extends HTMLElement {
query = null;
rgb = false;
// [previous details omitted]
get colors() {
let { query } = this;
if(!query) {
return [...COLORS];
}
return COLORS.filter(color => color.name.toLowerCase().includes(query));
}
}
Note:
I’m partial to the bouncer pattern.
Toggling color representations is left as an exercise for the reader. You might passthis.rgbintorenderPaletteand then populate<code>with eithercolor.hexorcolor.rgb, perhaps employing this utility:function formatRGB(value) { return value.split(","). map(num => num.toString().padStart(3, " ")). join(", "); }
This now produces interesting (annoying, really) behavior:
See the Pen [Color Browser (defective) [forked]](https://codepen.io/smashingmag/pen/YzgbKab) by FND.
Entering a query seems impossible as the input field loses focus after a change takes place, leaving the input field empty. However, entering an uncommon character (e.g. “v”) makes it clear that something is happening: The list of colors does indeed change.
The reason is that our current do-it-yourself (DIY) approach is quite crude: #render erases and recreates the DOM wholesale with each change. Discarding existing DOM nodes also resets the corresponding state, including form fields’ value, focus, and scroll position. That’s no good!
Incremental Rendering
The previous section’s data-driven UI seemed like a nice idea: Markup structures are defined once and re-rendered at will, based on a data model cleanly representing the current state. Yet our component’s explicit state is clearly insufficient; we need to reconcile it with the browser’s implicit state while re-rendering.
Sure, we might attempt to make that implicit state explicit and incorporate it into our data model, like including a field’s value or checked properties. But that still leaves many things unaccounted for, including focus management, scroll position, and myriad details we probably haven’t even thought of (frequently, that means accessibility features). Before long, we’re effectively recreating the browser!
We might instead try to identify which parts of the UI need updating and leave the rest of the DOM untouched. Unfortunately, that’s far from trivial, which is where libraries like React came into play more than a decade ago: On the surface, they provided a more declarative way to define DOM structures4 (while also encouraging componentized composition, establishing a single source of truth for each individual UI pattern). Under the hood, such libraries introduced mechanisms5 to provide granular, incremental DOM updates instead of recreating DOM trees from scratch — both to avoid state conflicts and to improve performance6.
4 In this context, that essentially means writing something that looks like HTML, which, depending on your belief system, is either essential or revolting. The state of HTML templating was somewhat dire back then and remains subpar in some environments.
5 Nolan Lawson’s “Let’s learn how modern JavaScript frameworks work by building one” provides plenty of valuable insights on that topic. For even more details, lit-html’s developer documentation is worth studying.
6 We’ve since learned that some of those mechanisms are actually ruinously expensive.
The bottom line: If we want to encapsulate markup definitions and then derive our UI from a variable data model, we kinda have to rely on a third-party library for reconciliation.
Actus Imperatus
At the other end of the spectrum, we might opt for surgical modifications. If we know what to target, our application code can reach into the DOM and modify only those parts that need updating.
Regrettably, though, that approach typically leads to calamitously tight coupling, with interrelated logic being spread all over the application while targeted routines inevitably violate components’ encapsulation. Things become even more complicated when we consider increasingly complex UI permutations (think edge cases, error reporting, and so on). Those are the very issues that the aforementioned libraries had hoped to eradicate.
In our color browser’s case, that would mean finding and hiding color entries that do not match the query, not to mention replacing the list with a substitute message if no matching entries remain. We’d also have to swap color representations in place. You can probably imagine how the resulting code would end up dissolving any separation of concerns, messing with elements that originally belonged exclusively to renderPalette.
class ColorBrowser extends HTMLElement {
// [previous details omitted]
handleEvent(ev) {
// [previous details omitted]
for(let item of this.#list.children) {
item.hidden = !item.textContent.toLowerCase().includes(this.query);
}
if(this.#list.children.filter(el => !el.hidden).length === 0) {
// inject substitute message
}
}
#render() {
// [previous details omitted]
this.#list = renderPalette(this.colors);
}
}
As a once wise man once said: That’s too much knowledge!
Things get even more perilous with form fields: Not only might we have to update a field’s specific state, but we would also need to know where to inject error messages. While reaching into renderPalette was bad enough, here we would have to pierce several layers: createField is a generic utility used by renderControls, which in turn is invoked by our top-level ColorBrowser.
If things get hairy even in this minimal example, imagine having a more complex application with even more layers and indirections. Keeping on top of all those interconnections becomes all but impossible. Such systems commonly devolve into a big ball of mud where nobody dares change anything for fear of inadvertently breaking stuff.
Conclusion
There appears to be a glaring omission in standardized browser APIs. Our preference for dependency-free vanilla JavaScript solutions is thwarted by the need to non-destructively update existing DOM structures. That’s assuming we value a declarative approach with inviolable encapsulation, otherwise known as “Modern Software Engineering: The Good Parts.”
As it currently stands, my personal opinion is that a small library like lit-html or Preact is often warranted, particularly when employed with replaceability in mind: A standardized API might still happen! Either way, adequate libraries have a light footprint and don’t typically present much of an encumbrance to end users, especially when combined with progressive enhancement.
I don’t wanna leave you hanging, though, so I’ve tricked our vanilla JavaScript implementation to mostly do what we expect it to:
See the Pen [Color Browser [forked]](https://codepen.io/smashingmag/pen/vYPwBro) by FND.
(yk)
Web Development Is Getting Too Complex, And It May Be Our Fault
Web Development Is Getting Too Complex, And It May Be Our Fault Web Development Is Getting Too Complex, And It May Be Our Fault Juan Diego Rodríguez 2024-02-07T13:00:00+00:00 2025-06-25T15:04:30+00:00 Front-end development seemed simpler in the early 2000s, didn’t it? The standard website consisted mostly of […]
Accessibility
Web Development Is Getting Too Complex, And It May Be Our Fault
Juan Diego Rodríguez 2024-02-07T13:00:00+00:00
2025-06-25T15:04:30+00:00
Front-end development seemed simpler in the early 2000s, didn’t it? The standard website consisted mostly of static pages made of HTML and CSS seasoned with a pinch of JavaScript and jQuery. I mean, who doesn’t miss the cross-browser compatibility days, right?
Fast forward to today, and it looks like a parallel universe is taking place with an overwhelming number of choices. Which framework should you use for a new project? Perhaps more established ones like React, Angular, Vue, Svelte, or maybe the hot new one that came out last month? Each framework comes with its unique ecosystem. You also need to decide whether to use TypeScript over vanilla JavaScript and choose how to approach server-side rendering (or static site generation) with meta-frameworks like Next, Nuxt, or Gatsby. And we can’t forget about unit and end-to-end testing if you want a bug-free web app. And we’ve barely scratched the surface of the front-end ecosystem!
But has it really gotten more complex to build websites? A lot of the frameworks and tooling we reach for today were originally crafted for massive projects. As a newcomer, it can be frightening to have so many to consider, almost creating a fear of missing out that we see exploited to sell courses and tutorials on the new hot framework that you “cannot work without.”
All this gives the impression that web development has gotten perhaps too complex. But maybe that is just an exaggeration? In this article, I want to explore those claims and find out if web development really is that complex and, most importantly, how we can prevent it from getting even more difficult than we already perceive it to be.
How It Was Before
As someone who got into web development after 2010, I can’t testify to my own experience about how web development was from the late 1990s through the 2000s. However, even fifteen years ago, learning front-end development was infinitely simpler, at least to me. You could get a website started with static HTML pages, minimal CSS for styling, and a sprinkle of JavaScript (and perhaps a touch of jQuery) to add interactive features, from toggled sidebars to image carousels and other patterns. Not much else was expected from your average developer beyond that — everything else was considered “going the extra mile.” Of course, the awesome native CSS and JavaScript features we have today weren’t around back then, but they were also unnecessary for what was considered best practice in past years.
Large and dynamic web apps certainly existed back then — YouTube and Facebook, to name a couple — but they were developed by massive companies. No one was expected to re-create that sort of project on their own or even a small team. That would’ve been the exception rather than the norm.
I remember back then, tend to worry more about things like SEO and page optimization than how my IDE was configured, but only to the point of adding meta tags and keywords because best practices didn’t include minifying all your assets, three shaking your code, caching your site on edge CDNs, or rendering your content on the server (a problem created by modern frameworks along hydration). Other factors like accessibility, user experience, and responsive layouts were also largely overlooked in comparison to today’s standards. Now, they are deeply analyzed and used to boost Lighthouse scores and impress search engine algorithms.
The web and everything around it changed as more capabilities were added and more and more people grew to depend on it. We have created new solutions, new tools, new workflows, new features, and whatever else new that is needed to cater to a bigger web with even bigger needs.
The web has always had its problems in the past that were worthy of fixing: I absolutely don’t miss tables and float layouts, along with messy DOM manipulation. This post isn’t meant to throw shade on new advances while waxing nostalgic about the good days of the “old wild web.” At the same time, though, yesterday’s problems seem infinitely simpler than those we face today.
JavaScript Frameworks
JavaScript frameworks, like Angular and React, were created by Google and Facebook, respectively, to be used in their own projects and satisfy the needs that only huge web-based companies like them have. Therein lies the main problem with web complexity: JavaScript frameworks were originally created to sustain giant projects rather than smaller ones. Many developers vastly underestimate the amount of time it takes to build a codebase that is reliable and maintainable with a JavaScript framework. However, the alternative of using vanilla JavaScript was worse, and jQuery was short for the task. Vanilla JavaScript was also unable to evolve quickly enough to match our development needs, which changed from simple informative websites to dynamic apps. So, many of us have quickly adopted frameworks to avoid directly mingling with JavaScript and its messy DOM manipulation.
Back-end development is a completely different topic, subject to its own complexities. I only want to focus on front-end development because that is the discipline that has perhaps overstepped its boundaries the most by bleeding into traditional back-end concerns.
Stacks Getting Bigger
It was only logical for JavaScript frameworks to grow in size over time. The web is a big place, and no one framework can cover everything. But they try, and the complexity, in turn, increases. A framework’s size seems to have a one-to-one correlation with its complexity.
But the core framework is just one piece of a web app. Several other technologies make up what’s known as a tech “stack,” and with the web gaining more users and frameworks catering to their needs, tech stacks are getting bigger and bigger. You may have seen popular stacks such as MEAN (MongoDB, Express, Angular, and Node) or its React (MERN) and Vue (MEVN) variants. These stacks are marketed as mature, test-proofed foundations suitable for any front-end project. That means the advertised size of a core framework is grossly underestimated because they rely on other micro-frameworks to ensure highly reliable architectures, as you can see in stackshare.io. Besides, there isn’t a one-size-fits-all stack; the best tool has always depended — and will continue to depend — on the needs and goals of your particular project.
This means that each new project likely requires a unique architecture to fulfill its requirements. Giant tech companies need colossal architectures across all their projects, and their stacks are highly engineered accordingly to secure scalability and maintenance. They also have massive customer bases, so maintaining a large codebase will be easier with more revenue, more engineers, and a clearer picture of the problem. To minimize waste, the tech stacks of smaller companies and projects can and should be minimized not only to match the scale of their needs but to the abilities of the developers on the team as well.
The idea that web development is getting too complex comes from buying into the belief that we all have the same needs and resources as giant enterprises.
“
Trying to imitate their mega stacks is pointless. Some might argue that it’s a sacrifice we have to make for future scalability and maintenance, but we should focus first on building great sites for the user without worrying about features users might need in the future. If what we are building is worth pursuing, it will reach the point where we need those giant architectures in good time. Cross that bridge when we get there. Otherwise, it’s not unlike wearing Shaquille O’Neal-sized sneakers in hopes of growing into them. They might not even last until then if it happens at all!
We must remember that the end-user experience is the focus at the end of the day, and users neither care about nor know what stack we use in our apps. What they care about is a good-looking, useful website where they can accomplish what they came for, not the technology we use to achieve it. This is how I’ve come to believe that web development is not getting more complex. It’s developers like us who are perpetuating it by buying into solutions for problems that do not need to be solved at a certain scale.
Let me be really clear: I am not saying that today’s web development is all bad. Indeed, we’ve realized a lot of great features, and many of them are thanks to JavaScript frameworks that have pushed for certain features. jQuery had that same influence on JavaScript for many, many years.
We can still create minimum viable products today with minimal resources. No, those might not make people smash the Like button on your social posts, but they meet the requirements, nothing more and nothing less. We want bigger! Faster! Cheaper! But we can’t have all three.
If anything, front-end development has gotten way easier thanks to modern features that solve age-old development issues, like the way CSS Flexbox and Grid have trivialized layouts that used to require complex hacks involving floats and tables. It’s the same deal with JavaScript gaining new ways to build interactions that used to take clever workarounds or obtuse code, such as having the Intersection Observer API to trivialize things like lazy loading (although HTML has gained its own features in that area, too).
We live in this tension between the ease of new platform features and the complexity of our stacks.
“
Do We Need A JavaScript Framework For Everything?
Each project, regardless of its simplicity, desperately needs a JavaScript framework. A project without a complex framework is like serving caviar on a paper plate.
At least, that’s what everyone seems to think. But is that actually true? I’d argue on the contrary. JavaScript frameworks are best used on bigger applications. If you’re working on a smaller project, a component-based framework will only complicate matters, making you split your website into a component hierarchy that amounts to overkill for small projects.
The idea of needing a framework for everything has been massively oversold. Maybe not directly, but you unconsciously get that feeling whenever a framework’s name pops in, as Edge engineer Alex Russell eloquently expresses in his article, “The Market For Lemons”:
“These technologies were initially pitched on the back of “better user experiences” but have utterly failed to deliver on that promise outside of the high-management-maturity organisations in which they were born. Transplanted into the wider web, these new stacks have proven to be expensive duds.”
— Alex Russell
Remember, the purpose of a framework is to simplify your life and save time. If the project you’re working on is smaller, the time you supposedly save is likely overshadowed by the time you spend either setting up the framework or making it work with the rest of the project. A framework can help make bigger web apps more interactive and dynamic, but there are times when a framework is a heavy-handed solution that actually breeds inefficient workflows and introduces technical debt.
Step back and think about this: Are HTML, CSS, and a touch of JavaScript enough to build your website or web application? If so, then stick with those. What I am afraid of is adding complexity for complexity’s sake and inadvertently raising the barrier to entry for those coming into web development. We can still accomplish so much with HTML and CSS alone, thanks again to many advances in the last decade. But we give the impression that they are unsuitable for today’s web consumption and need to be enhanced.
Knowing Everything And Nothing At The Same Time
The perceived standard that teams must adopt framework-centered architectures puts a burden not only on the project itself but on a developer’s well-being, too. As mentioned earlier, most teams are unable to afford those architectures and only have a few developers to maintain them. If we undermine what can be achieved with HTML and CSS alone and set the expectations that any project — regardless of size — needs to have a bleeding edge stack, then the weight to meet those expectations falls on the developer’s shoulders, with the great responsibility of being proficient in all areas, from the server and database to front end, to design, to accessibility, to performance, to testing, and it doesn’t stop. It’s what has been driving “The Great Divide” in front-end development, which Chris Coyier explains like this:
“The divide is between people who self-identify as a (or have the job title of) front-end developer yet have divergent skill sets. On one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. On the other, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, and so on.”
— Chris Coyier
Under these expectations, developers who focus more on HTML, CSS, design, and accessibility rather than the latest technology will feel less valued in an industry that appears to praise those who are concerned with the stack. What exactly are we saying when we start dividing responsibilities in terms of “full-stack development” or absurd terms like “10x development”? A while back, Brad Frost began distinguishing these divisions as “front-of-the-front-end” and “back-of-the-front-end”.
Mandy Michael explains what impact the chase for “full-stack” has had on developers trying to keep up:
“The worst part about pushing the “know everything” mentality is that we end up creating an industry full of professionals suffering from burnout and mental illness. We have people speaking at conferences about well-being, imposter syndrome, and full-stack anxiety, yet despite that, we perpetuate this idea that people have to know everything and be amazing at it.”
— Mandy Michael
This isn’t the only symptom of adopting heavy-handed solutions for what “vanilla” HTML, CSS, and JavaScript already handle nicely. As the expectations for what we can do as front-end developers grow, the learning curve of front-end development grows as well. Again, we can’t learn and know everything in this vast discipline. But we tell ourselves we have to, and thanks to this mentality, it’s unfortunately common to witness developers who may be extremely proficient with a particular framework but actually know and understand little of the web platform itself, like HTML semantics and structure.
The fact that many budding developers tend to jump straight into frameworks at the expense of understanding the basics of HTML and CSS isn’t a new worry, as Rachel Andrew discussed back in 2019:
“That’s the real entry point here, and yes, in 2019, they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However, those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.”
— Rachel Andrew
And I want to clarify yet again that modern Javascript frameworks and libraries aren’t inherently bad; they just aren’t designed to replace the web platform and its standards. But we keep pushing them like we want them to!
The Consequences Of Vendor Lock-In
“Vendor lock-in” happens when we depend too deeply on proprietary products and services to the extent that switching to other products and services becomes a nearly impossible task. This often occurs when cloud services from a particular company are deeply integrated into a project. It’s an issue, especially in cloud computing, since moving databases once they are set up is expensive and lengthy.
Vendor lock-in in web development has traditionally been restricted to the back end, like with cloud services such as AWS or Firebase; the front-end framework, meanwhile, was a completely separate concern. That said, I have noticed a recent trend where vendor lock-in is reaching into meta-frameworks, too. With the companies behind certain meta-frameworks offering hosting services for their own products, swapping hosts is increasingly harder to do (whether the lock-in is designed intentionally or not). Of course, companies and developers will be more likely to choose the hosting service of the company that made a particular framework used on their projects — they’re the experts! — but that only increases the project’s dependency on those vendors and their services.
A clear example is the relationship between Next and Vercel, the parent cloud service for Next. With the launch of Next 13, it has become increasingly harder to set up a Next project outside of Vercel, leading to projects like Open Next, which says right on its website that “[w]hile Vercel is great, it’s not a good option if all your infrastructure is on AWS. Hosting it in your AWS account makes it easy to integrate with your backend [sic]. And it’s a lot cheaper than Vercel.” Fortunately, the developers’ concerns have been heard, and Next 14 brings clarity on how to self-host Next on a Node server.
Another example is Gatsby and Gatsby Cloud. Gatsby has always offered helpful guides and alternative hosting recommendations, but since the launch of Gatsby Cloud in 2019, the main framework has been optimized so that using Gatsby and Gatsby Cloud together requires no additional hosting configurations. That’s fantastic if you adopt both, but it’s not so great if all you need is one or the other because integrating the framework with other hosts — and vice versa — is simply harder. It’s as if you are penalized for exercising choice.
And let’s not forget that no team expected Netlify to acquire Gatsby Cloud in February 2023. This is a prime case where the vendor lock-in problem hits everybody because converting from one site to another comes at a cost. Some teams were charged 120% more after converting from Gatsby Cloud to Netlify — even with the same plan they had with Gatsby Cloud!
What’s the solution? The common answer I hear is to stop using paid cloud services in favor of open-sourced alternatives. While that’s great and indeed a viable option for some projects, it fails to consider that an open-source project may not meet the requirements needed for a given app.
And even then, open-source software depends on the community of developers that maintain and update the codebase with little to no remuneration in exchange. Further, open source is equally prone to locking you into certain solutions that are designed to solve a deficiency with the software.
There are frameworks and libraries, of course, that are in no danger of being abandoned. React is a great example because it has an actively engaged community behind it. But you can’t have the same assurance with each new dependency you add to a project. We can’t simply keep installing more packages and components each time we spot a weak spot in the dependency chain, especially when a project is perfectly suited for a less complex architecture that properly leverages the web platform.
Choosing technology for your stack is an exercise of picking your own poison. Either choose a paid service and be subject to vendor lock-in in the future, or choose an open-source one and pray that the community continues to maintain it.
“
Those are virtually the only two choices. Many of the teams I know or have worked on depend on third-party services because they cannot afford to develop them on their own; that’s a luxury that only massive companies can afford. It’s a problem we have to undergo when starting a new project, but one we can minimize by reducing the number of dependencies and choosing wisely when we have to.
Each Solution Introduces A New Problem
Why exactly have modern development stacks gotten so large and complex? We can point a finger at the “Development Paradox.” With each new framework or library, a new problem crops up, and time-starved developers spend months developing a new tool to solve that problem. And when there isn’t a problem, don’t worry — we will create one eventually. This is a feedback loop that creates amazing solutions and technologies but can lead to over-engineered websites if we don’t reign it in.
This reminds me of the famous quote:
“The plain fact is that if you don’t have a problem, you create one. If you don’t have a problem, you don’t feel that you are living.”
— U.G. Krishnamurti
Let’s look specifically at React. It was originally created by Facebook for Facebook to develop more dynamic features for users while improving Facebook’s developer experience.
Since React was open-sourced in 2013 (and nearly re-licensed in 2017, if it weren’t for the WordPress community), hundreds of new utilities have been created to address various React-specific problems. How do you start a React project? There’s Create React App and Vite. Do you need to enhance your state management? There is Redux, among other options. Need help creating forms? There is a React Hook Form. And perhaps the most important question: Do you need server-side rendering? There’s Next, Remix, or Gatsby for that. Each solution comes with its own caveats, and developers will create their own solutions for them.
It may be unfair to pick on React since it considers itself a library, not a framework. It’s inevitably prone to be extended by the community. Meanwhile, Angular and Vue are frameworks with their own community ecosystems. And this is the tip of the iceberg since there are many JavaScript frameworks in the wild, each with its own distinct ideology and dependencies.
Again, I don’t want you to get the wrong idea. I love that new technologies emerge and find it liberating to have so many options. But when building something as straightforward as a webpage or small website — which some have started referring to as “multi-page applications” — we have to draw a line that defines how many new technologies we use and how reliable they are. We’re quite literally mashing together third-party code written by various third-party developers. What could go wrong? Please don’t answer that.
Remember that our users don’t care what’s in our stacks. They only see the final product, so we can save ourselves from working on unnecessary architectures that aren’t appreciated outside of development circles. It may seem counterintuitive in the face of advancing technology, but knowing that the user doesn’t care about what goes behind the scenes and only sees the final product will significantly enhance our developer experience and free you from locked dependencies. Why fix something that isn’t broken?
How Can We Simplify Our Codebases?
We’ve covered several reasons why web development appears to be more complex today than in years past, but blaming developers for releasing new utilities isn’t an accurate portrayal of the real problem. After all, when developing a site, it’s not like we are forced to use each new technology that enters the market. In fact, many of us are often unaware of a particular library and only learn about it when developing a new feature. For example, if we want to add toast notifications to our web app, we will look for a library like react-toastify rather than some other way of building them because it “goes with” that specific library. It’s worth asking whether the app needs toast notifications at all if they introduce new dependencies.
Imagine you are developing an app that allows users to discover, review, and rate restaurants in their area. The app needs, at a bare minimum, information about each restaurant, a search tool to query them, and an account registration flow with authentication to securely access the account. It’s easy to make assumptions about what a future user might need in addition to these critical features. In many cases, a project ends up delayed because we add unnecessary features like SSR, notifications, offline mode, and fancy animations — sometimes before the app has even converted its first registered user!
I believe we can boil down the complexity problem to personal wishes and perceived needs rather than properly scoping a project based on user needs and experiences.
That level of scope creep can easily turn into an over-engineered product that will likely never see the light of launching.
What can we do to simplify our own projects? The following advice is relevant when you have control over your project, either because it’s a personal one, it’s a smaller one for a smaller team, or you have control over the decisions in whatever size organization you happen to be in.
The hardest and most important step is having a sense of detection when your codebase is getting unnecessarily complicated. I deem it the hardest step because there is no certainty of what the requirements are or what the user needs; we can only make assumptions. Some are obvious, like assuming the user will need a way to log into the app. Others might be unclear, like whether the app should have private messaging between users. Others are still far-fetched, like believing users need extremely low latency in an e-commerce page. Other features are in the “nice to have” territory.
That is regarding the user experience, but the same questions emerge on the development side:
- Should we be using a CSS preprocessor or a CSS framework, or can we achieve it using only CSS modules?
- Is vanilla JavaScript enough, or are we going to add TypeScript?
- Does the app need SSR, SSG, or a hybrid of the two?
- Should we implement Redis on the back end for faster database queries, or is that too much scope for the work?
- Should we be implementing end-to-end testing or unit tests?
These are valid questions that should be considered when developing a site, but they can distract us from our main focus: getting things done.
“Done is better than perfect.”
— Sheryl Sandberg
And, hey, even the largest and most sophisticated apps began as minimal offerings that iterated along the way.
We also ought to be asking ourselves what would happen if a particular feature or dependency isn’t added to the project. If the answer is “nothing,” then we should be shifting our attention to something else.
Another question worth asking: “Why are we choosing to add [X]?” Is it because that’s what is popular at the moment, or because it solves a problem affecting a core feature? Another aspect to take into consideration is how familiar we are with certain technologies and give preference to those we know and can start using them right away rather than having to stop and learn the ins and outs of a new framework.
Choose the right tool for the job, which is going to be the one that meets the requirements and fits your mental model. Focus less on a library’s popularity and scalability but rather on getting your app to the point where it needs to scale in the first place.
Conclusion
It’s incredibly difficult to not over-engineer web apps given current one-size-fits-all and fear-of-missing-out mentalities. But we can be more conscious of our project goals and exercise vigilance in guarding our work against scope creep. The same can be applied to the stack we use, making choices based on what is really needed rather than focusing purely on what everyone else is using for their particular work.
After reading the word “framework” exactly 48 times in this article, can we now say the web is getting too complex? It has been complex by nature since its origins, but complexity doesn’t translate to “over-engineered” web apps. The web isn’t intrinsically over-engineered, and we only have ourselves to blame for over-engineering our projects with overly-wrought solutions for perceived needs.
(gg, yk)
UX & UI Best Practices To Increase Sales with Your B2B Website Design
B2B website design with appropriate UX and UI can increase lead generation and support prospective customers at every stage of the purchase process. There are key characteristics of B2B websites and B2B customers as well as effective UX and UI design practices that can help […]
AccessibilityB2B website design with appropriate UX and UI can increase lead generation and support prospective customers at every stage of the purchase process.
There are key characteristics of B2B websites and B2B customers as well as effective UX and UI design practices that can help you convert new users into leads.
Key Differences Between B2B and B2C Sales
Nowadays, it’s extremely important to provide customers with more helpful and relevant shopping experiences. Brands have to get creative and find new, more meaningful ways to connect with consumers. To follow the latest 4 COVID-era trends and to further improve products and consumer experience, it makes sense to dive into the broad theme of what distinctive needs characterize B2B customers compared to B2C customers. Understanding these unique characteristics and the needs of your target audience is the key to the successful creation and implementation of the most relevant UX (user experience) and UI (user interface) web design decisions. Let’s start!
Time for a Decision
First of all, unlike most B2C customers, B2B clients often research potential purchase for several weeks. The reason is that B2B customers often involve multiple people in this process, from both the vendor’s company and their own.
Services and Products Specifications
B2B purchases are often big–ticket items or service contracts. The sites’ products and services are often extremely specialized, with complex specifications. Finally, decisions made on B2B websites can have long-term implications — after all, customers aren’t just making one-time purchases. They’re often buying into a long-term vendor relationship that includes support, follow-ups, and future enhancements and add-ons.
Content Requirements
Research and multicriteria decision-making dominate the B2B user experience. B2B websites must provide a much wider range of information than what’s common in the B2C sector. A B2B website has to offer simple facts that can be easily and quickly understood by an early prospect who’s just looking around to see what’s available.
Creating a well-designed and informative B2B customer journey map can greatly enhance this process, providing a clear roadmap for engaging and converting prospects at each stage of their buying journey.
Target Audience
Another major difference is that B2C users typically buy for themselves. Therefore, they use a one-person decision process: a single user provides the budget and approval, researches the options, makes the decision, completes the purchase, receives the shipment, and uses the product. In contrast, in B2B, each of these steps might involve different people and different departments. That’s why among B2B salespeople there are widely used terms like “choosers” and “users”. Later, as companies and individuals send transactional emails, these become more personalized and precise.
But a B2B website must address many different types of users with various needs. That’s why this added complexity only strengthens the argument for B2B websites to emphasize usability in their UX design.
In the meantime, you should also take security measures such as regarding DDoS attacks, cyberattacks, etc.
The Purchasing Phases of B2B Customers
It doesn’t matter whether you close the sale online or offline, supporting your target users’ purchase process is essential to converting prospects into paying customers. The key component in effective B2B marketing and sales is establishing credibility among prospective clients.
The nature of B2B products and services often demands long sales cycles that can take months or even years. Additionally, depending on the purchase phase, customers will have different needs. Therefore, B2B websites must consider all these variables, in order to:
- support the purchase process at each stage,
- establish and maintain good relationships with customers,
- increase TCR (task completion rate) on your website.
Research Company Problem
Usually, B2B customers start with a company problem that needs solving, not with a product they’ll have to justify purchasing. Especially when this is a new challenge to their business, this initial research phase is all about seeking out common solutions and identifying the top vendors. Some buyers skip this step for industries or problems that they are already familiar with.
What a good B2B website design needs at this stage:
- Content that shows expertise, examples of solutions, and already solved challenges. This can take the form of: blog posts and articles, case studies, landing pages that describe managed solutions for specific industries, and product pages about specific customer problems that can be solved with the vendor’s help. You can then repurpose that content sharing it in email newsletters that reach your potential clients directly. And to ensure data safety on both sides, you may want to use an SPF checker as well. Another way to do that is through a high quality podcast series featuring discussions with industry experts, video tutorials demonstrating product benefits, and interactive webinars showcasing real-world implementations to effectively educate, engage, and convert your target audience.
Collect Options and Assess
At this stage, users want to find lists of top vendors, learn more about the shortlisted companies, get a feel for them, call if necessary to fill in missing details, and refine research by getting answers to specific questions. Colleagues will often share options and collaborate to help put together a rubric or requirements for assessing the shortlisted companies.
What a good B2B website design needs at this stage:
- Detailed specs,
- Pricing information,
- Clear product photos,
- Case studies,
- Testimonials,
- Downloadable product assets.
Discuss and Decide
This stage features a heavy collaboration with colleagues from multiple departments to narrow the list of companies and make a final decision. Many B2B customers create presentation materials for the leadership to explain their decision in order to be granted authorization.
What a good B2B website design needs at this stage:
- Presentation materials,
- Pricing information,
- Lead times,
- Corporate and team member information,
- Comparison tools.
Purchase
Customers engage with sales representatives to negotiate a price or make an online purchase.
What a good B2B website design needs at this stage:
- Contact information,
- Locations of offices,
- Warranty for support information,
- Pricing information.
Post-Purchase Support
In the initial aftermath of the purchase, your customers will have higher support needs from your B2B website, ranging from technical support to questions about migrating from a competitor’s product to requesting adjustments.
What a good B2B website design needs at this stage:
- Technical support,
- Contact information for service and account representatives,
- Turnaround time for service,
- Implementation and migration guides,
- Technical documentation,
- Content on how to get the most value from the product.
Providing top-notch customer support is therefore essential in this stage. If you’re using email to do that, using an email verifier to ensure good deliverability might be a good idea.
Upgrade and Maintain
At this stage, your customers will be looking to extend the life of their purchase as much as possible. For large mechanical equipment, this often means buying parts, accessories, or consumables; sometimes users will want to upgrade service contracts to accommodate company growth. For software, this can mean purchasing upgrades, modules, and other stopgap solutions to make an older product retain usefulness until the next major purchasing cycle.
What a good B2B website design needs at this stage:
- Technical information for already owned products,
- Newer products that can replace older models,
- Add–ons, modules, and upgrades that can be added to the current product for more benefits,
- Parts and consumables.
Replace
The process starts again when a service contract ends or equipment reaches the end of its life.
What a good B2B website design needs at this stage:
- Newer products that can replace older models,
- Changes in the industry that require new equipment or services,
- Detailed specs,
- Clear product photos,
- Case studies,
- Testimonials,
- Downloadable product assets.
Understanding the purchasing phases for B2B customers is extremely important when you plan to implement user-centered design processes (UCD) while working on a website project. At the same time, if you already have a website, you can instantly identify the stages where your users’ needs are poorly covered.
Best Practices for B2B Websites
Demonstrate How You Solve Your Prospect’s Problems
B2B customers are ruthlessly focused on just one thing: how you can solve their problems. Your prospects come to you because their business faces a challenge they cannot deal with on their own, due to the lack of time, resources, or skills. Whether your prospects just need to replace the toner in the office copier, or they look for a partner to help them develop and implement a business strategy, they want to solve a problem. That’s why you should remember to always emphasize these topics on your B2B website and prove you know these challenges inside–out with solutions included.
It’s also a great practice to consider the context of the buyer’s problem and describe your products or services in a way that precedes any questions a client might have. Don’t just say “our cartridges contain 0.8ml of ink”, but rather “with our product, you can print up to 600 pages”. Another great example is Apple’s genius approach to marketing and their famous “1,000 songs in your pocket slogan” — they could have said “5GB of storage”, but instead they’ve turned the information around to make it more relevant to an average customer while addressing the issue of limited space on a device.
Another angle is to consider how people form their queries on Google. Most of the time, they’re not looking for specific models of printers — they will search for solutions to their problems (“why does my printer have lines”) or search for models with specific, non–technical characteristics (“which printer has the cheapest inks”) which also suggests an issue (in this case, limited budget). That’s why it’s important to target all these questions in advance and always be one step ahead of the customer.
Customers need to know immediately whether your organization has the capability to solve their problems. Provide signals on your site to let people know you cater to them.
It is worth emphasizing your unique value proposition too. Determine which elements of your business approach are key differentiators, then advertise them on the homepage and other relevant site areas. In this case, the price can be a key factor, but you should also include:
- Quick turnaround time for delivery of products,
- Quick turnaround time for services or consulting to begin,
- Customization, specialized products, and services,
- Unique feature set,
- Perceived quality,
- Compatibility with existing products or services,
- Location of the company,
- Shipping rates and delivery time.
Don’t forget to mention how you solved customer problems in the past. B2B prospects are seeking solutions to their challenges, and while a perfectly written copy might capture their attention, they will still demand proof.
Case studies, testimonials, reviews, and other ways of demonstrating success in past ventures are critical to turning skeptical website visitors into paying customers. For instance, you can offer reviews conducted by external, reputable sources or provide short and true-to-life case studies.
To summarize, demonstrating how you solve your prospect’s problems is a smart approach that can convince users to take specific actions and help you generate new leads on your B2B website.
Keeping Your Customers Engaged
Most B2B websites don’t sell to prospects immediately upon their first visit. With a long sales cycle, B2B websites have to be able to provide valuable information to prospects on a recurring basis in order to close the sale. In fact, the sites that provide the most helpful information to prospects are ones that they return to over and over again as they near the purchasing phase of the sales cycle. This recurring engagement is a crucial part of the customer success process, ensuring that businesses build strong relationships with their clients and guide them through the sales journey effectively.
Providing business value for customers and showcasing valuable content for them is one of digital marketing’s main tasks. There’s lots of talk these days about content strategy (which should be supported by content marketing) and its value for B2B websites.
Content is generated on a recurring basis to both build SEO (Search Engine Optimization) value and to draw returning visitors to your website. Content strategy is only valuable if it helps your prospects understand the business challenges that you solve, and why your expertise helps them.
Focus your efforts on describing common challenges your prospects face and how your company solves these issues. Remember when writing the content that many of your best prospects may have no idea who you are, but if you have a blog post that offers a simple breakdown of their problem, they’re more likely to revisit your website and put you on their shortlist. Providing useful resources differentiates you from your competitors by establishing your organization as having expertise and credibility — qualities every organization seeks.
Considering all of the above, you can use such types of resources as:
- customer guides,
- blog page with thorough articles,
- resource base,
- whitepapers.
So to increase organic search traffic and lead generation on your B2B website, you should optimize the content on the entire site not only for search engines but also for your specific target audience.
Create Good First Impression
A first impression can make or break potential transactions. People judge the company’s competence by the way the website looks. An organized and coherent website instills trust and proves competence. UI designers should keep in mind the “less is more” concept — cluttered design and bad information architecture will only lead to confusion. That’s why in the design process, this concept helps to prioritize user interface (UI) elements and, accordingly, reduce the number of unnecessary elements on each page layout.
Also, people have different expectations for what websites should look like depending on the industry. For example, people expect a website in creative industries to reflect a company’s philosophy. Technology companies aren’t held up to the same aesthetic standards as design agencies. More emphasis is placed on clean designs that express professionalism and expertise.
On the other hand, your UI design impacts the audience’s perception of your organization. In a split second, users interact with an interface and decide whether the website is worth their effort. When there’s a mismatch between a site’s user interface design and the company’s business image, people assume that the organization doesn’t have what they want and go elsewhere. UI design also serves another important purpose: people can instantly identify whether they’re on the right web page.
UI Design
Every UI or web designer should remember that a B2B website design isn’t about a lifestyle brand, it needs to convey professional expertise and competence. Carefully consider whether trendy design patterns and visual styles support a message of stability and reliability — especially since many design trends come and go. Pay attention to core design principles and visual guidelines that help users understand your website: visual hierarchy, negative space and balance, and element affordance.
No matter where your organization falls on the creativity spectrum, it’s important to have a simple interaction design. Simple interaction models match people’s mental models by behaving in expected ways. Business customers need websites to streamline their processes, answering their questions quickly and easily. Although creative designs can be delightful, simplicity must come first.
Subtle Cues
Make your UI design more user-friendly and provide subtle cues. Even when users think a website has what they want, scrolling takes effort, and they typically do it only if they see the proper visual cues. How you place critical elements on the web page can dictate whether people scroll or not. Placing indicators such as headers or content that peeks out into the display’s viewable area suggests that there’s more content below.
Loading Time
Make sure that your site loads quickly. If it takes more than six seconds to load, the users abandon the site. To avoid that, remove unnecessary elements and media that negatively impact page speed. Buggy or unstable elements that take too long to load reduce the user experience and prospect’s impression of your organization. Optimize file sizes and minimize loading time, especially when designing for business audiences.
Also, make sure you pick the best web hosting provider.
Tone of Voice
Use a reasoned, neutral voice on your website. Avoid excessive marketing-speak and meaningless sales phrases. Business customers prefer a straightforward tone that describes the company’s business without hyperbole. Easy access to information and even-handed comparison of products or services make participants feel like the company has nothing to hide.
Content
Write and present content in a way that optimizes scanning, for example by using such elements as headings, subheadings, large type, bold text, highlighted text, bulleted lists, graphics, and captions. Write text that is short and to the point. Don’t overload people with too much text; that can feel overwhelming and intimidating. Instead, use concise and simple language, as well as break up large blocks of information into short paragraphs.
About Us Section
Offer the About Us section regardless of your company’s size. Sometimes small and medium-sized businesses neglect to have an About Us section on their website, thinking it’s not important.
Surprise — it is. According to B2B Web Usability Report from 2015, 52% of respondents indicated that they want to see the About Us section on the vendor website home page. Only two other pages — Contact and Products & Services — got higher results (64% and 86%, respectively).
The About Us page is particularly important to companies whose brand is not widely recognized. On the other hand, household names can afford to neglect this section.
Navigation
Users prefer consistent navigational structures, especially in business situations where time is scarce. Consistent navigation helps users visualize their current location in site structure and identify alternative options, making it easier to find information and keep track of where they are. Make sure that links in header and footer navigation are named and grouped correctly both on desktop and mobile devices.
Key Takeaways
- Prove your professionalism and expertise to your potential customers at every step. The key is to understand your prospects’ problems and provide appropriate solutions that are better than your competitors.
- Engage your customers at each stage of the purchasing process. Provide meaningful content and valuable resources that keep the user’s attention.
- Create a good first impression using appropriate UI design, tone of voice, and convenient navigation that streamlines purchasing processes.
Conclusion
Whether you use all of these practices or just a few, remember to keep in mind that you create a B2B website design for your target audience. If you don’t know the specific problems and needs of your target audience, you should run user research first, or else you’ll totally misjudge your prospects and give the wrong impression.
If you’d like to learn more about shaping your content towards a specific audience and how to generate leads, read this article on Customer Acquisition Strategy. Without that knowledge, even all those tips on UX/UI design won’t save you from lack of engagement.
So keep all that in mind and design away!
Agile Principles Explained: Definitions and Examples for Software Development
Agile was founded based on values and principles. It’s not a methodology or a philosophy to get things done but rather a framework, and a collection of beliefs teams use to make decisions. The Agile principles will help you guide your team on the right […]
AccessibilityAgile was founded based on values and principles. It’s not a methodology or a philosophy to get things done but rather a framework, and a collection of beliefs teams use to make decisions.
The Agile principles will help you guide your team on the right path, even when you’re unsure of your next step. In this article, we will explain the 12 Agile principles and how these help software teams adapt, optimize, and improve the development of software products or services.
What is Agile?
Agile refers to methodologies focused on iterative development where processes and solutions occur through continual collaboration among cross-functional teams.
Instead of following a well-defined and strict plan, Agile teams focus on continual improvement and efficiency. They work under “sprints,” which consist of specific tasks or deliverables boxed in a time frame. Each sprint typically lasts from two to four weeks, but this depends on the product in development. What’s worth noting is that sprints are not used in every single Agile approach. Kanban, for example, doesn’t use it.
In software development, Agile transformed entirely the way teams structured processes. Before Agile, software development life cycles like Waterfall focused on delivering software through a linear and rigid process.
With Agile, there’s no set of rules, procedures, or hierarchy that needs to be followed. The Agile software development life cycle (SDLC) focuses on breaking the process into manageable actions that can be continually improved until it reaches its primary goal. What matters is to deliver the best result possible.
A group of 17 engineers created Agile, focusing on building an efficient foundation to manage projects. However, since its inception, Agile has been more than a series of methodologies.
With 4 core values and 12 principles, Agile has become a globally accepted mindset for managing projects.
4 Agile Values
The Agile manifesto has 4 values and the 12 supporting principles that lead the Agile approach to software development.
1. Individuals and Interactions Over Processes and Tools
You can have high-tech tools and solid processes, but it’s the team that determines a project’s success. This value focuses on the importance of having teams with fluid communication who can respond to changes and customer needs. No matter if your team uses Slack, Microsoft Teams, or a virtual phone system, you simply must communicate clearly to work well.
2. Working Software Over Comprehensive Documentation
One of the reasons software development was slower and ineffective was due to all the technical specifications, requirements, documents, extensive planning, etc. Some Agile requirements are presented as a user story, which helps speed up the process. Documentation is still valuable, but working software is even more valuable in Agile.
3. Customer Collaboration Over Contract Negotiation
Agile aims to have customers engaged and who collaborate throughout the development process. Instead of having a negotiation period to outline all project details, it focuses on having a collaborative relationship from the start resulting in customers being heavily involved in the process. This makes it easy for Agile teams to quickly implement the customer’s feedback, understanding their needs and requirements.
4. Responding to Change Over Following a Plan
What characterizes Agile is that it embraces change. Instead of having a very strict and specific plan of development, the project should focus on delivering value. The definition of what value means for the project will vary, along with the project scope.
The 12 Agile Principles Explained
What are the 12 principles of Agile?
The 12 Agile Manifesto Principles are designed to help teams focus on what’s important, such as efficiently delivering valuable software, embracing change, working collaboratively, and prioritizing the customer’s needs, among other things.
These are the 12 principles of Agile explained:
1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Understanding customers’ changing expectations is one of the priorities in Agile teams. Instead of having a linear structure, where they engage with customers only at the start and end of the project, Agile emphasizes the importance of having a continuous cycle of feedback and improvement.
Agile understands that a customer’s needs might change or evolve, so instead of focusing on a rigid plan, teams focus on a series of iterations followed by customer feedback. This way, it’s easier for the product to be aligned with customer expectations and allows the team to focus only on valuable features.
Example:
As this principle focuses on the continuous feedback cycle, Agile teams often build a minimum viable product (MVP), and its response informs future releases. Product teams can test and validate their ideas by using MVP and experimentations. Teams do not release a final product, but iterations continue to make improvements until the product has reached a certain level of satisfaction.
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
One of the main characteristics of an Agile project is its adaptability. This second principle means that teams need to be willing to make changes to stay competitive even when the project is advanced.
Often, software teams think that the most reliable way to achieve a successful product is to make a solid plan and stick to it. But for Agile, it’s the other way around. Allowing change is necessary for teams to gain a competitive advantage.
Agile teams embrace change and are continually reconsidering their strategies and processes to ensure the quality of the product.
Adaptation and the willingness to change are part of Agile’s core strengths. Allowing change becomes necessary for teams to gain a competitive advantage.
A good way for strengthening your adaptation skills though may be taking part in agile project management training online. Especially, if you haven’t worked in the Agile methodology just yet. Learning directly from experts can particularly speed up the whole process.
Example:
Instead of prioritizing having well-documented plans, the Agile team focuses on observing the market, the customer needs, studying them in-depth, and being aware of the competitive threats they might face along the way.
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
As mentioned, for Agile, the clients’ and stakeholders’ feedback is fundamental. Instead of waiting to build a final product to present it, Agile focuses on delivering work frequently.
This means that Agile teams work with “sprints” where tasks and goals are usually planned in the short term.
Sprints allow customers to see how the product is evolving and for the team to evaluate if there are improvements to be made. The idea is to achieve goals on smaller scales that will ultimately contribute to the product as a whole. Teams are aware of the specific goals they need to reach while adapting and changing the product until it fulfills the customer’s expectations.
Example:
Software development teams work in sprints with a set timeframe between 2 and 4 weeks.
4. “Business people and developers must work together daily throughout the project.”
The fourth Agile principle focuses on unifying departments, prioritizing collaboration regularly. The idea is that customers, key stakeholders, and leadership work hand in hand with developers, strengthening the communication channels to ensure everyone is on the same page.
During the development of a product, business and tech groups work together consistently, building trust and transparency throughout the process. It also helps give immediate feedback to developers making sure that new arising requirements and details for existing ones are taken into consideration.
While, for some teams who haven’t applied Agile, having everyone involved through all the stages might seem like it will cost more time, in the long term, it’s more beneficial because it optimizes processes. It helps teams recognize gaps between business and tech teams early enough to avoid future problems.
Transparency while delivering a product is crucial on both sides. Businesses should be aware of development status and blockers as much as developers need to be aware of all market/business or organizational restraints of the project.
Example:
Agile teams prioritize regular meetings. For instance, every day, they have a daily meeting that takes only 15 minutes, and each member of the group shares what they are currently working on and if they have had any roadblocks.
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Usually, at the start of the project, where the planning and first steps take place, the team is motivated and ready to get started. However, it is harder for individuals to stay motivated and focused on the final goal when problems arise.
Agile principle 5 emphasizes the importance of choosing the right people with the right skills and roles to be part of the project to achieve success. And it also encourages team leaders to give them the necessary tools and resources.
Motivating team members is also about listening to their ideas and showing that it’s important. Giving team members the confidence to speak up is also a way to help them improve their performance.
This principle also focuses on trust, which translates into avoiding micromanagement. A key aspect of the Agile framework is to empower team members through trust and autonomy.
Example:
Team leaders need to ensure that developers understand strategy and requirements before development starts. Not necessarily focusing on how something will be built, but more on the “what” and “why”. The delivery team is who determines the “how” through the process.
The goal is to provide support when roadblocks appear and brainstorm on possible solutions through the sprints, not micromanaging.
6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
The sixth Agile principle translates primarily into two things: Communication and collaboration. The most effective way for teams to be on the same page is to communicate continually.
While this principle focuses on the face-to-face aspects, something to keep in mind is that it was written two decades ago, when Zoom and other remote tools weren’t part of the panorama.
In today’s world, applying this principle is not for face-to-face exclusively, but it highlights the importance of meaningful connections and conversations. While email and texting are fast and easier alternatives, video calls, and even regular phone calls are the best channels for remote teams to communicate effectively.
Example:
This principle is applied in software teams through daily meetings, brainstorming sessions, sprint planning meetings, frequent demos, and pair programming.
7. “Working software is the primary measure of progress.”
To understand this principle, let’s rewind to pre-Agile times to understand how teams used to measure success.
As mentioned, in many cases, software development was a hierarchical and linear process. This meant that teams, instead of working through iterations, left most of the testing and refactoring to the final stage. In the end, this left unhappy customers and many problems to review and improve, and that took time.
Agile focuses on maintaining a working software, measuring the progress of what has been completed. Each feature and addition is reviewed by the tech team and the client. So when it’s time to work on the next steps, the client is happy, and revisions and testing have already taken place.
Working software is not the final product, but it refers to each iteration. Agile teams work on Minimum Viable Features. That way, they measure success by delivering a working product that satisfies customers.
Example:
Software teams design and release Minimum Viable Features instead of fully-fledged features to get feedback and validate the product while building software. This makes agile teams have the capacity to adapt to change and gain a competitive advantage, as explained in the previous principles.
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
The key concept in this principle is “sustainable development.” What Agile means by this is that project managers and leaders should set realistic and clear expectations, even if that means that a project will take longer than expected.
In some cases, software development teams set high expectations trying to fulfill all requirements in a short period. And the problem is that putting in extra time to meet deadlines quickly burns out the team, impacting the quality of the outcome, morale, and motivation.
The idea is to strengthen morale by encouraging a healthy work-life balance with realistic goals. It’s not about finishing projects fast, but about making them at a constant rate.
Example:
Before every sprint takes place, teams need to consider the amount of work they can commit to. Instead of overpromising and not fulfilling expectations, teams should set realistic goals without adding more tasks through the process. Once a sprint starts, teams stick to the goals and tasks they have already established.
9. “Continuous attention to technical excellence and good design enhances agility.”
This principle focuses on constantly reviewing the product after every iteration. Agile promotes continuous attention to technical excellence and good quality design.
The purpose of this principle is to encourage teams to avoid shortcuts just because they want to finish a project faster. Most of the time, shortcuts become more costly in the long run.
Example:
Developers and the product management team work hand in hand to understand if the technical debt is acceptable. Usually, they will need to allocate development resources to refactoring efforts.
10. “Simplicity—the art of maximizing the amount of work not done—is essential.”
This Agile principle focuses on keeping processes as simple as possible. In other words, it talks about working smart, not hard.
Agile teams recognize what adds value to a project and what doesn’t, which enables them to maximize the resources that best serve their project. Too many features and planning are avoided at all costs. The idea is to avoid distractions and streamline the cycle to make it more efficient.
For Agile, simplifying and focusing on the things that truly matter is what has the most impact. In a product management context, leaders should always be focused on prioritizing, even if that means making difficult decisions.
Example:
Product managers are strongly aligned with organizational goals, and the customer wants and needs. This makes them selective in the user stories and features they pick. With prioritization techniques, they ensure that the strategies they implement always have a purpose and a “why” behind them.
11. “The best architectures, requirements, and designs emerge from self-organizing teams.”
Self-organizing teams are made up of a committed and motivated group able to plan, estimate and complete the work autonomously while engaging with the customers. This also breaks down the traditional vertical management style.
This Agile principle focuses on self-organizing teams that work under a more flat and horizontal management style. This translates into autonomous teams capable of acting faster, as they don’t need permission for every decision they make.
Example:
In practice, Agile teams are autonomous groups in an organization that have full control over their projects and take ownership in such areas.
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
This last Agile principle encourages leaders to take time to evaluate what the team has done, how they’ve performed, and how they can improve.
Agile focuses on delivering products through continual improvement, always considering feedback. Similar to this process, teams need to frequently evaluate their process and see ways to make it more efficient.
Example:
The idea behind this principle is to have sessions where the team reflects on their performance and discuss ways management and technical skills can be improved.
Key Takeaways
Agile Principles focus on providing guidelines to ensure teams focus on the right things. These are the 12 Agile Principles, explained in simpler terms:
1. Customer satisfaction through early and continuous delivery of software.
2. Focus on working on smaller and achievable tasks.
3. Adhere to a timeframe for the delivery of a working product.
4. Stakeholders need to frequently collaborate throughout the entire development process to ensure the project moves in the right direction.
5. Create a supportive environment that motivates team members.
6. Constant communication is key to a project’s success.
7. Progress is measured by working software.
8. Maintain a constant and realistic pace of development.
9. Always keep an eye out for technical details.
10. Simplicity is key.
11. Promote self-organization.
12. Reflect on the team’s performance to continue improving.
Conclusion
Thousands of organizations across the world claim to be Agile. However, as explained in the article, Agile is not a methodology or a philosophy; it is a framework.
Understanding the values and the principles of Agile provides teams with a foundation to make the right decisions, create quality software, and solid cross-functional teams.
Web App vs Mobile App: Which One to Invest in?
In fact, it’s projected that in 2022 the mobile app revenue worldwide will reach $808.7 billion, and in 2023 it’ll reach the astonishing number of $935.2 billion. Compared to 2014, the revenue difference would be $837.5 billion. Quite impressive, isn’t it? There’s also a wide choice […]
AccessibilityIn fact, it’s projected that in 2022 the mobile app revenue worldwide will reach $808.7 billion, and in 2023 it’ll reach the astonishing number of $935.2 billion. Compared to 2014, the revenue difference would be $837.5 billion. Quite impressive, isn’t it?
There’s also a wide choice of available options when it comes to the development of web or mobile applications. What’s the difference though? Do they actually differ, even if they look the same? In this article, we’ll cover all sorts of information about web apps, mobile apps, and how they’re built. What’s more, we’ll try to resolve the web app vs mobile app clash once and for all!
Web App and Mobile App – What’s the Difference?
Have you ever been confused about what a web app and a mobile app are? After all, they look very similar, right? The devil is in the details, so to speak.
Web apps and mobile apps, although they share some similarities to each other, they’re two different types of applications. At first glance, you may notice very few differences between the two as they almost look entirely the same. Design, custom logos, color scheme, functions, icons, they’re probably placed in the same spots. To bring these components to life, the use of cutting-edge AI tools can be of great assistance.
But don’t let this fool you, these two applications are even made differently. One classifies as a web application, and the other is a native mobile app.
The core difference is that native mobile apps are dedicated applications for specific mobile platforms, i.e. Android or iOS, whereas web apps can be accessed through different internet browsers on a computer or on a mobile device.
A great example of how a native app looks compared to a web application would be Uber Eats. You can access it through your mobile device by downloading an application or by accessing the website through your phone’s browser. They will look similar but will be different.
One more noticeable difference between a mobile and a web application would be the ability of native mobile apps to work offline, to a limited extent of course.
Native apps are built from scratch for the mentioned platforms. Users can download them through either App Store or Google Play. That fact alone increases the safety of the app. They require updates that can be done manually or automatically, depending on your preferences. That’s not the case with web apps though, as they are updated by the creators, whenever an update is ready, and it doesn’t take as much time as for the mobile apps.
Coming back to native apps, if you’d like to release an application with paid services for – let’s say – iOS, you’d have to pay a large fee to Apple for every made transaction.
Planning
Before proceeding to the actual building process, it’d be wise to plan your strategy ahead. What we mean is that you could follow one of the software development lifecycle models that would make the development and entire process easier and less complicated, as you would have every step planned and written down.
What’s more, think about your team, what roles would you need for your project. Two roles that you’d definitely need would be a web developer and web designer.
Building Process
Mobile apps are a much faster solution than a typical web application when it comes to performance. Let’s focus on the latter for now. What differentiates a native app from a web app besides the platform? Well, a number of functionalities or time spent on the creation. Your typical programming language or syntaxes for web apps would be either JavaScript, HTML, or CSS. With the help of CMS (like WordPress, Drupal, or Umbraco), devs can build them at a much faster rate.
Things are a little bit different for mobile apps. With more functionalities, native apps have to be developed in a specific programming language with the help of IDE – Integrated Development Environments (though IDEs are not limited to native apps). Additionally, the chosen programming language depends on the target device. For example, if you want to create an application for iOS, you would have to use Swift or Objective-C language. The same situation happens for IDE, as the default for creating apps for iOS would be Xcode. On the contrary to web apps, native mobile apps can be created with SDK – software development kits that are provided by Google and Apple. They can make the mobile app development much better and easier.
How about devices that run on Android? Well, in this case, you’d probably use Java or Kotlin programming languages along with Eclipse IDE or Android Studio software development kits.
There’s also HarmonyOS that’s worth mentioning but it’s much less popular than iOS or Android. So what languages would you use for creating Harmony apps for Huawei? The answer is either C, C++, Java, JavaScript, or Kotlin.
What should you do in a situation where you want to release the native app on multiple platforms? In this particular case, the best solution would be to use one of the cross-platform languages, like Flutter. By doing so you can develop a hybrid app that will land on every mobile platform.
To do so, you can use either React Native, Xamarin, or Cordova.
Pros and Cons of Native Mobile Apps
Examples of native apps: Spotify, Pokemon Go, WhatsApp
Pros and Cons of Web Apps
Examples of web apps: LinkedIn, Yahoo.
There’s a common ground though, and it’s called progressive web apps. Is it a good solution? Let’s find out.
Progressive Web Apps
A progressive web app (PWA) is a web application that combines features of both native mobile apps and web apps. What exactly? For starters, the ability of mobile apps to work offline. Even though it’s still a web application, it features something called Application Cache that allows it to work without an internet connection. Similar to web apps, they cannot be downloaded but accessed through an internet browser. Though they still can be added to the home screen.
Many programmers additionally use web frameworks like Angular or React to help them build their applications.
PWAs philosophy is based on three core pillars, they have to be:
- Capable;
- Reliable;
- Installable.
Examples of PWAs: Starbucks, Trivago, The Washington Post.
Hybrid Apps
Hybrid mobile apps may seem similar to PWAs, but they’re definitely not the same. Hybrid apps are a mix of both native and web apps, but they can be downloaded from the app store on either Android or iOS.
It’s a great option for those who wish to try out their idea before investing a lot of money. By developing the MVP release, you can see how your app is doing, take suggestions or release fixes.
Examples of hybrid apps: Instagram, Gmail, Twitter.
The Dilemma
Are you perhaps stuck on deciding whether it’s better to create a web app, PWA, or a mobile app? Check out these facts that may help you make the choice!
As we mentioned before in this article, the number of mobile users grows year by year, month after month, and day by day. In fact, there are more mobile phone users than ones using desktops.
But what factors should you take into consideration when choosing one of the two options?
Costs
If you’d like to start with a mobile app then you better have your wallet at hand. Developing a mobile app instead of a web app requires a higher budget. Additionally, if you’d like to release the application on iOS and Android simultaneously, that will cost extra, both in terms of money and time.
Bottom line is that developing a website application or PWA first is a cheaper option (that of course depends on your idea and goal).
Speed
When it comes to speed, web applications lose (though the difference is minimal). Even though PWAs are still faster than web apps, native apps win the race because they’re launched directly from your device.
There’s a downside to it though. In order to access the mobile app, you have to download it first, whereas to access a website app you only need to type in the address and wait for it to load. For PWAs you don’t even have to launch your browser (with the exception of the first time). You can pin the shortcut to your home screen and access it from there.
Another advantage in favor of a mobile app is the ability to work offline, though probably with limited functions.
Accessibility
A well-written website application should work just fine on every platform, whether it’s Windows, Linux, macOS, Android, or iOS. On the other hand, even a well-written native app can work only on one platform. If you’d like it to work on a different one, you’d have to develop a new code from scratch. Definitely a downside of mobile apps.
User Preferences
Since the start of the SARS-CoV-2 pandemic, our lives have changed drastically. Many of us had to give up on social interactions for the time being. Plenty of employees have been sent to work from home and it’s not the only thing that has changed.
People started using their smartphones or mobile devices even more than they used to. The actual amount of hours spent on mobile apps by an average person is 4.2 hours daily which is a 30% increase compared to 2019. That’s more than half of a typical day of work.
The reason for bringing this up is that the web itself is less browsed by the users, but applications are on the top right now.
Visibility in Search Engines
Unlike mobile apps, web apps can be easily found on the internet due to the fact that they can be indexed by search engines. In order to have your app rank high when it comes to downloads and ratings, take proper screenshots showcasing the design and functionalities of your app. Without such actions, it would be much harder to find the application in the app store, compared to the website.
What’s your Target Audience?
Before allocating your budget to either mobile or web applications, think about your target audience. Do you want to develop a business web application for your company? Or perhaps you wish to create a social media platform that could potentially gather people with similar interests? Or maybe you want to start a pet store and develop an e-commerce website for it?
If the former is the case, then creating a web application would be a wiser choice. If your idea is more like the latter, then only the sky’s the limit.
The Verdict
It’s time to summarize all the things we learned about native, web, hybrid, and progressive web apps so far.
As we mentioned before, your go-to app should be chosen based on your idea and target.
Real-Life Stories
Starbucks
Everyone heard about Starbucks. It’s one of the most popular coffee shops in the world. Let’s jump right into the time machine and head back to the year 2009.
You can hear Flo Rida’s or Pitbull’s songs all around, David Guetta is just becoming popular, and Starbucks just released their myStarbucks app. It lets the users find coffee shops in their proximity, learn about different coffee types, and more.
That was just the beginning of Starbucks’ online presence. In 2011, Starbucks released a loyalty program aimed at people who use the Card Mobile app. That move enabled users to make payments through their phones. In the following year 2012, Starbucks integrated their native app with Square and Apple passbook, the former is a payment system for mobile devices, and the latter is a place where you can keep your loyalty card information.
That’s still not everything. In 2017, Starbucks decided that it was time for a change. With new app ideas, the company released a PWA with everything that the user needs, like images, animations, and of course, offline accessibility. Customers could finally learn about the offered products, and their nutritional values, and could customize their orders, all done without internet access.
It turned out to be a huge success, as Starbucks doubled its daily active users. Moreover, compared to the huge and heavy iOS app (148MB), their PWA only weighs 233kB.
Everyone either has an account on Instagram or knows someone that does. It’s one of the biggest success stories regarding mobile apps. The picture-sharing platform gained a massive number of 100,000 users. To make matters more interesting, it even happened in the first week of its initial launch.
Released in 2010, Instagram continues to be one of the most popular social media platforms. Nothing speaks of success more than money, after all, Instagram was bought by Facebook in 2012, for approximately $1,000,000,000. Just wow.
From the companies’ point of view, now they can post to Instagram from a desktop for better quality and share engaging content to attract new audiences and interact with existing customers.
Pinterest is yet another success story of a low-performing website turned PWA. The company wasn’t doing very well. They had a slow-performing website with not as many views, and a poor conversion rate of 1%.
Even though Pinterest already had iOS and Android apps, they still couldn’t manage to get the wanted results. That’s when the idea of a progressive web app started to form.
Pinterest just hit a jackpot! Their core metrics increased, and users spent 40% more of their time on the app compared to the website. Even better, the company noted a 44% increase in revenue coming from the ads, as well as a 60% increase in user engagement.
After all, their PWA only weighs 150kB.
Trivago
The Trivago situation is a little bit different. They didn’t suffer from low numbers of views or lack of interest. Quite the opposite, actually. They were getting more and more visits from mobile users and it was time to think about the future.
Creating a native mobile app from scratch seemed like an expensive and problematic idea. The question of whether people will actually download the app has been one of the issues. Another one was the noticeable connection problems among the mobile visitors. These facts forced Trivago to rethink the idea.
Since native apps are out of the question, the company decided to place its bet on a progressive web application. The number of advantages like browser accessibility, push notifications, offline access, or the ability to add a shortcut to your home screen, had solidified the idea.
Was it a good idea? Did they succeed? They definitely did! Up to 2019, Trivago has been added to the home screen more than 500,000 times! Available in 55 countries and in 33 languages, the company’s user engagement increased by 150%. And that’s not all. Their repeated visits increased from 0.8% to 2%, and the push notifications contributed to increasing the conversion by 97%.
Key Takeaways
I promise, we’re almost here, but before we head to conclusions, let’s summarize what we’ve learned so far:
- Web applications can be accessed through the internet browser and are good for business websites, social media, etc.;
- Progressive web apps can be accessed through both the browser and the home screen, and they’re great for social media, news, and more;
- Hybrid apps can serve as a great starting point for testing the MVPs;
- Native apps are ideal for mobile games and other applications that require high performance and high usage of device’s components.
Conclusions
And here we are! We went through quite a lot of information here, starting from the difference between a mobile app and a web app, through planning, building, properties, and pros and cons of PWAs, hybrid, native, and web apps, to the dilemma, verdict, and some real-life success stories.
After reading this article you should be able to tell the difference between all those apps and decide which one would suit you and your business best.
Best Web Development Blogs To Follow Right Now [2022]
With this list of 10 best web development blogs, with a treat of best YouTube channels and podcasts, you’ll be able to stay up to date with the latest web standards on all fronts — front end, back end, as well as UX/UI design, and every […]
AccessibilityWith this list of 10 best web development blogs, with a treat of best YouTube channels and podcasts, you’ll be able to stay up to date with the latest web standards on all fronts — front end, back end, as well as UX/UI design, and every other branch pertaining to the web development services.
Your experience doesn’t matter; if you’re a code newbie looking for new skills or you’re a veteran in the coding world looking for latest news, new standards or solutions to unconventional problems, this list is still for you. And even if you’re neither, and you simply want to discover all the things web development is about, stay on this page and read on!
Top 9 blogs for web developers.
1. A List Apart
Main Topics: Code, Content, Design, Industry & Business, Process, User Experience
Audience: Front end Developers, Project Managers, UX/UI Designers, Graphic Designers, Content Creators
A List Apart is a webzine that’s been active for 23 years now, with a focus on web design and development, web content and its meaning, best practices and standards of modern web. Most of the content consists of opinion articles, ranging from future trends to environmental impact of IT and career advice. That’s why this site is wonderful for people who are not involved directly with web development — they can prepare themselves for better teamwork, understand common practices and be able to spot frauds during recruitment.
The articles are of the highest quality. They do invite writers to submit their pieces, but they’re all diligently checked over, reviewed, and edited. It’s not easy to submit a guest post, but they promise that it’s very rewarding. So you can expect to find articles from other IT professionals, keen on sharing their coding expertise.
A List Apart doesn’t stop at blogging. They also organise An Event Apart, a conference in San Francisco (which you can also join online) that’s known for being informative, educational, as well as inspirational. For some, it’s an event you can’t miss, especially since the invited speakers are well–known industry leaders.
And if you’re looking for knowledge condensed in one place, check out their book: A Book Apart, for those who design, write, and code.
2. Codrops
Main Topics: Tutorials, Resources, Code, Design, User Experience
Audience: Front end Developers, UX/UI Designers
Codrops is a fantastic source for front end developers, full of inspiration, useful tutorials, free resources that we all love, and articles with practical advice.
Their tutorials are long and comprehensive, and easy to follow through. They have plenty of embedded images, experimental videos, and lines of code shown in action. So if you want to learn fancy tricks, from creating infinite circular galleries to kinetic typography and glitch effects, this is your go–to site. Just like when you need inspiration: Codrops regularly posts Inspirational Websites Roundup, UI Interactions & Animations Roundup, and many others to spark your creativity.
If you’re not experienced enough to jump straight into tutorials and want to start with the CSS basics, there’s a CSS Reference library with the most important properties and information for you. All for free!
And if you want to know what’s happening in the tech world, check out their Collective, bundles of posts highlighting the latest news and resources.
For non–coding people, it’s a good site to see what can be done, and what the possibilities are.
3. CSS Author
Main Topics: Resources, Design, Content, User Experience
Audience: Front end Developers, UX/UI Designers, Graphic Designers, Content Creators
CSS Author is a front end coding blog that’s a goldmine of resources for web developers and web designers alike, with occasional publications useful for graphic designers and content writers as well. It has a staggering amount of “freebies”: you can find mockups, icons, and templates for WordPress and CMS, such as Magento or Drupal, etc. They’re all available for personal and commercial use.
This site acts as a good place to find free libraries, plugins, bootstraps, and tools for developers working with HTML, CSS, Java Script, jQuery, PHP.
4. CSS–Tricks
Main Topics: Tutorials, Resources, Code, User Experience
Audience: Front end Developers, UX/UI Designers
CSS–Tricks is a site you can count on to be constantly posting, sometimes even several times a day. They focus on CSS, HTML, and Java Script in the form of tutorials, guides, tricks, and articles. They range from animation, typography, accessibility, web performance, serverless, and many more. And if you’d rather watch a video than read — there’s more than 200 video posts to choose from.
When it comes to resources, there’s an Almanac with CSS Selectors and CSS Properties with lots of examples and demos. If you’d like some concrete knowledge in one place, the author of the site, Chris Coyier, has two books that are available to MVP Supporters.
5. David Walsh
Main Topics: Tips and Guides, Code, Mobile Development, User Experience
Audience: Full–Stack Developers, UX/UI Designers, Content Creators
David Walsh is a personal blog, run by a professional senior full stack engineer
working for MetaMask, who also used to work for Mozilla for eight years. So you can be sure that the guy knows what he’s talking about.
Besides tips and guides mostly on JavaScript (React, Node.js, jQuery), HTML5, CSS3, you can also find sneak peeks into a life in a web development industry, some career advice, and even interviews with other experienced developers. He’s a firm believer that practice triumphs over theory, and that experiments are a worthy pursuit. This approach has resulted in almost 83,000 followers on Twitter.
If you want to discover what a successful web developer needs to make an impact, following David’s blog is a good choice. Especially since new articles just keep on coming, even though the blog has been up for more than a decade.
There’s also some advice on technical SEO, so Content Creators should definitely take a closer look.
6. Dev.to
Main Topics: Tutorials, Code, Graphic Design, Content, User Experience, Industry & Business, Career Advice
Audience: Full–Stack Developers, UX/UI Designers, Graphic Designers, Content Creators, Project Managers
Dev.to isn’t really a blog and more of a community of software developers, but we couldn’t not mention it.
On the contrary to all the previous blogs, anyone can contribute to dev.to. All the posts published on the feed are tagged for easier navigation, and it’s easy to notice the popularity of Java Script, React.Js, Python, CSS, HTML, Node.js, PHP, Vue.js, and Ruby. There’s also a lot of content for beginners, as well as posts centered around career, testing, machine learning, and security, among others.
If you like podcasts, dev.to has hundreds of them, along with videos in the form of practical tutorials, guides, tips, and useful tricks. You can also find full blog posts that are often cross shared in places like Medium or Hacker Noon. And if you have trouble understanding a concept, you can ask the community to explain it to you “like you’re five years old”. It works wonders and is great even for non–tech people.
7. Joel on Software
Main Topics: Software Development, Project Management, Industry & Business, Career Advice
Audience: Software developers, Tech Leads, Project Managers, Recruiters, CEOs, Startup Founders
Joel on Software is another personal blog of an accomplished software engineer, Joel Spolsky, a creator of the project management software Trello and a Stack Exchange network. He shares his perspective not only on software development itself, but also on business, project management, recruitment, and getting started in the tech field, served with practical advice on career.
When it comes to the blog, which has been online for over a decade, it has more than 1000 useful articles. Anyone can find valuable content for themselves, from developers and tech leads to project managers, CEOs, and recruiters. Part of that knowledge has been captured into five books, available on Amazon.
8. SitePoint
Main Topics: Code, Web Application Development, Graphic Design, User Experience, Industry
Audience: Full–Stack Developers, UI/UX Designers, Entrepreneurs
SitePoint is bursting with books, online courses, and tech talks on topics of Java Script, HTML, CSS, PHP, Python, WordPress, Design & UX, App Development. The library is curated by the experts in web design and web development, so you can trust their input.
This web development blog focuses on a much wider range of subjects. You can learn more about the next wave of web technologies, such as Deno, Eleventy, Gatsby, Rust, WebAssembly, and many others. Reading the blog also ensures that you’re staying up to date with the future of the web and the state of the technology industry.
Not only web developers will benefit from paying attention to this blog, but designers as well. If you want to master Adobe XD, Figma or Sketch, along with any other similar programs, check out their materials. And even those that only want to polish their skills with Notion, Airtable, Obsidian, and other productivity tools, should also take a look.
It’s also a good place for people looking for a web development job or who want to advance their already prospering career. You can find articles full of advice for juniors and seniors alike, along with current job listings for remote positions.
And lastly, if you have questions that are still left unanswered after perusing the blog’s content, you can easily ask the community.
9. Smashing Magazine
Main Topics: Code, Mobile App Development, User Experience, Graphic Design
Audience: Full–Stack Developers, Mobile Developers, UX/UI Designers, Graphic Designers
Smashing Magazine is an online magazine of the highest quality, geared towards professional web designers and developers, offering them practical and useful content to improve their skills.
Their goal is to support the virtual community of the coding world with news on the latest web technologies, from app development, responsive web design to accessibility and usability, among many others.
New articles are published several times a week on a wide variety of topics, to keep front end developers, designers, animators, and illustrators more than satisfied. And of course, you can find articles to keep up with the latest trends and opinion articles as food for thought, along with productivity tips
Besides the articles, you can also jump right into guides, books, and online workshops. Not all of them are for free — to access them, you need to buy a membership. There are three levels: for $3, $5 and $9 a month or $30, $50 and $90 a year.
Don’t forget to check out this site’s podcasts. “The Smashing Podcast” runs around 1 hour each, so be prepared to gain a lot of new insight.
Smashing Magazine also takes care to post current job openings and present–day conferences.
Searching For Knowledge Beyond Blogs
Nowadays, blogging sites are not the only source of knowledge that’s worthy of our notice. Several times we’ve mentioned videos and podcasts, that’s why it would have been remiss of us not to list our favourites.
Youtube Channels
freeCodeCamp
FreeCodeCamp is a non–profit organization, supported by donors, with a mission to help people become developers for free. Besides a youtube channel, they run their own site with even more resources, and they also organize study group sessions around the world. They even offer certifications to give you an easier start in the industry.
FreeCodeCamp is perfect for self–learners. You can find there long and comprehensive courses for beginners on Python, SQL, Java Script, C++, C, Penetration Testing, HTML, Data Structure, React, HTML5, CSS3, Django, PHP, APIs, Laravel, and many more. Some of them even last for 15 hours.
TraversyMedia
Traversy Media is perfect for people who already know some basics and wish to learn something new in a quick manner without delving too deeply into each concept. Offered courses last from 20 minutes to 2 hours, with the more comprehensive ones available on Udemy. HTML, CSS, JavaScript, React, Async.js, Laravel, Rust, Ruby, Ruby on Rails, and many more — they’re all waiting to be learned and mastered while building projects from scratch.
The Net Ninja
If you prefer your courses divided into small, digestible parts, look up The Net Ninja. It’s perfect for beginners who want to learn bits and pieces on the run or in between other tasks. The overall tone is light and fun, due to the enthusiastic nature of the host, who is also very thorough and methodical in his approach.
You can choose what to learn next from over 1000 tutorials, that delve into Java Script, Firebase, Flutter, HTML & CSS, Laravel, MongoDB, Node.js, PHP, React, Vue.js, and many more. You can find both beginner and advanced material, so better keep a close eye on this channel.
Fireship
If you’re even more pressed for time, look up Fireship, a channel created by Jeff Delaney on the topic of building web applications of highest quality fast. His longest series is called “100 Seconds of Code”, which is straight to the point while being very informative. It’s perfect for those who want to grasp various concepts quickly before delving into them, or for those who simply want a reminder.
Besides that, you can find out more about development tools, pro tips, productivity tips, 15–25 minutes beginner guides, both for front end and back end, from Java Script to API and cloud infrastructure.
Coding Tech
If you’d like to take a step back from tutorials and to find out what’s happening during tech conferences without attending any, go to Coding Tech. They partner with many different conferences around the world and have their explicit permission to publish videos on youtube. Among their partners are ConFoo, JavaScriptLA, Pixels Camp, PyData, React Amsterdam, You Gotta Love Frontend, and many others. So if you want to stay on top of trends in the tech world, gain some valuable career tips while developing your hard and soft skills, subscribe without further delay.
Podcasts
JavaScript Talks / Conferences as Podcasts
JavaScript Talks was created with accessibility in mind. To bring conferences to those, who cannot attend them themselves, who can’t watch the videos due to visual impairment, or who simply don’t have the time to sit down and press play. It’s also a solution to those who lack a proper internet connection for one reason or another.
Thanks to this initiative, many people around the world can get access to Java Script conference talks, discover what’s new and, of course, to learn.
JS Party: JavaScript, CSS, Web Development
JS Party is a weekly podcast with a heavy focus on Java Script, but including as well Go, Ruby, Python, Node.js, and others. Besides talking about all things code, they also have episodes on developer’s culture, startups, sustainability, web development tools, and many others.
This podcast is well known for being informative (each episode lasts for an hour), yet at the same time, entertaining. With lots of banter involved.
React Talks
Interested in React? Then React Talks are perfect for you, with over 100 episodes, 1 hour long each. Every episode has a new guest invited to share their experience and expertise with React, from starting their career to leading some exciting projects to analyzing the newest and upcoming trends. If you like hearing stories concerning the web development world, listen to this one.
Syntax — Tasty Web Development Treats
Syntax is a podcast created by Full–Stack Developers Wes Bos and Scott Tolinski. It’s updated several times a month and each episode tends to last anywhere from 20 to 60 minutes. It’s well known for being fun, knowledgeable, and suited for both beginners and more experienced developers, improving their soft and hard skills.
Besides talking about their own experience as developers and dishing out career and portfolio tips, they explain Java Script and its frameworks, additionally venturing into HTML, CSS, Deno, development tools, freelancing, and many more.
Web Rush
Web Rush is another weekly JavaScript–centric podcast, run by John Papa, Ward Bell, Craig Shoemaker, and Dan Wahlin. They invite guests to share their stories of web development, challenges they’ve faced and the solutions they came up with. It’s full of practical advice and hands–on approach, making people excited to experiment on their own.
So if you’re curious about Google Maps behind the scenes, developing apps and themes for Shopify, or how to get started as a developer, check out this podcast.
Key Takeaways
Following a web development blog — still a necessity
Minimal commitment in website design won’t cut it. You need to stay up to date, which may seem like a challenge in the field that just keeps growing and changing. And if you’re not a web developer, but a graphic designer or a content creator, or an owner of your own website, it’s good to be aware of what’s happening on that front. This way you’ll create better content, by knowing what’s possible, what are the restrictions of web design, and what doesn’t work well in the long run.
And if you’re at the point of your coding journey where you can call yourself a professional, consider setting up your own web development blog or at least contributing to one. It’s a great way of giving back to the community and helping out those who are just starting. If you’re worried about creating competition for yourself, don’t — keep in mind the ongoing shortage of IT professionals that threatens the entire field and contribute to a better world instead.
Software Development Plan Made Easy
The Nature of Software Development Projects The first issue concerning software development projects is the fact that many of them are unique. So unless you’re developing the exact same software over and over again, the parameters differ too much to use them as a one stable point of […]
AccessibilityThe Nature of Software Development Projects
The first issue concerning software development projects is the fact that many of them are unique. So unless you’re developing the exact same software over and over again, the parameters differ too much to use them as a one stable point of reference.
The second issue concerns the rapid evolution of technology. We don’t even have to go back 50 years for comparison — it’s enough to see how much has changed just in the last decade. Software development has no choice but to reflect that in the form of constant new programming languages, frameworks, libraries, and tools.
On top of that, clients’ needs along with market demands change as well. Suddenly, the websites have to be SEO friendly, their mobile versions need to be top–notch to satisfy the constantly raising market share of mobile devices, and web apps need to be restricted to one single page, following the example of Facebook and many other successful projects.
Also, it will be beneficial to follow mobile SEO strategies to enhance user experience and improve mobile conversion.
It’s a lot. Each project has the potential to bring something new, and the proposed solutions can’t always be based on experience gained by the years of delivering different software. That’s what makes software development’s estimations so difficult — there’s simply too much uncertainty and novelty to be able to properly assess each project.
That’s also the reason why being an optimist doesn’t pay off. Assuming that everything will go well with no delays, that there won’t be any bugs to fix or last–minute changes, is naive. By thinking of the worst–case scenarios, you can predict many issues and prepare for them in advance — for example, by adding time buffers in recognition of sick leaves developers might have to take.
To properly and masterfully manage all those unknown variables, Steve McConnel, an expert in software engineering and project management, introduced a concept known as the Cone of Uncertainty. It’s a model describing the level of uncertainty throughout the whole project — at the start, the level of uncertainty is huge. The more time passes though, the more data you gather and therefore, the more you know. And so the challenge lies in achieving that level of knowledge as fast as possible.
Software Development Project Plan
Software development plan describes what needs to be done and how in a clear, concise manner, so that the whole team knows their roles and responsibilities, but with enough flexibility to reflect the tumultuous nature of software development.
Instead of having one strict deadline for the whole project, it’s divided into smaller parts instead, and the success rate is measured by milestones. Depending on the type of Software Development Life Cycle, the whole process will include iterations, revisions, and feedback. So even though it may seem chaotic at first, the whole team, as well as stakeholders, will know the state of the project at all times.
How does the software development lifecycle differ from the software development plan? The former is a specific roadmap, describing all the steps and their order necessary to complete the project, while the latter focuses on explaining the scope of the project and all its circumstances. In short, a software development plan explains what will be done and why, while a software development lifecycle explains how it will be done.
Now that we got all that out of the way, let’s move on to the phases that will ensure a proper software development plan everyone can rely on.
Defining The Problem
The first phase starts the moment the client contacts a software house. During the first talks, besides deciding on terms of cooperation, the client should say:
- What software project do they want exactly,
- What problem it should solve,
- What demand it’s answering,
- What business objectives or specific goals hide behind that decision,
- What will be the criteria of project success.
The software house’s responsibility is to discern whether the project matches the business decisions.
Think of it that way — the client doesn’t come with a project idea, they come with a problem. The vendor doesn’t deliver a project: it delivers a solution. If the solution doesn’t solve the client’s problem, it’s a waste of money. Period.
Finding The Solution
This phase focuses on discovering what can be done to fix the problem and how. And also, whether it’s possible to do so in the first place with the client’s budget, time limit, and other restrictions. That’s within the vendor’s responsibility to figure out, with the client’s help.
Here’s a time for settling on the project’s scope. Besides focusing on the how, it also has to be decided with what — when it comes to tools, languages, resources — and who — when it comes to the members of the software development team, any external groups whose help is needed, and who will be the project manager.
When all of the above has been decided, it’s easier to give a rough estimate of the budget and first deadlines.
Perfecting The Idea
Before digging into details, it’s important to decide on the essential features of the software project (usually via workshops). All the nonessential features should be categorized as “nice–to–haves” to ensure the right order of priorities. If your software project looks modern and sleek, but doesn’t serve its intended purpose, it’s a failure.
Only then you can start creating all the wireframes, user stories, and prototypes. Due to that, you can check if everyone’s on the same page, deal with any misunderstandings or dispel any doubts, as well as assess the risk. This part is also crucial to collect all the feedback you possibly can — mainly from the stakeholders and project team members.
At this point, a final estimation is possible: the scope of the project, the timeline, budget, and so on. There are still uncertain variables in play though: while the scope of the cone of uncertainty is smaller at this stage, it’s still significant enough.
Preparing The Environment
Once the whole scope of the project is known and understood by all, it has to be broken down into smaller phases that end with milestones. A good example of this is sprint, frequently used in agile development, which is a small time–boxed period with set tasks to complete. Sprint is repeated as many times as it’s necessary, till the project’s completion.
This approach ensures constant revision of what’s been done and what’s still left to do, making it easier to control and manage. Those frequent progress checks are also more convenient for stakeholders, who are kept in the loop throughout the whole project.
The biggest upside of creating such a project schedule is its flexibility. It’s easier to implement any change requests, catch glaring mistakes quickly, and to improve the software development process itself at any moment. Most importantly, it makes it simpler to check whether the product delivers significant value to the end–users.
Execution
Once everything on the project organization side is complete, it’s time for the developers to bring the idea to life. It’s also a good moment to set quality assurance in place, if it hasn’t been yet, to simultaneously fix bugs and any other reported issues. Additionally, you can also include User Acceptance Testing (if that’s applicable to your circumstances) or even involve your client in the final testing stages.
Delivering The Answer
At this point, software projects should be done with optional last–minute tasks and bug fixes left to do. But this stage should mostly focus on the release of the product and all the supporting processes surrounding it. Those can be: connecting the domain, activating the website’s certificates, adding payment features, and so on.
See also: How to Buy a Domain Name
All the results should be observed and analyzed, gathering feedback from users and responding to it. Especially if the product is in its beta version, it’s important to check how the users interact with the software, whether it serves its purpose, and if it’s up to everyone’s expectations.
The last thing left to do is the handover. The whole project needs clear and completed documentation, explaining the whole work done and the current state of the product. It ensures that in case of any future development needed, whether it’s further improvement or simple changes, the new development team will be able to jump right to work, without having to waste time to figure out the code. That’s why it’s also necessary for the code to be fairly clean and straightforward.
Common Mistakes In Software Development Planning
Since we know now how to construct a good software development project plan, it’s also proper to know what to avoid. The pitfalls tend to happen on both sides, on the client’s side as well as the vendor’s. Here’s a brief description of what can negatively influence the whole collaboration:
Client’s Perspective
- Lack of understanding and knowledge of software development process that leads to unrealistic expectations,
- Demanding drastic changes halfway through the project that go against initial principles,
- Not being clear enough on the requirements, needs, and goals,
- Too many people in decisive roles wanting different things and trying to answer the question of how to resolve the problem instead of sharing common goals.
Software Development Company’s Perspective
- Overpromising while overestimating capabilities and experience while not taking into account uncertainties,
- Bad communication with developers on the sales’ department side,
- Bad internal communication between team members,
- Putting up a wall between the client and the development team (often in the form of unnecessary middlemen),
- Not including any buffer in the schedule for fixes, unexpected issues, holidays, and sick leave,
- Neglecting to carry out tests with end–users before the release.
Key Takeaways
A good software development plan should include answers to the following questions:
- What problem does your client want to solve?
- What business results does the client expect?
- What can be done to resolve the client’s problem?
- Is it possible to resolve the problem within the client’s means?
- How can it be resolved?
- What resources are needed to resolve the problem?
- How will the development process look like?
- How will the project’s progress be measured?
- Was risk assessment conducted?
Best Web Development Tools in 2022
In this article, we’ll dive headfirst into the best web development tools available for developers around the world. From desktop development tools, through those available on Linux, to the ones that are meant to program apps for mobile devices. Without further ado, let’s get down […]
AccessibilityIn this article, we’ll dive headfirst into the best web development tools available for developers around the world. From desktop development tools, through those available on Linux, to the ones that are meant to program apps for mobile devices. Without further ado, let’s get down to business.
Best Web Development Tools
Development tools were created to make the entire process easier and faster, but with so many of them available on the internet, it’s really hard to pick proper ones. Luckily, you don’t have to resort to only one, but instead, you can have a choice of multiple tools. In fact, you can choose as many as you like or need because your web development project is worth it.
Code Editors (IDE)
Webstorm
Webstorm, also known as IntelliJ IDEA, is a popular and famous JavaScript IDE text editor that was released two decades ago in 2001. The latest stable release of the software was published on June 1st, 2021.
What makes Webstorm such a popular software are its features. Among many, the developers can find ones like:
- Code completion – the editor analyzes the written code and suggests how it should be completed;
- Plenty of supported programming languages;
- Supports version control software like Git;
- Supports various databases like MySQL, etc.
Though bear in mind that Webstorm isn’t free software. In order to use it, you have to pay $12.90 per month or $129 annually.
JetBrains company doesn’t stop here, as they offer more code editors. It all depends on your needs. Perhaps you need a code editor for PHP? Sure, there’s PHP Storm. You’re working on an application written in Python? Take a look at PyCharm. Maybe you like to program in Ruby? There’s an editor for you also and its name is RubyMine.
Visual Studio Code Editor
Also known as VScode, Visual Studio Code is a popular cross-platform source-code editor created and maintained by Microsoft. The tool incorporates a variety of features such as GIT commands, debugging options, and other useful tools.
Visual Studio Code can be upgraded with a wide choice of free extensions. To do so, you need to browse the marketplace and choose the ones that appeal to you the most. JavaScript and Python support also goes a long way for the app. VScode supports plenty, and we really mean plenty of programming languages for free. Take a look!
All things mentioned above make VScode an ideal text editor for programming your web development projects.
Atom
GitHub’s own, Atom is yet another cross-platform code editor on the list. Released in 2014, Atom is based on Electron software and supports many web technologies, such as C and C+, JavaScript, Python, and others. It’s ideal for developing desktop web apps as they can be customized with different APIs, themes, or plugins.
Thanks to being an open source code editor, Atom differs from Sublime Text or Visual Studio Code. In this case, you may wonder, what’s the difference? Well, due to Atom being open source it can feature more extensions and is more flexible in terms of development. And it’s free!
Sublime Text
Available for Linux, Windows, and macOS, the cross-platform Sublime Text is one of the best code editors for web development, as it features plenty of interesting and useful functionalities.
Not only that, Sublime Text editor also supports many syntaxes like CSS, PHP, Python, and more. Also, the software allows simultaneous editing, i.e. editing multiple lines of code at the same time.
Since this code editor includes so many features, the best way to visualize them would be to list them:
- Command palette that uses suggestions for quicker writing along with the ability to change syntax;
- Python-based API;
- 23 themes to choose from;
- Goto anything feature for efficient changing of projects.
In fact, 71% of software professionals confirmed using Sublime Text, Atom, or a similar text editor.
Development Tools
Chrome DevTools
You probably didn’t notice, but you most likely have it already! If you’re using the Google Chrome browser, you can use the Chrome DevTools any time you want. To do so, simply click the Ctrl+Shift+I button configuration.
Working with JavaScript, Chrome Developer Tools is essentially a set of built-in tools for web developers that allows them to change styles of the page through previews, check the technical aspect of any website, or view and change the Document Object Model.
Not only that, the Chrome Developer Tools gives the web developers freedom to do things like changing color palettes and formats, oversee the performance, set JavaScript breakpoints, edit CSS or HTML, and many more!
Here are some examples of the abilities of Chrome DevTools. With it, you can:
- View and edit CSS;
- Edit and view animations;
- Run JavaScript in the console itself;
- Check and view network activity;
- Manage cookies;
- Manage local storage;
- Simulate mobile devices;
- Debug JavaScript;
- Make the website faster by optimizing it;
- And many more.
Firefox Developer Edition
For all those who aren’t fans of Google Chrome, Firefox comes to the rescue. A direct competition of Chrome DevTools, Firefox Developer Edition is a web development tool that serves a similar purpose.
Including features such as WebSocket Inspector or Multi-Line Console Editor, Firefox’s alternative browser is ideal for people who wish to use a different web development tool.
CSS Preprocessors
Sass
Before getting into details of Sass, let’s briefly mention what a CSS preprocessor is. It’s software for generating CSS from the syntax of a preprocessor. Additionally, they can help the developer write the application faster.
Developed in 2006, Sass is the most popular CSS extension language. Being an easy-to-use frontend development tool, Sass can be used with all CSS libraries. It includes features such as nesting, mixins, variables, or selector inheritance.
Sass has been supported for over a decade, not only by the creators but also by a large community of developers. What’s more, some technologies have even been created with Sass, like Bourbon or Compass.
Less
Similarly to Sass, Less (Leaner Style Sheets) is an open source preprocessor that serves the purpose of CSS language extension. It can run on both the backend and frontend.
With its release over a decade ago in 2009, Less has since become a rival to Sass, even though they both influenced each other in some ways. The extension can attribute its popularity to various functionalities like nesting, mixins, variables, and more.
What differentiates Less from Sass among many other things is that it runs its compiler via browser by using less.js.
PaaS – Platform as a Service
Docker
Docker is an open source web development tool that serves the purpose of containerization of software. All containers are lightweight and have a common ground that’s called the operating system kernel. What’s worth mentioning is that Docker uses less resources compared to virtual machines.
Docker supports only three main operating systems, i.e. Windows, Linux, and macOS. Additionally, the software works with Github!
In fact, the software is an industry standard that enables zero-downtime deployment.
Git Software
Git
Git is a free version control software used for saving, editing, storing, or deleting any part of the code. Ideal for web developers to save their code documentation in so-called repositories. Then, web developers can view and store their repositories in software such as Github.
GitLab
Created by Dmytro Zaporozhets and Valery Sizov, GitLab is a DevOps lifecycle tool that works as a Git repository. Not only that, but it also includes plenty of other functionalities like a wiki, tracking issues, and many more.
Written in Ruby and Go, GitLab is a web-based software that can help developers with their projects.
GitHub
Probably everyone has heard about GitHub at some point, even those who aren’t familiar with the IT industry. GitHub is a platform used by over 50 million users and it serves the purpose of storing open-source software.
In the past, GitHub used to charge its users for storing projects, but since Microsoft bought GitHub in 2018 for the jaw-dropping amount of $7.5 billion USD, the projects can be stored free of charge.
Additionally to storing personal projects, you can also code web apps on the platform. Unfortunately, I’m afraid that for those who aren’t fans of the cloud, I’ve got some bad news. GitHub stores all information in the cloud.
Bitbucket
Made by Atlassian, Bitbucket is yet another Git-based storage for open source repositories. Written in Python, it’s available in both free and premium versions.
The storage features a lot of useful functionalities, among them users can find ones like integration with Jira or Trello, or built-in CI/CD.
What’s more, with the premium version you can set up the two-step verification to further secure your account, or set IPs that you would like to have whitelisted.
CI/CD Tools
Github Actions
A part of the entire Github, Github Actions is designed to be responsible for the automation of the software workflow with CI/CD (Continuous Integration/Continuous Deployment).
With support for matrix builds, different platforms, and a multitude of programming languages, Github Actions can connect every tool that you’re using to automate the process.
Not only that, the software features a plethora of available plugins that can help you with a variety of actions.
Bitbucket Pipelines
We already mentioned Bitbucket on our list, but the Bitbucket Pipelines are worth mentioning as well. It’s an integral part of the Bitbucket that’s responsible for handling CI/CD service.
Thanks to this feature, the user can build, test, or release the code automatically based on the repository’s configuration file.
Bitbucket Pipelines supports a wide range of platforms, for example, Python, Ruby, Java and JavaScript, PHP, and even more.
Jenkins Pipelines
Jenkins Pipelines is a set of plugins that serves the purpose of both implementing and integrating CD pipelines into the Jenkins program.
The software works based on the Jenkinsfile. When the user allocates it to source control, a range of benefits comes soon after, like automatic creation of a Pipeline build process with branches and pull requests, ability to review or iterate the code, and others.
Why should anyone use Jenkins Pipelines? Well, because it has a couple of advantages, like being durable or versatile. And these are not the only ones! Go ahead and see for yourself.
Project Management Tools and Communicators
Jira
One of the most used project management tools across software development companies, Jira allows the users to track the progress and plan the sprints. If you’re using the Agile/Scrum methodology, Jira is the perfect web application for it. It’s cross-platform software with a variety of options at your disposal, like Kanban boards to efficiently manage the tasks and prepare the sprints.
As you can see in the image above, Jira offers various subscription plans. Even the free plan would be enough for small teams who wish to track their progress throughout the project.
Asana
Similarly to Jira, Asana serves the purpose of a project management tool. There, the user can create new tasks and assign team members to them, create subtasks, or organize lists, and we just named a few.
Asana is a fine example of SaaS – Software as a Service with different subscription plans available. You can even register on Asana for free if you’re just starting a small project with your team. Prices grow accordingly to the needs, for example, if it’s a bigger project or an enterprise.
Trello
Trello is a very popular choice when it comes to project management tools as it’s both simple and efficient. With Trello, users can manage their own projects by creating columns and cards. Similarly to Asana, they can be grouped together in columns such as To Do, Done, etc.
Trello marked its initial release in 2011, making it a decade-year-old software that is still widely used to this day. It’s available in 21 languages and has over 50 million users.
There are three pricing options available for Trello: $0 (free version), $10 per month (billed annually, $12.50 billed monthly), and the last option depends on the number of users, but generally, it’s $17.50 per one user.
Surprisingly, the free version of Trello can still go a long way. Let’s take a look at the comparison. You can see the free version on the left, business class in the middle, and enterprise version on the right.
Additionally, Trello can be integrated with a variety of other tools, like Slack, DropBox, and many more.
Slack
Released in 2013, Slack has quickly become a communicator often used by web development companies. It features a friendly GUI (Graphical User Interface) and a structure that can be divided into channels or rooms. Not only that, but you can also make video calls, integrate it with multiple software, and many more.
The application is available on a variety of platforms, like Windows, Linux, macOS, iOS, Android, or Windows Phone. It’s a really versatile tool for communication and it seems that it’ll only keep delivering.
Even though Slack is a great tool, it’s also rivaled by open source MatterMost. Which one is better? You decide.
Zoom
Zoom is yet another really popular communication tool. When it comes to video conferencing, here is your undisputed champion. Whether you’re working from home or perhaps you need to meet with a client, Zoom comes to the rescue.
Of course, there are plenty of other ways to do so, but using Zoom can not only make it more professional but can also handle higher traffic as up to 100 people can join a conference for free!
Zoom features different subscription options starting from $0 per year up to $240. Bear in mind that the free option can only host conferences or meetings for up to 40 minutes which isn’t a long time. By the way, if you’re interested in online meetings, consider also Zoom alternatives to choose the best match for your online conferences and meetings.
Backlog
If you’re tired of Jira or perhaps want a change of environment, you can easily switch to Backlog as it includes an easy-to-use Jira importer.
The tool is available in various pricing models, ranging from $0 for a free version that includes 10 slots for developers, 1 project, and 100MB of storage, to $175 per month! The latter is the most expensive option of Backlog, but it includes unlimited slots for developers or projects. Not only that, but it also has 100GB of storage, as well as Gantt charts and custom fields.
With Backlog, developers can manage their projects in an easy and efficient way. Thanks to multiple tools like task hierarchy, IP address control, or Gantt charts, Backlog has become a quite popular solution.
Package Managers
Node Package Manager
Developed by Microsoft, the Node Package Manager is a JavaScript-based web development tool for finding and installing packages for specific programming languages.
It not only makes the search for the proper package quicker but also easier as you can install it from the manager itself. That all makes the software perfect for use as your default package manager.
Yarn
Yet another manager that serves the purpose of downloading and installing packages. Yarn has been created by Facebook and received a new stable version in January of 2020, called Yarn 2. Interestingly enough, Yarn can also be used as a project manager.
What the users appreciate the most about Yarn is its speed, security, and performance.
Composer
Being the third package manager on the list, Composer is widely used among developers around the world. Written in PHP programming language, Composer runs in the command line while installing the so-called dependencies, which are essentially libraries.
Composer was released in 2012, making it yet another almost a decade-old software. What’s worth noting is that Postman was heavily inspired by another package manager mentioned on this list – NPM.
API Tools
Postman
You’ve got mail! Though it will not deliver letters, Postman is a collaboration platform for API development (Application Programming Interface). There are various ways in which you can use the software, for example, using it directly in your web development or you can even create onboarding for new developers.
The Postman web application can also conduct automated tests and simulate endpoints.
Swagger
Swagger is an open source development tool, an API builder, and a tester that was released a decade ago, in 2011. Additionally, the tool allows developers to create testing APIs and makes the frontend development easier, even before releasing the first API.
What’s more, Swagger is a tool that’s easy to understand even for rookies. Additionally, it can be easily adjusted and features a nice and crisp editor.
Frontend and Backend Web Frameworks
Web development frameworks are also considered tools so it wouldn’t be right not to mention that. We’re not going to dive into details in this article, as we already covered the subject of the frameworks on our blog.
However, what we’ll mention here are some of the frameworks that are worth taking into consideration while developing web applications:
- Node.js;
- Express;
- React library;
- Foundation;
- jQuery JavaScript library;
- Angular;
- Svelte;
- Laravel;
- Vue.
Quality Assurance Tools
BrowserStack
Founded in 2011 in India, BrowserStack is a testing platform for both mobile applications and websites, all done in the cloud.
For testing, developers can use browsers and operating systems of their choice, along with real mobile devices. What’s more, you don’t have to possess a multitude of devices to test the software on, because you can conduct the tests on virtual phones, operating systems, etc.
With over 2,000,000 registered developers from at least 135 countries, BrowserStack is a key player when it comes to testing applications.
Selenium
Selenium is an open source automated tool for conducting tests of web applications. Created in 2004 with a stable release in 2018, this testing tool allows the users to write test scripts in various programming languages, such as Node.js, Python, and many others.
Selenium is actually one the most popular testing tools on the market with over 50,000 companies using the software.
Other
Webpack
To put it in simple words, Webpack is a static module bundler designed for working with JavaScript apps. With Webpack the user can bundle the scripts, pictures, and many other things.
What the software essentially does is create dependency graphs between the files, resulting in the creation of bundles
ESLint
ESLint is a linter software made for JavaScript. Since its release in 2013, ESLint has been a popular tool for developers programming in JavaScript.
With the help of plugins, the linter can also work with TypeScript or JSX. Additionally, the tool can work across multiple platforms.
Grunt
With over 5000 plugins available, Grunt is a versatile and popular JavaScript task runner. Used by companies like Microsoft, Twitter, Opera, and others, this software can perform tasks like testing, compiling, minificating, or linting.
The tool features a functionality called Gruntfiles. What it essentially is is a file with a defined task that is run in the command-line interface.
Autoprefixer
Autoprefixer is a post CSS processor that is designed to remove vendor prefixes. In fact, you can entirely skip the prefix thing, whether to add it or remove it, as Autoprefixer will take care of everything.
Additionally, you can choose which browser you want to be supported.
Husky
Husky is a really popular package developed to work with Git hooks, that can also lint code or commit messages, and run tests.
Designed to be lightweight, it’s powered by core.hooksPath Git feature. Any project that includes the package.json file can use Husky.
Stylelint
Stylelint is a popular tool for CSS that helps developers write clear and understandable code. It’s a linter that can find and report errors and issues.
It can definitely contribute to faster development and clearer code. Featuring over 170 built-in rules, plugin support, and a constantly growing community, Stylelint can be a really useful tool.
TypeScript
Based on JavaScript, TypeScript is an open source language used for programming a wide range of applications.
TypeScript is like a direct descendant of JavaScript, with additional features like static type definitions.
Additionally, many companies decided to migrate their applications from JavaScript to TypeScript, for example, the already mentioned Slack or Airbnb.
To get to know more, check out the presentation made by Anders Hejlsberg upon TypeScript’s release.
Web Development Tools for Linux
Most of the web development tools are not only available for Windows, but also for Linux and other operating systems. All of the ones that we’ve listed in the article are available on that platform.
Well, all but one – partially. Asana’s desktop version is not available on Linux. The only way to access it on the platform would be to use the browser version.
Mobile Web Development Tools
So far we’ve listed web development tools for a variety of platforms like Windows or Linux. Now, let’s focus briefly on the mobile web development tools. Of course, some of them are cross-platform, like Slack or Zoom, therefore we’ll skip the ones we already described above.
Android Apps
Android Studio
Android Studio is the most popular IDE tool for creating apps for Google’s mobile system – Android. It has been built by the IntelliJ IDEA that we already mentioned in the article.
Available for platforms such as Windows, Linux, or macOS, the software features functionalities like Android Virtual Device (that acts as an emulator for running and debugging the apps), an intelligent code editor, APK Analyzer, lint tools, refactoring and fixes, a layout editor with vast options, and many more!
With Android Studio, developers can code applications in various languages. Some of them would be Java or C++. Additionally, the software supports extensions like Go or Kotlin.
Overall, it’s a great tool for creating Android apps.
Charles Proxy
Created by Karl von Randow, Charles Proxy is a cross-platform debugging tool that allows the user to view HTTP, HTTP/2, SSL, HTTPS traffic.
Released 19 years ago in 2002, Charles Proxy features plenty of functionalities. Among them, the user can find ones like XML/JSON/SOAP interpretation, bandwidth throttling, different sorts of debugging features, and a lot more.
Charles is a paid software that costs $50 for one license. However, you may try the software for 30 days before purchasing and see if it suits your needs.
Xcode
The last entry on our list of web development tools is Xcode. Made by Apple, Xcode is an IDE for macOS and is used for developing applications for Apple platforms, such as the mentioned macOS, iOS, watchOS, tvOS, and last but not least iPadOS.
With Xcode, developers can not only program applications, but also manage the workflow, create new requests, manage the queue, and more. Additional features include the CarPlay simulator, custom documentation, crash reports, Vim mode, and other useful features.
A really well-made tool that happens to be the most popular choice when it comes to developing iOS tools.
Key Takeaways
Almost there! Just one more stop on the road and we’re done! As you’ve seen in the article, we listed some of the most popular web development tools that developers can use during their work.
For your convenience, let’s go through these few bullet points to solidify the knowledge:
- When choosing a tool, think about your end goal, is it a big project? Or perhaps it requires only a small team?
- Think about your budget, if you don’t want to spend too much money, choose a tool that’s free or has a free trial;
- Carefully choose the tools that appeal to you and your project the most.
Conclusions
This is the end, as Adele would sing. In all seriousness though, now you should be able to tell which tool can help you with the development process.
Additionally, if you had any doubts about web development tools, we hope that they have vanished by now! Thank you and see you around next time.
