Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nah, if you want heavy backend, go with Go/Ktor/C#, not node. If you want light backend, use sth like Hono or H3. If you want to primarily produce html, use Remix or Next.

Adonis/Redwood/Nest is something you will regret in few years because it will lock you down to "their" ways of doing things instead of something with replaceable components.

Admitted, Adonis looks most sensible out of these 3. Redwood is poisoned with needless GraphQL and Nest is written like 2008 java. In Adonis you can at least pick the db layer.

But even Adonis locks you to their validator instead of Zod or his cousins, they use their own Request/Response classes instead of the platform ones, has yucky inheritance and annotations magic etc.



Locking things in is not an issue if things are well built and well maintained. Having used Laravel, I'm amazed at their DX. First party libs all built by the same team, tools also built by the same team. Everything is congruent and just flows.

Compare that to the wild west that is Javascript land. Multiple libraries that all do the same thing in different ways. Stuff being deprecated or completely changed.

Sure, if you want "choice", there's plenty of stuff out there for that. You can cobble together your own framework or pick a light framework pick and then add your "batteries" to it. I hope AdonisJS only has 1 way of doing things and that those ways are good, then it will truly go a long way.


PHP world is different. There's only Laravel and Symfony. You can't count on both surviving till atomic winter.

As you say, js world is fickle and I wouldn't count on Adonis being here for a long time. Mix and match is more pragmatic in this setting.


> You can't count on both surviving till atomic winter.

Nor can you count on your JS library to survive until next winter.


Lol, Symfony was released in 2005 and Laravel in 2011. PHP is much older. They've been around for long time and will stick around for many winters.


Oops I made a typo, I meant you CAN count on them surviving

In Js world it's better to not bet everything on a single horse


The fact that people (the builders) don't bet on a single horse IS the reason why we are in the state JS world is in. The only person that readily comes to mind is Evan You, who's been working on and driving Vue JS for a very long time. Of course, Vue JS is not a framework.

Adonis is starting to get there, but I don't know much about the core team and how long they've been working on it. If they are able to focus on delivering core features and not getting distracted by every wave that hits the JS world, eventually the level of convenience they provide will reach a tipping point and developers will flock to it.


I think there are multiple reasons why JS world is different.

- JS libs often target browser as well and that's a fast moving target

- JS is primary language of serverless which is also moving fast

- it attracts younger devs chasing hot trends

- the fragmentation is already there, people got used to it and some even embrace it

I lead development on a 12 year old SPA. It's a Ship of Theseus where there is almost zero original code but we never had to rewrite from scratch, instead we were swapping piece by piece as we went. The time investment was reasonably small and we never endangered the business with the full rewrite. I shudder at possibility that someone before me picked "batteries included" AngularJs (the V1). A sibling project is still fighting it today!


"Locking things in" is an issue. It might not be a too big issue but it is one definitely.

Consider choosing Oracle as your database. It is a great database maintained by a big company so it will be around in future too. But you will be locked-in to very expensive licensing because when big businesses are "locked in" Oracle can and will raise their prices.


Terrible example.


Silly take. Apply this logic to Rails and you'd look like a fool.


So don’t use their opinions, use mine.

Until the next dev comes to the project and doesn’t agree with your opinions, right? I’ve seen this movie far too many times.

The main benefits of these frameworks is that they remove all the bike shedding decisions. And I trust more something used by a lot of people and battle proven even if I don’t 100% agree with everything.

What you think is the best library for validations is just an opinion as theirs, and for example I don’t think Zod is good at all. See? Now on a team of 5 people we have 6 different preferences and we have to schedule 10 meetings to decide what library is best. And next month we will regret using it anyways.

There is a reason Rails, Laravel, Django etc are so popular in their ecosystem.

I honestly don’t believe the “I can do better all of this by myself”. It’s usually an undocumented, unproven, buggy and insecure mess that only the main author knows how it works.


What are "heavy" vs "light?" Featureful middleware/plugin ecosystem vs stdlib+process forking?

And/or are we talking minimum memory footprint?


i mostly agree with your take, except that if you primarily want to produce html going with a server-side rendered approach might be simpler.

i'm building https://www.plainweb.dev/, which uses htmx + react style components for templating.


Looks great! +1 for using JSX as a backend templating layer.

We played a bit with Kita too and its great


Too much misinformation

- Locks you to their own Validator. Nope, Run npm install Zod and you have it working

- Their own Response/Request classes. Isn't it same with Fastify, Express and other frameworks?

- Annotations, Aren't they part of JavaScript?


That's why I don't recommend Fastify or Express. Remix and Hono use standard Req/Res

Annotations are not part of Js, they are part of Ts and are a concession to OOP people coming from other languages. It's a personal opinion but I don't like them and I enjoy this opinion is not uncommon because only few libs are riddled with them.


Yeah being subjetive is fine. We all have tastes and preferences and that's why there are so many frameworks and ecosystems.

Going to nitpick a little here

Hono docs language says, they wrap the standard Request object that you can access via HonoRequest.raw https://github.com/honojs/hono/blob/main/src/request.ts#L26

Annotations/Decorators are in stage3 of JavaScript. But I agree they are not super common in JS world except TS heavy libs or frameworks. Btw we aren't big fan of them and use them sparsely in models and commands only


this is the way




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: