Ah, it's that time of the year again – always enjoy seeing where the JS ecosystem is moving.
I would like to see two categories added for next year's survey:
1. Auth – would be interested to see if Passport is still the tool of choice
2. ORM – curious how Sequelize, Knex/Bookshelf, Objection, etc. compare in usage.
I understand this survey will obviously skew towards frontend tools, but some of the categorization just feels off to me:
For example, I wouldn't consider Next.js a backend framework. Sure, it's a server-side-rendering framework, but you wouldn't typically be using it for traditional backend things like accessing a database. Perhaps consider adding a SSR sub-section on frontend frameworks.
The data layer section seems a bit confused – it's mix between client-side stores and server-side persistence which have very different use cases. I'd probably move out the databases into their own category - would be interesting to see which JS devs prefer (eg. Postgres, MySQL, Mongo).
And trying to draw conclusions from the testing category seems odd when both frontend- and backend-specific tools are bunched together.
1. working on some of that now, going to hand-roll multi auth combined with password logins. I don't want to outsource my actual users' authentication beyond oauth to FB/Twitter etc.
2. I don't. If it's SQL, I use a tagged template string library, and just project from the response of the given library. If it's mono or similar, I don't see the point so much. I understand you can use type checking, but you can still do that at the API layer.
As to the data layer, I agree... client side libraries and abstractions should be different from server-side tech... though there's some overlap (libraries that sync client-server for you).
I would like to see two categories added for next year's survey:
1. Auth – would be interested to see if Passport is still the tool of choice
2. ORM – curious how Sequelize, Knex/Bookshelf, Objection, etc. compare in usage.
I understand this survey will obviously skew towards frontend tools, but some of the categorization just feels off to me:
For example, I wouldn't consider Next.js a backend framework. Sure, it's a server-side-rendering framework, but you wouldn't typically be using it for traditional backend things like accessing a database. Perhaps consider adding a SSR sub-section on frontend frameworks.
The data layer section seems a bit confused – it's mix between client-side stores and server-side persistence which have very different use cases. I'd probably move out the databases into their own category - would be interesting to see which JS devs prefer (eg. Postgres, MySQL, Mongo).
And trying to draw conclusions from the testing category seems odd when both frontend- and backend-specific tools are bunched together.