making memes as a form of self therapy

It is interesting to think about what the industry thinks its getting, and actually gets, with modern frontend engineering practices. I'd say they are designed for scalability in three directions:

1. scalable deployment (what you might need to put your front end on a bunch of different servers), 
2. scalable teams (this was once the best argument I heard in favor of standardizing on Angular.js despite the poor complexity-to-power ratio it offered; it also offered idioms and paradigms and narrowed the paths for "wheel reinvention" that distributed teams at AOL might go down)
3. maintenance and development across time (this is the temporal version of the second point - where you really want to avoid making too much of your own tangled legacy weirdness in the company repositories so that future teams can understand what you were up to)

Actually it's the cross of one and three that is a hurdle for me - I have several small projects in mind that would actually be useful to me (personally, or porchfests, or street bands I help support) but the monolithic server I usually throw things on is running an older version of linux that is a bit too old for some of the current supportive technologies (node/npm), and my sysadmin mojo has always been middling poor, despite my fluency with the Unix command line. (Also I am nervous of working with my service provider to do what is a potentially fraught upgrade until after Porchfest season.)

Maybe I should lean into prewrapped cloud options like Vercel. I'm shy about the possible costs - most offer free tiers, but A. if a project of mine takes off, I don't know what the cost scaling would be. (For Porchfests, for example, I got smacked with a bill for $600 for a map tile service once porchfest day launched us past the free tier - due diligence might have brought that down to more like $80 with another provider, but I didn't have numbers at that point) and B. for projects I might want to make for myself, now I have to also figure out a new backup strategy for any useful data the project generates (Someone one said (and I wish I could find the quote, this is a very rough paraphrase) that the Internet just has one big trick, getting information onto and off of someone else's server, and most of the apps I'm thinking of are definitely in that mold.)

The paradigm I've been leaning on: a mix of SSR and static front ends (rendered in crusty old PHP) with lightweight libraries and vanilla js, using handrolled NoSQL JSON blob on the file system storage of a monolithic server- actually has scaled really well for me across time (3), has handled the thousands of users crush of various porchfests (1), and while I've generally been lone wolf, I feel like I could teach it some other techie without too much hassle (2).

But anyway.
 

I need to decide where to focus these next few weeks. React seems to be the best overlap of what I have used professionally and what companies are looking for - but I have fumbled on at least one late tech screen, and so I might want to focus on stuff like greatfrontend.com, just getting practice in that mode. Or, I've noticed a lot of companies often want React plus something else, so maybe I need more Udemy-like classes. (Though I need to make sure I can show interviewers value from tutorial-based work.) But I also want to build some real stuff.

In May I made another meme that kind of predicted this:

Sometimes I wonder if I should switch gears and lean into the legacy stuff - like I've never done much PHP professionally, say, and it's super unglamorous and probably pays less, but I suspect there are a lot of places not looking to pivot, or to just gradually modernize their tech stack. Reminds me of COBOL programmers making bank in the late 90s as we built up against Y2K!