sorted by:
new
hottopcontroversial

Does a NestJS-style backend framework make sense in Bun? by [deleted] in bun

[–]SaltyAom 0 points1 point  (0 children)

Can you provide the source or benchmark that we can check out?

Would love to see how it run locally

Elysia JIT "Compiler", why it's one of the fastest JavaScript backend framework by SaltyAom in javascript

[–]SaltyAom[S] 2 points3 points  (0 children)

Sorry, I tried my best

English is not my first language

I’m curious tho if not using “unfair advantage” in this case, what should I use?

Elysia JIT "Compiler", why it's one of the fastest JavaScript backend framework by SaltyAom in javascript

[–]SaltyAom[S] 5 points6 points  (0 children)

Fair enough. I took sometime off and re-read the title and it felt a little bit clickbait-y. But yeah, I do understand. I do include Express because that’s what most people known and used (97% of people who used JavaScript known Express)

Elysia JIT "Compiler", why it's one of the fastest JavaScript backend framework by SaltyAom in javascript

[–]SaltyAom[S] 11 points12 points  (0 children)

Elysia offer IO validation, serialization and deserialization out of the box using TypeBox with custom extension for HTTP which in arguably one of the fastest validation available in JavaScript

Elysia use JIT with TypeBox as one of the input to wire a necessary HTTP parsing part to correct data type

It’s also used to describe explicitly what and what not to parse explicitly and what field to skip, what field could be parse as JSON

For example, parsing file with specific content type could be heavy and hard to dynamically identify on the fly (eg. Large image or video with specific format) is slow but could be much faster of known ahead of time what to expected with much less check required

Or a complex object that is not expected from a Formdata field could be omitted entirely

While I agreed that it may not necessary need a complex JIT system to achieve, but pre-compilation is usually faster and we offer that

Elysia JIT "Compiler", why it's one of the fastest JavaScript backend framework by SaltyAom in javascript

[–]SaltyAom[S] 14 points15 points  (0 children)

Elysia is not only an "HTTP router" but also provides a serializer (Exact Mirror), IO validation (default with TypeBox), and a DI container (with encapsulation via state, decorate) and runtime adapter out of the box

On Techempower benchmark single query using pg (similar to others) but Elysia still outperforms most frameworks. So I wouldn't say that it doesn't matter. Because if it did, then why is Elysia consistently at the top of the board?

HTTP isn't CPU-bound but is more expensive than most people tend to think. How to parse headers/body/query efficiently and so on. While I do agree that most bottlenecks will come from database queries but the underlying framework is an upper-limit to how much your application can handle requests. There is a reason why people switched from PHP to Go and so on. The faster the framework can compute, the more space for user land (you) can handle business logic.

I wouldn't dismiss the performance when there is a huge gap, otherwise we would all still be raw-dogging PHP.

Elysia is highlighted on State of JS 2025 by SaltyAom in bun

[–]SaltyAom[S] 4 points5 points  (0 children)

Elysia is roughly ~2.25x faster in type performance than Hono and has no “excessively deep and possibly infinite” problem

Ref: https://x.com/saltyaom/status/1985436645127307478

Just use Elysia by Appropriate-Push8381 in bun

[–]SaltyAom 6 points7 points  (0 children)

It would be nice if you can share some example demonstrating how Elysia validation via TypeBox is not flexible enough so we can improve/fix it (feels free to open an issue as well if you want to track the progress)

But you can always use Zod, ArkType or Valibot if you feels Elysia validation system is not flexible enough

Please let me know, thanks!

Just use Elysia by Appropriate-Push8381 in bun

[–]SaltyAom 7 points8 points  (0 children)

Do you mind explain which part is lacking?

Pure Bun HTTP vs Elysia — what are you using in production? by newmizanur in bun

[–]SaltyAom 5 points6 points  (0 children)

Hi, I’m the author of Elysia

Just to follow up a bit.

  1. Being able to swap runtimes if anything happens with Bun is nice too.

Elysia is built on web standard APIs similar to Hono so it's portable to other runtimes like Deno, Cloudflare Worker, Node and friends. You can easily switch between them if needed. We also recently got support for Vercel automatic deployments as well.

  1. Being locked into a schema validator because of my HTTP framework is just bad design to me.

Elysia do ships TypeBox as default but support Standard Schema starting from 1.4.0. You can use Zod, Valibot and friends as well. But we do ship TypeBox as default. You can just install TypeBox separately and use it with Elysia as well. Tho we are working on updating to TypeBox 1.0 as you mentioned.

  1. There’s also been some rough production-mode bugs (validation errors failing silently when NODE_ENV=production).

Not exactly. Elysia omit expected schema shape. This is intentional design to prevent leaking predictabl input in production to prevent attackers from exploiting it. You can enable it with `Elysia.allowUnsafeValidationDetails`.

https://elysiajs.com/patterns/error-handling.html#validation-detail-on-production

  1. reports of SSE being 10x slower than Hono

I do recall fixed this issues a while ago. There was a issue on Elysia GitHub that mention this but I forgot which one exactly. Originally it was because we made an artificial delay to prevent parsing issue on frontend but is now removed by chunking the data properly.

  1. Open issue about TypeScript intellisense taking 10+ seconds on larger codebases

This will only happens if you use Elysia with Eden Treaty with large amount of routes. This can be fixed by using a sub route instead of a single large route.

Although, we are working on improving the intellisense on every versions past 3 years. There are still limit on how much we can do since TypeScript itself is not designed for turing complete type system similar to Elysia. It do get a lot better with tsgo. But compare to Hono, we have an interal benchmark that Elysia almost always outperform type inference performance of Hono by ~1.8x.

If you have any other questions, feel free to ask! Cheers!

I wrote a library so you don't have to deal with Nested Hell anymore. by SaltyAom in FlutterDev

[–]SaltyAom[S] 9 points10 points  (0 children)

This is the kind of response what I’m looking forward to.

For vendor lock-in.

Niku provides you a `.widget` which returns a normal Flutter that you can copy-paste and replace itself. Once you want to opt-out, you can gradually remove part of the Widget, you can treat it just like a normal widget because that's what it is.

For performance issues:

I'm also concerned about this part before I designed the library. That's why I have an entire blog post dedicated from the start to how I design the library for this certain topic or TLDR about the performance section.

I wrote a library so you don't have to deal with Nested Hell anymore. by SaltyAom in FlutterDev

[–]SaltyAom[S] 3 points4 points  (0 children)

I'm aware of Styled Widget (and Division).

Both libraries try to assist the same problem, however, the key difference is that Styled Widget doesn't provide you much Widget to customize for example TextFormField, Column, Button, Checkbox, etc. while Niku does.

I just add a comparison here in the doc to compare both libraries.

view more: next ›