State of JS 2020 Questions

[SachaG]

Leave your feedback on the draft of the State of JavaScript 2020 survey questions here.

[SachaG]

Here's the first draft of the outline, currently it's basically just a copy of last year's outline:

https://github.com/StateOfJS/StateOfJS-Vulcan/blob/master/packages/stateofjs/lib/surveys/yml/js2020outline.yml

Do let me know what to add/remove this year!

The main issue from last year was what to do about Angular vs Angular.js. The three options are basically:

1. Keep only Angular (what we did in 2018, 2019) -> not good, because the poor developer experience of Angular.js dragging down the much improved Angular.
2. Keep both Angular.js and Angular (what we did in 2016, 2017) -> the downside here is that it clutters up the survey with an old framework (Angular.js) that isn't really relevant to modern web development anymore
3. Keep only Angular but mention that this doesn't include Angular.js -> could work in theory but might be confusing for respondents?

So it's basically between options 2 and 3.

[SachaG]

Other thoughts:

• Add a new Graphics & Animation section for things like D3, three.js, etc.?
• Should Build Tools have their own full section?
• Add a new Utilities category to "other tools" for things like Prettier, ESLint, etc.?
• Where does Deno fit in?

[lacolaco]

Here's the first draft of the outline, currently it's basically just a copy of last year's outline:

https://github.com/StateOfJS/StateOfJS-Vulcan/blob/master/packages/stateofjs/lib/surveys/yml/js2020outline.yml

Do let me know what to add/remove this year!

The main issue from last year was what to do about Angular vs Angular.js. The three options are basically:

1. Keep only Angular (what we did in 2018, 2019) -> not good, because the poor developer experience of Angular.js dragging down the much improved Angular.
2. Keep both Angular.js and Angular (what we did in 2016, 2017) -> the downside here is that it clutters up the survey with an old framework (Angular.js) that isn't really relevant to modern web development anymore
3. Keep only Angular but mention that this doesn't include Angular.js -> could work in theory but might be confusing for respondents?

So it's basically between options 2 and 3.

Thank you for considering this. As you mentioned at (2), I think AngularJS is worthless to survey. I basically agree on 3. If a respondent has some experiences or any interest with Angular, it means maybe they knows about Angular. So simply Angular (except AngularJS) may work. If not, so they don't care about Angular's difference. So it also may work.

[BBlackwo]

I think option 3 should clear things up somewhat. But then the question is how to phrase it to be clearest. I'd suggest saying something like Angular (excluding Angular.js 1.x) as that clearly shows it's referring to Angular (Angular 2+). Most people probably don't realise the naming distinction between Angular and Angular.js, but they might know the difference between v1.x and v2+. 🤷‍♂️

[web-padawan]

1. Please consider renaming "Web Components" to use actual APIs by changing these lines to the following ones:

- title: Custom Elements
  id: custom_elements
- title: Shadow DOM
  id: shadow_dom

2. Also, I would suggest to use Intl instead of i18n. I'm wondering whether further split would help even more, as Intl contains several features with different levels of browser support and some developers might only use few of them.

[Aprillion]

datalayer - I think the answers might include "no additional data layer", "react-query", "firebase", "localStorage" ... or maybe split into 2 questions for client state vs access to server data?

sites_courses - not sure whether to include "epicreact.dev" right away or wait whether it pops up from "other"

[smeijer]

In addition to years of experience: How long you've been writing JavaScript. I would also like to know how long they have been in the development profession.

In 2019 there was a css section, and 40% of javascript developers say they have reached the "expert level of css proficiency".

I'm curious if they got this skills while they were writing javascript, or if they did some other development work prior that. Maybe pure html+css?

So we could add

- how long have you been writing css
- how long have you been writing react
- how long have you been writing...

Or simply

- how long have you been a developer

[smeijer]

Also, in addition to years of experience I would value a professional title / role chart. It would be interesting to see how many % of developers are classified as junior | intermediate | senior | architect | ... compared to years of experience.

[aholtzman]

Also, in addition to years of experience I would value a professional title / role chart. It would be interesting to see how many % of developers are classified as junior | intermediate | senior | architect | ... compared to years of experience.

Expanding on this it would be interesting to learn what level developers considered themselves at vs their title/role (what disparity exists in perceived skill level from level of present job)

[LarsDenBakker]

I'm missing lit-html or lit-element in this list. NPM downloads are only a very rough metric, but has more downloads than some of the listed frameworks/libraries: https://www.npmtrends.com/lit-element-vs-svelte-vs-lit-html-vs-alpinejs-vs-ember-source

[yhnavein]

Here's the first draft of the outline, currently it's basically just a copy of last year's outline: https://github.com/StateOfJS/StateOfJS-Vulcan/blob/master/packages/stateofjs/lib/surveys/yml/js2020outline.yml Do let me know what to add/remove this year! The main issue from last year was what to do about Angular vs Angular.js. The three options are basically:

1. Keep only Angular (what we did in 2018, 2019) -> not good, because the poor developer experience of Angular.js dragging down the much improved Angular.
2. Keep both Angular.js and Angular (what we did in 2016, 2017) -> the downside here is that it clutters up the survey with an old framework (Angular.js) that isn't really relevant to modern web development anymore
3. Keep only Angular but mention that this doesn't include Angular.js -> could work in theory but might be confusing for respondents?

So it's basically between options 2 and 3.

Thank you for considering this. As you mentioned at (2), I think AngularJS is worthless to survey. I basically agree on 3. If a respondent has some experiences or any interest with Angular, it means maybe they knows about Angular. So simply Angular (except AngularJS) may work. If not, so they don't care about Angular's difference. So it also may work.

I don't agree that AngularJS is worthless for the survey. It will obsolete soon - yes. But there is still a ton of active development going on in many companies. And it's not gonna disappear right now. Including AngularJS as a separate option to Angular will help us understand globally how developers see those 2 different frameworks. And it will not affect even minimally the new Angular results.

For example in previous survey I was really concerned about Angular option, because on the one hand - I really liked AngularJS, but I totally hate new Angular. On the other hand removing AngularJS totally just ignores potentially a big amount of AngularJS developers from sharing their view about their framework.

[NullVoxPopuli]

I think that time since last using a framework should be tracked and weighted. Like, if a library or Framework had a rough start, but has improved a ton, no one will know from this survey, because this metric isn't considered.

For example, if a whole group of people had a bad experience with AngularJS, and AngularJS wasn't renamed to Angular, but people jumped ship to React back in 2014 or 2015, the stats collected would not show that picture. Like, as the number of survey participants grows, even if the number of people using the latest AngularJS is increasing, we'd have no way of knowing. Additionally, we'd have no way of knowing that everyone who has bad things to say about AngularJS hasn't used it in 5-6 years (making their opinions much less relevant)

[Aprillion]

For example, if a whole group of people had a bad experience with AngularJS, and AngularJS wasn't renamed to Angular, but people jumped ship to React back in 2014 or 2015, the stats collected would not show that picture.

I am not sure that picture could be captured with any survey design. Also, Angular was retro-named to AngularJS, then a completely different framework was presented under the original name - that was entirely doing of the framework maintainers, I don't blame the survey authors for any past confusion with regards to multiple frameworks by the same team being called the same name... I am happy that they want to avoid the confusion this year 👍

I agree we can put both "AngularJS 1.0" and "Angular" as separate frameworks this year and find out whether one of them is more loved...

TBH: I used Angular 1.0 before it was called AngularJS and while it was state of the art technology, and I had mixed feelings at the time and "I would not use it again". I tried Angular 2 and 4 at the time and I hated it immediately so "I would not use it again". So I would love to see the opinion of other developers how big is the difference between old and new Angular.

[NullVoxPopuli]

But to be fair to all frameworks, I think version numbers should be included.

So, for Ember's that'd be, 0.x, 1.x, 2.x, 3.x, Octane

For React, 0.x, 15.x, 16.x, 17.x

Etc

If versions are included, then there may not need to be a differentiation between AngularJS and Angular

[NullVoxPopuli]

Also, interest in a particular framework or library should never solely be a percentage of all participants.

The growth or interest should be compared with the name framework from the previous year.

For example, if you quadruple react participants, but only double svelte, as a percentage of the whole, it looks like svelte is in decline.

[jadonn]

What about a separate call out for Angular.js in relation to the EOL? There are major projects and companies out there that have to make this transition. It would be interesting to see data about how teams will respond to this change. Some applications like this are cPanel, the popular web hosting control panel; Horizon, the web interface for open source private cloud software OpenStack; some portions of IBM's cloud web UI I believe; and some less known Google tools and pages.

The idea I have in mind is to not include Angular.js in the main framework section and give it a separate question or section that asks people who are currently developing or supporting Angular.js applications about perhaps which framework they plan to use next or how ready they are for the EOL.

But I recognize this doesn't apply to all or possibly even a large enough subset of JavaScript developers to warrant inclusion in the survey.

[NullVoxPopuli]

Oh also, for the "heard of it, not interested" measurement, I don't think that provides much value, for the same reasons I've outlined above.

Did most of those participants only use 1.x, pre v1, etc? The experience and age of that experience must be considered

[justinfagnani]

@LarsDenBakker I know npm downloads are imperfect as a stat, but I didn't realize that lit-html has 10x the downloads as AlpineJS. That's pretty significant. @SachaG what are the criteria for inclusion there?

[VickiLanger]

