The State of the Web Platform

By Chen Hui Jing / @hj_chen

https://www.devographics.com

Chart showing rates of usage of highest-rating CSS properties over time

Join us on Discord.

Check out the code on GitHub.

The survey itself is an application that gets less attention that the survey questions and results, but work is consistently done to improve its features and user experience. Ever since the first survey, anyone could download the raw anonymised data for their own analysis. The State Of surveys from 2019 onwards had started to allow users to customise data queries via GraphQL on the application itself. Eventually, you could also update the charts to reflect the new query.

This allows folks who are versed in the ways of data analytics to explore even more insights and dive deeper into the data if they so wished. The 2023 version also introduced the concept of a reading list, such that folks going through the survey and found a property or feature or library they wanted to learn more about, they could add it to their reading list and come back to it later.

If any part of what I just said piqued your interest in any way at all, you can join us on Discord or go check out the application code on Github.

So, the GraphQL survey. What exactly is GraphQL anyway? GraphQL is a query language, specifically, an open-source data query and manipulation language for APIs and a query runtime engine. And it has implementations in almost every programming language you can think of.

GraphQL was invented by Facebook as a central intermediary layer between their many end-user-facing clients and many data sources. It was a specific problem that Facebook had, and they created a specific tool to deal with their problem. And back in 2022, GraphQL was something that had quite a bit of uncertainty and unclear best practices, and so Sacha decided to run the survey. But these days, it seems like the consensus is that GraphQL is best limited to niche use cases and use alternative less heavy-handed solutions.

Does this mean GraphQL is not useful? On the contrary. In fact, it is very useful when you encounter problems like slow loading times due to request waterfalls and overfetching or if your application has too many duplicative one-off endpoints. But if you don't need GraphQL, then you don't have to use it at all. Someone else could decide they wanted to know more about the GraphQL ecosystem moving forward, but it won't be run by the Devographics Collective.

https://wpt.fyi/interop-2024

https://web.dev/baseline

The State of CSS survey has had 5 editions so far, and the 2024 version will probably be out later in the year. And when looking over 5 years worth of data all at once, it reminded me of how much faster CSS is evolving today as compared to 5 years ago.

If you are coming to Code, I will be talking more in-depth about the State of CSS survey and CSS features, so if you are coming, it will not be déjà vu if you think you've seen some of these slides before. I do overlap a little bit.

When the State of CSS survey came about in 2019, in contrast to the State of JS survey, the CSS one was centred around CSS features themselves. The evolution of CSS has sped up over the past 5 years, and to be fair, browsers are also shipping new JavaScript features at a faster pace than before. This is why from the 2019 version onwards, features were also added to the JS survey.

As for CSS features, there are a lot of them. The last I checked (some time last week), there are 589 distinct property names from 81 technical reports and 83 editors' drafts. My personal opinion is that for the average web developer, there is really no practical reason to know each and every one of these properties and what they do, although I'm sure somebody does.

My take on things is to have a vague idea that something exists and can be used to do a thing. You don't have to know exactly how the property works, all its values etc. until you encounter an use-case where that something might be useful.

Like, I'm clearly not from here, I've heard of the AFL. And this might sound blasphemous but I don't know the rules, nor any of the teams or players. Now, my friend Chris suggested we go watch a game on Friday after the conference, and if I decide to say yes, then I would take the time to at least learn what the rules are. As of now, I do not.

Container queries

Pretend this is a responsive image

Cards need headers

Most cards have blurbs. This is the epitome of a generic example. Oh well…

A new feature that has seen a lot of attention this year is container queries, which allows you to apply styles based on attributes of a container rather than the entire viewport. With component-based architecture becoming the de facto design pattern for web applications, allowing components to adjust their styles based on the size of the container allows the same component to be shared across various different contexts in a more predictable manner.

Furthermore, the queries themselves are measured based on computed values on tha container element, so whichever width you specify for the query is based on the font size being used by the container, and not the site's base font size. Container queries also shipped with new cq units which specify lengths relatives to the dimensions of a query container.

See the Pen Container Query Bookstore by Max Böck (@mxbck) on CodePen.

Container Query Bookstore by Max Böck

The `:has()` selector

            /* Matches menu items with submenus in them */
nav li:has(menu) a::after { … }

/* Matches <h1> elements only if they have a <p> element directly after */
h1:has(+ p) { … }

/* Matches all <section> elements that do NOT contain headings */
section:not(:has(h1, h2, h3, h4, h5, h6)) { … }

/* Matches all <section> elements that have empty <div>s */
section:has(div:empty) { … }

Another feature ended up being widely talked about is the :has() selector, which is one of the many pseudo-classes that got released recently. People like to refer to it as the parent selector, or the family selector or the god selector. The specification just calls it the relational pseudo-class, and it represents an element if any of the relative selectors passed in as arguments would match at least one element when anchored against this element.

That is a mouthful but practically, it opens up a cleaner approach to dealing with component variants. Maybe you have a product card that may or may not have an image within it, or menu items that may or may not have submenus, or heading components that may or may not have subtitles within them, or sections that just happen to have no content in them. You can select them without having to add more specialised CSS classes, I have seen and personally used ternary operators in my component markup for this purpose.

Mobile applications. Wait, aren't we talking about the state of the web platform? Yes. I promise I'll make it relevant again.

When iPhone OS was unveiled, Safari 3 was included and you could browse the internet from this sleek new touchscreen smartphone. Android OS, after a number of twists and turns (and acquisition by Google) was first released on the HTC Dream in 2008. It too shipped with a browser that, fun fact, was based on Webkit.

