[The web didn’t change; you did](https://remysharp.com/2021/02/11/the-web-didnt-change-you-did "Permanent Link: The web didn’t change; you did")

I can’t remember when I started seeing this phrase but is was definitely in the last couple of years. Post after post in the open web community about framework fatigue. That is, the cognitive overload from not only being told that you’re using the wrong framework but that even if you are using the right one, there’s a new version that adds some brand new programming paradigm.

This is a real thing and there are more and more shifts in framework and library options. I do sincerely believe that these solutions do solve some problem that exists somewhere. Take React and GraphQL for instance. They solved Facebook’s specific problems with respect to their web site and the disproportionate amount of information they glean from their unsuspecting users. Somewhere along the line Facebook devs realised that this tech could be used in much simpler situations and thus open sourced the code. Same goes for Google with Polymer, and the iterations of Angular.

The thing is of course, if all these frameworks did actually stop evolving we’d very quickly get stuck and the web would stop innovating. Remember the days when everyone complained about IE6? If you don’t you’re lucky - you couldn’t turn a webby corner without someone kicking off about how terrible IE6 was (and indeed is… compared to the latest).

This period of time that has brought rise to the Vue and Reacts has helped spawn reactionary projects like Preact and Svelte which, I my opinion, try to pare back the amount the framework can solve and helps reduce the general footprint of functionality (and in some ways complexity).

During 2019 and 2020 there wasn’t a month that went by without a blog post about framework fatigue. Now if your job is to keep changing the frameworks that the business uses on a regular basis - then you’re definitely got your work cut out for you. But if your job is to keep an ear out for evolving technology on the web, well, then welcome to what every other web developer is doing.

Framework fatigue definitely exists. It’s also known as innovation in this particular area of software development. Which is also not a mandatory part of web development.

What spurred on this blog post that [Jeremy Keith](https://adactio.com/links/17804) bookmarked and shared. [Asko Nõmm wrote](https://www.askonomm.com/blog/i-dont-want-to-do-frontend-anymore):

Now, this advice on it’s own is useful, but not for the reasons it’s given. The complaint is that starting a new project is so time consuming with "frameworks, libraries, build, tools, pipeline and complexity" that it’s likely to wipe you out before starting.

I keep reading lately about how complex web development has become. How, now you can’t build a site before getting all the tooling in place and selecting the "right" framework or spending untold hours learning some new JavaScript technology.

I keep reading how there was once a time that you could just write some PHP and HTML and hit refresh and you’d see the fruits of your efforts.

How you could drop in jQuery and things were easier, and now the complicated web is here, and it’s here to stay.

Dear reader - let me ask you this, and I hope you ask your colleagues the same: what’s stopping you from using exactly method today?.

I say: nothing.

jQuery is still there. PHP and HTML (though I don’t think I ever saw a time where those were treated as two things rather than one weird mash of the two in a single file) and regular old JavaScript is still there.

What’s amusing to me today in 2021 is that I don’t even need jQuery to do a lot of what I was using jQuery for - which just means I don’t need to load additional JavaScript to play and create a web site.

These days are not illusive. This so-called simplicity has not gone. This simple pleasure of creating is still right there.

Sure the choices might be overwhelming, but what you learnt in the mid-2000s still works. Browsers bend over backwards to maintain backward compatibility. As someone who is personally embedded very deep in web development I can tell the only big tech that’s actually hard to do "the old" way is http (as in non-SSL) or "old https" because the new TLS stuff isn’t supported by old browsers and the entire page fails to load.

But when it comes to web development there is a massive range of options, except, perhaps if you’re [still using](http://www.stopbadtherapy.com/standards.shtml#new) document.layers you’re out of luck, but we’re talking about dropping support for a non-standard API from over 2 decades ago (and don’t worry, document.all does still work).

Web development did not change. Web development grew. There are more options now, not different options.

Browsers have become more capable and still work with web pages built over [20 years ago](http://info.cern.ch/).

You can use as little as you want or as much as you please. Here, for example is a [web site I built](https://zx.remysharp.com/audio/#src=MjM3LDE3MCwwLDEwLDIzNywxNDMsMCwwLDE3MywxMjAsMCwxNzMsMTAxLDAsMTczLDg1LDAsMTczLDcxLDAsMTczLDE1LDEsMTczLDIyOCwwLDE3MywxOTEsMCwxNzMsMTYxLDAsMTczLDEzNSwwLDE3MywxMTQsMCwxNzMsMTcwLDAsMTczLDE0MywwLDE3MywxMjAsMCwxNzMsMTAxLDAsMTczLDg1LDAsMTczLDcxLDAsMTczLDE1LDEsMTczLDIyOCwwLDE3MywxOTEsMCwxNzMsMTYxLDAsMTczLDEzNSwwLDE3MywxMTQsMCwxNzMsOTUsMCwxNzMsODAsMCwyMDgsMzI=) that ported a Windows XP tool to the browser without using a single framework. The tooling pipeline, originally was: a text editor and the ability to upload to a hosting platform - nothing else. In my case, I wanted something that behaved like a specific Windows program so that prerequisite relies on some dynamic programming language (JavaScript).

But there’s no doubt that it’s entirely possibly (and likely) that you’re working on a project with a complicated pipeline of tech all connected up. Maybe it’s some tools to check your code for errors (linting), and some tools to build and transform your code (like JSX to JavaScript, etc), and some aspect of CI (for tests or automated accessibility checks) and then some provisioning and staging environment (Netlify, Google Cloud, etc) and then some end point analytics or smoke tests.

But that’s because the businesses online have evolved and grown. In 1997, if your company was exclusively online you were either an innovator or a fool that was going to be quickly parting with their investment. Today, an exclusively online business is completely normal - so it’s understandable that the parts that go into supporting that business are larger and more involved.

I wouldn’t dream of hosting a business product on a platform that I couldn’t scale through some web interface.

But for my own playing? There’s no way and no need for the complexity that larger businesses need.

In the same way that if you wanted to sell an old monitor on a site like ebay, you’re not going to set up a limited business, file for VAT registration, appoint an accountant, get insurance and all the other very involved complicated tasks.

The web really didn’t change. It really didn’t become complex. The web development process is not one single path. There is simply more choice and more options.

We, you and I, the developers, consumers and businesses are responsible for demanding more complicated (and more thorough) tools. We are not, however, beholden to complexity.

Published 11-Feb 2021 under #web. [Edit this post](https://github.com/remy/remysharp.com/blob/main/public/blog/the-web-didnt-change-you-did.md)

👍 87 likes

[](](](](](](](](](](](](](](](](](](](](](](](](](](](]((/images/no-user.svg "Leon v. Kammen (cos)")]((/images/no-user.svg "Jan (Working remotely 🏡)")](](](](](](](](](](](](](](](https://twitter.com/cole007)

Lock Thread

Login

Add Comment[M ↓   Markdown]()

[Upvotes]()[Newest]()[Oldest]()


Aaron Davidson

0 points

22 months ago

https://daverupert.com/2021/10/html-with-superpowers/


Aaron Davidson

0 points

22 months ago

JS has now largely adopted what jquery(sizzle) mercifully brought to solve browser differences as well as introducing modules brought about by the frameworks and tooling you talk about.

CSS is now constantly being refined and replacing the need for JS in many areas.

HTML hasn’t changed so much since the seismic change of 5, but HTTP2 & 3 change years of "best practice". Devs caught up in complicated tooling fail to understand what is now native.

My point is that best/common parts of these frameworks WILL be integrated or simplified over time within the overall W3C framework, and the only thing to really concentrate on is understanding those fundamentals.

[Mike Foskett](https://websemantics.uk/)

0 points

2 years ago

From reading the comments Remy, there appears to be more than a few who may recall when IE6 was the mutt’s nuts. Myself included. ;o)


0 points

2 years ago

The choice isn’t even as stark as no-framework vs big framework vs jQuery. There are now options such as Alpine.js, which have the simplicity of jQuery, with some of the modernity of Vue but remain pretty light and easy to learn. It could be the goldilocks option for those who need (or simply enjoy) working in HTML with a sprinkling of progressive enhancement JS, but find vanilla JS a bit too raw and jQuery a bit too old.

https://github.com/alpine-collective/awesome

Point here is not to promote Alpine.js but to show that there really are options, which is great!

I like how Jeremy summed up in his 2019 post [Dev Perceptions](https://adactio.com/journal/15011):

I’ve also taken a lot from the mature, reasoned and pragmatic approach documented by Studio 24 in their open redesign of the W3c website. It’s a goldmine of information and insight into process and technology choices:

https://w3c.studio24.net/

The broader problem of poor leadership and recruitment practices among tech firms is a different issue and not really the fault of JS or the JS community. This problem is perhaps more about unsustainable and irresponsible (i.e. exploitative) business practices, which places unrealistic expectations on workers.


David Renelt

0 points

3 years ago

I’ve never changed, or at least I just grew with the addition of new Browser-API’s. But it became an uphill battle to convince my customers that a UI frameworks won’t help them. If your site is not an app, but a unique, very graphical UX, 90% of the work is the same between using a Framework or just going with vanilla JS. But the Framework comes at a huge performance and bandwidth cost. So it makes no sense at all.

But the argument is that it is "Best Practice" because the code is more portable from one developer to the other. The reality is that i’ve never had a project or heard of one that moved to another developer without that new developer rebuilding the app mostly from scratch. And secondly, "Best Practice" seems to change faster then projects getting outdated.

So who ever did things in Angular because it was "the shit" had to migrate to React, because that is "the shit" now. It hasn’t happend quite yet, but React isn’t "the shit" anymore either.

I still maintain sites that are older then 10 years, they all still work without touching a thing. Some have some jquery baggage which I very much regret now. But overall these old sites are still fast and slender. And anyone who knows HTML/CSS/JS would be able to work with them. So I call bullshit on the whole "portability" argument.

I’m in this game almost as long as the web itself is a thing. I’ve done my first websites in the mid 90s. I’ve seen things come and go quite a lot. There is a lot to keep up with. So I’m picking my fights and stick with keeping up with browser API’s and new language features.

Geez, this turned into a little more then a comment :)


0 points

3 years ago

I spent most of my career trying to get the perfect SPA toolset and now I am back here…​ with some PHP, maybe some WordPress - or just HTML and JavaScript for most of my projects. Funny. But that being said, I’d hate to build a huge long-lived project without the modern tools we have. Having a goal-driven design process really helps break things down and makes it easy to choose tools with confidence.


Gilberto Albino

0 points

3 years ago

Go read some of those websites that offer Tech Jobs oportunities and take a look what it takes to be hired as a frontend developer in 2021 for a miserable salary. Maybe people are really lazy not being able to study or learn a new thing after 10 stressful hours of working and in a world out of pandemics, spend up to 2 ours in public transportation. Really, people are lazy, but the majority will never touch the shoes of people who do this technologies and get slaved to enrich them.


Savino Pio Liguori

0 points

3 years ago

I partially agree. You can spin up a lot of stuff with plain simple CSS and JS. I still do that, when you have to deal with simple pages, plain websites, simple interactions like form validation ux/ui.

The point of frameworks is to CONTAIN certain degrees of complexity: on those fields, they are kinda-of necessary. Everyone who made a complex panel for a company with jQuery and CSS knows how much and how quickly it can turn into a monster with tons of unreadable code. Even if it is capable, jQuery it’s not so manteinable at scale.

To me, the FE fw fatigue exists because no one has ever considered the Developer Experience (before Svelte).


0 points

3 years ago

Great read, Remy! I admit that the issue is a lot more complex than [I managed to convey in my blog post](https://www.askonomm.com/blog/i-dont-want-to-do-frontend-anymore), but my overall point was that somehow, for whatever reason, working as a front-end engineer in a sense as making a salary and paying bills is reached a point of complexity where new-comers are faced with what seems like an impossible amount of learning just to land a job, and those of us who were moulded over time from the "simpler web" to this gradually, find it increasingly difficult to keep up with stuff. In no way am I saying that you can not write simple solutions for your own projects, sure you can, and perhaps I worded that bit wrong - but if you want to make money, you’ll have a seriously hard time finding a job where you can write simple solutions, with a simple stack.

The discussion that my blog generated made me realise issues I didn’t even know existed, such as how the hiring process is broken and tends to favour those CV’s that are keyword heavy as opposed to those that are not, thus making your colleagues hype-devs that love complicating the stack just because it’s new, or cool, so it surely must be better! Or how front-end engineers tend to only want to work at companies that are compatible with their hype-ness, so any stack that is older than N years is immediately regarded as legacy, old, and those jobs are not worthy of applying to, which then makes companies want to be on that hype train as well, because that’s where the employees are. Vicious cycle of sorts.


David Renelt

0 points

3 years ago

The "bullshit bingo" is and always was strong, because the people in the positions to hire, have no Idea what to look for. I’m a freelancer, so this reapeats for me with every new costumer. I combat it with my own "Bullshit Bingo".

To conivnce someone that a simple hosting would do: "It can be deployed as a Docker container as a serverless solution, making use of a NoSQL in-memory database, out of the box scaleable and cloud-vendor agnostic, but for now, it can just live on your rented webspace."

Or for using CSS: "We use the most performant UI tooling, making use of the latest Browser features while still being downwards compatible with older systems"

Or for using vanilla JS: "Our goal is to have our first impactfull paint, and the first interaction as fast as possible, look here …​ chrome lighthouse screenshot"

btw .. i very much enjoyed reading your blogpost.


-1 points

3 years ago

As someone who’s been in the industry for decades, I find all the posts about framework fatigue frankly irritating and totally agree with Remy. Of course hacking some HTML pages in your bedroom when you were 14 and doing stuff professionally in a studio are going to be different, doh!

As Remy said, in 2007 tooling was already complicated - if memory serves I used Bower, Ant for building, YUI for testing, some abomination called Sprocket for templating, jQuery in some projects but Prototype or Dojo in others, different flavours CSS preprocessors (PHP powered - so you had to get your hands dirty with that)…​ you get the drift. Professional work is complicated, because money and teams of people are involved, it’s not the tech in itself.

It’s also not any harder to be job ready nowadays - you forget that there was no Stack Overflow back then, nor a plethora of courses on Udemy etc for 10 bucks, nor army of devs on Twitter, mointains of books, piles of boilerplate on Gitlab, etc etc. I think it’s actually much easier to get started now.

So if you don’t like FE anymore fair enough, but please no more whinging about framework fatigue


0 points

3 years ago

Hi Akso - thanks firstly for the post and creating the discussion and thanks for dropping by here.

The hiring process sadly has been like this for nearly a decade that I’ve seen first hand. Thankfully I’ve not personally been at the end of it, but I remember running a workshop at the end of 2011 and attendees telling me that they had to have experience with backbone to get contracts. It has been and will be for some time, a buzzword industry.

And I agree largely that getting a job requires (a lot of the time) knowing some buzzword tech, in my circles it tends to be React. Equally though, not all the work, even in a React company, is React work.

I think the thing I get most upset at is the old guard vs. the new guard - "stop using frameworks" vs. "add all the cool stacks". The in-arguing is something that’s been niggling at me for a long long time and I’ve been writing posts like this for a while, and though I think a lot of people have taken this post as "you don’t need frameworks" - my point was (supposed to be!) that there’s a broad range of choice. The reality is that the majority of web developers are quietly working away with what they have and aren’t vocal because either they don’t want to be or they have no reason to be.

I guess I’m just trying to say: can’t we all get along!

Anyway, rambly - sorry. Thank you again for your post here and your original blog post 👍


0 points

3 years ago

So glad it’s not just me :) I’m a long-time web developer but still largely server-side apps, working mainly with PHP (my PHP and HTML are very separate things!) but obviously a lot more JS nowadays. Starting some new projects and have just spent some days researching all the current perceived-best-practice; am now reeling from the complexity that seems to be involved in adding a JS library or two to an app.

While meantime trying to resolve that with my existing knowledge and experience of being able to achieve the same end result by just - gasp - including a local/CDN version of eg Vue or some such. Fully ready to concede I’m a dinosaur; but amused that reading your article coincided with me finally saying *\**\* it and continuing with current barbaric methods in favour of actually getting some work done…​

[Jim](https://smidgeo.com/notes/deathmtn/)

1 point

3 years ago

I tell this people all the time. The thing about this question, though—

—for people working on their own, you’re right.

I think the thing that’s stopping most developers, however, is their managers and teammates. There is this horrible cycle in which managers say "We’re using React (or whatever framework) so we can easily hire devs!" Then, devs say, "I gotta learn React so I get hired!" Once you are spinning in that cycle, it is very hard to say, "Let’s drop React so we can make this piece of software quickly and simply!" I’ve brought it up and have found it makes people very uncomfortable.


0 points

3 years ago

I know what you mean, and the wonderful thing about the web is that it can be many things at many different points in time. If a developer, rightly, doesn’t want to work on web dev outside of work time (employed) then they’re going to use the process that’s laid out in front of them.

My post and question wasn’t a call to arms within big companies - like I said towards the end of the post - if you’re selling yourself on your own, you have the full gamut of choice available to you. If you’re working for any decent size company that relies on their website for their income, then there’s going to be a certain amount of procedure put in place.


0 points

3 years ago

Love this. I try to promote a similar message. Don’t overcomplicate things. Don’t throw a framework at a problem that doesn’t need it. Plain old JavaScript works well to solve a large number of problems we now regularly solve using React, Vue or Angular. Will your site get more complex? Maybe. Don’t prematurely optimize for complexity that doesn’t exist today. You cannot predict it and it’s likely your solution is needless for today’s problem and useless for tomorrow’s.


Hassanin Ahmed

0 points

3 years ago

It might be silly to admit that the environment around web development "shames" me into wanting to use these tools. For instance, I don’t enjoy writing React and I have absolutely no need for React but every once in a while, I ponder if I’m making the right choice by not using it, or if I’m "lagging" behind the rest of the industry.


0 points

3 years ago

Also that a lot of these are not actually new problems either, so much as they are a combination of escaping to a broader audience and our tendency to look at the past with rose colored glasses. For example: even when jQuery came out, if you were into these things you could easy have had library fatigue already. Similarly, when you look at the things that people are doing with frameworks today, lots and lots of this is not entirely new either - projects using Java or NET, etc had similar things happening - so many frameworks, build systems, package managers, libraries, etc - they just weren’t in a language you might also expect to work on the web itself and wound up in more isolated discussions.


0 points

3 years ago

me: nodding head over and over.

[Commento](https://commento.io)