Forem: Uli Troyo

Dear (Rust) Devs: Article Request

Uli Troyo — Sun, 02 Mar 2025 01:32:12 +0000

This is a request to all devs for a new type of article that outlines the non-obvious features and quirks of the languages you use the most.

All My Dev Tools Are Written In [Language]

Here's my issue:

Nearly all my developer tools are open-source projects written in Rust (Nushell, Helix, WezTerm, and more).
I don't need Rust for anything, and I have my hands full with other languages I use for work.
I would like to learn enough Rust to modify my tools and contribute to the projects.
I don't have a lot of time to devote to learning.

If you're a dev, I know you can likely relate:

You want to port a project to the web but you haven't touched JavaScript since 2005 and have no idea where to start with modern tooling.
You want to customize your Neovim config but you don't know Lua.
You want to build custom tooling or workflows in Logseq but you don't know Clojure (or Datalog, whatever that is).
You have a use case where a Bash script is the quickest solution but you forgot Bash doesn't support floats so 3 hours later you're uh... bashing your head in frustration.

So my personal problem is in Rust, but I would love for there to be an ecosystem of this kind of article available for ALL languages: an 80/20 introduction to a language, for programmers of other languages.

The 80/20 Rule

You've likely come across this truism, but in case you haven't, it goes like this:

80% of a company's profits come from just 20% of its clients.
80% of all community problems are started by 20% of the users.
80% of your memories with someone come from just 20% of the time you spend together.
You spend roughly 80% of your time playing just 20% of the video games you own, a.k.a. you spent $70 on Final Fantasy VII Rebirth but have barely played it as you clock your 300th hour in Balatro.

The 80/20 rule is a heuristic that helps you focus on what's important:

You should probably prioritize the needs of that 20% of your clients before anything else.
You should probably kidnap that 20% of your users and drop them in the middle of the Mojave Desert.
You should probably spend less time with the people you love, those unmemorable nobodies.
Only ever play mobile roguelites.

We can extrapolate what this means for programming languages:

When learning a programming language, 80% of the headaches come from just 20% of the stuff you don't yet know.

Your Mission

So can you do me a favor, please? Whatever you primary programming language is, identify the 20% of:

usage rules
coding styles & idioms
language quirks
standard library utilities
dev tools
macros
other unintuitive stuff to newcomers to the language

that you use 80% of the time, or that you see in GitHub projects of that language 80% of the time. Whatever will make reading code in that language easier to a newcomer.

Basically, when you were learning your language, what did you struggle to understand or use correctly? And from that list, what's roughly that 20% you use 80% of the time, or that you see in roughly 80% of the open-source projects you browse?

Can you then write an article where you tell me about these things? Name it something like "Rust 80/20" or "TypeScript 80/20". And in whatever social media platform you choose to share your article give it a hashtag like #rust8020 or #ts8020?

To give you an example of the stuff I'm struggling trying to read Rust code:

How do I know when to use a ::prelude thingy VS using the actual thing? What even IS a prelude?
When is it acceptable to reach for a macro VS a regular function? I've seen APIs written both ways, as in clap derive vs builder APIs.
When am I more likely to encounter lifetimes? I get scared whenever I see the little tick marks, because I never know when to expect them.
The whole business with unwrap and ! and ?. I find it very unintuitive.

What I Am NOT Asking For

I am not asking for beginner's guides, though. There are already a great series of articles titled "learn X in 15 minutes" like this excellent beginner's guide to Lua that take you through the main syntax of a language. Thing is, once you know one programming language (or a few), picking up the features of another is mostly just learning a few syntax differences and implementation details. Generally, there are already good beginner guides for every language, even those you've never heard of, such as this excellent guide to a language named Janet.

I'm also not asking for pedantic style guides. Those are for language fanboys, not casual users. Don't tell me how to write idiomatic Python. I know ThePrimeagen used to do that in Stack Overflow back in 2010 or whatever, but unless you have aspirations to be a mustachioed Twitch streamer dev, don't tell me about your idiomatic Python. Only tell me idiomatic rules if there's a particularly dumb construct you see in actual code all the time and I should know about it, like ugly list comprehensions and ternary operators.

A JavaScript Example

