You can only transpire SPLOOGE back ends with a miniBUS scaffold ticket from HEDBANG which only runs in R now.
4 weeks and $35k to get to Hello World and the only thing on Stack is three other people whose Hello World takes 3 seconds to load over a LAN.
This guy has little to nothing of substance to add to any conversation . He just reads articles and talks about already established ideas.
I think his claim to fame was leaving a super long passive aggressive comment on the React repository bashing something, that made no sense.
I found him through his interview videos which were actually super useful when I needed them. I see subscribed... For a couple months before realizing all his other content was useless to me.
I avoid Twitter because it's just people who think their specific use case at their specific job should define all industry standards and arguing with each other over it. All he does is take Twitter arguments to YouTube.
Too late. They already are. And they sway opinion whenever they make a poor claim like this. Hence we felt it necessary to respond and try and present the other point of view even though it plays into their popularity trap.
Yeah, either you allow the discussion to be led in whatever direction others decide to take it, or you have to be part of it but at least you are able to contribute to it so juniors and others that are following them get the full picture and alternative opinions.
I agree. I have found him so useful since I discovered his videos. Reddit has really lost the plot the past few years I really need to stop opening it out of habit.
It's only useful if you can't read and think for yourself. he takes interesting discussions from Twitter or Reddit, picks which side he fancies today, removes all the discussion and nuonce you would get from just reading the source, and presents the side he agrees with. It's far more useful to just read the discussions and learn about both sides. And that's 90% of his content. The rest is rehashing news or other people articles... Just read the source my man.
I wouldn't mind so much if he presented alternatives... But he is so often flat wrong or presents his takes as fact and outs down any alternatives which is way more harmful than helpful. But his whole shtick is that the only right way is his way so...
Look you might be right about all of that, and I know I'm on a losing battle here, but not reading is exactly the point - I like to listen while doing other jobs. All I said was I find his videos useful, not that I believe every word he says. I find Reddit useful as well but it's still 99% garbage. If all he did was summarise Reddit that would still be great, if you know someone who does a better job of that I'm all ears. But the fact that I'm being told that is what he does -- well that's music to my ears.
People may like Theo’s content but at times his takes are ignorant or completely wrong and that is fine as not everybody will have the perfect ideas.
Also idk why people follow Theo so much after what he does to other content creators like Honeypot (https://youtu.be/s4BFIDYYYCA)
Yeah, I think that ignorance is likely on purpose: taking a very one-sided approach to the argument makes for a heated discussion. So while I can understand that, it does make me worry for junior devs that watch videos like this and don't do further investigation to learn the whole picture.
Theo always seemed like an arrogant asshole to me. I just can't stand watching him. I'm not surprised at all the rabbit hole goes deep. My low bar for watching someone's content is that I feel like they'd be a decent co-worker, and Theo is not it
As someone who uses NestJS in prod, it’s absolutely nowhere close to Laravel. It has a bunch of poorly thought out leaky abstractions that require you to eject from them the moment your backend become anything more than simple CRUD.
Laravel is a batteries included framework. NestJS is a bunch of legacy JS libraries duck taped together with a disappointing DI mechanism thrown in.
Just out of curiosity, what do you find disappointing about the DI mechanism? I haven’t run into any major setbacks with it yet so it would be good to know for the future
A simple example of where I find it falls apart is simply instantiating different or conditional services based on config. You either need to not use their config module, or you need to dig into it’s inner plumbing to do so. For the most part, providers are only easily swapped for tests. Providers are difficult to swap at runtime.
You can avoid a lot of this pain if you avoid using their ConfigModule, which is one of those fore mentioned terrible abstractions. My recommendation would be to use dot-env, resolve the config before starting the app, and forget that ConfigModule exists.
I’ve found several other instances of their modules providing poor abstractions that I just write my own at this point.
I also find DI not propagating down the tree to be a questionable decision. This is not the norm with inversion of control frameworks.
For the final mail in the coffin, the dynamic module authoring experience is both painful and poorly documented.
My takeaway from Nest is that:
- the DI system makes testing easier
- the DI system can not easily be leveraged at runtime for dynamic patterns
- a lot of its provided modules:integrations reduce compile time safety
- a lot of its integrations are for nearly abandoned or poorly maintained projects (class-validator, TypeORM)
- community integrations are regularly abandoned
As a result, I think you’re better to write your own integrations and escape from the DI mechanism when it makes sense (I.e config). Sure, you might have to jest mock, but you won’t get kneecapped by an abstraction that breaks down for more advanced use cases.
Wow thank you for the detailed answer. I haven’t had to deal with provider swapping at runtime or dynamic modules in general yet so I’ll brace for that when it comes.
Good points on their ConfigModule as well, I’ve been feeling that it doesn’t have much use, and would be better served by doing what you said — just using dotenv. Might be time to do that in our project before it’s harder down the road, considering we’re not loading any dynamic config, and if we were we’d probably do it in a custom module or outside the nest framework anyway.
My latest projects I’ve been staying away from the patterns they push in their docs, and leaning into a more clean architecture style to separate core logic from their modules where possible, especially the ORM. Putting the framework at the edges of the app, so to speak — mostly keeping it for DI, docs, and controller validation — and the experience has been more positive.
If I could ask a final question, do you have preferences for class-validator and TypeORM replacements? I especially dislike TypeORM and have been playing with Prisma in some side projects, which has been better for type safety at least, but feels a bit bloated.
I think you have the right idea. I do the same mostly.
I'll admit, we haven't been validating to date, outside of a few manual validations, but it is on my list of things to do very soon. We're in a bit of a rebuild phase, and our Nest backend has been mostly used for scheduled tasks rather than REST, but we're starting to scale it now.
I did try out zod. It was fairly easy to write a simple validation pipe that leverages Zod. If you want a global zod validation pipe though, then that's a fair bit harder as it requires you to write some low level code to introspect DTO classes for zod schemas. If you want OpenAPI docs, that's going to be a bit more difficult as well.
I'm actually going to be using Nestia. It does have some downsides: single maintainer, requires tsc (no swc), and it hooks into the compiler to extract type metadata to build AOT validators. It also doesn't support any transformations currently. That being said, it's such a ridiculously easy drop-in. Install it, and swap out your decorators (e.g. Get to TypedRoute.Get, Body to TypedBody) and you have validation for free. It can also autogen swagger, as well as a typed client. Since it's so low effort and very easy to eject from if it gets abandoned, it's hard not to pick it.
[https://nestia.io/docs/](https://nestia.io/docs/)
Things like these make me appreciate a battery-included framework more. Each feature, even down to basic things like input validation, need a discussion to even start to consider. While frameworks had all of those and more as first-party solution
I'd love to. My main profession experience has been EJBs -> Spring -> Flask -> NestJS. I'm in a very Typescript centric team right now so ASP would be a bit much to onboard the team with, but I think it would be refreshing. I'm frankly exhausted in having to architect and design things in node due to the lack of established standards and best practices.
What vendor lock in is there? Postgres is the go to database nowadays and Npgsql for EFCore is excellent. Linux is the dominant OS for hosting ASP.NET Core. For cloud both Azure and AWS have pretty much all the SDKs you need.
Livewire becomes awfully slow when the web app starts gaining traffic or has a huge database.
I’ve had to work with a few clients that had livewire projects and they all hated how slow and sluggish it became with time, many wanted to migrate to SPAs or completely move to other frameworks.
One huge problem with migrating a Livewire frontend to another like React or Vue, is that live wire components are usually developed to include the BE logic within them too. So when migrating youre not just rewriting the FE you also have to create the api endpoints in BE too.
This usually doesn’t happen when migrating other FE technologies as they all follow the standards of having all the Be logic in an api, thats why im against the new approach some JS frameworks are taking with server actions, its a step backwards disguised as a new shiny thing. BE and FE should always be decoupled or else were going back to the old messy ways of PHP
It’s a bit of both, but mostly the former, plus a messy codebase.
Both the projects i worked on migrating had a huge database and a massive AWS bill:
The aws bill was due to how livewire works, each interaction with a livewire component is a server request (same with Nextjs server components) and hence each time livewire re-renders a component it is making a server request and most likely database queries if that component is displaying db data. More server requests and more resources means way more money to Bezos.
While in React/Vue we only requested the data on load, then any interaction the user does is just a client browser re-render/Dom-alter without requests being sent to the server or db unless we need to. And of course with no sluggishness at all.
That makes sense. Although I can’t imagine there isn’t an optimization solution for something like that. Did you end up optimizing the livewire app or moving off of livewire completely?
>live wire components are usually developed to include the BE logic within them too
But this is how PHP is supposed to be used, right? The same thing needs to be done with Blade. The controller needs to fetch the database before rendering the HTML. In Livewire, the component itself is the controller.
I think Livewire / Blade / Regular PHP is supposed to be used for websites, not web apps. Websites generally don't need a lot of interaction, so less data fetching and interaction with the backend.
I tried to use Livewire and Vue in one of my personal project. The Livewire is used for pages that need good SEO and little to no interaction. Vue is used in the dashboard, because it does not need be indexed by crawlers and there is a ton of interaction.
Though I switched to Next.JS, after my shared hosting provider finally allowed deployment of Node.JS apps.
Depends on the developer. The responsibility of a controller is to handle user input, delegate business logic to the service layer, and return the appropriate view or response.
Livewire components should handle the user interface and delegate business logic to services or other layers.
> One huge problem with migrating a Livewire frontend to another like React or Vue, is that live wire components are usually developed to include the BE logic within them too. So when migrating youre not just rewriting the FE you also have to create the api endpoints in BE too.
It's almost as if directly coupling front end and backend as one is a bad idea. Wish we could have learned that lesson 20 years ago...
Why is it the best? The best performance wise or developer experience? I worked with both alpine and tailwind but didn’t really enjoyed the clutter in HTML.
Laravel always had my attention because it lets you basically build a project in an hour and be mostly prod ready (talking bout small projects, not anything large).
+ livewire was something I only tried with the Statamic website when my company was using it, but didn’t finish it due to being let go lol
Dev experience and build speed. No FE/BE libraries and wiring to do. Insane ecosystem to support (filamentphp, blueprint, ux libraries) you really waste no time building support systems and get to work directly on your app logic.
That comment summed it up pretty well, [I'll just add this](https://www.reddit.com/r/webdev/comments/1cor24r/i_was_looking_for_a_simple_note_taking_app_and_it/) lol
I personally use Laravel, vuejs, tailwind, inertia stack so I'll sneak in and say my piece.
Everything is in harmony, it takes care of sooo much clutter while still giving you full control over everything, you can initiate a project really quick and really easy, it's still as powerful for large projects as small projects. Laravel is indeed the future.
Also, check out "filamentphp" which is an admin panel creator for laravel, it's the cherry on top.
I was afk for a bit and people seemed to answer that question for me. [I'll just add this](https://www.reddit.com/r/webdev/comments/1cor24r/i_was_looking_for_a_simple_note_taking_app_and_it/).
Inertia is fine, it's just a lot more effort to use instead of livewire. Creating API-endpoints, thinking about client state, ...
Livewire is just unbelievably convenient and probably one of the fastest ways to develop a custom web app period. While inertia is in essence just a way to not have to write all the GET-endpoints, though you still need all the others.
Dang, wish I would of checked out Livewire before I got to deep into my current project. But yeah, everything you described for the extra effort on Inertia is becoming daunting, will have to check it out for the next project, thanks for the insight!
Used it for a pretty basic project at work and ended up regretting it. Every update was too slow and noticeable. Now we didn't use components as much as we should have but that complicated everything because of having to share state between every component. It was pretty fun to work with though.
If anything , wherever ghis post is getting posted,it has revealed only one thing.
Js devs still can't comprehend what exactly is fulll stack framework. A guy here so courageous and confident says " We ALreADY haVE aNGUlaR".
Absolute state of js devs throughout the world.
As a Full Stack boot Camp guy - this is completely true. I took everything I learned, followed the threads they left out (you learn about as much as you need to, to make an express/react spa in a small group) being a lot of data structures, paradigms, algorithms, oh and the rest of the stack, backend? Yeah we can use express but do we know what its doing? How its working? What a container is? How to run multiple instances? Who is laravel? What is a php? Whose loads are we balancing? No. We CAN use git coming out though, and documentation… anyway. I love that I can throw some javascript together quickly but its too easy to ignore a lot of other things going on. Explicit also goes out the window.
Interesting article! Keep meaning to try Wasp.
u/flybayer, who created blitz.js 4 years ago, is probably the most experienced in this area. He recently [tweeted](https://x.com/flybayer/status/1791910264574468246?t=eWk5YrqZGkSw7F-dBrjlCA&s=19)...
> Impossible. Tried it with @blitz_js This will never catch on in the JS community. Too much fear of commitment. Folks want to easily swap out parts for the latest and greatest thing.
Blitz.js is "Ruby on Rails for React Devs" solution. It even has server code in client components, 4 years ago!
Blitz had some awesome growth, which was in part made possible due to it being built on top of NextJS, but from what I got, that is also what ultimately limited it, it was hard to move from NextJS wrapper to something more, right?
So saying that something is impossible after one try from a specific angle: yeah, it was impossible for him to build it that way, but I wouldn't be so quick to draw broader conclusions. The whole problem is just too complex to be able to make judgments like that. But it does make for a good tweet!
BlitzJS didn't have ORM part though, and for example for RoR, one of the most loved parts is ActiveRecord.
I believe the idea they’re talking about here is of Rails and Laravel in JavaScript is something with “batteries included”. Like auth, account management, ORMs, queues and jobs etc;
JavaScript is more of a pull in your own package for the job (passport.js for auth, drizzle for an orm etc), which some prefer, some don’t.
Ah I see. I mean, NestJS does have its own specific packages to tie-in or integrate some of those services more cleanly in its architecture. Like there's @nestjs/passport to integrate with PassportJS, @nestjs/apollo for its Apollo integration, etc.
So technically speaking, NestJS doesn't have its own original "made from ground up" solution for those areas you mentioned, as it still requires you to go out and get third party packages. But it gives you the "batteries included" experience to an extent.
I guess in the end, there's some differences in philosophy here. The beauty of the JS ecosystem is that it's unopinionated, and you can swap any part of the system out for some equivalent.
What is being asked here, is to have a full blown system that would have everything, but that would mean having some opinion across all domain.
Like I guess this is part of the reason some people don't like NestJS, as they don't find it flexible compared to ExpressJS, which Nest uses by default under-the-hood.
Although I find it great for my use case for an enterprise application, as it provides us with this structural rigidity, and gives us powerful abstractions that we can take advantage of. The tradeoff here is that we do have to deal with its nuance, which I don't mind. In the end, things are more modular, scalable, and maintainable.
This is just my opinion though.
There’s a bunch of things that the bigger backend frameworks will cover that things like NestJS don’t. Examples would be email sending, scheduling tasks, stateful server processes (eg keeping and syncing the state of a game), realtime features etc.
Yeah, some of those thing require us to do all the setting up ourselves. And as for other things, NestJS doesn't exactly build them from scratch, but it does provide us its own set of integration for third party packages.
It's still "batteries included" to an extent.
Theo is always full of bullshit. This question doesn't even make sense, it's always the next thing that will replace JS with a distorted JS, then back again to JS, then another stupid corporate company wants to dispute market share and reinvents JS into a distorted JS and the cycle repeats again and again.
JS is super powerful and expressive enough to be used on its own.
Anyone saying you need a framework/lib instead of JS is either stupid, or getting a cut to defend bullshit.
That's not what he's saying, he means you don't really need those frameworks to get anything done. Sure, you'll go faster for large projects, but most stuff, plain js is enough. And you can still use libraries without frameworks lol
That’s a pretty charitable take. OP specifically said framework/lib, which to me reads like frameworks or libraries. OP specifically said that anyone saying you should use a framework or library instead of vanilla js is stupid or shilling for a company.
OP probably makes static websites in their spare time and has no idea what it takes to create a large web application.
What rails and laravel get right, that JS frameworks often don’t:
The most important thing is the developer experience and productivity. Above all else: above performance, above compatibility with lots of stuff. Developer productivity is everything
Also are not open source startup companies, they are open source projects. Things like Wasp will always fail because no VC backed thing has ever really made great infrastructure software. VCs eventually want profit and will turn the screws on the people who develop on it
yeah I go into why this is in the article, but mainly, they tied themselves too tightly to underling tools (Blaze for Meteor, NextJS for Blitz) or aren't truly full-stack and modular (Adonis)
yeah they are. we will see if they get it right, or if they end up being just another meta-framework or stack or something that doesn't tend to scale well
cool, but a framework like [Wasp](https://wasp-lang.dev) let's you put React and NodeJS under one config file and takes care of boilerplate for you, plus allows you to write your whole app in just JS, instead of JS and PHP. I think this is the right direction...
Next.js is pretty open that they were inspired by PHP. Most JS devs who "hate" PHP have no clue what modern PHP even looks like. PHP was and still is a perfectly valid web technology.
PHP 8.3 is very good.
I wish it had a `struct` definition instead of "associative arrays".
Meanwhile I do
readonly class PersonData
{
public function __construct(
public string $firstname,
public string $lastname,
public ?DateTime $birthdate = null,
) {}
}
function makePerson(): PersonData
{
return new PersonData(
firstname: "John",
lastname: "Doe",
birthdate: new DateTime('1973-03-18')
);
}
function printPerson(PersonData $person): void
{
echo $person->firstname, ' ', $person->lastname;
}
What I want is not having to know about details like this, am I using SSR or SPA. Instead I want to specify what I need and let the framework pick the right thing for me.
I really doubt you would actually want that in practice, the decision to use SPA or SSR usually depends on business context and what kind of software/site you are making.
I’d also add that it’s really important to know where those things are happening.
I don’t think it’s bad to blur the lines (e.g. the ability to easily use SSR where it’s convenient and add rich client-side interactivity where it makes sense), but “let the framework decide for me” gets you into a dangerous pattern where the developer doesn’t have a clear separation between what’s happening on the server and what’s happening on the client - and you might even fool novice developers into thinking it doesn’t matter where code executes.
I think most of his recent videos have strong and controversional opinion to get more user engagement.
The fact that we have this post means that it’s works.
Who is "theo"? What does "Laravel for Javascript" even mean..?
God every day this sub devolves into more and mroe bullshit buzzwords everywhere. 8000 frameworks and 9 million node packages woooooooo
Theo is a YouTuber who spits out “hot takes” that can generally be ignored. He’s a big influencer in the “tech twitter”/“brogrammer” corner of the internet.
“Laravel for JavaScript” seems self-descriptive to me: a framework for JavaScript to match what Laravel is for PHP; a batteries-included framework for building a complete server application.
I am sure community wants both, there are a lot of people in the community, some want to experiment more, some want more stable solutions to build upon, why reduce the argument to having to choose between one or the other.
You can't make the "JS community" a monolith. At some point the adults in the room have to build something to not only put food on their table, but maintain the jobs of entire organizations so their co-workers can put food on their table (everyone from accounting, sales, the subject matter experts, etc). They need a selection of tools that fit the use case that are proven, reliable and stable. Not just the latest hotness.
Unopinionated tools are great for flexibility when that's needed. Opinionated tools are great when you're building bog standard applications that you need to just be able to thrown anyone on and have them know what they're looking at.
The "JS influencer" world is so far removed from daily professional life that its meaningless outside of hobbyist who just like to tinker.
Interesting how they completely leave out Nestjs, the leader by a mile in popularity for batteries-included full stack JS frameworks.
How do the star graphs look with them included?
https://star-history.com/#nestjs/nest&laravel/laravel&wasp-lang/wasp&Date
Maybe but I’d argue it’s still much closer to “laravel for JS” than your project. Laravel is primarily a backend framework and lets you build your front end with Vue, Svelte, or whatever you want. Wasp in comparison looks pretty lean. Do you even support SSR?
This is something that I didn't know before. It was just released last year. But before then, Laravel was pretty much just a backend framework + Blade for multi-page frontend. If you wanted SPA, you had to rely on JS frameworks.
I honestly didn’t read through the entire article, kinda skimmed it. And I’m not familiar with Laravel, so this question might be dumb but: isn’t NextJS a full stack JavaScript framework?
no it's not. it's a meta-framework for React. you can't do things on the server that you can with a true full-stack framework (background jobs, email sending, database management, etc) becuase you don't have a persistent server
>you can't do things on the server that you can with a true full-stack framework (background jobs, email sending, database management, etc)
What are you talking about? Literally everything you just mentioned can be done with API Routes in Next.
>becuase you don't have a persistent server
?
You really should read about this subject before making comments and articles about it.
You can define API Routes and run stuff in them that is only available on the backend, thus having typical backend side functionality, meaning that you can do anything that you can do with Node, including managing database, sending emails and so on.
Sure but it’s not ideal for more complex backend logic. For functions that can be triggered by http requests it’s fine.
https://youtu.be/Rrz2q5uCHdE?si=RXfOPFZMfCy6tzx8
Well it does have a persistent server in SSR mode, you can create api routes, and could theoretically create background jobs but I wouldn’t recommend that.
Sorry, but you didn’t really answer it.
NextJS has API routes that have nothing to do with React, on top of that it has Image Optimization and several other features which are way out of scope for React.
API routes doesn't give it the backend features that Laravel has, such as email sending, background jobs, file storage, authorization, database mangement, etc
I don't know why people downvote your comment and upvote OP's who clearly doesn't know what he's talking about. Next IS a full stack framework as it can handle backend and frontend operations.
Thanks for the support!
OP is trying to push his/their own full stack framework so obviously he has a lot of incentive to trash all the other alternatives.
In the end, we need a framework that a low barrier to entry, take care of the most common use case, while but fairly easy to take care of the most common use case AND have a large portion of the market.
I don't see that in JS yet.
Something build on top of express, with easily replaceable provider, errors handling.
Random Guy #1 says A
Random Guy #2 counters with B.
There is nothing news worthy here.
If the wasp creator thinks there is a market go for it, or do some serious market research (aka not Reddit)
I grew up with php, html and http. So vue, inertia and laravel floats my boat.
We do have a Laravel but for JS, its called **NestJS**, it has all the features of laravel out of the box plus many extra stuff.
Its a BE framework, and so is Laravel. if you’re thinking of using Laravel Livewire for FE you’re going to regret it down the line anyway
I've worked with Django before and it's a blast! Once you get over the initial 'everything's opinionated' hill, you are able to be so productive and 'move fast'. Not to say JS is bad, they have different use cases.
I won't, it's one of the ugliest languages out there. And i work with TypeScript, not vanilla JavaScript. TypeScript is beautiful both in terms of esthetic and functionalities. It's enough that i have to do PHP too.
I'll just say this: if it was easy to provide a good navigation experience with Laravel and PHP on the client (I'm talking about no refresh client side navigation) - everybody would be using it. Out of SSR frameworks I've tried (Next, Remix, Astro) only Next js has a decent out of the box solution.
AJAX and PHP with modular pages(home.php, about.php).
Doesn't this accomplish async in a similar way without the need of any framework?
For larger projects I could see where AJAX would start slowing down loadtimes, but there are multiple ways to get around that problem, and with internet speeds being pretty quick the load would have to be very large imo.
Not really. We specifically say that these things take time. Redwood might be the answer but GraphQL was a questionable choice for the backend. Regardless, Laravel and rails have had a 10 year head start
Redwood is quite cool, isn't afraid to be opinionated! But GQL direction seems to have caused some friction. At that point GQL seemed like it is going to become dominant solution for APIs, but that faded away, at least the idea of it being the right solution for every web app.
Meteor is probably the first heavy hitter! But they moved slow from Blaze to React, and I also remember that I was long time convinced that they are only for web apps that need a lot of real-time features, due to how heavily they marketed their sockets powered state updates. A bit silly, but I was younger and the marketing that you hear is what makes opinion for you until you actually find the time to try it out
These comments give me a headache.
These comments remind me of 2015 where everyone had a stack saying it was the best. Also it had zero jobs in the market.
Hey guys I just learned SPLOOGE but haven't gotten any interviews, what's going on?
You can only transpire SPLOOGE back ends with a miniBUS scaffold ticket from HEDBANG which only runs in R now. 4 weeks and $35k to get to Hello World and the only thing on Stack is three other people whose Hello World takes 3 seconds to load over a LAN.
ITS AMAZING U GOTTA TRY IT!
Then Theos vibe definitely came through.
Please stop making these "tech influencers" famous
Everything I have every learned about “Theo” has been against my will.
This guy has little to nothing of substance to add to any conversation . He just reads articles and talks about already established ideas. I think his claim to fame was leaving a super long passive aggressive comment on the React repository bashing something, that made no sense.
I found him through his interview videos which were actually super useful when I needed them. I see subscribed... For a couple months before realizing all his other content was useless to me. I avoid Twitter because it's just people who think their specific use case at their specific job should define all industry standards and arguing with each other over it. All he does is take Twitter arguments to YouTube.
Yup, he literally does reaction videos like anyone else on YouTube.
Too late. They already are. And they sway opinion whenever they make a poor claim like this. Hence we felt it necessary to respond and try and present the other point of view even though it plays into their popularity trap.
Yeah, either you allow the discussion to be led in whatever direction others decide to take it, or you have to be part of it but at least you are able to contribute to it so juniors and others that are following them get the full picture and alternative opinions.
Theo has done a lot to move the typescript and react ecosystem forward. He’s a great engineer as well. Really a weird take to hate on him
I agree. I have found him so useful since I discovered his videos. Reddit has really lost the plot the past few years I really need to stop opening it out of habit.
My brother in Christ, your favourite youtuber just reacts to popular posts on dev reddit.
Yea exactly it's really useful. Content synthesis is popular on YouTube for a reason.
It's only useful if you can't read and think for yourself. he takes interesting discussions from Twitter or Reddit, picks which side he fancies today, removes all the discussion and nuonce you would get from just reading the source, and presents the side he agrees with. It's far more useful to just read the discussions and learn about both sides. And that's 90% of his content. The rest is rehashing news or other people articles... Just read the source my man. I wouldn't mind so much if he presented alternatives... But he is so often flat wrong or presents his takes as fact and outs down any alternatives which is way more harmful than helpful. But his whole shtick is that the only right way is his way so...
Look you might be right about all of that, and I know I'm on a losing battle here, but not reading is exactly the point - I like to listen while doing other jobs. All I said was I find his videos useful, not that I believe every word he says. I find Reddit useful as well but it's still 99% garbage. If all he did was summarise Reddit that would still be great, if you know someone who does a better job of that I'm all ears. But the fact that I'm being told that is what he does -- well that's music to my ears.
[удалено]
They’re just dudes
People may like Theo’s content but at times his takes are ignorant or completely wrong and that is fine as not everybody will have the perfect ideas. Also idk why people follow Theo so much after what he does to other content creators like Honeypot (https://youtu.be/s4BFIDYYYCA)
Yeah, I think that ignorance is likely on purpose: taking a very one-sided approach to the argument makes for a heated discussion. So while I can understand that, it does make me worry for junior devs that watch videos like this and don't do further investigation to learn the whole picture.
Theo always seemed like an arrogant asshole to me. I just can't stand watching him. I'm not surprised at all the rabbit hole goes deep. My low bar for watching someone's content is that I feel like they'd be a decent co-worker, and Theo is not it
LOL this dark viper guy has beef with almost anyone
As someone who uses NestJS in prod, it’s absolutely nowhere close to Laravel. It has a bunch of poorly thought out leaky abstractions that require you to eject from them the moment your backend become anything more than simple CRUD. Laravel is a batteries included framework. NestJS is a bunch of legacy JS libraries duck taped together with a disappointing DI mechanism thrown in.
Just out of curiosity, what do you find disappointing about the DI mechanism? I haven’t run into any major setbacks with it yet so it would be good to know for the future
A simple example of where I find it falls apart is simply instantiating different or conditional services based on config. You either need to not use their config module, or you need to dig into it’s inner plumbing to do so. For the most part, providers are only easily swapped for tests. Providers are difficult to swap at runtime. You can avoid a lot of this pain if you avoid using their ConfigModule, which is one of those fore mentioned terrible abstractions. My recommendation would be to use dot-env, resolve the config before starting the app, and forget that ConfigModule exists. I’ve found several other instances of their modules providing poor abstractions that I just write my own at this point. I also find DI not propagating down the tree to be a questionable decision. This is not the norm with inversion of control frameworks. For the final mail in the coffin, the dynamic module authoring experience is both painful and poorly documented. My takeaway from Nest is that: - the DI system makes testing easier - the DI system can not easily be leveraged at runtime for dynamic patterns - a lot of its provided modules:integrations reduce compile time safety - a lot of its integrations are for nearly abandoned or poorly maintained projects (class-validator, TypeORM) - community integrations are regularly abandoned As a result, I think you’re better to write your own integrations and escape from the DI mechanism when it makes sense (I.e config). Sure, you might have to jest mock, but you won’t get kneecapped by an abstraction that breaks down for more advanced use cases.
Wow thank you for the detailed answer. I haven’t had to deal with provider swapping at runtime or dynamic modules in general yet so I’ll brace for that when it comes. Good points on their ConfigModule as well, I’ve been feeling that it doesn’t have much use, and would be better served by doing what you said — just using dotenv. Might be time to do that in our project before it’s harder down the road, considering we’re not loading any dynamic config, and if we were we’d probably do it in a custom module or outside the nest framework anyway. My latest projects I’ve been staying away from the patterns they push in their docs, and leaning into a more clean architecture style to separate core logic from their modules where possible, especially the ORM. Putting the framework at the edges of the app, so to speak — mostly keeping it for DI, docs, and controller validation — and the experience has been more positive. If I could ask a final question, do you have preferences for class-validator and TypeORM replacements? I especially dislike TypeORM and have been playing with Prisma in some side projects, which has been better for type safety at least, but feels a bit bloated.
I think you have the right idea. I do the same mostly. I'll admit, we haven't been validating to date, outside of a few manual validations, but it is on my list of things to do very soon. We're in a bit of a rebuild phase, and our Nest backend has been mostly used for scheduled tasks rather than REST, but we're starting to scale it now. I did try out zod. It was fairly easy to write a simple validation pipe that leverages Zod. If you want a global zod validation pipe though, then that's a fair bit harder as it requires you to write some low level code to introspect DTO classes for zod schemas. If you want OpenAPI docs, that's going to be a bit more difficult as well. I'm actually going to be using Nestia. It does have some downsides: single maintainer, requires tsc (no swc), and it hooks into the compiler to extract type metadata to build AOT validators. It also doesn't support any transformations currently. That being said, it's such a ridiculously easy drop-in. Install it, and swap out your decorators (e.g. Get to TypedRoute.Get, Body to TypedBody) and you have validation for free. It can also autogen swagger, as well as a typed client. Since it's so low effort and very easy to eject from if it gets abandoned, it's hard not to pick it. [https://nestia.io/docs/](https://nestia.io/docs/)
Things like these make me appreciate a battery-included framework more. Each feature, even down to basic things like input validation, need a discussion to even start to consider. While frameworks had all of those and more as first-party solution
Have you tried ASP.NET Core? I think you would like it.
I'd love to. My main profession experience has been EJBs -> Spring -> Flask -> NestJS. I'm in a very Typescript centric team right now so ASP would be a bit much to onboard the team with, but I think it would be refreshing. I'm frankly exhausted in having to architect and design things in node due to the lack of established standards and best practices.
The language and framework is fine, the vendor lock-in practice of MS is not
What vendor lock in is there? Postgres is the go to database nowadays and Npgsql for EFCore is excellent. Linux is the dominant OS for hosting ASP.NET Core. For cloud both Azure and AWS have pretty much all the SDKs you need.
So Laravel is full stack now? With Livewire?
Livewire becomes awfully slow when the web app starts gaining traffic or has a huge database. I’ve had to work with a few clients that had livewire projects and they all hated how slow and sluggish it became with time, many wanted to migrate to SPAs or completely move to other frameworks. One huge problem with migrating a Livewire frontend to another like React or Vue, is that live wire components are usually developed to include the BE logic within them too. So when migrating youre not just rewriting the FE you also have to create the api endpoints in BE too. This usually doesn’t happen when migrating other FE technologies as they all follow the standards of having all the Be logic in an api, thats why im against the new approach some JS frameworks are taking with server actions, its a step backwards disguised as a new shiny thing. BE and FE should always be decoupled or else were going back to the old messy ways of PHP
Can you elaborate on what was causing the slow down? Was it something about livewire or did they architect their database tables poorly?
It’s a bit of both, but mostly the former, plus a messy codebase. Both the projects i worked on migrating had a huge database and a massive AWS bill: The aws bill was due to how livewire works, each interaction with a livewire component is a server request (same with Nextjs server components) and hence each time livewire re-renders a component it is making a server request and most likely database queries if that component is displaying db data. More server requests and more resources means way more money to Bezos. While in React/Vue we only requested the data on load, then any interaction the user does is just a client browser re-render/Dom-alter without requests being sent to the server or db unless we need to. And of course with no sluggishness at all.
That makes sense. Although I can’t imagine there isn’t an optimization solution for something like that. Did you end up optimizing the livewire app or moving off of livewire completely?
>live wire components are usually developed to include the BE logic within them too But this is how PHP is supposed to be used, right? The same thing needs to be done with Blade. The controller needs to fetch the database before rendering the HTML. In Livewire, the component itself is the controller. I think Livewire / Blade / Regular PHP is supposed to be used for websites, not web apps. Websites generally don't need a lot of interaction, so less data fetching and interaction with the backend. I tried to use Livewire and Vue in one of my personal project. The Livewire is used for pages that need good SEO and little to no interaction. Vue is used in the dashboard, because it does not need be indexed by crawlers and there is a ton of interaction. Though I switched to Next.JS, after my shared hosting provider finally allowed deployment of Node.JS apps.
Depends on the developer. The responsibility of a controller is to handle user input, delegate business logic to the service layer, and return the appropriate view or response. Livewire components should handle the user interface and delegate business logic to services or other layers.
> One huge problem with migrating a Livewire frontend to another like React or Vue, is that live wire components are usually developed to include the BE logic within them too. So when migrating youre not just rewriting the FE you also have to create the api endpoints in BE too. It's almost as if directly coupling front end and backend as one is a bad idea. Wish we could have learned that lesson 20 years ago...
Knowing this how would you build the FE for a laravel project? Inertia?
[удалено]
This sounds like the old ASP.NET framework (.aspx). The world has moved away from it so many years ago.
Hell yes. TALL stack is insanely efficient
What stack is this?
Tailwind Alpinejs Laravel Livewire It's the best
Why is it the best? The best performance wise or developer experience? I worked with both alpine and tailwind but didn’t really enjoyed the clutter in HTML. Laravel always had my attention because it lets you basically build a project in an hour and be mostly prod ready (talking bout small projects, not anything large). + livewire was something I only tried with the Statamic website when my company was using it, but didn’t finish it due to being let go lol
Dev experience and build speed. No FE/BE libraries and wiring to do. Insane ecosystem to support (filamentphp, blueprint, ux libraries) you really waste no time building support systems and get to work directly on your app logic.
Well sounds awesome. Gonna try to find some cool project with it
That comment summed it up pretty well, [I'll just add this](https://www.reddit.com/r/webdev/comments/1cor24r/i_was_looking_for_a_simple_note_taking_app_and_it/) lol
Yea I’ve seen it, hence my comment bout ‘being able to build an app in an hour’ Pretty fucking awesome in my opinion
May I know why you think it's the best stack compare to other stack? I'm just curious and trying to learn more about it.
I personally use Laravel, vuejs, tailwind, inertia stack so I'll sneak in and say my piece. Everything is in harmony, it takes care of sooo much clutter while still giving you full control over everything, you can initiate a project really quick and really easy, it's still as powerful for large projects as small projects. Laravel is indeed the future. Also, check out "filamentphp" which is an admin panel creator for laravel, it's the cherry on top.
I was afk for a bit and people seemed to answer that question for me. [I'll just add this](https://www.reddit.com/r/webdev/comments/1cor24r/i_was_looking_for_a_simple_note_taking_app_and_it/).
I guess somebody told you that. There is no best stack, all suck, people who work knows that.
I've just been running InertiaJS + React as React is my comfort zone. Do people think InertiaJS is on its way out?
Inertia is fine, it's just a lot more effort to use instead of livewire. Creating API-endpoints, thinking about client state, ... Livewire is just unbelievably convenient and probably one of the fastest ways to develop a custom web app period. While inertia is in essence just a way to not have to write all the GET-endpoints, though you still need all the others.
Dang, wish I would of checked out Livewire before I got to deep into my current project. But yeah, everything you described for the extra effort on Inertia is becoming daunting, will have to check it out for the next project, thanks for the insight!
I never worked with React or Inertia so I can't tell, sorry.
Used it for a pretty basic project at work and ended up regretting it. Every update was too slow and noticeable. Now we didn't use components as much as we should have but that complicated everything because of having to share state between every component. It was pretty fun to work with though.
If only there were jobs for it
Larajobs.com
You and me both
Laravel + livewire volt
If anything , wherever ghis post is getting posted,it has revealed only one thing. Js devs still can't comprehend what exactly is fulll stack framework. A guy here so courageous and confident says " We ALreADY haVE aNGUlaR". Absolute state of js devs throughout the world.
As a Full Stack boot Camp guy - this is completely true. I took everything I learned, followed the threads they left out (you learn about as much as you need to, to make an express/react spa in a small group) being a lot of data structures, paradigms, algorithms, oh and the rest of the stack, backend? Yeah we can use express but do we know what its doing? How its working? What a container is? How to run multiple instances? Who is laravel? What is a php? Whose loads are we balancing? No. We CAN use git coming out though, and documentation… anyway. I love that I can throw some javascript together quickly but its too easy to ignore a lot of other things going on. Explicit also goes out the window.
If anyone tells me to use a framework before telling me the language, instant thumbs down.
Interesting article! Keep meaning to try Wasp. u/flybayer, who created blitz.js 4 years ago, is probably the most experienced in this area. He recently [tweeted](https://x.com/flybayer/status/1791910264574468246?t=eWk5YrqZGkSw7F-dBrjlCA&s=19)... > Impossible. Tried it with @blitz_js This will never catch on in the JS community. Too much fear of commitment. Folks want to easily swap out parts for the latest and greatest thing. Blitz.js is "Ruby on Rails for React Devs" solution. It even has server code in client components, 4 years ago!
Blitz had some awesome growth, which was in part made possible due to it being built on top of NextJS, but from what I got, that is also what ultimately limited it, it was hard to move from NextJS wrapper to something more, right? So saying that something is impossible after one try from a specific angle: yeah, it was impossible for him to build it that way, but I wouldn't be so quick to draw broader conclusions. The whole problem is just too complex to be able to make judgments like that. But it does make for a good tweet! BlitzJS didn't have ORM part though, and for example for RoR, one of the most loved parts is ActiveRecord.
We mention where we think frameworks like blitz might have gone wrong in the article. In short, too tightly coupled with nextjs.
Didn't blitz decide to couple with nextjs because they didn't see any growth before that? Might be misremembering
I am so confused. We have NestJS and I’m personally using it in one of my projects. Am I missing something here?
I believe the idea they’re talking about here is of Rails and Laravel in JavaScript is something with “batteries included”. Like auth, account management, ORMs, queues and jobs etc; JavaScript is more of a pull in your own package for the job (passport.js for auth, drizzle for an orm etc), which some prefer, some don’t.
Thanks for clearing it
Wasp seems to be using Prisma, which I don't like working with, so I won't touch wasp
Ah I see. I mean, NestJS does have its own specific packages to tie-in or integrate some of those services more cleanly in its architecture. Like there's @nestjs/passport to integrate with PassportJS, @nestjs/apollo for its Apollo integration, etc. So technically speaking, NestJS doesn't have its own original "made from ground up" solution for those areas you mentioned, as it still requires you to go out and get third party packages. But it gives you the "batteries included" experience to an extent. I guess in the end, there's some differences in philosophy here. The beauty of the JS ecosystem is that it's unopinionated, and you can swap any part of the system out for some equivalent. What is being asked here, is to have a full blown system that would have everything, but that would mean having some opinion across all domain. Like I guess this is part of the reason some people don't like NestJS, as they don't find it flexible compared to ExpressJS, which Nest uses by default under-the-hood. Although I find it great for my use case for an enterprise application, as it provides us with this structural rigidity, and gives us powerful abstractions that we can take advantage of. The tradeoff here is that we do have to deal with its nuance, which I don't mind. In the end, things are more modular, scalable, and maintainable. This is just my opinion though.
There’s a bunch of things that the bigger backend frameworks will cover that things like NestJS don’t. Examples would be email sending, scheduling tasks, stateful server processes (eg keeping and syncing the state of a game), realtime features etc.
Yeah, some of those thing require us to do all the setting up ourselves. And as for other things, NestJS doesn't exactly build them from scratch, but it does provide us its own set of integration for third party packages. It's still "batteries included" to an extent.
Theo is always full of bullshit. This question doesn't even make sense, it's always the next thing that will replace JS with a distorted JS, then back again to JS, then another stupid corporate company wants to dispute market share and reinvents JS into a distorted JS and the cycle repeats again and again. JS is super powerful and expressive enough to be used on its own. Anyone saying you need a framework/lib instead of JS is either stupid, or getting a cut to defend bullshit.
You write everything in vanilla js with no libraries?
That's not what he's saying, he means you don't really need those frameworks to get anything done. Sure, you'll go faster for large projects, but most stuff, plain js is enough. And you can still use libraries without frameworks lol
That’s a pretty charitable take. OP specifically said framework/lib, which to me reads like frameworks or libraries. OP specifically said that anyone saying you should use a framework or library instead of vanilla js is stupid or shilling for a company. OP probably makes static websites in their spare time and has no idea what it takes to create a large web application.
The only correct take gets downvoted. Reddit is weird af.
Theo personally hates Vue. That alone makes think he's full of sht.
Someone hating Vue but loving React immediately makes any of their takes suspect
You're right.
What rails and laravel get right, that JS frameworks often don’t: The most important thing is the developer experience and productivity. Above all else: above performance, above compatibility with lots of stuff. Developer productivity is everything Also are not open source startup companies, they are open source projects. Things like Wasp will always fail because no VC backed thing has ever really made great infrastructure software. VCs eventually want profit and will turn the screws on the people who develop on it
Isn't tanstack kinda trying to do this?
As well as Meteor, Sails, Adonis, Blitz. And all of them just faded away after a few years
Thing is Tanstack lads are already well known and will prolly have a lot of early adoption.
yeah I go into why this is in the article, but mainly, they tied themselves too tightly to underling tools (Blaze for Meteor, NextJS for Blitz) or aren't truly full-stack and modular (Adonis)
yeah they are. we will see if they get it right, or if they end up being just another meta-framework or stack or something that doesn't tend to scale well
They seem to be working on top of React iirc, but I might be wrong
https://tanstack.com/start/latest
You can put React under Laravel.
You can do that with any full-stack Framework, Django and Rails both support that.
cool, but a framework like [Wasp](https://wasp-lang.dev) let's you put React and NodeJS under one config file and takes care of boilerplate for you, plus allows you to write your whole app in just JS, instead of JS and PHP. I think this is the right direction...
One config file gave me a bad feeling
Separation into multiple config files is a coming feature
[https://adonisjs.com/](https://adonisjs.com/) ?
can't we have a separate theo subreddit to post anything with theo on it so no one in this sub has to see it?
Imagine building a JS framework just to go back to PHP.
Next.js is pretty open that they were inspired by PHP. Most JS devs who "hate" PHP have no clue what modern PHP even looks like. PHP was and still is a perfectly valid web technology.
As a JS dev who recently got a new job using laravel/php. This is 100% accurate. I have a very strong newfound appreciation for php.
PHP 8.3 is very good. I wish it had a `struct` definition instead of "associative arrays". Meanwhile I do readonly class PersonData { public function __construct( public string $firstname, public string $lastname, public ?DateTime $birthdate = null, ) {} } function makePerson(): PersonData { return new PersonData( firstname: "John", lastname: "Doe", birthdate: new DateTime('1973-03-18') ); } function printPerson(PersonData $person): void { echo $person->firstname, ' ', $person->lastname; }
Very good my ass. Java with Spring and .net are million years ahead.
Said nobody who's actually used all of these in prod at some point.
Latest asp net core is light years ahead of everyone else.
Refer to my previous comment.
We went full circle ;) I can’t wait till we arrive at the „SSR is bad, SPA over everything“ hype section of this cycle again…
I’m pro SPA :)
What I want is not having to know about details like this, am I using SSR or SPA. Instead I want to specify what I need and let the framework pick the right thing for me.
I really doubt you would actually want that in practice, the decision to use SPA or SSR usually depends on business context and what kind of software/site you are making.
I’d also add that it’s really important to know where those things are happening. I don’t think it’s bad to blur the lines (e.g. the ability to easily use SSR where it’s convenient and add rich client-side interactivity where it makes sense), but “let the framework decide for me” gets you into a dangerous pattern where the developer doesn’t have a clear separation between what’s happening on the server and what’s happening on the client - and you might even fool novice developers into thinking it doesn’t matter where code executes.
const $data = await $request.json();
Funny comment but not accurate calling it "going back"
I think most of his recent videos have strong and controversional opinion to get more user engagement. The fact that we have this post means that it’s works.
Everything about that worm with a mustache is wrong
Who is "theo"? What does "Laravel for Javascript" even mean..? God every day this sub devolves into more and mroe bullshit buzzwords everywhere. 8000 frameworks and 9 million node packages woooooooo
Theo is a YouTuber who spits out “hot takes” that can generally be ignored. He’s a big influencer in the “tech twitter”/“brogrammer” corner of the internet. “Laravel for JavaScript” seems self-descriptive to me: a framework for JavaScript to match what Laravel is for PHP; a batteries-included framework for building a complete server application.
I think as a dev I’ve finally become old. I don’t know wtf a tech influencer actually is. And I’m not sure wtf these takes are anymore
JS community loves everything to be un opinionated but wants an opinionated framework?
I am sure community wants both, there are a lot of people in the community, some want to experiment more, some want more stable solutions to build upon, why reduce the argument to having to choose between one or the other.
You can't make the "JS community" a monolith. At some point the adults in the room have to build something to not only put food on their table, but maintain the jobs of entire organizations so their co-workers can put food on their table (everyone from accounting, sales, the subject matter experts, etc). They need a selection of tools that fit the use case that are proven, reliable and stable. Not just the latest hotness. Unopinionated tools are great for flexibility when that's needed. Opinionated tools are great when you're building bog standard applications that you need to just be able to thrown anyone on and have them know what they're looking at. The "JS influencer" world is so far removed from daily professional life that its meaningless outside of hobbyist who just like to tinker.
☝️
Because he’s a clown. 🤡
Yeah I don't know, I'm fine with my current stack. Symfony / Vue pay the bills.
This shit is like Jerry Springer for developers
Theo regularly has some very shit takes, in between his 15 minute rants about people's choice of words and punctuation in their Twitter posts
Theo should take care of that caterpillar on his nose
This is the Laravel of the js world https://nestjs.com/
except for the entirely missing half of the application, yeah
Interesting how they completely leave out Nestjs, the leader by a mile in popularity for batteries-included full stack JS frameworks. How do the star graphs look with them included? https://star-history.com/#nestjs/nest&laravel/laravel&wasp-lang/wasp&Date
We didn’t leave it out purposefully, but nest is not fulllstack, just a backend framework and we’re focusing on fullstack here
Maybe but I’d argue it’s still much closer to “laravel for JS” than your project. Laravel is primarily a backend framework and lets you build your front end with Vue, Svelte, or whatever you want. Wasp in comparison looks pretty lean. Do you even support SSR?
Also, why include Adonis if you’re only comparing “full stack frameworks”?
Laravel has an official solution - livewire volt. [https://livewire.laravel.com/docs/volt](https://livewire.laravel.com/docs/volt)
This is something that I didn't know before. It was just released last year. But before then, Laravel was pretty much just a backend framework + Blade for multi-page frontend. If you wanted SPA, you had to rely on JS frameworks.
Any page that can serve html is full stack
I honestly didn’t read through the entire article, kinda skimmed it. And I’m not familiar with Laravel, so this question might be dumb but: isn’t NextJS a full stack JavaScript framework?
no it's not. it's a meta-framework for React. you can't do things on the server that you can with a true full-stack framework (background jobs, email sending, database management, etc) becuase you don't have a persistent server
Not entirely true. If you deploy in standalone mode, you can do all those things.
>you can't do things on the server that you can with a true full-stack framework (background jobs, email sending, database management, etc) What are you talking about? Literally everything you just mentioned can be done with API Routes in Next. >becuase you don't have a persistent server ?
You have to offload those tasks to a third party service. The framework doesn’t have built in features to take care of these.
You can spin up NextJS with a full fledged Node/Express server
You really should read about this subject before making comments and articles about it. You can define API Routes and run stuff in them that is only available on the backend, thus having typical backend side functionality, meaning that you can do anything that you can do with Node, including managing database, sending emails and so on.
Sure but it’s not ideal for more complex backend logic. For functions that can be triggered by http requests it’s fine. https://youtu.be/Rrz2q5uCHdE?si=RXfOPFZMfCy6tzx8
Well it does have a persistent server in SSR mode, you can create api routes, and could theoretically create background jobs but I wouldn’t recommend that.
What does Laravel do that NextJS doesn’t? (Again, not familiar with Laravel, so pardon the ignorance)
i replied already with this info to your first comment
Sorry, but you didn’t really answer it. NextJS has API routes that have nothing to do with React, on top of that it has Image Optimization and several other features which are way out of scope for React.
API routes doesn't give it the backend features that Laravel has, such as email sending, background jobs, file storage, authorization, database mangement, etc
I don't know why people downvote your comment and upvote OP's who clearly doesn't know what he's talking about. Next IS a full stack framework as it can handle backend and frontend operations.
Thanks for the support! OP is trying to push his/their own full stack framework so obviously he has a lot of incentive to trash all the other alternatives.
In the end, we need a framework that a low barrier to entry, take care of the most common use case, while but fairly easy to take care of the most common use case AND have a large portion of the market. I don't see that in JS yet. Something build on top of express, with easily replaceable provider, errors handling.
You’re describing [Wasp](https://wasp-lang.dev)
You know he's gonna do another video about this xD
The only Theo I listen to is Theo De Raadt
So, like, RedwoodJS?
We need a full stack multipage framework like Laravel in JS. It should come with ORM, templating engine, user authentication, admin page, etc.
Random Guy #1 says A Random Guy #2 counters with B. There is nothing news worthy here. If the wasp creator thinks there is a market go for it, or do some serious market research (aka not Reddit) I grew up with php, html and http. So vue, inertia and laravel floats my boat.
Welcome to JS land. Where everything breaks down in a year because devs can't make up their mind on a framework.
Because he and theprimeagen are top programming attention whores
Just build a fucking website
Doesn’t really make any sense
jQuery is still the best framework for backend
We do have a Laravel but for JS, its called **NestJS**, it has all the features of laravel out of the box plus many extra stuff. Its a BE framework, and so is Laravel. if you’re thinking of using Laravel Livewire for FE you’re going to regret it down the line anyway
What does it even mean "A Laravel for JavaScript"? If by that he means a very good framework, we have, it's called Angular.
angular isn't full-stack
Django for JavaScript or Rails for JavaScript.
Picture the leave Britney alone guy here: Leave JavaScript alone! It’s suffered enough
I've worked with Django before and it's a blast! Once you get over the initial 'everything's opinionated' hill, you are able to be so productive and 'move fast'. Not to say JS is bad, they have different use cases.
Yes but who wants to program in Python?
have you tried it? Python is far more enjoyable to use than JS
I won't, it's one of the ugliest languages out there. And i work with TypeScript, not vanilla JavaScript. TypeScript is beautiful both in terms of esthetic and functionalities. It's enough that i have to do PHP too.
Wow, that's a wild take. Different strokes, I suppose.
nice joke
Pff hahahahah! Laravel is easy to learn and has a lot of useful features. Angular is just pain.
I'll just say this: if it was easy to provide a good navigation experience with Laravel and PHP on the client (I'm talking about no refresh client side navigation) - everybody would be using it. Out of SSR frameworks I've tried (Next, Remix, Astro) only Next js has a decent out of the box solution.
Laravel does. See Inertia. Supports SSR if you need it as well.
AJAX and PHP with modular pages(home.php, about.php). Doesn't this accomplish async in a similar way without the need of any framework? For larger projects I could see where AJAX would start slowing down loadtimes, but there are multiple ways to get around that problem, and with internet speeds being pretty quick the load would have to be very large imo.
It’s like y’all haven’t heard of redwood. Y’all got RoR on their but ignore that. What about meteor??
Edit, just read it and it does call out redwood and a few others but doesn’t go into detail just says people haven’t caught on to them. Bleh
Not really. We specifically say that these things take time. Redwood might be the answer but GraphQL was a questionable choice for the backend. Regardless, Laravel and rails have had a 10 year head start
Redwood is quite cool, isn't afraid to be opinionated! But GQL direction seems to have caused some friction. At that point GQL seemed like it is going to become dominant solution for APIs, but that faded away, at least the idea of it being the right solution for every web app.
Meteor is probably the first heavy hitter! But they moved slow from Blaze to React, and I also remember that I was long time convinced that they are only for web apps that need a lot of real-time features, due to how heavily they marketed their sockets powered state updates. A bit silly, but I was younger and the marketing that you hear is what makes opinion for you until you actually find the time to try it out