Thread by @enjalot

I remember when AJAX was the new hotness in 2005 (it had been in IE for 6 years at that point). IE6 still mattered. git was just invented. there were magazines about code.

Your struggle is real, here is a thread on why I think it's all gonna be ok.

https://twitter.com/_lrlna/status/1254687998161178625

This thread is not a personal response to the OP but an attempt to share my perspective with the community.

Anyway, the reality certainly is that there are a ton of ways to build things, and constantly adding more. It can be hard to see where the fundamentals are underneath.

I did nothing but #reactjs for a solid year in 2015. I didn't really touch it again until a month ago.

It felt like nothing changed in 5 years, because fundamentally nothing did.

All libraries are just someone else trying to make a thing easier to do.

Frameworks are just someone's opinion on how to organize a handful of concepts and glue them together.

So what are these fundamentals?

At the end of the day we are all just trying to get the web browser (a program with a bunch of fancy APIs) to execute in a particular way when a user accesses our URL.

Those APIs can do a lot of cool things, but the core hasn't really changed since 1999.

The core is HTML. It's rules are simple until you add on CSS and start thinking about layouts.

Understanding the ways to layout DOM elements (without frameworks, preprocessors etc.) is key #1 to not getting overwhelmed by new shit.

not even talking styles, just layout.

Then comes JavaScript. The core of all programming is variables, functions and loops. Cool, the hard part is scope. Especially in JS. Get that shit down so that when you are reading code you know exactly what is in and out of scope.

After scope comes the concept of asynchronous. This one's a bitch. Your program is no longer a straight line. What's in or out of scope is essential AND hard to see directly.

async is also where knowing about 2 lower level abstractions is really helpful: networking and CPUs...

I don't mean for you to learn the whole TCP/IP stack, but a solid understanding of how data goes from one computer to another goes a really long way. The client-server paradigm, browser sandbox rules, fuckin CORS... knowing this well can unblock so much.

CPUs? yeah, at the end of the day you have one incredibly fast bean counter. Ok, maybe you have multiple cores, so you have a few bean counters. Fancy GPU? thousands of bean counters.

Still, your program is asking one bean counter to count a bunch of beans as fast as it can...

There are two ways to make code go faster: 1) ask your bean counter to count fewer things or 2) figure out how to divvy up your beans among different bean counters, just make sure you and they don't get confused about which beans go where.

Alright, so having solid fundamentals in what you're asking the network to do and what you're asking the CPU to do gives you solid footing.

The next skill is what let's you ignore 99% of the JavaScript ecosystem: isolation.

It's not just you asking the CPU for a favor...

it's everyone who wrote a library you are depending on, and everyone they depended on, and so on.

If you can isolate EXACTLY what is being asked and by whom you can get to the bottom of any bug.

I believe this is a skill that can be actively developed.

There are many fancy tools for this, but console.log and a return statement is all you absolutely need.

Fundamentally you want to be able to tell if some unexpected behavior is coming from 1) the environment 2) the libraries 3) your code
(it can actually be any combo as well...)

I think another big factor in the explosion of web libraries and frameworks is all the "patterns" they are providing.

Personally I struggle to understand the value of a pattern until I run into a problem where the pattern fits, usually after I've tried my own inelegant hacks.

Also if all you have are existing patterns it's easy to get stuck in a situation where none of your patterns fit. It can be tempting to start pulling patterns off the shelves (there are so many!)

But I believe that contributes to the exhaustion folks feel.

Knowing the fundamentals means you can make your own patterns tailored to the situation you find yourself in. You don't HAVE to... god knows I use a ton of libraries. But you also don't HAVE to keep up with the latest thing, you can afford to wait for the good ones to win out.

I think developing a taste for patterns comes from experience and deliberate practice.

You may notice that when you get the chance to apply a pattern to a problem it can be quite satisfying. You may rush to create an npm package so others can benefit. And that's how we got here.

To be honest, I love it. I hope more people make more libraries.

Once you have the fundamentals and a little taste it's pretty easy to benefit from a nice idea and ignore all the noise.

I bet that last sentence applies to any human creative endeavor...
♥️