> I became a dev when everyone was hiring for React, so React is what I taught myself immediately after <i>bootcamp</i> in the scramble for a job<p>A better education path (in a bootcamp, university, book, youtube, whatever) would start with the fundamentals and build it from the ground up... not the other way around.<p>(I just realized how lucky I am for being taught in the best possible order, from the ground up... first the basics... and how so many people didn't have this opportunity)
I've tried learning Ember, React, and Vue and have tapped out pretty early. Now I'm learning how to build a site using only vanilla JS and doing everything from scratch unless I find a reason to switch it. I think I'm making decent progress.<p>I even wrote my own simple test framework that shoves the results on the bottom of a page. After adding a few features I decided to switch it to Jasmine.<p>One thing I'm noticing is how often you need npm which I find very annoying. How is a JS library or framework anything more than a single JS file that you have to include in your page? Why is everything npm this and yarn that? Jasmine has standalone install instructions that are easy to find but I can't say the same about Jest.
I think this is a pretty awesome statement. I'm always unreasonably pleased when I see a web page that embraces appropriate simplicity.<p>> Coding a basic vanilla multi-page application (MPA) saves time in development (goodbye babel/postcss/SSR config) and builds are fast (this site builds in less than 1.2 seconds).<p>I'd hope that builds would be on the order of a small pile of milliseconds! (or zero: a site like that could just be handcoded, really).<p>> I'm only using these 2 lines of Javascript to add the current year in the footer copyright tag<p>This could also be eliminated. At least in the US, there is no legal reason to add a copyright notice at all, and you certainly don't have to add a year. Those requirements were removed years ago.<p>But, if all you want is the year, why not do that server-side? Or bake it into the html and set up a bit of automation to replace the year with a new one every Jan 1.
I don't get the value prop of all vanilla. The overhead involved in building a react app is nearly nil with all the tooling we have. Sure CRA was slow, but vite makes things sub-second again.<p>It's like when remix people talk about progressive enhancement to me. Sure, cool, you can do things differently. But why? If you already know the ins and outs of a framework or tool and are productive with it, use it. I'm never gonna hire someone because of how much they "flexed" with their vanilla site, just like I won't hire someone who flexed with their cool fresh-from-bootcamp react animations.
Many of the comments suggest that of course you wouldn't use React for a blog.<p>Someone forgot to tell these folks:<p><a href="https://buttercms.com/blog/how-to-create-a-blog-with-react/" rel="nofollow noreferrer">https://buttercms.com/blog/how-to-create-a-blog-with-react/</a><p><a href="https://www.sanity.io/guides/build-your-first-blog-using-react" rel="nofollow noreferrer">https://www.sanity.io/guides/build-your-first-blog-using-rea...</a><p>(and many more)<p>I'm firmly in the camp that React and similar frameworks are overused. However, the point is that there's a large part of our industry that is bought-in (and in many cases, built businesses around) the concept of "React all the things" and it's encouraging to see push back.
My website is also completely static, but made with React. That means no React at all at runtime, it is completely static. React does not automatically mean dynamic. I get all the benefits of both. I love the flexibility nextjs provides here.
Recently tried no framework, Jekyll, Next, Astro and finally SvelteKit. The only one I liked was SvelteKit.<p>Not interested in reinventing the wheel (no framework), dealing with lots of boilerplate and over-complication (Next/React) or using multiple UI libraries (Astro). SvelteKit is a fine balance between simple and providing enough functionality that allows me to focus on generating content with minimal friction.
* [...] brought to you by vanilla everything. No Javascript frameworks, CSS libraries or flashy animations. [...] *<p>Proceeds with a distracting animated image of the old portfolio, thought that was funny.
The reason react was developed is mostly null at this point. Modern javascript is so fast and plesant it's hard to imagine many real reasons you can't stay entirely within vanilla.
I'm glad this works for them. Personal websites and portfolios are a reflection of people on their journey. If it is built with React, maybe they are learning React. If it is vanilla JS, maybe they appreciate the flavor of vanilla.<p>Instead of making sweeping statements about the choice of stack, I appreciate that someone took their time and built something of their own. Congrats. Next thing they should do is an accessibility audit and learn from it.
Is it fashionable now to make a site like almost every site used to be in 2008 and wear it as a badge of honor?<p>P. S. Needs to be even more garish. Remember the "space pigs" theme of FastTracker II? Man, those were the days.
Why choose pug over EJS?<p>When I started my first Node/Express project I picked pug too but quickly realized it was too removed from vanilla HTML I was seeing in the books/MDN and switched to Handlebars. Immediately discovered that Handlebars didn’t have a built in support for something fairly basic I needed and I either had to roll my own extension to it or look for something else so I ended up switching yet again to EJS and I’m still using it a year later today. EJS is perfect if you want vanilla HTML + vanilla JS.
> A developer needs a website to prove they can build a website.<p>Not really. Doesn't your experience, reflected in your CV and the technical interview, already prove that? A portfolio site is nice to have, particularly if you're a designer and want to showcase your work, but it shouldn't be a requirement for a developer, frontend or otherwise.
I have a nitpick re: the centrifuge example<p>While the paperfuge is cool and may even reach higher RPM/G than some bench top ultracentrifuges, it cannot do so consistently.<p>Putting "Samples were centrifuged at whatever amount of G:s yours truly could crank out on a hand built paperfuge for a solid 10 minutes" in the materials and methods section doesn't exactly scream reproducible science.
I built my simple site with just Go, no libraries of any kind. Two years later it is such a dream to never ever have any dependency chores to do.<p>Before that I had a Phoenix site and I feel like every time I touched it (months apart) I had to update something.<p>Not such a big deal at work where monitoring for security vulnerabilities and updating dependencies is paid work that we make time for but I hate that kind of busy work on my own time.
> My portfolio needs to be nothing more than the HTTP equivalent of a tri-fold brochure.<p>My concern here is that your website _is_ your portfolio - including how you build it. It's not just the content and long narrative that's going to sell you. This new approach has switched from showing what you can do to telling what you can do.
About that Paperfuge analogy ... maybe I am stupid or overly skeptic but I haven't seen that paper wheel carry any samples in the video. If there was some solution to mount samples (symmetrically I'd guess) it would become quite dangerous to rotate them 120.000 rpm without any enclosure, right?
No, React with webpack/vite is simpler than "your handcrafted static site generator".<p>I don't have to use any of Hugo, Jelkyll,..., because i can cook my own SSG toolkit right inside React.