I wanted to believe this article, but the writing is difficult to follow, and the thread even harder. My main issue is the contradiction about frameworks and using what the large tech companies have built vs real engineering.

The author seems to think that coding agents and frameworks are mutually exclusive. The draw of Vercel/next.js/iOS/React/Firebase is allowing engineers to ship. You create a repo, point to it, and boom! instant CICD, instant delivery to customers in seconds. This is what you're complaining about!? You're moaning that it took 1 click to get this for free!? Do you have any idea how long it would take to setup just the CI part on Jenkins just a few years ago? Where are you going to host that thing? On your Mac mini?

There's a distinction between frameworks and libraries. Frameworks exist to make the entire development lifecycle easier. Libraries are for getting certain things that are better than you (encryption, networking, storage, sound, etc.) A framework like Next.js or React or iOS/macOS exist because they did the heavy work of building things that need to already exist when building an application. Not making use of it because you want to perform "real engineering" is not engineering at all, that's just called tinkering and shipping nothing.

Mixing coding agents with whatever framework or platform to get you the fastest shipping speed should be your #1 priority. Get that application out. Get that first paid customer. And if you achieve a million customers and your stuff is having scaling difficulties, then you already have teams of engineers to work on bringing some of this stuff in house like moving away from Firebase/Vercel etc. Until then, do what lets you ship ASAP.

You don't need a form fitting faraday cage. Want a free one? Find a food delivery bag that is insulated with foil. I believe some of the meal prep delivery services package their groceries in this. Stick your phone in there and wrap it up. All signals gone as far as I can tell.

Or, even more free or cheap: Wrap it in aluminum foil.

This is a good write up on the workings. However, in actual use, Turbopack has severe limitations when compared to Webpack. I’ve been working on https://jsonquery.app and rely on the jq WASM dependency for the queries. But, Turbopack cannot handle importing a WASM binary or the glue code for it directly. The workaround is to have a script copy the binary to the public directory. But that's not all. jq-wasm has a dependency on the ‘fs’ module, even though no fs functions are used. But trying to resolve this in Turbopack is not possible and 2 days of fighting this was a waste of time.

Webpack solved this problem with a few lines in the next.config.ts

For now, I’m back to using Webpack with NextJS 16 with the —Webpack flag. Hope they allow this for future versions.

There are plenty of complaints on the NextJS subreddit, and here is a open thread on complaints with Turbopack https://github.com/vercel/next.js/discussions/77721

Looks the alternative is Rspack?

Interesting read. I had the KR7A-133R motherboard as it won Anandtech's gold award for the best 4 bank DIMM support. It was $200 IIRC and was one the more expensive boards. Paired it with an Athlon XP 1800+ and Radeon 8500. Funny enough the AMD naming at the time was to reflect how Athlon's lower clock speed (1.5GHz) was a competitor to Intel CPU's (1.8GHz).

Asus was a strong competitor even then and I remember buying one just a few years before the Abit board that supported SD-RAM as well as DDR as a way to ease the transition for consumers.

It was a good time when IRC, AIM, and physical electronics shopping was still a thing. The only big tech presence that techies hated was Microsoft. Sigh.

EDIT: Their website is still around! https://www.abit.com.tw/page/en/motherboard/motherboard_deta...