My 2020 was colored by the considerable amount of time I spent analyzing data about CSS usage in the wild, for the CSS chapter of the Web Almanac, by the HTTP Archive. The results were eye-opening to me. A wake-up call of sorts. We spend so much time in the bubble of bleeding-edge tech that we lose touch with how the web is really built. Most of the web favors old, stable tech instead of new bling.
CSS-in-JS? Only 2% of websites.
React? Only 4%.
Service Workers? Less than 1%.
Houdini? Practically 0%.
Nobody uses jQuery anymore, right? Wrong. It appears on 83% of all websites! Everyone uses Jamstack instead of bloated CMSes, right, right? Wrong. Static site generators are used in less than 1% of websites, WordPress powers one-third of the Web.
A lot of the code we found could have been written a decade ago. When new tech ends up being used sufficiently to appear in these stats, it’s often because the primary driver is a popular library or framework. Effectively, we (standards folks, browser implementers, etc.) are building tech for tooling authors, who are the ones really building tech for the average web developer. Quite a perspective shift, isn’t it?
This kind of data is a palliative for all of the imposters out there who are compelled to study every new feature and API or else feel worthless.
Thank you. That is comforting.
This is why IE was so hard to kill, even though we thought nobody uses it. As being in tech since internet’s early days we forget what it feels like being non technical.
& WP uses jQuery, I run business on WP, perl, react etc…
I still need time to transition my sites, recently I have started using WP as a headless backend with react.
This isn’t surprising even a little bit to me. When ‘keeping up with one’s professional literature’ on a daily basis, reading articles by you, Chris Coyier, Šime Vidas, etcetera, it is easy, also for experienced developers, to feel lost in the plethora of ‘new’ web technologies that keep emerging. Coyier, for instance, really seems to like his Jamstack, Eleventy and what not. And rightfully so, don’t get me wrong! Because you guys need to come up with new things to write about every day.
But let’s not forget that developers like me, who operate just below the top level of specialists, are concerned with old-skool CMSs and ‘technologies of yesterday’ that still power the majority of sites on the Web.
Hear hear! I work in the non-profit space and it’s WordPress all down the line, including Kinsta, Cloudflare, Wordfence & LetsEncrypt. I use GIT & Terminal for the poor souls on Pantheon, with it’s long list of plugins with “issues.” I like Wix’s new Editor X, but not Wix itself… Even WP is too challenging for Joe Sixpack. These orgs, whether they know it or not, still need a webmaster.
This comment is perfectly on point here. What a lot of us developers often forget is that while we’re wowed by new technologies and better ways of doings things, our customers are the end user, the laymen and laywomen, who couldn’t even care less whether you used react, or JAMStack or Svelte, or Laravel or .Net.
They care that the website looks good and gets their business customers.
I tend to ignore articles that tout one programming language or a framework over another. Honestly, build your website out of sand if you want as long as it is designed well, performs great and allows for edits easily and smoothly.
Angular, React and web components… I have used these to create web applications for the past four years.
I have not used them to websites. However I am tempted to use next.js as a static site generator.
So true.
Also, Most of the stable servers/services are either PHP or dot net based… Much less of them are even node js. There’s a perfectly good simple explanation to that….
When you need to pick a flower from the garden… You use your hands, not a tank.
Using Angular to build a webpage is poor in every way.
Using a framework to write Sql queries is idiotic… Use SQL.
I have seen so many projects that are named projects since no one of the people involved knew nothing of the base needs of the customer and solved his wishes with what they know instead of what the customer needed.
Frameworks used for simple sql queries….
Frameworks used to create a simple table and put your values in it…
Frameworks used to do simple Js needs… Such as adding buttons and or elemnts within the Dom.
Jquery is awesome and makes JS easy as f***.
TypeScript makes you kNOW you ununderstand the JS and Dom.
Learn HTML it’s pretty easy.
Learn Css it’s the end chapter of HTML not a different thing!!!!
Learn JS Vainlla coz it’s amazingly easy today.
Want to be a bit more?!
Learn PHP or NODE.JS to control the back of your front.
Most of all… Understand that there are two sides with so much for each…
Frontend – no Angular/React nor any of these shitty crappy frameworks will make you u understand Backend nor will they help u build one.
Backend – no Angular/React nor any of these shitty crappy frameworks will make u understand Frontend nor will it help u build one.
To draw a circle on paper use a pencil with paper.
Practice ,later you can use a pen.
Using a pen before might work… But you will not have learnt
all of the abilities of a pencil….
As a web developer in the wild (wild web developer?) I can confirm the priorities of the people who pay my salary are: Does it work, does the stuff we wrote 15 years ago still work, and can we have these 3 new features by Friday? I don’t get to build using the bleeding edge for my day job. When something does become stable/supported enough to start using, I’m so incredibly grateful for the people who have put in the time to think, write, and make demos about it. If all that came up in a Google search was a spec document, we’d probably never implement anything new. The wild web of the future thanks you.
This is great. For a short piece, it says so much. I think it’s fascinating that only 4% of the web runs on React, and yet you’d think it was 96%, based on the job listings out there.
Front-end listings are so often about the bleeding edge stuff, when many companies could use people dedicated to supporting the current/legacy tech, too.
It may also be that a lot of job listings are about internal business application development, or b2b cloud / on premise apps which are usually not listed in search engine results directly.
These applications are often the right use case for heavy framework use. I’ve worked as a front-end dev for 11 years, used multiple libraries and frameworks (JQuery, ExtJs, backbone.js, angularJs, React, Angular) and never had to think about SEO once, because the product was not listed in search engines.
There is a whole hidden web behind the web.
As someone who likes reading about (and understanding some of) the new stuff, but uses PHP, MySQL and vanilla JS when it comes down to it, this is music to my ears.
Long live luddites.
Houdini always seemed like a pipe dream to me.
Or some kind of trickery?
These results aren’t surprising in the slightest.
I’m yet to see a single compelling real world use case for static site generators, and workers often fall into “cool, but unnecessary”. Sure, most dev sites love to chat about Jamstack, but lack of adoption in business/enterprise shows that it’s perhaps not the amazing new thing that many devs believe it to be.
Meanwhile, WordPress and jQuery continue to be both easy to learn and highly expandable, continuing their popularity with new and experienced developers alike.
A single compelling real world use case for static site generators? It’s the easiest way to create a website manually. Not sure how you’ve avoided seeing that quite major use case.
Haha only if looking at stats this way was correct. It’s as if one day an alien species were to visit planet earth, look at the entire population, and declare there are only two sexes present.
If we’re so hinged on stats, what we as developers should be really be concerned with are top 500 websites on the internet making most of the revenue, and staying in sync with those tech-stacks.
There’s no need to over-complicate a project with bleeding-edge frameworks, we should be using the right tool for the job.
Most businesses, especially those just starting out, are not going to pay you $50k to build them some custom site on laravel, or Vue.js, or whatever comes out next month.
“It’s as if one day an alien species were to visit planet earth, look at the entire population, and declare there are only two sexes present.”
And they would be correct for over 99% of mankind. Not the best example. ;)
I learn and use newer tech tools for fun side projects. But for work my employer expects stability, widespread support, maintainability, and rapid delivery — jQuery lends itself quite nicely for of those things. :)
As an unapologetic WP/JQ guy, I love this. Developers like me get things done for clients that need things done, and the client generally doesn’t care what you created it in as long as the business need is served.
I believe the perspective loss you noted here happens primarily because webdev community forums and conferences are populated with an overwhelming majority of corporate developers that have a specific, targeted job to do. As a freelancer, when I need to bring someone else in for support on a project I nearly always go with another freelancer. Mainly this is because they tend to have the flexibility and “let’s get it done” mentality needed instead of constantly trying to cram new tech into the mix.
On top of all these things, there is definitely something to be said for websites — especially small business websites of any purpose — having easy continuity of development. If a company pays good money for a website and the developer or agency is out of the picture for whatever reason, good luck finding someone that’s actually available, affordable, and reliable on a per-project basis to work on your CSS-in-JS/React/Houdini/flavor-of-the-moment site.
I prefer the solutions based approach. There’s no need to over-complicate a project with bleeding-edge frameworks unless they are actually needed.
These are interesting statistics, and I argued about a year ago that the bootcamp I teach at part-time should stop teaching mongo and teach mySql instead for this reason.
It would be interesting to see how/if the numbers changed if you tracked it based on web traffic. Things like react, PWAs, and static generators might have more of a presence… At scale, that’s where they were designed to shine.
Some good points made here, especially in relation to the use of WordPress.
In my experience of working on sites, it always comes back to a set of tools that just work for a project. One of these is a page builder that gets the job done. As we all know these are often not the flavour of the month for many.
In light of this It has often been suggested to me to go off and learn some new fancy framework. It starts out interesting but soon becomes a slog. Often at this stage I will sneak off to take a peak at the work of the one who suggested this path and I see very rudimentary results. It’s like all the brain energy has gone into the implementation of code and not much is left for design.
Don’t get me wrong, I am sure that in the right skilful hands these frameworks will produce a work of art.
I see this type of developer/framework malaise at play on the path taken with the block editor in WordPress. The block editor itself, though controversial for many, is in fact becoming very useful and enjoyable to use. The problem is the focus of attention, on Full Site Editing, is the wrong priority when other things are being overlooked. For example the use case of data entry where, on the back end, you want a simple form displayed to take data that is interpolated into a front end template. You don’t want to present the user with a free form mechanism for content creation in the form of the block editor. With that you are just distracting the user/client. Implementing the option to disable the block editor interface and leave meta boxes with custom fields should be easy to implement on post types right now with a simple update in WordPress core.
The other mistake with the block editor is that it enables third party vendors to make every conceivable Swiss Army knife block. It has been observed that this could lead to bloat with installs and the accidental removal of said blocks a breeding ground for orphaned code that the next dev/user has to decipher.
It might have been more conducive to best practice to have the block editor present a set of standard blocks for elements and layout with a an API that third parties could hook in their own bells and whistles and settings UI. All the page builders would then conform to this. Turn off or change page builder/theme and at least your content and layout is left in some reasonable state. This gets things done.
What we see with the team on the block editor is a lot of enthusiasm for the code they are working with but not enough on the end use cases.
Going back to data entry, one would wonder what Automattic’s plan for WooCommerce is, considering that it still lives in the classic space which is supposed to be retired soon.
@Keith Kritselis added a point that should have been incorporated into the stats by the creators: Web site traffic.
This is what closes the circle on the solution-based approach, that every other commenter was mentioning. Huge sites/apps, being supported by big teams need different tech than the coffee shop around the corner.
I love jQuery, it offers a brilliant way of getting into JS development and simplifies so many tasks.
Yes, vanilla JS may be quicker & removes bloat, but in my experience, performance issues around business applications come from server-side code. If I have to choose where to focus my efforts to improve performance then it’s certainly not in swapping out jQuery for vanilla JS.
It’s not just app performance we have to be conscious of, but also the performance of the developer.
This is cool to verify, but isn’t that surprising. The question is do you care about “website” as a basis for your metric, or something more tangible to value, such as web traffic or revenue generated.
I bet globally 4% of “farmers” are using robotics and automation, but they are producing 99% of the worlds food.
React is only used by 4% of websites, but what portion of the market traffic do those websites receive? And can they execute on new ideas more easily because they use React instead of jQuery?
Alex, your point is valid also. I tried out React once but don’t really need to understand how it works becuase the page builder on my site uses it under the hood; React is an encapsulated entity for me.
It’s a bit like Matt Mullenweg’s statement that we need to learn javascript deeply to now use WordPress. A bit of an overstatement for an awful lot of users of the platform. I dabble in both JS and jQuery but on a need to know basis, when required. This is enough depth for the sites I build for clients who are on a budget.
wordpress powers 30% of the public web. 83% of the public app 7se jquery. there is a lot of reuse for the same tech over and over (that is good).
SPA’s however are more used behind authentication and logins.
While this might relativate some of the numbers, you definetly have a point.
I have had the same first impression, but actually, we need to look at these statistics a bit deeper:
1. It’s counted all the websites, not the websites created in the last year
2. Companies generating revenue, such as Amazon, Facebook, Google and so one exclude their pages from Archiving robot analysis.
3. These companies pay for the work frontenders do. Most of the websites from the statistic are done for free. So different tools for different markets, which should be interpreted carefully.
I really thought the world is more advanced than this ;-)
WordPress 83% ? WTH. I am using static site generators for a loooong time now. Just transitioned from Middleman to Gatsby (will never look back). Also using a headless cms for a long time now. There is so much joy in a well packaged website with good performance characteristics.
But to be fair.. its a bit tougher to master Gatsby/React than to click in some menus in wordpress. So thats most likely the reason the numbers are as they are.
marc
“Nobody uses jQuery anymore, right? Wrong. It appears on 83% of all websites!”
“Appears” and “uses” are two different things. :)
jQuery is dead. The corpse is still there.
Great article and comments ^^^ above! It is nice to know my intuition and experience follows the comments of so may experienced web devs, but also the statistics.
After reviewing all the new 2020 website data on the Web Almanac, its obvious the youngsters entering this profession are not improving the Web via new scripting frameworks and toolsets as they claim.
The fact that these static page Javascript packages now shove into our phone browsers scripts approaching 500+ kilobytes on average with up to 800-8,000 millisecond thread times on their little CPU’s is nuts!! So every application needs a megabyte of scripts to print out some text? The ongoing trend has also been to moderniz, minify, prepreprocess, and polyfill basic css and html whose footprints are small already, but then download megabutes and megabytes of ECMAScripts scripts? It seems counter-intuitive at best!
The whole point of the Web 20 years ago was to move AWAY from a heavy client-side applications with thick scripting dependencies and harsh CPU cycles and get on board the lite-weight server model where tiny patches of HTML were sent to the browser and cached. Content used to be king, not scripts.
The last 10 years kids have gone backwards to the old desktop model but on mobile using Javascript! No wonder there isn’t wide adoption. And I predict there wont be. Looking at the stats we all should realize what’s old will be new again. Simple servers sending tiny pages of HTML and CSS is not only low bandwidth but lightning fast its been around for almost 30 years now with NO PROBLEMS! Why inject a megabyte of scripts to some poor mobile user. I honestly think the stats in 2020 teach us that coders in businesses and those stuck with WordPress and older frameworks still aren’t hurting for speed, needing knew web tools or models, or having development struggles. Yes, JQuery, PHP, and .NET still work and are reliable. The original World Wide Web has not changed. HTML and CSS and servers still drive most of what is online. Sadly, this proves what we knew years ago that ‘Javascript is still evil’. And this is coming from an Angular expert.
These new heavy client-side frameworks have their place, don’t get me wrong. In intranets they have proven helpful at the places Ive used them. But they aren’t any better than a older development solution that a corporation relies today to deliver a plain HTML page with information consumed by millions of people.
I sincerely hope the youth here trying to reinvent the wheel by developing all these scripted Open Source pie-in-the-sky solutions understand the web was never broken before you started playing with Javascript! You just never had the discipline (or mentoring) to understand how it has always worked before you dug your own rabbit holes. But keep digging!!