-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State of JS 2023 Feedback #224
Comments
Past suggestions: #65 |
Current changes under consideration so far: AddedFeatures
Libraries
Other Questions
RemovedFeatures
Libraries
Other Questions
|
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”. |
Here's mine: FeaturesThey 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-JSGo missing a translation string "options.non_js_languages.go" AIYou can add Vercel V0 already I think Application PatternsI 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 ResourcesI 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. PeopleAre 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 SurveysI don't know if Postman API survey is that known eg against Netlify dev survey or more specialized 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... |
Quick question, why is Backend Frameworks listed under Other but Frontend Frameworks is its own section? Just want to understand the rationale, thank you. |
@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. |
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
<#224 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3KWOGMP7ATM2MQXOHNSR3YEIHHVAVCNFSM6AAAAAA6W6YHCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGA3TONJXGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
It would be great to have some questions around performance:
And reliability:
|
@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. |
Thinking about removing AVA and Jasmine from the testing section, and adding Mock Service Worker instead. |
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. |
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. |
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 |
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? |
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! |
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
The text was updated successfully, but these errors were encountered: