The State of the Web Platform

Thanks, John, for that very flattering description of myself.

My mom would be very happy to hear it.

But hello everyone.

So what John said, I had been here before, but that was like 2018, so it was a very long time ago.

This is my first Code Leaders, we'll see how it goes, we'll see how it goes.

And can I just say that the weather is fantastic for me because it's frustratingly hot and humid where I come from.

So let's get into it.

How many of you fine folk have actually heard of or participated in any of the state of surveys before?

That's more than I expected.

Great.

Because only last week I realized that there are some state of surveys run by different organizations as well, and, nobody has a monopoly on the term state of.

Here I am with the, state of web platform as my session title.

But I digress.

The state of the series of surveys that I'm talking about today started back in 2016, when Sasha Greif spelled G R E I F.

He was feeling confused about what JavaScript technologies he ought to spend his time learning, so he decided to start a State of JS survey to crowdsource opinions and all that.

And back then, it was mostly around JavaScript frameworks and libraries.

Then one thing led to another, and then the project grew from a one man operation to a small team.

The DevoGraphics Collective, and I'm not sure if that's their official name or not, but they have a logo and everything.

Now the team, they're now working on this much larger series of state of surveys.

So it's this collective of the fine folk on the screen here, plus other contributors, volunteers, and translators, that allow this project to continue going year after year.

There have been five different surveys in the series so far, with JS and CSS ones being the most established of the lot.

There also might not be another GraphQL one moving forward, and I'll mention why in a little bit.

But the survey itself is an application that gets a little less attention than 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, anonymized data for their own analysis.

Surveys from the 2019 iteration onward started to allow users to customize data queries via GraphQL on the application itself.

And, the most recent ones, you can update the charts to reflect your new query, so it is being developed as an application.

What this allows is for folks who are well versed in the arts 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, so as you participate through the survey, you're, encountering these new features, frameworks, libraries, You are like, Oh, this is interesting.

I would want to learn more about it.

But later, you click Add to Reading List, and hopefully you'll come back to it later.

Because most people I know have 300 tabs open, and they will get to it one day.

If people If any of what I just said about the state of survey itself piqued your interest in any way and you were like, I want to join this, I want to contribute, you can join us on Discord or check out the application code on GitHub.

So the GraphQL survey, what exactly is GraphQL anyway, eh?

It is a query language, specifically it's an open source data query and manipulation language for APIs, it's also 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, because there are many user facing clients that needed to talk to many data sources, and so they had a specific problem They had a huge engineering team, they came up with a solution to solve their specific problem.

Back in 2022, GraphQL was something that seemed to have a bit of uncertainty and unclear best practices around it, so Sasha decided to run the survey.

But these days, it seems like the consensus is that GraphQL is best limited to niche use cases, and most other applications would probably be best run with less heavy handed approaches?

Does this mean that GraphQL is not useful?

On the contrary.

In fact, it is very useful when you encounter problems like, say, slow loading times due to request waterfalls, or if your application has too many duplicative one off endpoints.

Those problems?

GraphQL, perfect.

But if you don't have those problems, you don't need GraphQL, then you don't have to use it at all.

Now, someone else could decide that they wanted to know more about the GraphQL ecosystem, and moving forward, run another survey, but most likely, it wouldn't be run by the DevoGraphics Collective.

Now before we really dig into things, I want to highlight the Interop initiative, which is a strong collaboration between all the major browser vendors and their friends for improving the web platform across the board, and to make the web platform more usable and reliable for developers like you and I, so that we can spend more time building great web experiences instead of worrying and working around browser inconsistencies.

The initiative introduced the concept of baseline, which seeks to provide more clarity to information about browser support for web platform features.

So there are two stages.

A feature can be newly available when it becomes supported by all the core browsers.

And it beca it can become widely available after 30 months has passed since the newly interoperable date.

So baseline is now also part of caniuse.com, so features that are in baseline is gonna show like a batch along with the year that they became newly baseline available and so on.

So we're gonna start with the state of CSS survey.

Which has had five editions so far.