As adoption of such smartphones took off, the mobile application market also grew, or maybe it was the growth of mobile apps that pushed adoption of those smartphones, I can't say. But the fact was that more and more people could feel the UX difference between native mobile applications and websites on mobile browsers.

I posit that a lot of these frontend frameworks were created to allow web developers to recreate the smooth experience native mobile applications provided. A component-based architecture that allowed modularity and reusability across various parts of the website became a pattern that many applications were built upon.

I am, however, not in the position to explain why React gained so much traction. I did find a theory proposed by Brian Knapp who stated that there were 3 reasons. Firstly, it was because React was created by Facebook. Number 2: it solved major issues for Single Page Applications at the right time, and lastly, the concept of self-reinforcing popularity. The "because everyone else is using it" reasoning. You can agree with these reasons, you can not. But React does still sit on the top of usage charts in the State of JS survey.

HOWEVER, interest, retention and positivity toward React is trending down. I'm not sure if we are reaching a tipping point for resource hogging and JavaScript bloat when it comes to web applications but you can't deny that a framework-first approach has made basic web development an exercise in complexity.

I do think it is worth taking a step back and being more deliberate in our development choices. And I'm sure everyone here has very different working environments, with vastly different requirements. Not just between different companies, but sometimes even for different projects within the same company.

Just because one approach or framework was perfect for a project doesn't mean it will be perfect for the next one. It might, but it also might not. A lot of people groan when they hear the phrase "it depends", but tough luck, it does depend. On context. Which, if I could make a subjective statement here, as an industry, we're tragically not prolific at.

In an ideal world where unicorns shit rainbows, we would have clearly defined project requirements plus an experienced team with the time and freedom to analyse which framework would best suit the project's needs, or if a framework would be necessary at all. But the reality is that either one or all of those factors are missing in our context.

Some of you might work in places where specific frameworks are mandated because all projects need to use the same technology stack. Maybe it is to facilitate consistent and scalable deployment environments. Or the organisation wants engineers to be able to move between projects without spending too much time onboarding.

To be fair, those are perfectly good reasons, I think the issue most of the time is that these reasons are not clear nor well articulated to the team. In the best case scenario, it might be a matter of developing processes that ensure such information made known throughout the entire tech team. In the worst case scenario, the decision was arbitrary and has no good reason.

After listening to the day's sessions, I realised that many of you might be in the position to create an environment similar to the unicorn-rainbow-poop-land that I just described. I'm not a code leader, more a code acolyte, so to offer some perspective from the ground, we feel like more often than not, some framework just ends up getting shoehorned into the project whether we like it or not. Knowing the reason was not arbitrary is a morale booster. Craig said it this morning: Share the whys!

The next best thing we can do is to be aware of the gaps, and document the whys of technical decisions. Especially when faced with constraints, since it is more likely that we make unorthodox decisions. Having a decision log where people can trace back why certain parts of the codebase ended up the way it did can be extremely helpful.

I want whoever inherits my project to be able to figure out the gotchas quickly and hit the ground running. I believe developer karma is real. Because at some point in our careers, we are going to inherit someone else's project. Think about that.

Node.js is used by 3.3% of all the websites whose web server we know.
–W3Techs

PHP is the most used server-side language on the web as of 2024

PHP is used by 76.2% of all the websites whose server-side programming language we know.
–W3Techs

At the very least, make sure you know what jQuery is doing for you, and what it's not.
–You might not need jQuery

I love what the “You might not need jQuery” website states right when you land on it. It never says to not use jQuery ever, if it makes it easier to develop your application, go right ahead. But if you're developing a library, consider if jQuery is needed as a dependency. The site suggests thinking about the why behind the decision. And I think that applies broadly across our scope of work as developers.

Libraries and frameworks are an integral part of pushing the web platform forward, because they are indicative of what developers need to build the features they want. Perhaps a library's success indicator is that it is no longer needed because its features have become natively supported by the platform. Which makes jQuery a rousing success. Let's give a round of applause to jQuery.

Top 10 missing elements from the State of HTML survey

Top form related pain points from the State of HTML survey

See the Pen Untitled by Chen Hui Jing (@huijing) on CodePen.

For example, a feature that has recently become Baseline newly available is the Popover API. All you need is a button to trigger the popover and an element that serves as the popover. On the element, set a popover attribute and give it a unique ID. Then set the popovertarget attribute on the button to the value the popover element's ID. Without any additional scripting, you have a popover that can be dismissable by the escape key or clicking outside of it. And you are free to style it with CSS however you like. Amazing.

Web Components

In her conclusion for the State of HTML survey, Lea Verou made an excellent point that these State Of surveys are only a snapshot of developer perspectives, and reflects the state of the web platform at a specific time.

They are one of numerous data points that the folks working on web standards and browser implementations use to push the web platform forward. Even though in many other industries, especially the very established one, standards are created and maintained in a closed manner, web standards and browser implementations are discussed and evolved in the open.

And it is in these fine folks' best interests to develop features that developers like you and I want to use. So they do keep a look out for what developers are saying on social media, blog posts, GitHub issues for the CSSWG and TC39, surveys like ours and so on. So if you do write code at all, professionally or otherwise, I encourage you to participate the next time a new one comes out.

References

Thank you

https://chenhuijing.com

@huijing

@huijing@tech.lgbt