It depends a lot. I work as a web platform engineer so the datasets on some parts of what I do are limited. For a react project, there are millions of projects, code and setups in the training data. To create and manage a monorepo that runs on our specific infrastructure, the story is different. Writing bash scripts to run on GitHub actions: 10x. Ask to setup a monorepo: -3x. Modify a specific business domain: -10x. A couple of weeks ago I was handed a project that was the implementation of a experimentation sdk. The project was made by previous developer with Claude. I couldn't understand a thing. I had to basically start from scratch to understand all the principles of how this experimentation tool worked. This was not fault of the previous Devs, it was a combination of reading code from a third³ person (person through an LLM) plus I'm a bottom up processor.

There are still mid size company that try to make a good product for a fair price, but I have the gut feeling that any company that have a board of shareholders will always default to this behaviour.

An ad show on a native mobile app pays between 5x to 10x more than the same ad in a webpage.

Advertiser's also get way more data from the mobile app than the data they can get from a webpage.

The company I work for makes 75% of their revenue from showing ads and they pushed very aggressively to install their app.

For example if you stay as close as possible to the framework defaults, everything is golden. But as soon you start pushing it to the limits the cracks start to appear.

Last year I was working on a NextJS app with 15k files, 18k unit tests, 100+ developers in the same repository and a page with hundred of millions of page views daily. Under that conditions NextJS doesn't scale, but again, those conditions are not the majority of the NextJS cases.

In that project, we have been using NextJS as a standalone for around 5 years and each time NextJS rollout a major version it take us at least 2 months to be able to upgrade and keep it working.

Here is an article I wrote of why we chose it https://d13z.dev/blog/07-why-kleinanzeigen-picked-astro-over...

Having built (and debugged) large Next.js apps before (see my other articles series linked in the post), we applied those lessons learned to this decision. Factors like the friction in self-hosting Next.js at scale, the difficulty maintaining high performance with our specific page structure + third-party scripts, and the desire for faster dev cycles led us to explore alternatives. Astro's focus on minimal JS, Island Architecture, and framework flexibility ultimately aligned better with the specific problems we needed to solve this time around.

Full details on the comparison and decision process inside. Happy to discuss further!

Comments URL: https://news.ycombinator.com/item?id=43782980

Points: 5

# Comments: 1

Backend development at that time looked easy (build restful APIs of a database) and all the fun was in the frontend.

So I started focusing on frontend and I ended landing a job a techlead of a small team (6 Devs). This change give me visibility of what are the problems with development, so I started going meta-development. How are we developing things? How can we adapt to the business requirements? How do I keep my team happy and focused? Eventually management saw a value in my work and they asked us to create a team to help other teams across companies branches. I find the joy and purpose not in achieving company okrs, instead in making other developers better :)