Technology

Why I, a Python Developer, Now Build Products with Next.js

A Machine Learning Engineer's Reconsideration of the 'Right Tool for the Right Job' Principle and the Implementation Cost Inversion Phenomenon

2025-04-15
17 min
Development Productivity
AI-Driven Development
Technology Selection
Next.js
Python
React
Tailwind CSS
Ryosuke Yoshizaki

Ryosuke Yoshizaki

CEO, Wadan Inc. / Founder of KIKAGAKU Inc.

Why I, a Python Developer, Now Build Products with Next.js

A Machine Learning Engineer's Choice for Web Development Battles

For many years, I worked primarily on machine learning projects, and writing in Python was my daily routine. With plenty of educational activities, I created explanatory materials in Jupyter Notebook and published them as HTML using Sphinx. I even wrote a book using Jupyter Notebook (with much gratitude to the editors and typesetters who made this possible).

My love for Python stemmed from its overwhelming versatility—from data science to web development. With Django or FastAPI, you can build quite capable web applications. The ability to "do everything in one language" was incredibly appealing to someone like me who ventures into various fields.

However, I now barely use Python, having switched to Next.js, a JavaScript-based web application framework, as my primary tool. This is a surprising change even for me, but there's a clear reason behind it.

In short, I've returned to the principle of "the right tool for the right job". Yet, my interpretation of this principle differs slightly from what most people might think. It's the principle of "the right tool for the right job" viewed through the lens of implementation costs.

Deciding to Leave Python: Finding the Right Tool for Each Job

First, I'd like to clarify from my personal experience that comparing Python and Next.js directly is a misconception. I used the Python versus Next.js contrast in the title for clarity for those unfamiliar with Next.js, but the actual relationship is as follows:

図表を生成中...

Python is a programming language, while Next.js is a web application framework built on React. However, when I considered how each functions in my specific work, I made some interesting discoveries.

My Love for Python: Strengths in Data Science

What made Python wonderful for me was:

  • Overwhelming strength in data science/machine learning: An array of powerful libraries including NumPy, Pandas, scikit-learn, TensorFlow, and PyTorch
  • Highly readable syntax: Easy to understand for beginners with high maintainability
  • Versatility: Handling everything from scientific computing to web development

As someone who had used Django and FastAPI for web development, I even thought I didn't need any other options. FastAPI in particular is surprisingly high-performance and perfect for API construction1.

Conflict and Decision: Pivoting to Next.js

However, about 5 years ago, I encountered Next.js and gradually became attracted to it. Its appeal included:

  • React-based component-oriented UI: Highly reusable and maintainable UI construction
  • Diverse rendering strategies: Options for SSR, SSG, etc. selectable on a page-by-page basis
  • Excellent developer experience (DX): File-based routing, image optimization, and more

This transition was by no means easy. For me, as someone centered on Python, immersing myself in the world of JavaScript/TypeScript and React felt like giving up part of my identity. I struggled with learning for about 3 months. Implementations that used to take me just a few hours weren't progressing at all, and I repeatedly questioned myself: "Is this decision wrong?"

If this bet had been wrong, it would have been a huge loss. Accepting short-term losses while also heading in the wrong long-term direction—this is the scenario developers most want to avoid. But ultimately, this decision was correct. Next.js has now become one of the most important frameworks for web application development. I simply placed my bet before it ripened.

The Essence of "The Right Tool for the Right Job" I Discovered: An Implementation Cost Perspective

My reinterpretation of "the right tool for the right job" came from actual project experience. Its essence isn't simply "utilizing each technology's strengths." More importantly, it's about the perspective that "the main focus should be on what has the highest implementation cost."

The Implementation Cost Inversion Phenomenon I Experienced

While building various web applications with Python, I inevitably needed JavaScript for frontend development. Incorporating frameworks like React became necessary, and that's when I noticed an interesting phenomenon.

図表を生成中...

As implementation progressed, I found that I was spending an overwhelming amount of time on the frontend. Python's role was limited to basic file and database operations, calling machine learning models, etc., while the implementation costs on the JavaScript side rapidly expanded. And then it hit me:

