Look ma, no React: I recoded my portfolio site with vanilla everything | Hacker News Reader

Look ma, no React: I recoded my portfolio site with vanilla everything

clairefro.dev

117 pointsmarjipan200181 comments

> I became a dev when everyone was hiring for React, so React is what I taught myself immediately after bootcamp in the scramble for a job

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.

(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)

Agreed, but it's so rare nowadays though. I still remember when I saw a junior frontend dev struggling to get some element to look differently when hovered in React. They went though loops and hoops to style it using CSS-in-JS and mousemove, only because they didn't hear about :hover.

Then what ? That junior dev could produce working software, and fix the css issue later (if needed).

Give that "senior CSS developer" a day and figure out how to manage state, then what you get is a crap.

Yeah that's gonna work out great when the entire app is built using weird overcomplicated solutions to simple problems, let's just clean it all up later! Doesn't matter how you write your code as long as it seems to work, well deal with all the bugs we discover later!

The proper way to do it is to do code reviews and teach newbies how to do things like this. Ideally they should have asked about it(or just googled) before the review.

I think "well just fix it later if needed" is asking for trouble and you're basically just writing legacy code.

The problem is that if the end state you want is a clean codebase implementing your use case, that’s also easy to modify and extend, then the mess such a developer will produce is a much worse starting point than starting from scratch.

Business doesn't fund "fix it later" -- it just becomes tech debt. You have to push to do it right the first time or approve merges you can live with in perpetuity.

My favorite experience with Bootcamp folks was someone who came in do an interview, and she could talk, was professional, had nice looking blogs, etc. and seemed really awesome on paper. However, I had her do a really simple React exercise, and she was producing some really strange code like using Ruby inside of a JavaScript onClick handler? lol

I think a failing of a lot of these bootcamps is they encourage people to present themselves as more experienced than they actually are. I don’t mind someone who’s starting out, and has a lot of potential, but please be honest about your skill level, as it just disappoints the interviewer and misrepresents you.

I think this is an unfortunate side effect of boot camps trying to impart best practices on their students. They don’t really have time to learn and apply the actual practice well, but the names stick with them.

Seems like just lack of experience. You can even do it simply with JS with onHoverIn / onHoverOut

While that's possible, it's a lot more fault tolerant to use the declarative :hover rule, than it is to handle it procedurally. The browser knows how to handle odd pointing devices, touch states and won't ever have to deal with uncaught errors in a mouseover/mouseout event.

for sure, was just an example that there are apis, that could have been reached for even without CSS knowledge that would make it easier than trying to get the position of the mouse on the screen, the position of the target element and if they overlap

There is no onHoverIn or onHoverOut in JS.

yeah sorry that’s the react-native equivalent. you could use mouseenter / mouseleave events

I think most of this comes down to the fact that these bootcamps are there to freshly bake people to work on the latest shiny tech completely ignoring the basics of computer science. I, like yourself, was very lucky to attend a university course that gave me exactly those fundamentals.

