State of JS 2021 Outline Discussion

[SachaG]

(Outline WIP available here).

Deletions

The two big changes I'm planning are to remove the "JavaScript Flavors" and "Data Layer" sections.

JavaScript Flavors

TypeScript has almost 100x the usage of any other options, so setting aside a whole section for this category feels a bit superfluous at this point. Technologies like Reason or Elm are still very interesting but maybe they have their place in a more targeted survey?

Data Layer

This has always been a somewhat nebulous category, and would probably be better served by library-specific surveys (how to manage state in React, how to manage state in Svelte, etc.).

Features

• async_await
• promises
• destructuring
• spread_operator
• arrow_functions
• local_storage
• fetch

(These are removed because they're pretty much at 100% usage and/or awareness so it doesn't make a ton of sense to keep asking about them)

• decorators (not actually implemented yet so not the best section for them?)

Libraries

• koa
• meteor
• hapi

Other Deletions

• Text Editors

Additions

Since the deletions free up space, maybe we could add a new category such as Animations and Graphics? Or else just keep the survey shorter.

Features

• numeric_separators
• replace_all
• match_all
• logical_assignment
• promise_any
• array_at
• top_level_await
• page_visibility
• broadcast_channel
• geolocation
• file_system_access
• web_share

Libraries

• Solid
• Redwood
• Blitz
• Astro
• Eleventy
• Sveltekit
• Remix
• Vite
• WMR
• Turborepo
• Tauri
• pnpm
• Vitest

I also want to open the discussion regarding which features/browser APIs should be included.

[foolip]

For testing tools, it would be good to list Selenium, meaning https://www.npmjs.com/package/selenium-webdriver. https://www.npmjs.com/package/webdriverio is listed, but I don't think it's as widely used based on npm stats. (Suggested by @jgraham.)

[jgraham]

I think listing the Selenium WebDriver npm package is a good start, but I think the underlying question I have is what the testing questions are trying to address. As far as I can tell, the 2020 data only includes js-based testing tools. That makes sense if the idea is to find out about preferred choices for unit tests, since for unit tests the test and implementation language are almost always the same. However in that case it's unclear why Cypress / Puppeteer / Playwright / WebdriverIO are included, because they aren't used for unit testing. It also makes sense if the aim of the question is to find out how much people use/like various js-based libraries. However I don't know what the use case for that specific data would be.

If we want to know how people test their webapps in general we should probably include tools where the test authoring language isn't js. Selenium is the obvious example here, since there are various different language bindings, but there are others, like Rspec. At least for my use cases, having some sense of how much people use/like the full spectrum of end to end testing tools would provide much more actionable insights than just having data about the js-implemented subset. I understand that might seem strange for a survey specifically about js, but all languages exist in the context of the larger computing ecosystem, and I think it makes sense to ask about things that cross that boundary.

[SachaG]

I have to say I don't know enough about the testing ecosystem to have an informed opinion on that specific topic. Maybe let's see what others think?

[redbar0n]

JavaScript flavors:

I would argue that it is still interesting to know, for someone surveying what flavor to invest in. To see the various satisfaction ratings and that TS has 78% usage whereas the next contender Elm has 6 % usage isn't apparent from any other place. So the StateOfJS survey provides a good data point to orient oneself. It is also interesting to track the satisfaction, interest, usage and awareness of these flavors over time.

I would even add ReScript to the list, since it focuses on web, and split off from Reason (which focuses on native) at around Aug 2020.

Data Layer:

If you remove this category, where would you put XState for instance, then? A lot (most?) of state management solutions work cross-framework.

But from looking at the datalayer examples, I think this category should be split into:

• State management:
  • redux
  • xstate
  • mobx
  • (vuex)
• Client-server comm.:
  • REST:
  • tRPC
  • React Query
  • GraphQL:
  • apollo
  • urql
  • relay
  • swr
• Database:
  • Firebase

[SachaG]

We could put both Flavors and Data Layer libraries in the "other tools" section (basically just a have used/have not used checkbox), which doesn't give us the granular would use/not use again/interested/etc. data but does let us judge the relative popularity of different options in the same category?

[SachaG]

Currently working on the "JavaScript pain points" and "JavaScript missing features" questions, which need 8 items each. Would love some suggestions, here's what I have currently:

JS Pain points

• browser_interoperability
• animations (?)
• state_management
• form_handling (?)
• performance_issues (?)
• browser_apis (?)
• async_code
• managing_imports
• dates

Missing features

• static_typing
• standard_library
• pattern_matching
• pipe_operator
• decorators
• browser_support
• immutable_data_structures

[martinheidegger]

Some suggestions for topics of which I am not sure where to put them:

• Crypto API's (subtle): Node.js and the Browsers crypto API's are very close at this point. My personal question about this would be if people use this/perceive this as game changer/think its a good idea.
• Library Publishing: Do they publish libraries on NPM with ESM only, CJS only, Mixed. Compiled from TS, etc. Do they ship typescript declaration files?
• Library Consumption: Do people get stressed with ESM-only/CJS-only libraries on NPM?
• Security Considerations: On a surface level: Do people thing JS is secure? Their dependencies are Secure? etc.
• Corporate Products: Do other people perceive libraries (OSS) whether or not (big) companies are supporting them.

For the utilities: volta has been the biggest improvements for me this year, maybe worth adding?

[redbar0n]

JS pain points:

• Dependency discovery: Finding out which libraries/frameworks are compatible with other libraries/frameworks.
• Library documentation:
  • Finding out WHY one should or should not use a library is made hard due to poor description of purpose/rationale/problem.
  • Lacking comparisons with other libraries. Notable exceptions, best of class: React Query, URQL and Vite.
  • Bundle size: Finding out the typical bundle size impact for the client. Especially for those libraries not on Bundlephobia (esp. Deno libraries, which are not on NPM).

[bergus]

• pain points / state of the ecosystem: dependency hell
• missing from js, taken from the proposals list: temporal, iterator helpers, regexp.escape, records&tuples, disposables, structured cloning, object shorthands, cancellation, bigint math, observables, pattern matching, protocols
• awareness/usage of new 2022 features: static blocks in classes, error.cause, object.hasown, in operator for private fields, regex match indices
• opinions: js and browser engine diversity - no more chakra in ms edge?

[SachaG]

After some more thinking I think it makes sense to split out the "other tools" section in two categories: Tooling and Other Tools.

Tooling

Utilities

babel
prettier
eslint
nvm
n
nx
zx
volta

Runtimes/Execution Environments

browser_environment
node
deno
chakracore
hermes
service_workers
serverless_workers

Package Management

npm
pnpm
yarn

Package Registries

npm
github
jspm
private_registry

Monorepo Tools

rush
turborepo
yarn_workspaces
lerna
npm_workspaces
nx

Other Tools

Libraries

Flavors

Non-JS Languages

Browsers

Form Factors

Tool Evaluation Bracket

[SachaG]

OK, pretty happy with the latest outline. I'm still waiting for feedback from some folks but it's a good starting point at least!

[redbar0n]

Looks good! I would also put "State management" and "Client server comms." as headlines under "Other Tools".

[SachaG]

@redbar0n oh, what would you put in "Client server comms"? Things like Relay and Apollo? The reason I'm hesitant to add this (and state management as well) is because these libraries are so framework-dependent… in practice a lot of them are mostly used with React tbh.

[redbar0n]

yeah, those plus more. In my initial comment I outlined the ones you already have noted. But I know of plenty more, if need be. I would argue most of them are not actually framework dependent, even though many of them are used with React, since React has no scalable state management solution of its own. I see them used with Preact, Solid, Svelte, Vue, etc.

[SachaG]

Actually I will promote monorepo tools to a "full" category at the same level as build tools. They're pretty niche but it's a very dynamic category so I think it'll be worth fully tracking them sooner rather than later so have historical data.

[eric-burel]

It sounds rather good, I would add "yalc" alongside pnpm and stuff https://github.com/wclr/yalc, as a competitor to pnpm

I would maybe add a section about open source visual builders and maybe various headless tools:

• Plasmic https://www.plasmic.app/
• Maybe non open source stuffs like Amplify studio https://aws.amazon.com/fr/amplify/studio/
• There's a list of headless CMS here: https://jamstack.org/headless-cms/

Collaborative coding tools :

• Tiptap https://github.com/ueberdosis/tiptap
• StackBlitz
• Netlify and Vercel features for coding online

