Let's say you're about to embark on a cross-oceanic sailing voyage. For safety reasons, you think it's best to bring another living being with you who can help if things go south or you are incapacitated.
Are you going to bring another human, or a goat? Can a goat navigate while you sleep? Can it apply first aid to you? Can it respond on the VHF radio if you get hailed? Can it operate the bilge pump?
First sentence of the Wikipedia article for Node.js:
> Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more.
First sentence for the Wikipedia article Deno:
> Deno is a runtime for JavaScript, TypeScript, and WebAssembly that is based on the V8 JavaScript engine and the Rust programming language.
First line of hero text from Node.js's site:
> Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.
First line of hero text from Deno's site:
> Deno is the open-source JavaScript runtime for the modern web.
The question is not whether MacOS is ahead of Windows. As an Apple user since the Apple IIe, I agree it's still the best OS by a mile.
But that has basically always been true, at least since Mac OS X. (I liked the earlier OSes too, but they really did crash all the time and have no memory protection, so arguably Windows had some compelling advantages.)
The interesting question is whether recent MacOS releases are ahead of their previous versions. Of the top of my head, I can't think of a single feature that MacOS has shipped since 2020 that I care about. Maybe dark mode?
The hardware keeps better, and the experience of third-party apps I care about (VS Code and Ableton) is superior to Windows. But the OS and first-party apps seem completely stagnant.
Which, arguably, is OK. Maybe the OS should just be a commodity. But I have to imagine that there are user experience improvements they could make at the OS but I certainly haven't seen any.
I'm not so sure about that, modern Linux is pretty good — I was able to configure it to fit my needs much better than I could a mac. It's also free of dark patterns (looking at Windows).
If you're willing and able to configure Linux, I would say that, for some people, it's much better than a mac.
One of the main things I run on my Mac is Ableton Live, so Linux is a no-go.
Also, I'm no longer the kind of person who really wants to tinker with an OS set up and doing a lot of manual configuration. I just want a decent user experience out of the box and good connectivity with all my various peripherals.
I wish I could disagree, but Microsoft won't let me thanks to their determination and speed in destroying what was good about Windows.
Right now I find myself forced to use macos for iOS dev, and Windows for gaming-adjacent stuff. For the first time in 33 years, I truly wish I could just have Linux everywhere.
Granted it's not a giant list, but each release does have little refinements here and there, and Claude may have missed some (it didn't mention container CLI, for instance; that was from my memory). I also omitted some features I don't care about (like Safari profiles and some other window management stuff).
What features are you hoping for? Aside from a tiling WM, which won't happen, I'd be happy just with refinements and bug fixes.
It was good when we had social networking, and it got bad when that turned into social media.
The point should be connecting people to other people and their creativity, not just connecting people to content which may or may not be vomited out by generative AIs.
Agreed, they aren't all huge, but they are all pretty big and the few that aren't huge sacrifice a lot of bed size.
I'm going through this now because I'm looking at upgrading from my ancient 2002 Tacoma Xtracab. Here's compared to 2025 models:
Vehicle Length Bed
---------------------------- -------- -----
2002 Toyota Tacoma (Xtracab) 202.9" 74.5"
2002 Toyota Tacoma (2Dr) 184.4" 74.5"
2025 Maverick 199.8" 54.4"
2025 Honda Ridgeline 210.2" 64.0"
2025 Hyundai Santa Cruz 195.7" 52.1"
2025 Toyota Tacoma Xtracab 213.0" 73.5"
My Tacoma wasn't even the shortest you could buy back then and it's still shorter than half of the "small" trucks you can buy today. And unlike those, my truck has a full 6' bed. A Maverick is shorter than mine, but the bed is also nearly two feet shorter. I honestly don't see the point of a bed that's less than five feet long. At that point, it's just an SUV with a trunk that isn't weather-sealed.
Now, granted, it's not like you get nothing in return. These new vehicles (except the new Tacoma Xtracab) all have four doors and full-sized back seats. I can fit a kid in my jump seats but anyone older than that has a bad time. I'm sure they're safer for everyone in the truck too.
But if you really do want to prioritize bed size and still want a short vehicle, that option is just no longer well supported. I accept that my use case is probably a narrow one:
* Live in a dense city with a lot of parallel parking so don't want a long vehicle.
* Kayak fish a lot so want a long bed I can load a kayak in.
* Can get away with a two-seater because we can use my wife's car when there are passengers.
But it's definitely not as well served as it used to be. I'm probably going to end up with a short-bed Tacoma and rely on a bed extender to keep the kayak safe.
For what it's worth (maybe not much from an internet stranger), I couldn't possibly overstate how much I love my Ridgeline. I love the trunk under the bed, I love how the back seats fold up for extra in-cab cargo space, and I love how the unibody structure and independent rear suspension make it drive like a car. It's comfortable enough that I can use it happily for longer road trips.
I love it so much that when it was stolen on a trip to Montreal a few years ago, I bought the exact same year and model again without even googling other options.
It is a bit longer than I'd prefer--I live in urban Chicago and occasionally do have to forgo a good parking space, but usually those are, like, Honda Civic spaces that a slightly smaller truck wouldn't fit into either.
I didn't seriously consider the Ridgeline because it's, uh, kind of funny looking, but you are making me take another look. Thanks, I'll do some research.
Why get rid of your perfectly fine truck? People would be lining up around the block for your truck. As you say they don’t make them like that anymore. Here in socal there are still 70s-80s era ford and chevy trucks in service. Those old f150s look tiny today. And in major demand even if they aren’t prestine.
The answer is sad. Last year, I destroyed my left ankle when I slipped in a puddle while biking to work. Even after three surgeries and tons of physical therapy, the joint is falling apart. I drive a stick and it hurts every single time I push the clutch pedal in, so I've accepted that I have to move to an automatic.
> People would be lining up around the block for your truck.
You're not lying. I'm the only owner and it's got barely over 100k miles on it. Every few years, I find a note on it from someone asking if I'm interested in selling.
The kids joke that I love that truck more than them.
It has been a really amazing vehicle and I've had a ton of fun in it. But I'd be lying if I didn't say that it would be nice to have, you know, anti-lock brakes and a back-up camera.
> you don't actually have to form a consensus. You can split off whenever you want.
This is true and is a key property of open source.
But it's also true that network effects and economies of scale are key for how open source projects provide value to their users. Those effects mean that the value an open source project provides to its community is often super-linear relative to the number of users.
A concrete example: If someone writes a blog post about how to use some feature, every other user of the feature can benefit from it. But also every user can potentially write this kind of documentation. So the value people provide through documentation is very roughly quadratic in the number of people reading and writing docs.
Because value like that scales super-linearly with the number of people in the ecosystem, breaking a community in two can result in less total value even if the total number of users of both communities put together is the same.
If you fork and the forks diverge, now a given bit of documentation may only be relevant to one side of the fork. A given person writing some docs may documenting things that are only true for one fork.
> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages.
Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?
I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortable with HTML", "not comfortable with JavaScript", and "able to ramp up on XSLT" is pretty small.
At some point, we have to just decide "sorry, this use case is too marginal for every browser to maintain this complexity forever".
> Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?
Hi! I'm a non-programmer who picked up XSLT of my own volition and spent the last five-ish years using it to write a website. I even put up all the code on github: https://github.com/zmodemorg/wyrm.org
I spent a few weeks converting the site to use a static site generator, and there were a lot of things I could do in XSLT that I can't really do in the generator, which sucks. I'd revert the entire website in heartbeat if I knew that XSLT support would actually stick around (in fact, that's one of the reasons I started with XSLT in the first place, I didn't think that support would go away any time soon, but here we are)
For what it's worth, you can still run an XSL processor as a static generator. You of course lose some power like using document() to include information for a logged in user, but if it's a static site then that's fine.
I eventually started using server-side XSL processing (https://nginx.org/en/docs/http/ngx_http_xslt_module.html) because I wanted my site to be viewable in text-based browsers, too, but it uses the same XSLT library that the browsers use and I don't know how long it's going to be around.
> Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?
Admittedly this was 20ish years ago, but I used to teach the business analysts XSLT so they could create/edit/format their own reports.
At the time Crystal Reports had become crazy expensive so I developed a system that would send the data to the browser as XML and then an XSLT to format the report. It provided basic interactivity and could be edited by people other than me. Also, if I remember, at the time it only worked in IE because it was the only browser with the transform function.
Funnily enough, XSLT is one of those things that I don't know very well but LLMs do. I find that I can ask Gemini to blurt out an XSLT implementation of my requirements given a snippet of example doc, and I have used this to good effect in some web scrapers/robots.
I was such a non-programmer as a child, yes. At the time that XSLT was new, if you read a book on HTML and making web pages from the library, it would tell you about things like separating content from styles and layout, yes. Things that blew my mind were that you could install Apache on your own computer and your desktop could be a website, or (as I learned many years later) that you could make a server application (or these days now Javascript code) that calls a function based on a requested path instead of paths being 1:1 with files. By contrast, like I said XSLT was just a natural extension of HTML for something that everyone who's written a couple web pages wants to do.
The fact that the web's new owners have decided that making web pages is too marginal a use-case for the Web Platform is my point.
Yes that's why XSLT is such a natural fit when you learn about HTML+CSS. It's the same idea, but applied to HTML templates, which is something you immediately want when you hand-write HTML (e.g. navbars, headers, and footers that you can include on every page).
Your problem here is that you're hand-writing HTML including all the templates. This wasn't a good way to do it 30 years ago and it's not a good way to do it now.
See all these "static site generators" everyone's into these days? We used those in the mid-90s. They were called "Makefiles".
Yeah because I was 11 and didn't know what a Makefile was. That's my point. I wanted to make web pages, and didn't know any programming. HTML is designed to be hand-written. You just write text, and when you want it to look different, you wrap it in a thing. When doing this, you'll quickly want to re-use snippets/invent your own tags. XSLT gives a solution to this without saying "okay let's back up and go learn how to use a command line now, and probably use an entirely different document format" (SSGs) or "okay let's back up and learn about functions, variables, classes, and callbacks, and maybe a compiler" (Javascript). It just says "when you want to make your own tags, extract them into a 'template' tag, then include your templates just like you include a CSS file for styles".
I've seen non-programmers learn SQL, and SQL is far more inconsistent, complex, non-orthogonal, fragmented, footgunny, and user hostile than most programming languages.
I'm not sure what I mean by this, WRT XSLT vs Javascript.
Are you going to bring another human, or a goat? Can a goat navigate while you sleep? Can it apply first aid to you? Can it respond on the VHF radio if you get hailed? Can it operate the bilge pump?
reply