use hono in adapter-node

[huseeiin]

Describe the problem

why is polka preferred over hono? the last time it was updated is 5 years ago. this on top of it being very slow. hono uses web-standard Request and Response so integrating it with svelte-kit's Server class (which is basically all of svelte-kit) class would be very easy and doesn't need constructing a Request from IncomingMessage.

Describe the proposed solution

use hono as described above.

Alternatives considered

hono

Importance

would make my life easier

Additional Information

hono works with bun so that's an extra

[Conduitry]

https://github.com/lukeed/polka/tags The last time polka was updated was two months ago.

Hono appears to be much larger and to do a lot of things we don't need. All routing happens within SvelteKit, not within any of the adapters.

[huseeiin]

https://github.com/lukeed/polka/tags The last time polka was updated was two months ago.

Hono appears to be much larger and to do a lot of things we don't need. All routing happens within SvelteKit, not within any of the adapters.

[dominikg]

adapter-node creates handler.js which you can use in custom servers https://kit.svelte.dev/docs/adapter-node#custom-server

you could also create a custom adapter-node-hono that wraps adapter-node and outputs a custom server using that handler.

bundle size for hono seems to be around 4x larger https://pkg-size.dev/hono https://pkg-size.dev/polka

[Rich-Harris]

adapter-node uses the most recent version of Polka listed on the tags page that @Conduitry linked to above. (This would have been very easy for you to verify, rather than just repeating yourself.)

As others have pointed out, Hono is unnecessary overhead for our use case. You could create a custom adapter that used it instead of Polka but you would be wasting your time; there is absolutely no benefit to doing so.

[huseeiin]

adapter-node creates handler.js which you can use in custom servers https://kit.svelte.dev/docs/adapter-node#custom-server

you could also create a custom adapter-node-hono that wraps adapter-node and outputs a custom server using that handler.

bundle size for hono seems to be around 4x larger https://pkg-size.dev/hono https://pkg-size.dev/polka

size doesn't matter in terms of backend.

[huseeiin]

adapter-node uses the most recent version of Polka listed on the tags page that @Conduitry linked to above. (This would have been very easy for you to verify, rather than just repeating yourself.)

As others have pointed out, Hono is unnecessary overhead for our use case. You could create a custom adapter that used it instead of Polka but you would be wasting your time; there is absolutely no benefit to doing so.

alright then, use hyper-express its native (meaning it doesn't even use node:http because it relies on uWebSockets.js)

[Rich-Harris]

size doesn't matter in terms of backend.

This isn't true. Size affects startup time, which matters if (for example) you're using socket activation.

alright then, use hyper-express its native

Why not try creating an adapter that uses it? (Though I'm not sure why you wouldn't just use uWebSockets.js directly.) If it's meaningfully faster, and doesn't introduce complexities related to native bindings, then people will use it — maybe it could even be merged into adapter-node.

[huseeiin]

size doesn't matter in terms of backend.

This isn't true. Size affects startup time, which matters if (for example) you're using socket activation.

alright then, use hyper-express its native

Why not try creating an adapter that uses it? (Though I'm not sure why you wouldn't just use uWebSockets.js directly.) If it's meaningfully faster, and doesn't introduce complexities related to native bindings, then people will use it — maybe it could even be merged into adapter-node.

i will be working on it. will keep you updated. thanks.

[huseeiin]

size doesn't matter in terms of backend.

This isn't true. Size affects startup time, which matters if (for example) you're using socket activation.

alright then, use hyper-express its native

Why not try creating an adapter that uses it? (Though I'm not sure why you wouldn't just use uWebSockets.js directly.) If it's meaningfully faster, and doesn't introduce complexities related to native bindings, then people will use it — maybe it could even be merged into adapter-node.

this is just a demo of uwsjs using Request and Response. it doesn't use sveltekit yet (it gets ~8k req/s peak, kinda not that fast to me?). tell me if you think its "meaningfully faster" so i can turn it into a proper adapter. https://github.com/huseeiin/uws-web-api

[Rich-Harris]

it doesn't use sveltekit yet (it gets ~8k req/s peak, kinda not that fast to me?)

These numbers are context-free — what machine is this running on? how does it compare with an equivalent app using polka? how much of a % difference would it make when you add the overhead of SvelteKit's routing and SSR? — and therefore meaningless.

Let me put it this way: are you currently running an app that uses adapter-node where your server is crashing or you're dropping requests and you've determined that Polka is the bottleneck? If not, you are wasting your time.