The 2024 version will probably be out later this year.

And when I was looking over five years worth of data all at once, it just reminded me of how much faster CSS is evolving today as compared to five years ago.

Now, if you are coming to code, tomorrow, Friday, I will be talking more in depth about the survey and then, some highlighted CSS features.

So if you are showing up, it will not be deja vu if you have seen some of these slides before.

It's, totally me, it's not you, I do overlap a little bit.

But when the state of CSS survey first came about in 2019, in contrast to the state of JS survey, the CSS one was heavily centred around CSS features themselves.

Because the evolution of CSS has sped up over the past five years.

And to be fair, browsers are also shipping new JavaScript features at a faster pace than before.

So from the 2019 version onward, the JS survey also included platform features as well.

As for CSS features, there are a lot of them.

The last time I checked, which was some time last week.

They are 589 distinct properties from 81 technical reports and 83 editors drafts.

Now my personal opinion, you can agree or not, is that for the average web developer, there's really no practical reason to know each and every one of these properties and what they do.

Although I'm sure someone's going but I do!

I'm like, good on you.

My take on things is to have a vague idea.

That something exists.

It can be used to do this thing.

And you don't actually have to know exactly how the property works, all the values, all the quirks and everything, until you run into a use case where you're like, oh, I remember vaguely this thing that I encountered that might work here.

Then you dig into it.

Because we all have limited, lifespans and brain power and all that.

As analogies go, I have a terrible one.

I'm clearly not from here.

And I've heard of The AFL, and now this might sound blasphemous, but I don't know any of the rules, no teams, no players, and my friend Chris there has suggested that we go watch a game on Friday after the conference, and if I do decide to say yes, then I would take the time to at least learn what the rules are.

As of now, meh.

Now a new feature that has seen a lot of attention this year is container queries, which allow you to apply styles based on the attributes of a container rather than the entire viewport.

Now 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 this same component to be shared across different contexts in a more predictable manner.

Let's see if this demo works.

Okay, this is an example.

Oh, yes.

This was an eyesight test.

But, the thing is, normally when we do a media query for responsive design or anything, we do base it on the size of the viewport.

My slide's not gonna change viewport, but with container queries, the container in which my very random and generic example lives in, we can change the styles based on the context in which the component lives in.

And I think this is like an es Especially useful, tool in, the way we, design our applications these days.

In addition, I think a, very useful aspect of container queries is the fact that the queries themselves are measured based on the computed values on the container element.

Which means that whatever query, like your min width something, max width something, That, that length, that, that unit, is based on the font size of the container, rather than the site's base font size, which is usually like 16 pixels.

So what, this means is that you can more predictably determine how you want your component to look like at specific widths.

Container queries also shipped with something called CQ units.

It's like to complete the set of features whereby it is a length unit that is relative to the size of the container.

So it's things like CQH for height, CQW, et cetera, et cetera.

So when you combine this entire set together, and I'm gonna show you a much better demo than my set demo.

This, It's a, it's a CodePen by Max Bock, really good.

So it's an application, literally, like a bookstore application, where every single book uses the same component code.

And depending on where you want the book to go, it's gonna change its styles.

And you don't have to have, extra, classes or anything, or rewrite the component.

The same component can be styled differently, depending on the context.

And I think this presents a refactoring opportunity for codebases that rely on duplicates to achieve a similar effect.

So definitely something to ponder if, it's relevant to you.

Another feature that ended up being widely talked about is the :has Selector, which is one of the many pseudoclasses that got released recently.

And people like to refer to it as the Parent Selector, some people call it the Family Selector, I've heard a person call it the God Selector, and, the specification just calls it a Relational Pseudoclass.

And that's it.

Let's see if I can get this right.

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 doesn't make sense.

It's not really English.

But practically, it opens up a cleaner approach when it comes to dealing with component variants.

Because maybe you're going to have a product card that may or may not have an image, or menu items that may or may not have submenus, or hidden components that may or may not have subtitles.

Or you could even have But based on the user who's logged into your application, there could be sections that just have no content in them, and I don't want to show an entire container.

