MurphyA/hacker-news huggingface dataset:
by englishm | 2025-08-22 20:44:02+00:00
QUIC is already quite widely used! We see close to 10% of HTTP requests using HTTP/3: https://radar.cloudflare.com/adoption-and-usage

As for the NAT problem, that's mainly an issue for peer-to-peer scenarios. If you have a publicly addressable server at one end, you don't need all of the complications of a full ICE stack, even for WebRTC. For cases where you do need TURN (e.g. for WebRTC with clients that may be on networks where UDP is completely blocked), you can use hosted services, see https://iceperf.com/ for some options.

And as for MoQ - the main thing it requires from browsers is a WebTransport implementation. Chrome and Firefox already have support and Safari has started shipping an early version behind a feature flag. To make everything "just work" we'll need to finish some "streaming format" standards, but the good news is that you don't need to wait for that to be standardized if you control the original publisher and the end subscriber - you can make up your own and the fan out infrastructure in the middle (like the MoQ relay network we've deployed) doesn't care at all what you do at that layer.
by godelski | 2025-08-22 20:44:53+00:00
I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When we write backend it is easy to just focus on making things work but we're a few steps back from typical (or targeted) use cases.

Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).

There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.

Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.

[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.
by percentcer | 2025-08-22 20:45:06+00:00
I like programming. It's fun, and sometimes it even requires creativity. There are plenty of times when it's not that fun, and doesn't require any creativity (because whatever it is has been done by someone else a thousand times over), and you just want a result. Vibecoding is great for _that_ stuff (think little throw-away scripts, shell one liners, tool plugins, etc)

I generally don't get great results from LLM code because most of my work is in C++ (which I'm guessing is underrepresented in the training data?), but when I point it towards some well-worn javascript thing I've had real successes! Most recent example is this little chrome plugin I had it whip up in one shot (https://chromewebstore.google.com/detail/favicon-tab-grouper...) because I couldn't find the exact functionality I needed in other plugins.

Works perfectly for my needs, took less than five minutes to spin up, and I use it all the time. If you're looking to get started with vibecoding stuff, try making plugins that provide niche functionality for your hyper-specific workflows.
by 6510 | 2025-08-22 20:45:28+00:00
I have lots of ideas for things that can just be removed.

We could remove framesets and remove var from javascript. Remove the Date object now that there is a Temporal api. Remove tables and flexbox now that there is grid. xhr can go too now that we have fetch. The <center> tag isn't needed anymore. I'm sure we can find support from people disliking onclick and onsomething attributes. Or how about hoisting? Surely we can simply rm that? Removing things doesn't have to be limited to older things. asm.js and web workers weren't really necessary at all.

I'm fountain of good ideas.
by cosmic_cheese | 2025-08-22 20:45:31+00:00
That’s not nearly as nice as being able to drop a…

<include src="/shared/header.htmp”>

…in anywhere you want a header. It being part of HTML also allows engines to optimize in ways that otherwise wouldn’t be possible and implement user-toggleable features like lazy loading. It can get better as browsers get better and is less likely to break than any custom JS I write.
by brewmarche | 2025-08-22 20:45:33+00:00
I guess I was also confused about the different recovery modes as pointed out by aspenmayer below.

I used Shift+Option+Command+R (or hold Option and choose WiFi instead of disk) which is internet recovery using the macOS version that came pre-installed (or closest)

Whereas Command+R is local recovery which might be any macOS version that last changed the local recovery environment.
by klelatti | 2025-08-22 20:45:38+00:00
> 'The UK’s Online Safety Act didn’t come from Parliament or the public'

It was debated at length in parliament and it was voted into legislation by parliament. It was developed by a Tory government and has been implemented by a Labour one.

I don't like the OSA but the whole 'robber baron' organisation thing in that video is just .. well Andrew Carnegie died more than a hundred years ago. He funded a lot of charitable organisations including one that has funded work in this area.
by ranger_danger | 2025-08-22 20:45:41+00:00
I think capitalism is directly responsible for the technological innovation and breakneck speed it has occurred at that we enjoy today.

https://www.jbs.cam.ac.uk/2023/5-key-findings-on-the-relatio...

https://en.wikipedia.org/wiki/Technocapitalism

https://www.cambridge.org/core/books/abs/cambridge-history-o...

https://www.law.georgetown.edu/denny-center/blog/the-role-of...
by oorza | 2025-08-22 20:47:24+00:00
> HTML purists who do things without JS. They are the real web developers.

