This is mentioned in the article. The problem is that based on my experience, most JS devs have never heard of it, and I've personally never heard of it being used anywhere.
It's awful. It's a cheap copy of laravel in typescript. It adds no value on top of it. The thing is, a laravel or rails for JavaScript needs to feel at home in the js land. That requires original thinking which is quite limited in the js space because the folks coming into the js ecosystem are very much into fads.
I was very interested in Adonis and decided to try it out. I scafolded a project using it and the installation kept on going. That revealed the state of the project and I never touched it again.
If someone mentions Rails or Laravel among programming people, they don't need to post a link because "everyone" knows about them as if they were React or jQuery.
Laravel and Rails are very mature and in significant contexts are standard operating procedures. There's nothing like that in Javascript.
"So, I will quote a statement from the W3C Web Platform Design Principles at the end:
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."
A lot of real world front end work involves talking to multiple systems and APIs, and most of the FE devs I've worked with don't really care about ORMs or rendering data via server side templates. Being comfortable talking to APIs usually means you don't care too much about how that is implemented.
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.
They're too busy replacing packages because the sole maintainer and contributor of each package found a new shiny thing to work on/need a new project with lots of emojis in the README to enhance their Personal Brand
And every time, management just congratulate them for keeping "up to date"
It'll end up somewhere in the middle: cloud rendering. Come try out our new service at Https://cloudrenderfish.frog.ly and be amazed at the insane benefits of offloading your render tasks to our experts.
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.
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.
I am so sad that Blitz.js kind of… well, I’m not sure what it did, but it didn’t Ruby/Rails.
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.
Nice! To expand on my original point I don't understand how someone new to Laravel can take the ecosystem seriously[1].
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.
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 really like developing with Rails (with or without React, depending on how complex the UI needs to be). In a recent project, though, I had to use a Node.js backend for something where it was OK to choose a somewhat experimental tech stack.
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.
And it's complexity for no good reason. There's still 3+ different ways to do modules and configure that in the build. And I extremely don't care - the build system knows about them, so why is it even a thing that's exposed to / can fail for me?
I'm quite happy we don'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.
Yup, I much prefer PHP to js hell but laravel is great until you want to actually build something novel. Then it gets in your way with a million layers of indirection all the way down.
JS is much more friendly when it comes to plug n play.
Maybe this is good for your pet projects, but on an industry level I can't imagine constant arguing about which flavor of week every special snowflake within the team wants to use.
It's downstream of a cultural difference. JS devs aren't as obsessed with their software ecosystem as PHP or Ruby devs.
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.
> JS devs aren't as obsessed with their software ecosystem as PHP or Ruby devs.
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.
One possible cause that bites me in JS/TS all the time is the lack of good metaprogramming tools. There'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.
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.
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.
ETA: For example, Laravel was first released before Composer was available.
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.
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.
This has been on my mind loads lately and I’ve been playing with some ideas (ohmybuck.com/2024-05-26-10-51-what-i-want-from-the-next-big-framework/ and github.com/olmesm/hadeda - reviews welcome although they are both rough)
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.
I agree Adonis doesn’t feel like js, but guess what, applying rails conventions will lead you to the same problem, it won’t feel as js either.
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.
My thought was that there is too much focus on react when it comes to js development, and catering for interactivity via react adds complexity that often forces the react frameworks adopt. React frameworks are client state first and don’t have mechanisms to keep server state in sync without requiring loads of plumbing. I feel phoenix liveview solves this somewhat elegantly.
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.
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!
I'd like to get into the nuance of Frontend vs. Backend vs. Full stack
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.
57 comments
[ 4.6 ms ] story [ 99.6 ms ] threadLaravel and Rails are very mature and in significant contexts are standard operating procedures. There's nothing like that in Javascript.
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"
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.
[1] https://pasteboard.co/1ogXkvldN47I.jpg
[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.
JS is much more friendly when it comes to plug n play.
It's nothing specific, just everything becomes harder.
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.
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.
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).
ETA: For example, Laravel was first released before Composer was available.
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.
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.
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.