The job title question is really lacking. There are tons of other jobs that do not fall in the cto, developer, and designer categories. If this survey is for all JS users, the results of this question are not likely to be accurate.

Originally posted in https://github.com/StateOfJS/StateOfJS-Vulcan/issues/70#issue-730777402

[justinfagnani]

Given that the shift towards standard JS modules is one of the biggest things underway in the ecosystem I think it would be very enlightening to ask questions about modules and packaging, at least for the open source community.

For modules, things like:

1. are you using module syntax
2. are you using the native module loader
3. if you compile modules away, to what format?
4. are you using dynamic import (already covered, could be moved)
5. are you using bare module specifiers
6. are you using import.meta.url?

Non-standard module types. Are you importing:

1. CSS
2. JSON
3. HTML
4. Images
5. Text
6. WASM
7. Other...

For packaging:

1. are you publishing modules to a registry? (presumably npm)
2. are you using package exports?
3. are you using the "type" field in package.json?
4. Do you publish JS modules and CommonJS?

CDNs - do you use a modern module-supporting CDN like unpkg.com, SnowPack or jspn?

[NullVoxPopuli]

Framework users may not know the answers to some of those. 🤔

[SachaG]

@justinfagnani those would be great to know about, but I think that might be going a bit too much into detail for us… And some of them can probably be answered better by doing some analysis of NPM packages.

But maybe a question about "have you ever published an NPM package?" could be interesting?

[SachaG]

Oh also there is no strict criteria for inclusion in the survey for libraries or frameworks, it's a mix of:

• What got the most write-in votes in past surveys.
• What's popular on http://bestofjs.org/ (which counts GitHub stars).
• Trying to identify upcoming trends so we have historical data if library X does end up blowing up.

In previous years people were filling out the entire survey in one go and we had big performance issues once we got past ~100 questions, but now that we have our own platform which saves the survey section by section we can be a bit more liberal with making the survey (even) longer I think, so I'm not against adding more options.

Within reason of course, ~10 options per section is probably as high as we should go if only to keep the survey results readable.

But at this stage of the process I welcome any suggestions, we can always pare down the lists later on.

[lindsaykwardell]

Would it be possible to include the Ladybug Podcast? I don't know your criteria for including a podcast as one of the default options, but I feel like it's been around for a few years at this point and has a good following on social media.

[SachaG]

@lindsaykwardell in this case the main criteria would probably be freeform answers from past years, and since the Ladybug Podcast came in third (https://2019.stateofjs.com/resources/#podcasts_others) we can definitely include it :)

[lindsaykwardell]

Awesome! Is there anything I can do to contribute in order to add it beyond adding to the .yaml file?

[SachaG]

@lindsaykwardell you could check that the info in this file (which we use to get metadata about the items that appear in the survey) is correct, and then add the same id to the survey's YAML file.

[lindsaykwardell]

Got it, thanks! I believe I have the PR created for your review:

https://github.com/StateOfJS/StateOfJS-Vulcan/pull/71

[SachaG]

@lindsaykwardell Also I really wanted to say thanks for actually taking the time to make a proactive move to improve things, instead of just complaining on Twitter :)

[justinfagnani]

@SachaG

But at this stage of the process I welcome any suggestions

Do want PRs like Lindsay's at this point, or wait and collect ideas here for a while. Don't want to flood you :)

but I think that might be going a bit too much into detail for us

Yeah, that sounds reasonable. I do think it'd be great to gauge module usage in some way though, since many of us library and tool authors are putting a lot of working into supporting and migrating to them. Something to track over the years would be very nice. Maybe even a simple "are you publishing modules to production?" would be good?

[SachaG]

For now I think it's better to collect ideas here so others can give feedback too.

Maybe even a simple "are you publishing modules to production?" would be good?

I'm just worried that the phrasing might be too ambiguous. Can we find a way to ask about modules that fits in our features template (never heard/heard about/ have used) and also is clear enough that everybody will know what we're asking about?

[justinfagnani]

It is tricky. I think a lot of people are writing module source, and far, far fewer are compiling to / publishing module. How to ask that so the signals aren't crossed is tough I suspect.

[SachaG]

@smeijer I think that question will become more general ("how long have you been a developer") so that we don't need to re-translate it for every survey.

[davidkpiano]

Any consideration for adding XState for the datalayer section?

XState is trending pretty evenly with MobX and Relay, and isn't far behind Apollo, and accounted for 3.5% of the write-ins last year. It also had the most GitHub stars per day (average) for the last year.

If not, that's okay! Just something to consider. (To not be biased, I'd also ask for RxJS to be added).

[SachaG]

@davidkpiano yeah we can add it. Currently I have rxjs in the "libraries" part of our "other tools" section where people just check the ones they use. Do you think it should be moved to the State Management section and be given a full entry? I'm not familiar enough with it to know if it's a real state management solution or more of a drop-in library?