I worked at a boot camp that started off CS-"heavy" (relative to other boot camps). Unfortunately, they gradually just turned into a React shop to try to maximize profits. There were students who had been in the program for 4 months and couldn't write FizzBuzz. The placement rate was poor because students couldn't do technical interviews. I understand this particular company has made improvements since then (I've left), but it was fucking grim at the time. I now teach at a state university.

But yes, to anyone in a boot camp, get yourself some Khan Academy or whatever you need to get the fundamentals. This is an art, a science, and a craft, and you need to study to show your pride in that craft.

Not always. The bootcamp I worked for did 2 months of pure HTML/CSS/JS and then did a personal project for another month of which students almost exclusively used HTML/CSS/JS, some did React. Only in the final week did I teach React.

This was around 2017, most students didn't become React devs. Most students did end up in the JS ecosystem, but 30% did something else [1].

[1] When I say 30%, that's not an official statistics. It's just on my impression what I've personally seen from students who connected to me on LinkedIn. It's a guestimate at best.

Which part of that curriculum was core CS?

None of it, as those skills were not asked for by the labor market. And I tend to agree with it (as a CS bachelor and master graduate). What you need to learn is programming in a specific way. CS teaches a broad scope of things that are all helpful but they are not strictly necessary to know, especially not as a junior. I think doing a CS degree after having done web dev for 3 years in the field is a much wiser decision.

For example, I never really had to know how a compiler works or assembly, but I know it. I only needed my data structures and algorithms knowledge once. My knowledge of UML? Meh

And so on

You are describing the distinction between a scientist/engineer and a technician. Technicians only need thin slices of knowledge about the underlying abstractions.

The problem with _aiming_ only high enough to create technicians, though, is that you create a good chunk of _operators_, instead, who make do with both thin _and shallow_ slices of knowledge, making them poorly suited to any kind of generalization.

I think there's a place for what are essentially factory workers: taught specific skills for specific jobs. The problem is I think most don't understand the trade-offs and have unbalanced expectations.

For me, coming online in the late 1990s, I've never experienced as much "education density" as I did when learning HTML to build sites on Geocities. For those who didn't experience that, circa 1997, you could either upload files or write HTML in nothing more than a textfield. No highlighting, no WYSIWYG, no page builders. Just you and a blank canvas (if you were lucky you might use an editor like Homesite or HotDog)

It was also a time of DIYing shopping carts in cookies, forums all about getting payments working, and what's HTTPS?

Yeah, I was just chatting with another principal eng friend recently where maybe a whole new generation of programmers may be several degrees away from topics like operating systems, compilers, computer security and networking.

Once in a while, (lower level) software needs to be rewritten as underlying invariants go out of fashion. Think filesystems due to hardware access patterns etc. - to unlock magnitudes of performance improvements. The scary part is maybe we'll never have enough programmers to know how to do "the hard stuff" anymore. I hope I'm proven wrong though!

This is sort of a FUD argument IMO. There will always be people who focus on low level software engineering. There will always be people who want to learn about the hardware of computers much more than the software. Proportionally there will almost certainly be less (we don't need nearly as many computer engineers as we do software engineers) but as long as the salaries remain competitive there will be plenty.

It's not just this but also the fact that there are many more layers of abstraction now than there were even 10 years ago, never mind 20/30/40 years ago, and the real world incentive to understand the entire stack of those abstractions is virtually nil in modern engineering environments.

It depends on the intention of the person trying to learn. When someone is starting and asks to me which language/tech is best to start, I always ask, what do you want from learning tech? Are you comfortable with X salary? Do you want to make a career of it? Go international/remote? Etc.

I had some friends being honest about only wanting some good money, not top high, but in comfortable zone, and preferably fast, in less than a year. With that kinda of mentality, I usually recommend going straight to the most used stack where I live, React, Angular or Java.

They are usually just starting and want to feel the waters, I tell about the basics and link some online courses. Everyone can start on one tech and learn another later.

I myself learned frontend before high school and only had a formal education on software years later on college, and now I feel like pretty proficient on software as a whole. The answer to it, is usually giving some time and experience

We had an intern last year, and I got a chance to do a 1-on-1 with him later on on his time with us. He was looking for some insights from the engineer in the org with the longest career in tech.

The biggest single thing I think I ended up doing during that session was getting him to re-frame his thinking from "I'm a React developer" to "I'm a developer", emphasising how all the fundamentals remain the same, just the nitty gritty implementation changes a bit from time to time. It was interesting to watch that lightbulb moment happening with him as we were talking, while also frustrating that the bootcamp etc. training he'd been through had so fundamentally set his thinking up wrong from the outset (since had a few more interns that came via different bootcamps, and it has been the same story with each!)

And that's why learning is best left as an individual pursuit. For me, it is always best to start with a complex system and then work backwards, understanding the thoughts and decisions that went into each step along the way. When I start with the basics I don't get a feel for the bigger picture and it means nothing.

I'm glad I've only been around the industry for 25-some-odd years. We already had many high level abstractions to work with. If I were old like you and had to start with flipping toggle switches, I'm sure I would have zoned out immediately and never progressed further.

I could handle flipping toggle switches now, but only because I've been engrossed in the bigger picture thanks to those high level abstractions.

I hate to break it to you but if you've been in the professional world for 25 years, you're old :)

Well, yeah, but you'd have to be at least twice my age to have been starting out when this tech was in its primitive state. Comparatively, I'm still a spring chicken.

I think the word(s) you meant to say were ‘properly experienced’ ;)

I have a strange feeling about the industry. It seems better received to know a framework 30% (or enough to make simple/intermediate things) even if you know next to nothing about the underlyings rather than the opposite. If you're an ES6 master but can't mesh well with react tasks / react convos in daily you will look as less useful.

I disagree. It's like telling someone who is somewhat interested in building cars to learn how an engine works before having them on the ground playing with the actual car parts. The issue becomes not whether they'll learn, it's about whether they WANT to continue to learn. Most people when they want to start coding, would rather want to build cool things. And then later on, they'll naturally be more interested in the fundamentals.

