Why is no Laravel/Rails in JavaScript? Will there be one?

It&#x27;s downstream of a cultural difference. JS devs aren&#x27;t as obsessed with their software ecosystem as PHP or Ruby devs.<p>You can put all species of tech worker on a spectrum of more to less ecosystem-focused. At the extreme end you have, like, OpenBSD &quot;sysadmins&quot; who are more hardcore than most actual programmers, who do everything in KSH and C and try to avoid installing new packages to their boxes if at all possible. Most backend-first programming languages are around the middle of this spectrum. And most frontend developers are on the other end. They&#x27;re very much of the mindset that installing a package now that makes their immediate job marginally easier, even if it means they have to come back to it in 3 months to update the dependency, is a worthwhile tradeoff (maybe it leads to more billable hours).<p>So you don&#x27;t get unassailable home run successes like Rails in the JS world. What you do get is a constant, diffuse process of tinkering and improvements, which is often underrated by HN type readers because we just want our code from 1&#x2F;5&#x2F;10 years ago to work without changes.<p>In the macro I think the healthiest thing is to simply jump around on this spectrum on a regular basis to max out the rewards to learning at any given point.

As a Laravel dev for my main and side gigs, who also had to use React, Next, GraphQL and a whole bunch of other JS tools I can safely say nothing comes close to the full Laravel stack.<p>It&#x27;s certainly been mentioned a million times before here but the JS ecosystem is just a shitshow. It&#x27;s certainly capable, but so f*cking complicated.<p>Just on the page linked here there&#x27;s yet another three tools I hadn&#x27;t heard of before (Redwood, Blitz, Adonis) + mentions of Prisma for DB access and stuff built on Next, which is built on React. And then there&#x27;s Typescript.<p>When is this insanity going to stop.

&quot;So, I will quote a statement from the W3C Web Platform Design Principles at the end:<p>User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.&quot;<p>That&#x27;s a keeper.

Because JavaScript developers are too busy fighting over whether it should be rendered on the client or server or both

I&#x27;m quite happy we don&#x27;t have one dominant framework in JS. We have good tools for specific tasks and glueing them together is easy in JS land. Not having a big framework dictate your options is actually quite liberating.

There was one, it is called Meteor.js. However, it is widely regarded as ahead of its time.<p>Maybe the time is now?

