hiddendip:
virtualgirladvance:
sreegs:
sreegs:
sreegs:
sreegs:
automattic’s made a ton of blunders recently but i hope they’re not gonna try something like convert tumblr to run on wordpress, a project that both tumblr and wordpress engineers agreed would be a lot of work for no gain (most likely worse performance). that would be a silly thing to do.
hang on my aide is handing me a note
oh dear.
L O, and if i do say so, L
Given the blogging site’s continued financial woes, Mullenweg shifted the majority of Tumblr’s workforce to other areas at Automattic late last year and laid off others. At the time, he suggested that moving Tumblr to WordPress would be “tricky” but added that new technology like AI would make it easier.
Oh they’re actually intentionally trying to kill Tumblr this time huh
thing is, i’ve literally ran hosting infrastructure for wordpress at scales maybe a tenth of tumblr traffic-wise, and this is not totally impossible, just incredibly wrongheaded.
the way you run wordpress at scale is to use it as an editor, then render all of your posts/pages out to static html and serve them through a content delivery network; this only works when you’re running almost-entirely read-only because (say it with me): there are two hard problems in computer science, cache invalidation and naming things. it was literally a joke at my old job, to the point that we had “solution: static-cache the living shit out of it” permanent markered on our hosting team’s whiteboard.
running tumblr on wordpress would be an exercise in cache management beyond the technical skill of automatttic. y'all still haven’t fixed the postmeta bloat issue after two decades, you are not ready for the actual computer science you’re going to have to do to handle caches on this scale.
that’s not even mentioning the three timelines you need to dynamically generate - can’t static-cache that lads.
i don’t know what tumblr’s infrastructure looks like now, but any savings they’d make from a skillset and work-sharing perspective would be eaten by the cost of retooling a square peg into a round hole.
this feels like an edict, not a decision; led by internal cultural ideology and not engineering forethought.
fuck it, i’m not done.
about those timelines, are you serving them from the posts table? guessing you’ll be partitioning or sharding that table by blog, right? cool, so you’ll need to tree out reblogs which is totally doable in a single query.. hope your sharding doesn’t take a performance hit doing cross-partition joins.
or are you going to build a specific service for doing that?
are you using the existing media-management system? so that’s a database call or three for every embedded image, video or audio-clip.
or are you going to rebuild that system to pull from a static cache?
how are you storing likes? postmeta? cool, so that’s loading a set of serialised strings every post load, that you then have to deserialise to extract a value.
or are you going to store them somewhere else? maybe adopt the eventual consistency model that just about every other social media site uses for interaction tracking?
what’s the plan for the editor? tumblr’s post editor isn’t amazing but it’s a hell of a lot easier to use than wordpresses?
see, at this point you’re basically building a new platform on top of the, frankly, awful foundations provided by wordpress.
i hate to be that guy, but at this point just rewrite the damn thing if you’re that bothered.
