[HN Gopher] Ask HN: Should I use React for a personal portfolio?
       ___________________________________________________________________
        
       Ask HN: Should I use React for a personal portfolio?
        
       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.
        
       Author : numcap
       Score  : 12 points
       Date   : 2024-07-02 21:35 UTC (1 hours ago)
        
       | lcnPylGDnU4H9OF wrote:
       | 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.)
        
       | prisenco wrote:
       | 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."
        
         | CleanCoder wrote:
         | One might say, OP is overREACTing.
        
       | ladidahh wrote:
       | 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!
        
         | bhhaskin wrote:
         | Nextjs is the way.
        
           | langcss wrote:
           | Or Vite. It is a close call.
           | 
           | 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.
        
         | reducesuffering wrote:
         | Agree, you can use the React-isms to easily compose html into
         | reusable components while statically generating everything or
         | React Server Components.
        
           | prisenco wrote:
           | Or they could just write html and css.
        
       | karaterobot wrote:
       | 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.
        
       | SkyPuncher wrote:
       | You should use "resume" to show off your skills.
       | 
       | Nobody is looking at a portfolio site.
        
         | muzani wrote:
         | 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.
        
       | SCUSKU wrote:
       | 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!
        
       | Menu_Overview wrote:
       | 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.
        
       | purple-leafy wrote:
       | Why? Why not?
       | 
       | 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
        
       | rightqa wrote:
       | 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.
       | 
       | All the very best.
        
       | seabass wrote:
       | 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.
        
       | hluska wrote:
       | 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.
        
       | treyd wrote:
       | 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.
        
         | threatofrain wrote:
         | Maybe that's just generational expectation for the web. I doubt
         | users of native apps want their apps to be less interactive.
         | 
         | When I'm using a rich app like Notion or Obsidian I don't find
         | myself thinking "Oh wow, I wish Notion wasn't so interactive."
        
       | rty32 wrote:
       | 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.
        
         | gamegoblin wrote:
         | Depends entirely on how you intend to get a job
         | 
         | 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
        
         | sontek wrote:
         | 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.
        
       | risenshinetech wrote:
       | 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.
        
       | vintagedave wrote:
       | 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.
       | 
       | [0] https://daveon.design/
        
       | langcss wrote:
       | Go for it! Not sure why it is overkill.
       | 
       | 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.
        
       | aren55555 wrote:
       | If you are using this project for learning you may want to
       | consider something like Astro: https://astro.build/
       | 
       | It will enable you to dabble in building different pages/routes
       | in different frameworks very easily.
        
       | spcebar wrote:
       | 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.
        
       | apatheticonion wrote:
       | Personally, I have been experimenting with precompiling my
       | content-heavy sites in CI from markdown then delivering them as
       | static HTML.
       | 
       | 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 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)
        
       ___________________________________________________________________
       (page generated 2024-07-02 23:00 UTC)