DEV Community: Gulshan

Retro desktop website - show-and-tell

Gulshan — Tue, 24 Feb 2026 04:18:22 +0000

This is a little show-and-tell, it's a retro desktop inspired website.

lights off - reading in dark with a flashlight [codepen]

Gulshan — Sun, 25 Jan 2026 17:40:55 +0000

Just for fun

Design System with CSS

Gulshan — Sun, 28 Dec 2025 15:35:15 +0000

Quick Summary

If you have set out on using a design system for your website without the help of any popular framework or library but just pure CSS, then you've come to the right place.
This is still relevant if you're using any javascript framework, including react.

Getting Started

To begin with implementing a design system with CSS we should have it documented somewhere, maybe on Figma. We can then pick up those tokens and styles and starting working.

What are the essentials?

Colors
Typography
Iconography
Spaces
Components
Patterns/images/logos

We can use a open-source design system for this exercise. Carbon by IBM is one such open-source, well designed and documented design system.

Setting up design tokens

Design tokens are important part of a design system's foundation, here's a overview about design tokens from material. We can consider these as the source of truth whenever necessary.

It is important to scope everything under the design tokens and keeping exceptions and one-offs at the minimum, else we could end up with a design system (-system).

In CSS, we can setup these design tokens as variables (i.e. custom properties). Design tokens are usually available globally and thus we can define these variables at :root pseudo-class like this:

:root {
  /* Colors */
  --color-bg: #FFF;
  --text-primary: #161616;
  --text-secondary: #525252;
  ...
}

Once we have all the design tokens set-up, we can proceed for application. Tokens that we have defined are the only possible values to be used anywhere in the styles and hardcoding values should be avoided in-order for the design system to succeed.

Application and usage patterns

We can any model or patterns that we prefer in CSS, as long as we are referencing property values to the CSS variables we defined.
Using utility classes is a common and popular method. We can also set styles directly to some of the HTML elements. For example, setting up a heading styles

/* common properties of headings */
h1, h2, h3, h4 {
  font-family: var(--font-family-heading);
  font-weight: var(--font-weight-heading);
}
/* typography h1 properties */
h1 {
  font-size: var(--font-size-heading-1);
  line-height: var(--line-height-heading-1);
  letter-spacing: var(--letter-spacing-heading-1);
}

Similarly we can set default styles for other semantic tags like a, img, p and others. This will most of our atom level components styled according to our design system and we won't need to add classes to for these elements across the codebase.
For more complex components, we can start creating classes and use the design tokens there.

These are some of the very basics of using a design system with plain CSS. We will talk more about the applications and best practices in the upcoming articles.

Thanks for reading!

Ticket with CSS Grid [old codepen]

Gulshan — Sat, 25 Oct 2025 15:43:35 +0000

Made this pen for fun, a long time ago. Back when CSS Grid was new and I was trying to make everything with it. Fast coded this, hence no point looking at the code.

Grid Layout of dribble shot https://dribbble.com/shots/4959941-Webinar-Tickets-Now-Available

Error Monitoring for Web Apps

Gulshan — Mon, 22 Sep 2025 06:43:13 +0000

Summary💡

Have you ever had an error reported by your web app users but found it difficult to track down or reproduce in your environment? Or do you wonder whether your users are happily using the new feature you just released?

Adding an error monitoring or real user monitoring solution to your app could help you keep these things (and more) in check!

In this article, let’s introduce some of the tools to help you do that.

What is Error Monitoring? 🤔

Here, we are discussing two different terms, error monitoring and real user monitoring (RUM). But what are these?

Error Monitoring systems help you collect unexpected crashes and exceptions that occur in an app. They also provide a way to handle exceptions manually in the code and report them to the error monitoring system. These systems usually come with an interface where you can check the error logs along with more specific details such as operating system, browser, app version, sourcemap, etc.

Real User Monitoring is a more comprehensive solution that not only tracks exceptions and crashes but also helps you analyze how a real user is interacting with your application and learn what affects their user experience. Different RUM solutions may offer various metrics and types of data.

Almost every Error monitoring/RUM solution provider would have a blog section where you can learn more about these terms in detail.

Why do we need this? 🧐

There are many scenarios where we may want to rely on these solutions to get the most accurate report from a user’s encounter with our app.