This has been on my mind loads lately and I’ve been playing with some ideas (ohmybuck.com&#x2F;2024-05-26-10-51-what-i-want-from-the-next-big-framework&#x2F; and github.com&#x2F;olmesm&#x2F;hadeda - reviews welcome although they are both rough)<p>I think there are two main issues with js stacks - react and too much plumbing.<p>React based frameworks require too much thought about lifecycles and management &amp; synchronisation of client state. RSCs could make this easier, but I think the whole use server&#x2F;use client is a mistake and pushes the problem onto third party frameworks which aren’t focused enough to close off some doors, in the fear they loose marketshare. Remix and redwood may be on the right track but lets see in the next few months.<p>Plumbing is an issue because you still end up creating a somewhat separate api that feeds into your components. That wiring sucks time and adds to the maintenance workload.<p>Adonisjs with htmx and tsx templates feel like they’re the right direction but as another post pointed out, adonis doesn’t quite feel like js.<p>I think the solution is more magic and conventions like RoR provides. I think more opinion is good here - the wild west needed some law.

I may be wrong on this, but I feel like one of the reasons there has been so many frameworks for PHP is that for a long time, there were was no dependency manager. Once Composer came along, and the PSR standards were created, then there was less need for frameworks. You could just bolt together whatever you needed from available libraries.<p>ETA: For example, Laravel was first released before Composer was available.

I&#x27;d like to get into the nuance of Frontend vs. Backend vs. Full stack<p>Having a *backend* platform that has opinionated answers to schema &#x2F; db access, file storage, auth, scheduled jobs &#x2F; async workflow, text&#x2F;vector search, subscriptions&#x2F;streaming, scalable hosting... is awesome. That is a huge pain point surfaced by this whole debate. However, this doesn&#x27;t need to tightly couple with html rendering &#x2F; all your frontends.<p>Having a *frontend* framework that has amazing inter-op with your backend framework is amazing. E.g.: end-to-end type safety, reactive &#x2F; realtime updates, authentication flows, etc. However, this doesn&#x27;t need to be the same framework as your backend (and probably shouldn&#x27;t if you care about mobile).<p>*Full-stack* is exciting b&#x2F;c the same developer can work on the frontend and backend at the same time, ideally in the same language, with the same models flowing through. Full-stack development is about enabling full-stack workflows. It doesn&#x27;t require that the same company makes your backend and frontend abstractions. It&#x27;s actually nice when you can have multiple frontends using different frameworks (RN, React, Swift, Kotlin, etc.) or change frontends over time, while still being owned by a single full-stack dev.<p>For example, with Convex you can write your backend in TypeScript and your frontend with Next.js, Vite (Remix etc), Vue, Svelte etc. and they can all talk to the same backend API with end-to-end types and real-time reactivity. Convex has a built-in reactive database, serverless functions, subscriptions w&#x2F; automatic caching, file storage, auth, scheduled functions, text &amp; vector search, automatic scaling, etc. It&#x27;s the opinionated backend for TypeScript developers. AND you can hit the same API from golang &#x2F; swift &#x2F; etc. without getting html in response or duplicating all your business logic into opaque `&#x2F;api` routes.<p>This enables you to ship frontend components that have associated backend logic, and makes it easy for people to drop that into their Convex projects, since the database models and logic is all speaking Convex, which isn&#x27;t possible when the backend might be using any number of database connectors with varying degrees of transaction support (Convex has the highest (serializable) level of Isolation in its ACID guarantees).<p>disclaimer: I work at Convex. disclaimer disclaimer: I pivoted my career to join b&#x2F;c once I used it I didn&#x27;t want to go back.

One possible cause that bites me in JS&#x2F;TS all the time is the lack of good metaprogramming tools. There&#x27;s no simple way to autogen boilerplate, and libs that try use decorators (nest), custom compilation steps (deepkit), node modules fuckery (prisma), custom schema types (zod), etc.<p>You basically always end up with the same information in different out-of-band places (types, schemas, classes, decorators).<p>Deepkit is the most interesting approach I&#x27;ve seen - patch TSC to output type info you can use at runtime. But the custom compiler patch and solo dev make it a hard sell.

There is one. It is called AdonisJS <a href="https:&#x2F;&#x2F;adonisjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;adonisjs.com&#x2F;</a> Well, it is Typescript.

To be fair, using a separate backend and frontend is perfectly fine.<p>Full stack laravel isnt perfect. Nor is full stack frontends.<p>Laravel backend + next js react is great.

Heres how I do it. I just use express.js, sequelize (sqlite) for ORM, nunjucks for templating. Then on the frontend I use VueJs 2 which I use like jQuery - no compile step no components. Throw in some Bootstrap 4.5 because I dont need the new features of 5. Deploy on a $5 lightsail server. Done!

There are a couple, but the ecosystem is so fragmented that nothing gains a majority of mindshare.

15yrs ago i worked in an agency where we build everything with drupal. Intranets, websites, shops, apps.. At that time i hated it, but today i have to say that i am missing this kind of definitness and productivity.

IMHO the article misses at least one important thing: Microservice architecture.<p>I see Node.js&#x2F;JavaScript in the backend most often used in microservice architectures where the applications are mostly trivial and the Node.js developers are at most in the middle of the experience spectrum.<p>Thing is, for every single microservice it is easier to just implement it with some libraries than to learn a proper framework, and the hype cicles in Node.js are so short, that developers never experience real proficiency with a library.<p>In combination, after having used Node.js in the backend, I will never touch it again for backend work, unless a lot of things change in the community and tooling. I am much happier and sane using Spring or Django.

Many years back I tried a full stack JS framework called Meteor. Its still around.

Missing some (big?) contenders in this post: KeystoneJS and Strapi.

There is and it’s called emberjs. Angular counts too (I think).

How about nest? <a href="https:&#x2F;&#x2F;nestjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nestjs.com&#x2F;</a>

A lot of real world front end work involves talking to multiple systems and APIs, and most of the FE devs I&#x27;ve worked with don&#x27;t really care about ORMs or rendering data via server side templates. Being comfortable talking to APIs usually means you don&#x27;t care too much about how that is implemented.