codinhood (u/codinhood)

codinhood commented on Ask HN: Expository/Succinct Books on Modern Physics · Posted by u/rramadass

senorcrab · 2 months ago

Freshman university textbooks have what you need. Two of the most popular are:

- University Physics by Young and Freedman

- Fundamentals of Physics by Halliday, Resnick, Walker

- Modern Physics by Krane

You might guess that real physics is not actually in freshman textbooks, and you are right. Modern physics requires rigorous mathematics.

For a nonrigorous introduction/overview:

- The Road to Reality by Roger Penrose

If you want to actually learn almost all of physics at a high level:

- Course of Theoretical Physics by Landau

Note that Landau is extremely difficult.

If you want to learn the math needed for modern physics (topology) in the context of physics, nonrigorously:

- Geometry, Topology, and Physics by Nakahara

codinhood · 2 months ago

> Fundamentals of Physics by Halliday, Resnick, Walker

I strongly recommend this textbook. I used in college, and it's really good. There are a lot of problems for each chapter, I suggest doing them as they help a lot.

codinhood commented on React and Remix choose different futures laconicwit.com/react-and-... · Posted by u/surprisetalk

davedx · 3 months ago

> Breaking backward compatibility isn't collateral damage, it's the point.

LOL, if you say so.

Honestly, I don't know how anyone decides to build something on top of the software the react router team puts out. I went through approximately 2 major version upgrades of react router then decided I was done with it unless I had no other choice.

Why do people think being left with huge upgrade tech debt time and time again is worthwhile? There are just so many other choices out there these days. Why you'd choose this "different future" now is beyond me.

codinhood · 3 months ago

It's kinda wild to take something people really like and just keep re-writing it while keeping the same name.

They were around when Angular 1 -> Angular 2 right? No one liked that. Angular 2 is good but calling it Angular 2 when it was so different put a bad taste in everyone's mouth.

Google did that because they wanted the Angular userbase, but that alienated a bunch devs and many decided to switch to React (me included) instead.

Seems the remix/react router team is trying to do the same. They built something popular, and they want to use that to launch their new ideas.

They want to have their cake and eat it too, a built in userbase and explore new ideas. I get it, but why not use another name so people don't get confused or frustrated?

It's just exhausting

codinhood commented on Ask HN: What Are You Working On? (Nov 2025) · Posted by u/david927

codinhood · 4 months ago

Working on some fun/silly projects.

My favorite so far is: "The Anti-AI UI Test".

After ChatGPT Atlas came out I thought it would be fun to find UI patterns that AI browsers couldn't figure out like multiple download buttons, hidden unsubscribe buttons, etc. So I created 7 levels of web dark patterns for AI browsers. You can try it yourself if you want:

https://codinhood.com/anti-ai-ui

I found Atlas can get through most patterns, so I created an even more unhinged one (job application form) that shifts the interface and flashes content.

Don't take it too seriously as actually testing AI browsers, it just a fun side project. I documented the patterns here: https://codinhood.com/anti-ai-ui/about

codinhood commented on ChatGPT Atlas chatgpt.com/atlas... · Posted by u/easton

gh0stcat · 5 months ago

The thing I find the most funny about all of these demos is they outsource tasks that are pretty meaningful ... choosing where to hike, learning more about the world around you, instead, you'll be told what to do and live in blissful ignorance. The challenge of living life is also the joy, at least to me. Plus I would never trust a company like openai with all of my personal information. This is definitely just them wanting greater and greater control and data from their users.

codinhood · 5 months ago

Yeah I thought the same, they're automating ordering on instacart. That's such a small task. I wonder if it was a paid product placement

codinhood commented on Wikipedia says traffic is falling due to AI search summaries and social video techcrunch.com/2025/10/18... · Posted by u/gmays

codinhood · 5 months ago

AI seems obvious, but social video? Are they saying people watch TikToks instead of reading Wikipedia, or people who used to look things up don’t bother anymore because of TikTok?

codinhood commented on Microservices are a tax your startup probably can't afford nexo.sh/posts/microservic... · Posted by u/nexo-v1

swisniewski · 10 months ago