If you get what I'm looking for and have enough sauce to get cooking, you can stop reading. (Just link me your article in the comments after plz.) But if you'd like a more thorough explanation of what I mean, I want to give a brief overview of an article I would've found useful when I got started with JS. This won't be an actual 80/20 introduction to JavaScript, but I bet most of us are at least somewhat familiar in order for this to make sense, and get a better idea of the type of article I'd love to see.

1. In JavaScript, we pass around functions like they're your ex-boyfriend.

Whether or not it's a good idea, in JavaScript we like to encapsulate functionality in functions, and then pass them around like memory overhead isn't a thing. Because functions are first-class constructs in JavaScript, we can, and do, pass them around like variables all the time. This is a common pattern in functional programming, which is much more popular now, and most languages now support lambdas and closures. This wasn't always true though, and I used to find the function shenanigans of JavaScript very confusing:

passing in functions as parameters to functions
passing in function calls as parameters to other functions
returning function arguments as functions within objects
calling a function's mom within another function and having her mom do some work from within yet another function
having said grandma function promise to return a modified clone of herself in the future unless there's some sort of unhandled network error

As such, here's a short guide to get you up-to-speed with some of the most common ways you'll see functions being passed around in JS. (Note to the reader: if this was an actual article, I would spend a LOT more time explaining closures, but this is just an example.)

// An imported function
import { importedFunction } from "some-npm-dependency";

// A regular JS function
function goodLittleFunction() {
  // Do stuff here
}

// A gross un-labled arrow function that
// is super popular to use right now because
// it means JS devs don't have to bother
// learning scoping rules or prototype
// binding, even though it prevents error
// messages from being nicely labeled
// because they are anonymous. Have you
// ever had a moment in debugging where
// you go "and then some random function
// gets called, but I don't care which
// function it is, event though this is
// where the error is coming from"?
// No?
// Well we are JS devs, and that's how
// we decided we're going to do things.
const lilArrowFunction = () => {
  // Do stuff here
};

// Sometimes arrow functions get a single parameter
// as input, in which case you can skip the parens
// altogether. You can tell it's still an arrow
// function because it still has an arrow, but my
// brain is wonky and I used to have trouble parsing
// arrow functions without parentheses in my head.
// Also, notice this function is returning another
// function, which will be modified by whatever
// argument you passed in to the function. This is
// a very common pattern in JS, and functional
// programming in general.
const yourExBoyfriend = param => {
  return () => {
    // Do stuff with `param`.
    // The effect of this returned function
    // will be permanently different depending
    // on what the value of `param` is.
  };
};

// Now let's demonstrate how you'll see functions being used.

// Here we pass a function to another function. If you check
// the documentation to `importedFunction`, it likely uses
// this passed-in function as a callback, meaning it will do
// the work that `importedFunction` is supposed to do, and
// then it will do whatever you specify in `goodLittleFunction`.
// This is a way for you to specify your own functionality
// that gets run as a custom step in other people's code.
importedFunction(goodLittleFunction);

// Here we are creating a new arrow function at the same time
// we pass it into `importedFunction` as a parameter. This is
// how we can quickly encapsulate a function *call* as the work
// that needs to be done.
importedFunction(() => lilArrowFunction());
// You'll often see this when dealing with DOM event handlers
// on the browser. In the following, when the user clicks the
// button, the browser will call our `lilArrowFunction`.
document.getElementById("my-button").addEventListener(
  "click",
  () => lilArrowFunction(),
);

// Often, you'll see badly-named parameters being used in the body
// of these types of functions. Read the documentation, and you'll
// likely see that the function you're using exposes some kind of
// object you're supposed to use to derive your functionality.
importedFunction(obj => yourExBoyfriend(obj));
// In the example below, the browser gives you an object containing
// a bunch of information about the event that triggered the event
// listener. Here, the user has badly named the event parameter `e`
// for convenience, which is only acceptable because this is a VERY
// common use case, and it prevents the developer from typing out
// 'event' in its entirety repeatedly. I'd say it even helps
// readability. You'll likely also see `fn`, `err`, `msg`
// and a few other obvious ones, but there are also some other
// common ones that are a bit less obvious:
// - `cb` for a callback function, a.k.a. a wrapped function call
// - `req` and `res` for the request and response objects of some
//   network functionality, such as `fetch`, or in web server code.
// - `el` for an HTML element reference in browser code
// - `ctx` for 'context' used in browser graphics APIs and in code
//   that encapsulates some sort of state that is passed around.
document.getElementById("midas-input").addEventListener("input", e => {
  e.target.style.backgroundColor = "gold";
});

