Nirjan's Coding & Tech Blog

Big life updates, Joy of simplicity, Coding & AI and a New job: 2025 review.

Nirjan Khadka — Sun, 04 Jan 2026 00:00:00 GMT

Big life update

I made some major decisions in my personal life in 2025. I decided to get married and to move to Spain.

I knew I wanted to move from Nepal at some point but I hadn't decided where to move. I'm a classic over-thinker so I might've spent way too long deciding on which country to move to but ultimately Spain had a nice balance of everything I wanted (a safe country with great weather and a good quality of life).

I realize how fortunate I am to be able to make this move at all and I hope it will turn out well.

Joining Athlos

I joined Athlos in February and spent the year working on the Athlos tournament platform. Athlos lets game studios seamlessly integrate a complete tournament platform into their games (includes both a dashboard to manage tournaments and an embedded frontend that players can use to compete in tournaments).

It was interesting to work exclusively as a frontend developer again. Having worked as a fullstack developer for the previous 3 years, I realized I still prefer having full ownership over the products that I'm building and being able to ship a full feature from scratch feels great but I enjoyed collaborating with other people again as well. I got to work with lots of talented backend developers at Athlos so it was great to learn from them. It was also fun to collaborate with another frontend developer and designer too.

These were some of the most fun and rewarding things I got to work on with Athlos this year:

Introducing the team to Storybook for documenting our in-house component library and redesigning our theming token system using css variables. This enabled us to make our themes more customizable for each client.
Launching a few key features requested by our clients like:
- Supporting player created events (which lets studios invite players who can then use event templates and host their own tournament event).
- Adding a billing section to the dashboard so studios can easily see their user metrics and get their billing estimates.
- Creating a new standalone web app product where players can take part in Counter-Strike 2 tournaments (previously we only had a webview embed that clients could add to their mobile game). It was an interesting challenge to extract our core logic for the webview embed into a shared package so we could use a monorepo for different platforms (webview and standalone web app).
Refactoring our lobby queue system (so players can seamlessly join a game lobby, find matches and accept a match with realtime notifications for each step).
Making improvements to our developer experience with:
Automatic language translations with the Google Cloud Translate API (our webview embed project needs to support multiple languages).
Adding some end to end tests with Playwright so we could make new changes to our dashboard and webview project with more confidence.
Introduced product analytics and error tracking (with screen-recordings) using Posthog analytics.
Used Cloudflare workers and Grafana to create a request log dashboard so we could have better insights into all our frontend requests.

Clickout consulting

In my free time, I took on some consulting work for Clickout Marketing as well. Clickout is a global multi channel marketing company with a focus on SEO and affiliate marketing.

I worked as a freelancer for them and was tasked with building some internal tools to help them be more productive with their day to day operations. I also built some automation-workflows to automate a lot of tedious manual work they were doing previously.

These are some of the things that I worked on for Clickout this year:

Introducing the team to n8n workflows and building out some core reusable sub-workflows (better error tracking, markdown converters, WordPress data extraction, etc) and some custom agentic workflows (SEO brief generation, position tracking report generation, etc). This helped automate a significant amount of boring manual work. It has been a huge success within the internal teams and now they're automating 96+ hours of work every day (with more automation-workflows to come in 2026).
Created a custom internal web app for the marketing team. It lets them track their partner outreach more efficiently (automatically getting stats about potential partner sites and their contact information, syncing the outreach status to Monday CRM, finding new partners to reach out to based on the tracked keywords, etc). It also helps them track the SEO rankings for their internal sites automatically without checking multiple SEO tools.

AI-assisted coding and joy of simplicity

2025 was also the first year where I (along with many other developers) actually started using AI tools in my day to day work. I have mixed feelings about the state of AI-assisted coding currently.

It can be incredibly helpful at times when you have a clear idea of what needs to be done and you just need to write a bunch of boilerplate code. It can be magical to just use a few prompts and have a complete feature ready without the hours of tedious manual coding you would need previously.

It has also enabled me to be more ambitious with the type of projects I take on. It feels like I have a pretty competent pair programming partner who I can consult with and talk through ideas about different types of projects (including the ones that I have very little experience with). I don't have to do countless hours of research before starting something that I'm unfamiliar with. AI tools like Claude can be great to bounce different alternative ideas around with and figure out the best approach to take.

But, sometimes it can be infuriating to work with AI. I appreciate the ability to quickly vibe-code interactive prototypes, they are a massive improvement over just regular Jira tickets or static designs and tell me a lot more about what the product needs to be like. However, trying to make a vibe-coded app into something that's robust, secure and performant still feels like too much work. In most cases you're probably better off just starting from scratch.

I also don't get into the same type of flow when working with an AI agent because I have to wait for it to finish and then reviewing the massive amount of code it spits out (they sure do love to use a lot of code) can almost be a bigger bottleneck than just writing the code myself.

So, I think there's still a lot of value in AI-assisted coding but you need to follow some best practices to get the most out of it and luckily those best practices tend to be the same ones you'd use when improving your own code too. Some of the things that I've found to be helpful are:

Have a clearer idea of the actual problem you're trying to solve first. AI can help you write a pretty decent spec which you can use as a high level plan for yourself or have it try implementing some isolated parts of it.
Have small focused commits. There's nothing worse than having to review a massive code change made by an Agent. Some of the newer models are capable of one-shotting incredible apps but just because they can doesn't mean you should let them do it. It's much better to have them work on smaller features or parts of a feature, review it and then move on to something else.
Use as much deterministic tooling as possible. You can use AI to get a good summary of code changes but you should take it with a grain of salt. It's not a replacement for actually reading the code. Instead, to make sure the code is actually correct, use tried and tested tools that are deterministic like linters, type checkers, unit tests, end to end tests, etc.
Introduce constraints whenever possible. Use things like an agents.md file or add specific instructions in the spec to only allow the Agent to do certain things. Be clear with your tech stack and patterns you want to follow. This is the reason why I rarely start a project with AI, I often find it much more productive to establish a good foundation myself and once I run into repetitive tasks, I use AI to help me with that.

I've also grown to appreciate simplicity a lot more because of AI-assisted coding. I know that we should always optimize for reading code more than writing code because you will be reading it much more often than writing it. But, in practice it can be hard to remember this and you end up trying to create abstractions and use dependencies that let you write code faster which often makes it harder to read and understand.

This year I read the Let's go and Let's go further books by Alex Edwards and it made me appreciate the simplicity of golang and how great it can feel to write simple code that is easy to understand. This has the added benefit of making it easier for AI agents to understand your codebase without needing additional context about different abstractions or dependencies. So, in 2026 one of my goals is to write more simple code and think a lot more critically about the abstractions and dependencies I use.

Learning and projects

I finished a few different courses this year and tried to understand the tools and languages I use in a deeper way. Some of the courses I took were:

