State of JS 2023 Feedback about surveys HOT 17 OPEN

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.

from surveys.

I care a lot:

• Smaller ranges in "yearly income."
• Work modality (fully remote, hybrid, in-person).

I care a little:

• Weekly time spent in meetings/standups.
• Location of the company
• vacation days per year
• I would eliminate all the questions of "How happy are you with..." or "Overall Happiness" (personally I can't make sense of it)
• Instead of removing Rome, I would replace it with "Biome (formerly Rome)".
• Observability and session replay tools (Highlight.io, Logrocket, Sentry, Datadog, etc).
• Analytics tools (Matomo, Plausible, Umami, PostHog, GA4, etc.).
• Payment tools (Stripe, Paddle, etc.).
• Marketing platforms tools (Mautic, Mailchimp, etc.).

I do not care much:

• Testing section: the built-in test runners in runtimes (node, deno, bun) seem more relevant to me than some of the options that appear there.
• Other tools section: UI libraries would be interesting (especially the headless ones). I wouldn't mind if "AI tools" were removed.
• Usage section: I wouldn't mind if "application patterns" were removed.
• Resources section: I wouldn't mind if First Learning Methods, Blogs and Magazines, and Sites & Courses were removed.
• Section about you: I wouldn't mind if "Race and Ethnicity" were removed.

Thank you for the incredible work you do!

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

from surveys.

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

from surveys.

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

from surveys.

Current changes under consideration so far:

Added

Features

• hashbang_grammar
• array_to_sorted
• array_to_reversed
• array_with
• array_to_spliced

Libraries

• htmx
• SolidStart
• Fresh
• bun (as a build tool)
• tsup

Other Questions

• AI Tools

Removed

Features

• dynamic import
• proxies
• numeric separators

Libraries

• Ember
• Gulp
• Browserify
• Snowpack
• Rome
• WMR

Other Questions

• Date management libraries (merged into "Other Libraries")
• Data fetching libraries (also covered in State of React)
• Utilities (nvm, n, etc. – not much movement in this category)
• Data visualization libraries (probably too niche? most people don't use them)

from surveys.

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

from surveys.

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

Just want to understand the rationale, thank you.

from surveys.

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

from surveys.

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!

from surveys.

Past suggestions: #65

from surveys.

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

• Squash Promise.allSettled and Promise.any like it's done for arrays and string, it's clearer
• Remove Logical Assignment
• Add Array.flat()

Frontend tools

• Remove Preact

Metaframeworks

• "Fresh" clarify it's Deno Fresh

Testing

• Add MSW Mock Service Worker, it has a new version out

Mobile & Desktop

• Add Vercel "pkg"

Build tools

• Remove bun, it's considered a runtime rather than a build tool

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

from surveys.

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

from surveys.

from surveys.

It would be great to have some questions around performance:

• Do you struggle to obtain good LCP scores for page load on your websites?
• If so, is it due to the size of your JavaScript? How well do existing bundlers, minimizers and other tools help?
• Do your existing framework and build tools impact your ability to achieve faster page loads? (Negative impact? Positive impact?)
• How important is it to you to reduce the cost of loading JavaScript vs other improvements such as language features?

And reliability:

• How hard is it for you to write reliable and resilient JavaScript for your website?
• Do your existing framework and build tools impact reliability and resilience? (Negative impact? Positive impact?)
• What new capabilities might help with this?

from surveys.

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

from surveys.

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!

from surveys.

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?

from surveys.