I argue that this is why schools are terrible for teaching. They try and teach fundamentals without making kids interested in the topic first. As someone who taught many kids, the struggle is always making them interested, not the rate at which they learn.

I remember when I started programming, the worst advice i got was on stack overflow, that I should learn from this thick c++ textbook as a start... Wasted couple months on that book, where the concepts went through one ear and out the other, became extremely disinterested. Only until someone told me to just learn Javascript and build things was when I progressed and learned rapidly. Took me only a year after that to get a job with me becoming interested very quickly on learning fundamentals from there. If I kept learning from a book, it would've taken me several years before I got to even building. It's silly to assume someone who learns from the top down can't learn the fundamentals at some point.

Now I've learned game development and currently learning ai on the side. I've tried bottoms up learning many times, but it is incredibly slow to get my goals. Top down and learning fundamentals after you get your hands dirty has been the absolute fastest way for me to learn new topics. With bottoms up, while you may learn many of the basics, you also happen to learn a bunch of extraneous information that you may never use, and will forget because you don't use it.

There's space between "read this giant c++ tome" and "you're good to go with a couple of months of React", quite a lot even.

From my experience with bootcamp people, it leaves them woefully underprepared. But my sample size is small: 3 people, 3 separate bootcamps, similar results. They knew one portion of react, no fundamentals.

And sadly a couple of them really took to using Copilot. So they don't know how to do what they're doing and couldn't explain their submitted code.

Just the worst of all worlds there. They were effectively incredibly expensive Copilot subscriptions (not to belittle them, they did that themselves)

definitely.

I just think for some, bottoms up learning has quite some disadvantages and was an approach that I've used for a long time with okay results. It would get me to where I wanted to be...but it takes way too long sometimes.

Of course there are people like you mentioned though who only do top down learning but just never go into learning the fundamentals ever, which is another problem in its own right.

I've gradually taken towards "always learn as if it's a sport" as the approach to learning. Which, if you look at the sports science recommendations is:

* Isolate highly specific techniques into drills.

* Then go directly to practicing live gameplay. Ignore intermediate exercises.

And the approach with programming can, in fact, do this, if presented properly: definitely, we know how to isolate things into short follow-along examples. What tends to be missing is the "live gameplay" element, because it's hard to set up sample projects that are complex enough to reveal the need for a particular technique.

I don't know anyone who has ever learned programming bottom up. Now growing with the technology as it evolves is one thing, but being taught in that manner is miserable because it's unmotivated and the reason for the low level is the high level not the other way around. You just use even handlers in JS and then when you hit some confusing behavior you dive in at learn about how event propagation works.

Nobody learns block how devices work before filesystems because it's backwards. Filesystems are the motivation, block devices are a means. The processors course in college comes after the intro programming and after systems programming.

I love when people say this, because everyone has a different relative arbitrary starting point for the term "basic".

So let's take you, for example.

How far back did you start ? Did you write a basic HTML site in notepad?

Did you program your own TCP/IP stack?

Of course you at least configured the actual Web server using Apache on your Debian vps, right?

See how tired this argument is?

As for me, I just directly manipulate the platters of my hard drive using a magnetized needle to encode sequences of ones and zeros.

None of these things are fundamentals

The opportunity one is really the core. A friend went through a bootcamp. Father of 3. I think this is the most viable option to join the field for him.

So the options are bootcamp or not. Not from the ground up or not. Bootcamps cater thst group. Ideally skilled, smart, willing to learn but on a tight schedule and in need of a job.

This also changed my mind a bit on how to think about bootcamps. They are a way to give people who couldn't afford a longer education on the discipline an entry point.

All the success or failure is still on the person, and there is a lot to learn, but I respect everyone going through the hard path.

Yes you don’t need React for a static site. Is this news at this point?

Also I find the colour scheme hard to read but maybe it’s just me.

> Is this news at this point?

If you started your career in the last 5-10 years then yes, it might be news.

An entire generation of web developers has been trained to think that every app big and small needs to be a convoluted SPA. The results are a disaster.

"A convoluted SPA" is fully orthogonal to React. If you're making a blog into a SPA, that's a you problem. It's been possible (and recommended for many things!) to just bake a static website with React and use JSX as a templating language for a long time.

Why would you need JSX for a static website? If you need JS then it's not "static".

You can render JSX at build-time. So it's just a templating language, as the parent comment said.

