Answering as the author who also understands the fundamentals of all of the technologies involved and questions much of what goes on in the minds of today's web developers and designers--

I use Make as the standard way to interact with every repo I own. This allows me to type `make build` instead of `$some-language-specific-command-I-forget-in-2-weeks`.

I use Docker for distributing every app I build. If the app is a website I also use the nginx base image. Docker images make packaging and distribution a breeze IMO.

Regarding yarn, npx, react, and jest: I'm similarly disillusioned by the churn but I also like to remain knowledgeable as the industry evolves. React was something I hadn't touched before, so I decided to pick a simple project to give it whirl ;)

But now you’re paying for keeping a server online, whereas a GitHub page could’ve hosted this static website for free.

He did this for fun, his motivation wasn't to find the cheapest way to host his content.

It's also not like you'd have to have a separate server/vserver for every such project, a very affordable vserver will run quite a lot of nginx containers. Plus I guess some people will have a vserver or something like that anyway (I have a small one to get around NAT at the ISP level), in which case it might be net-zero.

>get around NAT at the ISP level

genuinely interested in the benefits of this. care to share?

My ISP puts everyone behind some sort of NAT, which means I can't reach my home network from elsewhere since I can't open ports. They'd let me buy my own IP address for a monthly fee, but I've found that an old Pi I already had, an autossh-ed reverse shell, SSH forwarding and a cheap cloud instance work just fine for checking sensors and the like, cost less and the cloud instance has other uses, too.

I see, so NAT traversal over SSH as opposed to VPN/DDNS

I honestly don't understand where's the fun in using docker for anything.

Unless one is into masochism.

Especially to host what could be implemented as a single static HTML file.

React is compiled to static content so this could be hosted with GitHub pages too

I build static sites in Docker too. But then simply extract the built files out and upload them to any static hosting I need.

This allows me to self contain all the build tooling. And allows other developers to setup a dev environment in a few easy steps.

There's no reason that this would have to be hosted on a traditional server.

Free as in beer, yes

> I use Make as the standard way to interact with every repo I own.

After much fussing around with many kinds of solutions, this too is what I have settled on. Download repo and run `make` will "do the needful" to get you going, and all the major entry points are make stanzas.

except that "making" anything, or any commands in a new language he forgot, etc = entirely unnecessary for a single static html page.

> I use Make as the standard way to interact with every repo I own. This allows me to type `make build` instead of `$some-language-specific-command-I-forget-in-2-weeks`.

I also used to do this until I switched out Make by Just[1]. I find it worth a recommendation.

https://github.com/casey/just

Just like perl and grep, I stick to make because it's likely to be already available everywhere I need it. Such is the tyranny of the installed base. :/

I second this. “just” is like make, but without the extraneous/confusing parts.

make all and make run would be more standard, no?

I liked your page. I might even use it!

People love to constantly say "Want to learn to code? Make projects! projects! projects!" and then when someone makes a project as a means to learn a particular technology, now people turn up their nose and say "ew, why did you use this?"

Anyway, this project provides exactly what I needed. Thanks to OP for sharing! Slick and simple

Make a project -> learn to code

Share a project -> get opinions on it

What's the problem?

It's fine to criticize, but it's very likely "release wificard.io" was a bonus on top of the main goal of "learn react, nginx, docker, jest", so the author could have used simpler technology if it weren't for their objective of obtaining hands-on experience.

There's a simple explanation: people in this context refers to separate groups.

Sure but if you want to learn a specific technology by making a project, it makes more sense to make a project that can actually benefit from that specific technology.

> and then when someone makes a project as a means to learn a particular technology, now people turn up their nose and say "ew, why did you use this?"

Why post your learning project on HN then? You advertise and get free critique. Double win in my book. What's wrong with that?

Many of these are not critiques, but rather not-so-subtle implications that the author must either not know what they’re doing or is trying to show off.

A lot of developers only know the new, needlessly complicated ways of doing things. I have met professional software engineers who have never heard of shared web hosting, for example.

It's also surprisingly possible to learn enough about programming to get a job without understanding basic computing concepts. I've met professional software engineers, with multiple years of experience and promotions under their belt, who did not know the difference between hard drives and RAM in a server context. I've literally code-reviewed attempts to deploy a database server with 1 TB of RAM in order to store 1 TB of data.

No, how can you not know the difference between RAM and disk in a server context? What sort of programmers are these?