I see this a lot ("if you are a startup, just ship a monolith").

I think this is the wrong way to frame it. The advice should be "just do the scrappy thing".

This distinction is important. Sometimes, creating a separate service is the scrappy thing to do, sometimes creating a monolith is. Sometimes not creating anything is the way to go.

Let's consider a simple example: adding a queue poller. Let's say you need to add some kind of asynchronous processing to your system. Maybe you need to upload data from customer S3 buckets, or you need to send emails or notifications, or some other thing you need to "process offline".

You could add this to your monolith, by adding some sort of background pollers that read an SQS queue, or a table in your database, then do something.

But that's actually pretty complicated, because now you have to worry about how much capacity to allocate to processing your service API and how much capacity to allocate to your pollers, and you have scale them all up at the same time. If you need more polling, you need more api servers. It become a giant pain really quickly.

It's much simpler to just separate them then it is to try to figure out how to jam them together.

Even better though, is to not write a queue poller at all. You should just write a Lambada and point it at your queue.

This is particularly true if you are me, because I wrote the Lambda Queue Poller, it works great, and I have no real reason to want to write it a second time. And I don't even have to maintain it anymore because I haven't worked at AWS since 2016. You should do this to, because my poller is pretty good, and you don't need to write one, and some other schmuck is on the hook for on-call.

Also you don't really need to think about how to scale at all, because Lambda will do it for you.

Sure, at some point, using Lambda will be less cost effective than standing up your own infra, but you can worry about that much, much, much later. And chances are there will be other growth opportunities that are much more lucrative than optimizing your computer bill.

There are other reasons why it might be simpler to split things. Putting your control plane and your data plane together just seems like a head ache waiting to happen.

If you have things that happen every now and then ("CreateUser", "CreateAccount", etc) and things that happen all the time ("CaptureCustomerClick", or "UpdateDoorDashDriverLocation", etc) you probably want to separate those. Trying to keep them together will just end up causing your pain.

I do agree, however, that having a "Users" service and an "AccountService" and a "FooService" and "BarService" or whatever kind of domain driven nonsense you can think of is a bad idea.

Those things are likely to cause pain and high change correlations, and lead to a distributed monolith.

I think the advice shouldn't be "Use a Monolith", but instead should be "Be Scrappy". You shouldn't create services without good reason (and "domain driven design" is not a good reason). But you also shouldn't "jam things together into a monolith" when there's a good reason not to. N sets of crud objects that are highly related to each other and change in correlated ways don't belong in different services. But things that work fundamentally differently (a queue poller, a control-plane crud system, the graph layer for grocery delivery, an llm, a relational database) should be in different services.

This should also be coupled with "don't deploy stuff you don't need". Managing your own database is waaaaaaay more work that just using Dynamo DB or DSQL or Big Table or whatever....

So, "don't use domain driven design" and "don't create services you don't need" is great advice. But "create a monolith" is not really the right advice.

codinhood · 10 months ago

> This distinction is important. Sometimes, creating a separate service is the scrappy thing to do, sometimes creating a monolith is. Sometimes not creating anything is the way to go.

I think this hits the nail on the head. People are trying to find the "one true way" for microservices vs monoliths. But it doesn't exist. It's context dependent.

It's like the DRY vs code duplication conversation. Trying to dictate that you will never duplicate code is a fool's errand, in the same way that duplicating code whenever something is slightly different is foolish.

Context is everything

codinhood commented on Sunsetting Create React App react.dev/blog/2025/02/14... · Posted by u/acemarke

acemarke · a year ago

Some of the main points I had:

- At least _mentioning_ Vite directly on the "Create a Project" page _is_ genuinely a step in the right direction. That said, they're going out of their way to still not just directly say "creating a basic SPA with Vite is a valid option for using React", and at this point it just looks pretty ridiculous. (Someone pointed out that the Svelte docs start with "Use SvelteKit"... and then the very next thing is "or add Svelte to a basic Vite project with this template". That's what's needed here.)