React is completely happy to spit out a DOM tree as HTML for you; wiring up the in-browser JavaScript side of React is optional. This is how static site generators like Gatsby or NextJS work (with some hacks that as a user you don't really care about) and (eliding some detail) how React Server Components now work generally. I've also used it to generate email templates[1] with some success, too.

I use JSX because it's a nicer templating system than EJS or similar. It allows me to write components to encapsulate reused fragments rather than text manipulation. And I like it, which counts for something.

Candidly, this is something that people who fulminate about React probably should know before they start talking.

[1] - https://github.com/eropple/rx-mailer

Obviously there's a spectrum. A static website just means the files are served statically from a folder, and routing is just the folder path. You can still serve JS files and have a static website. If you put an alert on a button, you're not suddenly a SPA

It's more than that: you can just call methods in ReactDOMServer to get a DOM tree. The tools to wrap this vary widely; you can use Gatsby (ehh) or NextJS (yeah!) to do it if you want a full-featured framework around all of it, you can use something like react-snap if you want something simple and less all-in, or you can just call them yourself and plop some files in a build directory.

Generally, a static website refers to any website where the server just serves files rather than running application code for each request. JS runs on the client.

For example, I've been working on a character generator for the Inquisitor tabletop game. It's completely static because I just SFTP the build output to my webserver, but it uses React and JSX.

You're missing OP's point. The website can be fully static (even without any JS) but you could still use JSX/React to generate it (during build time, not runtime).

If you've ever had to build a static website from scratch, with the same navigation, footer etc. on each page, and without using frames, then you'll appreciate the amount of work that a templating engine saves you (whether JS-based or else).

I think you all missed GPs point, JS is barely required, let alone an SPA framework, let alone static generation in an SPA framework, etc.

And you're missing the other GPs point. Even when building a static website, you might want to reuse components. Or use shared components. Or do some logic. Or easily compose things.

Note they said "JSX as a templating language". Why worsen the experience using Python + Jinja when you're just building a static site.

Mm, herein lies the problem, I was not thinking about Python at all, and I suspect we are all thinking about various different tools.

A static site is necessarily not dynamic though, as soon as you need dynamic features you need to reach for one tool or another. "Static site generators" are just dynamic sites with a pre-compile step instead of JIT.

When I think of a static site, I am thinking HTML, CSS, some server side includes for header and footer. A bit of vanilla JS if you absolutely need it. Apache and nginx both have native template includes so you don't even need an extra language like py or php.

A static site to you requires a server generating files? A static site to me implies the assets can be dumped to something like S3 and you're done.

So if you wanted to say, pre-generate those pages with the header and footer already there, you would ... ?

No I was saying the opposite, a static site is necessarily not dynamic.

I would not want to pre-generate those pages. Your static files on an S3 bucket are still served by a webserver.

Anyway, can you honestly say, hand over heart, that server side rendered JSX or React is a robust and simple solution comparable to SSI or I don't know, a bit of copy pasting? Of course not. Server side rendering is a complex toolchain that will rapidly and constantly deprecate. My blog has been sitting on the same "stack" for 13 years, takes me 5 seconds to set up a new post.

I have worked on countless JS projects, sometimes they don't even build just 6 months later without faffing about with packages and versions.

Yeah at this point I have literally no idea what you're talking about?

The thread is about pregenerating static content, "can you honestly say, hand over heart, that server side rendered ..." is way off base. Seems like"static site" means "assets can be plopped into any server that can serve static assets" to one set of people, and to others it's an invitation to balk?

I'm in the former camp, if that wasn't obvious. If you want to talk about serving static assets to host a blog, I'm down. If you want to compare server stacks, I'm out.

Yeah I was going to point out this is getting pretty obtuse but didn't want to be rude. I think we're talking past eachother, or I'm missing something.

My TL;DR I guess, pregenerating/SSR, is a more complicated toolchain than is needed for a simple site (and what I interpreted the topic comment's point to be). How you serve it wasn't really the issue, that is the easy part. I might leave it at that, cheers for being gracious.

Static doesn’t mean no JavaScript. Usually it means it’s not rendered on the server.

Every time i start making a static website, i end up needing to include a table (or some other structured display of data) and then just switch to JSX to render the data with a loop. Sometimes i then render it as html and deploy, and sometimes i deploy it as react. But that’s how i usually end up using React even when static.

Indeed, static just means that the site files can be on a CDN and not need to change. Technically, SPAs are also static, if they spit out pure HTML, CSS and JS files that you can put on a CDN.

You use JSX the same way you'd use PHP - it just compiles into HTML. In this case, you just save the output after compiling it once. (as you can with the dozens or hundreds of non-JS options that do the same)

Because they only know JS and it’s ecosystem.

It's also been possible for 30 years to do the same with languages like PHP, ColdFusion, etc, no build steps necessary, and HTML is your "templating language".

You totally can, but for my money that's kinda not great. Because HTML isn't your "templating language", PHP et al are, and you aren't templating around the DOM with typed objects, you're templating around text with all the pitfalls that entails. Object structures save time, reduce errors, and give you more to-the-programmer natural tools for composition and reuse (just call a function that returns a JSX object! give it typed parameters! declare victory and go have beers!).

I wouldn't go back to doing text manipulation to generate HTML, because I value not having to make sure I've escaped all my quotes.

PHP, ColdFusion, etc allows you to intermix HTML and variables without doing the type of escaping you're describing.

For instance, CFML:

<ul> <cfoutput query="people"> <li>#firstName# #lastName# </cfouput> </ul>

You can also write classes that return data and custom tags that return rendered html.

<cf_PeopleList queryObject="#people#">

I'm not saying we need to go back to those languages necessarily, but I think there's a ton of misconception about how those languages can be used, and quite a bit of reinventing the wheel in the Javascript world.

Sure, of course you can in some contexts and with many asterisks (though in PHP it is literally text munging and that's what you get).

But even, granting your correction: in the CF example you're writing representation and logic in two separate contexts. JSX does not do that. JSX is JavaScript and the constructs that JavaScript provides work without fail with the constructed trees (which need not be DOM trees, e.g. react-three-fiber) you're generating. It puts a lot of strain on the assertion that you must-repeat-must separate these concerns, which hasn't been materially true really at any point in my career all the way back to JSP or Velocity templates where (much like ColdFusion) you had worse tools for one context than you got for free with the other.

While JSX and something like CFML (or hell, Angular) look similar when you squint, this is a different thing. The closest equivalent is something like Scala or Visual Basic XML literals, which never took off; JSX is no-bullshit a step change in consistency and productivity and it's awesome.

Sure, I like TypeScript and componentization though which JSX can give me where PHP doesn't. Most templating languages are dynamically typed.

PHP pages absolutely have to be built/rendered.

I think the distinction is that PHP is interpreted in real time most often. So there is rarely a separate build step.

It’s a build step that happens every time the page is loaded instead of once when it’s deployed.

Then arguably JS is worse, since any 'build' steps preceding it don't bypass the (client side) interpreter either. Except perhaps if WASM is involved.

That's not true, though; JSX can be entirely prerendered server-side. If you don't write client-side JavaScript, you're not going to get client-side JavaScript (modulo maybe a thin hydration layer if you're using particularly old tools, but nothing running pervasively). Your code becomes HTML files. It's more Hugo/Jekyll than it is "a SPA".

I am unaware of a major PHP framework that is designed around similar, though it may exist.

JSX SSR would be in real time again, correct?

If you mean rendered once for all, i.e. statically, there are some PHP wikis, frameworks, and caching plugins that can/do work that way.

You think they would have discovered Flask or something similar just out of personal curiosity.

I think a culture has been created where anything resembling server-side rendering (other than Node spitting out JSON) is legacy to be avoided ..... until of course the Javascript creates its own convoluted version of server-side rendering, which is revolutionary and the new hotness.

I'm not really in webdev, although I still do django sites for people sometimes, amazed and glad I had no idea that's how things had gone.

The main benefit to JS being used as a server side rendered and client side rendered language is that you have a lot more control over which parts you want on the server vs the client, and you can introduce hydration where needed. You technically could do that in PHP and other non JS languages but that's annoying because you'll be mixing multiple languages together and it would be more clunky. So yes, there is some "revolutionary" benefit to having everything in JS/TypeScript.

My least favorite JavaScript argument is “Instead of using one good language for the backend and one lousy one for the front end, we’ll rewrite ALL the code in the lousy language to keep it easy!”

I fail to understand why anybody would use JavaScript - a language so bad everybody uses a series of wrappers around it - for anything they didn’t absolutely have to (e.g. client code).

The entire point of the MVC architecture is to allow you to pick the best tools for the job.

EDIT: I’m not saying PHP is good, though it’s better than JS. And TypeScript is still JavaScript with extra steps.

PHP is a good language? Lol

TypeScript is an excellent language and I agree, no one should be using Javascript anymore.

PHP is a good language nowadays. Much better than JS. Also, Jimmy Hendrix is dead.

I mean, Django makes it very clear and very trivial which parts are serverside and which parts are client side, and I assume rails is the same way. I don't see how JS has any advantage over their approach.

Aren't those just the server-side components from React?

They won’t touch anything that isn’t Javascript.

I like the colors. It's readable for me and it reminds me of sherbert.

edit: hm, she says it's a yaki imo / satsuma imo color theme. I love yaki imo.

You don't understand, it's the future !

https://www.bitecode.dev/p/hype-cycles

It's not just you.

The site has poor contrast ratio - fails all accessibility guidelines for text contrast ratio requirements.

Really? Firefox says the contrast ratios meet WCAG AA.

For me, the main problem is the font weight. I'm sure it looks better on high-density displays, but it is way too thin to read comfortably at a regular pixel density.

Which extension are you using?

I use a tool called CCA and it takes font size into consideration.

I'm using the built-in Firefox accessibility pane.

I checked with other tools and yes it does pass AA for normal text. I'd still increase the contrast ratio.

I use a high resolution screen and the text is rather small - hence why it's harder to read.

On mobile it's OK.

I use React for static sites and really enjoy it.

* as it’s simplest, it’s a really easy to use templating tool.

* there are a tools that compile to mostly static HTML, so not performance hits

* theres almost always something that pushes you to want some JS. React is handy to have. It also opens the door to all of the the community packages. No sense to re-invent the wheel.

Curious what you mean by “almost always something” that makes you use JS?

What besides shitty/illegal tracking code and cookies do you need to include? Honest question.

In my case, we wanted to gather feedback on a product we were launching. Because we wanted to move fast, we’re in a regulated industry, and our initial tests were simple, we decided to built a simple “chatbot” style feedback tool.

More generally, forms. Forms always seems to morph into more than just simple inputs.

Thanks for the reply, forms are such a pain in the ass. Of course you need hard input sanitizing on the backend but just helping people fill out a form correctly can require some JS.

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.

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.

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.

Ditto on Ember, React, Vue and Elm. Was a jQuery minimalist, nut now moved on to Haxe-HTML5. Yes, it compiles Haxe to JS. But the JS it generates maps back to the Haxe very simply, and it's straightforward to debug in Chromium dev tools. There a nice declarative XML system for widget layout. It's up to you to choose how much you do declaratively, and how much in .hx code.

I'm confused by this, why do you think npm is needed? It just acts a central repo, you're free to self host the JS file yourself or pump it through a CDN.

Jest is a different story, it's not a single JS file and has many dependencies. Running it globally is an easy way to reduce the need to include it per project.

People use package managers because it lets us find everything in one place, install it and keep it up to date easily.

I'd much rather do `npm i whatever` than having to hunt down a bunch of git repos and copying files over and when they're outdated having to do the same thing to update them etc.

I think this is a pretty awesome statement. I'm always unreasonably pleased when I see a web page that embraces appropriate simplicity.

> 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).

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).