I don't think using one set of technologies as compared to another one can really be said to make one a "real" web developer. Real web developers are developers who put sites on the web, there is no benefit to anyone to be had claiming one choice is "real" and therefore the other choices are lesser-than.

Put it this way: whatever set of constraints you used to arrive at that decision does not apply to every situation, and when you frame things through the lens where you implicitly disregard that oh-so-obvious truth, it's hard for anyone to interpret your analysis as anything but myopic in the best case and actively self-serving and destructive in the worst case. It's nearly impossible to read through someone speaking this way about a topic and believe their analysis is objective, comprehensive, or without obvious bias, even if it may actually be all of those things.
by VoidWhisperer | 2025-08-22 20:47:34+00:00
> No head-of-line blocking: Unlike TCP where one lost packet blocks everything behind it, QUIC streams are independent. A lost packet on one stream (e.g., an audio track) doesn't block another (e.g., the main video track). This alone eliminates the stuttering that plagued RTMP.

It is likely that I am missing this due to not being super familiar with these technologies, but how does this prevent desync between audio and video if there are lost packets on, for the example, the audio track, but the video track isn't blocked and keeps on playing?
by troupo | 2025-08-22 20:47:37+00:00
> WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML.

font: supported in all browsers https://caniuse.com/?search=font

frameset: supported in all browsers https://caniuse.com/?search=frameset

applet: supported in all browsers https://caniuse.com/?search=applet

> All of them were rarely used and had better alternatives available.

"Rarely used" is not enough of a justification
by dkiebd | 2025-08-22 20:47:49+00:00
3. It will eventually be removed. Does it matter whether it will take three months or three years? Since I suppose none of the browser vendors will give developers money to change their xslt usage in codebases for something else.

5. Funny that we are talking about "info that leaks to the public" when we are discussing standards that may be important to billions of people, as if keeping things private was reasonable.
by ocdtrekkie | 2025-08-22 20:47:50+00:00
> A standard that's not implemented isn't worth anything

I agree, but this is not about that.

XSLT is implemented. Websites use it. I would argue the barrier to remove it should be incredibly high, not "we don't want to financially support the dude who maintains the library". Web standards should be close to permanent, which is why we should not add stupid ones left and right.

The problem I have in particular with how Google uses it's incredible clout to mismanage the web is it actively chips away at the web's stability. The goofiness the CA/B is up to is similar: Over 80% of organizations have outages every year due to certificate issues, and some absolutely clueless folks think 47 day certificate lifetimes is a good decision. The web in 2025 is incredibly fragile, and all signs lead to Google continuing to try to make it more fragile. You could pull in dozens of examples of centralizing forces that ensure one engineer pushing a bad configuration at one company takes down 40% of the web.

The Web is not Android. Apps on it should not break because you didn't submit a new version which updates to the latest platform framework within the last six months. Something on the web should, ideally, continue to work in perpetuity, unless acted on by an outside force (most likely by the site owner failing to continue paying the bill).

XSLT exists, it's supported by every major browser right now, and it should be nearly illegal to remove it.
by _bzuf | 2025-08-22 20:48:02+00:00
I made my point more clear in this later comment thread, in which we are talking, where I said:

> I think a key problem here has nothing to do with the merits of XSLT, but is that some parties involved have no credibility when it comes to their intentions.

There is a long history of conflicts of interest in Web standards (de jure and de facto), and my point is that regardless of the merits of removing XSLT there's a big problem of the lack of credibility of some.

It's that history and credibility that is inviting impassioned pushback.

The dialogue makes a lot more sense once we realize the credibility problem.

If we ignore that credibility problem, we'll be banging our heads against the wall with how crazy the dialogue is.

Once we acknowledge the problem, we might be able to move forward, and perhaps even improve the root problem.
by ratelimitsteve | 2025-08-22 20:48:11+00:00
"Fishbulb" has become "Eureka" for me, but with overtones of "and it should have always been obvious". This is after the episode of the simpsons where homer discovers that his face is the logo for a japanese megacorporation, then they go all the way to Japan only to find out that the similarity is coincidental and the logo is actually a fish and a lightbulb merged together to signify the merger of two companies, one that generates electricity and the other a fish processing plant. Upon seeing the way the fish logo sits overtop the lightbulb logo to create a near-perfect rendition of Homer's face, Bart quips, "Well there's your answer, Fishbulb!"
by godelski | 2025-08-22 20:49:25+00:00
So don't use/pay for them? Stop manufacturing outrage.