2. JS dev tooling is complex; use Bun instead

(Note to the reader: notice that this is not relevant to reading code, but writing it. Having an opinion here is OK, because you're not tricking the reader into thinking this is how things are commonly done, but rather a tip on how THEY can get started more easily. However, if I wanted to show some typical server code, I would not be appropriate to use Bun or Deno; I would just show some common Node and Express code.)

You want to throw some JS on the browser. You could install a thousand dev dependencies, install React for no reason, run a local development server, have the dev server compile your React into HTML, and a bunch more cartoonishly exaggerated steps in the style of a 90s infomercial... or you could just install Bun!

Step 1: install Bun

curl -fsSL https://bun.sh/install | bash

Step 2: start a new Bun project

mkdir my-experiment && cd my-experiment && bun init

Step 3: write your HTML boilerplate

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>My JS Experiment</title>
  </head>
  <body>
    <script src="my-experiment.js"></script>
  </body>
</html>

Step 4: install an NPM dependency

bun i cowsay

Step 5: use that dependency in your JS

my-experiment.js

import * as cowsay from "cowsay";

const cowDialog = cowsay.say({ text: "I don't like to say 'moo'" });

console.log(cowDialog);

Step 6: Directly execute your HTML using Bun!

bun ./index.html

Bun v1.2.4 ready in 47.77 ms

➜ http://localhost:3000/

Press h + Enter to show shortcuts
Bundled page in 22ms: index.html

Bam! Now you can open http://localhost:3000/ on your browser, and should see the following in your dev console:

 ___________________________
< I don't like to say 'moo' >
 ---------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Now Go Write Me Some Articles! Pretty Please.

That's my basic idea for these 80/20 articles. If you like it, I'd love to see one for whatever language you want to throw at me: React, Julia, Svelte, Nushell, C++, Zig, Odin, Nim, Crystal, whatever! And remember to link me in a comment so I can see them. And write the Rust one ASAP because I'm over here waiting. Get to it. Up and atom. Remember I'm paying you nothing!

Dark Mode is breaking your branding—easy fix!

Uli Troyo — Tue, 29 Jun 2021 01:59:47 +0000

As more sites and apps support dark mode, I've seen tons of logos and profile avatars saved as transparent PNGs and SVGs begin to break. The fix is simple, though: make sure that your art has a border in a contrasting color. If your art is all black (the most common situation) or otherwise mostly dark, a thin white border will be invisible on a light background, but will set off your art nicely on a dark mode background. Similarly, if your art contains a lot of light color, a dark border will prevent it from washing out on light backgrounds.

Below is my example for both cases. Notice how I add a 10-pixel white border on the first logo to suit the art, and a 1-pixel border and a drop-shadow to the second logo to keep it subtle since the art is more complex:

That's literally all I have to say! I've seen this a lot in the wild and it's apparent it bears to be mentioned. I hope you didn't need the help, but you're welcome if it did ;)

Why Everyone Is Fighting About CSS/UX and JS

Uli Troyo — Sat, 02 Feb 2019 18:01:02 +0000

TL;DR: There isn’t one. There’s no short way to say any of this, yet one of the reasons you keep fighting is because you misunderstand what the fight is about. Read the damn article. Please and thank you.

I hate intros. Let’s just dive in and I’ll fill you in where pertinent.

The Great Divide

Chris Coiyer’s essay "The Great Divide" broke the frontend dev community, inviting no small amount of snarkiness and drama on Twitter and elsewhere. In case you haven’t read the piece (and you should), it revolves around an observed division between frontend developers who use primarily JavaScript-related technologies to do their job, and frontend developers for whom JavaScript is only one of the many technologies they employ to do their more UX-centric job. The thing that everyone seems to be missing is that this is not a prescriptive view of how frontend-land should work, but rather, a descriptive view derived from real-life interviews Chris and his buddy Dave Rupert have conducted on their podcast ShopTalk Show (dot com).

In other words, the split is real. Chris and Dave are merely putting it into words.

Chris concludes in “The Great Divide” that this rift in focus is happening because frontend-land has basically ballooned away from the old context where frontend development was comprised of merely styling server-rendered components. He notes that many frontend developers are using JavaScript in a way more closely reminiscent of usual MVC-style backend programming, while others are focusing on using a more rounded set of tools, and primarily CSS, to make the frontend experience better and more accessible, and thus, if we’re to helpfully describe the jobs frontend developers are being hired to do, we should be distinguishing between JS Engineers and UX Engineers.

Class Warfare

The discussion, though, immediately devolved into whether JS Engineers (I’ve gone ahead and accepted Chris’s proposed nomenclature) do more work than UX Engineers, and whether UX Engineers deserve to be paid the same as JS Engineers.

I should note: if you've seen the discussion online and the outline I'm presenting doesn't jibe with your version of the events, that's fine. The web is a big place, and it's entirely possible you and I have witnessed two sides of the same coin. I'm trying to contextualize what I've seen with this narrative I'm building; I hope that's OK with you.

Anyway, as a surprise to nobody in the industry, we have a recurring theme of derision and general snootiness toward other people’s tech, an attitude which developer Aurynn Shaw incisively terms “contempt culture”. In this case, we began to see this contempt target UX Engineers... and I’m certain a number of you reading this are now thinking “you mean designers, though, right? How is design also engineering?”

Because here's the thing: even when no offense is meant, a lot of people don’t think UX Engineers are a thing, or that they’re glorified web designers at best. I observed this same attitude in the discussions surrounding the ShopTalk interviews of people who were primarily doing design-centric work. I’m not going to nag you one way or the other about whether this is correct; I’m merely pointing out that this is an attitude that people hold.

I'm likewise going to point out that people who take part in this culture of contempt often don't mean harm with their dismissiveness (citation needed, sure, but it’s my writeup). People are not necessarily trying to be jerks when they dismiss Ruby for being slow, nor when they dismiss JavaScript for “having been written in ten days”, nor when they dismiss Java as tech for stuffy old farts, nor when they dismiss Elixir as a toy language, nor when they dismiss PHP for being PHP, nor when they dismiss web development as “not real programming”, nor when they dismiss UX Engineers as “not engineers”. Sometimes the snootiness is just abrasive opinion based on passive biased observation.

Not many are keen on defending this behavior, though, because to people specializing in the technologies being disdained, these opinions often constitute a direct attack. You can pin a huge asterisk on this point, but basically: turns out when a person feels other people are shitting on the thing that pays the bills, that person might (rightly or understandably, your choice) get defensive. And that’s precisely what we saw on Twitter.

Jen Simmons (W3C's Working Group, Mozilla, Layout Land) describes the animosity toward UX Engineers as “class warfare”, and shot a number of choice spicy tweets toward a particular lean of JS Engineers:

// Detect dark theme var iframe = document.getElementById('tweet-1089611136666927106-446'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089611136666927106&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1089611137459671040-594'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089611137459671040&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1089611138176860161-614'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089611138176860161&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1089611138906636290-885'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089611138906636290&theme=dark" }

I’m not doing you the (dis)favor of including any of the shittier tweets thereafter flung in Jen's direction: it’s the web—use your imagination. On the more sensible side of things, though, this argument gets more nuanced. Dan Abramov (React, Redux, create-react-app) writes:

// Detect dark theme var iframe = document.getElementById('tweet-1089630864336740352-71'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089630864336740352&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1089631271309975553-125'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089631271309975553&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1089631513858228224-244'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089631513858228224&theme=dark" }

I'm obviously putting Dan in the JS Engineer camp because, you know, React. Then there are people who don't fully identify with either of our new frontend designations. For example, Kyle Simpson (You Don't Know JS, Frontend Masters) writes:

// Detect dark theme var iframe = document.getElementById('tweet-1087514283817267201-180'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1087514283817267201&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1087514284660277249-541'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1087514284660277249&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1087514285637554176-222'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1087514285637554176&theme=dark" }

Among other opinions, though, you can see folks beginning to tire of the incessant barrage of negativity. Das Surma (Google, HTTP203) sums it up thusly (and I really wish I could say “Surma surmises” but it’s wrong diction):

// Detect dark theme var iframe = document.getElementById('tweet-1087415492116185089-662'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1087415492116185089&theme=dark" }

Basic as HTML

By the time Surma makes this statement, though, we’ve lost all semblance of a common thread of discussion. It’s no longer about how frondend development is evolving, but about whether CSS and HTML are difficult as technologies, by way of defending people whose job might often go no further programming-wise (though in my case obviously not dismissing the wealth of education and experience required for UX Engineering).

This is where DHH, whose JavaScript framework Stimulus (and indeed his entire work on Rails) pivots on the idea that the web is becoming unnecessarily complex and we’re all better off focusing on making app development as straightforward as possible, gives us his unsurprisingly direct opinion that designing for the web ought to mean making HTML and CSS. Here's his tweet on the subject:

// Detect dark theme var iframe = document.getElementById('tweet-1088234367715921920-288'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1088234367715921920&theme=dark" }

I’ll admit that I think the discussion did seem to have jumped the shark a bit around the time DHH said this (though in the name of defending UX Engineers, so I’m not faulting anyone).... I mean, isn’t the whole point of web technologies to be accessible? Shouldn’t we take pride on the fact that HTML and CSS are as easy as they are powerful?

Wait, what were we talking about?

Somewhere around this point, there seemed to be a shift in the atmosphere: a secondary argument began to emerge... and it is where I think everything became real convoluted, and it's where people are having trouble reconciling what the hell is even going on with this whole UX vs. JS thing. Because while one side was fighting about whether UX is as cool as JS or whatever, an adjacent and more interesting talk began to make its way forward...

From my personal vantage, it started with DHH, who goes on to make a second appearance in this story with an observation about the state of web technologies, this time in a post about how View Source is on the decline and how we shouldn’t let it die. Here's his tweet on that subject:

// Detect dark theme var iframe = document.getElementById('tweet-1089179428788133888-137'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089179428788133888&theme=dark" }

(Here Tom Dale throws a spicy one at DHH; I'm including these for no better reason than it's funny:)

// Detect dark theme var iframe = document.getElementById('tweet-1089230610743332865-292'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089230610743332865&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1089284763230195717-792'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1089284763230195717&theme=dark" }

Anyway, the idea that View Source is worth saving is pretty interesting, because I knew I couldn’t be the only one who thinks the original discussion is coalescing into a second and more nuanced conversation, namely: what is going on with the semantic web?

Wait, what? Who is even bringing up the semantic web?

Well, look, allow me a brief leap in context. In case you're not familiar and didn't bother reading the article I linked to just now, the semantic web was Sir Tim-Berners Lee's idea for the future of the web, where web pages would be intelligible to humans as well as computers. To be realistic about it, though, the semantic web ultimately amounted to not much more than a bunch of schema tags that we were supposed to throw into our HTML to make it easier for Google to do their job, but while it's fun to be cynical about it, let's not forget the real reason the notion of the semantic web exists: the dream of a decentralized web where everyone owns their data and information silos aren't a thing. More pertinently, though, the semantic web illustrates that, ever since the beginning of the web, there's been the idea that the web is meant to be accessible and open.

Agree or disagree—not the point. I'm only claiming this is what is at the heart of this second round of the fight pitting JS against UX: whether or not JS is becoming bloat that is keeping the web from being accessible and open.

As you can probably tell, this also runs in contempt culture territory, because it implies that frontend Javascript technologies are bad for the web. And while I think this argument has more intellectual merit than whether UX engineers are less cool than JS engineers or whatever, as you might infer, things once again got pretty heated. For the sake of brevity, here's a cursory list of the types of arguments being made:

Some people argue that using so much JS on the frontend is creating a scene where the fabric of the web that's supposed to tie us together is no longer human-accessible (implication being that's a problem).
Some people argue that it doesn't matter because the web is only a delivery method for digital products.
Some people argue that JS frameworks make the web impractical or inaccessible for people with accessibility needs.
Some people argue that, while accessibility concerns are a valid criticism, it doesn't mean that frameworks and best practices aren't still evolving and this is a solvable problem.
Some people argue that frameworks are making people overly reliant on technologies not inherent to the web, and new developers are losing grasp of the possibilities of raw technologies.
Some people argue that frameworks help tame the complexity of the web and allow people to become productive faster.
Some people argue that frameworks are needlessly bulky and make the web experience worse for people with crappier internet.
Some people argue that's also a solvable problem....

I wanted to back each of those sentiments with individual tweets expressing them concretely, but that's a lot of work, so I'm using my editorial discretion and not doing any of that. However, you can go on Twitter or Dev.to or Medium and do your own research—people are expressing these opinions.

None of this is new

This whole fight about the state and future of the web has long been a simmering disturbance in the Force, usually felt by developers as no more than a dull background throb, but every once in a while coming back with a jolt. This is evidently one such time. As developers though, we recognize this recurring argument as the worn motif of old, morphed but yet familiar, and existing as long as our industry has existed: what role should computers play on the theme of our collective human experience?

...yeah, OK—I'll tone down the philosophical flight of fancy.

But you know what I'm saying, at least. This is the industry that coined the hacker ethic, and free software, and open source, and Creative Commons, and "information wants to be free," and the aforementioned semantic web, and shit, we could even take it as far back as Doug Engelbart's notion of augmenting human intelligence with computers. All I'm saying is that developers have been known to entertain thoughts about the nature of the relationship between humans and computers.

So one good thing that's emerged from this fight is a renewed vigor in visiting this topic from the point of view of the web: what do we want out of it? What do we want the web to look like? What's worth preserving, and what's expendable? What new features do we want to see? Who's role is it to bring this all about? And what role will frontend engineers of every persuasion play?

Indeed, some of the people I've already mentioned in tweets have some pretty sharp observations on the future of the web. For example, in his excellent talk about the future of JavaScript, Kyle Simpson talks about whether we should let JavaScript become a mere compilation target (relevant bits at 27:50):

And in one of her great videos about modern CSS, Jen Simmons recommends to stop reaching for frameworks such as Bootstrap and to begin to use raw CSS and all its awesome features (relevant bits at 8:29):

And it couldn’t hurt to also watch this other excellent talk about why the semantic web as originally envisioned failed, and what we can do about it (summary slide thrown at around 1:09:24).

But maybe I digress....

Get to the point, author guy

Yeah, ok. My point is that there are a number of us (whoops, I guess I am choosing sides after all) who think the web should be a batteries-included, accessible platform for everyone, and that we should try hard to maintain its open and semantic nature. Some of us (me) even go so far as to buy into Sir Tim Berners-Lee’s idea that the web should be wholly decetralized and become solid scheming turtles all the way down or whatever. In this newly morphed discussion, let's call this extreme side A.

Then there’s others who think that it doesn’t matter if the web is just a compilation target: that the web only matters insofar as people are using it for real business purposes, and if this is so, then our only concern should be to deliver a good experience to our product’s users, and this hippy-dippy notion of the web as a place where we can hold hands and view readable source be damned. Let’s call this extreme side B.

No doubt, most people will have opinions that fall somewhere along that continuum, rather than at either extreme. To conclude, though:

Chris Coiyer’s “the Great Divide” is meant to be descriptive, not prescriptive, of the state of frontend development.
The conversation of whether UX Engineers should be paid as much as JS Engineers is mired in misunderstanding of what the hell UX Engineers even do and whether the appellation is just a fancy new name for “designers”, a word which in this context seems to carry the weight of substantial misplaced disgust. I would stay away from this.
The conversation among sensible developers centers more around whether it’s OK or not that we’re using so much JS framework magic on the frontend that it’s in fact evolving the industry—less like gradually leveling up a Pokémon, and more akin to forcing a Thunderstone-induced transformation on Pikachu. I think there are good points to be had either way, but everyone involved would probably benefit from being careful not to tread in contempt-culture territory. Not that you need me refereeing your shit, but you know, it's my blog.
Also, no surprises, but Twitter commenters who are not sensible can indeed be so much fodder for a hefty trash compactor.
But fuck’em, because there’s a neat adult conversation to be had about the future of the web in spite of these people, so let’s, you know, get crackin' on that front: let's discuss the role of JS frameworks; let's discuss whether Web Assembly is really going to replace JavaScript, and whether we want it to; let's even discuss all the great new features available on the web... There's a lot to talk about, valid interpretations of our future as web denizens and as developers, and we should definitely sit down and talk it out.

You go first, though.