The Div Soup

January 2022 → March 2026. 4 years. No connections. No privilege. Just a guy from Siwan, Bihar with a laptop and internet. I'm writing the most honest post of my life on @thedivsoup, everything about: - How I started (with literally zero audience) - The grinding days nobody saw - Mistakes that cost me months - Every way I make money today - What I'd do differently as a beginner - A proper blueprint for career + money Not the "follow your passion" nonsense. Real numbers. Real timeline. Real failures. 99% transparent. The remaining 1%? Some things you just can't put on the internet. But after reading it, you'll have a clearer picture of how career building and money-making actually works, especially if you're starting from a small town with no roadmap. Dropping soon. Stay tuned.

I built a privacy-first bank statement analyzer using only frontend + local LLM (@Kombaico + Ollama) Last weekend I tried vibe coding with Kombai and ended up building something surprisingly useful. I built a frontend-only tool that lets you: • Upload your bank statement PDF • Automatically extract transactions • Visualize spending in charts & graphs • Ask questions about your statement (like “How much did I spend on food in Jan?”) Here’s the interesting part: 👉 It’s completely local 👉 No backend 👉 No server 👉 No API calls All data stays in your browser (local storage). For AI queries, it uses a local LLM via Ollama. You just install Ollama once, and it auto-configures in the browser. So basically: Your financial data never leaves your machine. I built this mainly to explore: - Frontend + AI integration - Local LLM usage in browser apps - Privacy-first AI tooling I’m thinking of adding: - Monthly budget tracking - Auto expense categorization - CSV export - Multi-bank support Would love feedback from: - Indie hackers - Privacy-focused devs - People who hate giving bank data to SaaS tools Would you try something like this?

Imagine a user asks: Show me data from the last 24 hours. But the question is, 24 hours according to which clock/timezone? Now, if the server assumes a different timezone than the user, the result will be wrong, right? So here we need to send the user's timezone so that the backend knows, like: Okay, this user is requesting from India, etc. That way, time-based filters work correctly. Sometimes servers require the timezone in IANA format. But what is it all about? It's just a standard name for timezones. Instead of writing: - India - California We use official names like: - Asia/Calcutta - America/Los_Angeles And servers understand this format globally. It's like a universal language for timezones. But how do you get this IANA timezone? The best thing is that the browser already knows the user's timezone. We just have to read it in the following way, as shown in the image below.

Complete JavaScript Roadmap 😎 |-- JavaScript_Basics | |-- Variables (var, let, const) | |-- Data_Types | |-- Operators | |-- Type_Coercion | |-- Console.log_Engineering | └─ Hoisting (Surprise_Test) | |-- Control_Flow | |-- if_else | |-- switch | |-- Loops | | |-- for | | |-- while | | └─ forEach_but_cant_break | | | └─ Ternary_Operator | |-- Functions | |-- Function_Declaration | |-- Function_Expression | |-- Arrow_Functions | |-- IIFE | └─ Callback_Hell | |-- Arrays_and_Objects | |-- Array_Methods | | |-- map | | |-- filter | | |-- reduce (Black_Magic) | | |-- some_every | | └─ sort_without_logic | | | |-- Object_Methods | |-- Destructuring | |-- Spread_and_Rest | └─ JSON.parse_without_try_catch | |-- Advanced_Concepts | |-- Scope | |-- Closures | |-- this_keyword | |-- Prototypes | |-- Event_Loop | |-- Call_Stack | └─ Memory_Leaks_you_dont_notice | |-- Asynchronous_JavaScript | |-- setTimeout_confusion | |-- Promises | |-- async_await | |-- Promise.all | └─ Why_is_this_not_waiting | |-- DOM_Manipulation | |-- querySelector_vs_getElementById | |-- Event_Listeners | |-- Event_Delegation | |-- Forms_and_Validation | └─ InnerHTML_Destruction | |-- ES6_and_Beyond | |-- Modules | |-- Template_Literals | |-- Optional_Chaining | |-- Nullish_Coalescing | └─ Top_Level_Await | |-- Error_Handling | |-- try_catch | |-- Custom_Errors | └─ Debugging_2AM | |-- Browser_APIs | |-- LocalStorage | |-- Fetch_API | |-- IntersectionObserver | └─ Geolocation_permission_denied | |-- Tooling | |-- NPM | |-- Package.json_Depression | |-- Webpack_or_Vite | |-- Babel | └─ Why_node_modules_is_2GB | |-- Frameworks_and_Libraries | |-- React | |-- Next.js | |-- Vue | |-- Angular | └─ Switching_Framework_Every_6_Months | |-- Testing | |-- Unit_Testing | |-- Jest | |-- Testing_Library | └─ It_works_on_my_machine | |-- Performance_Optimization | |-- Debounce | |-- Throttle | |-- Code_Splitting | └─ Lighthouse_Score_Flex | |-- Bonus_Level | |-- TypeScript | |-- Design_Patterns | |-- Clean_Code | └─ Reading_Documentation_Finally | Repost and Follow for support 🚀 Drop a like too All the best JS warrior 😎🔥

