Nice, but, do you really need Next.js and React for that? What about just taking screenshots and linking them to the sites in simple HTML? Wouldn't that serve the purpose?
I guess you wouldn't really call that an 'app', just a page. But it'd be pretty quick and simple. And if you really want to get away from over-engineering and getting lost in the code details, doing it without any code at all is a good exercise.
Perhaps from there a simple script to take a list of URLs and generate the page's HTML, but still no libraries or frameworks. Scripts like that can live for many years, just being run as needed, serving their purpose with no maintenance or dependency or deprecation issues. Some scripts that I wrote are still running perfectly fine on their own, untouched after 7+ years, while the main application requires a whole team of people constantly maintaining it.
It's good sometimes to get back to basics to put things in perspective.
Things like the leftpad debacle of 2016 should make us think about how we build complex, fragile ecosystems that are constantly changing, and need constant maintenance, often to just do something simple that doesn't need all that complexity in the first place. How simple and quick can you do it? Do you really need code to dynamically scroll down to thing X, or could you just put that thing at the top to start with and not need any code or dependencies?
You're on a good track. We over-complicate things a lot.
Any builder is 10x as productive when working with known tooling. Meanwhile, tooling that even makes you 5% more efficient is very rare. So the OP is very right in his technology choices.
I've seen a COBOL+assembly team run rings around teams with more modern tooling, producing guis that, while ugly as hell, were more productive than a modern HTML based interface. They know their tooling and business inside out, and that more than offset the fact that their tech was 50years stale.
Yeah I spent half my internship in a acquired COBOL shop, the thing is not all cobol is created equal and theirs was the sum of all evil (old debt, old code generators, less old 4GL transpilers, eclipse pluging glue code).
I'm more interested into people from that era doing lean and mean apps. I've seen a few instances of AS400 and COBOL programs that gave me more joy than anything the web ever produced. And I assume Parent was talking about people doing similar things.
This can be misleading. Most local banks aren’t using the type of technology the bigger banks are, because those smaller banks tend to run on banking-as-a-service platforms. So the smaller banks are often essentially just proxies to larger ones.
Yes, I'd call it a site as well, not an app, my mistake.
Ironically it's even easier to host an iframe than an image. I didn't want to really sit there and grab screenshots of every site, plus iframes are interactive which is interesting given that many of these sites use a lot of animations, for better or worse. I also don't have to do any upkeep really, as long as the site is live it will continue to be updated in the iframe since it's accessing the actual site. The only thing I had to do extra was download the site contents for a few of the sites, which block iframe hosting, but it's far fewer than getting screenshots for all of them.
I even thought more deeply about the screenshot approach, going so far as to look into using Puppeteer or Playwright, but I decided against it because that's even more work than doing <iframe src="site.com"/>.
I used Next.js because that's what I know, someone else on Reddit I believe asked if I could do the same in 12 hours with WordPress (or raw HTML, CSS and some scripts as you mention), which yes is possible but I don't know WordPress so I'd have to learn its quirks. The HTML/CSS/scripts version doesn't seem much easier, since that's basically what I'm doing in the React side as well, for-looping through the contents of a JSON file which Next.js handles generating HTML for automatically.
I have some experience with static sites — my personal site was a static Markdown-generated site for about six years. The generator went through several iterations, from a shell script to a Haskell app. My company site (also static) was generated with Haskell and later bits of it used Mustache. I've used a variety of hosts, too — GitHub Pages, Vercel, DigitalOcean.
None of those survived even a year without bitrot.
Sure, once the site was deployed it would work forever regardless of the platform. But this is true with Next.js and Vercel (what the OP is using) as well.
Once I wanted to modify the site and reupload it, something would always break. Incompatible dependency versions. The deploy manifest (for Vercel) doesn't work anymore. Something happened with Bash (I don't remember what exactly was the culprit). Nix doesn't work on my new machine and I specified the deps (imagemagick etc) with Nix because "then it'll never break". Etc.
At least with Next.js you get a bunch of nice stuff out of the box. A Next.js site should in theory be faster than a fully 100% static site. Next.js automatically prefetches links in viewport/on hover, makes sure images are only loaded when they are in the viewport, and inlines Google Font links. Vercel automatically distributes your static files over a CDN.
This is just my experience, but personally I have learned that if I want to make a static site, I will not avoid bitrot no matter what. So at least I might enjoy free CDN-enabled hosting & out-of-the-box performance tricks & a good templating language.
> makes sure images are only loaded when they are in the viewport
To be fair that can already be done in pure HTML with the `loading="lazy"` attribute. And browsers will probably do the link preloading as well sooner or later, some already do in specific cases.
NextJS is nice but after all the issues with dependencies and npm I went through I'd hesitate to use it for personal projects.
Hey, could you share more about the issues you hit? Would be happy to take a look.
Also FWIW the new version of the Next.js image component has been refactored onto native browser lazy loading. When it was first created, cross browser support wasn’t there so it had to polyfill support. Not only does it do lazy loading, but it also can optimize your images for you.
Hey Lee, I actually have your personal site as one of my examples, hope that's alright. Do you know if Next has iframe lazy loading as well? I'm using `loading="lazy"` which works but didn't work as well as the package I'm using that's on the React side, react-lazy-load-image-component, which works for iframes as well, and it actually doesn't even mount the component until it comes into view, which didn't seem to be the case for `loading="lazy"`.
It could take me more to buy domain, transfer it to Cloudflare, set up DNS records, spin up VPS, set up the server, create project in IDE, create github repo and clone it on the server. All of this before I even write thr first line of code.
True, however don't discount some of the complexity that arose regarding CORS and iframes. Also, I was tweaking the styling for some time, to make it look good on all devices. The barebones functionality, yes, I did indeed do it within 30 minutes, but the other parts take more time.
I guess you wouldn't really call that an 'app', just a page. But it'd be pretty quick and simple. And if you really want to get away from over-engineering and getting lost in the code details, doing it without any code at all is a good exercise.
Perhaps from there a simple script to take a list of URLs and generate the page's HTML, but still no libraries or frameworks. Scripts like that can live for many years, just being run as needed, serving their purpose with no maintenance or dependency or deprecation issues. Some scripts that I wrote are still running perfectly fine on their own, untouched after 7+ years, while the main application requires a whole team of people constantly maintaining it.
It's good sometimes to get back to basics to put things in perspective.
Things like the leftpad debacle of 2016 should make us think about how we build complex, fragile ecosystems that are constantly changing, and need constant maintenance, often to just do something simple that doesn't need all that complexity in the first place. How simple and quick can you do it? Do you really need code to dynamically scroll down to thing X, or could you just put that thing at the top to start with and not need any code or dependencies?
You're on a good track. We over-complicate things a lot.