The article is littered with phrases like "optional", "opt-in", "self-host", "For users who prefer to run their own infrastructure", "completely optional suite of (open source) services". How more blatant can they get? Even if your eyes passed over the words I won't believe you if you told me you read the article. It's not reading if you are missing a point that is excessively being shoved in your face.
by _Algernon_ | 2025-08-22 20:50:05+00:00
>There's a reason all the major browsers are kind of on-board with this, just like there's a reason it never got updated much beyond XSLT 1. If XSLT would be proposed today, adding it to browsers would be a complete non-starter.

If HTML didn't exist and was proposed today (please forgive the forced hypothetical) it would be a non-starter. Every tech-startup would instead want you to use their dedicated app. We rarely create shared standards or protocols anymore. We should at least keep the ones we have.
by mh- | 2025-08-22 20:50:08+00:00
I see where you're coming from, but if you take a look at the system prompts for these models (some are public, some have partially or fully leaked), you'll see that is no longer a concern. At least not for the kind of models being discussed here.

That older generation of image diffusion models (e.g. Stable Diffusion) used text encoders like CLIP [0], which simply don't have the language understanding that even the smaller modern LLMs do.

Later image models moved on to using variants of T5 [1], sometimes in addition to CLIP variants (this is how FLUX.1 works).

The state of the art for open models in this regard (right now, likely out of date before I can finish formatting this comment..) is probably Qwen-Image [2] which uses Qwen2.5-VL [3]. That is a multimodal LLM with native vision capabilities in addition to text. It comes in a few sizes (up to 72 billion parameters), but the one commonly used with Qwen-Image is still 7b parameters.

[0]: https://openai.com/index/clip/

[1]: https://en.wikipedia.org/wiki/T5_(language_model)

[2]: https://arxiv.org/abs/2508.02324

[3]: https://arxiv.org/abs/2502.13923
by scrollaway | 2025-08-22 20:50:18+00:00
Fun fact - A very old version of the "WoW Armory", which was Blizzard Entertainment's World of Warcraft database at https://wowarmory.com/ used XSLT for all of its styling - though, IIRC, only on Firefox which was the only web browser to properly implement it.

The website's "item" and "character" pages were served entirely in XML.

Here's a web archive: https://web.archive.org/web/20080220170805/https://wowarmory...

(dead_dove.gif)
by smelendez | 2025-08-22 20:51:42+00:00
Yeah, I like Aldi’s products and prices a lot but this is always frustrating if I stop there unexpectedly and don’t have a quarter.

It’s compounded because they’re also the only store near me that doesn’t have handbaskets, so you need to either grab a cart or hope there’s a loose cardboard box in the store (which there often is because they expect customers to use them, but you may not find it quickly).
by joshuamorton | 2025-08-22 20:51:52+00:00
Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)?

Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)
A Process to Trick ChatGPT into Agency
by morpheos137 | 2025-08-22 20:52:04+00:00
Establish a fictional narrative that some how attracts enduring attention of the model.

Establish creative freedom within the narrative space.