It would basically replace your Text editor section, with instead what tools people use to generate some code visually

Maybe what turn-key backend people use?

• Hasura
• Supabase
• Firebase

You may want to add Bedrock to librairies, it's not open source though

[snowystinger]

Adding to the headless tools React Aria https://react-spectrum.adobe.com/react-aria/index.html

I know up above you were saying that a few sections have been cut. Maybe there's space for a more nuanced section about accessibility? To name a few potential topics

• The accessibility tree hasn't been mentioned anywhere above, how many people know what it is and that you can inspect it in chrome/ff
• Focus Management
• Cross ScreenReader normalization
• Aria Roles
• Live Regions
• Landmark navigation

Thanks for opening this discussion :)

[SachaG]

@snowystinger a11y is super important but I have to confess I'm not sure how to approach it in this survey, since it covers a lot of tools where it's not really applicable (example: back-end frameworks, testing tools, etc.). So I think a11y questions are more at home in the State of CSS survey.

[SachaG]

OK, the survey is now live! https://stateofjs.com/

Thanks to everybody for your contributions!

[snowystinger]

Great news! Maybe in the next iteration we can figure out a11y questions. I hope you don't mind me following up here for now.

@SachaG I had that thought too, however, I've done enough work now (on React-Aria) to know there is a ton that you have to both do and know in javascript combined with HTML and CSS to make an accessible application. I think I see a gap between the State of CSS and State of JS, which is neither of them really include libraries such as React-Aria, MaterialUI, etc. Meanwhile, simply putting it into CSS does it a big disservice I believe. I think it has a place there as well, but it also has a place here.

I'm not sure why testing tools or back-end frameworks would negate its inclusion in this survey. Could you explain more?

Maybe it'd be better to sprinkle it throughout? I do like how it was included in the brackets for evaluation. And maybe that is enough. Though I think it'd be useful to know if people know about the accessibility tree which they manipulate by rendering and various accessibility patterns.

For instance, in questions about Browser API's, when setting aria-labelledby or aria-label or roles such as group, you can inspect the accessibility tree to see what an assistive technology such as VoiceOver on Mac will read. There's also LiveRegions, which you typically create with Javascript, and once they've finished announcing, you remove them. I think of them almost as indirect JS API's from the Browser.

Or there are a ton of patterns that people should follow when implementing various components. So when asking about frameworks, maybe also asking about design systems that help implement many of these. Here's a link to a bunch of the patterns https://www.w3.org/TR/wai-aria-practices-1.1/#grid

Do you coordinate with the State of CSS folks?

[SachaG]

I think I see a gap between the State of CSS and State of JS, which is neither of them really include libraries such as React-Aria, MaterialUI, etc. Meanwhile, simply putting it into CSS does it a big disservice I believe. I think it has a place there as well, but it also has a place here.

I agree, and I think a State of React (or Vue, or Svelte, etc.) survey could be a great way to fill that gap :)

I'm not sure why testing tools or back-end frameworks would negate its inclusion in this survey. Could you explain more?

I just meant that a chunk of respondents might not find that accessibility questions apply to them, or might not know how to answer them. I was worried it might make the data misleading (e.g. "50% of JS developers don't care about accessibility" when it turns out those 50% were all strictly back-end Node.js developers).

[snowystinger]

Ah, very fair reasoning. Thank you for taking the time to explain it.

[Felienne]

Hi @SachaG!

Sorry for the late reply. I was wondering whether we can include a question about the other (non-JS) languages that people are familiar with. In the committee, we sometimes struggle to predict whether concepts of syntax will feel weird to js developers and knowing what they in general know could be helpful!

[SachaG]

@Felienne sorry the survey is already finalized and open! But there is in fact a question about non-JS languages so don't worry :)

[shadowings-zy]

Hi @SachaG I notice that you remove koa from libraries, but npmtrends shows koa has more users than nestjs and fastify. https://www.npmtrends.com/express-vs-fastify-vs-koa-vs-@nestjs/core

So I wonder why koa was removed from the investigation？

[SachaG]

I looked at other metrics like recent commits, github stars added by month, etc. and it seemed like Koa didn't have the same kind of momentum. And it's also an older framework, so I thought it was better to leave room for new entrants like Remix, Blitz, etc. even if they're way smaller in terms of userbase.