Eventually, even with Python, you need JavaScript for web development and end up incorporating React or similar frameworks. When that happens, Python's role becomes surprisingly minimal, and implementation costs for dynamic operations in JavaScript increase. So, wouldn't it be better to focus on what has the highest implementation cost?

This was the main reason for my pivot to Next.js.

Distribution of Implementation Costs: From My Experience

Let me visualize the implementation cost distribution in web applications based on my experience.

グラフを読み込み中...

This chart is based on my project experience, but in many web applications, the majority of work hours are spent on frontend implementation. This tendency is even stronger in today's world where user experience (UX) is highly valued.

In such situations, I'm convinced that it's rational to choose technology that focuses on the area with the highest implementation cost. In other words, if you're spending most of your time on the frontend, it's efficient to center your approach on a framework optimized for frontend development and integrate the backend accordingly.

Next.js precisely aligns with this thinking. It not only handles the frontend but also provides backend functionality through API routes, functioning as a single integrated framework2. This was a significant discovery for me.

The Decisive Factor of Speed: Prioritizing User Experience

Beyond implementation costs, a critical reason I chose Next.js was performance. When it comes to what we deliver to users, speed is justice.

Python's Speed Issue: The Reality

While people sometimes say "Python is slow," in my experience, it depends on the context. Indeed, for pure computational processing, Python can be slower than compiled languages like C++ or Java3.

However, modern Python frameworks like FastAPI demonstrate excellent performance with asynchronous processing and ASGI servers4. I myself have experience building high-speed API servers using FastAPI.

The Decisive Difference in Perceived Speed: What Next.js Changed

However, in terms of performance that users actually perceive, I've felt that Next.js has a significant advantage. This is mainly due to the architectural differences between SPA (Single Page Application) and MPA (Multi Page Application).

図表を生成中...

With Next.js, which doesn't render page by page like Python, the browser's re-rendering method is fundamentally different. In MPA frameworks like Django, each page transition requires fetching complete HTML from the server and a complete browser reload5.

In contrast, Next.js can function like an SPA, where page transitions are handled by client-side JavaScript alone. Only the necessary data is retrieved from the API, and only parts of the DOM (Document Object Model) are dynamically updated6. Therefore, page transitions are faster because it's an SPA (Next.js).

Additionally, Next.js's most brilliant aspect is its flexibility to switch between SSR (Server-Side Rendering) and SSG (Static Site Generation) on a page-by-page basis7.

  • Home page (high traffic): High-speed display with SSG
  • Dashboard (requires authentication): Dynamic content with SSR

This flexibility enables optimal performance across the entire site. I experienced this firsthand when initial page load time in one project was reduced from 3 seconds to 0.8 seconds. Users even asked, "Why did it get so much faster?"

Technology Selection with an Eye on the AI Era: The Path I Chose

In the AI era, the importance of "being mainstream" was beyond my imagination.

Forward-Looking Decision to Choose Next.js

Choosing Next.js was a courageous decision 5 years ago, but now I can say that decision was correct. Major companies like Netflix, Uber, and TikTok have adopted it8, and React itself maintains unwavering popularity as a frontend framework9.

From my experience, if you're making a web app now, Next.js is the only choice. Of course, there are issues. Particularly significant is whether you can tolerate being locked into Vercel. You can deploy in other environments, but you'll move away from the optimized environment Vercel provides, and some features will be limited. However, considering the improvements in development efficiency and performance, I accept this trade-off.

Why Mainstream Technologies Shine with AI Assistance

I particularly value my choice of Next.js for its benefits in the AI era.

図表を生成中...

Being mainstream is quite important in the AI era. Code-generating AI tools like GitHub Copilot, ChatGPT, and Claude use public repositories like GitHub as learning data10. Therefore, AI often has more accurate and detailed information about widely used languages and frameworks.

In my own experience, when asking AI questions about Next.js, I get surprisingly accurate and detailed answers, while with minor frameworks, errors and vague responses tend to increase. This difference directly affects project progress speed.

Choosing Tailwind CSS: Structural Reasons

For frontend development, it's better to use Tailwind CSS for CSS. Vibe Coding with AI definitely gives this an advantage. It completes with reading and writing in a single file, keeping costs low.

The idea that separating functionality and styling is better was about maintainability for humans. In an AI-prerequisite world, it seems more important that functionality and styling be close together, even if they're combined.

