Pains

Despite Python 2's end-of-life, many libraries and frameworks still don't fully support Python 3, creating compatibility issues when trying to migrate legacy codebases or integrate multiple dependencies with different version requirements.

Some Python libraries and frameworks (notably PySpark) cannot be easily used with Docker, forcing developers to choose between containerization approaches or framework selection, limiting deployment flexibility.

Working with code editors or tools that developers don't enjoy significantly crushes productivity, zapping energy levels and motivation. The editor is the most important daily tool for developers, and poor editor experience has outsized impact.

The Python ecosystem has so many libraries and modules that developers struggle to determine which library best fits their project. Evaluation requires considering documentation, community support, maturity, and stability across numerous options.

PostgreSQL backup and restore tools have counter-intuitive workflows: pg_dump by default does not include global objects like roles, so backups are incomplete unless users manually dump additional information. pg_dumpall doesn't support custom format, and pg_restore requires non-obvious flags like -C to create databases. File naming conventions (.backup) are inconsistent with documentation.

Python's dynamic nature makes debugging difficult and time-consuming, especially in large codebases. Cryptic error messages and the need to trace through dynamically-typed code makes it hard to identify root causes of bugs without strong debugging tools.

Python has a significant dependency on C implementations for heavy computational tasks, creating a gap between Python's ease-of-use and the complexity of leveraging performance-critical operations.

Docker, docker-compose, and Dockerfile syntax is confusing with numerous edge cases. Image sizes grow to problematic sizes unless carefully constructed, and Docker enforces restrictions on multi-line RUN commands that lack clear documentation on resolution.

There is a substantial lack of Docker experts in the Stack Overflow community and broader developer ecosystem compared to other areas such as web development, making it difficult for developers to find help and solutions.

Only 29% of Next.js GitHub issues get resolved; 52% of discussed issues remain unresolved. Many developers solve problems independently without creating tickets, making it impossible to measure framework debt accumulation. This visibility gap prevents data-driven planning and cost estimation.

The requirement that each page must have a page.tsx file can be confusing and may inadvertently lead to server-only code being bundled into client bundles, creating security and performance issues.

Next.js lacks comprehensive built-in internationalization support, making multi-language applications challenging to implement. Developers must rely on third-party solutions or complex workarounds.

The cookies() API allows type-checked usage like cookies().set() anywhere, but fails at runtime in certain contexts. This unexpected behavior differs from traditional request object access and creates developer footguns.

Many developers perceive Next.js as overengineered, adding unnecessary complexity without proportional benefits. The framework's architectural decisions and accumulated features create bloat that doesn't serve most use cases.

Web fonts from third-party CDNs require multiple round-trip requests (DNS lookup, CSS request, font file request), adding significant latency even on fast networks and degrading FCP.

GitHub Actions feels overwhelming for new users due to the range of features, options, and complexity of setting up workflows. The platform's learning curve is especially steep for those new to version control or CI/CD concepts.

Workflow syntax errors and broken `needs` clauses are only discovered after pushing code. Linters exist but are imperfect. Developers cannot validate workflows locally before commit, forcing a push-and-wait debugging cycle.

GitHub Actions provides no simple way to re-run workflows against the tip of a branch, making it difficult to handle transient failures and test workflow changes. Developers must work around this limitation by adding additional triggers, which is unintuitive and slows development velocity.

React violates traditional web development standards by requiring JSX instead of HTML, pushing CSS-in-JS and inline styles instead of cascading CSS, using custom routing instead of native window.location and history API, and introducing 'use server' directives instead of standard fetch/JSON/HTTP patterns. These deviations create debugging nightmares and bad practices.

Wrapping updates in act() for tests remains confusing and error-prone, especially with asynchronous operations. This adds friction to the testing workflow and requires additional cognitive load.

React lacks built-in support for complex form validation logic. Native HTML validation attributes cannot cover substantial use cases, forcing developers to reinvent form validation solutions repeatedly. Framework alternatives like Svelte with SuperForms provide more integrated solutions.

The React community exhibits growing frustration and disagreement about where React is headed, how it's developed, and recommended approaches for using React. Tensions exist between React team recommendations (full-stack, server components) and community concerns about complexity, accessibility, and backwards compatibility.

React's requirement to factor conditionals into separate functional components or use ugly ternary operators creates poor ergonomics. The lack of first-class IDE support exacerbates this issue, making conditional logic difficult to write and maintain.

Developers encounter difficulties with TypeScript configuration and integration in React projects, contributing to poor overall development experience and inconsistent typing patterns across codebases.