I know the different between RAM and disk in a server context (what sort of programmer wouldn't?!), but I've worked pretty exclusively in no-persisted-storage environments (mostly Heroku) for ~5 years now, where referring to "saving" files/data outside of a DB context almost exclusively means "save to memory" and I routinely run into problems whenever my stack requires downloading any sort of third-party library that would have to persist outside of RAM (e.g. downloading NLP libs).

When you abstract "storage" into "my library/tools save state somewhere" (and god forbid you include localStorage into the mix!) and don't deal with the hardware itself, I could see how a lot of new-ish coders wouldn't be able to differentiate RAM and disk.

Thanks for the great explanation! I haven't messed with Heroku myself. Might be a sign I'm getting old...

I thought that was crazy, but reflecting over my CS education they haven’t gone over the difference between disk space and RAM. I suppose they figure everyone already knows?

I think that's why Scott Hanselman started this series https://www.hanselman.com/blog/new-youtube-series-computer-t...

You sure you didn't have a computer architecture course? Most CS programs it is a required course

I did (actually it was last semester) but they didn’t do basic definitions, it came with an assumption you knew what the parts of a computer were.

That's unfortunate. Luckily there are tons of good resources online like OSSU https://github.com/ossu/computer-science

What is a required course?

In American terminology, individual classes are called "courses". This particular course is likely "required" as one of the steps in a Computer Science "major".

a required module of a course

It could be meant not in a way of "this is ram vs this is disk", but "we have a 1tb dataset, what kind of a server do we need?", and the person not knowing enough about databases to think they need 1tb of ram to be able to run it.

But can you really be, let's be modest, around the baseline of developer competence not knowing the difference between RAM and disk space?

Hard to believe to me.

>A lot of developers only know the new, needlessly complicated ways of doing things.

Yeah that was inevitable in an industry that moves quickly, likes new stuff, and prefers fast, superficial learning when that's all you need to get your product out of the door. Google and StackOverflow are probably controlling a decent chunk of decision making these days such that you don't need to think about solutions too much.

If I had done this project it would probably use node.js + gulp + sass + pug + browserify + babel + bootstrap ... or maybe Webpack instead of gulp and browserify (depends on the project).

Why? Because I have a website template that solves many things for me, like:

- I see no reason not to use SASS or the latest ES even though I know how to. Or pug, for that matter... which I like. I also have a SASS template with some utilities and a particular code organization.

- Using an ES bundler allows you to throw in libraries from npm. I would not write the QR code myself, for instance.

- Automatically watches sources and recompiles.

- Adds hashes to asset filenames in order to cache-bust changes in CSS/JS/images (critical when using a CDN).

- Has placeholders for things I'll probably need, like the metadata for building previews in social networks.

- Is prepared for dealing with i18n, if the need arises.

- Future-proofing, since 80% of projects you think are small end up becoming larger. This is a single-page site, but if I wanted to publish this in Europe it'd already need two extra pages for the Privacy Policy + Impressum... so the single page site suddenly needs to worry about navigation.

- It's prepared for quickly deploying to AWS or Github Pages. It could be quickly tweaked for working on Cloudflare Pages or other hosting/CI environments that do the compilation for you.

And most importantly...

... my stack does not negatively affect the end result. All the extra baggage is just part of the development environment. If you want to skip my tools, they're quite easy to bypass and replace for any other transpiler... or you can just ignore my sources, reindent my compiled files and work on them directly.

PS: Back in the 90s I drew complex table layouts on graph paper, typed them down with vi, and ftped them to the hosting. I'm well aware of the alternatives. My current workflow + templates + helpers are based on the need to efficiently juggle A LOT of completely different projects every year as a freelance developer.

> All the extra baggage is just part of the development environment. If you want to skip my tools, they're quite easy to bypass and replace for any other transpiler... or you can just ignore my sources, reindent my compiled files and work on them directly.

This might be technically true, but is not true in any meaningful sense if another developer ever has to work with your code. They will have to deal with all your baggage, and their job will be much harder because of it.

If "you have to make it easy for third parties to fork your website" were a requirement in a particular project, I would still use the exact same stack but output non-minified pretty-printed code to some subdirectory that will get commited to the repository... so they don't even have to run "npm install && npm build" if they don't want to or don't know what npm is (although the README in my template provides these instructions).

... but I would still get advantages in terms of speed, maintainability, etc. from using a modern web development environment that I see no reason to give up. There are things like cache-busting hashes, linting, splitting js code in modules and using variables in SASS for things like colors, that to me are mandatory in a professional practice.

> "you have to make it easy for third parties to fork your website"

That's not the requirement I'm talking about. It's "multiple developers you don't know, of varying experience levels, will work on this project over the course of years".

They're going to clone the repository and have to make changes. Ignoring your stack is not an option. They have to figure it out, or throw it away and rebuild something else.

They'll be the ones paying the time cost of all the advantages you get by doing something complex but easy for you.

You may say this doesn't apply in your situation, and maybe right now it doesn't, but it almost always happens in any successful project eventually.

I'd much rather work on projects that used as many standardized common tools as practical to do the job, versus a project where someone did some kind of code golf to try and use as few tools as possible to save some negligible amount of server space or bandwidth. I'd expect it would be much easier generally to find other collaborators for the first type of project too.

I often choose simple, useful projects for learning new technology… i can’t learn something new if I am not using it for something useful, but I also don’t want to try to learn something new WHILE also solving a challenging problem… so something simple like this is a great sweet spot to learn new tech.

Developer experience? Learning project? For fun?

If the maintainer is comfortable using that technology, let it be. No need to rain fire on it.

There's a lot of that around here

This app seems its using create react app, so agreed the app might come with a few extra things that you might not need. However, there are a few reasons I might choose CRA over static HTMl. Don’t get me wrong, HTML is great, but the developer experience can be primative.

Here is why I like using CRA for some projects:

1. Live reload. This comes for free with CRA. Makes dev work easy.

2. As easy as installing a component and getting started. And they logically fit in the code flow. Native import libraries, you have to write the JavaScript and point em to your divs and dom and initialize em.

3. Let’s say in the future, I want to reuse the code logic in a different app, I can just take the js and element as one unified component and move it across.

Tbh, for an app like this, after doing a production build (npm run build), I don’t think it’d make a radical difference in performance with raw html or react. Might just be dev preference, and ease of use.

Docker with nginx because that’s your delivery pipeline. It’s much more common to have a place to run an OCI container than a directory to upload static HTML. CDNs operate on this model but there aren’t many turnkey “on-prem” solutions. The tooling to run a container and get it hooked into your web tier with routes is actually the easier path these days.

Edit: More

The reason for this model is that it makes everything the same and your caching tier is the great equalizer. Everything is a backend for your caching SSL terminating reverse proxy. And your static site will live in the cache for ages so once your cache is warm there’s no real performance hit.

I can't speak for the poster, but sometimes the fun is in using tools you know.

I don't know VanillaJS that well, so I took a stab at the same concept:

https://q726kbxun.github.io/qrcodes/

Not nearly as pretty, since I know even less about making pages pretty, but still, a fun little stab at making such a site.

I'd say that a tiny amount of CSS would make that basically perfect for the task, except that it's honestly already perfect for the task now. Though it looks like you replace semicolon a second time instead of colon in clean.

Ahh, right you are! All fixed.

Would be nice if the code was in an image I could save.

Just pushed a small change to make it use images instead of a canvas so you can save the image (at least with the browsers I tested with)

What browsers don't let you save a canvas as an image?

The same reason I take a massive V8 engine attached to a massive truck bed one mile over to my friend’s place to watch England lose at the Euros. Turns out that sometimes, even when tool X isn’t the best at the job, it’s way better for me to use what’s at hand.

This is what a lot of people have trouble understanding: sometimes the best tool for the job is the tool you’re best in.

Evidence? No one has made this static website you’re talking about. It doesn’t exist. This one does. The imperfect app that exists beats the perfect app that is vapor.

> No one has made this static website you’re talking about. It doesn’t exist. This one does. The imperfect app that exists beats the perfect app that is vapor.

Another poster whipped one together since this was posted, because it's so trivial to do with vanilla tech:

https://news.ycombinator.com/item?id=27804490

I also don't think anyone has a problem with someone who says: "I dunno, this was just the way I learned and I don't know the underlying tech."

But that's usually not what happens. Instead, there are endless rationalizations for why the obvious over-engineering is not only okay, but preferable.

No, that’s not the best tool for the job, that’s just the most convenient tool for the job.

This is the part engineers don’t get. Speed is an engineering feature. The most convenient is the best if it’s faster.

It’s the Rube Goldberg style of software development? Didn’t you hear? It’s super popular with the kids!

Made a simple page here https://news.ycombinator.com/item?id=27805746 to see how this would look

Probably to learn those various technologies. Not only did they use a bunch of new tech, they made something other people can use in the process. Better than making a bunch of throwaway code.

Of course, why write 50 lines of throwaway code when you can write 500?

Single static HTML files are under valued.

To be slightly snarky, because the author wants to record your WiFi and Password.

That it was a learning project, ok. I guess.

What motivates you to use a feature rich browser on an OS with graphical user interface running on on-premise hardware including your own internet line and all those peripherals if you could just use CLI from a good old VT100 hooked up to your nearest mainframe to HTTP POST a comment on HN?

Yeah, probably because nowadays you just do it like that.

Ease of distribution and sandboxing