State of JS 2022 Survey Preview

[SachaG]

Live Survey Preview

https://survey.devographics.com/survey/state-of-js/2022

GitHub Project

You can track the state of the survey contents here:

https://github.com/orgs/Devographics/projects/2/views/1

Details

Note: everything is still temporary, additions and removals can still be walked back before outline is finalized.

Features

Added

• Temporal
• Array.findLast()
• Error.prototype.cause
• Object.hasOwn
• Regexp Match Indices

Removed

• optional chaining (already established)
• BigInt (old enough)
• web audio (too niche)

Libraries

Added

• Qwik
• Stencil

Removed

• Stimulus

New Category: Rendering Frameworks

• nextjs
• nuxt
• gatsby
• redwood
• blitz
• remix
• astro
• eleventy
• sveltekit

Back-end Frameworks

Added

• Adonis
• tRPC
• Directus
• Keystone
• Amplication

Testing

Added

• Selenium
• Testcafe

Build Tools

Added

• Turbopack

Mobile/Desktop Apps

Added

• NativeScript

Other Tools

Added

• zod
• partytown
• tanstack query
• Radix UI
• Mitosis
• Theatre.js

New Question: Back-end as a Service

See https://github.com/Devographics/surveys/issues/58

New Question: Edge Runtimes

See https://github.com/Devographics/surveys/issues/59

New Question: JS App Patterns

See https://github.com/Devographics/surveys/issues/56

New Question: Video Creators

See https://github.com/Devographics/surveys/issues/53

[AndrewIngram]

I like tRPC, but I wouldn't call it a backend framework, I'd describe it as an API layer. And Blitz is closer to being a backend framework than anything else (it's partly an API layer like tRPC, but does quite a number of backend things too)

[SachaG]

@AndrewIngram yeah I wasn't sure about tRPC, good call. And I'll move Blitz to the back-end section then.

[sirisian]

I don't know if my previous comment was clear, but I think the wording here will confused people:

Static Typing: Native types (similar to what TypeScript offers).

There's a types-as-comments/annotations proposal created recently called Type Annotations. This proposal is not native types and someone that supported it might think that's what the option above implies. (Or if they did understand the proposal they'd be confused why there isn't an option for it). While the proposal does pull syntax from TypeScript, it specifically does not implement native types or a runtime checker. Using "TypeScript" syntax doesn't define the type of Static Typing as native types vs types annotations which can use very similar syntax, but they'd produce very different results and language features.

Phrasing Static Typing without specifying the goals was an issue with the 2021 survey as it wasn't clear what opinion is being tallied.

I think the most explicit wording would be:

Static Typing: Type Annotations/Types as Comments
Static Typing: Runtime/Native Types

For the latter if you need an example proposal I have one. Like the Type Annotation proposal it's a WIP, but it shows the various differences in language features. (If you need a small explanatory paragraph comparing both I could write one).

[markerikson]

Quick thoughts:

• The list of "other tools" is a very oddly scattered grab bag
• Feels odd to have just "TanStack Query" in there, when there's no other "data" related libs in the survey that I can see. (Seems like the "Data Layer" question got removed in 2021 looking at questions_outline.yml. Also, most folks still probably know it as "React Query".
  • Personally, I'd suggest having sections for both "State Management" (Redux, Mobx, VueX, Pinia, maybe a few others) and "Data Fetching" (React/Tanstack Query, Apollo SWR, ....)
• Similarly, seems like there's one random UI lib (Radix), and no other UI component libraries. Suggest either remove it and keeping the "Other tools" section limited to framework-agnostic util-ish libs, or have another section on "Component Libraries"
• Also don't think it's worth listing TurboPack. It was literally just announced a week ago, it's still in alpha, and it's Next-only until it gets farther along.

[SachaG]

Phrasing Static Typing without specifying the goals was an issue with the 2021 survey as it wasn't clear what opinion is being tallied.

@sirisan I see your point, but I'm not sure survey respondents would understand the difference? Maybe it's a bit too in the weeds for the survey?

[SachaG]

@markerikson good point, I mostly added projects that got popular this year but we can definitely narrow it down a bit more.

Regarding TurboPack, on one hand I agree with you but on the other hand if we do think it might play a big role in the ecosystem in the next few years, it might be good to have historical data starting this year just so we can track its evolution from the start?

[DominusKelvin]

Hello can we add Sails.js for backend?

[SachaG]

@DominusKelvin Sails hasn't shown a lot of momentum lately, projects that are in that category tend not to be included.

[DominusKelvin]

@DominusKelvin Sails hasn't shown a lot of momentum lately, projects that are in that category tend not to be included.

Got you.

[sirisian]

@SachaG I'd recommend removing it then completely as any conclusion drawn from it will confuse people more (or be used to draw flawed conclusions about the direction of JS). I've had people on both sides of the discussion talk to me thinking it means people support my proposal for native types and I've had to explain that might not be the case due to the vagueness. The current types annotation goes so far as to use this survey as proof that people want types as comments and not native types which shows just how confusing it is when worded incorrectly.

[SachaG]

@sirisian What if I change it to

Static Typing: Native runtime typing; or TypeScript-style type-as-comments

This way people who don't know the difference but just want some kind of typing can still pick it, and people who do understand the difference won't think the survey is leaning in one direction or another?

Basically I totally understand the issue, I'm just afraid if we offer people a choice they won't understand the distinction, and it will make the results less reliable.

[SachaG]

Actually, after some thoughts I've decided to move back-end and full-stack frameworks to the "other tools" section. I feel like these frameworks have always stuck out a bit among the other items in the survey, since so much of it is focused on the front-end. So it might be best to embrace that instead of doing a poor job trying to accommodate too many different concerns.

[RomainLanz]

I really like the way you splited Back-end Frameworks and Rendering Frameworks. In my opinion, you can keep it like that instead of moving them to "other tools".

[SachaG]

@RomainLanz I don't want the survey to be too long though, I'd rather think about a separate "State of Node" survey down the road that can properly focus on back-end frameworks.

[RomainLanz]

Yes, if you plan to create another survey dedicated to Node.js, it makes more sense to remove them entirely.

[SachaG]

OK, I know it's not perfect, but overall I think I'm pretty happy with were we ended up: https://survey.devographics.com/survey/state-of-js/2022

Barring any last-minute changes, I think the survey is ready to launch next monday :) Thanks for all your feedback!

[SachaG]

The survey is officially open! Thanks all!