Devographics / surveys

YAML config files for the Devographics surveys
40 stars 8 forks source link

State of JS 2023 Feedback #224

Open SachaG opened 8 months ago

SachaG commented 8 months ago

Here is a preview version of the 2023 State of JS survey:

https://survey.devographics.com/en-US/survey/state-of-js/2023

The feedback period will last from now until around November 15th, after which the survey will be published.

Questions

SachaG commented 8 months ago

Past suggestions: https://github.com/Devographics/surveys/issues/65

SachaG commented 8 months ago

Current changes under consideration so far:

Added

Features

Libraries

Other Questions

Removed

Features

Libraries

Other Questions

GermanJablo commented 8 months ago

I care a lot:

I care a little:

I do not care much:

Thank you for the incredible work you do!

EDIT: marked suggestions implemented, moved “work modality” from “care a little” to “care a lot”.

eric-burel commented 8 months ago

Here's mine:

Features

They definitely deserve a small description if possible

I would keep "dynamic import" around, related to the introduction of React.lazy namely, it's still confusing for JS devs

In observability add chrome record feature, and replay browsers

Frontend tools

Metaframeworks

Testing

Mobile & Desktop

Build tools

Non-JS

Go missing a translation string "options.non_js_languages.go"

AI

You can add Vercel V0 already I think

Application Patterns

I would clarify "Build-time Static Site Generation" and "Request-time Server-Side Rendering". You know how much I dislike "SSG" and "SSR" ':), Next is moving to a slightly clearer "static"/"dynamic" wording but the only explicit terminology is "build-time" vs "request-time" rendering.

Next 14 brings "Partial Prerendering" which is a pattern on its own: you have "islands" of dynamic server-side rendered components, within static server-side rendered pages. Perhaps it could be merged with "Streaming SSR", because streaming is what makes it possible. Previously this could be done only with static + client-side rendering (= Island Architecture).

Incremental Static Generation => it's now called "Revalidation" in Next, we should put the word "revalidation" somewhere either in the title or description.

Edge Rendering => I think it should be "Edge personalization", which englobes edge alteration of the rendered content and edge redirections towards the right content via URL rewrite. All the more that we use it in the survey to implement i18n :)

 Pains

"usage.top_js_pain_points.question" => missing i18n

I think "managing multiple environments" is a recurring painpoint when you have client/server hybridation, eg people will try to use the "window" object in a React client component, or have trouble with Edge runtimes and Node (conflating Next API routes and Next Route Handlers, importing code in middlewares etc.) etc.

"usage.top_currently_missing_from_js.question" => missing i18n

Resources

I would add Newline.co (previously fullstack.io) to the course list. Disclaimer: I write a course for them so I am 100% biased and they published Amelia Wattenberger book (who designed our awesome tech popularity chart). But I think they publish authors famous enough to be in the list.

People

Are we sure about diversity here? We could ask in advance who people want to see in case we discover other people with huge follower bases

Surveys

I don't know if Postman API survey is that known eg against Netlify dev survey or more specialized surveys

charlesdeb commented 8 months ago

I only looked briefly at the survey, but didn't see any mention of the JS tools that Rails brings to the party (turbo, stimulus, hotwire etc). They are (I suspect) mostly used in just the Rails world, but they can be used in non-Rails projects too. But maybe they are too small in adoption to include...

tayambamwanza commented 8 months ago

Quick question, why is Backend Frameworks listed under Other but Frontend Frameworks is its own section?

Just want to understand the rationale, thank you.

SachaG commented 8 months ago

@tayambamwanza the reason why the State of JS survey doesn't focus on back-end frameworks as much compared to front-end frameworks is that they tend to have far fewer users than front-end frameworks, since they have to contend with non-JS alternatives (Laravel, Rails, etc.); and also the fact that writing your back-end from scratch is probably more common than writing a front-end without using a framework.

tayambamwanza commented 8 months ago

Thank you :)

On Mon, 13 Nov 2023, 14:30 Sacha Greif, @.***> wrote:

@tayambamwanza https://github.com/tayambamwanza the reason why the State of JS survey doesn't focus on back-end frameworks as much compared to front-end frameworks is that they tend to have far fewer users than front-end frameworks, since they have to contend with non-JS alternatives (Laravel, Rails, etc.); and also the fact that writing your back-end from scratch is probably more common than writing a front-end without using a framework.

— Reply to this email directly, view it on GitHub https://github.com/Devographics/surveys/issues/224#issuecomment-1808077573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3KWOGMP7ATM2MQXOHNSR3YEIHHVAVCNFSM6AAAAAA6W6YHCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGA3TONJXGM . You are receiving this because you were mentioned.Message ID: @.***>

chrishtr commented 7 months ago

It would be great to have some questions around performance:

And reliability:

zloirock commented 7 months ago

I'm just curious why here missed core-js that's used in half of popular websites, including State of JS by itself -)

image

SachaG commented 7 months ago

@zloirock good question! Sometimes items might be widely used, but not mentioned much by survey respondents.

In the case of core-js I feel like maybe the reason is that it's something that people use through other libraries without being aware of it directly?

UPDATE: added for the 2023 edition.

SachaG commented 7 months ago

Thinking about removing AVA and Jasmine from the testing section, and adding Mock Service Worker instead.

deriegle commented 7 months ago

@tayambamwanza the reason why the State of JS survey doesn't focus on back-end frameworks as much compared to front-end frameworks is that they tend to have far fewer users than front-end frameworks, since they have to contend with non-JS alternatives (Laravel, Rails, etc.); and also the fact that writing your back-end from scratch is probably more common than writing a front-end without using a framework.

This reads to me like a lot of assumptions being made. To me, the whole point of a “state of JS” survey is to get a real life view into the world of JavaScript and how it’s being used. It should use real data from real users to give us insights.

To say “probably more common”, just tells me that we don’t know and we assume.

I have been doing only JS-based backend work for the last several years and know many others like me.

The ease-of-use and familiarity are making it a good choice. I’d have to make an assumption, but most JS frontend work includes installing node. We see teams like Deno and Bun making big improvements in this space.

If the “State of JS” survey is only giving a “State of Frontend Frameworks” that’s fine, but I think a name change would be appropriate.

shadow-identity commented 3 months ago

My feedback could be to release results of State of JS / HTML 2023 in the same year, maximum at the beginning of 2024. In contrast with situation where there is Q1 of 2024 is almost finished, but there is no results of surveys from the previous year.

eric-burel commented 3 months ago

Well, it turns out that my clients also want their tax report during the same fiscal year they must provide said reports, so we do our best as a very small team balancing everything We are 100% open to contributors though!

shadow-identity commented 3 months ago

The great amount of work on this poll was done by you and others, and the poll was super popular among developers. Maybe if there is a call for help on the survey page or in social media, others can help? So it could really help in case of any occasion with your high load or any other reason. What could be done by the community to publish the results?

SachaG commented 3 months ago

The issue is that the project is complex enough that you can't just drop in and "help out", any contributor would need to be onboarded for a couple days, which 1) would take up time we could use to advance the project and 2) most people don't have the free time to go through anyway.

That being said we do have a discord you can join if you do want to help!