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 ;)
genuinely interested in the benefits of this. care to share?
Unless one is into masochism.
This allows me to self contain all the build tooling. And allows other developers to setup a dev environment in a few easy steps.
I also used to do this until I switched out Make by Just[1]. I find it worth a recommendation.
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.
Anyway, this project provides exactly what I needed. Thanks to OP for sharing! Slick and simple
Share a project -> get opinions on it
What's the problem?
Why post your learning project on HN then? You advertise and get free critique. Double win in my book. What's wrong with that?
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.
Hard to believe to me.
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.
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.
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.
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.
... 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.
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.
If the maintainer is comfortable using that technology, let it be. No need to rain fire on it.
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.
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 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.
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.
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.
Single static HTML files are under valued.
That it was a learning project, ok. I guess.
Yeah, probably because nowadays you just do it like that.