The design language is (understandably) feeling a bit 2013 these days, but objectively I think it's held up great.
It's something I'd like to do for my blog, since I'm getting tired of looking at the same static header, but I've yet to come up with the perfect design.
The background noise is a subtle detail I would have never noticed on my own, but it does subconsciously make the blog appeal to me. Content in front of something that looks like real paper appears more credible than the same content on a flat background.
I thought I was the only one considering the praise it's getting throughout the thread and others saying that they didn't even notice it until it was pointed out in the article. I had to reduce the opacity by at least half for it to not be so distracting.
Perhaps the noise doesn't "scale" on mobile as I'm also viewing it on an iPhone and/or is just more apparent in dark mode.
I've just deployed a change to the noise as I saw a screenshot from another user and it looked like an iPhone bug! The noise shouldn't even be noticeable.
I wonder if it looks different on different platforms. My first reaction looking at the site was that it looked super grainy - a lot of the embedded screenshots and interactive snippets are almost too noisy to read. I played with the setting and found that while I do like the aesthetic, it needs to be about half as strong to my eye.
True. Designer I worked with believes the eyes focus easier on text if there is a small amount of low contrast fuzz surrounding it. I don't know if that is based on science but it seems plausible at least on white backgrounds.
I agree.. I was surprised that it made a difference, but on a large screen it makes the text feel more anchored to an actual page, not just sliding on the screen. It may be less effective on a small phone screen where the screen is less of your total view.
In my experimentation with it, I can't quite figure out how he applies the effect to the whole page without it either dissapearing on adjustments to the viewport or affecting the pages text opacity.
To make it fill the page, you need to make sure it's placed inside an element (with relative positioning) that's height comes from its content. Then give the noise absolute positioning.
The noise still overlays the text, it's just not really visible because of the contrast between text and background.
It's a cool idea but it is laggy to the point of unusable on my Android phone running Firefox (it's a budget phone but I don't have this issue with any other sites).
Also Firefox on mobile, and I have zero issues (on this blog or the last linked one) on a pixel 4a.
Perhaps it's related to android version, Firefox version or constraints imparted by your budget phone, but it's not a mobile layout//Firefox specific problem as far as I can tell (and I have like a dozen add-ons installed now that we can install from the full Firefox catalog).
This is great! thank you - it inspires me that I need to do same.
What are your thoughts on HTMX, how would that play when your using the Tailwinds stuff? (sorry, I am not familiar enough to perhaps use precise nomenclature on these two - but just curious on your thought on HTMX as it would relate to your post?
I always enjoy playing with new tech, and HTMX looks fun, though I wouldn't use it for anything serious. If you're looking for something fun and simple, I'd 100% recommend using Svelte on Astro, they're both a joy to use.
I built this with Next.js to learn, because I use it at work, and need to stay 100% up to date when I'm educating others. It also just has such a huge ecosystem which is hard to match.
Tailwind's Catalyst UI kit only supports React, so it wouldn't work I'm afraid!
Catalyst looks pretty neat. I decided not to go with any kind of component system for the latest iteration of my blog / personal site, and overall I like that decision - I know how everything on the site works, and I just write articles in plain HTML. I really enjoy the flexibility I get from this approach, and it's allowed me to do some neat layout things on certain articles without having to figure out how to escape from the context of a SSG or whatever.
I will say, though, that there's a bit more manual labor involved in setting up a page and writing content than I would prefer. In some of my articles it would have definitely saved time to just write the content in markdown, and there are a few repeated components on each page that would definitely be nice to extract out.
So anyway, maybe some kind of minor refactor is in order - although every time I consider doing this, I try to remind myself that actually writing / making content is the more important thing to spend time on. Maybe if I ever get to the point where I'm writing multiple posts a week it would be worth optimizing the workflow more.
Right, the most important thing is getting your posts out there! I say do what works best for you, we all have knowledge and experience in different areas, and there isn't a single solution for everyone.
Love this! Love the design and font are fantastic choices as well. I actually just started last week building film grain into my current WIP and it really feels like it catches the eye so much more. Largely inspired by trying to make super high quality photos feel vintage by blurring + adding noise.
Exciting to see what more comes whenever you post. Digging this cursor blog as well.
This looks beautiful and I appreciate all the work that went into it.
For me, it is overkill. I went in the opposite direction this year, putting more emphasis on my posts (and their readability) rather than visual flourish.
I am planning to do further optimizations (such as font subsetting) to reduce the burden on my site's visitors later this year.
> I’m applying a tiny amount of film grain to the body. To me, this makes the page feel like one consistent piece; as you scroll down, the noise sticks to the content, somewhat similar to seeing texture on paper.
That’s a really nice touch. It does help me with reading, kudos.
I did the same thing a few months ago on my web page https://pablo.rauzy.name/ (well, not on the home page but on all other pages), for the same reason :). The texture is not noised because it is just a CSS trick with background properties so it is quite regular, but I feel like it does the job.
Thanks. I'll try to get my hands on a portable Apple device to test and debug this behavior. I test my websites in WebKit using Epiphany (GNOME Web) but not directly on Apple devices.
One part worth noting: this gets dark-mode right by making it a three-way toggle, not a binary toggle - it's automatic/system, prefers-dark, prefers-light. It's not 'opposite whatever'.
would love you to publish open-source as nextra.site blog theme is not cutting it in terms of customizations. Would be great to fork it and write from IDE
I'm not going to dive in and play with it, but often it can help to add the CSS rule "transform: translateZ(0)" in order to force rendering to the GPU instead of CPU.
I like Next.js and have used it for a few projects. However, my previous two blog iterations (yes, I remake my blog as often as writing blog post) with Next.js (page router) were less than ideal.
Even with full static generation, Next.js still makes your site a React application. A page might be pre-rendered completely on the server, but Next will still ship JS to the client for hydrating ... zero dynamic content. Here, speed is not a concern for me (I believe the performance impact (ab)using React for text content is negligible), but the fact that it is just ... not ideal?, irks me so much.
Then I turn to Zola, a more traditional SSG, but then for any interactivity or demo in the posts, I need to add my own vanilla JS, which is a hassle to maintain, and I am not a very good developer. (Though Zola is excellent for completely static sites, much nicer than Hugo IMO.)
I want the site to have zero JS except the sprinkle of React components in the middle of otherwisr semantic DOM nodes for content. The fact that this was seemingly impossible in Next.js is just mind-boggling to me. Then I discovered Astro, which does exactly what I want, no more, no less. Only write markdown? Slap in the official Markdown plugin. Want latex math? Slap in the official remark/rehype plugins and katex stylesheet. Want react components in the middle of the post? Just import it into MDX files. The result? Absolutely no JS if there are no React components, otherwise
the only JS shipped is restricted to those components.
(That should have been the logical way to build frontend, and now Next.js is following Remix and Astro with its fine-grained component approach using RSC. Too bad the last time I tried the app router, all markdown plugins broke, while Astro is building my site beautifully.)
If you disable JavaScript in your browser and load my blog, you'll find the entire site works apart from the interactive components in the article! That's the only part that uses client-side JS.
I think people with an eye for design are going to be much more interested in showcasing that through their blog. In that sense it's pretty neat (and I'm curious about the Tailwind stuff used because I could see myself using that at work in future). Plus, the author's other stated goal was to try out some new hotness.
Of course, I'm not a designer myself so I would see all of this as overkill if I tried to do it. It's enough for me to write in org-mode and export my blog as HTML with a nice template. A static file server can handle a small bunch of HTML files at scale without breaking a sweat, so no need for the JS take on SSR or AWS Lambda functions or what have you.
Maybe this will show all the React/Next.js/Server components haters that you can use them to very quickly build pages that are very performant (though used stack isn't that important anyway, the result depends more on the user's effort and attention to details).
Well, if you use CSS blur and load even the most simple HTML page on old Android phone or full-screen on 4K screen, lag happens, but that's orthogonal to what I meant.
Again, because I'm boring like that: it's pretty hilarious to me that anyone would choose to make a new blog and not just use WordPress, especially when their stated aim contains this: "...that makes it as easy as possible to create posts".
There are some moments when you shouldn't use WordPress. A blog is not one of those moments.
Avoiding the obvious tool for the job is classic developer trendytool syndrome.
Not really, wordpress is a bit of nightmare to code upon and buying plugins and themes can result in incompatibility issues and vulnerabilities. I think Medium is easier, but it’s a walled platform.
Sorry to be argumentative, but it just isn't. It's PHP, and you probably don't need to code anything at all. You also don't need many plugins. Incompatibility issues and vulnerabilities just aren't a thing - as long as you keep stuff up to date and don't install a thousand dodgy plugins, you'll be fine.
And yes, this is what I do: maintaining 50+ sites for clients, so I have been round the block a few times, not just making this up.
It’s funny, I see it as entirely the other way round.
I see many on HN as being sort of “automatically negative” about Wordpress and php and unable to see that there are actually some times when they’re totally the right tools for the job.
I’d be the last person to suggest anyone use Wordpress for everything - yes, I happen to have a niche that is about this tool, and I like it and am passionate about it, and for what we do it’s highly relevant and very much the right tool - but we’re also very pragmatic about decision making.
What I see so much in developer land is that certain trends drive strategy. It’s so often not the boring, known, stayed tool which wins the day but the bleeding edge one which actually isn’t as good a fit.
As I say in a comment lower down here - the tradeoffs to me here are: no feed, no comments, no categories, no OG tags, no API - all of which are out of the box with Wordpress.
Ah, please tell me the easy way to include interactive js demos in wordpress like the blog post author has. It's obvious that the blogpost author wants a level of customization that wordpress can't offer.
Also, trying new technologies was literally a goal of the project.
> I mean, write a simple plugin that enables you to embed these using a shortcode
Ok, so learn php when they could just use js which they likely already know and likely get paid to know.
Wordpress and php are negative value skills, you do not want to advertise that you know those things as a developer because someone might try to hire you for them.
You've been hilariously accurate here—I was actually a WordPress dev for years, and now I don't mention it because I'm not interested in those jobs. Haven't even told any of my colleagues!
> Wordpress and php are negative value skills, you do not want to advertise that you know those things as a developer because someone might try to hire you for them.
It's the truth, the jobs that use php are not the ones I want to work in. People are saying php is actually good nowadays but I have no reason or desire to learn it. I don't want to learn or work with wordpress, I already know as many scripting languages as I need to know, and there are no companies I want to work for that use php.
I'm already in the part of my career where learning another programming language is not what will take me to the next level so unless there is something unique about a programming language that makes it very useful I'm not interested in learning it.
Learning how to use more tools is not necessarily better when you are already proficient in other more flexible tools.
Your personal view is not widespread though, your original message would have been better left off with out bashing PHP because YOU don't find a use for it.
There's billions of dollars in revenue generated yearly from PHP sites. And not just "legacy" either, I'm talking evergreen PHP apps being built and generating revenue.
It's just as alive and well if not even more alive than some other languages people prefer over it.
It means I, for example, wish I didn't know how to use WP and PHP so I didn't have to work on them in our legacy apps. Because I don't want to write or read PHP. I'm much happier when I don't have to. Get paid the same either way.
Again, pretty hilarious given how full featured and fast PHP is nowadays, but ok... I'm also gonna make a little private bet that PHP will outlast a fair amount of the currently trendy tooling...
I'm with you on the anti-PHP hate, but FWIW PHP and JavaScript came out exactly 6 months apart from each other, and one is the only way to code in the browser, so I'd say both are pretty likely to last a long time.
I don't know much about the PHP landscape but at least with Javascript it seems like trendy frameworks change every 5 years. JS -> JQuery -> AngularJS -> React -> Angular 2 -> React Hooks -> Next -> ... Feels like the "right" way to do things keeps changing.
The "right way" is subjective and the first mistake many people make IMO. What I think is the right way isn't always the right way for other people.
Tooling changing in JavaScript is unique to JavaScript only because of the language constraints. PHP, Ruby, etc are all controlled by the developer, whereas JavaScript is controlled by the browser vendors and end users of those browsers. You have more things to work around, inconsistencies to smooth over, and more importantly larger ambition on the frontend than most things can currently support, so new paradigms and frameworks come out to tackle that.
Also 5 years in internet time is a long time. So I'd probably not say it "changes so fast"
I was making a point that the best tool for the job can sometimes be the one which is widely used, hugely supported, cheap to host, well understood - it may not be the trendy choice, but "trendy" is not (in my humble opinion) a terribly good criteria for tech stack decisions...
It's not an interesting point, especially if you intend it as a tangential flamewar hook and, as you say yourself, you post it repetitively. The submission is not about 'tech stack decisions', it's somebody showing something they made. You don't have to like it or have much to say about it but a completely generic 'just use something else' is well within the scope of the guideline and a bunch of other ones.
…I’ll just leave this [0] here. A perfect example which just popped up in my feed list of “simple but does this job” tech. No js, no database, a $10 a month vps.
Author mentioned that the reason for the new blog is to be easier to create posts. But doesn't mention much of what changed in the workflow. Seems he's using md files. But then what was he using before? If MD->MD, then what changed? Using Obsidian to be easier to edit and sync between devices?
The author is in the thread so if these are your specific questions or critiques, you should direct them there. 'It's hilarious to me they don't use Wordpress' is not a specific question or critique, it's a generic sneery putdown.
Yeh, I get that - but then at the same time we have a web developers blog here with no RSS / feeds as far as I can see, no comments, no API, no OG tags - all the things one would expect from a blog. These seem to me a strange set of things to sacrifice in this context.
Wordpress is incredibly complex when compared to a static site that can be served ~entirely from a CDN. A database-backed blog has been outmoded now for years.
If you don't want a pre-built theme, you don't need the plugin ecosystem, and you don't need/want a WYSIWYG editor, there's no reason to choose Wordpress.
Eh, debating what's a "blog" and what's a "personal website" is splitting hairs.
Most "blogs" nowadays don't have the features you're talking about, because very few people actually care about them anymore. If you really want comments, you can add them via something like Disqus, but so few people are using RSS today that it's not worth bothering with.
The point I’m making is that we should choose tech that is relevant to the job in hand, not just because it’s the latest cool thing.
When I first started doing web stuff, ColdFusion, Perl, Flash and WAP were The Big Things at the time.
Not so much now.
It may seem like no-one can build anything on the web without having js through and through the stack - but actually you can, and sometimes you should. Even JavaScript will probably one day be relegated to the dustbin of a good idea we all once had…
Btw - this might be the wrong forum to diss RSS ;-)
It’s a blog post about rewriting/redesigning the foundation of his blog.
It would be titled “A New Blog Post for 2024” if all he did was write a new blog post. But if you read the blog post, you’ll see that he overhauled the entirety of his blog.
Maybe an analogy would help. If you’re a game developer and you replace the game engine of your game, you might update your in-game “about/credits” page to mention “in release x.y.z we switched from Unity to Unreal Engine” — what you wouldn’t do is say “in release x.y.z we updated this in-game ‘about’ page to, well… mention that we changed the about ‘about’ page to now state that we changed the ‘about’ page”.
The design language is (understandably) feeling a bit 2013 these days, but objectively I think it's held up great.
It's something I'd like to do for my blog, since I'm getting tired of looking at the same static header, but I've yet to come up with the perfect design.