> I'm only using these 2 lines of Javascript to add the current year in the footer copyright tag

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.

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.

> 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.

In this case I think I'd argue that the JS solution is the most simple to implement+maintain.

This is what Js is good at. It sucks for building actual systems but it's fine for small stuff

There's zero need to set up babel/postcss/SSR. Those have all been handled by frameworks for years and years.

Is it even correct to automatically update the year? Shouldn't the year be whenever the work was created or revised? Which could be set at build time.

Another advantage of setting it in the build is it'd show even without javascript. If I disable JS, no copyright statement at all appears on the page. So if it was really necessary to declare your copyright, then would it mean anyone who disables JS can freely infringe?

I agree just leaving the copyright out of the footer would be best.

I am of the opinion that what you are suggesting is correct. You don’t want a programmatic copyright because you want the copyright to reflect the date created as that when the right begins, and it continues from there without need for refreshing.

I think it's also incorrect because it's getting the date client side. so it would just display the local client's year, not necessarily the correct one.

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.

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.

It’s not a value prop, it’s just a statement of remembering to use the right tools. You even mention this yourself, just not explicitly, when you say “react app” and “vanilla site”. They serve different purposes and I’ve worked with many people who do not understand because react is all they know.

Remix is an improvement over react as a framework though because you can fall back on native browser functionality where the framework will fall short (high latency, slow devices, no JavaScript).