A web app with a large number of users and a wide variety of hardware/software environments could be an ideal case. It is almost always impossible to have the same experience as the user who is facing an issue with their hardware and software.

For example, a user with the Brave browser faces an issue that doesn’t occur in Chrome. This could be due to an unsupported browser API or a CSS property. Knowing the user’s device, browser, and browser version could help us resolve this much faster. (Some tools may even point out the exact code where the issue exists.)

It is always great to let our users reach out to us directly for any feedback, but we may not rely on that because our users may be confused, may not have the time to report, may be first-time users, and may simply decide not to report it and avoid that feature or the app altogether.

Solutions 🔨

Here are some of the tools that I have been familiar with and used in frontend projects.

Before we get confused between the similar-looking and functioning tools that all claim to be the best, it is perhaps good to know what we should look for. Here’s a list of some of the basic checks:

Ease of use (user-friendly dashboard, navigating through the logs, finding the details you’re looking for)
Support for your application (frontend, backend)
Error tracing
Reports and insights
Pricing

Sentry

Sentry is one of the most popular and open-source platforms. It comes with good support for almost all types of application stacks. Apart from error monitoring, Sentry also emphasizes performance monitoring and some of the best debugging features.

Pros

Active open-source community support
Easy to integrate
The most usable free plan
Tons of free learning content (blog, youtube)
User feedback
Code coverage, error tracing in the source code
Support across platforms and support for all major frontend frameworks

Bugsnag

Bugsnag has been around since 2013 and is really simple and user-friendly. It has a good support for mobile apps as well.

Fun fact - Bugsnag is now acquired by Smartbear who provides an ecosystem of software testing tools including Cucumber (also acquired).

Pros

Simple and easy to use
Only the essential information
Good support across platforms

Datadog

Datadog is an all-in-one solution for a whole range of monitoring and security products. It is more focused on network, cloud, and all backend-related monitoring.

Out of all the other options available, Datadog would surely find itself at the bottom of the list when it comes to ease of use and user-friendliness.

Pros

All-in-one solution for one subscription
Great support for backend
Decent community support

Honeybadger

Known for its error tracking and uptime monitoring, Honeybadger comes with good support for all types of backend applications and minimal JavaScript support as well. It has been around for a long time, and I have seen my colleagues (backend devs) rely on it for any production issues/alarms, which makes it worth mentioning.

Pros

Easy and reliable
Integrations with Slack, GitHub, etc.

Getting started with a free plan 🍻

To get started, consider trying out a few of these tools before hooking them up with your production app. Here’s a quick comparison of the free plans provided by these software tools.

Features	Bugsnag	Sentry	Datadog	Honeybadger
Users	1	1	Unlimited	1
Error Monitoring	Y	Y	Y	Y
Alerts	Weekly	N	N	Y
Data Retention/Display	30 Days	30 Days	1 Day	15 Days
Error Limit	7.5k	50k	Unlimited	5k

Conclusion

We’ve briefly covered error monitoring for web applications. Each of these software/services has its pros and cons, and we can pick the one that fits best for our specific app.

Thanks for reading! 👋

Links 🔗

Resources: Data Visualisation

Gulshan — Mon, 22 Sep 2025 06:36:53 +0000

A plain list of libraries

Here’s a simple list of the Data visualisation libraries that I came across. You can check these and decide for yourself based on your own likings and requirements. As per my experience, Echarts has been the top pick. It has some of the best documentation.

Resources

CSS Media Query in Javascript

Gulshan — Mon, 22 Sep 2025 06:34:30 +0000

Quick Summary

CSS media queries are very effective and optimal for applying styles based on device properties and settings. We’re going to look at a feature in javascript that let’s us use CSS media queries in our JS.

What’s matchMedia?

matchMedia is a method available on the window object that can be used to match or track a CSS media query on the document. Read more about it on MDN.

Syntax

Taking a CSS media query for example

@media (max-width: 480px) {
  body {
    font-size: 16px;
    background-color: lightgray;
  }
}

We would need what’s written after @media as it is

const matchMobileQuery = window.matchMedia("(max-width: 480px)");

Testing it on the browser console, here’s what the matchMedia returns

So we can take the matches variable to check whether the query matched or not.