Joy of React by Josh W Comeau (a fantastic course on how React actually works)
Let's go and Let's go further books by Alex Edwards (great books on the Go programming language and its standard library to build web servers)
Total TypeScript Essentials by Matt Pocock (Matt is probably the go-to guy for TypeScript and his free TS course is fantastic and much more detailed than any other typescript essentials course)
Dev Productivity and Blazing fast JavaScript by The Primagen (The Primagen needs no introduction, his courses are fantastic and very detailed)
Complete Intro to SQLite by Brian Holt (SQLite can be a great tool for many different projects where you don't need a full blown database)
Front-End System Design by Evgenii Ray (it was nice to go deeper on some of the common patterns and practices used in front-end development)
Some Vueschool courses (like TDD with Vitest, Vue Component Design and Nuxt data fetching)

Besides this, I also took some time to learn Vim motions and moved from VSCode to Zed and started using zellij for my session management (small things like this probably don't make you a better developer, but they do make you more productive and make coding more fun). I also tried out the Symfony PHP framework and some Ruby on Rails but decided they weren't for me (going to stick with TypeScript and Golang for now).

While it's important to keep learning, building projects is also important. They help you learn by doing and solidify your knowledge. I worked on these side projects in 2025:

Servomon: A selfhostable homelab monitoring app built with Nuxt and Deno. The dashboard is built with Nuxt and communicates with a Deno client that runs on the server using websockets.
Rosetide: A privacy focused secure period tracking app. Stores all data locally and lets users track their periods and get an overview of their cycle and a prediction of their next period.
Evergreen Plants: An online store for the best plant nursery in Nepal (I'm totally not biased because my girlfriend runs the nursery).
Remote Dev Jobs V2: Updated the job site that I run for remote developers to Nuxt 4 and Nuxt UI 4 and Drizzle (from Prisma).

Coding in 2026

2026 is shaping up to be another year filled with huge potential changes in the world of coding. There are lots of uncertainties but I feel like there's some exciting opportunities as well. The AI Genie is truly out of the bottle now and there's no going back, however we can choose how we use this tool (at the end of the day it's still just another tool in the toolbox).

Personally, I want to focus on making my tech stack simpler (less abstractions, minimal dependencies and solid fundamentals). I'm planning on using a set of core technologies which are tried and trusted and simple (Golang, SvelteJS, TypeScript, Postgres, Docker, Linux). I have a lot of interesting ideas that I want to turn into actual products.

This year I want to focus on some more foundational concepts as well. I want to learn more about security, networking, databases and performance optimization.

Apart from coding on my side projects, I also want to spend my free time doing some more writing and open source work. I realize that making any sort of money from writing about tech is pretty much impossible now but I want to write mainly as a way of clearing my head and a way of solidifying some of my opinions and ideas. I want to become a better coder too so for that I want to start reading a lot more open-source code. Being able to get some actual feedback from people with more experience than me is important too so I want to find a few open source projects that I love using and contribute back to them.

I can't predict the future and have no control over how things are going to shake up in the tech world. I don't know how AI will change things in 2026 but I can control how I spend my time and what things I chose to focus on so hopefully it's going to be another year of working on some cool shit, learning some amazing things and growing as a person and a developer.

2024, The year I pressed reset: Career change, Back to TypeScript (for now) and new habits

Nirjan Khadka — Fri, 03 Jan 2025 00:00:00 GMT

Sometimes the biggest transformations start with a series of small decisions. In 2024, I made three choices that completely reshaped my professional and personal life: stepping away from a senior technical role during tech's most uncertain year, embarking on a month-long journey to London, and committing to what seemed like a simple habit – daily journaling and time tracking.

That last decision, surprisingly, had the most profound impact. Tracking every day of 2024 fundamentally shifted how I view my priorities and where I choose to invest my time. It revealed patterns I had never noticed and helped me make decisions I might have otherwise second-guessed.

As I step into 2025, I want to reflect on these changes and share what I've learned – both for my future self and for others who might be considering similar transitions.

Farewell to Gfinity

After nearly four years at Gfinity, where I progressed from a front-end developer to technical lead, I made the difficult decision to move on. While I'm grateful for the experience and the excellent team I worked with, I felt it was time for a change as I was stagnating in my role and my vision no longer aligned with the senior leadership.

During my final year, I was able to lead my team with the roll-out of several significant improvements:

We achieved a 93% cost reduction by migrating our sites from GCP to Fly for Node.js hosting, maintaining performance and stability throughout the transition.
I developed a custom product tracking system using Crawlee, GCP functions, and Node.js, resulting in an 80% reduction in scraping infrastructure costs.
We implemented Hashtag labs advertising with a custom placement algorithm, moving from a revenue-sharing model to a fixed-cost structure that increased our advertising revenue.
I spearheaded the migration of StockInformer sites from legacy C# and VB.net to a modern Nuxt 3 codebase, leading to more frequent releases and improved uptime.
Led the roll-out the redesign of our shared design library that empowered our editorial team with enhanced curation controls, leading to a measurable increase in page views per session
Launched and integrated a new property, TCGRocks.com, into our network, expanding our digital footprint
Led the gradual migration of all network sites from Nuxt 2 to Nuxt 3, ensuring smooth transitions while maintaining site performance
Supported the migration of our Siege Laravel server and Golang microservices from bare metal to Fly.io, significantly improving system reliability and observability

Learning and Growth

2024 was also a year of lots of learning. I deep-dived into modern Laravel, mastered Docker through Brian Holt's container course, and explored Vue 3's internals with Evan You. I completed the Linux Journey curriculum and learned to build desktop apps with Electron and Tauri as well.

A significant focus was on web technologies – I studied service workers, Progressive Web Apps (PWAs), WebSocket protocols, and WebRTC for real-time applications. I also picked up Phoenix LiveView and improved my development workflow by learning VIM motions and proper touch typing.

Perhaps most importantly, I completed Yale's "The Science of Well-being" course on Coursera, which had a profound impact on my perspective and daily life.

Side Projects and Community Engagement

Throughout the year, I worked on several side projects:

Built Chromastery, a Tailwind color palette picker
Developed JobGettr, an app to tailor your resume for each job, powered by AI
Migrated my personal site to Astro from Next.js
Built a peer to peer video chat application called Litsi

I also began working part-time with Clickout and became more active in the local tech community by attending meetups and conferences like DevFest Kathmandu.

Looking Forward to 2025

After a year of extensive exploration, I've made some deliberate choices about my technical direction. These decisions aren't just about choosing technologies – they're about aligning my tools with my career goals and working style.

Why I'm Going All-In on TypeScript

My journey in 2024 started with plans to focus on Laravel, but I've come to realize that TypeScript better aligns with my current career goals. While Laravel remains an excellent choice for indie hackers building sustainable businesses, I've discovered that my passion lies elsewhere – I thrive on exploring diverse problems and building various solutions rather than maintaining a single product.

TypeScript offers several advantages that match my needs:

Robust tooling that supports rapid prototyping while maintaining code quality
Flexibility to evolve projects beyond the prototype phase through easy refactoring
A vast ecosystem that enables building anything from web apps to desktop software
Strong job market with numerous opportunities at companies solving interesting problems

I'm also planning to expand my expertise into React and Go. While they might not be my first choice for personal projects, their position as industry standards makes them valuable additions to my toolkit. The goal isn't to master every technology, but to be proficient enough to contribute effectively in various professional contexts.

Shifting Focus: From Framework Exploration to Problem Solving

2024 was my year of framework exploration – I dove into everything from Laravel to Rails to Phoenix. While this broadened my perspective, it also limited my ability to ship projects. For 2025, I'm taking a different approach:

Shipping More, Learning Through Building: Instead of framework-hopping, I'll focus on launching more projects and solving real problems.
Exploring New Territories: I'm particularly excited about:

The local-first movement and its potential for creating resilient applications
Real-time technologies and their applications in modern web development 3. Embracing Progressive Web Apps: I'm making a conscious decision to step away from native app development. While native apps have their place, the constantly changing app store policies and restrictions have become more burden than benefit. The web's openness, ease of deployment, and maintenance advantages make PWAs an attractive alternative for most use cases.

Pragmatic AI Integration

While AI generates plenty of hype, I'm taking a practical approach to incorporating it into my workflow:

Selective Usage: I've actually disabled AI code completion as I found it was hindering rather than helping my learning process.
Strategic Implementation: Instead, I'm leveraging AI tools as thinking partners for higher-level planning and architecture discussions.
Focus on Productivity: The goal is to use AI where it genuinely enhances productivity without becoming a crutch or distraction.

This approach to AI reflects my broader technical philosophy for 2025: being deliberate about tool choices, focusing on solving real problems, and maintaining a balance between exploration and productivity.

I'm refining my focus to be more intentional and impactful and limiting it to the following areas:

Technical Focus

Mastering fundamentals: TypeScript, JavaScript, CSS, SQL, C, computer systems, Golang, and React
Deepening my expertise in Nuxt
Exploring both real-time and local-first applications
Expanding into PWA development as an alternative to traditional app stores

Professional Growth

Contributing to open source projects
Studying more existing codebases
Exploring cybersecurity
Integrating AI tools into my workflow

Personal Development

Adopting a more focused learning approach instead of trying to keep up with every new technology
Emphasizing depth over breadth
Creating and launching prototypes more quickly

I'm looking for my next long-term role – somewhere I can grow and contribute for at least five years. My favorite part of being with Gfinity was being able to improve the company, team and codebase for an extended period of time. So, even though job hopping might be better financially for me, I would prefer to find another long term company to work for.

My goal is to focus on strong fundamentals while solving diverse problems with a consistent tech stack, rather than constantly switching between technologies.

The tech industry continues to evolve rapidly, but I'm excited to take a more measured, focused approach to my career growth in 2025 and beyond.

Migrating my site from Next.js to Astro, Picking simplicity over complexity

Nirjan Khadka — Fri, 06 Sep 2024 00:00:00 GMT

The old tech stack with Next.js and Sanity

Over the years, I've migrated my sites to a few different frameworks. It all started with a Gatsby site, then I moved it to a Svelte static site generator called Elder.js (which actually implemented the islands architecture before Astro), then finally to Next.js. I've also migrated my content from using markdown to storyblok CMS and then to Sanity CMS.

If I'm being honest, I haven't enjoyed working with Next.js that much. I mainly decided to use Next.js for my site because it's by far the most popular meta-framework and uses React which is the most popular frontend framework. So, I thought If I used it for my personal site, I would be a better react developer and it would give me more opportunities professionally. But Ironically, I ended up joining a company that uses Vue.js and Nuxt.js and I've been working with that tech stack for the last 4 years 🤷‍♂️.

I don't necessarily hate React and I don't mind working in a React codebase but there are a lot more simpler alternatives. As I get more experienced, I'm appreciating simplicity more and more and leaning towards the simplest way to solve problems.

So, as a part of rebuilding my site, I wanted to simplify my tech stack as much as possible. That meant picking a framework like Astro which has good support for templating without needing to use any other frontend frameworks (unless I want to) and moving back to using good old markdown instead of a CMS.

I also decided to get rid of my monorepo setup with turborepo which was definitely overkill for my personal site. I don't have any complicated linting rules or pre-commit hooks or auto-formatting either. You can still find the Next.js version and the Elder.js version of the site on my Github.

Why Astro?

Since the main goal of rebuilding my site was to make it simpler, Astro was a great fit for that. I also considered Nuxt.js which has a better developer experience but is probably overkill for a simple content focused site like mine.

I wanted to move my content to markdown again too because I want to have complete control over my content, store it in a format that is extremely portable (in case I want to migrate to something else) and it also makes writing and editing simpler. Astro just happens to have great support for markdown with it's content collections feature that lets you create a schema for markdown and query it like structured content.

Another selling point of Astro was the Island's architecture where everything is just HTML but I can have islands of interactive components on any part of the page. I really think this is the best way to build modern sites and even most web apps.

The browser is great at rendering HTML so we should just shift towards that instead of trying to render everything with JavaScript. Even with Server Side Rendering, I think sites that hydrate and turn into client-rendered sites (most meta-frameworks like Next.js, Svelte, Nuxt, etc) are more brittle and less performant.

I've worked on a lot of content heavy sites with a framework that does this (Nuxt.js) and I definitely want to avoid going back to fully hydrated sites like that and deal with all the extra issues from hydration.

Moving towards sites that are just HTML with smaller isolated interactive components just makes the most sense to me. It let's us actually use the underlying web platform which is a lot more stable than most frameworks and is also way more performant and accessible.

We also have a lot more lightweight alternatives to frontend frameworks, like HTMX, Alpine or just using web components to handle client-side interactivity. My thoughts on this might change as I build more projects with these technologies but for now I'm happy to embrace simplicity over the complexity of modern frontend frameworks.

What I liked about astro

There's a lot of things to like about Astro. I've already mentioned the simplicity of Astro sites (they're mostly just HTML, CSS and some JavaScript if needed). But, the developer experience is also not that bad. It's basically just a framework that lets you create templates and organize them neatly into smaller components. All the Astro components are turned into regular HTML during the build process.

It also has a lot of useful features to improve the performance, accessibility and SEO of your sites. It has a built-in image component that can help you optimize your images. It automatically does syntax highlighting for code blocks in your markdown which you can customize too.

There are first-party integrations for creating sitemaps and RSS feeds to improve your SEO. It includes a toolbar during development that can detect some accessibility and performance issues and flag it to you. It does CSS scoping for you automatically and has an official tailwind integration.

The best selling point for Astro for a lot of people might actually be the support for multiple frameworks. It has official integrations for React, Preact, Svelte, Vue, Solid, Alpine and Lit. You can also just use a little vanilla JavaScript to add interactive Astro components too. It has some support for Server Side Rendering and Server APIs but I haven't used that part of it so far.

It was a pretty good experience building with Astro and I really like how much they prioritize simplicity, performance, accessibility and using the web platform. I will most likely continue building a lot of my upcoming projects using Astro.

What can astro improve

I still think there are a few things that could be improved in Astro. Having come from the Nuxt.js ecosystem I might be a bit spoiled when it comes to enjoying a good developer experience. Astro is not the worst when it comes to developer experience (looking at you Next.js 👀) but it is nowhere near to the level of seamless integration that you get with the Nuxt.js devtools.

Astro has made a good start with their toolbar to detect accessibility and performance issues but I would love it if they added some features from the Nuxt devtools like the built-in routes and API explorer, bundling and compilation visualizations, open graph image previews, component inspectors and being able to browse and install integrations directly from the devtools.

I didn't use the server-side features of Astro in this project but looking at the documentation they seem to be missing a few things that the nitro server (which Nuxt.js uses) already supports. So, it would be great to see some support for things like Tasks, Cron jobs, built-in ORM (besides just Astro DB), caching and KV storage. The 3rd-party integrations can also be a bit hit and miss but that should start improving as more people start adopting Astro.

Result of migrating from Next.js to Astro

Overall, I'm really happy with the move from Next.js to Astro and I look forward to working more with Astro on future projects. Here are the main things I learned by migrating my blog from Next.js to Astro - A framework that lets you incrementally add complexity and start from the simplest possible way of doing things feels great to use - Sites built with Astro will most likely always be better in terms of performance, accessibility and SEO than other meta-frameworks that need to do a full page hydration - You can use technologies that are closer to the web platform when using Astro compared to other frameworks. You can more easily adopt things like web components, smaller bits of vanilla JS logic, plain CSS HTML features. Of course, you can still use them with other frameworks but that's generally not the most common practice in those ecosystems. - Modern HTML and CSS has come a long way and is really good for common interactions. Features like the popover API, HTML Dialogs, HTML details and summary, CSS scroll transitions and the View transition API are enough to build a lot of rich modern client-side interactions without using additional JavaScript. - Astro might be the best solution for now if you value simplicity, performance and accessibility for your projects and want to stay in the JavaScript/Typescript ecosystem. - I still think there are some trade-offs to consider when using Astro, especially for highly dynamic apps or sites that require lots of server-side processing but in most cases Astro makes a lot of sense. - If I had to construct a Frankenstein's monster of a stack to fit all web projects it would probably have Astro's island's architecture, Nuxt's developer tooling, Laravel's first party packages, Go's simplicity and speed and Elixir's easy concurrency and scaling features but since I can't make something like that (yet), Astro's the framework to beat for now. - Astro sites are blazingly fast 🚀

The best tech stack for 2024, self-hosting and 3 years at Gfinity | 2023 review

Nirjan Khadka — Wed, 03 Jan 2024 00:00:00 GMT

You can also skip to the end to see what I think is the best tech stack for most developers in 2024. You can also checkout my previous yearly recaps for 2021 and 2022.

3 years at Gfinity and first year as a Tech Lead

I’ve officially spent 3 years working at Gfinity PLC now. I also finished my first full year as the technical lead for my team. This year was definitely a mixed-bag as we had lots of changes in the company and had to say goodbye to a lot of talented developers. But, We also had new team-members who have absolutely killed it since joining. Being able to have a big say in the hiring process has allowed me to be more selective when picking new hires. We also managed to accomplish a lot this year, with the following achievements being the highlights for me:

Migrated to a new ad-tech partner to increase our revenue per session and better per page revenue breakdowns.
Rolled out a lot of performance improvements which led to all the sites passing the Core Web Vitals assessment. Our sites also load in less than 2 seconds on average now.
Migrated from Nuxt 2 to Nuxt 3 and from Vue 2 to Vue 3.
Launched Starfield Portal which ended the year with 1.5 million page views in just 5 months after launch.
Launched game databases for Starfield and Call of Duty: Modern Warfare 3
Deployed our custom content analytics dashboard with Nuxt 3 and a site health monitoring dashboard with Grafana.
Improved our deployment process by adding support for feature flags and A/B testing.
CMS workflow improvements including a mass link replacement tool, customizable automatic internal linking, built-in integration for freelancer payments and a draft and review workflow.
Redesigned the navigation experience and added support for easier homepage content curation.

The recent developments with AI and the changes in the ad tech market are definitely big challenges for publishers like us. But, we’re confident that our plans for growing our community, increasing engagement and augmenting our content production with custom AI tools will help us grow bigger than ever.

Learning new tech, two new projects and a home server

It has also been a busy year for my personal projects as well. I launched two new side projects this year:

Remote Dev Jobs: A job site focused on helping developers get remote tech jobs.
Smart Spend: An android app to help you plan your expenses and be more mindful of your spending habits.

I didn’t get to add all the features that I wanted to for these projects, but I’m glad that I actually shipped them. I definitely want to push out improvements to them in the next year and market them better.

It was surprising to learn that I published 6 blog posts this year (I know it’s not that much but I only published 3 last year). I also started to use an old laptop as a home server. I mostly use it to manage my media library, run a self-hosted alternative to google photos, run self-hosted versions of LLM chatbots and run automated backups. Sometimes it can be frustrating to maintain and fix issues but self-hosting different services locally has helped me improve my knowledge of docker and it’s also just fun to try out new things on your own local server.

I spent a lot of time learning new technologies as well in 2023. These are the main things that I learn this year:

Finished a masterclass in Nuxt 3.
Did a course on Deep JavaScript foundations and Async programming in JavaScript.
Learnt Golang for backend development.
Learnt a little bit of Elixir and the Phoenix framework. Elixir might be my favorite new technology that I discovered in 2023.
Did a few courses on Langchain.js and Prompt Engineering. Looking forward to integrating this more into the projects that I built in 2024.
Took a look at quasar again for building mobile apps
Discovered n8n and wrote a few automated workflows using it.
Learnt more about how docker containers work.
Used Supabase as the backend for a few projects.
Started using Prisma and Drizzle for my typescript projects. Prisma has the better docs and a bigger community but I prefer the drizzle syntax a lot more.

Plans for 2024 and the perfect tech stack

I spent a lot of time exploring new tech in 2023 but for 2024 I want to focus on getting better with those technologies and launching more projects. So, without further ado, I want to share the perfect tech stack (for most developers) in 2024.

And the best tech stack is…

It’s Laravel. I know a lot of people who hate PHP might disagree but I don’t think there is a better option than Laravel for building web-apps as a solo developer.

I spent a lot of time comparing different frameworks like Ruby on Rails, Nuxt.js, Next.js, Sveltekit, ASP Dontnet, Golang and HTMX, Phoenix, etc but nothing came close to Laravel.

When you’re building something quick and you don’t have the luxury of having millions of users, nothing beats Laravel with it’s simplicity, extensive documentation and fantastic ecosystem.

I would love to use something like Typescript, Go or Elixir for my main language but they just don’t have a framework as mature as Laravel right now. I will still be using Vue and Nuxt for the UI layer because I don’t believe livewire can support building the highly interactive and responsive UIs that I want in my projects. I would also love to build some smaller services with Golang and explore data science and machine learning with Elixir. So for 2024, I'm planning to use this tech stack for my projects

Backend APIs with Laravel
BFF API with Nuxt
Vue.js for the frontend
Golang for performance critical APIs and tooling
Elixir for data science and machine learning
Tailwind and PrimeVue for styling and UI components
Postgres as my database
Vercel for frontend hosting
Fly for backend hosting
Capacitor for mobile apps (with ionic or quasar)
Electron for desktop apps (tauri does look interesting too but no sure about rust)

Conclusion

I still have some doubts about my tech choices, mainly how context switching between multiple languages will affect my productivity but I think the trade-offs are worth it.

I also want to mention how being more reflective about my goals has helped me this year. I’ve started to track my time with toggl and do a weekly, monthly and quarterly review in notion. This has helped me track my progress more consistently while being flexible enough to change my goals when needed so I will definitely continue using this practice and would recommend it for anyone struggling to track their goals.

To sum up, I will be focusing on on the following things in 2024:

Launch more projects
Get proficient with my tech stack
Connect with more developers
Get better at marketing
Publish more blog post
Contribute regularly to open source
Redesigning my personal site

How to debug a Node.js Server

Nirjan Khadka — Mon, 18 Dec 2023 00:00:00 GMT

You can grab the final demo app from my github profile.

How to use the node.js debugger

Node includes a built-in debugger that you can use on the command line. You can do most of the debugging actions that you normally do in the chrome DevTools or the VS Code debugger directly from the command line. Let’s create a very basic node HTTP server to try it out.

How to set up a basic node.js server

I’m using the following tools to setup the HTTP server in node.js:

NPM v8.19.2 (you don’t actually need it, you can just run the commands through node)
Node v20.10.0
VS Code

You can follow these steps to get the server running

Initialize the node project with npm init (you can use the default options for everything)
Create an index.mjs file and paste in the following

    import http from "node:http";
    const PORT = 3000;
    const HOST_NAME = "localhost";
    
    async function fetchData() {
      return new Promise((resolve, reject) => {
        setTimeout(() => {
          resolve("Hello World");
        }, 3000);
      });
    }
    
    const server = http.createServer(async (req, res) => {
      if (req.url === "/") {
        const someDataFromDatabase = await fetchData();
        res.end(someDataFromDatabase);
      }
    });
    
    server.listen(PORT, HOST_NAME, () => {
      console.log(`Server running at http://${HOST_NAME}:${PORT}/`);
    });

Here’s a brief overview of the code
- we import the http module from node
- we create a fetchData function which simulates getting data from somewhere else
- we create the server with a handler that’s setup to handle only the root endpoint
- we setup the server to listen to port 3000 on localhost
You can now add this to the scripts section of the package.json file to setup a start command

    "start": "node index.mjs"

Then, run the command through npm

npm start
when you visit localhost:3000 you should see hello world after 3 seconds.

How to start the node.js debugger

To start the node debugger, you have to add the inspect argument to your node command. So, you can add a start:debug command to the package.json script section like this:

"start:debug": "node inspect index.mjs"

If you run npm run start:debug then the debugger will pause on the first line of the file. To pause it on the debugger statement, you need to set the NODE_INSPECT_RESUME_ON_START variable to 1.

"start:debug": "NODE_INSPECT_RESUME_ON_START=1 node inspect index.mjs"

Now, let’s update out code to add a few debugger statements.

    import http from "node:http";
    const PORT = 3000;
    const HOST_NAME = "localhost";
    
    async function fetchData() {
      return new Promise((resolve, reject) => {
        setTimeout(() => {
          resolve("Hello World");
        }, 3000);
      });
    }
    
    const server = http.createServer(async (req, res) => {
      if (req.url === "/") {
        debugger;
        const someDataFromDatabase = await fetchData();
        debugger;
        res.end(someDataFromDatabase);
      }
    });
    
    server.listen(PORT, HOST_NAME, () => {
      debugger;
      console.log(`Server running at http://${HOST_NAME}:${PORT}/`);
    });

When you run the start:debug command again, you'll see it pause after the server starts listening on the port.

    ❯ npm run start:debug
    
    > debugging-node-server@1.0.0 start:debug
    > NODE_INSPECT_RESUME_ON_START=1 node inspect index.mjs
    
    < Debugger listening on ws://127.0.0.1:9229/69001291-bc1e-4f0a-af8a-685cb2e7c74b
    < For help, see: https://nodejs.org/en/docs/inspector
    < 
    connecting to 127.0.0.1:9229 ... ok
    < Debugger attached.
    < 
    break in index.mjs:23
     21 
     22 server.listen(PORT, HOST_NAME, () => {
    >23   debugger;
     24   console.log(`Server running at http://${HOST_NAME}:${PORT}/`);
     25 });
    debug>

You can use the help command to see all the commands that you can use with this CLI debugger. The most useful ones will be c to continue and repl to go into the repl mode. Inside the repl mode, you can check the values of the variables in your program. Try to get to the last debugger statement and go into the repl mode to check the value of someDataFromDatabase. You just have to type the variable name and press enter in the repl mode to see it’s value. To actually reach that debugger line, you’ll also need to trigger the handler by visiting localhost:3000 in your browser.

You can checkout the full debugger docs on the node documentation to see what else you can do with it.

How to debug node.js using the chrome DevTools

If you’re already used to the chrome DevTools debugger, then you can also debug your node apps using that.

To setup debugging in chrome, you need to use the --inspect flag. Let’s setup another NPM command in your package.json to do this.

    "start:chrome-debug": "node --inspect index.mjs"

Now, when you run it in your terminal, you should see a similar message.

    ❯ npm run start:chrome-debug
    
    > debugging-node-server@1.0.0 start:chrome-debug
    > node --inspect index.mjs
    
    Debugger listening on ws://127.0.0.1:9229/8689da89-80f3-4cd4-bdd9-9a6199c8fc34
    For help, see: https://nodejs.org/en/docs/inspector
    Server running at http://localhost:3000/
    Debugger attached.

You can visit chrome://inspect in chrome to view your app using the chrome DevTools. You should see your app listed in the Remote Target section. Just click on inspect option and then you should see the chrome DevTools open up. Now you can debug your app with the chrome debugger.

How to debug node.js in VS Code

The VS Code debugger uses the CLI debugger under the hood and gives you the same options inside your editor. To start, you can go to the debugger window (Ctrl + Shift + D). If you’re doing this for the first time in your app then it will prompt you to create a launch.json file.

Click on that button to create a new launch.json file. For this specific demo, the default options should be fine. Go to your index.mjs file again and press the “Launch Program” button. It should pause at the first debugger line again and open up the debug console in your VS code terminal.

You can read more about the different options with the debugger on the VS code debugger docs.

I would recommend the following simple changes to the launch.json file for this demo server.

Update the program property to your server entry file so the debugger will run that file regardless of what file you have currently opened . The default option will try to run the currently opened file with node instead.

    "program": "${workspaceRoot}/index.mjs",

If you’re using something like NVM to manage your node versions then you can use the runtimeVersion property to match it to your version of node.

    "runtimeVersion": "20.10.0"

Destructure and rename variables with JavaScript, plus other cool JS destructuring use cases

Nirjan Khadka — Mon, 12 Jun 2023 00:00:00 GMT

Destructuring and Renaming Variables in JavaScript

Destructuring is a useful feature in JavaScript which lets you assign variables to the values of object properties and array items easily. It is a way of unpacking data from objects and arrays into different variables.

This allows you to create new variables from object properties and array items. In JavaScript, you can destructure objects with curly braces {} and arrays with brackets [].

JavaScript Object Destructuring Syntax

Destructuring can be used in lots of ways, but the most common usage is to extract properties from an object or items from an array.

For objects, the syntax is as follows:

const person = { name: 'John', age: 30 }; const { name, age } = person;

Here, we’re destructuring the person object and assigning its name and age property values to a name and age variable.

Note: Destructuring doesn’t actually change the original object at all. It only copies the value of the object properties.

JavaScript Array Destructuring Syntax

For arrays, the syntax is:

const numbers = [1, 2, 3, 4, 5]; const [first, second] = numbers;

In the example above, we use destructuring to assign the first two items from the numbers array to the first and second variables.

Storing the remaining values in a separate variable

You can use the ... rest operator to assign the remaining properties or items in an array to another variable.

const person = { name: 'John', age: 30, country: 'USA', city: 'New York' };
const { name, age, ...remainingProperties } = person;
console.log(remainingProperties) // {country: 'USA', city: 'New York'}

const numbers = [1, 2, 3, 4, 5];
const [first, second, ...remainingItems] = numbers;
console.log(remainingItems) // [3,4,5]

Whatever variable you put the ... rest operator in front of, it will have the rest of the values that you didn’t destructure. It will create a new object when destructuring an object and a new array when destructuring an array.

Renaming variables using destructuring

One of the useful features of destructuring is that it allows you to rename variables during the assignment. You can use the colon : to rename a variable.

For example:

const person = { name: 'John', age: 30 };
const { name: personName, age: personAge } = person;

In this example, we are renaming the name property to personName and the age property to personAge. This is useful when you want to rename a property to something more specific or if there is another variable in the current JavaScript scope with the same name.

Note: the right hand-side will be the new name that you want to use, and the left hand-side will be the name of the property you want to destructure. {name: firstName} means {name as firstName}

Default values with destructuring

You can also set default values for variables in case the value is undefined or null. You can do this by using the equal sign = after the variable name.

For example:

const person = { name: 'John' };
const { name, age = 30 } = person;

In this example, if the age property is not defined in the person object, it will default to 30. This feature is particularly useful when you need to handle optional properties in an object.

Practical examples of destructuring in JavaScript

Destructuring can be used in many practical scenarios such as extracting data from APIs, handling function parameters, and more. Here are a few cool tricks you can do with destructuring in JavaScript.

Extracting function arguments

You can use destructuring to quickly create variables from an object parameter for a function.

function getFullName({ firstName, lastName }) {
    return `${firstName} ${lastName}`;
}

const person = { firstName: 'John', lastName: 'Doe', age: 30 };
const fullName = getFullName(person);

In this example, we are using destructuring to extract the firstName and lastName properties from the person object to get the full name. This makes the code more readable, and the function parameter is self-documenting.

Overall, destructuring and renaming variables in JavaScript is a powerful feature that can simplify your code and make it more readable. With destructuring, you can extract the values you need from objects and arrays with ease, and with renaming, you can make your code more descriptive and self-documenting.

Removing some properties from an object

To remove some properties from an object, you can use destructuring and the rest operator.

const person = { name: 'John', age: 30, country: 'USA', city: 'New York' };
const { age, ...personWithoutAge } = person;
console.log(personWithoutAge) // {name: 'John', country: 'USA', city: 'New York'}

In this example, we are removing the age property from the person object and creating a new object without it. This can be useful when you want to pass an object to a function, but don't want to include certain properties.

Merging arrays and objects

Destructuring is also useful when you want to merge objects or arrays. You can use the spread operator to merge objects or arrays together.

const person = { name: 'John', age: 30 };
const address = { country: 'USA', city: 'New York' };
const mergedPerson = { ...person, ...address };
console.log(mergedPerson) // {name: 'John', age: 30, country: 'USA', city: 'New York'}

const numbers1 = [1, 2, 3];
const numbers2 = [4, 5, 6];
const mergedNumbers = [...numbers1, ...numbers2];
console.log(mergedNumbers) // [1, 2, 3, 4, 5, 6]

Here, we are using the spread operator to merge the person and address objects into a new object. We are also using the spread operator to merge two arrays into a new array. This is a concise way of merging objects and arrays without having to write a lot of code.

Multiple return values

Finally, destructuring can be used to return multiple values from a function.

function getValues() {
    return [1, 2, 3];
}

const [a, b, c] = getValues();
console.log(a, b, c) // 1 2 3

In this example, we are using destructuring to assign the values returned from the getValues function to the variables a, b, and c. This is a convenient way to return multiple values from a function without having to pack them into an object or array.

If you are using react, then this syntax will be familiar. It is used to destructure the return values of useState and other react hooks.

Here's an example of using useState with destructuring in a React component:

import React, { useState } from 'react';

function MyComponent() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
  }

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={handleClick}>Click me</button>
    </div>
  );
}

Summary

JavaScript destructuring allows for easy assignment of object properties and array items to variables. Renaming variables, setting default values, and merging arrays and objects are all possible with destructuring. It can be used in practical scenarios such as extracting data from APIs and handling function parameters. Destructuring is also used in React hooks such as useState. What are your favourite ways of using destructuring? Let me know in the comments below.

JavaScript Performance Testing Made Easy: A Beginner's Guide

Nirjan Khadka — Tue, 23 May 2023 00:00:00 GMT

What causes poor JavaScript performance

First, let’s go over what leads to poor JavaScript performance. The most common causes of poor JavaScript performance are:

Large JavaScript files with lots of unused code that takes a long time to parse and execute
JavaScript Code that blocks the main thread for a long time
Blocking JavaScript code that gets called too often
Memory Leaks. If you’re using too much memory, the Garbage Collector will run more often. This pauses the execution of your JavaScript and can cause a lag.

To figure out you can optimize your JavaScript code further, we need to do some performance tests. Then, we can make the right optimizations based on the results.

JavaScript Performance test for functions

If you already know that you're calling a specific function a lot, then you should test the performance of it. Generally, you can use easy online tools to quickly check the performance of a function. Then, you can make some optimizations and recheck it.

My favourite tool to do this is perf.link. You can check different functions at the same time, and it will show you how many times it can run in a second.

You can also use jsbench.ch or jsbench.me to test JavaScript performance, but perf.link is the easiest to use.

This is a good way to optimize performance bottlenecks. But how do you the performance bottlenecks in your app? This is where the browser DevTools come into play.

JavaScript Performance testing using DevTools

You can use the DevTools in any browser to do performance tests. But, I’m going to use chrome for this post because it has the most in-depth measurement tools. Chrome recently added the new performance insights panel which is easier to use than the old performance tab.

Using the chrome performance insights panel

To open the chrome insights panel, first open the Dev Tools (Ctrl + Shift + I). If you don’t see the Performance Insights panel next to the other tabs (Elements, Network, etc), you can search for it using the command palette (Ctrl + Shift + P).

You can measure the page load performance with this or measure how quickly your app is responding to user interaction.

Measuring Page Load Performance with the Performance Insights Panel

Before you measure the page load performance, you'll want to set up the throttling settings at the top. This allows you to simulate the page load for slower CPUs or slower network connections.

You can also add your own custom network throttling profile to make it closure to your user's network.

This github gist contains the different profile settings for the different network connections.

After setting up the CPU and network throttling, just click on the “Measure page load” button. This will automatically reload the page, start measuring the page load and stop when it’s done.

This will show you a recording of the page-load, with performance related events and insights on the right.

You can click on the insights like Long task, Layout shift, etc to learn more about the issues. It will give you a link to learn how you can fix those issues too.

This is especially helpful for you to debug issues related to Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). These metrics are a part of Core Web Vitals. You can read more about them in my guide to optimizing core web vitals.

You can use this panel to figure out exactly which element is causing the most layout shifts. It will also tell you how much it’s impacting the CLS score. This will then allow you to locate the element in the DOM and prevent the shift from happening.

Additionally, You can click on the Largest Contentful Paint event to figure out which part of the LCP process is taking the longest. This will let you focus on the part that needs the most attention. It also gives you some helpful links to fix some of those issues.

Debugging common performance issues using DevTools

Besides using the Performance insights panel to debug Core Web Vitals issues, you can also use it to debug issues with network resources, long JavaScript tasks and unnecessary layout re-calculations.

Debugging network issues

The network section can help you figure out what resources are loading, their loading time and their order. It shows all the request from when you start your test to the end.

If you click on the dropdown arrow next to network, you can toggle a view which shows the network requests grouped by the domain name. The insights panel can also show you all the render blocking requests.

When you hover over the render blocking request insight, it will highlight the request in the network section on the left. If you click on it, then it will give you more details like about the request. So, you can figure out why you’re making it and if you can avoid the request.

Debugging Long JavaScript Tasks

You can use the performance insights panel to figure out how many long tasks are freezing your site’s UI. Since, JavaScript is single-threaded, if a script takes a long time to run, it will cause your site’s UI to freeze. So, you need to reduce synchronous long tasks as much as possible.

This panel can show you when long tasks are happening and how long the tasks are going on for. If you enable source-maps for your sites, then it will also show you where the functions are in your codebase.

It will look like this when you have a source map enabled. This tool can also show you if the long tasks are happening on a third-party script.

Tips on using the performance insights panel

Here are some tips on using the performance insights panel that will help you make the most out of it:

Use network and CPU throttling
Enable Source maps
Run your tests in incognito mode without any extensions
Only enable the sections you’re focusing on

Summary and tips

In summary, here are the main takeaways from this post:

Poor performance can be caused by various factors, such as unused code, memory leaks, and network issues.
JavaScript performance testing tools like perf.link and the Performance Insights can help identify and fix these issues.
Best practices, such as minimizing file sizes and avoiding long-running tasks, can significantly improve the speed of JavaScript code.
The performance panel offers valuable insights into a website's performance, including load times and network activity.
By following these tips and utilizing performance testing tools, developers can create fast, responsive websites that provide an optimal user experience.

Tools like perf.link and the performance insights panel can be a great way to get started with measuring and debugging your JavaScript performance. But if you want to dive even deeper, then the performance tab will give you even more data on what is impacting your performance. But, it is also more complicated to use, so you might not need it. Let me know in the comments if this helped you fix any JavaScript performance issues, and what do you think is the most frustrating part of debugging JavaScript performance?

Top 10 Software Engineering Podcasts for Developers: Learn from the Best

Nirjan Khadka — Tue, 18 Apr 2023 00:00:00 GMT

Listening to Podcasts is an underrated way to level up in your software development career. It’s also a great way to rest your eyes after working in front of a screen all day. So, Here are my top recommendations for software engineering podcasts.

Best podcasts for Frontend developers

I’ve been working on the frontend for most of my career and as a result, frontend engineering podcasts are some of my favourites in this list. The podcasts listed here won’t be a shock to anyone, as they’re easily the most popular podcasts in the frontend community. But, just because something is popular, it doesn’t mean it’s not good (unless we’re talking about React 😉).

Syntax.fm

Syntax.fm is easily the most popular podcast in the frontend community. Wes Bos and Scott Tolinski do a great job of covering the latest trends and technologies in the frontend community. They’ve sold quite a lot of frontend courses and are great teachers. So, this podcast is especially great for beginners or intermediate developers who want to level-up on a new technology.

JavaScript Jabber

JavaScript Jabber is a weekly panel discussion podcast featuring a rotating group of experts and guests. The podcast covers a range of topics related to JavaScript, including frameworks, libraries, and tools. Sometimes the debate can get a bit heated, but if you enjoy listening to passionate people defend their stance on modern web development, then you’ll love this podcast.

JS Party

JS Party is another panel discussion show with JavaScript experts. The podcast covers a wider range of topics than the previous podcasts. They also branch out and cover other technologies outside of JavaScript that are related to web development. I really like the game show episodes they do, often featuring other podcast hosts from the frontend community.

Best podcasts for Programmers

The next group of podcasts are a bit more generic and could be interesting to people outside of web development too. Because they cover a lot of different topics, some episodes might not be for you, but they all have a great backlog of programming related content.

SE radio

SE radio is a weekly podcast that covers topics related to software engineering like architecture, design patterns, and programming languages. Each episode has expert guests and that discuss topics relevant to programmers. The quality of the episode will depend a lot on the guest, but I find this podcast really useful to get a quick summary on technologies I haven’t used before.

Programming Throwdown

Programming Throwdown is very similar to SE radio in terms of the format. They also feature guest interviews about different programming topics. While SE radio has more variety in terms of guests, Programming Throwdown covers the topic in a bit more detail. The chapter notes included in this podcast are also helpful to skip parts of a discussion you’re already familiar with.

The Changelog

The Changelog is yet another programming interview podcast (are you getting tired of this yet? I promise this is the last one). It’s from the same people behind JS Party. But instead of focusing on just web development, they cover a wider range of programming topics.

You can also subscribe to the master changelog podcast feed to get all the podcasts from the changelog team.

They have great show notes and chapter links on all their episodes. They also have the best production quality out of all the podcasts in this list (shoutout to their editor 👍).

CodingBlocks.Net

CodingBlocks.Net started out as just a .Net podcast, but overtime they’ve branched out into different technologies and topics. All the hosts have great personalities and seem really fun to hang out with. They focus mostly on backend technologies, but they explain the topics really well, so even someone who mostly does frontend like me can follow along easily.

They also do series of episodes focused around programming books occasionally. So if you want to experience a book club in the form of a podcast, then this is definitely something you should follow.

Best Podcasts for Indie Developers

The next set of podcasts are a great listen if you’re an indie dev or a solo founder. If you work alone, then learning a bit more about the business side of things and related stuff like design can be really helpful. These are my favourite podcasts to do just that.

Coder Radio

Coder Radio by Jupiter Broadcasting is a great podcast if you want to hear about coding from the perspective of two business owners. The hosts do a fantastic job of covering the latest coding news and also sharing what they have been working on.

I really enjoy hearing about how they go about their decision-making process. If you like this podcast, then you can check out the Jupiter Broadcasting’s master feed to subscribe to the rest of their shows too. They cover topics related to Linux, open source and self-hosting.

My Life as a Programmer

My Life as a Programmer might be my favourite podcast out of this list. It’s just the audio version of the YouTube clips that Fredrik Christensen puts out.

In it, he answers coding related questions sent by his audience. They are mostly 5–10 minutes long and straight to the point. He doesn’t preach about any specific tools or technologies, instead you’ll get direct actionable advice from an experienced programmer.

Design Details

if you’re like me who’s interested in getting better at the design side of things, then Design Details is the perfect podcast for you. It’s hosted by really experienced designers who have worked for companies like YouTube and GitHub. It’s also a relatively short podcast.

They cover one big topic in every episode and respond to some feedback and questions. Like most of the podcast hosts featured here, they are also great teachers, which makes it easy for non-designers to follow too.

Best Podcast Players

I hope you find this list of podcasts interesting. Let me know in the comments if you’ve listened to any of them or gave them a try after reading this. As a bonus, here are some of my recommendations for podcast players:

Pocket Casts: This is my favourite podcast player. It has lots of customization options and great playback controls. My personal favourite feature is auto-archiving podcast episodes. Since, I subscribe to a lot of podcasts, it can get messy real quick. But, with this, if I don’t listen to an episode within 1 week, it will archive it for me.
Podverse: This is another great podcast player. It’s also open source and continuously improving. It has the best podcast playback options that I've seen. They have an android, IOS, and web app, so you can listen on multiple devices.
Fountain.fm: I'm not too familiar with this app, but it has an interesting concept. It actually rewards you for listening to more content. You can connect your bitcoin wallet and earn some sats while you listen to podcasts.

How to Improve Core Web Vitals: A Complete Guide for Developers

Nirjan Khadka — Tue, 14 Mar 2023 00:00:00 GMT

First, let’s briefly discuss what Core Web Vitals are and how do they impact your site.

Core Web Vitals are page load metrics that measure 3 different aspects of how users experience your site.

Core Web Vitals consists of three metrics:

Largest Contentful Paint (LCP): Measures how quickly the main content loads.
Cumulative Layout Shift (CLS): Measures how stable the layout of the page is.
First Input Delay (FID): Measures how quickly the site responds to user input.

Google uses the Core Web Vitals (CWV) assessment as part of it’s ranking algorithm. So, If your site depends on SEO, then improving CWV can result in more organic traffic. A faster site is also a lot better for your users. Then, there are plenty of other business reasons as well to improve CWV.

To pass the CWV assessment, you must hit the following targets for all three metrics, for at least 75% of page visits:

LCP should be less than 2.5 seconds
FID should be less than 100 milliseconds
CLS should be less than 0.1

Since you need to pass CWV for at least 75% of page visits, you need to improve your site's experience for all users.

For instance, suppose we have a website with 36 visitors. We can sort their Core Web Vitals (CWV) experience from best to worse. The green bars are good CWV, yellow bars need improvements, and red bars are poor CWV.

The 75th percentile for this would be the 26th bar (75% of 36), which is in the needs improvements range. So, this site would fail the CWV assessment.

If we make improvements to speed up the site for visitors that are already getting good CWV then it still won’t pass.The same thing happens when we only make improvements for people getting the poorest CWV.To pass the CWV assessment, you need to make changes that will impact most of your users.

How to measure Core Web Vitals

Before we learn how to improve Core Web Vitals for your site, we need to know how to measure it. You need to have some way of measuring CWV before you start making changes. This will allow you to actually see the impact of your changes. There are two ways to measure CWV.

How to measure Core Web Vitals with Lab data

This is the easiest way to measure Core Web Vitals. This is the easiest way to measure Core Web Vitals. You can use tools like Lighthouse and WebPageTest to measure it locally, on staging and on production.

Lab data, also known as synthetic data, is collected from a controlled environment, rather than actual users.

You can even use Lighthouse CI to add it to your CI/CD pipelines. This is a good way to get started and build a performance-centric culture in your team. But, since Google will use the metrics from your actual users (that use Chrome), you should have some way to get that data too.

How to measure Core Web Vitals with RUM

RUM stands for Real User Metrics, and it’s the best way to track Core Web Vitals. There are lots of services that will track your site’s RUM performance for you. Popular services include Speedcurve, Sentry, Cloudflare Analytics, Cronitor, New Relic and Dynatrace.

If you want to track RUM performance on your own then you can use the web-vitals JavaScript library. With this library, you can send the metrics to any API that you want. If you have Google Analytics then you can use this to send the data to Google Analytics. Then, you can visualize your RUM data in Google Analytics using this tool. If you use BigQuery or Looker Studio then you can use them to create a RUM performance dashboard.

How to check CWV using Google’s Tools

You can also use some tools by Google to check your RUM performance. These tools all use the data from chrome users visiting your site.

CrUX dashboard: You can use this pre-built CrUX dashboard. It uses a Looker Studio template to visualize your data.
Search Console: You can use Google Search Console to view the CWV data on a per-page basis for the sites that you own.
PageSpeed Insights (PSI): You can use the PSI tool to analyze page level and site level metrics. It will show you both the RUM scores and run a lighthouse test for you. You can also use the PSI API to automate the testing of your pages.

How to keep track of your Core Web Vitals

Once you have a Lab and RUM tracking system in place, you should keep monitoring your Core Web Vitals. It is especially important to check them after a release to avoid any regressions. You can also setup alerts when you get performance issues so you can respond quicker. I find this workflow helpful when tracking Core Web Vitals:

Setup performance tests on your CI pipeline to avoid deploying any new issues.
Setup running Lab tests whenever you make a new deployment and tag the test with the deployment ID.
Have RUM tracking enabled for all your users.
Setup alerts whenever you notice the metrics go over a certain threshold.
Set up a combined dashboard with your user analytics (some tools will have this out of the box). Then you can corelate site performance with your conversion metrics.
Make sure you follow these guidelines when setting up your RUM tracking.

Now that we know how to track Core Web Vitals, let’s look at how we can fix your site's Core Web Vitals.

How to improve CLS score

What is CLS?

Cumulative Layout Shift (CLS) measures how much your layout shifts during page visit. The more stable the layout, the better scores you will get.

Cumulative Layout Shift metric, measures the instability of content by summing shift scores across layout shifts that don't occur within 500ms of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.

What causes CLS issues?

Layout shifts happen when elements that don't have a fixed height, load after the initial HTML. Elements like images, ads, embeds and banners can cause this issue. Fonts that are a different size than the fallback system font you are using can also cause CLS. When the font loads and replaces the system font, text will be bigger/smaller and cause a layout shift.

Debugging and Fixing CLS issues

You can run a lighthouse test or use the chrome performance insights panel to find the layout shifting elements.

Compared to the other CWV metrics, CLS is actually pretty easy to get right. To improve your CLS score, you can follow these steps

Set the width and height size on your images and video

All Modern browsers can calculate the aspect ratio for your images based on the width and height you set. They will add this style to your images by default.

img { 
  aspect-ratio: attr(width) / attr(height); 
 }

You also don’t have to worry about the image not being responsive. For example if you have an image that’s 800px wide and 400px tall, then you can set the width and height like this:

<img width="800" height="400" class="my-img" src="/path/to/image.jpg" alt="image description" />'

Then you can make it responsive from your CSS

 .my-image { 
   width: 100%;
   height: auto;
 }

Now you have a responsive image that doesn’t have any layout shifts. The Browser will reserve the height based on the aspect ratio calculated from the width and height attributes. Then, because of the CSS, the image will only be 100% of it’s container and won’t go outside of it.

Set a content placeholder for dynamic content

You should set a placeholder for dynamic content like ads, embeds banners, etc.

You can create a container div and set the right width and height for it. You can also hide overflowing content, in case the dynamic content is bigger than you expected.

.container { 
  display: block; 
  width: 300px;
  height: 600px; 
  overflow: hidden; 
}

<div class="container"> <div class="my-special-widget"> ... </div> </div>

Use a fallback font that’s close to your custom font

If you are using a web font then you need to make sure you use a fallback font that’s a similar size to it. This will make sure that when the browser downloads the font and applies it, the text doesn’t jump around too much. Other font optimizations that google recommends are:

preloading the web font with <link rel=preload>
combining preloading with font-display: optional

How to fix FID issues

What is FID?

First Input Delay (FID) measures how fast your site can respond to user input.

FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

To pass the Core Web Vitals assessment your site needs to have an FID of 100 miliseconds or less. Another thing to remeber with FID is that it only measures the delay in event processing. This means, the response to the user’s input can be longer but it needs to process it as fast as possible. So, the response to user inputs like clicks, taps and key presses needs to be fast

What causes FID issues?

The main causes of FID is long running JavaScript tasks or large JavaScript files. Long running tasks in your scripts can block the browser from responding to user input. Likewise, if you have lots of JavaScript files or big JavaScript files then the browser will need more time to run it.

Debugging and fixing FID issues

FID is difficult to measure because it requires a real user to actually interact with your site. Instead, You can use a metric called Total Blocking Time (TBT) to estimate your FID. You can get your TBT score by running a lighthouse test. It can give you a good estimate but to get the actual data for FID, you should use some sort of RUM tracking.

The main ways to improve your FID score include:

Regularly Audit your third party scripts to make sure you aren’t using large scripts or scripts that have long running tasks.
Reducing long running tasks in your own code
Try to use async code as much as possible instead of code that blocks the main thread
Load less JavaScript on your page -make use of codespliting and minify and compress your code
Don’t load any unnecessary JavaScript on your page

As you may have noticed, a lot of these tips involve reducing the amount of JavaScript on your site. If you are starting a new project, frameworks like astro, remix or qwik can help you to ship less JavaScript.

How to improve LCP score

What is LCP

Largest Contentful Paint (LCP) measures how long a page takes to load the largest image or text block (above the fold). Your site needs to have an LCP of 2.5 seconds or less for at least 75% of page views to pass thre Core Web Vitals assessment.

Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics, and it represents how quickly the main content of a web page is loaded.

What causes LCP issues?

LCP is the hardest CWV metric to get right because there are so many possible reasons for a bad LCP score. You can breakdown the loading into different steps to figure out where the bottleneck is. The most common reasons for having a bad LCP score include:

Slow response from the server which maskes the HTML load slowly. This in turn makes the LCP element load slower.
Delaying the loading of the LCP element. If the HTML is fast but there is a significant delay in loading the LCP element itself then it will have a bad LCP score.
The LCP element taking a long time to load. If the LCP element is a big image or relies on a large font download then this could be another reason for a bad LCP score.
Blocking the LCP element from rendering. If JavaScript or CSS blocks the LCP element from rendering then it can also lead to bad LCP scores.

How to optimize Largest Contentful Paint

In most cases, there are many reasons for a site having a poor LCP score, not only one reason. So, the best approach is to break down these parts and optimize them.

How to fix LCP element load delay

This is often the most easy thing to do when optimizing LCP. You should set the loading priority for the LCP element high enough so that it gets loaded as soon as the HTML loads. The sooner the browser can know about the LCP element and download it, the sooner it will load. To do this you can follow these steps:

If the LCP element is an image, make sure to load it from the HTML and not from the CSS. If your LCP element is a CSS background image then it will need to wait for the CSS file to download. So, you should to keep the LCP element in the initial HTML.

<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp"> <link rel="preload" fetchpriority="high" as="image" href="/path/to/font.woff2" type="font">

Preload your LCP element. If your LCP element is an image, then preload the image using a link preload tag. If your HTML element is a text block then preload the font file.
Use priority hints to make sure your are setting the highest priority for your LCP element. You can then check how early the element is being loaded by using this resource hint validator tool.

How to make the LCP element render sooner

Sometimes even after loading the LCP element, the browser can’t render it immediately. These are the main causes that can block an LCP element from rendering:

Synchronous Render Blocking JavaScript or CSS in the head of the document.
Adding the LCP element to the DOM with JavaScript after the page loads. It will need to wait for the JavaScript to load, execute and then add the element.
A/B testing tools or some other similar logic that is deciding whether to add the LCP element to the page or not.
Blocking of the main thread by long running JavaScript tasks. The element will need to wait for it to finish before rendering.

To fix the issues mentioned above, you can follow these steps:

Inline any critical CSS and JavaScript in the HTML. (make sure to not inline too much CSS or JS)
Reduce the size of the CSS and JavaScript files.
Remove any unused CSS and JavaScript. You can use the chrome dev tools to find unused CSS and JavaScript.
Minify and Compress your JavaScript and CSS.
Don’t use any JavaScript script tags without the async or defer attributes. This will prevent it from blocking the rendering.
Don’t use client-side rendering. Instead use server-side rendering or static site generation instead. This will mean your LCP element will be in the initial HTML document.
Avoid long tasks in JavaScript as much as possible. If a JavaScript process takes a long time to finish then the browser will delay rendering the images. This is because browsers render images using the main thread which long JS tasks can block.

How to make the LCP element load faster

The LCP element of your page will be the main featured image in most cases. If you don’t have a featured image on your page then it will be the text. So, this means you need to optmize the LCP element to make it load faster. Here are the most common ways load your LCP element faster:

Reduce the size of your image or web font. Make sure you’re not serving uneccesarily large images.
Use modern image formats like AVIF or WebP. They will often be a lot smaller than the JPEG or PNG version of the image.
Use a CDN to serve assets. Look for a CDN that allows you to proxy requests from your domain. This will reduce the extra step the browser has to do to connect to the domain of the CDN provider.
Don’t load too many resources at the same time that you are loading your LCP element.
Cache your LCP element so users visiting again will see the LCP element immediately.

How to load your HTML faster

This is the most difficult way to optimize LCP as it involves making changes in different places. You can start by finding out what is the slowest part of loading your HTML. Different Cloud providers offer different ways to measure your server processing times.

You might have to make changes to your server-side code, hosting provider, CDN, etc. Here are the most effective ways to load your HTML document faster:

Use a good hosting provider with the most optimized settings for your site. Take a look at the memory consumption and CPU ussage for your site. Make sure your server is capable of handling the traffic you are getting. If it's failing to do that, you should try scalling your server horizontally or vertically.
Use a CDN on top of your server so you can serve cached content from your server to your users faster. Some popular CDNs for this are Cloudflare, Fastly and Cloudfront. Make sure to check the cache-hit ratio your are getting. You should be hitting the cache for most of your user vistis if your site’s content doesn’t change often.
Update links on your site that are redirecting to another page. Having lots of redirects can cause the page to load slower. So, you shoud try to edit all links that are redirecting within your site.
Stream HTML to the browser. Some server side technologies can stream HTML so the browser doesn’t have to wait to get it all at once.
If your content doesn't change too often then you can use a service worker with the Stale-while-revalidate approach.
If you want to speed up your page navigation, then this approach of using a service worker with streams can help.
Check how fast your database queries are executing. You might have to make some database optimizations to get the data for your pages faster.
Make use of 103 Early Hints to load critical assets for the HTML faster.

Checklist for Improving Core Web Vitals

Here's a checklist to help you optimize your site for Core Web Vitals:

Measuring Core Web Vitals

[ ] Use lab data testing with tools like Lighthouse and WebPageTest to get started.
[ ] Use RUM data tracking to get data from actual users.
[ ] Use Google's tools like CrUX dashboard, Search Console, and PageSpeed Insights to track CWV.

How to Fix CLS Issues

[ ] Set the width and height size on your images and video.
[ ] Set a content placeholder for dynamic content.
[ ] Use a fallback font that's close to your custom font.

How to Fix FID Issues

[ ] Avoid long running JavaScript tasks or large JavaScript files.
[ ] Regularly audit your third-party scripts.
[ ] Use async code as much as possible instead of code that blocks the main thread.

How to Fix LCP Issues

[ ] Reduce the size of your image or web font.
[ ] Use modern image formats like AVIF or WebP.
[ ] Use a CDN to serve assets.
[ ] Don’t load too many resources at the same time that you are loading your LCP element.
[ ] Cache your LCP element so users visiting again will see the LCP element immediately.
[ ] Use a good hosting provider with the most optimized settings for your site.

General Best Practices

[ ] Reduce the use of third-party scripts and keep them up-to-date.
[ ] Use lazy loading for images and other non-critical resources.
[ ] Avoid using large JavaScript libraries and frameworks.
[ ] Optimize your CSS to cut down on render-blocking stylesheets.
[ ] Use server-side rendering or static site generation to reduce the load on the client.
[ ] Use a service worker to cache content.
[ ] Optimize your web server to reduce response times.
[ ] Use a content delivery network (CDN) to serve content closer to your users.

By following these steps, you'll optimize your site for Core Web Vitals and a better user experience. Remember that improving your CWV will also improve your search engine rankings. So, it's worth taking the time to make these improvements.

Tools for Improving Core Web Vitals

Here are some tools that will be useful to improve your Core Web Vitals.

Lighthouse - an open-source tool developed by Google that measures and improves site performance
WebPageTest - a free online tool that tests site performance from different locations worldwide
Google Analytics - tracks Core Web Vitals and provides custom reports and dashboards
Chrome DevTools - built-in web developer tools in the Chrome browser for real-time performance optimization
PageSpeed Insights - a Google tool that analyzes site performance and provides improvement recommendations
SpeedCurve - a tool that tracks site performance over time, providing detailed metrics and visualizations
GTmetrix - analyzes site speed and provides actionable insights for optimization
Pingdom - monitors site performance and uptime, and provides alerts for issues
YSlow - analyzes site speed and provides recommendations for improvement
Varvy Pagespeed Optimization - analyzes site speed and provides detailed recommendations for optimiza
Web.dev - a Google resource that provides guidance and tools for improving site performan
CrUX dashboard: A tool that provides aggregated metrics for a large number of sites, based on real-world user data.
Lighthouse CI: A continuous integration service for Lighthouse, which runs Lighthouse tests on every pull request to your codebase.
Search Console: A free tool from Google that helps you monitor, maintain, and improve your site's presence in Google Search results.
Cloudflare Analytics: A tool that provides insights into your site's performance, security, and reliability. It includes Core Web Vitals data.
Sentry: A tool for error tracking and monitoring. It can help you identify and fix issues that are impacting your site's performance.
Google Analytics: A tool that provides insights into your site's traffic, user behavior, and performance.
Performance Insights Panel: A panel in the Chrome DevTools that provides insights into your site's performance, including Core Web Vitals data.
Debugbear Resource Validator: A tool that can help you validate your resource hints, including preload and prefetch hints, to ensure that they are being used correctly and are improving your site's performance.

Software Development Project Management 101: How to Stay On Track and Deliver Quality Software

Nirjan Khadka — Wed, 01 Mar 2023 00:00:00 GMT

Goals of Project Management in Software Development

This isn't about a specific framework like Agile, Scrum, Kanban, etc. Instead, it's about practices that should work with them all. You should use those frameworks as tools for your end goal, not as a strict checklist to follow. A good project management plan should cover how to do these three things well:

Build the right thing
Build the thing right
Build the thing fast

Key Roles in a Software Development Team: Product Owner, Project Manager and Individual Contributors

To build a successful product, you'll need a team of people with different expertise. Each person needs to know exactly what their role is and how they can do it most effectively. Here are some key roles in a software development team:

Product Owner: The PO is in charge of the “build the thing right” part. This person acts as a bridge between the stakeholders and the dev team. They need to be a good communicator and should explain the goals of the product to the dev team. They should prioritize the tasks, so the team can focus on the most valuable tasks for the business.
Project Manager: This person is in charge of the “build the thing fast” part. It's their job to make sure the team is as efficient as possible. They need to manage people, remove blockers for the team, and increase productivity. They should coach the team, analyse progress, and make changes to deliver things on time.
Individual Contributors: They are responsible for the “build the thing right” part. This includes people from the dev team, the design team, the QA team, etc. They should build the product to a certain standard. They need to meet the requirements set by the PO.

Document the Project Management Process

You should have clear documentation on the steps each team member needs to take and when. This ensures everyone is as efficient as possible. Include all the steps of the project management process and what each team member needs to do.

Make sure to update this often as processes may change over time. You can also automate some of the tedious steps that the team members need to do to keep it updated.

Create consistent task descriptions

You should create a consistent task template for all similar tasks. The template can be different for each team or company. But, it should encourage the creators to include all the relevant details.

Our templates look like this: As a <user role>, I want to <feature description> so that <benefit>. We also leave some room for more context and comments from the person creating the task. All task descriptions should have the following:

Who will benefit from the task
Clear explanation of the requested change
How will it be beneficial for the business (with calculations or estimated improvements if possible)
Any examples by other sites/apps
Does this have a fixed deadline

Create a task checklist

You must have a clear idea of what you should finish, to complete a task. This helps with sprint reviews, or individual PR reviews. A checklist is a great thing to include in a task. This helps the task creator to communicate to the developers exactly what they want.

How to estimate a task

This is one of the most difficult things to do. But for effective project management, it is something we have to do. Without estimates, it's hard to prioritize the work.

It also makes it difficult to communicate the status of the project to the stakeholders. Some teams prefer time estimation, while some teams prefer estimating using story points. Our team moved from time estimation to story point estimation. Here’s a helpful guide on story points estimation.

How to prioritize tasks

A good prioritization system will make sure your team is focusing on the right things. If you already have a good system for creating tasks and estimating them, then this part should be easy.

Your team needs to settle on a consistent and clear prioritization system. In our team, we're using this formula, (Business point + Time Criticality) / Story points. Business points,

Time criticality and Story points all use a modified Fibonacci series as the values, e.g. 1,2,3,5,8,13,20,40, etc. A good priority formula should account for the following:

How time sensitive a task is
How much value will it bring to the business
How complex will it be to finish it

Setting up a review process

At the end of each sprint, there needs to be a review. The team should go over what they accomplished and celebrate that. They should also look at any problems faced during the sprint and find ways to avoid that in future sprints.

It can be hard to schedule time for the review in a fast-paced environment, but this is one of the most important parts of the process. You should check that your process is actually working and meeting your needs.

Make sure you're not blindly following a plan just because it's easy and that's how you've always done it. You should track the key objectives of your business. Then see if the work you've done in your previous sprint has actually got you closer to the objectives or not. If they haven't, then you need to refine all the items mentioned above for the next sprint.

Besides the sprint review, you should also have a check-in process to see how the team is progressing on the tasks. This doesn’t need to be as thorough as the sprint review. This should remove any blockers from the team and figure out if the team is on track or not.

Communication within the team

You should have a clear communication system set up for your team, especially if it’s a remote team. Try to keep it as asynchronous as possible. Tailor your communication for the intended audience.

Highlight the stuff that your audience actually cares about. Be careful not to have too little communication, which can make people lost. Also, don't over communicate, which can cause information overload. When creating your process documentation, include how the team should give out updates.

Conclusion and checklist

I hope these tips have helped you decide what things you need to do next for your process. Here’s a list of stuff that will help you make your process better:

Make sure each team member is aware of their role in the team.
Make sure each team member knows the full process they should follow as part of their role.
Have a consistent Task template and ensure everyone follows it.
All tasks should have a checklist that the team can review.
Estimate tasks in relative values instead of an absolute value like a time duration.
Each task should have an estimate for it.
Create a prioritization system which should sort the tasks automatically for the team.
Have a template for your review process. Make sure to tie down the reviews with the key metrics your business cares about.
Have check-ins within sprints to check whether the team is on track or not.
Set up async communication between the team and the key stakeholders. Inform everyone about the key areas they actually care about. Tailor your communication for the intended audience.
The Product Owner should communicate the business priorities to the dev team.
The Project Manager should inform the Product Owner about the status of the different work streams.
The Dev team should communicate the changes made to the Product Owner.
The Product Owner and the Dev team should inform the design team on the goals of the designs and the technical limitations for the design.

Moving to a Tech Lead role, Working on More Side projects, Learning Sveltekit and C# | 2022 review

Nirjan Khadka — Fri, 30 Dec 2022 00:00:00 GMT

I also wrote about my experience in 2021 if you want to take a look at how that went down.

New role at work

I was officially promoted to the Technical Lead role at Gfinity Digital Media. This has meant shifting my focus more towards management than coding. While there are some aspects of the role that I don't enjoy as much, like an increase in meetings and process management, I'm excited to be able to play a bigger role in shaping the vision and strategy of the company. I've also really enjoyed improving the workflow of my team and helping them grow as we work to make our sites better with each release.

Major accomplishments

Together with my amazing team, we were able to accomplish quite a lot. Some of the highlights include:

Migrating two new sites from WordPress to our custom Manifold tech stack
Adding a suite of automation tools to help our content team produce better content faster
Improving our personalization tech to serve more personalized promotions on our network
Working with the Stockinformer team to add a custom products’ widget on our sites that can track the stock and prices of products in almost real-time
Faster and smoother editing experience for larger articles in our CMS
More fine-grained access controls for our CMS
More UI improvements to large sections of our sites like navigation, search, article cards, image and video galleries, etc
Improved the speed of RSS feed and sitemap generation significantly
New Ad placement algorithm to improve the UX of our sites while boosting ad revenue and impressions
Started adding automated tests for the most important parts of our codebase
Improvements to documentation and product analytics

Things I learned in 2022

I've been able to learn a lot about management this year, but that has limited my ability to learn new technical skills. To make up for this, I've made a conscious effort to set aside personal time to work on side projects. Some of the things I've learned or delved deeper into this year include:

Started learning about C# and dotnet
Learned Next.js and migrated my personal site from Elder.js to Next.js
Started learning Sveltekit
Tried out Nuxt 3
Currently building a side-project using Supabase and Sveltekit
Moved my site from markdown to Sanity.io
Started Learning Google BigQuery and Google DataStudio
Did the SEO for Devs course

One of the main takeaways I've had this year is the importance of being clinical in deciding where to spend my time and energy. I also plan to be more consistent with my "learning in public" approach and not worry so much about perfection.

Things I want to learn in 2023

I already have a huge list of things I want to learn in 2023. This may change in the future but here are the things I want to learn next year:

More Sveltekit (I really like the progressive enhancement concepts and the simplicity of the dev experience)
More Supabase and Postgres (I want to do more side-projects using supabase and want to dive deeper into Postgres too)
Improving my SEO knowledge (while ChatGPT is a threat to google, I don’t see the value of SEO skills declining for at least another decade)
Improving my backend skills (I want to get some experience with more backend technologies so that I can be a bit more well-rounded)
Marketing (I want to be able to market my side-projects and start generating some revenue from them)
Writing (I want to write more in 2023 and keep improving my writing and communication skills)
Machine Learning and AI models
Finally, I want to continue improving my team leadership skills and finding ways to better support and empower my team.

My focus in 2023

I’m honestly looking forward to 2023. I want to launch a couple of products and learn how to market them. Furthermore, I’m also looking forward to doing more svelte and learning more about backend technologies. It’s going to be hard, but I’m going to try to write a lot more and document my journey in 2023 as I build and learn new things along the way. Happy new year, everyone! Hope you have a great year ahead.

11 easy tips to fix bugs and debug your code faster

Nirjan Khadka — Fri, 25 Mar 2022 00:00:00 GMT

1. Gather info

Your dev tools are your best friends during this step. Look for error messages in the console or your logging tool of choice. Try to reproduce your error by focusing on certain parts of your app. Look at the end-game. Ask yourself what are you trying to do? Try to be focused instead of looking everywhere. The better you get at filtering logs, the easier this will get.

Can you build a simpler version some place else like codepen, codesandbox, stackblitz, etc?

You need to be analytical in this step of the process and think like a detective.

2. Go through your code

Actually read your code – don't skim it. Think about how the code is actually working. Follow the control flow of the code. If you have a whiteboard or even a notebook, then use that in this step. Try to visualize your code and create a mental model of how it's working. Can you spot any logical issues with your code? This step can also help you figure out if you need to refactor your code, too. If it's hard to read and reason about then when you're done fixing the bug, you should also make a note of coming back to this and refactoring it.

3. Stay calm and take a break

It's easy to get nervous or worked up when the stakes are high, but panicking won't help. Don't stress out about finding the bug. Take a 10-minute walk or take deep breaths, take a shower, stretch, anything that will help clear your mind.

Sometimes our subconscious is a much better coder than we are. We can stumble upon the fix when we least expect it. This is also a good time to ask for help if you are working in a team. Normally, I ask for help if I get stuck on a problem for more than 2 hours without any progress.

You don't want to go to your teammates for every small issue. But there is also no point in wasting hours of your time if they can help you fix it in minutes.

4. Make it simple

Make your code simpler, break it into smaller parts. Limit the number of inputs and outputs. Get it working in a limited capacity. (e.g. safe mode, Codepen, etc.)

Comment out major sections of code until you have a working example. Ask yourself, does this issue exist outside the framework? Does this work in a clean environment? Sometimes the bugs can exist outside your code. It might just be a bug in a third party library.

5. Test in all environments

Testing in different environments can help you discover the cause of your errors quicker. You should be able to take a look at the problem at different levels. Does it work locally but not on the server? Does it work in other browsers? Is it breaking only on mobile and not desktop? Tools like lambdatest and browserstack are great for this.

6. Talk it over

Getting the perspective of another developer can be extremely helpful. Even talking to a non developer about what you are trying to do can sometimes help you get to the root of your issue. Even if you're alone, just saying the problem out loud can be helpful.

7. Use Git

Commit your code often. If you're worrying about having too many commits in your branch, then you can squash them when you're done. If your code commits are up-to-date, you can change code without fear of deleting things. Just revert to a previous commit once you find the issue and fix it. You can use git features like stashing to try out different things.

8. Don't jump to solutions

Take the time to dissect the problem. Question your assumptions. If you're thinking It can't possibly be a problem with x, then it might actually be a problem with x. Nothing should be off the table. Sometimes the cause of your bugs are in the place you least expected.

9. Get good at pattern matching

This comes with experience. After fixing a lot of bugs throughout your career, you'll notice yourself asking the same questions. When did this problem start? Did we deploy any code? Did we change any logic? X bugs tend to happen when Y happens. This is mostly about figuring out the right questions to ask.

10. Document your bug fixes

This is related to the last tip. It's not good enough to only recognize the questions you're asking to find the bugs. You should also document it somehow. List your errors, their causes, and their solution somewhere. You never know when you will run into the same problem again. You don't have to list every bug, only the ones that took a long time to find the fix for.

I like to list all the bugs and their fixes that I've faced before using GitHub issues. You can use the labels to organize them and the search feature to find the bug fix you're looking for.

11. Google

Get good at googling, being able to describe your problem is key. Learn to search for keywords that will help you find solutions quicker. Also, learn to search in sites like stackoverflow, GitHub issue pages, discord channels, etc.

Most likely someone has already faced a similar problem. So, there is already a fix for it somewhere on the internet.

Do you have any other debugging tips? I would love to hear about it in the comments section. Thanks for reading.

First remote job, leading a team, learning SEO | 2021 review from a web developer

Nirjan Khadka — Sat, 08 Jan 2022 00:00:00 GMT

This was a pretty big year for me. While my personal life didn’t change a lot because of the pandemic, my professional life changed quite a lot. I got my first remote role, got involved more in management and met lots of talented people. I don’t remember each moment, but I do have some highlights for the year that I want to go through in this post.

Work update

I joined Gfinity in December 2020 so this year I finished my first full year at Gfinity. My experience has been pretty good so far. We have a great team of talented developers from around the world. The team that I’m working on is small, so we’ve had a chance to get to know each other pretty well. I like the fact that my team can run at a startup speed without a rigid bureaucratic management team. Yet, we don't have to constantly worry about raising money. We have a flexible remote working culture that has allowed me to improve my work-life balance.

Some notable moments for me at gfinity so far include:

Being able to manage a team for the first time in my career.
Architecting a new platform (Manifold) to power the sites in our network.
First time working with SEO and Ads. It was challenging, but the experience of working with them has made me a better developer.
Learning more about improving site performance. A huge part of my job was improving the performance of the sites in our network.
Being able to improve my project management skills. This was the first time I had to actually go in-depth with project management. There are still some that I need to improve on, but I’ve made good progress in this part of my skill set. I still have a love-hate relationship with click up (our project management tool).

Accomplishments

These are the things that I’m most proud of in 2021:

First time leading a team of developers.
Architecting the manifold platform that will power all our sites going forward.
Being able to contribute to the decision-making process as well instead of only working on tech features.
Improving the project management process for my team.
SEO improvements made to the Gfinity Digital Media sites (ended the year at 15.5 monthly unique users).
Performance improvements made to the Gfinity Digital Media sites (went from sites loading MBs of only JavaScript and 800KB of compressed HTML to 600 KB for all resources including HTML, JS, CSS, images and fonts). We’re also close to getting a green CWV score on all the sites using our manifold platform.
Migrated two sites from WordPress and a legacy CMS over to the new manifold platform.
Kept a consistent deployment schedule for almost the entire year.

What next

It has been an eventful year, but I expect 2022 to be even bigger. These are the things I’m most excited for in 2022

Growing the GDM network (more sites, more traffic, more revenue).
Process improvements — I want to further optimize our tech precesses like sprint planning, CI/CD, automated testing, etc.
Re-architechting manifold — the first version of manifold has served its purpose well. Now we need to update it to fit the current requirements of the network.
Focusing on writing high quality tests for the most important parts of the network.
Growing the GDM community — only having high traffic is not enough. We should be aiming to have a more engaged user base and strive to provide more value to our users.
Writing more posts — There are lots of topics like SEO, web performance, CSS, project management, debugging, UI/UX,etc that I'm interested in. I'm hoping to write about them a lot more this year.

Wrapping up

It has been a crazy challenging year in which I got to grow quite a lot in my role. Special shoutout to Mike Stevens, Eric Ping and Dominc Needler at Gfinity who believed in my capabilities and trusted me to lead the amazing GDM tech team (Vlad, Raymond, Victor). On a personal note, I am looking forward to writing more and building more cool stuff in 2022. Happy new year, everyone!

How to build accessible hidden navigation menus on the web

Nirjan Khadka — Thu, 15 Jul 2021 00:00:00 GMT

How most hidden Menus work

Most hidden menus work by using JavaScript to change the styles or toggle a class to show or hide a bunch of links.

    .menu-list {
    //hide menu
    }
    
    .menu--is-open .menu-list {
    // show menu
    }

I've created a basic nav menu on codepen. You can use that to follow along with this post.

Semantic HTML

Using good semantic HTML is essential to creating accessible sites. In my example, I've wrapped the links in an unordered list. So, the screen reader can know how many links are there in the list.

I've wrapped the list in a nav tag. I've then wrapped the nav tag in a header tag. I'm also using a button to toggle the menu and not a span or a div. So, the user can focus on it by tabbing and use the button with just the keyboard. The menu button shouldn't be a link either because it won't link to anything.

You should always try to find the correct HTML tag for your use-case, instead of just using divs or spans everywhere. The elements reference page on MDN is great for researching what tags to use where.

    <header class="main-header">
      <a class="brand-logo" href="/">NK Studio</a>
     
      <nav class="main-nav" id="primary-nav">
        <button class="menu-btn">
          Menu
          <i class="gg-menu menu-btn__icon"></i>
        </button>
        <ul class="main-nav__list">
          <li class="main-nav__list-item">
            <a class="main-nav__link" href="#about">About</a>
          </li>
          <li class="main-nav__list-item">
            <a class="main-nav__link" href="#team">Team</a>
          </li>
          <li class="main-nav__list-item">
            <a class="main-nav__link"href="#portfolio">Portfolio</a>
          </li>
          <li class="main-nav__list-item">
            <a class="main-nav__link" href="#case-studies">Case studies</a>
          </li>
        </ul>  
      </nav>
    </header>

Note: I'm placing the Menu button inside the nav tag. This is to ensure that the people who move to the nav tag using a shortcut won't just find a hidden list. They'll find the button to open the nav menu. You should also make sure that the focus order makes sense. Here the next item that is focusable after the menu button is the first link in the menu.

Hiding the menu

You need to make sure that the hidden menu is not accessible without opening it. You should use the display or visibility property to hide the menu. This makes sure that the hidden menu isn't focused when tabbing and aren't read by screen readers.

Be careful if you're only using transforms, width, opacity or any other similar properties to hide the menu. Screen readers can still access them, and users can reach them by tabbing. So, you need to use the display or visibility property to hide the menu.

In this example, I'm using a high negative transformY value to hide the menu. So I need to use the visibility property to make sure the hidden nav is not accessible without opening it. You could also use the display property, but it can be bad for performance.

    .main-nav__list{
      // other styles
    
      transform: translateY(-999px);
      visibility: hidden;
    }
      
      
    .main-nav--is-open .main-nav__list {
      transform: translateY(0);
      visibility: visible;
    }

Communicating Menu States

The next thing you need to do is make sure all the users of your site are aware of the menu's open and closed states. This is simple for sighted users as they can just see the menu open and close, but you also need to make sure any users with visual impairments can tell the current state of the menu.

We need to add an aria-expanded attribute to the button. This informs the user about the current state of the button and lets them know we can open the menu using the button. We need to change the value of aria-expanded to true when it's open and to false when it's closed.

    <button class="menu-btn" aria-expanded="false">
      Menu
      <i class="gg-menu menu-btn__icon"></i>
    </button>

    function toggleAriaExpanded() {
      const isExpanded = menuBtn.getAttribute('aria-expanded') === 'true';
      
      let newState;
      if (isExpanded) {
        newState = false;
      } else {
        newState = true;
      }
      menuBtn.setAttribute('aria-expanded', newState);
    }

Adding Aria-controls

The aria-controls attribute helps screen reader users navigate from a controlling element to a controlled element. But, it is only supported in the JAWS screen reader. So you simply can’t rely on it.

The aria-controls attribute is still a nice to have feature for JAWS users and since it doesn't do much harm, we can choose to add it to our menu.

We just need to add it to the menu button and set the value to the value of the ID for the menu.

    <button class="menu-btn" aria-expanded="false" aria-controls="nav-list">
      Menu
      <i class="gg-menu menu-btn__icon"></i>
    </button>
    <ul class="main-nav__list" id="nav-list">

Where to go from here

If you follow all the tips mentioned in this post, then you should have a more accessible nav menu for your site. Make sure to test this using an actual screen reader.

There are other types of menus that aren't used for site navigation. Instead, they're used for choosing options in an app. Take a look at Heydon Pickering's excellent guide to building inclusive menus.

If you're using a hover menu, then it might be a good time to switch to click menus, as mentioned in this post on csstricks.

Step by Step guide to CSS text truncate; different ways to truncate text with CSS

Nirjan Khadka — Tue, 22 Jun 2021 00:00:00 GMT

Text Truncate in CSS

Truncated or shortened text is most common when you're working on a design with equal-height columns. But generally, the text for those columns is dynamic. I had to work on a design like that at work recently.

The category names like Mario, Nintendo, Call of Duty: Modern Warfare, etc need to be in a single line. If it doesn't fit, then I need to truncate it. I also need to truncate the title of the article to 4 lines. So, for this specific layout, I had to do CSS text truncate for both a single line and multiple lines.

How to do CSS text truncate?

Let's start off with a single line CSS text truncate with a “p” tag. You can follow along with me using this snippet. Here's the link to the finished codepen if you want to copy it from there.

<p class="single-truncate">
  Call of Duty: Modern Warfare
</p>

/* global styles */
body {
  min-height: 100vh;
  display: grid;
  place-items: center;
  gap: 0.8em;
  font-family: Arial,Helvetica Neue,Helvetica,sans-serif;
  font-size: 1.6rem;
}

p {
  background: tomato;
  padding: 1em;
}

Here are the steps you need to follow to truncate this text.

1. Setting fixed width with CSS

You need to set a width on the element that you are targetting. So, the browser knows how long the text should be before you truncate it.

/* truncate stuff */
.single-truncate {
  width: 150px;
}

2. Using the white-space property in CSS

To avoid wrapping the text to the next line, we need to set the white-space property to nowrap.

.single-truncate {
  width: 150px;
  white-space: nowrap;
}

3. Using the overflow CSS property

Next, you need to set the overflow property to hidden. This hides the text when it goes beyond it's width.

.single-truncate {
  width: 150px;
  white-space: nowrap;
  overflow: hidden;
}

4. CSS truncate with ellipsis

We have successfully truncated the text. But it would be nice to have some sort of indication that we have truncated it. Let's add ellipses to the end of the shortened text. We can do this by setting the text-overflow property to ellipsis.

.single-truncate {
  width: 150px;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

All you need to remember is 4 CSS properties. Width, white-space, overflow, text-overflow or remember the acronym, WWOT. You can use "We Won't Overflow Text” as a mnemonic. You can probably come up with something better.

How do you truncate multiple lines with CSS?

Truncating text for multiple lines is a bit more tricky. Let's start with a simple “p” tag again, but with some more text this time and make it wider.

 <p class="multiple-truncate">
    Nintendo E3 2021: Direct Dates and Time, Predictions, Rumours and Zelda Plans 
 </p>

.multiple-truncate {
  width: 250px;
}

Right now, the text has 5 lines. Let's see if we can truncate it to just 4 lines.

How to use line clamp in CSS

This property only works if you set the display property to -webkit-box or -webkit-inline-box. Also, the -webkit-box-orient property needs to be set to vertical.

Note: This property was originally implemented in WebKit and has some issues. It got standardized for legacy support.

When applied to anchor elements, the truncating can happen in the middle of the text, not necessarily at the end.

Now, let's add the new rules to our multiple-truncate class and see what will happen.

  .multiple-truncate {
    width: 250px;

  /* truncates text   */
  -webkit-line-clamp: 4;
  display: -webkit-box;
  -webkit-box-orient: vertical;
}

It's not quite what we were looking for. The problem with this approach is that we won't be able to have a padding-bottom on the actual text. Otherwise, the space occupied by the bottom padding will show the truncated text. So, let's remove the bottom padding for now.

.multiple-truncate {
  width: 250px;
  
  /* truncates text   */
  -webkit-line-clamp: 4;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  padding-bottom: 0;
}

Then we need to hide the truncated text by setting the overflow to hidden.

.multiple-truncate {
  width: 250px; 

 /* truncates text   */
  -webkit-line-clamp: 4;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  padding-bottom: 0;
  overflow: hidden;
}

The downside to this approach is that you can't have a padding-bottom on the text. You would need to add your padding to the parent or try something else.

One thing you can try is to set a border on an "after" pseudo-element. The border-color should be the same as the background for the text. Then, you need to set the border-width to the padding-bottom value you want. You can use an SCSS mixin or CSS variables for this to make it more robust and reusable.

.multiple-truncate:after {
  content: '';
  display: block;
  border-bottom: 1em solid tomato;
}

Truncate text with flexbox

Truncating text like this doesn't work well if the element you're truncating has a display value of flex or inline-flex.

The text will still be shortened but you won't get the ellipsis at the end. I'm not sure why it happens or if there are any workarounds for this. If you have any ideas, then let me know in the comments below.

Truncate text with SCSS

Here are two SCSS mixins that will make truncating text easier.

@mixin truncate-single-line($width) {
  width: $width;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

@mixin truncate-multiple-lines($width, $lines, $paddingBottom: false, $bg) {
  width: $width;
  -webkit-line-clamp: $lines;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  overflow: hidden;
  padding-bottom: 0;
  
  @if $paddingBottom {
    &:after {
    content: '';
    display: block;
      border-bottom-width: $paddingBottom;
      border-bottom-style: solid;
      border-bottom-color: $bg;
    }
  }
}

You can even use CSS variables for the $paddingBottom argument and then use media queries to make it responsive without changing the mixin.

.multiple-truncate--with-mixin {
  --pd: 1em;
 padding: var(--pd);
  @include truncate-multiple-lines($width: 250px, $lines: 4, $bg: tomato, $paddingBottom: var(--pd));
  
 @media (max-width: 600px) {
    --pd: 0.2em;
  }
}

Summary on CSS truncate text

Here's a quick summary of how to do text truncation with CSS:

Truncated or shortened text is commonly used in designs with equal-height columns where the text is dynamic.
To truncate text in CSS, you can use the following steps:
1. Set a fixed width on the element you are targeting.
2. Use the white-space property and set it to 'nowrap' to avoid wrapping the text to the next line.
3. Use the overflow property and set it to 'hidden' to hide the text when it goes beyond its width.
4. Use the text-overflow property and set it to 'ellipsis' to add an indication that the text has been truncated.
Truncating text for multiple lines is more tricky, but can be done by setting a fixed height on the element, using the display property and setting it to '-webkit-box' and '-webkit-line-clamp' and setting the number of lines to be displayed.

How has your experience been with truncating text in CSS? What techniques have you tried? Do you know any other ways to do this? Let me know in the comments below. I hope this was a helpful article.

Tips for beginners learning to code

Nirjan Khadka — Thu, 13 Feb 2020 00:00:00 GMT

It's been a while since I started coding, So for this post, I decided to do something different. I want to list down some tips I've learned over the last two years on getting better at learning to code. So this will be like a message to my younger self which might also hopefully be useful to some other beginners just starting out.

1. Build more cool stuff

I think this is the number one thing that can make it easier for you to learn something whether it's a programming language, framework or any other coding concept. Don't just go from one tutorial to another. Take what you've learned and make something cool with it, Most of the time you will learn way more from building stuff than any tutorial will ever teach you.

It can be normal to develop a mindset where you think what you've learned so far is not enough and you can't possibly make anything useful from it. You will always want to know more and that's not a bad thing. But, I'm gonna let you in a little secret,

No programmer on earth knows enough to always get the job done without any help, whether that help is a coworker, mentor or StackOverflow, Nobody knows enough, There's always more to learn whether you've been coding for a month or 10 years.

2. Build apps that actually help you

If you agree with my first piece of advice and decide to build things then don't just build random things or some demo app that you saw being built in a tutorial instead identify a problem that you are facing in your day to day life, no matter how small that may seem and try to build a solution for that.

For example, you might find it hard to focus or manage your time then build a simple time tracker, if you are having a hard time managing your money then build a budget tracker, etc. (note: Don't just build trackers, these are just examples) Doing this will make sure you are truly invested in the project and won't give up as soon as the project becomes a little difficult.

3. Don't build complex apps too fast

Sometimes it can be overwhelming to build apps that do too much. Instead, break your idea down into small pieces and focus on the most important part of your app and once that is complete then move onto other parts. You don't have to build a complex app just a simple app that solves one problem really well. I have gone down a rabbit hole where I kept adding features and eventually just gave up on the project because it was to complex for me to handle. Take it one step at a time and don't try to build something too complex.

4. Be a part of the community

Listen to coding podcasts, subscribe to coding channels, follow other developers online, be a part of the community. Don't just be a passive observer, share your thoughts, ask questions but don't be a dick.

5. Take a break

I think this is something that beginners tend to ignore. When you're learning something or working on a new project you might lose track of time or might spend hours trying to fix something. Remember to take a break from coding, do other stuff, focus on other interests to recharge your batteries. If you are interested in a sport or any other team activity then that can be great for your work-life balance since most developers spend a lot of time sitting and staring at a screen. Don't neglect your wellbeing because it's really easy to get burned out when you don't know your limits.

Other useful tips

There are tons of tips that I have for beginners but I consider the tips mentioned here to be the most helpful. You should be fine if you follow these tips but if you don't then you're never going to make it (just kidding, these are just suggestions, not rules). Take what you want from this post, it might be helpful for you or it might not but If I could go back in time then I would certainly give these tips to my past self. Here are some other tips that might be useful

Share your journey online with others and document it
Try a little bit of everything(different frameworks, coding - styles, etc), you'd be surprised at what you find yourself enjoying the most
Before trying everything make sure you master the fundamentals (please don't learn a JS framework before learning JS)
Find different ways to tackle problems
Always think critically before committing to something
Always pick readability over clever code
Don't use the DRY principle for everything
Don't use abstractions too early
Take a look at the project from a larger scope
Make sure most of the code you write is easily replaceable

How to easily understand "this" in Javascript - with a simple visual chart

Nirjan Khadka — Wed, 15 Jan 2020 00:00:00 GMT

This post will help you figure out how you can easily find out the value of “this” in JavaScript. If you're in a hurry, there's a JavaScript this keyword cheat sheet at the end.

The keyword “this” in JavaScript has confused a lot of developers, but with just 4 simple rules, you will never be confused again.

First, you need to know one important thing when working with the “this” keyword -

this is not author-time binding but runtime binding so it's not about where a function is declared but how it's called

When I talk about “this bindings”, I simply mean, how the “this” keyword is given a value. In JavaScript, there are 4 different types of “this” bindings, and they have their own order of precedence. So here are the 4 different “this” bindings in ascending order of precedence.

How the “this” keyword works in JavaScript — Default Binding

Most of the function calls in your code will have the default binding. The value of this is bound to the global object (the window object when working with JavaScript in the browser). This happens when you call a function with just the function name and it's arguments within brackets.

Note: If the function is in strict mode, then by default “this” refers to undefined. When working in a JavaScript module, strict mode is enabled automatically.

function foo() {
  this.a = 4;
  /**
   *   creates a global variable a
   *    this is the same as doing these things
   *    var a = 4;
   *    or window.a = 4;
   **/
}

foo();
console.log(a); // 4

function bar() {
  "use strict";
  /**
   * since this is undefined in strict mode
   * the a variable cannot be set and it
   * results in an error
   */

  this.a = 6;
  console.log(a);
}
bar(); // TypeError: Cannot set property 'a' of undefined

What is the “this” keyword in a JavaScript class – Class Binding

This type of binding happens when you call a function as a method of an object. The value of this is the object itself.

obj = {
  a: 4,
  foo: function() {
    console.log(this.a);
  }
};
obj.foo(); // 4

It does not matter where you declare the function, as long as you call it as a method of the object.

function foo() {
  console.log(this.a);
}

obj = {
  a: 7,
  foo: foo
};

obj.foo(); // 7

Only the top/last level of an object property reference chain matters.

function foo() {
  console.log(this.a);
}
const obj1 = {
  a: 4,
  foo: foo
};
const obj2 = {
  a: 7,
  obj1: obj1
};
obj2.obj1.foo(); // 4

/*
Here, obj2 is accessing it's obj1 property 
and then since, the obj1 property is an object itself, 
it calls it's own foo method,
which accesses the a variable set in the obj1 object so it logs the value 4.
*/

The most important thing to remember is that, it's not about the function itself. It's about how it is called. For example, here we call the foo function but since it is not called as a method of an object, we fall back to the default binding of “this”.

function foo() {
  console.log(this.a);
}

const obj = {
  a: 7,
  foo: foo
};

/**
 *  only a reference to the actual function is assigned
 * it does not care about the implicit binding
 */
const bar = obj.foo;

var a = 11;

/**
 * here this refers to the window object because of
 * default binding
 **/
bar(); // 11

How to bind this in JavaScript – Explicit Binding with call and apply

Most of the built-in functions and all user-defined functions have two special utility methods; apply and call. You can use these methods to explicitly bind the value of this. The value of “this” is easy to figure out because it is explicitly passed in as the first argument to the call or apply methods.

function foo() {
  console.log(this.a);
}

const obj = {
  a: 4
};

/**
 * calls the foo function
 * where this is bound to the obj object
 */
foo.call(obj); // 4

Note: apply and call both works the same for explicitly binding “this” to a given value, but the way they pass in other arguments is a little different. You may have also used the .bind() es6 method before which uses explicit binding under the hood, you can read more about it here.

How this works in JavaScript with the new keyword – new binding

To understand this type of binding, you need to understand how constructors work in JavaScript. In JavaScript, constructors are just functions that are called with the “new” operator in front of them. They are not attached to classes, nor are they instantiating a class. They are just regular functions hijacked by the use of the “new” keyword.

Any user-defined or built-in function can be called with a “new” in front of it, and that makes it a construction call. There is no such thing as constructor functions, but rather construction calls of functions.

These things happen when you make a construction call:

A brand-new object is created.
The new object is prototype linked.
The object is set as the “this” binding for the function call
Unless the function returns its own alternate object, the new invoked function call will return the newly constructed object.

function foo() {
  this.a = 4;
}
const bar = new foo(); // bar is set to the newly created object;
console.log(bar.a); // 4

How this works in an arrow function – Arrow function binding

I know I promised there were only 4 different types of “this” binding and in the past, that was true, until es6 which introduced arrow functions.

/**
 *  arrow functions use the fat arrow =>
 * instead of the function keyword.
 */

a => {
  console.log(a);
};

Arrow functions are not just a quicker way to write functions, but they also do “this” binding a little different. They use lexical scope for “this”. To learn more about lexical scope, check out my guide to lexical scope and closure.

They inherit the value of “this” from their outer function. By “outer function”, I mean the function where you declare the arrow function, not where you call them.

function foo() {
  var = 3;
  return () => {
    /**
     * here this actually refers to the
     * this of the foo function
     */

    console.log(this.a); // 3
  };
}

Here's a more complicated example, that uses the other ways to bind “this” alongside the arrow function binding.

function foo() {
  return () => {
    /**
     * here this actually refers to the
     * this of the foo function
     */

    console.log(this.a);
  };
}
const obj1 = {
  a: 4
};
const obj2 = {
  a: 7
};

/**
 * sets "this" binding to obj1 and
 * gets the arrow function as the return value
 * Now bar is a reference to the arrow function returned by the foo function
* */
const bar = foo.call(obj1);


/**
 * tries to set the this binding
 * of the arrow function to obj2 but
 * the arrow function's this is set
 * to the this of foo which was bound to obj1
 **/
bar.call(obj2); // 4

Therefore, the “this” binding of arrow function is actually done in author-time rather than runtime like the other types of “this” binding.

"this" in JavaScript Summary and Cheat sheet

Here are the things we now know about how "this" works in JavaScript:

The "this" keyword in JavaScript is not author-time binding but runtime binding, meaning it's not about where a function is declared but how it's called
There are 4 different types of “this” bindings in JavaScript, each with its own order of precedence:
1. Default Binding: the value of this is bound to the global object (the window object when working with JavaScript in the browser). If the function is in strict mode, then "this" refers to undefined.
2. Class Binding: the value of this is the object itself when calling a function as a method of an object.
3. Explicit Binding with call and apply: allows you to explicitly bind the value of this by passing the desired value as the first argument to the call or apply method.
4. Implicit Binding: the value of this is the object that the function is a property of.
The most important thing to remember is that it's not about the function itself, it's about how it's called.
Arrow functions in JavaScript do not have their own "this" binding, they inherit the “this” value of the surrounding scope. This means that the value of "this" inside an arrow function will be the same as the value of "this" in the code that surrounds the arrow function.

You can use this cheat sheet to help you find the value of “this” in JavaScript. So, next time when it's hard to debug the value of” this” just remain calm and ask yourself these questions.

Javascript Closures Complete Guide - with practical use cases and examples

Nirjan Khadka — Thu, 21 Nov 2019 00:00:00 GMT

What is scope in JavaScript?

We first need to know what we mean by scope to understand a JavaScript Closure. Scope is a set of rules that tell you where your variables and functions can be accessed from.

Depending on where you have set your variables and defined your functions, you can only access them in specific sections of your code. Here is an example of that in JavaScript.

const firstVariable = 1;


function firstFunction() {
    return 2;
}

function functionWithAnotherFunctionInside() {    
    const secondVariable = 2;
    
    function secondFunction() {
        return 3;
    }
}


// will log 1 2
console.log(firstVariable, firstFunction()) 

// Uncaught ReferenceError: secondVariable is not defined
console.log(secondVariable, secondFunction())
    ``` 

So what's the deal here? Why can can we access the _**firstVariable**_ and the **_firstFunction_** but not the **_secondVariable_** and the **_secondFunction_** ? This is because of how JavaScript Scope works.

How does Scope work in JavaScript
---------------------------------

JavaScript only had **function scope** (with a few exceptions) until the [ES6](https://www.programiz.com/javascript/ES6) version came out. This meant that, whenever you defined a new function, you created a new scope. A variable defined inside a function cannot be accessed from outside the function.

This is why we get an error when trying to log the secondVariable value and call the secondFunction.
```js
const firstVariable = 1;
]
function firstFunction() {
    return 2;
}

function functionWithAnotherFunctionInside() {    
    const secondVariable = 2;
    
    function secondFunction() {
        return 3;
    }
}


// will log 1 2
console.log(firstVariable, firstFunction()) 

// Uncaught ReferenceError: secondVariable is not defined
console.log(secondVariable, secondFunction())

Scope won't let you access the variables that are set inside a function from the outside.

JavaScript Scopes are nested

The inner scope has access to the outer scope, but the outer scope can't access the variables set in the inner scope.

function outerFunction() {
  let i = 777;
  console.log(i); // 777
  console.log(b); // Refference Error (outer scope can't access variables in inner scope)

  function innerFunction() {
    console.log(i); // 777 (inner scope can access the enclosing outer scope)
    let b = "hello";
  }

  innerFunction();
}
outerFunction();

Scope consists of a series of bubbles that each act as a container or bucket in which identifiers are declared , these bubbles nest inside each other and this nesting is defined at author time.
Kyle Simpson (Author of the You Don't know JS series)

//global scope
var i = 666;
console.log(i); // 666

function foo() {
  // scope of foo
  var i = 777;
  console.log(i); // 777
}

foo();

How does JavaScript Scope work in ES6

ES6 introduced two new ways to declare variables; using let and const. They can be used for block scoping. Whenever you use let or const to declare variables, they are scoped to the block (any code surrounded by a pair of curly brackets). ES6 also introduced another scope with modules, but closures work in the same way in modules too, so we don't have to dive deep into that. If you are curious, here's the MDN link to JavaScript modules.

//global scope
var i = 666;
console.log(i); // 666

{
  // new block scope
  // you'l see these types of blocks used with if,else,for,while,etc
  let i = 777;
  console.log(i); // 777
}

note: You might have heard the term lexical scope in JavaScript which is just a technical term for scope that is defined during the code compilation process called lexing. It basically means that scope is defined when you are writing the code (declaring functions, or blocks), instead of when it is actually executed by the computer.

What is a Closure?

A closure is a programming technique for allowing functions to access values that are defined outside of it. It is the combination of a function bundled together with variables that are outside of it.

You have a closure when a function accesses variables defined outside of it.

What are JavaScript Closures?

In JavaScript, because scope is nested, it is actually pretty easy to create a closure.

let usernames = ['John', 'Jack', 'James', 'Jhonny'];
let searchTerm = 'Ja';

// Here the function is accessing the searchTerm variable which is outside the function
// this is a closure
let filteredUsernames = usersnames.filter(function (username) { 
    return username.startsWith(searchTerm)
  });

Since, functions can be nested, you can also use closures with nested functions like this:

function outerFunction() {
  let a = 666;
  function innerFunction() {
    console.log(a);
  }
  return innerFunction;
}
let myFunc = foo(); // now myFunc is just a reference to innerFunction inside the outerFunction.

myFunc(); // 666;

When the outer function runs, the 'a' variable is set to 666. So, You might expect the 'a' variable to not be available afterwards when the function has finished running.

Since scope can be nested, the inner function still has access to the 'a' variable. So, as long as some part of the code can still call the inner function, it can still remember the 'a' variable.

Closures can cause functions to remember variables within their scope.

With a Closure, you are combining a function with the data that it can access outside of it.

Examples of JavaScript Closures

Closures are useful to combine a function with some internal value that it should use. This might be familiar if you have some experience with object-oriented programming and encapsulation.

function getClickCountUpdater() {
  let counter = 0;
  return function() {
    counter = counter + 1;
    console.log(counter);
  };
}

const updateClickCounter = getClickCountUpdater();

// now to change the counter, you need to use this function, you can't change it directly
updateClickCounter(); // 1;
updateClickCounter(); // 2;

counter = counter+1; // ReferenceError: counter is not defined
console.log(counter); // ReferenceError: counter is not defined

// You can create another count updater function which will have a seprate counter variable in it's scope
const anotherCounter = getClickCounUpdater();
anotherCounter(); // 1;

They can also be useful for creating different variations of a function, and to keep track of some value inside a function that shouldn't be changed from anywhere else. This is pretty useful when you want to do some logging for a specific function like this:

function createAd(width, height) {
  let adCounter = 0;
  return function (link) {
    adCounter++;
    console.log(`${width}x${height} ad created ${adCounter} times!`);
    return {
      _type: 'ad',
      link: link,
      width: width,
      height: height,
      // other generic ad options
    }
  }
}

const create300x250Ad = createAd(300, 250);
const create728x90Ad = createAd(720, 90);

// 300x250 ad created 1 times!
const new300x250Ad = create300x250Ad('https://linkToTheAd.com/path');

// 300x250 ad created 2 times!
const another300x250Ad = create300x250Ad('https://linkToTheAd.com/path');

What is the benefit of closure in JavaScript?

JavaScript Closures can also be used to do some performance optimization. Let's say you have a function that needs to set a variable, but that variable takes up a lot of memory. Instead of creating that variable each time you run the function, you could use a closure to reuse it.

function findAdLinkById(id) {
  const adMap = {
    'e645-2456': 'https://link.com/path',
    '2282-3238': 'https://another-link.com/another-path',
    // 1000 more items
    
    '2901-2192': 'https://one-more-link.com/path'
  }
  return adMap[id]
} 

// whenever this function gets called it needs to store a new adMap value in memory which makes calling this function slower the more we call it
const firstAd = findAdLinkById('e645-2456')
const secondAd = findAdLinkById('2282-3238')
const thirdAd = findAdLinkById('2901-2192
function createFindAdLinkById() {
  const adMap = {
    'e645-2456': 'https://link.com/path',
    '2282-3238': 'https://another-link.com/another-path',
    // 1000 more items
    
    '2901-2192': 'https://one-more-link.com/path'
  }
  return (id) => adMap[id]
} 
const findAdLinkById = createFindAdLinkById()

// whenever this function gets called it reuses the same adMap value which makes it faster to run
const firstAd = findAdLinkById('e645-2456')
const secondAd = findAdLinkById('2282-3238')
const thirdAd = findAdLinkById('2901-2192')

Note: while this will be more performant, it will also use more memory. So, if you also need to optimize the memory consumption then you should try something else.

One of the most common use cases of JavaScript Closures is with asynchronous JavaScript.

let id = 1;

getUserFromAPI(id).then(response => {
  // this works because the function callback here can still remember the value of the id even though this code won't run immediately
  console.log(`Fetched user ID: ${id}`)
})

Most of the time, you might not even realize when you're using a closure. Basically, anytime you're using a variable that is outside a function from inside the function, you are using a closure.

So, These are some practical use cases for JavaScript Closures:

Limiting the access to certain variables
Limiting the access to call certain functions
Keeping track of values across function calls
Logging function calls
Optimizing the memory usage of function calls
Creating different variations of the same function
Remembering values with asynchronous functions that get executed later

Closures can cause performance issues

While closures can be pretty useful when you use them intentionally. Sometimes they can also lead to memory issues, because closures are stored in memory. If we create unnecessary closures frequently, then it can cause a memory leak.

We need to make sure we're actually using the variables that are being stored in the memory. We should not create unnecessary closures too much. Let's take a look at our example from earlier to see how closures can cause too much memory usage.

function createFindAdLinkById() {
  const adMap = {
    'e645-2456': 'https://link.com/path',
    '2282-3238': 'https://another-link.com/another-path',
    // 1000 more items
    
    '2901-2192': 'https://one-more-link.com/path'
  }
  return (id) => adMap[id]
} 


// now instead of having just one closure, we have 2000 closures
for (let i = 0; i <= 2000; i++) {
  const findAdLinkById = createFindAdLinkById()
  const firstAd = findAdLinkById('e645-2456')
  const secondAd = findAdLinkById('2282-3238')
  const thirdAd = findAdLinkById('2901-2192')
}

So, Whenever you are creating closures, you need to be aware of how much memory you are actually using.

Summary of JavaScript Closures

I hope you now have a better understanding of JavaScript Closures. Here's what was covered in this post:

Scope is a set of rules that determine where variables and functions can be accessed in code.
Until ES6, only function scope was available in JavaScript, meaning variables defined within a function could not be accessed from outside.
ES6 introduced block scoping with the “let” and “const” keywords.
JavaScript's scope is nested, with inner scopes having access to outer scopes but not vice versa.
“Lexical scope” refers to scope that is defined during the code compilation process, rather than when the code is executed.
Closures are functions that have access to variables in their parent scope even after the parent function has returned.
Closure allows a function to remember the environment in which it was created, even after it leaves that environment.
Closures can be used to create private variables and methods, by returning inner function from outer function.
Closures can also be used to make performance optimizations.
You should use closures carefully if you want to make your apps more memory efficient.