If you want to do a portfolio regardless, especially for non job hunting purposes, do it however you'd like and spend however much time you want, ONLY IF you enjoy creating such a website. Otherwise anything that is not ugly is ok, and my personal preference would be to give the website a somewhat "modern" look, although not fancy.
If your portfolio's content is simple enough for one page, or just a unique pages, go for just HTML! You will like it. Static HTML files (with a bit of JS) will be easy to deploy and better for SEO and performance.
That said, you might quickly find you want something with more capabilities.
Through my experience, you're eventually going to want some sort of template engine. Want to reuse the same "article" layout or you want a for-loop over a list of articles? Templates. Your template engine could be as simple as Pug or Handlebars templates, no client-side rendering needed yet. Compile your templates and deploy your HTML files.
Pug (or other template engines) will probably carry you a long ways. The next step would be some sort of static site generator. This is basically the same as Pug, with with extra options and more structure. Hugo and Jekyll are popular, but there are a lot of options. Deploys are the same: build locally, deploy, or set it up with some hoster like Netlify or Vercel to build and deploy automatically (and for free!).
The next level is something like Nuxt, Vuepress, or Next, which can generate static websites, but also give you fancy things like client-side rendering for fancy page transitions (although there is now a native way to accomplish this with just HTML and CSS!). My blog articles are written in Markdown so they are easy to port to other frameworks or themes. This is the approach that I use because I like to stay up to date with Vue...but you'll spend a lot more time "upgrading" things instead of building or writing. Just my experience.
That said, I think, e.g., "I wanted to learn what I could do with React" sounds like it would be a pretty good reason to choose React. The important thing is being honest with why you chose something even if the reason seems boring or same-y. (Hiring managers love boring and same-y.)
On the other hand, there's always fun in doing something stupid and impractical, like porting DOOM to a smart appliance. So instead of making a portfolio with React and SASS, try doing something else that more clearly projects "I know this is overkill, but it's weird fun so I did it anyways."
Here’s an example: I created a new website to contain articles[0]. It’s not a portfolio but the design and the way it’s built carry a specific message. For me, that message is caring about HTML as a communication mechanism; about websites as documents not apps; about minimalistic design not meaning lack of ornamentation; and on privacy. I did this through a site based on more text than graphics, but beautifully styled; on zero JavaScript; on zero cookies or tracking scripts; and on elegant, manuscript-like typography. None of this is overt in the site unless you read the About or the CSS file comments or happen to realize. It’s there so the kind of people who will notice this, will notice this.
So for you: what will best show off your programming skills? Perhaps you could have special JavaScript behavior or a HTML5 canvas special effect header. Or some custom widget. Or beautiful transitions between pages. Or something I cannot advise but that’s difficult with React and those who know React, will recognize when they see it. Find your communication purpose, and then build something that communicates that to those who have eyes to see it. They’re your audience.
To me, part of the joy of small personal sites is that you can sidestep all of the tooling and compilation stuff and instead just write and publish. But I’ve also seen some highly interactive portfolio apps that run on React or similar, so a lot depends on your vision and what excites you.
The git repo is a bunch of folders with markdown, where the file path in the repo becomes the URL on the website.
e.g. "/articles/foo.md"
Becomes: "https://example.com/articles/foo.html"
If I need dynamic functionality, I'll sprinkle in a little Preact, petite-vue or alpine-js.
Some examples of dynamic functionality are article search (done on the client side with a pre-computed index), a comments section or a contact submission form.
This opens the door to:
- Pre-downloading articles in the background using service-worker
- Your site being incredibly small and jarringly fast
- Largely free to host using AWS S3 + Cloudfront/Cloudflare
- Easier to manage from an SEO standpoint
You can see an example of this here: https://ozkiwi2001.org
I'm not a designer though so the design is pretty spartan haha. I also haven't yet updated my own portfolio site with this approach and I haven't found a minimal solution to serverless/free analytics.
In the above example, rather than a CMS, I taught the client (the OzKiwi team) how to use SourceTree/git and they edit the content markdown directly via a markdown editor.
It was interesting for me to see if people without software development experience would be motivated to learn these tools to maintain their website - in exchange they get effectively-free hosting costs.
They did super well, calling me every now-and-then when an image doesn't appear on their site because of a malformed URL, haha). I added a few pre-commit hooks to do validation on file names and so on.
That said, it might be easier to do this with a single SPA entry point and the content delivered separately (still precomputed during CI)
Use whatever you like. The most important part is to make something you enjoy keeping up to date that doesn’t become a big chore. I use NextJS for my personal site, but before that I used a Python static site generator, and before that a collection of FreeBSD POSIX make files and shell scripts. All the same design. Whenever I changed technology it was because it would make it easier for me to update or deploy the site
If this was a work task, you would consider those things, plus time to deliver, cost and existing skill in React (versus need to upskill resources).
My advice would be to go through that process. What are your requirements, both from a functional and organizational point of view? From there, what options do you have to achieve the requirements? And finally, what are the costs, benefits and potential risks/rewards of both?
That level of technical analysis would be an excellent addition to a portfolio.
If you want to show off React, do a demo somewhere other than your main website. It's really offputting to see gratuitous interactivity on personal sites that just gets in the way of actually reading what's there.
Arguments can be made either way.
You could build a portfolio site with just HTML depending on your priorities
Or you could extend to using CSS
If you need basic interaction and event listening, JavaScript is fine enough
Maybe you want a really interactive single page portfolio or web app, then you could reach for React/Svelte/Vue/Angular
Maybe you want a blog style portfolio with many pages and some interactions, in which case you can use any server side templating framework or a “full-stack” framework like NextJS
Do what excites you, and interviewers will pick up on that!
Focus on the content of the portfolio and don't sweat the invisible details.
It will enable you to dabble in building different pages/routes in different frameworks very easily.
And in parallel create something specific to React which demonstrates your skills and at the same time useful to others.
All the very best.
People may have JS disabled. But you can mitigate against this with SSG/SSR. Although you might have to "dual code" forms to work both ways if you have any.
I would just use what makes you happy.
Nobody is looking at a portfolio site.