Open SachaG opened 1 year ago
I like tRPC, but I wouldn't call it a backend framework, I'd describe it as an API layer. And Blitz is closer to being a backend framework than anything else (it's partly an API layer like tRPC, but does quite a number of backend things too)
@AndrewIngram yeah I wasn't sure about tRPC, good call. And I'll move Blitz to the back-end section then.
I don't know if my previous comment was clear, but I think the wording here will confused people:
Static Typing: Native types (similar to what TypeScript offers).
There's a types-as-comments/annotations proposal created recently called Type Annotations. This proposal is not native types and someone that supported it might think that's what the option above implies. (Or if they did understand the proposal they'd be confused why there isn't an option for it). While the proposal does pull syntax from TypeScript, it specifically does not implement native types or a runtime checker. Using "TypeScript" syntax doesn't define the type of Static Typing as native types vs types annotations which can use very similar syntax, but they'd produce very different results and language features.
Phrasing Static Typing without specifying the goals was an issue with the 2021 survey as it wasn't clear what opinion is being tallied.
I think the most explicit wording would be:
Static Typing: Type Annotations/Types as Comments
Static Typing: Runtime/Native Types
For the latter if you need an example proposal I have one. Like the Type Annotation proposal it's a WIP, but it shows the various differences in language features. (If you need a small explanatory paragraph comparing both I could write one).
Quick thoughts:
questions_outline.yml
. Also, most folks still probably know it as "React Query".
Phrasing Static Typing without specifying the goals was an issue with the 2021 survey as it wasn't clear what opinion is being tallied.
@sirisan I see your point, but I'm not sure survey respondents would understand the difference? Maybe it's a bit too in the weeds for the survey?
@markerikson good point, I mostly added projects that got popular this year but we can definitely narrow it down a bit more.
Regarding TurboPack, on one hand I agree with you but on the other hand if we do think it might play a big role in the ecosystem in the next few years, it might be good to have historical data starting this year just so we can track its evolution from the start?
Hello can we add Sails.js for backend?
@DominusKelvin Sails hasn't shown a lot of momentum lately, projects that are in that category tend not to be included.
@DominusKelvin Sails hasn't shown a lot of momentum lately, projects that are in that category tend not to be included.
Got you.
@SachaG I'd recommend removing it then completely as any conclusion drawn from it will confuse people more (or be used to draw flawed conclusions about the direction of JS). I've had people on both sides of the discussion talk to me thinking it means people support my proposal for native types and I've had to explain that might not be the case due to the vagueness. The current types annotation goes so far as to use this survey as proof that people want types as comments and not native types which shows just how confusing it is when worded incorrectly.
@sirisian What if I change it to
Static Typing: Native runtime typing; or TypeScript-style type-as-comments
This way people who don't know the difference but just want some kind of typing can still pick it, and people who do understand the difference won't think the survey is leaning in one direction or another?
Basically I totally understand the issue, I'm just afraid if we offer people a choice they won't understand the distinction, and it will make the results less reliable.
Actually, after some thoughts I've decided to move back-end and full-stack frameworks to the "other tools" section. I feel like these frameworks have always stuck out a bit among the other items in the survey, since so much of it is focused on the front-end. So it might be best to embrace that instead of doing a poor job trying to accommodate too many different concerns.
I really like the way you splited Back-end Frameworks
and Rendering Frameworks
. In my opinion, you can keep it like that instead of moving them to "other tools".
@RomainLanz I don't want the survey to be too long though, I'd rather think about a separate "State of Node" survey down the road that can properly focus on back-end frameworks.
Yes, if you plan to create another survey dedicated to Node.js, it makes more sense to remove them entirely.
OK, I know it's not perfect, but overall I think I'm pretty happy with were we ended up: https://survey.devographics.com/survey/state-of-js/2022
Barring any last-minute changes, I think the survey is ready to launch next monday :) Thanks for all your feedback!
The survey is officially open! Thanks all!
Live Survey Preview
https://survey.devographics.com/survey/state-of-js/2022
GitHub Project
You can track the state of the survey contents here:
https://github.com/orgs/Devographics/projects/2/views/1
Details
Note: everything is still temporary, additions and removals can still be walked back before outline is finalized.
Features
Added
Removed
Libraries
Added
Removed
New Category: Rendering Frameworks
Back-end Frameworks
Added
Testing
Added
Build Tools
Added
Mobile/Desktop Apps
Added
Other Tools
Added
New Question: Back-end as a Service
See https://github.com/Devographics/surveys/issues/58
New Question: Edge Runtimes
See https://github.com/Devographics/surveys/issues/59
New Question: JS App Patterns
See https://github.com/Devographics/surveys/issues/56
New Question: Video Creators
See https://github.com/Devographics/surveys/issues/53