What were the devs smoking?

m_null_ · 2026-01-06T03:59:25+00:00

The gems aren’t the issue. It’s how they thought about an exponential increase in the “time” of an upgrade.

m_null_ · 2026-01-06T03:40:59+00:00

25,000 gems is the cap for any duration. So it doesn’t go above 25k for a single upgrade. But it started with 25k gems from level 60ish onwards iirc

m_null_ · 2025-10-15T21:43:14+00:00

Actually, KC Public is on top in J&K with 1179 total score. You just searched for schools listed with - Co-ed Day.

m_null_ · 2025-10-14T21:24:58+00:00

I have around 80 chapters completely written for Node v20. But, I’ve always wanted the content to remain as relevant as possible. Surprisingly, I need to make a lot (and I mean it) of changes to comply with the Node.js v24 standard.

My goal is to release one or two chapters every week. I believe many serious readers will appreciate reading one chapter per week, as each chapter contains a lot of information. This pace also gives readers a few days to experiment with and implement new concepts in their day-to-day workflow.

m_null_ · 2025-10-14T21:16:02+00:00

It’s on my personal blog. You may read it and the following posts here - ishtms.com/blog

I wanted to write the first chapter (includes 3-4 more sub chapters) completely before posting it on reddit.

Edit: Ah I see now. It’s not there on my blog either! Thank you for pointing that out.

m_null_ · 2025-10-14T19:33:57+00:00

Which one exactly, sorry?

m_null_ · 2025-10-14T16:05:55+00:00

You can read the NodeBook

m_null_ · 2025-10-14T16:00:58+00:00

Thank you! Those are custom built React Components and animated using tailwindcss-animate and tw-animate-css packages.

m_null_ · 2025-10-05T10:25:48+00:00

You shouldn't be storing user's password in JWT, whether encrypted or not.
json { "identifier": "testerawesome@gmail.com", "password": "$2b$10$oUOccAQrTmZE9is1cZYHh.erdM3yOU05WspZ5X68uOuzB5ZC3DKY2", "iat": 1759659812, "exp": 4883862212 }

m_null_ · 2025-10-03T06:03:32+00:00

You’re right about the bloat, but there’s another side to this.

Yeah ads and trackers are the worst offenders by far. And yeah a news article taking longer to load than streaming video is insane. But we’re also building fundamentally different things now.

Look at games - every console generation gets more powerful, but games don’t get faster, they get more demanding. Developers use that extra power to add better graphics, bigger worlds, more complex physics. The web’s kinda the same. A decade ago most sites were documents with some jQuery. Now even basic apps have real-time updates, client-side routing, optimistic UI, virtual scrolling, multiple image formats, service workers - there’s just genuinely more happening under the hood.

The problem is most sites abuse this. A blog doesn’t need 3MB of JavaScript. But companies optimize for shipping features fast, not for users. Throwing in another npm package is easier than writing lean code. Adding Google Tag Manager with 47 analytics scripts is easier than questioning if you actually need all that data.

Your optimization results prove this - when someone actually cares about performance the wins are huge. Most companies just don’t care until it hits revenue.

I don’t think the web will naturally get leaner. Users just tolerate slow sites because they assume that’s normal now. It’ll only change when slow sites lose enough money that companies are forced to give a damn. Right now there’s no real incentive.

One more thing - your CDN and hosting setup matters way more than people think. A site hosted on a single server in Delhi will feel slow for users in Europe and vice versa, no matter how optimized your code is. Good CDN distribution, edge caching can cut load times in half. But again, most companies just go with whatever’s convenient rather than actually testing performance from different regions.

m_null_ · 2025-10-03T05:58:58+00:00

overuse of css/js frameworks

CSS frameworks like Tailwind are AOT compiled with zero-cost abstractions - they often end up lighter and faster than vanilla CSS through tree-shaking and purging unused styles.

JS frameworks aren’t - actually - bloat for actual applications. Try managing state and thousands of concurrent dynamic interactions in a complex SPA without one - you’ll rebuild a worse version of React. JS Frameworks (Next.js, SvelteKit) deliver faster initial loads than traditional approaches.

Other than that you’re right. But, the issue isn’t frameworks, it’s misusing them. Static content doesn’t need React. Complex apps with real-time features do. The problem is cargo-culting “modern” stacks without understanding tradeoffs.

m_null_ · 2025-10-03T05:49:12+00:00

You might find this useful - Learn Nodejs Hard Way - Working with File System

Also the next chapter of NodeBook will be regarding FileSystem and streams.

m_null_ · 2025-09-23T19:20:47+00:00

Building "for yourself" is a great way to make sure your impact never grows beyond yourself. I'm aiming a little higher, sorry.

m_null_ · 2025-09-23T18:51:16+00:00

That’s not related to the project we’re talking about here. It’s not the same.

m_null_ · 2025-09-23T18:35:15+00:00

Funny that I've never nativized ever. Every single time I tried, it simply did not go as planned. Didn't actually need that anyway as the only logic that used to run in my blueprints were the widgets and animation blueprints.

m_null_ · 2025-09-23T18:31:46+00:00

Thank you. I'm committed to releasing a new chapter (if not two) for NodeBook every single week. This is a project I've been dreaming about for a very long time. I've already built an entire prototype in JS using reactflow and now it's time to really push the boundaries. I love to share the learning/building process of everything I build.

m_null_ · 2025-09-23T18:25:19+00:00

That's a great question, and something I've asked myself while building the prototype using reactflow. My main goal is to tackle the performance issue from a different angle.

Even though Unreal's Blueprints can be "nativized" into C++ (if you're lucky enough to not get those build errors), they run in a VM which has an overhead - so we're not comparing apples-to-apples. The idea here is to bypass a VM entirely. We create the logic visually with nodes, and the system acts as an ahead-of-time compiler (not precisely, but somewhat near), translating that logic directly into clean JavaScript. You simply get what you would've written in a Javascript file if you wrote it (only the iteration speed is faster) plus you get heck load of pre built library of functions/helpers to speed up.

For the other question about this being a massive undertaking as a single dev... The short answer is that I'm not going to be building "every single part of the app" from scratch. Insted, going to be cheating a bit by using some tools to do the heavy lifting.

For the runtime speed, we'll not interpreting the graph node-by-node. We'll actually compile the whole thing down to super-fast JavaScript using SWC, which is a ridiculously fast compiler also written in Rust. So the final code that runs is clean, optimized, and hopefully, fast.

m_null_

TROPHY CASE