- I get the _intent_ of the "Build Your Own Framework" phrasing (ie, "choosing to self-install a router, data fetching lib, etc, results in a poor self-created framework"). That said, the "BYOF" page is the opposite of what's needed. It needs to be concrete steps to guide beginners into setting up an app with Vite or Parcel and recommending specific tools to add and techniques to use. Instead, it's "Step 1: Install Vite or Parcel"... and then multiple sections of "Look how hard routing, data fetching, and rendering are, you'll _never_ get this right yourself, use an existing framework instead, DON'T DO IT YOURSELF!". The content would be great if it was on a page titled "Web App Perf Basics", or "Framework Capabilities". But given that this is linked from the "Create" page with the hint of "follow steps here to get going DIY", this is the wrong content entirely.

- Similarly, the repeated use of "framework" to mean "a pre-existing thing someone else built" vs "a set of libs you added yourself" is confusing. Along with that, the overall tone generally comes across as "we don't want to acknowledge the breadth of ways that people use React in practice, and we're going to keep repeating the word 'framework' because we don't trust users to know how to make decisions themselves and we know what's best for you".

- I understand why they tried to emphasize "Next/RR/Expo can all export plain SPAs with no server needed!". That knowledge is genuinely not widespread. But, I don't think a bright green callout with that info should be the _first_ thing on the "Create a Project" page. _Somewhere_ on the page, sure, but it's not the most critical thing to show right away.

So, actual genuine improvement... and yet still kinda frustrating to read and see the phrasing and messaging so far off from what it _ought_ to be.

codinhood · a year ago

This perfectly captures my thoughts about the situation.

I don't know why they're so resistant to do treat SPAs as a completely valid way to use React in 2025. The majority of devs still use React primarily as a SPA. Recent State of React has it at 85% for SPA and 63% for SSR (1). Probably they know their answer is unpopular and thus we get a lot of deflection and phrases like "you should only consider a SPA if you have unusual constraints" whatever that's suppose to mean.

I've said it before, but changes don't happen when random devs like me complain, because I'm easy to ignore. So I really appreciate you specifically bringing this topic up, it really helps to get things going.

1. https://2024.stateofreact.com/en-US/usage/

codinhood commented on Avoiding outrage fatigue while staying informed scientificamerican.com/po... · Posted by u/headalgorithm

1970-01-01 · a year ago

In principal it's a great method to get back to normal, however there are key areas (subreddits, local groups, etc.) that really do provide information, expertise, and news content that isn't available anywhere else online. It's a double edged sword. The best way I've found is to be in there with a read-only mindset or perhaps only participating inside those key areas where political discussions are strictly prohibited.

codinhood · a year ago

This has been my exact issue with giving up reddit. It's really hard to replace very niche topics without it, since many online forums are dead. I also append so many searches on google with "reddit" because the top results are generally SEO spam.

Reading "You should quit reddit" helped a little. The author tries to reframe your hidden beliefs about reddit like "finding useful information" or "it's filled with experts." Helped me to realize I was spending more time reading about my hobbies than actually doing them. Though I understand it's not that simple, doing requires more energy, etc.

codinhood commented on Svelte 5 and the Future of Frameworks: A Chat with Rich Harris smashingmagazine.com/2025... · Posted by u/ulrischa

rk06 · a year ago

UseEffect(), dependency tracking, too much re-renders??

Problems galore in react, you should try out new js frameworks. Atleast vue and solid, to see what else is on the table

codinhood · a year ago

There are definitely problems with react, but I think his point was that they're not big enough to justify a change.

Though I agree trying other frameworks is a good practice. See what you're missing, or understand your preferred framework better.

codinhood commented on Bitwarden is turning 2FA on by default for new devices bitwarden.com/help/new-de... · Posted by u/coldblues

move-on-by · a year ago

I didn’t realize it was not required. This is a good change.

I could see this being one of those no-brainer decisions that requires herculean effort to push through all the product politics.

I would love to hear how this change came about and what hurdles needed overcoming from someone in the know.

codinhood · a year ago

Yeah it's interesting because on the one hand you're adding one more step to login. You're adding friction. On the other hand, it's pretty obviously a good security practice.

I wonder what the product and stakeholders discussed. Were there metrics on how many users they might lose with this?