> remembering to use the right tools

100% agree here. But if I were going to rewrite a whole application, I'd need a really good value prop.

> high latency, slow devices, no JavaScript

I don't see why high latency would be improved by remix, you're still fetching everything it's just without the waterfall. I've yet to see a modern-ish device (going back to iPhone 7s) that struggle so hard with rendering that progressive enhancement is valuable.

Are there modern devices which are that slow? Or browsers without js?

> you're still fetching everything it's just without the waterfall

It's exactly because of the waterfall. If I have to make 3 roundtrip fetches, and the latency of each is increased by 150ms, then eliminating 2 subsequent fetches will save me 300ms.

> I've yet to see a modern-ish device (going back to iPhone 7s) that struggle so hard with rendering that progressive enhancement is valuable.

I have used an uncountable number of websites that are extremely janky, slow to load, and overall unpleasant to use on mobile while traveling on trains and busses between cell towers. Some of that can be attributed to ads but the reality is you don't need SPA's to serve news. Remix is cool in that it lets you develop like an app but serve like a website.

> The overhead involved in building a react app is nearly nil with all the tooling we have.

All the tooling we have is exactly why React has an overhead which is far from nil. Every package goes through a period of changing its best practices, some go through multiple. Entire packages go in and out of season, seemingly depending on the phase of the moon. There's a new bundler every year, each with its own quirks. For some things there's 4 "go to" packages that achieve the same thing but take a different path to get there. You have all these packages and tooling you have to learn, stay in touch with, maintain and fight against. All of that so you could ship megabytes of JS that ultimately just changes some text on a page. You can do all of that with vanilla JS and spare yourself the headache.

