I’ve recently read the third edition of Bjarne’s “A tour of c++” (which is actually a good read). I feel the author of this post could benefit from doing so also.

I really like the concept of this. I'd love a html reference guide (pattern library?) with plain html no CSS or JS to document the basic building blocks of the web.

I’d rather be explicit. If the value is null then it should be explicitly handled.

I feel like this is another step in the race to add every conceivable feature to a language, for the sake of it.

This is explicit though. The question mark operator is the developer explicitly asking for this behavior.

> What seems wasteful to me is to have the server spend CPU cycles rendering data into JSON, only to have the front-end decode from JSON into internal JS representation, then back into HTML (which is then decoded back into an internal browser representation before being painted on the screen). Seems better to just render it into HTML on the server side, if you know what it's going to look like.

Well put. I think the main issue is that we have a generation of "front end engineers" who have only ever worked with javascript apps. They have no experience of how easy it is to write html and send it via a server. The same html works now, worked 20 years ago, and will work 20 years from now.

This is why many websites (even ones light on interactive functionality) now display a progress bar after loading the website. It's a big step backward for user experience and I even see it on blogs.

Your average veteran "front end engineer" has implemented las month half a dozen features that almost impossible to do server-side only, "just send the HTML, dude".

Progressive enhancement, forms with fields depending on other fields, real time updates, automated retries when the backend is down, advanced date selectors, maps with any kind of interactivity.

Any of the above is an order of magnitude harder to do backend-only vs backend API + any frontend.

Who says you can't use any JS when doing server side rendering?

And why would you even want progressive enhancement if you can just send the proper full version right away, without waiting for MBs of JS to "hydrate" and "enhance" the page

You know, you went direct for the "bait" case, while ignoring all the others.

Progressive enhancement is often done to mask the fact that fetching the data takes an unacceptable amount of time, otherwise no effort would be done to mask it.

Your plan is to take that same unacceptable time, and add the server side render-to-html time on top of it, and that will improve it via...

The server rarely has to render/build the html. It will do it once and then cache it. 99% of websites don’t have real time data. They are just boring webpages.

The GUI of an OS has never concerned me. Seems like a red flag when the main selling point is a slight bit of transparency.

Well, that's why there is a lot of complaints.

The main selling point of a macbook is not a UI with transparency. It's hardware stuff (like ARM processors, battery life, aluminum frames, etc..) and a decent, stable, unix-ish software environment. No one is using macOS for the visual effects, so it is annoying that Apple is revamping the UI everyone is used to in order to add more visual effects.

Seems nuts to me, but I'll be curious to see how this all pans out.

The new Spotlight seems like a strong selling point for power users.

I use html and server side rendering. The whole react thing has passed me by. If I need to use a js framework to add interactivity it’s Alpine. But then I just ask myself the question? Is this bad design? And if the answer is yes, I look for a vanilla html approach. Bye the way... the answer is always yes.

Yeah, I have to admit I don't really understand the need for front end frameworks in 2025 with how fully featured vanilla JS and CSS are.

With web components and a little bit of good architecture you can sidestep most front-end complexity. And server-side rendering dramatically simplifies state, because your state is now the database.

How many times will Tufte CSS be reposted?

I feel like I see this every year. Unfortunately I like it less every year too.

I think posting Tufte CSS, upvoting it, and complaining about it in the comments is a bit of an HN tradition at this point. Here's the first iteration from ten years back: https://news.ycombinator.com/item?id=10012360

Was going to say maybe time to add a (2015) to it, but it does look like there's been incremental updates in recent years with tweaks and things like dark mode etc.

Looks like about every 18 months.

I suffer from this. I even get as far as nearly finishing a project, and then just decide to abandon it as the last 20% is just mentally exhausting, and I should have written the whole thing in language X using framework Y…

Haha that's the legendary 80/20 curve of a sidegig ;) As i grew older i just do the work when i feel it. When i don't feel it after a few days i stop working on it. The feeling may come back but i won't force it like my younger self would do.

Well said, Zed could be great if they just stopped with the AI stuff and focused on text editing.

Wait until they find out about PHP. Mind blown.