The :has Selector allows you to target these conditional situations in a much cleaner manner.

Because today, what I would do is, I would end up having to add specialized CSS classes, I have used ternary operators in my component markup just to get those classes in there.

That, that, you can actually refactor that out whilst using the :has selctor.

But overall, in contrast to JavaScript frameworks, which I feel will continue to be mainstream at least in the near future, CSS frameworks have steadily seen a downward trend.

Given how much faster CSS features are being broadly supported these days, it has gotten to a point where the frameworks are starting to fall behind in terms of supporting the latest features.

Because for CSS frameworks, they are like a layer of abstraction between the platform and the developer.

So I don't think that they will actually die out altogether, but I do think people will reach for them as a default less and less moving forward.

Now the big one, which is the State of JS survey.

This one's the longest running.

As I mentioned, it started in 16.

It's been running continuously every year, so there have been 8 editions.

Looking back, it also gives us a reminder of the state of the industry back then.

Because 2016 was also about the time where frontend frameworks really started to go mainstream.

AngularJS, don't know if anyone still remembers it, it's now discontinued.

But that was released in 2010.

Think about the years here.

EmberJS came out in 11.

MeteorJS came out in 2012.

The big one, React, came out 2013.

Vue came 2014.

Angular 2 came out 2016.

The point is, it's relatively safe to consider the 2010s the boom times of JavaScript front end frameworks.

But why, though?

Why did these front end frameworks come out so fast and furious during this time period?

And everyone was in on it, everyone wanted to use one.

I'm no expert, but I do have a theory.

Theories are free.

My theory is mobile applications, and you're like, wait, are we not talking about the state of the web platform?

Yes, I promise, I'll try to make it relevant again.

Now when the iPhone OS, that's what it's called, exact logo, exact San Francisco font, in case any of you didn't realize, Safari 3 was bundled with iPhone OS, and you could browse the internet from this swanky, sleek, new touchscreen smartphone.

Now, Android OS, after a bunch of, twists and turns and acquisition by Google, it was first released on the HTC Dream smartphone in 2008.

And that too shipped with a browser, which, fun fact, was actually based on WebKit.

Hey!

Now, as adoption of such smartphones took off, the mobile application market also grew.

Or maybe it was the growth of mobile apps that pushed the adoption of these smartphones.

I don't know.

I'm not an expert.

But the fact was that more and more people could feel this UX difference between native mobile applications and websites on mobile browsers.

So I posit, just a theory, that a lot of these front end frameworks were created to allow web developers to recreate the smooth experience that native mobile applications provided.

A component based architecture that allowed modularity and reusability across various parts of a website became a pattern.

That many applications are now built upon.

I am not in a qualified position to explain why React gained so much traction, so I did my Googling, and I found a theory that seemed rather plausible.

It's a theory proposed by Brian Knapp, who stated that there are probably three big reasons.

Firstly, it was because React was created by Facebook.

Number two, it solved major issues for single page applications at the right time.

And lastly, there's this concept of self reinforcing popularity, that you know, because everyone else is using it, reasoning.

Now you can agree with these reasons, you can not, but the fact is, React does still sit on top of the usage charts in the State of JS survey.

However, Interest, retention, and positivity to what React seems to be trending down.

Now I'm not sure if we're just reaching a tipping point for resource hogging or 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.

What I do think it's worth is taking a step back and being more deliberate in our development choices.

Now, I'm sure everyone here has very different, working environments with vastly different, requirements for projects, and not just between different companies, but also between different projects even within the same company.

But the thing is, just because one approach or framework was perfect for a successful project, it doesn't mean it's gonna be the right one for the next project.

It might, but it also might not.

Now, 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 very subjective statement here, as an industry, we are tragically not prolific at this.

In an ideal world where unicorns shit rainbows, We would have clearly defined project requirements, plus an experienced team with the time and the freedom to analyze which framework would best suit the project's needs.

Or, if a framework would be necessary at all.

But the reality is, either one or all of these factors are missing in our context, right?

