This is a cool project, and to render Simon's blog will likely become the #1 goal of AI produced "web browsers".

But we're very far from a browser here, so that's not that impressive. Writing a basic renderer is really not that hard, and matches the effort and low LoC from that experiment. This is similar to countless graphical toolkits that have been written since the 70s.

I know Servo has a "no AI contribution" policy, but I still would be more impressed by a Servo fork that gets missing APIs implemented by an AI, with WPT tests passing etc. It's a lot less marketable I guess. Go add something like WebTransport for instance, it's a recent API so the spec should be properly written and there's a good test suite.

Is there any data on which AWS regions are most reliable? I feel like every time I hear about an AWS outage it's in us-east-1.

Disclaimer: it's possible XSLT got better over time, although I doubt it.

I actually wrote a whole app that used XSLT back 25 years ago, even backed by an XML database! Super hip (tech stack wasn't my choice).

XSLT is bad tech and you shouldn't use it. The modern equivalent is React+JSON which implements many of the same ideas in a much better way. And I say that as someone who isn't a big React fan but who has used both. It's not a coincidence that this example is for a 1999-era static blog; it's about the limit of what you can do with this tech.

The core idea of XSLT is to provide a functional transform from an app-specific model to a view, where both are expressed in XML. It does that by asking you to supply templates that match patterns in the original data structure. This idea has some deep flaws:

1. The syntax and generic data model used to express your app's own model has to be XML, but XML is descended from a line of technologies intended to express views. XML-based languages are a competent enough way to express a view which is why React invented JSX, but they are less natural for expressing data structures. Modern apps use JSON for expressing data structures which is also far from ideal but it's still an improvement over XML.

2. Transforms from data to view can be arbitrarily complex. React uses a regular imperative programming language with some additional rules to make it "functional-ish", XSLT gives you XPath and what is basically an XML syntax for something a bit like Haskell. Expressing complex transforms is very awkward in this language. Something as simple as a for loop over a list - very easy in JS - requires you to think in pure functional terms in XSLT.

3. Modularity? Debugging? Nope. It's Web Tech, what do you expect? If you make a syntax error you might get a parse error if you're lucky, if you make a logic error you get to sit down with a pen and paper to work out what might be going wrong. Because it's a functional transform rather than a programming language there isn't even really printf style logging. And IIRC there's no such thing as XSLT libraries.

4. There is no solution for interactivity. Mutating the model might yield retransformation depending on implementation (I don't know for modern browsers, I think I mostly tested on IE6 back in the day). If it does, it'll be a retransform of the entire document that blows away any changes to the DOM. But if you want actual app-level state in UI components that efficiently re-render, then you're just out of luck, you have to mutate the generated HTML DOM directly as if XSLT didn't exist at all.

5. There is no functioning protocol for controlling server-side rendering or not (in practice most XSLT based apps give up on browser rendering pretty quickly). Soooooo the original motivation of exposing the app's data structures directly allowing machine-readable access to data, does not actually apply in practice, because there's no systematic way to ask the server to give you the raw XML. Sure a tiny number of servers might actually serve you something different if you use an Accept header with text/xml up front, but even when XSLT was hip apps that did that in the wild were unicorn poop. People claimed they saw one once, but I never actually tracked down a real server that did it.

This blog demo could have been implemented using Preact and the results would be better. The view logic would be much easier to read and write. The underlying data would be a JSON file, or perhaps a combination of JSON and Markdown, i.e. syntaxes designed for the convenient expression of data and marked up text. The browser would still take care of rendering, and the server could easily do the render work up front to make things snappy by avoiding extra roundtrips. The advantage would be that debugging, modularity and retransformation for interactivity all work well.

This send me into a whole rabbit hole. Mostly children get paracetamol overdose. Then I learned that in US/UK kids get paracetamol in liquid form with all kinds of flavours. Which is much harder to dose correctly when the kid spits or drools it out.

Total culture shock for me, as in Europe the default for children is rectal ingestion (which is probably a culture shock as well for Americans). Any how, with pills it is much easier to avoid overdose.

I am familiar enough with the numbers that I am not necessarily surprised, but I still find it emotionally hard to grok that more than one in five would-be paracetamol suicide victims would be dissuaded by having to pop the pills out of a blister pack first.

The idea that you must retire from tech before 50 is so incredibly false I have difficulty believing this view is even shared here.

Perhaps in some of the "trendy" "bro-culture" startups you'd have a more difficult time as an older developer but even in those places, the level of experience and skills older devs bring can be extremely valuable.

But say you were laid off in your 40's, now what? Well, there are so many bigger, less volatile companies out there with solid pay that are desperate for senior people with experience. There's also consulting for those who have spent a career building up a network of contacts. You can still leverage those old contacts for future opportunities as well.

Governmental work and such is also a place where age is not a concern. Here I agree you might not make as much money but employment is always available to developers who are skilled, experienced and flexible.

I just recently encountered the urgent necessity for the additional income, so I didn't really tried much until now. Another thing I'm thinking about it teaching kids computers and some mathematics, but I also don't know how to start here.

Wow, just look at the number of pills he takes every day: https://protocol.bryanjohnson.com/#step-2-supplements

And then apparently the same dish, every day... definitely a very scientific approach.