To Track a media query, we can add a change event listener on the same MediaQueryList object given by the matchMedia.

Let’s test this with an example of prefers-color-scheme media query

const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)');

function handleChange(e) {
  if (e.matches) {
    console.log('Dark mode');
  } else {
    console.log('Light mode');
  }
}

mediaQuery.addEventListener('change', handleChange);

We should see a console log whenever the color scheme changes

When to use?

To replace window.innerWidth to find out what device we’re on
Replace any element size tracking with resizeObserver, if it can be solved with a media query
It’s not just for screen size—use it to react to dark mode, device orientation, and more

Thanks for reading!

If you made it till here, let’s hear your thoughts on this in the comments!

Phantom in Data Visualisation

Gulshan — Wed, 17 Sep 2025 16:19:14 +0000

Quick Summary

This article explores how to handle gaps in data and make sure your charts don’t quietly mislead. A must-read if you care about honest visual storytelling.

What is The Phantom?

Consider, the case of a line chart: where discrete data points are plotted along X and Y axes and connected to form a continuous line. Though the underlying grid may technically support an infinite number of coordinates, the chart typically displays only a finite set of values. The regularity of intervals between these points—along with axis labels and contextual annotations—enables the viewer to infer patterns and anticipate trends.

On occasion, there exists an unexpected discontinuity—a gap in the data. When such an absence occurs without explanation, it can render the chart misleading, implying continuity where none exists. These absent yet influential voids are termed as phantom values by some.

Why care?

Missing data, if not clearly indicated, can lead to incorrect interpretations. In a line chart, for example, the absence of a data point may result in the line being drawn across the gap, implying continuity where none exists. This creates a visual distortion—subtle, but consequential—especially when the viewer assumes the data is complete. In the context of data visualisation, clarity about what is present and what is not is essential to avoid misrepresentation. Marking or addressing such gaps makes the chart more accurate and reduces the risk of false conclusions.

To be precise, the goal is to

Avoid misinterpretation of the chart
Maintain honest and transparent data visualisation
Caution the reader about the missing data

What is the solution?

We can not fill the missing data, however there are ways to handle this better.

Display points on line

Displaying point markers along the line emphasises the of data points. This visual cue helps distinguish real values from interpolated gaps, avoiding the illusion of completeness.

Keep the gaps

Leave the gaps visible, rather than interpolating the line, to accurately reflect the absence of data.

Highlight the missing data area

Highlight the missing data and allow them to be distinct from the rest of the points.

Downplay the missing data area

Use visual cues like faded colours or blur effects to indicate missing data segments.

Use annotation for the missing data

Annotations can be used to provide context for missing data or imputed values.

Conclusion

Missing data in charts can lead to wrong conclusions if it isn’t handled properly. When a line connects across a gap, it may look like the data continues, even when it doesn’t.

It’s important to make these gaps clear—whether by breaking the line, adding a marker, or showing a note. This helps keep the chart accurate and avoids confusion.

References

Access Control in Web Apps: Backend + Frontend

Gulshan — Wed, 17 Sep 2025 16:02:38 +0000

Quick Summary

This article is an introduction and exploration of various types of Access Control solutions for a web application. Including the backend strategy and the frontend handling.

It is not a tutorial post. We are briefly touching upon the options and solutions available and some best practices. You can use AI to help with implementation of a specific solution.

What is Access Control?

In summary, Access Control is a security process or framework for your application that enables you to control the accessing and operating over the resources by the users.

There are more detailed resources available on the basics of Access Control. For instance OSO (an access control solution provider) provides some good knowledge resources that can be found here. And there are many other blogs, as well as youtube videos available.

History of Access Control in Software

The history of Access Control systems goes back to the 60s and 70s when it was mainly developed and used by OS developers to manage access over data/files. With DAC being used in UNIX and windows.

Then comes the Mandatory Access Control (MAC), initially used by the US Military and Government. It later became more mainstream and was adapted to make security tools and applications in Linux, MacOS and Windows.

Role-Based Access Control (RBAC), a more familiar name comes along in the early 90s. RBAC is still around and is the most basic/standard type of access control system. In RBAC, we have predefined roles that can be assigned to users and the access permissions are attached to the roles. More about history of RBAC here.

Read more about the origins of these access control models here

Types of Access Control

