I’ve been a “front of the front” front-end developer for over 20 years now, and it has been so refreshing lately to see a lot of respected FEDs like Andy Bell and Jared White push back on the idea of how every site should be built using a JS framework.

My relationship with JavaScript has always been very mixed. I never formally sat down to learn it until about 18 months ago, getting by with just hacked together scripts from Stack Overflow or help from other developers (such as the awesome other FEDs at Lullabot where I work). Lullabot knew this when they hired me but fortunately, my skills with CSS, HTML and Drupal theming (where I primarily work) were enough for them to take me on, and for that I am forever grateful.

Part of the reason I never dove into vanilla JS was that I was busy. For 11 years, I ran my own Drupal development company as a solo developer and on top of that, was a partial stay at home dad for my two kids. Learning something new that I didn’t always see the practical purpose for on a project was never front of mind, I would much rather spend the weekend with my kids than studying docs, and I was thankfully able to get by without it.

But that didn’t mean I wasn’t aware. Starting in 2015 or so, the idea of using a JS framework to build a website really began to spread in the dev circles I was in, and it made me feel less-than as a developer. If everyone else was using this really awesome thing, and I wasn’t, did that mean I was going to get left behind, become a dinosaur of a past era and thus unemployable? It was always a thought in my mind, causing a sort of internal anxiety that still persists today. Having technical knowledge debt is one thing but knowing you have that debt as you continue your day to day job is something all together. It felt like JS frameworks were going to eat the web, and I was going to be gobbled up too.

But as Andy points out in his blog post, that simply didn’t happen. Citing a study from W3Techs, it turns out that React and other frameworks still aren’t doing much gobbling of anything at all.

React is used by 4.0% of all the websites whose JavaScript library we know. This is 3.3% of all websites.

That’s…not a lot of sites, especially when WordPress alone makes up 53% of all websites. So then why the anxiety? As Andy discusses, it was just a very loud, very vocal minority of developers who presented the need for a better DX (Developer Experience) over all else, and - for a while - JS frameworks were the things to do that. Everywhere I looked, from Dev Twitter to blog posts to general conversation, everyone was talking about how this or that framework was the best way forward for making better sites, it made things better for developers, unicorns and rainbows etc etc.

But in hindsight, what I thought was just me languishing in my own embarrassment over not learning the hottest new thing, was really just me being stuck in a dev echo chamber with people I respected telling me something I just had to know and me just…well, feeling bad for not learning it.

Had I stopped to really think about this, I would have seen that everything wasn’t all unicorns and rainbows; the web is made up of a lot of different tools, doing a lot of different things, and no one tool is perfect for every job or need. I had many scenarios when I ran my company where someone wanted a custom website and while I could have probably sold them on using Drupal, it would have been way overkill for what their needs were, adding unneeded layers of complexity, and instead I would steer them towards using Wordpress or something like SquareSpace or Wix.

That’s what’s at the core of choosing any tool for a project: what is the need for the client. Because at the end of the day, most stakeholders in a project don’t generally care how the thing is built, just that it is built and is built in a way that they like and can use. Developers and the companies they work for sell a product, an experience, an expectation. And unless they have a stakeholder who is just enraptured with a hot new thing, chances are any sort of explanation of compiling and first-paint and on and on will just go right over their heads. They hire us to be the experts, not to show off why we are experts.

That’s not to say that I am 100% adverse to learning new things. I remember years ago when CSS pre-processers first started taking root, first with LESS then with SASS. I jumped on learning those because they DID enhance my skills, and made my life easier, without sacrificing anything for my clients (I even presented on SASS back in 2014 . And today, I’m proud that I have built a foundation for myself in vanilla JS, even if it’s years later.

And yes, as developers, discovering a new tool for our toolbox is incredibly exciting, especially in the world of open source. It still gives me a little thrill when I find something that I know I will A) like working with and B) will meet a need, professionally or personally. But what I like to work with, at the end of the day, should NOT cloud how I approach a project.

When it comes to whose experience should matter the most, it should go something like this:

1). END USERS

2). CLIENTS

3). SUPPORT TEAM

453.) DEVELOPERS

Sustainability on a project should also be paramount too. Besides the cores of writing good documentation, adding comments throughout and making sure that the knowledge of how something works is embedded in multiple people should someone get hit by a bus, we shouldn’t be building things that make making changes more cumbersome than they have to be.

I (think) I see the value in something like CSS-In-JS but what happens if you just need to make a quick styling change? Rather than just editing a single line and pushing that up, you have to make the change, verify your tests, recompile everything, etc and adding extra steps to what should not be a complicated process. If we continue to focus on the best DX possible, we are hamstringing ourselves later for those who know how something works by adding unneeded work, and further mystifying a project for someone new (or not as knowledgeable) to come in after the fact.

And yes, knowing how complex systems work might also seem like built in job security for a lot of people. But it isn’t sustainable in the long run, when everyone moves on to the next shiny thing and hiring folks are left scrambling to find someone new to refactor or redo entirely a project because the winds of dev trendiness have changed. I would argue instead that it lessens job security because a company that chases the newest thing is likely to continue to do that and it puts more burden on the developer to keep up or get let go, in a much shorter time frame. The tortoise can sometimes still win the race.

I remember when Angular was the thing. Then it became React. Now it’s TypeScript. All of which made me feel like less-than as a developer, until suddenly…they didn’t. The in-crowd moved on to the next thing and I stayed where I was, growing my skills slowly, and I had a hard time even determining where I should try to focus, if I was going to attempt it at all, because the vocal minority was always carnival barking me in different directions.

But in the end, I didn’t chase the new for many years and you know what? I was able to stay in business, live comfortably enough to give my kids (most of) what they wanted and deal with genuinely happy and satisfied clients. Maybe I was an outlier and someone who got lucky, but I don’t think so. I think there are more of us out there than people realize, who had the same conflicted feeling as me.

Back to that echo chamber for a second. As Jared points out in his post, we should have realized sooner that the onus wasn’t on us to keep up with the front-end framework race but rather for those loud voices to explain why we need to run the race in the first place.

The Burden of Proof is On You, Frontend Framework Stans, Not the Vanilla Web!

So then, I ask:

• Explain to me why I need to abandon what I know to be a better developer

• Explain to me why this or that tool is going to be better for my project

• Explain to me why clients should ignore any FOUC on their site in favor of a slightly cooler experience or any other “gotchas” that come along with any tool

It’s like that line in Jurassic Park when it comes to trying to push us all towards frameworks

You don’t have to have JavaScript on your website. JS is the third leg of an already stable table, along with HTML and CSS, that makes the web work. So why are we offloading entire websites into just one? It just doesn’t make sense. Frameworks have a purpose but (again to quote Jared), the web is a polyglot of technologies that make it work and none of us should be made to feel like we have to all follow just one of them to be successful.

So yes, I’m glad - very, very glad - that other people are finally speaking up about the echo chamber a lot of us were stuck in and pointing out the flaws in always following the crowd. As I continue to grow as a web developer, I’m sure that I will adapt and learn new things as I need them. But never again will I just beat myself up for not being on the cutting edge. It’s just not worth the anxiety and stress.

I’m still here as a successful front-end developer. And I didn’t get eaten by JS frameworks.