Some of you might work in places where specific frameworks are mandated because, all projects need to use the same technology stack.

Maybe it's to facilitate consistent and scalable deployment environments.

Because I've been there.

Or the organization wants everyone to be, all their engineers to be able to move between projects without spending too much onboarding time.

I've also been there.

To be fair, these are perfectly good reasons.

Very, good.

Logical.

I think the issue is that most of the time, these reasons are not clear nor well articulated to the team.

In a best case scenario, it might be a case of just, developing some processes to ensure such information is disseminated well and made known throughout the entire tech team.

In the worst case scenario, the decision was arbitrary and there's actually no good reason other than your manager felt like it.

Hopefully not.

Hopefully not.

After I've listened to the day's sessions, I've realized that many of you might be in the position to create an environment similar to the unicorn rainbow poop land that I just described.

So I I hope you can do that.

Because I, I'm not a code leader, I'm more of like 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 in the project whether we like it or not.

But, knowing the reason why, knowing that the reason was not arbitrary, is a morale saviour.

Like, Craig said, it this morning, share the whys.

So I, support that sentiment.

So the next best thing we can do is to be aware, of the gaps between our technology choice and the project requirements.

And then again, document the whys of technical decisions, especially if we are doing a project that's faced with these constraints.

Because when we face, a lot of constraints.

It's more likely that we make unorthodox decisions, right?

So having a decision log where people can trace back why certain parts of the code base ended up a certain way I think can be extremely helpful.

I want whoever inherits my project to be able to figure out the gotchas quickly and hit the ground running because I believe in developer, karma.

Developer Karma is real.

At some point in our careers, we're going to end up inheriting someone else's project and hopefully you have enough karma to get a project that is documented in a way that you don't look at it and you're like, were they drunk?

Karma.

Think about it.

Like I said before, React still seems like the most dominant framework at the moment, and if you would like to discover more insights, do stay tuned to the results of the State of React survey.

We ran it late last year.

Honestly, there had been plans to run a state of React survey for a while, given how popular it was, but attempts to collaborate with the React core team fizzled out, so we only managed to get it going last year.

So there will also be a 2024 survey for React this year, but again, later on in the year, because it's very, it's a lot of work to try to, make sense of all the data and the results.

Now, JavaScript is not only used for the front end.

Most web developers associate server side JavaScript with NodeJS, and rightfully Since it is still the dominant JavaScript runtime today, if you Google node usage on websites, you will see this number, 6.

3 million websites.

You will never see where that number came from though.

I've tried to find the source.

I don't know where the source is.

Everyone just uses it.

You can try right now, Google it.

You'll see 6.

3 million for the first two pages, and nobody just, nobody codes the source.

It's just 6.

2, 6.

3 million websites, which does sound like a lot, until you look at the data published by W3Techs, which says that NodeJS is used by 3.

3 percent of all websites whose web servers are known.

Don't know anyone who works at W3Techs, so I can't really fact check this number, so just take these statistics as, a reference and not gospel.

But 3.

3%.

What about the other, 96.

7?

What are, they, running?

I, would like to take some guesses.

Someone please shout out.

What do you think?

I knew it.

I knew someone was going to get the right answer.

Absolutely correct.

It is PHP, my friends.

PHP.

Even though we do not have a state of PHP survey, nor are we planning one.

I thought this is a fact worth mentioning.

We should all try not to get too caught up in hype cycles, because there won't ever be a technology, or framework, or library, that can solve all problems for all time.

Take something like jQuery, which nobody really talks about anymore.

It is still widely used, and it will continue to be widely used for years to come.

And I love what the You Might Not Need jQuery website states right when you land on it, on the homepage.

It says, it never says to not use jQuery ever.

If it makes it easier to develop your application, they're like, go right ahead, use it, it's a good library.

But if you are developing a library yourself, they ask you to just consider, do you really need jQuery as a dependency?

So what the site is suggesting is thinking about the why behind your decisions.

And I think this applies broadly across the scope of work that we do as developers.

Now 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 that they want.