AI doesn't care about contexts like "for humans..." What's a good choice for AI? I think it's about time we start organizing around this question. Compatibility with AI code assistants is becoming an unavoidable factor in technology selection.

Overcoming the Wall of Unlearning: From My Experience

The most difficult part of my switch from Python to Next.js was the process of unlearning existing skills.

What 3 Months of Struggle Taught Me

Unlearning is difficult. About 5 years ago, it took me about 3 months of learning to complete my first project while unlearning my current skills. Despite having acquired the same concepts in Python, which should have meant only learning the differences, learning something new is frustrating at first.

Things that would have been accomplished in the same amount of time before couldn't be done at all. The key point is whether you can tolerate and endure this short-term disadvantage. You need to grit your teeth for the future.

図表を生成中...

What I learned from this experience was the value of betting before it ripens. If you start learning after a technology has fully matured, you've already missed that wave. If you start learning when it's already mature, you'll always be behind.

My Advice to Web Developers

I hope those who want to develop web apps will boldly try unlearning. Especially for those proficient in Python, investing in Next.js should bring significant long-term returns. However, this isn't an easy path. You need to be prepared for initial productivity drops and approach it with a long-term perspective.

I'm now reaping significant returns from my investment in Next.js 5 years ago. However, the world of technology is constantly changing. It was good that I switched 5 years ago, but there's a possibility things will change again. That's why it's important to always keep an antenna up for new trends and have the courage to "bet before it ripens" when necessary.

Conclusion: A New Interpretation of "The Right Tool for the Right Job" I Discovered

Through my transition from Python, I've come to reinterpret the principle of "the right tool for the right job". It's not just about "utilizing each technology's strengths," but contains the deeper insight of "focusing on the part with the highest implementation cost."

Python is suitable for data analysis. However, when deploying to a production environment, the right tool for the right job applies.

Considering the reality that frontend implementation costs are often highest in web application development, it makes sense to center on frameworks optimized for frontend like Next.js. And if that framework also integrates backend functionality, development efficiency increases further.

Currently, I use Python only when absolutely necessary, such as for machine learning. In those cases, I use it partially by API-izing it with FastAPI. I consider this a practical approach in line with the "right tool for the right job" principle.

Technology selection is always context-dependent, and the optimal solution varies based on project requirements and team skill sets. However, the perspective of judging based on implementation cost distribution should be useful in many scenarios.

And finally, success in the world of technology depends on the courage to anticipate trends and an attitude unafraid of unlearning. By betting "before it ripens," you can reap maximum benefits when it does mature—this is the greatest lesson I learned from my adoption of Next.js.

References

Footnotes

  1. FastAPI - High performance, easy to learn, fast to code, ready for production. https://fastapi.tiangolo.com/

  2. API Routes - Next.js. https://nextjs.org/docs/pages/building-your-application/routing/api-routes

  3. The Computer Language Benchmarks Game. https://benchmarksgame-team.pages.debian.net/benchmarksgame/

  4. FastAPI Benchmarks. https://fastapi.tiangolo.com/benchmarks/

  5. Django: The web framework for perfectionists with deadlines. https://www.djangoproject.com/

  6. SPA vs MPA: Which Web Architecture is Right for You? https://www.ramotion.com/blog/spa-vs-mpa/

  7. SSR vs. SSG in Next.js: Differences, Advantages, and Use Cases. https://strapi.io/blog/ssr-vs-ssg-in-nextjs-differences-advantages-and-use-cases

  8. Next.js Showcase. https://nextjs.org/showcase

  9. Stack Overflow Developer Survey 2023. https://survey.stackoverflow.co/2023/

  10. GitHub Octoverse 2023. https://octoverse.github.com/2023/

Ryosuke Yoshizaki

Ryosuke Yoshizaki

CEO, Wadan Inc. / Founder of KIKAGAKU Inc.

I am working on structural transformation of organizational communication with the mission of 'fostering knowledge circulation and driving autonomous value creation.' By utilizing AI technology and social network analysis, I aim to create organizations where creative value is sustainably generated through liberating tacit knowledge and fostering deep dialogue.

Get the latest insights

Subscribe to our regular newsletter for the latest articles and unique insights on the intersection of technology and business.