React CheatSheet. 1. Normal variable - no re-render ❌, no persistence ❌ 2. State variable - re-render ✅, persistence ✅ 3. Ref variable - no re-render ❌, persistence ✅ read more: 👇🏻

I'm a frontend engineer with more than 2 years of experience. I must say, if you don't use tools like theORQL, you're already far behind the game. Don't waste time on repetitive work. I recently came across this tool called theORQL. And tried it to fix a broken element, it usually takes me about 20 minutes, but it fixed it in just 2 minutes. I would say, be friendly with AI tools to level up your productivity.

This 5-Step React Pattern Saves You From State Hell. Step 0: Why this pattern exists in the React ecosystem? In React, data flows from top to bottom.
Multiple components often need the same data. Passing props everywhere becomes messy. So instead of passing data manually, we create a shared data layer. That’s exactly what Context and Provider give you. Step 1: Create a Context => boundary of availability In simple words, Context defines what kind of data can be shared and which components are allowed to access it. The key thing is:
Context itself holds nothing.
It’s just a pipe. Data flows through it later via a Provider. Step 2: Create a Provider => single source of truth The Provider is the owner of data and logic. Inside the provider, you can: - store state - write business logic - talk to APIs - control side effects, etc. Then the provider decides: - what data exists - how it changes - who can read or update it This is why we can say,
Provider is the decision maker. Step 3: Wrap the component tree with Provider. Wrapping decides who gets access. Only components inside the provider can use the data. Anything outside, knows nothing, stays clean and independent. This keeps the scope tight and avoids global mess. Step 4: Create a Custom hook => clean entry point A custom hook is a safe door to the context. With it, we: - centralize access - hide implementation details So UI components only consume the data. They don’t care: - where it comes from - how the API works - how state is managed Step 5: Consume data where UI needs it In this step, components: - read data - trigger actions and nothing more. This keeps components: - predictable - reusable - easy to test One provider owns the logic.
UI just consumes.
State flows one way. What this pattern gives you? - Single source of truth - Clean separation of concerns - No prop drilling - Easy scaling - Predictable UI - Testable logic In short, Context defines the data, Provider manages it, hooks expose it, and components use it. That’s it. Thank you!

Correct mental model for defining state in React! Parent component = decision maker. Child component = action trigger. If multiple components depend on the same state, that state must live in their parent component. Suppose you have 5 child components inside a parent component, and a few of them need the same state variable. Before defining a state in React, ask this one question first. Who decides what is visible on the screen? If the answer is the parent layout, and one state action affects multiple components, then: - The state should be defined in the parent component. - The parent should pass the state and setter function to child components. - Child components only perform actions using those setters. This is what we call lifting the state up. The Core principle, If a component doesn’t own the layout, it shouldn’t own the state. What lifting state up solves? - State moves up. - Logic stays central. - UI becomes predictable. When should you lift state up? You should lift state when: - One component’s action affects another component - Rendering of components is conditional - Sibling components depend on the same value - You are trying to sync two states manually - Closing or modifying one component should reset others If the answer is "yes" to any of these, you must lift the state up. BTW, State lifting isn’t a React trick. It’s a React way of thinking. Parents decide what exists. Children decide what happened. That's it, thank you!