So perhaps a library's best success indicator is that it is no longer needed because the features it provides has become natively supported by the platform.

With that definition, jQuery is a rousing success.

So I would like everyone to give a round of applause to jQuery.

Yes!

[Audience applauds] jQuery, actively supported today.

And finally, the most recent survey whose results have just been released is the State of HTML survey.

Even if you did not participate, I think it's still very interesting to just go review the results.

Now the key person who did the heavy lifting for the crafting of this survey was Lea Verou, W3C Technical Architecture Group member and contributor to numerous CSS specifications.

Now HTML is the OG of the web.

It is the key pillar that has existed since everything began back in 1989.

Yes.

Yes.

The web is the same age as Taylor Swift and one year younger than Rihanna.

I know this because I got asked in a trivia, trivia comp thing and I got it wrong, sadly.

Now in spite of the lack of hype around HTML, things are continually evolving in this space, just very quietly.

The state of HTML survey goes beyond just pure HTML alone, it almost seems like a catch off all the things that we couldn't fit in the state of JS and CSS surveys.

So it turns out that developers want more interactive HTML elements.

So the top, because we ask people, what do you think is a missing element in HTML, right?

So the top ones were all interactive widgets of some sorts.

Now I wonder if this ties into my mobile applications took over the world and changed the nature of web development hypothesis.

A lot of developers have spent the last decade building components that are mostly interactive widgets.

And given the rate that we move around, as an industry, I think a big chunk of developers must have built similarly functioning interactive widgets again and again in different frameworks, different styles, different design systems, you get the picture.

And maybe, just maybe, we are starting to warm up to the idea that maybe the browser could do that for us.

But we are a tricky bunch to please as developers, because based on feedback on interactive elements that already exist, which is largely, form inputs, the biggest pain point is styling and customization.

So what I'm hearing here is that the message we're sending back to the browsers is like we want the browser to do really complex things for us, but we also want to be able to make those complex things look like we built them ourselves.

But in all seriousness, this is not an unreasonable thing to ask for, and the folks who work on specifications and browser implementations are actively developing new initiatives to improve the current situation.

I think that's a good thing.

For example, a feature that recently became baseline newly available is the Popover API.

Now, I don't know if you've had to build popovers, or dialogues, or modals, or whatever, but I've spent a lot of my time having to deal with oh, now I have to hijack the escape key, and then I have to deal with when someone clicks outside the thing, and so on and so forth.

This is a demo with nothing.

Basically, it's just HTML.

It looks like this because there's no CSS, there's no JavaScript involved.

So what you do is on the element that you want to be the popover, you give it an attribute of popover, and then you give it a unique ID, and then you need a button to trigger the popover, so then on, you manage to link these two things together by setting popover target to the element ID.

So all I, all you do is click it, and it just shows up.

I'm not gonna hit escape because my slides have already hijacked escape, but you, can do the click outside to close thing and I'm clearly sharing some past trauma here, but I love that no JavaScript is needed.

Oh my god, this took me five minutes.

And, again, there's no CSS here.

You are definitely free to style it with CSS however you like.

It's not hidden in the Shadow DOM or whatever.

So I think this is amazing.

One of many examples.

As for web components, that's what we have Keith for!

.Moving on.

But seriously, the results, albeit a relatively small sample size, of all web developers around, is that they do indicate that actually people are using web components.

But the consensus is that the developer experience for web components still leaves very much to be desired.

The browser people and the spec people know this, and they are working to make it better.

So 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 they reflect 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 ones, think, banking, whatever, standards are created and maintained in a closed manner, web standards and browser implementations are discussed and evolved out in the open.

And it is these fine folks, it is in these fine folks best interest to develop features that developers like you and I want to use.

So they do keep a lookout for what developers are saying on, say, social media, what they're writing in blog posts.

GitHub issues for the CSS working group and TC39 are public, right?

And then there are surveys like ours.

So these are all just data points to inform them of what a day to day developer need.

And if you do write code at all, professionally or otherwise, I do encourage you to participate in the next state of survey the next time a new one comes out.

Thank you.