I want to create a personal portfolio website for my personal projects, and to show off my programming skills for employers. I was wondering if using ReactJS with SASS instead of plain HTML, CSS, and JS would be okay for something like this, or would it be overkill using React for a small project like this.
I wouldn't spend any time on a portfolio. No manager spends their time looking at that. You are not a UX designer and portfolio means nothing. Your best bet would be polishing your resume and LinkedIn profile -- that's where recruiters and hiring managers look for highlights.
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.
As a hiring manager -- I very much disagree. If there is a link to a personal site, github, or anything else on the resume I will visit it and try to get as much information about the candidate as I can through it.
I'll ask them questions about it and see if they can talk passionately about it. Sometimes a nice personal site or github with some portfolio projects on there is the difference between a yes or a no.
As a manager who has hired hundreds of developers I always ask for a portfolio, with links to live sites.
Right-click, view source!
Can reveal a lot about a developers habits and practices.
I also expect a GitHub repo. Fyi, personal sites and projects are just as important as the ones you get paid to build.
IMHO LinkedIn is a waste of time. People struggle to keep it up to date and most don't have the time to put enough detail into their profile that it says very little about the candidate.
> Fyi, personal sites and projects are just as important as the ones you get paid to build.
You're missing out on great developers who have children and family lives that don't lend themselves to having the time for building a portfolio that nobody is going to look at except once every few years.
Not to mention that if a portfolio is going to be a selling point to a hiring manager, you need to rewrite it every time you change jobs to stay up to date with the latest trends lest you be pegged as someone who is out of touch.
Vanity projects are fine as vanity projects, but a hiring decision based on one is a red flag about the person doing the hiring and I'm happy to be passed over for it.
What do you expect to see in the source? You're either going to see minfied code, or like 5 lines of HTML and then a js import.
GitHub repo and personal portfolio are unreasonable expectations. I have both but keep neither up to date because 99% of my work is commercial/private.
You have to ask them to richly narrate their portfolio or you won't know if it's fake. You could be judging someone else's code quality. It's not wrong to do so but it's a different kind of interview.
In my experience you can quickly tell if the quality of somebody’s resume material lines up with the person across the table. I suppose at more attractive workplaces there are folks spending serious effort to game the system, but I haven’t seen it.
If anything I am most accustomed to seeing a light GitHub profile and an out-of-date personal site, and the candidate clearly has the skills to do way better today, they’re just not touching open source or spending time on their site.
I couldn't agree more! I don't know why this site is still relevant these days. It should be a sign of an entry-level or mediocre employee/job by now. I haven't updated mine in about four years or so.
I trust that when you were hired as a manager you were required to provide a sample of the recreational gantt charts you have done for historical engineering projects.
If you post cool projects on HN or Twitter, people will absolutely look at your personal site and send you job offers if you look promising
I've gotten 10x more serious job offers from posting projects on HN and Twitter than via resumes and LinkedIn
All that said, the content of the projects is an order of magnitude more important than the design of the personal site, unless you want frontend roles
Agree, if your personal site is basic looking but links to a cool react library you made that would be more impressive to me than a fancy portfolio.
If you want to learn React then nothing you do is a bad idea because it is all going to teach you something. If you want to look impressive spend your time building something impressive that you think is cool. Even something overdone like a Select component or a Table component if it works well will demonstrate way more competence.
If you want to use or show off React, use it. If you want to make it simple, keep it simple.
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.
Personally, something I think would stand out is an explanation of decisions made for the project, such as in a README. I'd love to know why you picked React for the project and it may not sound great in recruiting context to say, "I thought it would make me more likely to be hired." Of course, that's a very understandable motivation but it's not going to fly in a real-world job setting (though, I've heard stories; don't count on it happening to you).
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.)
I'd argue that it's overkill. Simplicity of solutions is a virtue and a good employer recognizes that.
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."
It depends what you want to communicate through your portfolio, other than your portfolio items. What message do you want prospective employers to get?
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.
I don't know if I've ever thought to see which technologies went into a candidate's portfolio site. For me, you want it to be clearly presented, with the content being the most important thing. I would not give an engineer more or less attention if I knew they were using React vs. vanilla HTML/CSS/JS. I want to see good case studies of previous work, which show you've got a good head on your shoulders. Everything else comes out in the interview.
If you’re using it as a reason to learn React or it gets you excited to get started, sure! Especially if you plan to have more than just static content, it’s totally a viable choice. But as someone who writes a lot of React for work, do I think it sounds like the right technology for a personal portfolio? Not really.
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.
If you're trying to market yourself as a react developer, creating a killer portfolio site in react isn't a bad idea, but as a general use case, I don't think React makes a ton of sense. React, in my opinion, shines mainly for web apps, and not informational websites, which presumably is what you're looking to build. There are better solutions if all you want to do is post links to your work in a presentable way.
My suggestion is to use something that's simple to maintain because you might have plenty of time now, which may not be the case in the future. Your content should be platform-agnostic; for example, as markdown files, so if you migrate to something else, it will be quick and easy. My last suggestion is to use a Static Site Generator (SSG), minimize or eliminate JavaScript, as it makes things faster to load, and your content mostly doesn't require it. I personally use Zola, but there are plenty of other good options. Hugo can be a bit complicated at the beginning, though.
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
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)
Anyone who over-obsesses or nitpicks framework choice for some personal project isn’t someone I’d want to work for/with.
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
It depends on a lot of things, including how much content you have to display and how much interactivity you want to provide.
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 are looking for a front end role, a great idea, otherwise it's not a bad idea. But, I would suggest going with Next over React for static content, this a great starter https://vercel.com/templates/next.js/nextjs-boilerplate and your build process will be all set from the set and tied to the created GitHub main branch, best of luck!
Vite seems to more configurable but the trade-off is you spend more time figuring out how to set stuff up like SSR and routing. NextJS had it all set up but Vercel make some weird choices like rolling out the app router and saying it is recommended when it felt very beta still.
My preferred thing is NextJS or Vite but constrain it to front end only. Use a better back end stack than Node. Any of the major ones will do.
I browsed with JS disabled by default for a long time so I would have seen nothing and clicked away. Unfortunately I don't do this anymore because every website uses JS for innocuous things now and most sites (not HN though!) would be hopelessly broken.
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.
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
React or not, I think you should maximize for your fun and enjoyment. I've seen many a personal portfolio and the ones that shine the most are the ones where you can tell the author really enjoyed working on it, either on the site itself, or when asked about it in an interview.
Do what excites you, and interviewers will pick up on that!
You haven't provided enough context (if there even could be enough) to answer this question. You asked if it "would be okay". No one can answer this question for you. What does "be okay" even mean?
Focus on the content of the portfolio and don't sweat the invisible details.
I'm a manager and certainly take a look at any platform provided by the candidates before an interview. You should create a portafolio that not only showcases your work but that it also follows web standards, SEO rules and great performance, this is what I would likely focus on.
If it's a portfolio website, I don't think your client would know/care what you have used. So use whatever brings the best of your skills and knowledge.
And in parallel create something specific to React which demonstrates your skills and at the same time useful to others.
How will your portfolio benefit from React? Portfolios are usually just static content. By all means use interesting technology like React and Sass to develop it, but compile it all to static HTML/CSS, unless you really need dynamic functionality.
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.
It's the opposite in my experience. Anyone can write on a piece of paper that they have 5/5 CSS skills. The portfolio says what those skills really are. I've gone to interviews where people printed out all 20 pages of my portfolio, but surprisingly none where they printed out the resume.
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.