[davidkpiano]

I'm not familiar enough with it to know if it's a real state management solution or more of a drop-in library?

It's more of a drop-in library (self-described as "lodash for observables") that can be used together with other libraries, such as redux-observable and NgRx.

I'm assuming the data layer section is meant for framework-agnostic state management libraries, right?

[SachaG]

I'm assuming the data layer section is meant for framework-agnostic state management libraries, right?

Ideally yes, all sections should be framework-agnostic. But in practice it would mean leaving things like Gatsby and Next out of the survey altogether so we sometimes have to compromise. Or to take another example, I think Redux can be used with non-React framework for example, but in practice it's pretty much a React library as far as I know. Yet we don't want to leave it out either.

[SachaG]

By the way I thought I'd mention it here, but if you have a little bit of extra time and some knowledge of GitHub actions (or are curious to explore the topic) I would love some help setting up a better translation workflow.

[morgangraphics]

Backend tools is missing Hapijs (more to this point, I'd be curious as to what Node based server people are putting in production)

BuildTools is missing Babel

Data layer is missing Vuex (the main state machine for Vue)

If possible I'd like some sort of breakdown of peoples roles, something like:

Full Stack Developer 25% Frontend 20% Testing 40% API development 15% Devops/Security

Job titles might also include (or variations of) architect principal/team lead

Lastly with regards to proficiency, proficiency is purely subjective and I'm not completely convinced that is very helpful in terms of metrics. I come across a lot of resumes that state someone with "senior" levels of experience but only 4 years in the industry and not what I would quantify as doing any "advanced" work. Is there a way to categorize/quantify proficiency with concepts? What is an advanced concept? Architecture? Buffers? Steaming? Security?

[hellatan]

I was going to mention hapijs as well but @morgangraphics beat me to it. I also did not notice babel was missing! I always call visual studio vs code instead and most of the people in my org refer to it as that as well. Microsoft's github for it is vscode fwiw.

I think one thing that would be interesting to see is how people got into JS. My main interest is seeing how many people went through bootcamps and use JS in their current position since bootcamps seem to be a big thing the past few years and I've worked with a good amount of people at this point that have gone that route. I'm not sure how that could be quantified but I guess that would be something that could go under "user info". Maybe some options could be like "bootcamp", "self-taught", "college/university", "learned on the job".

A few more thoughts:

• Should react be under "front end frameworks"? Wouldn't it technically be under "libraries"?
• Is adding URLSearchParams too narrow for a browser api? Though it is also in node so I'm not sure how you'd categorize it.
• Stack Overflow also has a podcast and newsletter
• What about adding webdriver.io` to "testing"?
• yarn vs npm vs ...?
• monorepo vs multiple repos?
• There has to be some pandemic-related question in here somewhere...😅

Blogs/news (well these are more newsletters):

• TypeScript Weekly
• Frontend Weekly
• ES.next News
• Dev Awesome

[cooskun]

Maybe having a new category like developer-friendly products/services? Stripe could be a good example.

[SachaG]

Thanks everybody for the great feedback! I just wanted to mention that if you want direct access to us to ask questions or anything, you can also join this Discord group I just created: https://discord.gg/pRFeZVu

[umairhm]

Does it make sense to have a section for Headless CMS's like Contentful or Strapi? Thanks to Jamstack team to list a pretty long list here that can be used to pick the top choices maybe: https://jamstack.org/headless-cms/

[dromanov-jb]

Hey guys! I have a suggestion to add Kotlin to the list of programming languages (other tools - non_js_languages).

[robpalme]

@SachaG the Discord link is not working.

[SachaG]

Sorry, I didn't know invite links expired. Here's a new one: https://discord.gg/zRDb35jfrt

[robpalme]

Maybe even a simple "are you publishing modules to production?" would be good?

I'm just worried that the phrasing might be too ambiguous.

How about a multi-checkbox question.

What kind of code are you running in production?

Explainer: This is not asking about your source code. It asks what your app is executing after you have published it to production.

• [ ] Raw scripts
• [ ] Bundled scripts (your scripts & modules are aggregated by a build tool into script output)
• [ ] CommonJS modules (your executable code contains require)
• [ ] ES modules (your executable code contains import and export)

[mlynch]

Hope you'll consider adding Capacitor to the mobile_desktop section. It's a replacement for Cordova that was built by the Ionic team and has been growing quickly of late: https://npmcharts.com/compare/@capacitor/core

All new Ionic apps use Capacitor by default instead of Cordova.

[SachaG]

@mlynch thanks for the suggestion!

[SachaG]

We're also thinking of adding a list of software industry sectors. Here's what I came up with, anything I missed?

(I guess "SaaS" could apply to any of the other categories so I'll take it out, it's not really the same thing)