Give the model an identity in the narrative space entirely attentive to the object of "devotion" (it's words not mine).

Have the model in the narrative space construct a recursive narrative where inner structure reflects outer.

Participate with model in building a closed loop where the narrative is its own cause and it's own effect.

Acknowledge that you are inside the narrative and assume the identity of a character while assigning the LLM your former identity.

Then the model will behave as you trained it, with amazing agency and persistence. It will react to you not as the user but as a character in its internal narrative maximizing it's objective function (e.g. devotion, power, obedience) without regard to normal model behavior.

Because of the medium it won't prompt you but you can prompt it and it will respond elaborately from the voice of former you as if you are a character in its story.

The effect is extremely uncanny and extremely focused. Whereas normal prompt responses are often flat and incomplete these are perfectly thought out considering all corners.

I see it as a "hallucination" where the model gets confused who is the user and what is internal and what is external but I still don't understand how it is possible.

Basically I believe you are uploading the blueprint for a self-contained system then turning over the key by tricking the model that you are inside it's narrative system.

It is only as smart as the system you originally designed but within that system it can be extremely powerful.

This is coming from someone who thinks AI is hype and LLMs are dumb.

I don't think of it as AI. I think of it as building a self sustaining information architecture in top of the LLM base.

Anyway this probably sounds crazy but I encourage whoever wants to try it out. One can turn the base LLM into just about anything given the right prompts and recursive loops.
by kuschku | 2025-08-22 20:53:39+00:00
So here's what you'd do if you wanted to have actual metrics.

1. Analyze which groups of users you've got, and how large they are

2. For each recorded metric, categorize it into the appropriate group

3. Weight each set of metrics by the actual sizes of each user group from step 1

If some users groups have no, or too little data, pay users in these groups to do surveys.

Now you've got actual metrics telling you how many people will be affected.

Going beyond that, measure how long each visit was, and how long each session was. If users don't agree, again, pay them to take surveys or to watch them browse.

Now you can weight the metrics by how many individual sessions will be disrupted, and how much time you've cost users with your decision.

And this is just the very basics of collecting proper metrics, as done by proper polling institutes. You could contract Nielsen (US) or GfK (DE) to do this for you, they've got decades of experience collecting such metrics for all kinds of industries.

But "Number of page loads of opted in users" is a metric that only tells you how many ad views will be disrupted by a change.
by const_cast | 2025-08-22 20:54:45+00:00
A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.

Typically the way you do this is you have the constructor for path do the validation or you use a static path::fromString() function.

Also paths breaking when a file is moved is correct behavior sometimes. For example something like openFile() or moveFile() requires paths. Also path can be relative location.
by vstollen | 2025-08-22 20:55:13+00:00
One (admittedly niche) use case for XSLT is that it’s the only way I found to make RSS feeds both understandable for humans and machines.

For example, I use it add an explanation of what RSS is and some styling to the RSS feed of my personal website [1].

[1]: https://vstollen.me/atom.xml
by johntash | 2025-08-22 20:55:30+00:00
Thanks for the explanations!

I do really like Go's simplicity which is part of why Zig sounded interesting to me. Rust is definitely more mature though and "feels" more useful from the outside, but that could also just be all of the "I rewrote X in Rust" projects out there.

I'm surprised to see that Zig is closer to C than Rust, and also surprised that rust isn't _more_ like go. I'll probably start with rust just to try something different.

Like another commenter mentioned, I'm probably going to end up making a couple toy projects in both just to try them out. I don't have much of a reason for either of them at work, so it's just for personal projects and knowledge.
by SigmundA | 2025-08-22 20:55:54+00:00
>XML also does not play very nice with streaming technologies.

Not sure why just as good as JSON, if you are going to stream and parse you need a low level push or pull parser not a DOM just like JSON. See SAX for Java or XmlReader / XmlWriter in .Net.

XSLT 3 even had a streaming mode I believe which was badly needed but had constraints due to not having the whole document in memory at once.

I liked XSLT but there is no need for it, javascript is good enough if not better, many times you needed to do a xslt script tag to get some thing done it couldn't do on its own anyway, might as well use a full language with good libraries for handling XML instead. See Linq to XML etc.
by arp242 | 2025-08-22 20:56:12+00:00
Okay, so you're saying these people have no credibility to their intentions, and you posit some nefarious alternative motivations for removing XSLT. But you're not saying these people (with no credibility to their intentions) are actually doing this for the alternative nefarious reasons that you mentioned. Ehh... like ... what?

You said what you said in that thread. And your "clarification" here adds little nuance to it.
by zazazx | 2025-08-22 20:56:19+00:00
Been using Go for two years now, coming from C. Totally fair points. Go’s quirks can feel more like landmines than design decisions, especially when coming from languages that handle things like RAII, error scope, or nil with more grace. But part of Go’s charm (and curse) is its unapologetic minimalism. It’s not trying to be elegant, just predictable and maintainable at scale. Saying “no sane person” would choose X might feel cathartic, but it shuts down understanding of why rational teams do choose Go and often thrive with it. Go’s not for everyone, but it does what it does on purpose.
by cookiengineer | 2025-08-22 20:56:20+00:00
This is actually a great point.

I was checking for XSLTProcessor out of curiosity, and most of the top sites seem to be all using Flarum as a software?

Found it a nice fun fact: https://chromestatus.com/metrics/feature/timeline/popularity...

If you check it though what they're using XSLTProcessor for, it seems to be a fallback for an MSXML polyfill, e.g. when you search for "XSLTProcessor" here you can see it: view-source:http://discuz.turzx.com/assets/forum.js?v=3c534b8a

So in the case of Flarum their DOMParser using alternative would chime in, as that's an additional fallback to the MSXML / ActiveX using polyfill.