Keep in mind, these are just methods, not a programming language or a feature. This means if someone creates a new variation of access control and names it, it would become a new type.

In the context of Web Applications, here are the main types of access control models:

RBAC - Role Based Access Control
ABAC - Attribute Based Access Control
PBAC - Policy Based Access Control

To make things easier, I have listed only the most popular and commonly used types. One of these, or a combination, will likely suit your needs.

Best Practices and Patterns

Here are some best practices, standards and patterns to make sure the access control system is implemented properly

Centralised authorisation layer - access related logic should not be scattered around in the codebase but maintained in a dedicated authorisation layer
Principle of Least Privilege - users must have only the minimum required permissions
Deny by default - no access unless explicitly granted
Server-side enforcement - never rely on client code (JS, HTML) to protect resources
Access logs - track and review access events for anomalies
Separation of duties - prevent single roles from having excessive combined powers
Policy as code - manage authorization logic declaratively, versioned, and testable
Short-lived tokens / sessions - reduce the window for misuse
Consistency - ensure frontend reflects backend authorisation rules

Handling Permissions in the Frontend

Most of the heavy lifting around access control is relevant and possible only in the backend but when it comes to the frontend, we have to make sure to update the app to:

Maintain good UX
Avoid unnecessary exposure and access attempts - displaying only relevant options to every user
Make sure access to any static information is managed accordingly

What are the essentials to handle in the frontend?

Show/hide options to the user based on their role and permissions
Receiving and storing roles and permissions from the backend
Handling the permissions in the code

Here are some the questions we can ask to find an optimal frontend solution

How could we receive roles and permissions details from the backend?
1. Is there a config API to add these details to? or can we include it in the auth API?
2. Do we need a dedicated API for roles and permissions?
3. Can we cache this API response?
4. How do we make sure that we have the latest details whenever backend is updated?
How do we handle permissions in the UI code?
1. What is the best way to separate the access logic from UI? (Based on the frontend framework)
2. How best can we make sure that it is scalable? (while making minimal or no changes to UI code)
What is the technical debt?
1. Does the solution require deep integration?
2. Does it depend on a particular backend structure?

After this you would have a better idea of what and how to implement access control in the frontend to reflect the backend rules and permissions. To keep things straight forward, here is a standard, scalable and high quality solution CASL, that takes care of all the things we’ve discussed above and more.

💡
Pro tip: Just like how you should not go coding your own state management in React thinking that React Context = Redux, you should not go writing a access control solution from scratch unless you really know what you’re doing and understand everything about it.

Conclusion

The optimal access control solution for your application would depend on the requirements and other conditions, it could be a basic or a combination of different models. The article focused on the basics of access control and exploring on the possibilities, as well as some important principles and best practices.

Links to Knowledge Resources

Accessibility of Toggle Buttons

Gulshan — Wed, 17 Sep 2025 15:53:43 +0000

Quick Summary

A task of making a cool toggle button comes your way and you’re headed down the div lane. What happens next? Sounds like a crime thriller but it could actually be a nightmare for your users. Explore what is the best approach, how to ensure the button is accessible, and what could go wrong when you replace native HTML elements with artificial ones.

Toggle Button

To begin making a toggle button or an icon button with toggle feature, the easiest and straight forward option is to use a div and style it according to the design. Like this button here

We have a like button with a thumbs-up icon similar to what we see under social media posts, clicking it makes it active and clicking it again makes it inactive or reset. Works well visually and functionally. But right now, it has a few things missing.

Trap of Artificial Button

Since we used a div and icon to make a toggle button, it does not have the properties of a native HTML button. Which means we would miss out on these built-in features

Feature	Div	Button	Comment
Tab indexing	❌	✅	Using keyboard to navigate
Button label	❌	❌	Users have to guess the usage by icon
Keyboard support	❌	✅	Spacebar support
Default focus styles	❌	✅
Semantic	❌	✅	Browser doesn’t know if it is a button
Accessibility	❌	⚠️	Button is inherently more accessible but not totally
Form features	❌	✅

These issues could affect the user experience and they are easily be overlook if not tested specifically. Even if we notice and try to fix them, we would need to manually solve them.

Addressing Accessibility

How do we solve the issues discussed above?