I’ve been working in the frontend industry for the last 4 years. If you’re a beginner or a vibe coder, here’s how you should build a strong foundation. If I had to start learning JavaScript from scratch today, this is how I would proceed: 1. Understand what JavaScript is and why you need to learn it. Don’t jump into code without clarity on its purpose. 2. Learn data types and understand why type safety matters. This will help you avoid bugs and write more predictable code. 3. Learn different types of functions in detail, including callback functions, and understand when and why to use them. 4. Understand objects and arrays deeply. These are the backbone of JavaScript and real-world applications. 5. Practice commonly used and well-known string and array methods. These are used everywhere in production code. 6. Logical and conditional concepts are the most essential skills. Spend most of your time here, this is where real problem-solving happens. 7. Learn the basics of asynchronous JavaScript. This is more than enough to crack an entry-level job if your fundamentals are strong. 8. Practice error-handling techniques and understand their consequences. You must ensure that your web application never breaks unexpectedly. 9. Before building any feature, think and understand the problem first. Then practice by building the UI and logic on your own. 10. Last but not least, learn how to break a big feature into smaller sub-features. This is a real-world skill used in every professional team. If your foundation is strong, I’m confident you’ll crack an entry-level job easily. Let me know if you still have any questions.

1 year completed as a frontend developer. Here’s what I learned while working on big products. These are the standards you should follow, whether you’re working on your own project or contributing to a company codebase. > Logically split a big feature into multiple sub-issues on GitHub. If you’re unable to split it, take ideas from AI. > Create one main feature branch, and separate branches for each sub-issue so you can work independently. Merge sub-issues one by one into the feature branch. > Pick one logical sub-issue and work on it as an individual task. > Always follow the existing patterns of the project. > Think about components and file structure from a big-picture perspective. > Use well-known patterns like Provider, custom hook or Reducer patterns. You can take ideas from AI, but understand them first. > Before writing any logic, think about the sad (error) path along with the happy path. > Keep components and providers as small as possible. > Keep JSX clean. Avoid heavy logic inside JSX, use helper functions for reusable logic. > Keep all SVG icons in a central place and reuse them across the project. > Instead of rewriting the same logic, components, error handling, or null checks again and again, create reusable components, and use well known tools if required: - Use shadcn for UI components - React Hook Form for forms - Zod for validation - Redux (or similar) for state management - Tailwind CSS for styling Plan and integrate these properly from the beginning. > Comment your code. Use AI, but fully understand the code before copying it into your project. > Always look for ways to reduce complexity... for example, use React Context to reduce prop drilling. > Try to avoid useEffect as much as possible. Research when and why it’s actually needed. > If some parts of your app are unpredictable and can crash the whole application, add extra protection using React Error Boundaries. …and much more. I’ll share these learnings one by one. That’s how we build quality products. Let me know your thoughts.

JavaScript for Noobs Working on a series called "JavaScript for Noobs". I’ll share this content on X and LinkedIn starting the 1st week of December. It will cover essential JavaScript concepts based on internship and job interview questions. If you’re interested, let me know your thoughts or if there’s anything you’d like me to include in the series. Let’s go...

Frontend Developers Might Become History.🤨 Last Friday, I was working on some frontend development strategies when a specific requirement came up from the PM. Out of curiosity, I thought ... why not test the real capabilities of AI now? So, I jumped straight to Claude, provided the full context with proper prompts… and it failed. It couldn’t fix the problem. Then I moved on... tried ChatGPT, then Gemini. Guess what? None of them could solve it either. That’s when I switched gears. I opened Excalidraw to plan things out visually and discussed a few approaches with my PM. He shared some great insights, and I added my own ideas on top. Together, we came up with a solid plan and I successfully built that feature myself. Whenever I got stuck, I used AI tools for help, but the actual execution and decision-making came from me and my PM. What did you notice here? In my opinion, AI won’t replace frontend developers, it’ll replace the boring parts! AI tools aren’t a curse for frontend developers. In fact, they’ve become one of our biggest strengths. They can handle repetitive tasks, boilerplate code, design-to-code conversions, and even syntax migrations. But creativity, problem-solving, and strategy? That still needs us. Read the full story: 👇🏻

Back in 2021, I had $0 income. No clients. No job. No idea where to start. I began my journey by sharing my learnings on Twitter (now X). Fast forward to today — I’ve built 4 solid sources of income: - Earnings from X - Freelance work with 3 amazing clients - A full-time Software Engineer role - YouTube It took consistency, skill-building, and patience — but it all started with one simple step: sharing what I know. I wrote about this entire journey on Medium: How I Built from Zero to Four Sources of Income Read the full story from the comment below.

JavaScript Interview Series starts soon, brought to you by @thedivsoup. Any specific requirements or suggestions? Please share below. 👇🏻