StateOfJS-2020

StateOfJS-2020 copied to clipboard

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

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.

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?

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 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+. 🤷‍♂️

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.

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"

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

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.

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)

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

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.

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)

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.

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

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.

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.

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

@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?

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

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?

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

@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?

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.

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.

@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 :)

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

@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.

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

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

@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 :)

@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?