I wish they'd consider adding lighter pages. Compare the load time of a NYT page [1] to a text NPR page [2]. I'm seeing 5.5 seconds vs 600 ms. I think the latter is easier to read as well.
> The Monolog is our new source of truth for published content. Every system that creates content, when it’s ready to be published, will write it to the Monolog, where it is appended to the end.
> The Monolog contains every asset published since 1851. They are totally ordered according to publication time. This means that a consumer can pick the point in time when it wants to start consuming. Consumers that need all of the content can start at the beginning of time (i.e., in 1851), other consumers may want only future updates, or at some time in-between.
> As an example, we have a service that provides lists of content — all assets published by specific authors, everything that should go on the science section, etc. This service starts consuming the Monolog at the beginning of time, and builds up its internal representation of these lists, ready to serve on request. We have another service that just provides a list of the latest published assets. This service does not need its own permanent store: instead it just goes a few hours back in time on the log when it starts up, and begins consuming there, while maintaining a list in memory.
Absolutely insane. The only reason this works is that the NYT publishes less than 300 articles per day so you can get away with doing un-indexed full table scans of your entire database. But the engineers can put "I created a log based time-series architecture on their resumes".
App-ifying articles is an unfortunate path many sites have gone down. Islands of interactivity are great for special cases (games, some charts), but delivering a few KB of text via an application framework is overkill.
As a dev that has never worked with react its, interesting, to see react '18' introducing fixes to problems that have not been issues before. I've used angular, straight SSR from PHP / node.js / .net and never suffered from 'screen jank' or huge culumative layout shift issues. Not sure we should celebrate the fixing of issues that shouldn't have ever been a problem for a site that just renders text and images.
13 comments
[ 2.9 ms ] story [ 37.6 ms ] thread[1] https://www.nytimes.com/2024/06/29/us/politics/biden-donors-...
[2] https://text.npr.org/g-s1-6773
https://www.confluent.io/en-gb/blog/publishing-apache-kafka-...
> The Monolog is our new source of truth for published content. Every system that creates content, when it’s ready to be published, will write it to the Monolog, where it is appended to the end.
> The Monolog contains every asset published since 1851. They are totally ordered according to publication time. This means that a consumer can pick the point in time when it wants to start consuming. Consumers that need all of the content can start at the beginning of time (i.e., in 1851), other consumers may want only future updates, or at some time in-between.
> As an example, we have a service that provides lists of content — all assets published by specific authors, everything that should go on the science section, etc. This service starts consuming the Monolog at the beginning of time, and builds up its internal representation of these lists, ready to serve on request. We have another service that just provides a list of the latest published assets. This service does not need its own permanent store: instead it just goes a few hours back in time on the log when it starts up, and begins consuming there, while maintaining a list in memory.
Absolutely insane. The only reason this works is that the NYT publishes less than 300 articles per day so you can get away with doing un-indexed full table scans of your entire database. But the engineers can put "I created a log based time-series architecture on their resumes".