Well, the best solution would be to use a <button> element. Using button in place of the div will restore the built-in button features. This could affect the styles of the icon button due to the default button styles. All browser default button styles can be removed by using a CSS property all: unset, but this property removes every default style, including the focus styles which we should still keep. Alternatively we can only update the styles that are affecting our button design, such as background, margin and border.

Using a button, improves the element without any extra work. However, there are still a few more things to address

It is still a generic button element and not a toggle button
It still misses the label
ARIA tags for A11y
Toggle state

Using Labels to Clearly Describe the Button

The purpose of a button must be clear to the user. An icon on its own may not be clear enough or even accessible. Icons are graphics made of lines and shapes, and their interpretation can be highly subjective. They also limit users to understanding the control only visually.

Adding a descriptive label to the button improves accessibility, while showing the label on hover can enhance the overall user experience.

Here’s a list of things to consider for button labelling

Visible text label next to the icon - Ideally, just include a label if there’s no good reason to hide it
Hidden text in the button - Add the text in a span beside the icon and hide it using CSS
Using aria-label - Use the aria-label tag on the button to add a descriptive label
Tooltip on hover - Use a tooltip to show the label when the user interacts with the button

Toggle State

Now we have the button more accessible and working fine. But what about the toggle state? Is it accessible to every user yet? Maybe we can see it visually as the design and styles change after it is clicked and we have the state in our JS probably. But how does the browser know in which state the button is currently? So how would users with assistive tech know the state?

This is where the aria-pressed tag comes in to help. It is meant for using as a state indicator for toggle buttons. We can set the current toggle state of the button in this tag like this

<button aria-pressed="true">...</button>

💡Pro-tip: Do not confuse the user by changing the content of the button when toggled. Also mentioned in MDN docs here

Downsides of Not Using Native Button

Replacing any native HTML element comes with its downsides. Native elements are recognised by the browsers and include a lot of important properties that help with a consistent cross-browser behaviour and accessibility.

Although we don’t have a dedicated toggle button in HTML but by using a generic button element with proper labels and pressed state, we can get close to the best possible solution.

TL;DR

A quick checklist for toggle/icon buttons

Basic button features (by browser)
Descriptive button label
Accessibility tags
Toggle state

Links to resources

TL;DR: Baseline

Gulshan — Tue, 30 Jul 2024 18:17:37 +0000

What is Baseline? 💭

Web Platform Baseline has been around since 2023, as you can see Una Kravets talk about it at Google I/O 23 in the video below.

Baseline's purpose is to let the developers know if a new hot feature is ready to use in their project right now.

It will also help developers discover some interesting and really useful features that are already shipped in the modern browsers.

Core Browser set 🧭

Baseline includes these browsers as the core browser set. So once a feature (except limited availability feature) is in baseline, we can expect it to work in all these browser without having to check for cross-compatibility.

Chrome (desktop and Android)
Edge
Firefox (desktop and Android)
Safari (macOS and iOS)

Three stages of Baseline 🥽

Newly Available

Newly available features are available in the latest browser versions but are still new and may not be supported by the older devices or browsers.

Widely Available

Widely available features are well established features in all the browsers and have been available from more than 30 months ago. These are the most safe to use features from Baseline.

Limited Availability

Limited availability shows that the feature is not yet available across all the core browsers.

Baseline Year 📅

At the end of the year, all the features that became part of the Baseline in that year are compiled together. Like https://web.dev/blog/baseline2023

Web Platform Status 📝

Baseline aims to solve the problem of developers trying to figure out a new feature and it's compatibility, interoperability and sometimes keeping track of a feature that developers would want to use but are still in development.

We can now quickly track the features at Web Platform Status dashboard. It contains the entire web platform features with their browser support and baseline stage.

Learn More 💡

Watch Rachel Andrew's talk at Google I/O '24

Hear Rachel Andrew talk about it at Smashing Podcast

Check out https://web.dev/baseline for more resources.

Thank you for reading!

Resources: Learn Git

Gulshan — Tue, 30 Jul 2024 17:02:34 +0000

List of some of the best free resources to learn Git

Official website

Simplest and well organized

Cheat Sheet by git-tower

branches cheat sheet by git-tower

Comprehensive guide by Atlassian

Share in the comments what are your favorite sources to learn or reference git!