php is not dead. wordpress runs roughly four in ten websites. laravel pays a lot of salaries. the php-is-dead opinion is loud on social media and quiet on job boards, and i'd rather not pretend otherwise.
so when i tell you i'm building my portfolio on next.js, tailwind, and prisma instead of the php + mysql + bootstrap stack i spent two years learning in coursework, i want to be clear about what's actually motivating the choice. it's not "the new thing is better than the old thing". it's a more specific calculation.
what i'm actually optimising for
i want a portfolio that signals modern frontend skills to the specific market i'm targeting — full-stack and cybersecurity roles in spain and the eu, with a bias toward companies that ship product rather than maintain legacy systems.
for that market, the current consensus stack is react-based, server-rendered, with utility-first css, deployed to a cdn with zero build configuration. next.js + tailwind + vercel checks every box. php + bootstrap + shared hosting checks none of them, even though it can deliver an identical user experience.
hiring is partly a vocabulary test. the vocabulary i want on my cv right now is the one that companies are writing in their job posts.
the honest trade-off table
this is the comparison i keep coming back to. nothing in either column is wrong:
| | php + mysql + bootstrap | next.js + prisma + tailwind |
|---|---|---|
| routing | react router or framework convention | file-based, automatic |
| backend logic | separate php files | route handlers in same project |
| seo | poor unless you ssr manually | strong by default |
| deployment | cpanel, ftp, or git on a server | git push → live in 60 seconds |
| hosting cost | ~€3–10/month | free for portfolio scale |
| job market signal | "maintains legacy" | "builds new" |
| mental model load | low if you grew up on it | medium — server vs client split is new |
| best agency match | wordpress / laravel shops | product / startup / agency-modern |
the right side wins on the things i care about right now. the left side wins on things that aren't on my current shortlist — running an agency that builds 50 wordpress sites a year, for instance, or joining a team that's already php-shaped.
the parts that are actually harder
it would be dishonest to claim the new stack is just better with no friction. the friction is real:
server vs client components. next.js's app router runs your components on the server by default. when you need interactivity — useState, onClick, event handlers — you add "use client" at the top of the file. forgetting this is the single most common new-developer error, and the error messages are not always kind. budget two or three days of just sitting with it before the mental model clicks.
typescript everywhere. my coursework was javascript. next.js examples are all typescript. picking up ts isn't hard — it's a thin layer on top of js — but it's another thing learning at the same time as the framework. i'm choosing to do them together because doing it later would be worse.
the tailwind class noise. a button can have twelve classes on it. some developers find this unreadable. the standard answer is to extract repeated patterns into components, which works but takes practice. i haven't loved it on day one. i expect to love it more by week three.
prisma's abstraction debt. prisma generates typed queries from a schema file, which is great until something goes wrong and you need to debug both the prisma layer and the sql it generated. the same operation in raw mysqli would have been one query i could read. the trade is type safety and migration tooling against debugging clarity. i think that trade is worth it. i won't pretend it's free.
what stays the same
most of what i learned in coursework transfers directly:
- http fundamentals. methods, status codes, headers, cookies, the request/response cycle. none of this changes with a framework swap.
- sql. postgresql has more features than mysql, but the join, the subquery, the index — the things that make you fast at sql — are identical.
- auth concepts. password hashing, sessions, csrf, role-based access. the implementation moves into nextauth or a custom solution, the underlying ideas are unchanged.
- owasp top 10. every item on that list applies to every web stack ever shipped. the libraries change. the vulnerabilities don't.
the way i think about it: the coursework taught me the what of web development. the new stack is teaching me a different how.
what this means for the portfolio
the site you're reading is the first artefact built on the new stack — next.js 16, tailwind, shadcn/ui, mdx for posts, vercel for hosting. the codebase is small on purpose. every piece is something i want to be able to defend in an interview without notes.
there are two more sites planned. a full-stack crud application — probably a job-application tracker, since i'm running one of those by hand anyway — that exercises the api routes, prisma, and authentication parts of the stack. and an api-driven dashboard with no backend at all, to show i can build something that's all async ui without reaching for a database i don't need.
that's the plan. the post you're reading is roughly week one of executing it. if you're following along, the rest will show up here.