I've landed on the same approach for my photography portfolio. Benefit of jumping ship from development to photography is that I don't have to rely on Squarespace like most other photographers!
After trying a few server-based options like Ghost, Statamic and self-built ones with Phoenix or Vapor (I've covered some ground as a dev) and the usual SSG options I ended up just writing everything as straight HTML without any templates and upload to a Hetzner server using rsync.
The lack of templating for shared UI like navigation is a touch irritating, but with some RegEx magic I haven't found a change I want to make that takes more than a few minutes. I got caught out early on with some greedy RegEx that nuked some content, but git to the rescue.
Image generation with all the sizes and format variants is laborious, but it prompts me to try new layouts rather than relying on cookie-cutter ones like Ghost. Plus I've noticed a slight improvement in image quality generating my web variants out of my RAW editor (Capture One) vs using the libraries and CLI tools used in most SSGs.
It's slower, but my thinking is that it's more akin to putting together a photo book. It take more effort up front, but once it's done, it's done for good, and won't need mangling in and out of various CMS over the next 20 years!
It's something I've considered with both nginx and caddy because I've got the server so I may as well use it! I prefer a server over services like Netlify because I can deploy with rsync rather than git (or the web-based UI). Plus it lets me log the many 404s I get after so many site migrations, and then create 301s. Most services like Cloudflare and Netlify just swallow details like that unless you pay for upgraded analytics.
I keep it as vanilla HTML though because I like the fact that I can open any page as a standalone file with no server and almost any browser can render it. I'm not saying this won't change, but for now I'm happy without SSI.
Plus, I'm using Nova for some Panic-based nostalgia (Coda was big when I started), so I like having the code and rendered HTML side by side in Nova's preview.
I moved from static HTML to 11ty (https://11ty.dev) for the same reason and I'm pretty happy with how simple it allows you to keep things. Plus, it helps me avoid yak shaving instead of writing content!
I think for a site like this I'd go with 11ty, just a clean project without a template or custom config, one collection to pull the photos from Flickr inline the styles.
(just sharing my personal approach, nothing wrong with Jamie's approach, ofc)
- Svelte + TailwindCSS (Basically just a couple html files, plus the power of templating)
- Flickr API (To pull my photos from an album that I use just for this website)
- Netlify (To host the site - all have to do is `git push` and the site auto deploys!)
Total cost (incl hosting): $0
With Flickr I can manage the photos from my phone via the Flickr app.
With Netlify I don't have to tinker with an actual server box, plus it's free.
Also, you might find some value in an approach that I used recently (https://news.ycombinator.com/item?id=36592641). Using a Google Sheet as the data driver was easy, but it could have just as well been a filesystem of photos.
I really want to like Vapor because it's just a simple stripped back server-side framework; but I always get frustrated building with it. I've loved learning SwiftUI, but Vapor - even with Leaf swapped out for Plot - just isn't as ergonomic.
Plus I have the lingering memory of working with Elixir and Phoenix LiveView which is kind of the gold standard for web frameworks at the moment in my opinion.
Someone beat me to the punch and added the URL (thanks!).
The site is what's left over after trying a few different options, most notably Ghost and later Zola.
Most of the current layout mimics what can be created within Ghost's editor. I then migrated to Zola which shares the bulk of the layout. Currently most of my images are coming from Zola's "/processed_images" directory. You can view the Zola codebase here[1] if you like.
The layouts I'm currently working on (not yet published) are heavily influenced by Andrew Clarke's work [2] and his book "Art Direction for the Web" [3] which I highly recommend if you want to explore less generic layouts online. I hope that on day my site can be example that web design can be as varied and interesting as print!
This seems to fall into the 'simplistic, not simple' school of thought. You can have a relatively simple website if it doesn't do anything and if it cuts corners.
Take your dark mode, which is just about the only nontrivial feature I see on this page. (One could also criticize the low contrast of the appearance and other problems, but that's less relevant to the simplicity thesis you're claiming.)
First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load instead of the correct way of CSS body classes; so you get the 'flash of white' unavoidably on every page load - just what every dark mode user with their phone to their face at midnight wants to see! (If your solution doesn't work, it doesn't matter if it's 'simple' or 'complex'.)
Second, you implement what is like 3 lines of JS (setting localstorage & dark-mode) by pulling in what looks like an entire interpreter for a custom 'hyperscript' https://hyperscript.org/ language which seems to mostly just offer some sugar over JS; now, maybe you use 'hyperscript' elsewhere for reasonable purposes, but surely pulling in a 96kb (uncached) library solely to run
def saveMode() if first classList.value of <html/> contains 'dark' set localStorage.kkColorMode to 'dark' else set localStorage.kkColorMode to 'light' end end
init if localStorage.kkColorMode is empty set localStorage.kkColorMode to 'light' end if localStorage.kkColorMode is 'dark' add .dark to <html/> end
is a bit against the spirit of this "simplicity is the ultimate perfection" enterprise...? Personally, I feel like I see some easy perfection to add right there. (And is this hyperscript stuff also why the HTML doesn't validate?)
Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it. And since localstorage expires and users switch devices, they would have to do so repeatedly. Is this a good thing? A user probably would disagree with the developer who is touting how 'simple' the dark-mode implementation is because they cut corners in handling system settings/auto-dark-mode...
Honestly if the goal is a website as simple as possible, dark mode should not belong there at all. We've had simple readable websites in 90s long before the dark mode fad was a thing, only having light mode is fine.
> Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it.
There's so much complexity here that goes against the philosophy of a simple website if simplicity is the goal. They should just skip dark mode entirely. HN itself is perma light mode, it doesn't stop me from reading it at night.
'Simple' is always relative to requirements. Otherwise, you'd just be sending 80-col ASCII textfiles down the wire (or something even simpler than that, like nothing at all).
Is dark-mode a good requirement? I'm not sure. It's nice to have, and our dark-mode does look great on a recent smartphone in the dark - but if I had known just how hard a good dark-mode would be, and how many of the issues we would struggle with (issues which OP runs headlong into), I think we would've skipped it. There's a lot of other things that time & energy could go into.
For most websites, I would say that they have far too many problems to spend time on dark-mode, no matter how trendy dark-mode is. (Users who really want dark-mode can install one of many extensions/plugins/apps/screen-inversion tools. They work reasonably well, and usually avoid issues like the white-flash FOUC.)
hn isn't pure white and it does kill me at night on powerful monitors... just like I can't do dark mode outside on a laptop. Sure we did readable websites in the 90s, on dialup or slow dsl, and they took forever to load on small monitors. We also didn't have USB or SSDs.
Dark mode and light mode is a nice tradeoff for varied lighting conditions.
Well I don't really mean white, but more of pick a default theme that works in both day and night and stick with it. So that it's all kept very simple. You could use a dark theme as the default as well, but light mode tends to be more accessible in more situations so I prefer light over dark. As an example, I think the Solarized Light palette is pretty usable in all situations.
If you have ergonomic issues with mostly white screens, it should be the job of your operating system or web browser to police this. It wouldn’t be difficult to implement a feature that sets a maximum total luminance for each page. Perhaps even automatically inverting the colours if it’s over a certain threshold.
> If you have ergonomic issues with mostly white screens
...you need to turn your display brightness way down!
Hold a piece of white paper next to your display. Open a window with white background. Is the window/display brighter than the piece of paper? It's too bright.
It depends on the display of course, but just as an example: my brightness setting is at 2 out of 100. At the work computer it's 19 out of 100.
I've been using Chrome's experimental "Dark Theme" feature on Android for months primarily for reading HN at night. It works great for HN, but occasionally it renders other websites completely unusable.
Why would simple avoid dark mode? It respects the user's preferences.
My site uses CSS to respect light/dark theme, so has no manual toggle. (A manual toggle requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS.) It was quite simple to do: just a media query and setting a few colours.
I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. I don't know of a browser that does this, yet.
> First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load ...
I agree with your whole comment, but the media query approach is also tricky.
You typically still want to offer a toggle while respecting prefers-color-scheme, and you may want to give priority to whatever choice the user has made with that toggle if they've used it on your site before. This still requires JS and localstorage.
So what to do? My preferred choice is having an inline style element of:
body {visibility: hidden; opacity: 0;}
This will maintain the previous page until DOMContentLoaded, at which point you can query prefers-color-element and localstorage, set the body class correctly, and let the page paint.
The nuts-and-bolts implementation of inlined-CSS to avoid flash-of-white is separate from the UX toggle question, which is why I listed them as separate criticisms.
The former is just wrong of OP: no user wants the FOUC flash-of-white, end of story; similarly for some of the other solutions proposed here (block the entire page, really? talk about burning down the village to save it). The latter has more leeway for design: we settled on a tri-toggle to use the media-query but allow users to override and hardwire light/dark mode, and that seems to work most naturally. But there may be other contexts where something else would be better.
Indeed, for toggles, you could even try not having a toggle at all and relying on the system setting through the media-query. (However, as appealing as this is - why have separate controls when the user already has a global control and can enable/disable it? - we found this confused & angered users: https://gwern.net/design-graveyard#automatic-dark-mode So, gotta have a toggle. At least for now; maybe as dark-mode becomes universal, at some point users will become educated enough that you can afford to use only the system setting?)
> block the entire page, really? talk about burning down the village to save it
I'm curious for what the other approach is. Users find it annoying to refresh the page and have their dark-mode setting change, or have their dark-mode setting change while navigating the site.
So I have to block paint until I can query local storage in order to avoid flashing, what's the alternative? Below someone suggested using cookies and only serving CSS that does the desired styling, which I guess is doable but requires a non-trivial infrastructural change.
You don't need to hide the entire page until fully rendered. You inline in the head just the bits of CSS/JS you need and set styles from there, so if you are in dark mode, it's set to dark before anything has rendered, without needing to block a huge amount of time. You can see how it works on my site https://gwern.net/ - set dark mode in the toggle (assuming it is not your system setting already), and refresh or force-refresh; note that there is no flash of white nor is the page hidden until rendering is fully finished.
The idea there is what we call 'demo-mode', a new feature to try to enable helpful chatty features but for only _n_ page loads. So the full theme toggle (or Control Strip in Mac terms) is exposed on the first page load, but then is left collapsed into the gear on subsequent page loads to reduce clutter.
I don't think it should 'try to slide up then it dies'; do you mean you can't see the gear at all?
As long as you have a good reason for your decision. Some things you just have to make tradeoffs and can’t please everyone. Enter key to submit or enter key for newline in a chat context? You’ll go crazy trying to solve for all - sometimes it is just not possible
You can also swap out the CSS file for one that explicitly sets/unsets light/dark mode. This allows for a website that works in any browser even if your Javascript breaks or doesn't load.
Or you could use cookies. No need to mess with localStorage. Just set a cookie "prefersDarkMode" to true or false and have the backend send the right file. No need for an interactive backend, nginx can handle serving files based on cookie contents. No need for cookie popups/walls either.
> This allows for a website that works in any browser even if your Javascript breaks or doesn't load.
I just use <noscript> for this. If you don't have Javascript you're just going to get whatever your prefers-color-scheme is set to. Users without JS don't expect things like a dark-mode toggle to work anyway.
I've been considering this recently for my site and I settled on having prefers-color-scheme on the root domain with dark. and light. subdomains. If the user chooses a color they just get bumped to a subdomain that sets a cookie with their preference. If they come to the site from an external link and they have a preference cookie they get redirected to the subdomain again. Absolutely no clientside JS is needed anywhere, no FOUC issues, and it's trivially simple to code because it's literally just a redirect in the server config based on a cookie value.
I really should spend the time to actually build it, but Diablo 4 came along and I got sidetracked.
I don't know whether to be fascinated or horrified by this proposal, but I admire the novelty - I can definitely say that in all the dark-mode proposals/implementations I've looked at over the years we've been fiddling with ours, I've never seen that suggested.
This sounds like it would have the same problem as redirects to mobile subdomains - users will share links to light. and dark. subdomains, unknowingly forcing their preference onto the recipient.
The proper solution is to only implement the media queries and yell at browser vendors to make this easier to toggle either for all websites or for specific websites. Implementing a light/dark mode switch in every website is absurd.
unknowingly forcing their preference onto the recipient
I'd suggest knowingly rather than unknowingly. It's a link to a website after all. It should link to the same thing that the person who shared it was viewing. That's the point of a URL - when you share one the recipient should see what you were seeing.
FWIW I would also like browser vendors to do a better job at enabling users to manage their preferences on a per site basis though.
My idea has the benefit that users can block the cookie if they want to and still use whatever mode they want, although they'd lose the redirection 'functionality' if they do that.
I was reading this thinking "that's a great analysis" and then read _who_ posted it. OP, this is the author of https://gwern.net, which has been very influential in the design of many technical blogs / personal sites and has some very inventive and fantastic ideas. Ie, the author knows what they're talking about.
My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar.
/u/gwern, in case you read this, your design along with Tufte.css were one of the influences of my own site: https://daveon.design/ . (Also present is inspiration from older-style publishing and manuscripts, and personal preferences. But your site was the first one -- a key influence -- I saw that inspired me with what a modern, clean personal website could be and how it could look, as well as what it might contain. It's a real honour to see you here and reply!)
> My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar.
I agree that it should definitely respect the OS level setting but I really like it when I'm given the option to override that setting. What if I don't like the way a site implemented their dark mode styles and I would rather switch back to light mode for just that one site. Having no toggle on the site I would have to go to my OS level settings, turn dark mode off, then later remember to go back to my OS level settings and turn it back on.
That's very flattering. So I'll relay some comments on your site:
- you make sentence-spacing a major design goal. I looked into that a bit ago and I found little or no real evidence that sentence-spacing is a good idea (https://gwern.net/doc/design/typography/sentence-spacing/ind...) and it would be expensive to implement: you do the only reasonable thing of injecting <span>s... but oh so many <span>s. If you get long pages like mine, that is going to cost you - DOM nodes are not free, soldier!
- one issue with sentence-spacing is that you are fighting HTML & CSS the entire way. They just do not want to do it. You correctly note that it's hard, but you accidentally demonstrate it's even harder than you thought: you have justification enabled but not hyphenation... so all that happens is that sentences get stretched out to make them fully-justified and you get large double-spaces everywhere! Your current implementation winds up being not so much 'sentence-spacing' as 'every few words spacing'. (This is especially glaring in the sidenotes, like on the page I'm looking at right now, 'Stephen Zamadics' looks like 'Stephen_________Zamadics'. Since you set the column narrow, you probably want good hyphenation too... perhaps server-side, if you're deadset against JS.)
- Dropcap positioning is hard, especially if you'd like it to work on more than one browser, and I'm not surprised yours has problems; pretty much everyone screws those up. (At least, I assume you don't intend the positioning problems like the '1' almost overlapping the 'someone' in cases like https://daveon.design/creating-joy-in-the-user-experience.ht... .)
- I think the dotted underlining is too hard to see: much too small and close to the link. Are you sure you don't need `text-decoration-thickness: from-font` & `text-underline-position: from-font`?
- Rubricating the entire sidenote on hover seems excessive.
- Sidenote numbering is very confusing. They get numbered 1/2/3/4... and then all lose their numbers in favor of ''? Mixing numbered & unnumbered is confusing enough, but then transitioning at the utterly arbitrary '5' let me baffled and wondering if the ''s were supposed to be a separate kind of sidenote like a margin-note. Definitely a case for 0/1/infinity.
- Sidenotes come off as cluttered and hard-to-read, at least partially because they are all 1 big paragraph. Breaking them up would increase readability. I hope you didn't inherit Tufte-CSS's unnecessary and artificial limitation to non-block elements...? (I can't believe they refuse to fix that.)
- EB Garamond is a variable font, which is a bit of a questionable choice because OS+browser support is still relatively low. (Just browser-wise, it's only at ~95% global https://caniuse.com/?search=variable%20font so add on OS incompatibility... The text should still render, but it won't look like you expect it to. Example: https://share.obormot.net/screenshots/Arcturus_Screen%20Shot... Also shows the sentence-spacing problems & dropcap problems.)
- The use of auto-smallcaps (after H1s, I guess?) winds up feeling busy and confusing. Look at a page like https://daveon.design/about-dave-on-design.html where the sections so short - it winds up feeling like smallcaps is just being sprayed around at random, and the logic is lost.
- Your image dragging widget is mysterious. The icons are unfamiliar and so small that they signal non-interactive.
- am I imagining it or are your <hr>-asterisk-thingies weirdly offset to the right?
- The lack of any header or obvious site navigational apparatus, despite the very large header, makes the site feel somehow cramped and confining. You must like your tree - have you considered the classic HTML approach of an image map?
- The use of triangles in the ToC is a bad idea. They look too much like collapse/disclosures, which are becoming increasingly common, especially in ToCs like this, especially when the reader has already seen you use black-dots for unordered list markers.
- Easter eggs like `X-Clacks-Overhead` are fine, but the page should still validate... (Doesn't look like a legal http-equiv to me: https://html.spec.whatwg.org/multipage/semantics.html#attr-m... )
- You have low-hanging fruit in performance and can definitely render faster: https://pagespeed.web.dev/analysis/https-daveon-design-about...
- Tooltips, tooltips, tooltips!
I don't notice any "flash of white" (Firefox, Chrome, Safari on Mac; Firefox, Chrome on Android). Not on initial page load, refresh nor toggling between Dark and Light. It seems to just work.
Well yes, the entire page flashes white if you have FOUC because you implemented it wrong. And since mobile browsers are usually fullscreened, it means the entire device flashes you; I assume you don't use dark-mode much if you haven't noticed this. But dark-mode users do notice and once in a great while, even complain to you about it.
Right now, sveltekit + skeleton has absolutely blown my mind at how fast you can make a usable prototype. It’s honestly insane. You don’t even need to know svelte, really. As long as you can understand the file based routing thing, the rest is just html unless you really need more. Especially with the tailwind stuff built right in and a mostly vanilla looking theme.
I’ve tried probably a dozen different things in the last few months, ranging from Astro to Lit to NextJs to using the built in golang templating system, pug, eleventy, and more I’m forgetting. So far this is my favourite in just about every way.
SvelteKit is amazing. I disagree about Skeleton though. Skeleton makes you feel productive and safe at first but it has a lot of foot-guns. It leads you down a happy path until you don't like something and then it's difficult to customize. You're much better off using DaisyUI or something headless like MeltUI when it's ready.
Take a look at Skeleton's own site https://www.skeleton.dev/docs/get-started
Press page down - no scrolling happens. Hover your mouse over the navbar - no scrolling. Print the page - the content is cropped to only what's shown on the screen. I've raised this with them and it hasn't been a huge priority yet tones of sites are using this pattern from the <AppShell> component. Skeleton thinks you can just take your dark theme, invert the colours and end up with a decent looking light theme which just isn't the case.
With DaisyUI you get a more mature/performant/popular framework that takes accessibility seriously. It's amazing what they can achieve with just CSS animations and no JS. It solves the hard part (HTML, CSS) and let's you write the easy part (Svelte). You're also less locked into Svelte - you can much easily pull your DaisyUI html into a different framework.
This is good to know! I’ll try out DaisyUI next! My favourite part about skeleton has been having mostly functional, pre-existing component classes. The svelte material ui (smui?) library left a lot to be desired there, and I like how easy it is the modify the skeleton ones, since they aren’t a horrible jumbled mess of tags like all of the Vuetify components are below the surface.
My least favourite part of tailwind is needing a stock button and having to add 80 characters worth of class stuff just to get a generic looking button, which is what skeleton solves for me.
Very happy DaisyUI user here. While I like tailwind, I have to agree that for simple things like buttons as mentioning above, it sure is verbose. One of the best aspects of DaisyUI is the wealth of ready-made elements that have very reasonable defaults which often need very little to no tweaking. Of course, you can adjust them as needed very easily. Since we’re on the topic let’s complete the stack: Using DaisyUI and a small GoFiber.io server running Go stdlib HTML templates, I’m able to crank out high performance web apps with minimal fuss. By using the embedding feature in the Go compiler you can ball everything up into a single deployable binary. For in-page interactivity, I like htmx and/or AlpineJS, depending on the use case. No NodeJS dependencies in sight!
I agree. Yes, it’s a “framework” but it easily outputs static sites that work fine without JS enabled, you don’t need to know any Svelte to use it (but it’s there if you want it), Tailwind works out of the box, and deploying it to eg Netlify is dead simple (much easier than FTP).
If you ask me, it’s the best static site builder right now, and a lot simpler than what’s described in this article.
I'm a minimalist fanatic myself. I've tried astro and Sveltkit. IMHO - Sveltkit is really very minimal on top of an already very minimal component library, Svelte.
With +page.ts and appropriate setting, you can even generate static website or can go MPA or SPA .
I'm not finding a "here's what you type and here's the final page" style example. Is there one? Id prefer not to install something and run through the steps just to see it.
There's a fairly high barrier for people to commit to installing a tool and building with it, especially if you haven't shown them what they'll get out.
I haven’t tried flutter! It looks interesting, but I don’t have much interest in learning Dart so it’s pretty low on the list of things to try, for me. I have experience with Capacitor and Vue, which kind of accomplishes the same cross platform thing, although I wouldn’t really recommend it.
Another one I tried was Hugo, but I also didn’t bond with it. I found Go makes it so tough to have your templates be properly reusable if you stick to only the standard library template engine.
Fancy that! HTML and CSS? To make a Website? They must be mad!
All joking aside, I use the same stack save for the templating. Unless you are a web developer I don't see the point of a CSS framework, it's much easier to roll your own. Nor of a site generator, I tried Hugo it saved no time at all. Nor of JavaScript, a few months ago I tried replicating the websites of a few companies to improve my css skills, HTML and CSS were enough to reproduce the appearance of all of them, yet none of their website would even appear without JavaScript enabled.
We stack on framework after framework, new languages, new tools, all for nothing but increased complexity and busy work for a new generation. (Save for the 5% of websites that actually need that stuff.)
Also interesting to see they actually sell a service, would have been curious to know what their prices are like.
I see your point. My recommendation if you wish to improve your designs is to do them outside of CSS if you don't already. With something like figma or Penpot you will have your fonts, palette, spacing and layout all predefined.
Then once all your views are created using these common elements, you only need to transcribe them as classes in your CSS and use those few classes where needed in your HTML.
I'm not a design expert, so take it with a grain of salt, but I used to be terrible and following that workflow allowed me to get decent.
Without some design knowledge and experience (and dedication), starting from a blank canvas in Figma, Framer, or Penpot is going to be extremely difficult. Design is an art and skill in its own right.
Of course but starting from the assumption that he is doing it himself he will have an easier time using design software than jumping into CSS.
Design software encourages/enforces good design rules through its interface. You couple that with a willingness to learn and a bit of practice and you can achieve some nice things. Especially given that the design of some types of websites is very codified like SaaS or blogs.
I believe the most minimalistic and productive way is to just use php. The language was specifically just created for that. If it's a simple site then you don't need composer you don't need router logic. just create separate files for header footer navigation and include them on each page.
You can build a router and layout in about 100 lines with no libs. If the router just checks the existence of the file and the layout just includes header.php, pagename.php and footer.php. I do that for simple sites. Very easy and fast.
Ya, or any server side scripting language. You just want the ability to refactor your site, as in, name, save, and load data and code blocks.
And if html allowed inserting html as it does css or js from external files, even that would be mostly be redundant. If only it let you use <html src="" /> at will.
Even better better just <html src="" /> or even <div src="" />
Functionality should be considered based on potential utility. Not sure what politics are involved at the w3c, but if it's not that, then maybe it's their philosophy and approach that has them not going for that which is most useful.
if you want simple, you can't beat PHP + HTML. I wouldn't actually go that simple for anything that's more than a single purpose script, usually I would at least have a separate templating library, but it's really nice that you can do it.
I agree with your sentiment, but with just 5-20 hours of effort one can make an effective Eleventy-based custom site generator which is then deployed on Netlify for free (and edge-available globally).
Edit something, git commit/push, and within 30 seconds your changes are live everywhere. It's pretty awesome, and it requires no "server" hosting.
Agreed, with the caveat that it's only so easy if a server is already set up for it. Otherwise it loses a bit of it's edge, but not by much.
We are being simple, and I consider a simple PHP site about one step above HTML and CSS in required complexity, and about 5 steps below anything else in regards to tooling/setup/execution.
I think every flavor of Linux except Alpine includes PHP by default if you go the VPS route and every $2 shared host also has PHP. Seems like a bit of a moot point.
Working with PHP has always been such a breath of fresh air. No build process, just upload the files via FTP and it works. You can keep it as simple as you want (just include() files, write functions directly, I never really need to use classes in PHP).
"as simple as possible but no simpler" - (not Albert Einstein, probably)
Pure HTML + CSS, with the CSS in the <head> or inline in each html tag... this is a fine way to get something going. And then when you have two pages, you pull the CSS out to a separate file.
But once you start making any site which has multiple pages of the same format, you want some kind of template system with includes and a (static page) generator.
If your pages are data-driven, then you might want a programmable site generator which can ingest the data and spit out pages.
But if your data is "live", you end up needing per-view page creation, which is at minimum PHP realm (and certainly leaning into modern web framework with running servers realm).
I recently built a pro-bono website for a hobby of mine. The site is a dance promotion and event site, and the owner is a very non-technical dance teacher. It uses Eleventy (https://www.11ty.dev/) to generate a static site on Netlify (free tier), and it has some custom build code which pulls data from a Google Sheet which I have setup for the teacher to use to define upcoming events. It took a good dozen hours to build, but now it works like a charm while costing nothing to operate or manage. Now having built this, I have discovered a great and powerful sweet spot between absolute bare minimum and Rails/Phoenix/Django level.
Yes, even OP ends up using two libraries: Jinja for templating and Tailwind for styling. It’s the happy medium, as you say, between bare HTML + CSS and full-blown Django/Phoenix/Rails + Angular/React/Vue.
I tend to refactor on two, but I've heard that letting DRYness lapse until three tends to be the sweet spot in terms of likeliness to break even in effort. Although I guess pages per site is almost guaranteed to hit 3 anyway, whereas in general a block of code being used 3+ times doesn't necessarily have that same likelihood.
Have you open sourced this or found a similar project?
Does it make an API guy to the google sheets api client side to populate the data, if so is there a caching layer or does each client get a fresh copy.
I have not open sourced it. I probably wouldn't go to that trouble, but I might write a good blog post illustrating it.
The Google Sheet has a script associated with a button which the sheet editor uses to "publish" the changes. That triggers a rebuild on Netlify, and the build does the sheet data fetch. This was better than automatically triggering the build on sheet save, since the save happens within a second or two of every change.
Netlify has an unpublished URL trigger to force a rebuild, and that URL requires no authentication. Thus, one must be careful about making that URL public. But worst case scenario, the free tier Netlify build credits get used up for a period.
I’m just really tired of this debate about “frameworks” and “complexity”.
If your client asks you for a custom CMS with a multi-stage publishing workflow with i18n and regulation-compliant a11y, you’ll need high-powered tools to build it in the time clients expect. Lots of clients in enterprise are like this, which is why the demand for this stuff is so high. If you’re working in B2C this may be surprising, but this is what the underwater part of the tech industry iceberg is.
Yes, a complicated Next.js setup or Vite toolchain isn’t necessary for a static blog. But the people who are talking seriously about these tools aren’t talking about making a simple blog site (even if that’s what their “reduced teaching case” tutorial is).
So can we just chill with this framework hate? If you’ve got ideas for simple ways to make web sites, go ahead and publish tutorials, and if they’re appealing then people will start doing things your way where appropriate. But please don’t position yourself in opposition to a vague “spicy toolchains and trendy frameworks” enemy.
Yes the thing is most people participating in the conversation just haven't worked on the problems these tools are useful for. They maybe are an engineer... but they don't touch frontend, so they don't know much beyond the basics. Or they're a CS student... but they made a personal blog with Jekyll, so of course they know everything about frontend dev. Or they work on internal LoB apps with user counts in the two digits and no UX requirements... but they've been doing it for years, so of course they know all about it. It crowds out the discussion with low information takes.
Eh, I read this a lot. An app architecture is not a framework, frameworks get complicated because they have to be generalised enough to serve multiple projects with different requirements which leads to a ton of abstraction. Then because they're complicated they're difficult to learn.
An architecture concept just needs a page or two of docs and diagrams to understand, and the code is right there in the app. You don't need a framework to implement relevant design patterns.
Those apps can also last longer, because there's less pressure to rewrite in React/Svelte/Solid/etc when the existing code isn't dependent on some obsolete framework - Ember/Angular 1/etc.
> Then because they're complicated they're difficult to learn.
It's easier to learn a publicly available framework, as there is lots of help on Stackoverflow, and usually the popular frameworks have good, or just existing, documentation.
> existing code isn't dependent on some obsolete framework - Ember/Angular 1/etc.
The "app architecture" can also become obsolete. But now instead of a migration path, you're stuck with the person who made the "app architecture" most likely having left the company.
No, not a framework. The fundamental idea of a framework is that it's reusable, and there are inherent compromises and complexities which are a direct result of making reusability a goal.
I've adopted lots of code, some good and some terrible. Framework-based code is only easier to understand if I already know the framework and sometimes not even then if the original developers mostly had to fight their framework.
The "app architecture" does not become obsolete because nothing has come along to replace it and it was already simple enough that Stack Overflow was never a necessary part of development.
I wrote my post as Gemtext (the Gemini markdown) and wrote a python script that convert it to HTML and generate an index page.
Also, I put the CSS in each page because I’ve 42 lines of CSS and I did the math to show that having 42 more lines in each file would never cost more than having a second http request.
Honestly, it was a lot simpler than expected, without using any python library or any template. The hardest part was generating the email to send to the list. I spent month analysing different frameworks, different static site generators. I spent week trying to find a good CSS.
According to the git history, it took me 2 weeks of hacking to get it done including importing 18 years of Wordpress history. And without having to learn anything because it was straight python. And the best of all is that I can easily change/correct if I’ve a bug. It’s my code.
We, computer scientists, forgot completely that we could simply code adhoc solutions instead of trying to reuse everything. We take more time to learn and adapt than to do.
I serve my site from a 6502 processor I carved out of balsa wood back in 2003 and epoxied to an ethernet cable. When I want to make changes, I heat the EPROM with a hair dryer until the right bits flip. No templating, no code, no bloat.
Maybe I'm misunderstanding, but this doesn't sound all that different from your average static site generator—Python-based Jinja templating for HTML files versus Ruby-based Liquid templating for HTML/Markdown files (i.e., Jekyll).
For sure! I'm all in favor of bespoke new tools. If anything I'm just confused about the way they describe this in contrast to SSGs (and why a SSG wasn't a good option for them), and then go on to create a tool that literally generates a static site. :P
Maybe I'm being obtuse, but the reasons they gave for not using an established SSG primed me to expect a radically new solution. Versus "we didn't like any existing SSGs so we built our own," which was my takeaway from the whole thing.
I was thinking the same thing. If the author's goal was simplicity, it seems like a strange choice to forgo using an existing SSG only to build a bespoke one on their own.
A PHP site (for the includes), or an out-of-the-box SSG would make much more sense, IMO.
The article says "Unfortunately, Jamstack tools require an initial setup and an initial (and continuous) learning" but with the bare minimum, static website generators are nothing more than glorified template engines.
I'm using Hugo and for my purposes, I always start without any theme. Basically, I start to write a markdown file for each page, and an HTML template, then if I need more complexity I have the power available underneath.
Static website generators are not necessarily complex to use, and they generally stay compatible from version to version so you only need to learn the new features and only if you want to use them.
Are there ways to view tweets without an account? Kind of like archive.is? For now, I could enter it in Google and view cache, but I assume that will go away soon.
And if I understand correctly, it's not the index.php, but the actual service behind it, that earns thousands per month. Looks nice :)
Just because you can doesn't mean you should. Just because it's one file doesn't mean it's better. It'll be shit to maintain, it'll make working with multiple developers a pain (merge conflicts much) and having one file means having minimal structure at best. There's a reason why we split things up into multiple files.
I could also write his cool startup in just one line if I just remove all newlines. Does that make it even better than 14.000 lines? Obviously not.
I adopted this mentality a few years ago and it's served me very well.
Pro tip to anyone looking to do the same without losing the benefits of SquareSpace's WYSIWYG editor: try out Bootstrap Studio [0], which gives you a visual editor but also full control over the CSS and the ability to create reusable components. The licensing is also user-friendly (doesn't require a subscription).
I recently built AI Search with 0 frameworks and dependencies (please don't hate because of the word AI)
For comparison, similar sites are a lot heavier (not criticizing anyone here)
phind.com = 1.09MB
you.com = 1.3MB
aisearch.vip = 0.035MB
I still find the ~1MB of other sites to be ok, but 35kB is the smallest I've ever made a full SPA and that's simply because every single letter in the code is specifically made for this one and only site (and uses vanilla everything)
Thanks for letting me know. Oh yeah, I can see in the logs that someone was summarizing a 100-page PDF. It slowed things down for a few seconds. All should be well now (I need to tweak the PDF function to prevent this, it seems to cause issues)
If it is a website - then it is plain HTML with some CSS. The exception is - there will be some JS if we want saucer flying across screen.
If it is an application - the logic will be coded in plain JS that talks to backend using JSON based RPC. No frameworks bar some domain specific libs. Minifying / building step can be included for production.
Hetzner is the hands down best cloud/infrastructure provider for the quality and price both but for a static website, spinning up a cloud VM is far from minimal.
You need lots of setup, a web server and web server configuration.
That too when far minimal options like Cloudflare Pages exists that are dirt cheap as well and is somewhat "serverless".
Frameworks and libraries should not be limited by ideology. The primary objective should be to utilize whatever is necessary to achieve the task at hand. And no more!
When creating websites, the focus should not be on competing to use the fewest (or most) number of tools, but rather on effectively serving users and ensuring their satisfaction.
*User experience should be the guiding principle.*
What concerns me about this article is their simplistic view that using a minimalist stack is solely a matter of choice, without acknowledging the nuances involved. It comes across as arrogant.
Furthermore, their demonstration of "building a website without frameworks and numerous libraries" is based on their own website, which is nothing more than a static landing page with links to blog posts.
Could anyone realistically build an Uber or an Airbnb using the same approach, even if they wanted to?
Kind of annoying to see tailwind mentioned practically as a footnote when it clearly enables a huge amount of productivity for a system like like this. Styling is easily half of the work for most web development, even for the simplest websites.
Totally agree. I think where complexity really creeps in is as you add multiple new content editors with varying skill sets.
If you want a team of people that don't know HTML or rest of the stack to edit, manage and deploy it then you're going to need a more complex abstraction.
The alternative might be a training programme for new staff in HTML, CSS, git and rsync.
You're trading one type of complexity for another. As you say, it all comes down to use cases.
Simple static sites are great ideas. Writing HTML/CSS and not relying on a WYSIWYG back-end editor is an awesome way to work, especially if you're using a templating engine to generate the static content as mentioned here. However, in my experience the people paying to have websites built or your in-house marketing team maintaining and updating the company website, making sure the SEO is up-to-snuff, etc. can't do these things. They don't want to learn how to do these things. The unfortunate truth is that more times than not they require Wordpress or something like it to do their job.
It may not have a zillion libraries, but surprised that a site trying to be zippy uses low-contrast text (obviously, I am not a fan of the "increases engagement time" school of thought).
Agreed. I feel like I'm always the first in my company to complain when someone proposes a too-thin or too-light font style or color, but this read fine for me. I'd move away from monospace if anything, but I take that as a stylistic choice they made even if it hurts readability a little (not like thin gray that's used without even noticing: the dev already knows what's written there, or doesn't care if it's lorem ipsum, and checks the font only for form instead of also for function).
It passes minimum (AA) contrast recommendations but fails enhanced (AAA) contrast recommendations. I also wouldn't settle for it on a site I'm responsible for.
My advice would be to use github and github pages. It uses jekyll by default which is good enough for static website. It's easy to add domain. You can use HTML or Markdown and you don't need to write anything. I read jekyll starting guide and didn't do anything else, it was enough for everything I wanted to implement.
I also use cloudflare for caching, but that's more because I wanted to tinker with it. Surely GitHub can withstand personal blog.
Nice, it’s always interesting to discover blogging stacks.
Historically a blog requires a feed, this is typically where super minimal stacks stop, although I guess you could scrape your index.
I wonder how many web devs can still build a blogging app, a webshop, etc from first principles when mostly it’s all npm create packages and template languages.
I started a php / SQLite blogging stack with basic web based editing and a feed (ah and tagging, a search), hope to add more indie web features to it.
I build my sites the static way too these days. The best part is that I can host my sites on Cloudflare Pages, which is completely free and can easily handle a traffic spike. Plus, it has a built-in CDN, so it's super quick.
I use Astro for my websites, because I'm familiar with the framework and have used it for many of my clients. Even though Astro is a framework, it doesn't feel like one when creating content inside it.
Been dedicating a ton of time to this goal lately. I released a "SvelteKit template for building CMS-free editable websites" earlier this year and the idea has evolved since. I started out with using Postgres + MinIO for storage, but have switched entirely to SQLite. I also added an in-place image cropper, to resize and optimize images on the client side (WebP output) before uploading and storing them in SQLite. I chose Svelte because it's easy to build classic Web pages (with minimal JS overhead), and at same time implement the reactive layer (e.g. editing) on top of it (will be loaded async). However we are also evaluating the possibility to port this to a LAMP stack at some point. Oh and everything is dynamic here, no build steps involved, edits are live immediately.
Just launched my first client project using this approach:
This resonates a lot. I really wanted to get on the Hugo train but I just couldn’t. I’ll probably give it another go someday.
For now it’s straight HTML,JS, and tailwinds for CSS.
Then I let Parcel do all the minifaction magic when shipping to GitHub pages.[1] Which is the only “magic” in this equation. I could pull it out if it ever broke.
Not sure about other Static Site Generators, but Eleventy lets you write your content in straight HTML, or whatever else you want, doesn't have to be in Markdown. Do that, plus don't use anything much else except simple template includes, and you've basically got the author's build script, without having to write or maintain any code yourself. Just sayin'.
I fondly remember writing a bottle.py+jinja based dashboard wrapped into a windows utility that allowed to let that run as a service. My first web app, only for my team's internal use, without any autoscaling etc but boy did I have fun writing it!
It's a scale thing - today I would reach for a framework for bigger things but lightweight setups have their own place.
This is the same approach I took when trying to set up a small project site at SDF.org. It was a great way to build a site, and learn some new things while having a bit of fun. Sadly, I just don't have the time to generate the content I wanted to do, so the site sits.
Reminds me a bit about the minimalism trend where people boasted about getting rid of all their belongings, only to mention at the end that they borrow everything they need from their parents or roommates.
Did anyone else notice the fact that on the home page, for any window width >= 1280px, the text "Your design. Our HTML and CSS" (in the body) overlaps the text in the footer (and is strangely hard to select for copying to the clipboard). In fact the footer tends to overlap the body at various window sizes. Can't help but think that you'd wanna at least get a simple thing like that right on such a page...
Edit: I noticed it's using "rem" for specifying the font size, and I've actually seen quite a few sites where the font sizes look wrong using that unit, I'm wondering if it's something specific to my system (but happens both with Chrome and Edge).
Guess it wasn't just my system, they've since fixed this. Though at the cost of the footer never being visible without scrolling now (even at ~2100 x 1080 size).
It's the same ergonomics as custom template languages as far as I know, loops, variables, functions etc, plus you can just call them directly in your server code, not having to worry about another syntax that's not even turing complete
WordPress was very simple back when it started. You needed just a few files: header.php, home.php, single.php, footer.php, and I wrongly assumed "Code is poetry" was about the brevity of poetry.
More recently, for simple websites I created a Golang template that reads a PSV config file. (PSV throwback to my Perl days.) Uses very little memory, no database, and I can reuse the same Go code for multiple websites. I think about sharing the code, but I'm not sure if it's worth the trouble.
I'm encouraged to see people here using their noggin, following their bliss, keeping things simple, and I hope this trend catches on.
I think everyone writing content for the web should learn HTML and maybe some CSS - although the design part should be done by someone good with CSS, so that you only need to use semantic HTML, or you will end up with div's all over.
I think CSS is an order of magnitude more complicated than html, so I'd leave that to the professionals. But pretty much everyone should learn html, I agree with that.
With a little bit of CSS I mean enough to know how to add some extra padding to all buttons on the site, like finding button { padding 4px } and change that to 6px.
The first hurdle in trying to make simple multipage apps with handwritten HTML/CSS is, as the author mentioned, getting to the step where you have reused components across pages and have to jump into a server-side templating setup like PHP, or use something that introduces a build step if you want to stay static. I don't know why there isn't a simple method for including HTML partials incrementally in handwritten sites without doing either of these. WebComponents and slots seemed perfect for this but they force you to define them with JS.
I genuinely believe Gatsby is the epitome of everything wrong with front-end development. It’s such a bad framework. So complex and confusing and fragile just to generate static pages.
I've found a combination of picocss (or similar), a webserver with some templating (like handlebars) and as much server side rendering as possible pretty simple, and pretty easy to use, so far.
For example, one could use rust with some webserver and handlebars-rs to do this. You can add databases to this, and whatever else you need, and it works nicely. If you want to change anything, its very vanilla html, css, javascript, or rust/c++/nodejs/whatever else.
No new frameworks to learn, and you decide the structure.
Now to make a website, first start to design a cluster, what services it will run, the CICD pipeline and after a week of battle forget what was the site you wanted to make.
For information, static sites are unchallenged imho.
Even for a certain level of collaboration, I think one could get away with using static sites. I haven't tried this in practice but imagine having a git-based CI/CD flow for a static site, where non-technical end users could use the web-based Markdown editors of github.com or gitlab.com to make small changes, save and push via a pull request.
Each merge is of course approved by a more technical user.
I would love to hear if anyone has tried this model.
I've thought of something similar! A git-based flow for a friend's static portfolio site, where he can make text edits and upload images, and the site builds that content with HTML templates.
Not sure how the GitHub markdown editor would feel for the user. It might be really great, even for uploading images.
I was imagining a static admin page, WYSIWYG, that makes git pushes on submit. These were the headless CMSs that seem to be able to accomplish that:
Github.com and Gitlab.com have after all put a lot of effort into their WYSIWYG editors, but they're not very useful for image uploads.
That part should probably be handled separately just to avoid slowing down the git repo with huge binary files. For example upload an image to S3, note the path, enter it into a markdown syntax image url.
There are many ways to skin that cat, depending on the technical skill level of your client. They could even e-mail the images to a script, or message them to a bot on an IM service, that then returns the URL for them to use in Markdown.
There's a fairly popular site I run that is run like that, except we don't use github. Just `git push production production` to push the production branch to the production machine. The bare git repo there has a post-commit hook that detects production branch pushes and unpacks the branch to the correct server directory, compiling some static assets along the way. If we want you to be able to push to production we just add your public key to the machine where that git repo resides (no login, just git). Makes pushing changes very easy. But it's obviously not high-availability, or CDN-backed or anything crazy.
I am trying it now for some volunteers that I am building a web site for. Building the web site and responsive theme almost from scratch took about 10 hours of work, and further changes will only be the addition of news items ("posts" in Jekyll slang).
The theme is HTML and CSS plus about 20 lines of jQuery JavaScript to handle simple toggle effects such as the hamburger menu on mobile. Probably could be done without jQuery but I am not a web developer and that's what I know. Posts are written in markdown and the idea is that the others will either send me an email or later will open a merge request on GitLab.
I'm a technical writer and this is how I'm running docs at my company. You'd be shocked at how easy it was to get one of our content marketers comfortable enough to start opening pull requests for an internal-only docs site. (It helped that I assured them that, thanks to how branches and approval workflows function, absolutely no changes they made could ever wreck the live site.)
What are your thoughts on (1) Obsidian vault (folder of markdown files), (2) stored on a shared Google Drive folder (several team members can edit files using Obsidian) (3) Less technical users could publish the site by using GitHub Desktop app. When they commit changes (4) git-based CI/CD uses MkDocs-Material to publish the site somewhere...
tldr; the author is using jinja templates + tailwind + a python script
It all feels a bit moot because most frameworks exist to create website that tend to be web apps
If you just want static website well it's pretty easy to use any kind of simple templating system that will give you some html + css + optionnally js.
Hell you don't even have to generate the file, you can use CGI to generate your page on the fly with CGI (I like haserl)
If you like or are competent in dealing with quirks, you can do it all by hand instead.
I just got into webdev and I really like Svelte and SvelteKit so far.
Svelte works well if all you want is to colocate a bit of html, css and js. You can really start simple and iterate when you have bigger needs.
Now, if I want to make a webapp I'll use SvelteKit even if only for the baked in client side routing based of the structure of the project.
I'm still using Dreamweaver 8. I have to run it under Wine on Linux, but I have a permanent license, and it works fine. That does most of the drudge work. Sometimes I'll hand code some Javascript.
I wish there was a modern version of Dreamweaver that didn't phone home, didn't use "cloud", and didn't require endless payments.
I've not tried this for any adobe products, but you could try running them in a locked down environment (container, vm, whatever) and don't allow network access.
Adobe Creative Cloud apps stop working after a while if they can’t phone home. Adobe Creative Suite apps do not.
“After Adobe Systems' acquisition of Macromedia in December 2005, Dreamweaver 8 was added to Adobe Creative Suite 2.3 and was later succeeded by Adobe Dreamweaver CS3.“ [1] (Replacing Adobe GoLive, good riddance)
So you could use up to Dreamweaver CS6 with just a serial number (usually requiring one-time internet activation), but anything newer requires regular internet access.
> Mind you, Hetzner webhosting starts at 2 EUR! How crazy is that?
Oh yeah?
and netlify is totally free for an infinite amount of sites! how crazy is that?
> We use a short Python script with exactly 45 lines of code. Including comments and blank lines.
>
> In summary, this is the simple toolchain for building our web:
>
> Developer updates index.src.html
> Watchdog.py detects the file change and ...
> ... renders Jinja template into index.html and ...
> ... calls Tailwind CSS CLI to generate styles.min.css.
love posts like these that insult literally any other way of doing things except their way, claiming it's "simple" when in the end they don't even show the step by step code or link to any repository that shows how it's done. regardless of "without frameworks or tons of libraries", its esoteric and definitely not an average or common way of doing things (to the rest of us), and clearly DOES use codes (and/or?) a framework!!!
no description of what the heck "Watchdog.py" is, no description of what Jinja - I for one don't know what either of those are, sorry if i'm an "ignorant normie"
simply put, it's quite clear you ARE using frameworks, just in your mind, perhaps, you "aren't"
this whole framework vs no framework vs BS vs BS vs BS has gotten really out of hand, and 99% of devs cant see the forest from the trees
> they don't even show the step by step code or link to any repository that shows how it's done
They describe the steps and provide the clue that it's a 45 line script including blank lines and comments. I think they expect you would be able to quickly replicate their work in a language of your choice and calling out to libraries of your choice.
> no description of what the heck "Watchdog.py" is, no description of what Jinja
The authors expect that their readers know how to google (or ask chatgpt) for simple coding terminology.
> Meet Jinja templates, which make our life much easier. Jinja allows us to use loops, include files (navigation bar, footer, etc.) and much more.
> no description of what Jinja - I for one don't know what either of those are, sorry if i'm an "ignorant normie"
The first mention of Jinja had both a description of what it does for them, and a link that you could have clicked to get more information about it. Guess it's easier to post snarky comments on HN.
It is simple, both templating and hot-reloading are fairly common programing concepts, neither are uncommon or esoteric when it comes to web development.
The specific implementation is irrelevant, you could use any other piece of software to achieve it.
Anyone who has spent a good chunk of their life trying to keep things as minimal as possible after being “inspired” by such articles can understand the reaction. There’s no reason a sensible comment, even if it’s a bit emotionally charged, should trigger your zen master spidey sense. I’m sure they’re speaking from experience and are trying to prevent others from taking the oh so tempting bait.
Why are discussions of web development and JavaScript unique in that we can’t discuss alternative methods and trade offs without the discussion devolving into personal attacks and defensiveness?
They don't want to use a framework so they wrote their own framework that is most likely shittier and more impossible to debug. Also, now they have to train all their new engineers on their own home-grown shitty/impossible-to-debug framework.
How is a 45 line python script that runs templates hard to debug? You’re calling something “most likely” shitty, but have you seen it? Used it? I find this post and the method they use to produce their site utterly refreshing. What is “shitty” is many dozens (being kind) of JS libraries, complex configurations, and learning multiple tools to produce the same result!
Also many frameworks get over bloated and complicated because they’re trying to solve problems for everybody and edge cases that might not interest you. A lot of times you can get some ideas from it and build something simpler.
Jinja is a templating framework. You can use it with ansible for example, to replace config values or secrets in a configuration file for different servers, etc
Well, it is a decade-and-a-half old and fairly common in the Python web world. I don't think there's any shame in not knowing what it is if you haven't encountered it, but I also don't think there's any shame in assuming a developer audience reading about web development would at least know how to figure out what it is.
When I look at the page, there’s a link on the word Jinja. And the next word is templates. Maybe you aren’t familiar with what a template is, but they are hardly obscure. Here’s a list of large websites that used a Perl-based templating engine a decade ago: http://www.masonhq.com/sites
I am one of those vanilla advocate that is sick of the react for everything approach everyone seem to follow for simple stuff. To argue the point with code, I made a scaffold with examples of what such simple web app could look like in pure es6: https://mickael-kerjean.github.io/skeleton/example/index.htm...
Most such blogs are that way--not telling you everything to reproduce what they did--but I did this for 23 years. I never used a framework of any kind. I rarely used someone else's code unless I had to. I had to use npm cause the credit card service required it. I didn't build our own server software. I did use my operating system's builtins.
And I can guarantee that at some point, most of you have visited one of two web sites I created. (My company created far more than that.)
It wasn't hard to do what I did. I'm a programmer, damn it. And I hired programmers to do the same thing. None of them struggled with it.
> and netlify is totally free for an infinite amount of sites! how crazy is that?
Netlify is hot garbage and you should avoid them like the plague.
I built a startup on a second account, invited a team, and then it started charging me for my personal websites on my first account.
I didn't know about this and they cumulatively billed me hundreds of dollars. When my card info changed, they took my websites hard down. I had no idea either of these things was going to happen.
When I told them their support was 100% unhelpful. No refund, not even a restoration of my websites that they completely deleted.
> simply put, it's quite clear you ARE using frameworks, just in your mind, perhaps, you "aren't"
You're conflating libraries with frameworks. I see no frameworks listed in TFA so they're not wrong. Seems a weird argument to be getting so angry about
99% of code is boring, closed source, and provides business value. Most people do not work at FAANG, and do not want to. People mostly work at SMBs doing things that are not super exciting, and that's OK.
The page has low contrast (3.5:1) and uses a fixed width font. Both are bad for legibility. The contrast is even too low to fulfill the WCAG minimum success criteria (4.5:1).
To me as a site visitor, that's more important than whatever framework it uses.
Also, uploading the site via FTP? There are far better options.
Back in the old days (90s), I remember seeing the “made with notepad” icon on the footer of many pages :-)
I used it myself on many websites. Heck, we were still using the <blink> tag back then. Here’s an Easter egg for young HN readers, search for “blink tag” on Google and see the results ;-)
Why? Most companies require skills in frameworks and libraries. The fact you can glue them together shows a different skill, that you'll most likely use in job daily.
This feels so forced. Make a joke CV, strip it of any mentions of these "bad" things, try applying. Good luck.
There's a ton of value in building stuff without tools. It's somewhat similar to learning two frameworks; seeing React's philosophy makes me a better Vue programmer. In a similar vain, building stuff without tools teaches me a lot about what those tools actually offer me. What stuff is really hard? What stuff is really easy to abstract out? How do Vue/React/Whatever do these things?
It also teaches you more about your platform. In the end, all these web tools and frameworks are running in that same browser. I find especially with newer web developers, it's hard to solve something in React/Vue/.. because they don't know how to break up the problem. If you'd roughly know how to solve the problem without those frameworks, it becomes much easier to figure out how to solve it with them too.
Finally, I also just get toolchain fatigue. If I want to build a simple landing page, I don't want to learn new stuff, I don't want to read what changed in the latest versions, what the correct way of the day is to set up a project. Honestly, I don't even want to have a build pipeline and module swapping dev server, that inevitably needs to be configured. Just some static html/css/js is often good enough. And as I said, you also learn which problems frameworks solve well, so you'll know when some static files isn't the right choice.
Most framework devs don't have any incentive to stop adding features. What was a simple and elegant tool ends up trying to do much more and the additional complexity negates a lot of the benefits.
I use pandoc (and a makefile) as an SSG. It has stuff like syntax highlighting and TeX equations built-in and the install is one exe, not a pile of node or python cruft. It's simple and reliable.
I just do literally everything with next.js and Vercel and either MUI Joy or Tailwind.css... works pretty well and fast to implement once you understand it.
emacsformacos.com still uses a CGI script written in Perl which is just a very simple wrapper around Template::Toolkit. It _used_ to be CGI even in production but it had to change for silly reasons (_not_ related to speed!). The CGI script still exists but has a small tweak to loop over all the pages and save the output of each. Then I just rsync the output to the production server (which still runs Apache, lol).
As someone who was around when people still wrote apps in plain HTML and .js files without a build step, I'm surprised to read stuff like 'the simple toolchain for building our web: Watchdog.py detects the file change and ... renders Jinja template into index.html and ... calls Tailwind CSS CLI to generate styles.min.css...'
You don't need any of those tools. You can build a fast website and even a complex reactive web app with plain HTML, JavaScript and CSS and you don't need any transpilation step.
These days browsers have native features that we couldn't even dream about 10 years ago like HTMLElement (Web Components) which you can use to isolate components (each with their own dependencies) and build reactive front ends with very little boilerplate required. You don't even need a bundler these days because now there is HTTP2 which allows servers to preemptively push resources to the front end before they were requested by the browser so the round-trip latency argument for using a bundler is gone. Not to mention the script tag now has async and defer attributes to give you fine-grained control over the execution order of scripts on a page or within a component.
Also, caching controls are on another level nowadays. It's probably even less efficient to bundle everything into a single file as the whole thing has to be downloaded again each time any change is made to any tiny script...
I feel like there are all these amazing native features that are being ignored completely in favor of heavily-marketed over-engineered bloatware.
It boggles the mind... From where I'm standing, it feels like there is a psyop in this industry to make everything as complex as possible. Even the narratives around keeping things simple are over-complicated.
Junior developers these days are accustomed to a level of complexity that I find unfathomable and they are incapable of seeing through the abstractions. There is all this stuff available in the layers below which is less complicated and provides a more elegant solution than all the abstractions you learned, yet you are discouraged from peeking under the hood.
All these layers of abstraction offer nothing substantial aside from lock-in factor for certain large tech companies which benefit from people thinking that building software end-to-end is more complicated than it really is.
How many junior devs were discouraged from building a new website or app because they thought they didn't have what it takes. They could have done it if they knew: It's OK, you don't need to know React or Next.js or NestJS or TypeScript or Tailwind or WebPack or Lambda/serverless or ORMs... There are better technologies and techniques to learn with your time which will make you a better developer much faster and with less pain and unlearning required later...
Do you ned a lot of experience to know how to start browser-native tools?
I wouldn't have a clue how to start with Web Components and all the other things, to build a < 1000 user web app. I've read the Web Components docs and tutorials but there's few tutorials that are like "Here's how to a full system for XYZ; here's to
handle templating, routing, API data layer, server-side, etc."
I don't think I have the energy to move off from Sveltekit to a new thing, without having to re-learn everything and make a ton of mistakes
It's been a while since I dipped into it, but Web Components use this thing called Shadow DOM to encapsulate the CSS inside from being affected by the stuff outside. Great for compartmentalization, but unnecessary for my personal needs.
So if you're curious about the concept, check out Custom Elements. Same thing, but no Shadow DOM. I found them to work quite well for a toy project I made a couple years ago.
Shadow DOM is a nice touch and in terms of isolating CSS definitions per-component, it does something beyond what most popular front frameworks can do. That said, I know some developers don't even use the shadow DOM; you can use inline styles like some people do with React or you can use a centralized stylesheet for skinning and only write barebones CSS definitions as part of components.
I use Tailwind as well for terse styling and fast experimentation (allows me to write a darkMode-aware and responsive 100 line CSS in a single line with about 10 classes)
For interaction I can write CoffeeScript directly in the page [1] and have it compiled by plim.
I run a Caddy static server [2] and use Syncthing [3] to have every file save deployed instantly to my Hetzner server.
I use entr [4] and livereloadx [5] to rebuild the pages and do hot reload on file save. All the commands are managed in a simple Makefile [6]
———
You can already see how the footnotes take up a large chunk of this comment, this is not my idea of simple. Sure, the end result is readable static HTML and I never have to fight obscure React errors, but it’s a high effort setup for starters.
Simple for me would be: write markdown files for pages, a simple CSS for general styling (should be optional), click to deploy on my domain. Images should automatically be resized to multiple sizes and optimized, videos re-encoded for smaller filesize etc.
After trying a few server-based options like Ghost, Statamic and self-built ones with Phoenix or Vapor (I've covered some ground as a dev) and the usual SSG options I ended up just writing everything as straight HTML without any templates and upload to a Hetzner server using rsync.
The lack of templating for shared UI like navigation is a touch irritating, but with some RegEx magic I haven't found a change I want to make that takes more than a few minutes. I got caught out early on with some greedy RegEx that nuked some content, but git to the rescue.
Image generation with all the sizes and format variants is laborious, but it prompts me to try new layouts rather than relying on cookie-cutter ones like Ghost. Plus I've noticed a slight improvement in image quality generating my web variants out of my RAW editor (Capture One) vs using the libraries and CLI tools used in most SSGs.
It's slower, but my thinking is that it's more akin to putting together a photo book. It take more effort up front, but once it's done, it's done for good, and won't need mangling in and out of various CMS over the next 20 years!