I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. ORM situation looks pretty fragmented or you write pure sql. And then you still have to decide on the backend. Going raw with express? Next.js, well known, but with a questionable agenda (, Remix, Astro, TanStack, and so on. It's a mess, because you always have to recalibrate and re-evaluate what to use.
I often see myself going back to Ruby on Rails for my private stuff. It's always a pleasure. On the other side, there are so few rails people available (compared to js) that it's not viable for any professional project. It would be irresponsible to choose that stack over js and often java for the backend.
Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM.
My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shape because that’s too magical. Instead the Right Way is to learn a DSL (such as Zod) to describe the shape of the input, then manually write the code to check it. Every single time. Oh and you can’t write a TS type to do that because Reasons. It all comes off as willful ignorance of literally a decade or more of established platforms such as Rails/Spring/ASP.NET. All they had to do was steal the good ideas. But I suspect the cardinal sin of those frameworks was that they were no longer cool.
I have a hard time relaying this without sounding too negative. I tried to get into SSR webdev with TS and kept an open mind about it. But the necessary ingredients for me weren’t there. It’s a shame because Vite is such a pleasure to develop with.
The curse of being an experienced developer is watching good things go away, and then get re-invented and everyone hails them as a major innovation without any awareness that this has existed for a long time.
Someone will steal the good ideas eventually. And everyone will act like it’s the first time this idea has ever come up. I’ve seen it happen a few times now, and each time it makes me feel ancient.
We had to write a migration layer on top of Prisma that can run arbitrary code to do things like transactions in migrations. Kind of a bummer that something like that's not built-in to the system but it was also trivial to put together.
Well, we're not the "go to" yet :-) but if you want an entity-based ORM that isn't just a query builder, Joist has several amazing features (no N+1s) and great ergonomics https://joist-orm.io/
What's wrong with TypeORM (besides being javascript of course)? Works alright, creates migrations based on entities automatically, and I really haven't had any issues with it. Even having several different dbs in the same project is straightforward.
We currently have two major apps, One in typescript and one in rails. I have to hire devs for both, and I have not experienced it being any more difficult to find a rails developer or a node/typescript developer. If anything, I think finding a rails developer with relevant experience is even easier because the stack is so much more standardized. With people with node experience, there is a huge chance that they won't actually have any experience with the libraries that we are using, even though they've used other libraries in the node ecosystem. With rails, however, pretty much everybody with experience in a rails app will be able to jump into our application and will see a lot of stuff that is familiar right out of the gate.
I'm personally an elixir Phoenix Fanboy now, so I don't choose rails as my first choice for personal projects, but I think it is an excellent choice for a company. In fact, I would probably recommend it the most over any framework if you need to hire for it.
That's a point which cannot be underestimated, almost every Rails codebase looks mostly the same while I've never seen two similar node projects. Standardization also has advantages on training and hiring.
I really hope that Elixir / Phoenix will gain more traction.
It is very easy to write a server with it, hosting and deploying is painless, upgrading it (so far) has been painless, linting and debugging has been a breeze.
If you're coming from Ruby, then learning Elixir requires a small mental adjustment (from Object Oriented to Functional). Once you get over that hump, programming in Elixir is just as much fun as Ruby! :)
Agree. The one thing LiveView is missing is 1:1 Tailwind and Shadcn libraries that are more or less interchangeable with the huge ecosystem around them. I just want to be able to pull in popular components for the wider dev community. There’s some commendable attempts at UI libraries for LiveView, but they are too opinionated stylistically or just slightly off mainline shadcn. I don’t really want to hang my hat on this type of thing and later get burnt when it’s no longer maintained (which is more often the case). Also, the AI tooling for Elixir is greatly lagging which is disappointing as that language is particularly well suited for it.
Can't speak to ORMs, but I'd have a look at SolidStart. If you need an API, add in tRPC. End result is highly typed, can do SSR, and once you get used to it, it's a much better experience than using React.
I still haven't found an ORM with JS that really speaks to me.
> there are so few rails people available (compared to js) that it's not viable for any professional project
I don't think this is true; Shopify is a Rails shop (but perhaps it's more accurate to say it's a Ruby shop now). It feels easy to make a mess in Rails though, imo that's the part that you could argue is irresponsible
The JS ecosystem would be so much better if developers concentrated to contributing to libraries rather than writing new frameworks. After about 10 years of JavaScript, I recently moved over to .NET and I'm finding that my team can focus on actually developing features than maintaining the plumbing.
Yes, my experience as well. Last year I had to make a decision for the stack of a small app at work that needs a SPA (3D viewing large data sets using threejs and agGrid if anyone cares) and with long term stability as very high prio.
Long story short: I ended up choosing ASP.NET Core with Minimal APIs. The main reason was indeed EF Core as ORM, which I consider as one if not the best ORM. In the Node world there's so much promise (Prisma, Drizzle, ...) but also so much churn.
I think there are a lot of Rails developers available. The concern many devs have is that they fear they can't get a job anymore (they're mostly mistaking the downturn of the entire market for one limited to Rails).
Why is that a mess? From my experience you have to recalibrate your project constantly. the framework that's hip and new will be phased out in 5 years.
I don't mean that rewrite hell is a permanent state, but you will always be rewriting parts of your project. I'd rather choose an ecosystem where the friction for rewriting is minimal.
If you need to rewrite everything every 5 years then you are making the wrong technical decisions up front.
Choose boring tech that doesnt change since its already mature and battle tested and because it is not beholden to the whims of some VC money or whatever.
React itself (not Next.js) doesnt change a lot and will let you run your app for the next decade at least.
Same with any boring PHP, Ruby, Python, Java, dotnet framework out there.
You might need to upgrade versions, but there will very seldom be breaking changes whete you have yo rewrite a lot.
I often see myself going back to Ruby on Rails for my private stuff. It's always a pleasure. On the other side, there are so few rails people available (compared to js) that it's not viable for any professional project. It would be irresponsible to choose that stack over js and often java for the backend.
Anyone have similar feelings?