It takes work to keep up with the latest-and-greatest in modern web frameworks. 100% agree.

But if you're already doing that, because you work in the field, or are passionate about it, then that checkbox is ticked.

I wouldn't do all that JUST to build a static portfolio, but if you already learnt and kept up with all of that stuff, then I still don't see why not use it.

Because in a professional setting the guy who takes over after you also has to know or learn whatever tech you chose.

I worked on a team maintaining solutions in React, Vue, angular, Svelte, JQuery and more. It sucked. Basically every task I ever did there was my first time doing that thing with that framework.

I totally agree, simpler is better. Except for extenuating circumstances, teams working anywhere remotely close to each other should aim to stick to the same technologies and practices. If that's vanilla js, sure, go for it.

I'm not arguing everyone needs to move to react. I'm saying the opposite. Stick to the tools you know. I once worked in a strict java-angular.js shop, and it was awesome. Everyone was familiar with the tech and the company saved energy otherwise wasted on tool-related decisions.

My point is this

> it is more of a flex in this SPA era to show you know how to make a website the old-fashioned way.

is not valuable to me at all. If I were giving advice to a new programmer, I'd tell them learn the basics first, like your html, js, css, and then familiarise yourself with one of the frameworks. Then if you want to build your portfolio, build it in whatever you like, but for people at that level, it can be a great chance to practice and show off their skills to employers. If you're shipping 2MB, who cares.

Strongly disagree

npm install -g vite

vite init my-react-app

npm install

npm run dev

The most popular build tools have mostly stayed the same. Some things have fallen out of fashion sure like gulp. But overall the abstractions built over complicated tools have only improved and only made it easier to get started with web dev. I’d argue it’s never been easier to start a modern statically typed react app.

Many of the comments suggest that of course you wouldn't use React for a blog.

Someone forgot to tell these folks:

https://buttercms.com/blog/how-to-create-a-blog-with-react/

https://www.sanity.io/guides/build-your-first-blog-using-rea...

(and many more)

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.

Yes this is correct. It’s perfectly possible to build purely static website by react and nextjs

NextJS really does feel like a featherweight React in all the best ways

I love React as a templating language. I find it very easy to use since JSX is very close to actual html.

Recently tried no framework, Jekyll, Next, Astro and finally SvelteKit. The only one I liked was SvelteKit.

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.

Jumping on the React hate train has become a trend these days, but it still has its place.

Shitting on React is one of the easiest way to reach the HN frontpage.

Of course it has its place. Not for a blog though, it makes no sense

You can achieve very good results with Next, by using SSG, SSR and ISR. That implies being very comfortable with React. Otherwise there’s tons of solutions for a blog scrnario.

It doesn’t really matter what you write your personal blog in lol I’ve created some egregiously over engineered personal projects over the years just for the sake of learning a new technology

It has its place, but there's no shortage of React sites where it's misplaced.

React hate train has its place indeed.

