Why is no Laravel/Rails in JavaScript? Will there be one?
zenstack.dev
zenstack.dev
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 "sysadmins" 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'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).
So you don'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/5/10 years ago to work without changes.
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.
Sure, individual developers like vanilla js. However corporations like Next.js & React. Because "everyone knows Next.js & React". And the same JS developers who love to tinker in their free time insist their job use Next.js & React. It's a challenge for me because I like to use my own stack that I developed. So I'm mainly focused on freelance or contract work as a sole developer. I'm happy with the tech but I sometimes have to take on work using other stacks. I prefer to avoid JS for these types of gigs.
My experience with Rails back around 2010 was attempting to transcend the constraints Rails imposes on the developer. Which led me to nodejs. People like me left the Rails ecosystem & those who liked Rails largely remained.
It's certainly been mentioned a million times before here but the JS ecosystem is just a shitshow. It's certainly capable, but so f*cking complicated.
Just on the page linked here there's yet another three tools I hadn'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's Typescript.
When is this insanity going to stop.
And my IDE had a reeeeally hard time keeping up because of its size. All the defaults were “sensible” as advertised, but the codebase was massive when I hopped off. Maybe it’s improved? This is my sign to check back in.
Creating a company selling solutions around a web framework is weird thing.
There is zero distinction here as to what is external to the framework and what's built in. Some ecosystem parts require a payment or a subscription and some don't.
The naming is the worst offender. How am I supposed to know what Envoyer does? Rails does this to an extent but it's easy to understand at a glance that Action Mailer can be used to send emails.
[0] https://medium.com/signal-v-noise/hunting-for-great-names-in...
> How am I supposed to know what Envoyer does?
If you google "Laravel Envoyer" the first result tells you "Envoyer - Zero Downtime PHP Deployment". You don't even need to click. "Envoyer" in French means "to send", not sure if that's why they picked it.
This costs money but it's for deployments so you don't even need it. Just deploy as you normally would with a git hook.
You can also deploy with Envoy, where you write a simple script that executes ssh commands (git fetch, pull, composer install, ...). Envoy is free. Obviously you're free to deploy whichever way you would.
Personally I either use Envoy (free) or an ssh script that listens for git hooks.
I picked Blitz.js, and I have to say that this is the closest experience I had so far to Rails level rapid development with a Javascript back-end tech; not having to worry about client-server communication is just great. It's a pity that Blitz is nowhere as stable and well documented yet, but it's very very promising.
I just hope that Blitz will grow in adoption and stability, and not become an abandonware like so many other promising JS projects in the past.
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."
That's a keeper.
Is your app a content website? Does it have interactive features? Is it a tool that has no state? Does it have tons of transient state? Do you depend on SEO for this thing? Do you need it to work offline?
It's far too easy to think of the web as "the thing that feeds you text articles while you are actively connected to the Internet" and lose sight of the fact that as time goes on more and more software use cases are moving to it whether you like it or not.
If it was not the preferred way to receive software as a user, software made using non-web stacks would have an immediate advantage over web stack ones. Obviously the opposite is true.
And every time, management just congratulate them for keeping "up to date"
JS is much more friendly when it comes to plug n play.
It's nothing specific, just everything becomes harder.
Maybe the time is now?
I think the team behind Meteor.js went on to build a new product (https://www.apollographql.com/ if I remember correctly).
I think there are two main issues with js stacks - react and too much plumbing.
React based frameworks require too much thought about lifecycles and management & synchronisation of client state. RSCs could make this easier, but I think the whole use server/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.
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.
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.
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.
Also, react has nothing to do with all of this. This is about backend.
Laravel is a great example of this kind of framework, and with inertia you can use react in a sensible way.
And also, htmx is no way the solution to anything g of this. It’s only useful for the minimal examples, you can build anything slightly advanced with it without everything becoming a mess.
Mind elaborating on why react has nothing to do with this?
I appreciate your comment on htmx - I have yet to work with it on a larger scale.
ETA: For example, Laravel was first released before Composer was available.
Having a *backend* platform that has opinionated answers to schema / db access, file storage, auth, scheduled jobs / async workflow, text/vector search, subscriptions/streaming, scalable hosting... is awesome. That is a huge pain point surfaced by this whole debate. However, this doesn't need to tightly couple with html rendering / all your frontends.
Having a *frontend* framework that has amazing inter-op with your backend framework is amazing. E.g.: end-to-end type safety, reactive / realtime updates, authentication flows, etc. However, this doesn't need to be the same framework as your backend (and probably shouldn't if you care about mobile).
*Full-stack* is exciting b/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't require that the same company makes your backend and frontend abstractions. It'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.
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/ automatic caching, file storage, auth, scheduled functions, text & vector search, automatic scaling, etc. It's the opinionated backend for TypeScript developers. AND you can hit the same API from golang / swift / etc. without getting html in response or duplicating all your business logic into opaque `/api` routes.
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'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).
disclaimer: I work at Convex. disclaimer disclaimer: I pivoted my career to join b/c once I used it I didn't want to go back.
You basically always end up with the same information in different out-of-band places (types, schemas, classes, decorators).
Deepkit is the most interesting approach I'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.
Full stack laravel isnt perfect. Nor is full stack frontends.
Laravel backend + next js react is great.
I see Node.js/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.
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.
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.
Laravel and Rails are very mature and in significant contexts are standard operating procedures. There's nothing like that in Javascript.