* [...] brought to you by vanilla everything. No Javascript frameworks, CSS libraries or flashy animations. [...] *

Proceeds with a distracting animated image of the old portfolio, thought that was funny.

But not flashy! :)

React is a great tool for building complex, large applications. Your blog is not large or complex.

It's barely even an "application". The entire thing could be rendered as static HTML.

Even many sites that are large and complex would benefit from being a server-rendered app. I've come across way too many sites that break in bizarre ways, and all they are doing is displaying text or HTML forms. Every time I check, they are React or Angular sites.

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.

React wasn’t created because JS is slow, but rather to streamline and speed up DOM operations.

That statement indicates you don't know why react was developed.

> That statement indicates you don't know why react was developed.

Why was it developed?

Hint: it was not because the performance nor the JS language limitations. You can google the rest.

I am friends with the original 2 React founders who I met at facebook. I don’t need to Google, I’m asking because the comment was lacking substance and wasn’t adding value to the conversation.

I find state management to be much easier with React. "All state is lost by default when any variable changes" is a fantastic starting point.

Author made a two page static website without React. Okay? Congrats?

Actually, yes. The conventional wisdom these days is to do everything in React (or something similarly bloated).

Because, you know, users just love seeing a bunch of grey boxes shimmer and dance on a white background for several seconds before the magic really starts to happen.

So any exercise which demonstrates that there just might be an alternative to this philosophy should be applauded.

I don’t think this is the “conventional wisdom”!

I've just joined a team recently and had a chat with the head of product. We will work on a tiny internal app, it has 3 pages: sso login page, Excel template upload page where earlier uploaded templates are shown as a card and if you click on them it opens a dashboard: a map with markers, a bar and a pie chart. This is the whole thing.

This guy asked what we will use in the front-end. I said react and he was like "amazing, good job, it will be great" and the talked about we should always use react. So yes, there are places where react is used without question.

Also, we will use snowflake as a backend while indexing would make everything a lot faster and the budiness logic is done by 800+ line sql (stored procedure).

It's been the conventional wisdom at every company I've worked for in the last ~5 years, and I hate it.

I ranted about this in another thread a few months ago and I stand by what I wrote: https://news.ycombinator.com/item?id=34857513

> users just love seeing a bunch of grey boxes shimmer and dance on a white background for several seconds before the magic really starts to happen.

This has nothing to do with React, this is a placeholder rendering strategy employed by many different frameworks and languages.The rendering strategies are orthogonal to the framework.

I've written many websites entirely in React but you'd never know it, because they're all SSG. I've done hybrid SSR + SSG + placeholder/delayed load.

I could have done all of that with .NET, Elixir, etc. too because it has nothing to do with the language/framework.

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.

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. 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?

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.

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

While the paperfuge is cool and may even reach higher RPM/G than some bench top ultracentrifuges, it cannot do so consistently.

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.

Before that I had a Phoenix site and I feel like every time I touched it (months apart) I had to update something.

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.

Can I write a React app and recompile it as a vanilla? For example to take all involved parts of the library and not take the rest.

That doesn't really parse. React as a thing is some pretty thin DOM manipulation and some helper stuff. Are you thinking of something like Next or some all-in React+Redux stack?

As misfortune would have it, I spent a significant fraction of the day reading the implementation of hooks for fibers. There's nothing light weight about virtual Dom, reconciliation, and micro task queues.

You mean a normal react build?

This is what Svelte does, React has a runtime even when bundled

Is that like Astro?

It's a portfolio, is js really necessary?

Javascript is the new Python in many shops.

So while one doesn't have to know JS, it will definitely get you through a lot of doors. And not knowing it, or being too stubborn to keep your skills in it polished will keep you in the doghouse.

> My portfolio needs to be nothing more than the HTTP equivalent of a tri-fold brochure.

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?

I could see a thin red tube (or maybe two half-tubes) which marked a sort of diameter line across the cardboard disc. For separating blood to get a concentration of plasmodium cells for quicker identification/diagnosis it should be enough?

Unrelated note, but I had never heard of the paperfuge, thanks for teaching me something new!

I like using react from a cdn and rolling it out when needed - kind of the best out both world

A company I used to work for used react to build the app, and Wix for the site.

No, React with webpack/vite is simpler than "your handcrafted static site generator".

I don't have to use any of Hugo, Jelkyll,..., because i can cook my own SSG toolkit right inside React.

Pug is the most disgusting piece of sh* to ever exist.

Reply on news.ycombinator.com