I made a mistake. I referred to Ukraine as "The Ukraine", not knowing this phrasing was meant to refer to Ukraine as part of Russia. I fully support Ukraine's right to independence. It's not much, but I donated another $1000 to Ukraine's efforts to stay independent 🫡
My 2c - people in javascript seem to be terrified of being opinionated. Every framework has to work with every library. Everything needs adapters. Everything needs "options" that must be decided first. What I want is a no bullshit framework that just has everything I need to start adding value from day 0, and has the longevity and backing to maintain LTS.
Then go build it! I'm sure it's never been tried before! But don't let it be a surprise that people won't adopt it in the first 4-5 years until it's deemed "stable" and "production-ready".
@@dealloc adonis js is basically a laravel porting and has been ready for years and is barely known let alone used, thats too bad since the dev experience is crazy good
I have a top level comment on the video explaining why I think it is, but generally, it's just a package management issue that the JS world hasn't come together to figure out a good solution for. No standardized dependency injection and the perpetual threat of circular dependencies. A monolithic single framework will never really be preferable as long as the dependency injection in PHP doesn't have an equivalent way of working that doesn't break static analysis tools. Same issue with Django, where you can smell the history of PHP in it's design, but is such a pain when it comes to static analysis tools.
@@sharkpyro93 i'm disappointed I did not come across this... I'm hip deep in NestJS right now so too late to back out. Will keep it in mind next time, thank you!
Having a solid stable framework like Rails, Laravel or Django is not equivalent to having 100 bits and pieces of sort of frameworks maintained by a small group. A web framework must solve a consumer problem. The client wants an ERP system, if I'm a ruby dev I know it's Rails what's needed. If I'm a php dev I know it's Symphony I need. If the client wants a basic CRM or a CMS I know I will need Laravel or Django. The frameworks I mentioned are stable, reliable, well maintained, has support and focused innovation. I don't think a js dev can make a decision like that simply based on the consumer requiement. Having too much to choose from is not always a good thing
Exactly. Not a ruby/PHP guy here but from my experience in big enterprise, a bighuge percentage of solutions always go for the battle tested options of Spring Boot - and some others for Quarkus / Micronaut / etc. Nobody wants to hedge a bet on something that has not been out there for YEARS and has proven its worth and is still alive and "hungry". There is a reason that React has become the "nobody got fired for buying IBM" of frontend: up to fairly recently, the thing was stable and simply augmented upon itself. Now that the META team and the Vercel team are too intermingled, perhaps its time to start looking elsewhere, esp. if your frontend is JUST frontend and the backend is JUST backend.
I think Google has made this stability issue for whole of JS ecosystem. At one time around 2015 it started to settle in JS ecosystem but then Angular 2 came, then it broke everything. I then switched back to Laravel and still sailing smoothly with laravel ecosystem. Never went to JS waves.
I understand these points but we should acknowledge that the the Javascript Fatigue is a real thing. I am working with javascript/React for years now and I love learning new stuff but needing to relearn things each 3 years and build apps differently is really tiring. Not keeping up has a career cost! Knowing how things are built and being able to discuss it is part of the job interview. And new projects that are in general more interesting will start using the latest way of doing things. So if you want to join those projects you have to keep up. I do agree, the beauty of the JS ecosystem is this ease to build things and innovate, but it's also what make it hard to keep up with
"needing to relearn things each 3 years and build apps differently" I cannot stress this enough: you don't need to. Whatsoever. Most orgs aren't adopting bleeding edge JS tech.
JS has many issues which lead to never having something as comfortable as PHP. One of them is the lack of focus in the community, no solution is able to take off for long because everyone thinks "I can do better" and proceed to create their own stuff. And no one wants to invest into a framework that has no future.
As someone who started doing vanilla PHP, then Laravel, and now does Javascript (i.e. NestJS), I disagree with this video. Having a fully fledged framework like Laravel available is incomparable. Laravel is amazing and if my workplace and much of the world wasnt focusing on Javascript based approaches, I'd still prefer to stick with Laravel. The developer experience is unbelievably good compared to JS. Let's take auth (login and also permissions). In JS, you need to pick the auth framework(s), integrate them with the rest of the application manually, and usually, put some fairly considerable thought into how it works with the rest of your app. In Laravel, I would literally just install the relevant package, and boom, functionality is in - and easy to use as well with little to no thought. (Take the spatie laravel-permission addon for example). Let's also take database event auditing as another example. There is literally an addon you can just install for that. And boom, audit events are logged - including who did it. In Javascript approaches, again, there is no equivalent. I will say that there is a lot of flexibility that comes with the way the JS ecosystem works, but we absolutely miss out on all these amazing plug-and-play tools that come from the stability of something like laravel. The amount of times i've thought 'we should have a NestJS starter kit with DB + auth + etc at my work' is too many times. Meanwhile with laravel you just HAVE that 'baseline application logic' ready to go (and plug in a few addons while you're there).
problem is NestJs heavily inspired by Angular which Js Devs love to hate so basically it doesn't exist I bet if it was React/Jsx inspired, this video would have a different tone
Since you mentioned NestJS, I'm curious what's is your opinion on it? you said it's just lacking on those plug and play features, do you think in general its pros outweigh the cons? For me I disagree on a fundamental level with the approach they took. DI and AOP in a dynamic/prototype-based language like JavaScript is really uncalled for. Feels like they trying to bring the Java out of Javascript. And for a number of reasons it's hard for it to compete against popular web frameworks, or even other frameworks within the JS ecosystem itself.
i hate php but i completely agree. at work we use this framework called loco which is a rust framework based on ruby on rails and it's also great. the js ecosystem feels like the wild west and it's also very easy to use bad patterns and write messy/unmaintainable code because of the lack of opinions. flexibility has a lot more disadvantages than advantages in my opinion.
Same thing with Rails, we have devise for user auth, you know how old is this gem? 10+ years old and still alive! It does authentication and signups form also send email to confirm email address, like you said, when JS is banging their head against the wall related to ORM, all these framework got it solved 10 years ago, and it work perfectly today, for audit we have Papertails gem, it's plug-n-play you add it to the model and it just works
@@smoked-old-fashioned-hh7lojust look the ORM mess, like Node has 4 ORMs and the community keeps changing it, like Rails active record is the same for a decade, all the edge cases you can think about they solved because it's super old haha
The fragmentation of the JS ecosystem and the sheer amount of third party libraries is why it’s bad without even going into the quirks of the language itself. It’s not okay to have dependency trees that go into thousands. I would much rather use a language where the community understands that third party dependencies are to be used sparingly.
I don't share the view that only JS allows you to make a "customised framework" using only what you want from existing packages. Laravel is also a giant collection of components that we can use individually to create our application infrastructure. You only have to look at the vendor folder created with a new Laravel project to see that there is everything you need to create your solution. The main problem, for me, is that if there is no common solution adopted by the market, it will be more complex for those entering the universe of a company that has chosen a set of solutions for which I only know how to use half of them, because in my projects I used other types of solutions for the same purpose. When a company is looking for a programmer with experience in Laravel, anyone who knows how to use Laravel is immediately ready to fill that position.
But you are suppose to be a DEVELOPER that knows Lavarel, not a Laravel developer. You are suppose to know how to handle databases or emails without Laravel too.
@@neociber24 Let me be a little clearer. I know how to send emails with PHP's mail() function, or using PHPMailer. I know how to log following the PSR standard, or how to use Monolog to speed up the process. I can create a PHP class to communicate with MySQL via PDO. That's not the point. If a company is going to hire someone for the team to continue a project that was built with a certain stack, you certainly won't be the best person for the job if you haven't mastered that stack. The whole thing about choosing the best options to develop my projects is OK. But if I'm going into a team job, with projects in progress, and I'm not used to using the stack that the team uses, that's going to be a problem, because companies aren't very willing to invest their time in getting you to adapt to the team's stack. That's why many companies are looking for programmers who have mastered Laravel, and not just pure PHP.
@@neociber24 Yes u are supposed to know the theory behind these concepts and how they work, not the different versions of syntax! There’s always WASTED time in getting to know how the new toy works
I'm a massive, massive fan of Laravel with Inertia and React. I also love Laravel's grammar and the fact that it gives you pretty much everything you need in an API or service, NPM is fantastic but it's much easier to get into dependency hell.
Dependency hell is a real thing when your app gets just a couple of years old. And it certainly does not help that NPM install by default makes you lock into extremely specific versions of every package.
@@05xpeter Peer dependencies allowing the same versioning as regular packages was a mistake. I've been burned so many times and forced to force install packages due to lazy devs just saying we should use latest peer dependency. Suddenly a package has an update with a breaking change, they force latest version, now everything breaks. There's also the fun time when you want to update one package, it requires latest, another package requires a different version. Both versions work, but one was decent enough to add a range of tested versions, the other was lazy and just said latest.
@@05xpeter We have a biggish NextJS app that’s less than a year old and I’ve spent the past two weeks in dependency hell. I added a pretty big feature and it INSTALLED THE ENTIRE OF REACT NATIVE. Even after cleaning that mess up there are some Jest issues where “the environment is not configured for act”or something, which is apparently is caused by a version conflict between React and the test library, but… no idea how to fix it. And even after all that a recent React change apparently triggers a bug in next/image. It’s a nightmare.
Adonis is probably closest to Laravel for JS (TS), and it's excellent. I use Adonis whenever Next + Vercel doesn't make sense. APIs to glue various systems together, puppeteer & pdf templating, CRON jobs too big to be severless, etc. The ORM is great, the templating engine is decent, and support for everything from redis to s3 to mail is baked in and works flawlessly. Beyond that, it can be quite modular. IMO, it's also the best option out there if you want fullstack TS HTMX.
Honestly, it ALWAYS boils down to priorities. If you need ultra high speed parallel stuff. Maybe JS or PHP are not the best language. GO may be an option. If you're a one man start-up and you need a shit load of things, maybe you don't want to integrate 500 different parties and integrate everything yourself - then choosing PHP with laravel ist a perfectly fine decision. If you need to move kinda fast in a team and want easy re-hiring, Typescript is perfect for the job. It just should always boil down to a set of priorities.
Inertiajs not mentioned at all for some reason. Also : 20$ for hosting 20$ for auth 20$ for database 20$ for queues 20$ for mail 20$ for rate limiting Yeah nextjs ecosystem is a PERFECT solution to own and control nothing. It is a maintenance dream sprinkled with some good old premature optimisation.
I had an experience with serverless queue service and it was truly a nightmare. it was in down time to time because of its cloud provider (cloud over cloud) and even more my messages got stuck or lost. The price of this decision was too high.
Hi there, Ruby developer and now Elixir/Erlang dev here. Before I start, please don't kill me-just understand my context. So... here we go... After years of doing web development (around 15 years), I've seen the JS community taking off. Even before the React wave, there were a lot of frameworks and tools. For a JS developer, landing in a new job was crazy because once a developer learned and mastered a tool (framework or library) in JS, in the new job, they had to re-learn everything again. This eventually caused what we call JS Fatigue, leading experienced developers to exit the JS community. As you grow older, it gets harder to learn new things. Many will say, "Isn't that the goal of an engineer? To stay updated and learn new things?" And I will say yes, but new problems, not new tools. Consider the average age of a JS dev-most are in their 20s and maybe 30s. Eventually, JS Fatigue will reach you, even though it seems more stable now than in the past. Also, another little rant: why is it the only language without any proper standard library? Why does doing basic stuff require a 3rd party package?
I'd say learning doesn't get harder, but learning the constant reinventing of the wheel is definitely exhausting. Why learn jquery, angular, react, svelte, solid, next, nuxt, remix, vite, etc etc when if you want to build product, you can rely on all batteries included frameworks that are tried and tested by large companies like Stripe, GitHub, Shopify, etc. As an older web dev, I'd rather spend my time learning a new language, game development, a different paradigm like FP, etc. Want to build a saas product quickly, with standards and conventions that have been worked on for over a decade? Then just pick an all batteries included framework and focus on building your product. Don't waste time learning about all the different toolkits, "meta" frameworks, and an infinite amount of packages only to fall into analysis paralysis and get nothing done.
Nuxt is kind of closest to Laravel in JS. A lot of primitives, a lot of modules from core maintainers. You can do almost anything out of the box, without spending time to deal with incompatible libraries.
A certain part of this is a bad info - the mentioned ecosystems definitely have their fair share of smaller frameworks. PHP ecosystem is especially rich, from Symfony, to ReactPHP to whatever was the name of that static one that used to be the fastest ttfb in the world. Also, most of these, if not all, existed during and before the Angular era, whereas Theo mentions only Rails. Don't let me start on Java. And it is super duper common to play around with the runtime models, much more common than in the JS world (although that is changing). I think that is where the answer lies - all of these had 10-15 years more to develop, and all of them have more freedom to fool around with the execution model, JS ecosystem is fragmented and often can't pick a lane. This can be good, as we end up with a lot of products and components that are industry leading, but its bad side is that it often feels like our job isn't coding and delivering, but instead figuring out how pieces work together and which pieces to pick.
Yeah backend framework has their stuff stable for years(Mailers/Database migration system/good ORM) and it makes the development easy and fast, like install one lib for this framework and you get auth/basic admin dashboard/audit logs and soon on, with Node you need setup everything everytime and all the time a new library came up you need to integrate or replace, it's a messy environment
I'm interested on your take on how this affects the devs who spend 1-2 years outside the JS ecosystem doing other things not living and breathing the JS coding news. Having myself included in that group I see myself always doubting each and every library decision I'm making thinking that is this gonna be outdated in a year or is there already a better alternative. In Laravel/Rails/Django land the "gotcha"s are documented and you can find workarounds, or then have those fixed by a single pr. But in JS ecosystem the answer is quite often "just change the library". But how do I then know if the other library can accommodate the other features I was using from the last library
I don't need options, I need sh*t to just work. I'll set you up production ready Java Apps in no time. Meanwhile the average React experience I made myself is that something hasn't been connected to something else as it should be and I get ungodly error messages that leave me alone. The startups don't use the JS framework cause they get started faster, but because they don't know better (in most cases I've seen)
"I'll set you up production ready Java Apps in no time." Sure buddy 😂 Java/Spring is not as bad as JS world but it's definitely no Laravel/Rails that's for sure.
you shouldn't be ashamed--it's ridiculous, that's the word you're looking for. Somehow it was never acknowledged that it was ridiculous when people where writing all of that boilerplate code back in the day smdh.
You're correct but remember, the all in one frameworks are the best thing for new developers. It makes it easier to quickly learn the important things quickly and later refine them with experience.
Not to mention that a junior dev that you need to quickly get through some basic ropes and start doing even the grunt work has a much safer place to do it inside an all-in-one heavily opinionated framework - and actually write some decent-ish productive code.
@@PhilipAlexanderHassialis sure thing I already trained people on Rails and it's quite fast for them to be productive, yeah they don't know much of Ruby at start but with time they become good devs, but with Next, I don't even know where to start is so much to drop, it's crazy and the libraries changing all the damn time
not only new developers, old developers too. Most projects don't really require the modularity js backend land imposes that's the truth. Theo is coping.
Did you really say "no other languages has so much full stack solutions" ? Omg. PHP alone has 5 very good fullstack solutions along those 2 are the most solid and very known Laravel et Symfony, that 99.99% of the photo devs have heard about. The 3 others being YII, Codeigniter and CakePHP for people who have a bit more experience. In the JS world I doubt even 20% of people know about the 3 your just mentioned. So before making those kind of bold statement, please do some research. In the JS world there is no fullstack clear winner because the JS ecosystem is way more too prone to hype than other ecosystems. Having mainly alternatives or options can be good but in the JS world we've passed the "options" phase, there's just too much stuff.
If you google search most popular web frameworks you get at least 3 php frameworks in the top 10. These 5 php frameworks serve different purposes. Symphony is for large erp solutions and laravel is for common cms like apps. All the innovation focus on improving the areas they're specialized for. That's the problem with js. JavaScript has too many stuff going on scattered among the community without the focus on specialized innovation, and no one is actually solving industrial problem. Everyone's like, showing off this cool thing they can do with js or trying to patch up some technical flaw in someone elses framework. That's not very meaningful innovation
@@icemelt7ful that's not the point of the video at all. And what you just said is awefully wrong since InertiaJs came out. And actually, even with just Vite, using React, Vue or any other frontend framework is more than easy if you've learned who frontend and backend really works. The issue is, because of FW frameworks and API-driven frameworks, a lot of devs don't even know basic web principles anymore. Now when you say "don't have much control on the frontend", that's actually the case for ALL backend framework by definition, because the frontend is executed in the browser. Things like Next, Nuxt or any SSR based framework don't give you control on the frontend either, it's the frontend framework that does. Those frameworks only makes it to be rendered first in the backend as a strong, but no fronted code will be executed, it will be hydrated and executed on the frontend later one.
💯💯💯 The JS world is hyped, and Prisma is hyped even though it doesn't have some essential features like TypeORM has. However, now Drizzle has come, and many companies that chose Prisma will have to maintain it for the next 3-5 years. One more difference between PHP and JS developers is that the PHP community built really good backend ecosystem frameworks and didn't touch the frontend. In contrast, the frontend community built poor frontend libraries and is now trying to build a good backend.
The "hype" take is a poor argument. There are 2 types of people in each ecosystems: Those who hype tecnologies and those who build stuff. In RUclips and Twitter you mainly just found the hype. Because a framework comes each week doesn't mean a company is rewriting their website each week.
I am a Linux user, and this is what I think when I hear about "ecosystem fragmentation being a good thing": both Microsoft and Apple enforce a one-size fits all solution, Linux is fragmented AF. Now, who has more OS market shares between the three? Don't get me wrong, I'm always the first to push for keeping projects up-to-date with latest updates, but I also have to wear an administrator hat, and be frustrated that we still need to manually integrate authentication to the n-th app we are creating. For what is worth, I think Astro could become a Laravel equivalent. It's integration solution for various components is very promising in that sense. Next.js could also become as such if there was a similar integration solution (e.g. swapping React for Solid, or Vue, etc.) because it already has a solution for server actions. In short, modularization may be good, but if there isn't a Laravel equivalent, then there can never be a popular solution such as Rails or Laravel.
If you consider all computers Linux has the market share and it's not even close. The flexibility it gives you is just what's needed for embedded, server, phones, and all these other use cases
@@niamhleeson3522 And which are the most installed distros for servers? Do you see a lot of servers running Arch? Fragmentation is good, but too much fragmentation isn't.
Remember Linux pre 1999 when you had to compile every package and solve the dependencies on your own? That's the js ecosystem now, Laravel is like the Debian/Ubuntu experience after 2010 where packages are made to work with each other and you can mix and match any service or app
As someone who doesn't know much about web dev (and doesn't really care to tbh; I prefer low-level stuff), I remember picking up JS when I was first learning to program. There wasn't anything inherently wrong with it, but as a new self-learning beginner, the number of options for how to do things was overwhelming. Add that on top of JS's already confusing syntax rules, and you get a very unpleasant beginner experience. While the code might run easily, you stand no chance of figuring out the errors when things do go wrong. That's the only issue I had with it. In my opinion, JS should not be considered a beginner language, but it is frequently treated like it's the *best* beginner language. I think that's what it boils down to for me. You can do a lot if you know what you're doing, but it'll confuse you more if you don't.
the javascript community is like Honda Civic owners they love it cuz they can mod it till infinity... but some of us rather just buy a AMG Mercedes Benz and call it a day 🤣
8:39 “and the doc that your reading is less than 5 years old” While I agree with the inverse of this statement, I feel like your statement is flawed here. One of the benefits of the all-in-one frameworks from other languages is maturity and adoption. Sure they have updated docs but a lot of JavaScript projects and frameworks have scattered adoption and are very young (even for svelte, I think one of their major releases and hype peaks was in 2019, just 5 years ago). If you’re new to the web dev scene, it probably is harder to tell apart the frameworks that are hype with no substance and the frameworks that will last.
I desagree on this one. JS/TS needs some type of ruby on rails that dictates a standard to build a good quality truly full stack apps that can handle more than the trivial complexity on the backend. I'm not saying that the backend should be written in JS/TS, maybe it can be go, python or whatever but we are lacking that all in one winning default stack that everyone can use to build and ship fast without headaches and that we can be sure that in 5 years it will not have gone out of fashin and we will be forced to move to the new thing.
To me, it’s testament to Laravel that it’s so great that it’s regarded as the main go-to framework for a language. JavaScript having multiple ‘frameworks’ just shows they’re all not good enough to suit everyone’s needs.
so-so feelings about this one. i think you're skimmin over one thing that is quite nice about the "laravel" approach or in my case Django mostly. it's been solid, battle tested, reliable for many years. it's modular too so I can plug in different auth-systems for example. But I dont have to have the headache of constantly looking for the right choice. The trade-off obviously being the inertance that it brings. Django for frontend is basically dead for anything bigger than a two-minute mockup. But for the backend, the mixture of ORM and Auth being baked in and working worry-free is a plus that i don't see so easily with any JS solution.
JS has many issues which lead to never having something as comfortable as PHP. One of them is the lack of focus in the community, no solution is able to take off for long because everyone thinks "I can do better" and proceed to create their own stuff. And no one wants to invest into a framework that has no future.
Switch to new Language that provide all stuff like using PHP because Laravel is not a best deals. You need to maintain 2 language because all we knew, we still use JS as a client too
@@ngaji_it And what's wrong with writing your app using PHP and JS? PHP and Laravel are stable, fast, well-documented and very much modern. So I don't see your point. The OP should go for learning PHP!
this is probably bad advice but php is cool because you don't really have to learn it straight. just start doing stuff with laravel or kirby or even wordpress and you'll pick it up.
@@ar_xiv and then you will be stuck with a bad language that easily breaks and is difficult to debug, while also being painfully slow to write code in (PHP vs any modern statically typed language like Typescript)
There is a big problem with saying people can stay on old versions of stuff, namely it will keep getting harder to find people with experience. Keeping CRA with react class components around for 10 more years and it will be more difficult to find devs than it is for cobel code bases
Yea but the standard library doesn't (and shouldn't) provide all the things you get with Laravel. It takes minutes to start Laravel projects with great functionality, and you get all the batteries included.
@@ardavanansari it doesn't provide all things but everything is built on top of std library so it works seamlessly with each other. we don't need adapter bc std lib connect all it. Lets say I have made auth lib in js I have to provide a adapter for every framework but in go I just give net/http Handler and works with every library.
@@abhinavadarsh7150 absolutely love that about Go. I just wonder why there is no popular batteries included framework written in Go (which uses the std lib as much as possible). I'm thinking of writing a rudimentary Laravel equivalent in Go, but the community really dislikes using anything outside the std lib.
While the modularity of JS is amazing and allows you to truly create and compose anything you want together it also comes with a great cost. Stability just isn't there as theres too much flexibility and the library probably didnt think about your use case. Also these libraries often depend on other libraries so when it comes to upgrading it's a very painful experience
In PHP land, we can also build things without laravel, pick and choose components/modules that we need. The most popular framework to do that is Symfony (which laravel builds upon), but you don't even need it. There are also Frameworks like Phalcon that runs as a php extension, so you get C-like performance. One of the great things in PHP-land is actually the PSR. Which has come up with guidelines for not only coding styles, but naming conventions for auto-loading and interfaces for common core functions like Logging, Request, Response, Http Clients, etc. So if your projects/libraries follow the PSR standard, its pretty damn easy to switch components and navigate around because there's a standard to follow.
Agreed, mostly. Laravel only requires about five files in a project to run, and be booted from a plugin in another app. Personally, talk of performance in interpreted languages is moot unless you don't have a database or external service to integrate with, so I think of Phalcon as existing to address the wrong problem. It's doesn't bother weighing of business priorities + cost + maintenance + impact, etc. We built a successful company around an app I built Phalcon and I was hiring, I made the decision to switch to Laravel, based on the idea that I can't nearly guarantee support will exist for it in ten years, nor that developers will want to imagine themselves working with a framework they haven't heard of, and at the very least would likely not help their resume. It also wasn't as easy to set up as vanilla PHP with common extensions, and the community was way smaller. Turns out, within that year, the libraries I was using for API integrations required a newer PHP version than Phalcon supported, and I would have had to switch anyway.
@@stevenhorton8604 I just mention Phalcon to let people know that it exists, wouldn't really recommend it for anyone lol. It was more relevant in the PHP5 days, its pretty much pointless now. Laravel + Symfony will work for 99% of the cases. Want some performance boost in a certain area, can write a micro service using swoole; which I've done before. Could I have used something else? Yes, but I just wanted to give swoole a go and it was fun.
I agree with Theo. JS does not need a single-most-popular-framework, and some of us who at times would like that to be so, need to learn to appreciate the differences. That said, I also came here to sing my praises for Symfony, although, you've done a better job than I ever could. Kudos!
I'd say the Nuxt ecosystem is probably the closest thing right now to the "Laravel of the JS world". Think about it... Laravel was the first major framework to endorse Vue because of it's similar philosophy. Vue and Nuxt have always been about simplicity, elegance, low barrier to entry, opiniated but still flexible enough for the majority of use cases, and they've always involved the community and their feedback (all things that React isn't and never did). They've also recently been really focused on creating tooling for the JS community, not tied to just Vue/Nuxt: Vite and the whole UnJS server toolkit including Nitro.
I think you touched on this, but also it kinda flew by. Laravel is so different in this space because it hasn't missed on a lot of things it tries to do. So you mentioned the fact that your T3 Create App thing recommended a DB ORM but through learning you actually don't like the one that it is recommending hence you're using another. But with Laravel, that doesn't happen. Because it has and always will ship with EloquentORM, and if you don't like that, it's all built with composer so has support for Doctrine or just raw dogging SQL queries and doing your own thing. Like, the examples you gave as to how easy it is to swap out with JS, affects all package manager based languages? I think the question still remains, why doesn't JS have a Laravel? And for better or worse it's because the vast amount of people I speak to don't use JS on the backend so it makes no sense to build one. Hence why you get these weird solutions that always have drawbacks. Btw, the last 3 minutes I really didn't understand, nor get why you brought up when neither is unique to any language, which you state, but then state it's why JS gets funding because it has better traction when those things aren't language agnostic. Laravel legit has about 40 other products which have been cut off as businesses in the PHP community. Again, this isn't JS specific and I really don't know what you're talking about here. Perhaps I'm misunderstanding. Apologies but this video has missed the mark for me personally.
As primarily a Laravel developer, my experience as a relative beginner using Nuxt 3 on Cloudflare Pages is that it comes pretty close in typical use cases.
The real truth is that client side SPA apps were a mistake, and the HTMX,/Hotwire/Livewire,/Liveview approach will win in the end once everyone realizes how easy they are, and once businesses realize how much faster they can ship features and reduce staff.
Laravel's core is kernel and follows the UNIX design philosophy pretty well. Only about five files (classes or modules) are required. You could have Laravel events signaled over standard pipe to a JavaScript code being run within a library built in Rust within a Python app through pyo3. I built a Laravel app that uses both React server side and Client-side because Laravel's ORM and routes are easier for me.
Thanks for being genuine with laravel, sure js is great, but Laravel is pretty awesome, and the fact that we can use any UI framework ie React or vue or svelte in Laravel, just makes a super awesome framework
As a JS constant user I dislike maintaining JS projects, if you don’t keep updating your packages you will have security issues eventually, it you do you need to upgrade multiple different packages being updated at multiple different times, deal with all types of breaking changes, major NodeJS upgrades, etc. These updates are much easier to be done in those full blown frameworks like Laravel, Spring, and even Adonis and others since they own more of the ecosystem. I am personally getting tired of maintaining JS applications and considering using some of these other solutions more often
6 years ago when I became a full stack JS dev (I ended up going back to jvm land for my sanity and that says a lot) it was obvious that enterprise software should have NEVER been built using js in the backend. It's insane how fast libraries become deprecated and then you can't just update to a point release to fix it you have to upgrade to a different version with dozens of breaking changes. It's ridiculous.
Are you old enough to remember that P did not stand for Php originally? I'm old enough to remember "Matt's script archive", a bunch of badly written cgi-scripts in Perl4, full of security problems.
If this is a walking-stick-measuring contest, my first server-side web code was CGI in C for CERN httpd, and I was SO happy when Apache came out. I wrote my static site generator with m4 and sed, because I didn't have enough disk quota to install and compile Perl.
@@tomgidden Wonderful times, back when WWW was just one contender for the backbone of Internet hypertext, and things like Gopher and WAIS were in some aspects better...
It is also very easy to exchange components in PHP. The reason why Javascript Devs don't switch to Rails or Laravel is not because Javascript has an advantage and would be easier to compose. The reason is simply that they are Javascript Devs and want to stay there as long as there are no compelling reasons to switch.
Symfony is on par with laravel. I think frameworks should be like astro. Pluggable view layer. Templating in whatever framework you want. SSR via wasm. Then the BE can be whatever and the FE is in a web native language.
The way you described the js ecosystem was how the java ecosystem back in the day - before spring won for the youngins, java used to have a new MVC framework every week too. Soon, javascript ecosystem will normalize too. in fact, you can feel it right now with React. Why learn Vue or Svelete or Solid when you're already productive with React. The more the community moves to something like Nextjs, the more people will just a one stop shop for everything. It's the same thing for Spring and Sprint Boot. Spring was very modular. Once people started just using Spring Boot, nobody used Spring modularly anymore. You're now in Spring world.
Java was never like this, there were always "enterprise" options besides Spring that you could just learn and get a job. Not even close to the same in js land. JS land is anarchy.
Theo stated: "This video has attracted a uniquely high number of people leaving dumb comments before watching the video. Try to not be one of those dumb commenters :)" So here I am leaving a prewatch comment.
Doesn’t he mean: “this uniquely dumb clickbait title has attracted reasonable responses to the dumb title?” If they haven’t watched the video, the video itself didn’t attract anything.
It's more so that he attract a great number of devs outside the JS world which then wonder about how everything seems to go against the common sense of said outside world in JS if this makes sense
You missed the main point. Faster development without spending $20 for different services. To be able to scaffold a project and get things done quickly is way more productive than figuring out which package to glue together or which service to use for what features. It takes way longer just to organize things the right way and test things out. Forget about shipping the product.
JavaScript does not belong in the server. Edit: at the end of the day the best tool is the tool you are most familiar with. The reason why I said "JavaScript does not belong in the server" is because the js ecosystem is so bad that, you need a third-party startup company to manage your auth. JavaScript is good at one thing. And that is making a web page more interactive. There are a lot of other reasons why js doesn't belong in the server but I cannot write an article here.
For the most part I agree, but for some tasks it can be quite good. For example at my place of work we have a microservice that runs tasks in the background in dedicated threads. These spend a lot of their time dealing with asyncronous tasks. JS is perfect for that sort of thing because we don't need fast, we just need it to be easily maintained. It turns out JS async await, and Promise stack are exactly what we need wrapped up in a language every developer at the company knows. It perfectly fits the requirements we have while it's negatives aren't issues for our need.
That's the biggest lie ever. Maybe in the past pre-2015, however the async nature of it has arguably made PHP not belong on the server in comparison. As it's been the cause of blocking on servers for years. Using the same language on the backend and front-end is also a pro.
Thinking about Django when I say this, but I think a large part of the reasons things worked out this way stems from how Django was created at a time when the ecosystem was simply incomplete. There wasn't a fully featured Python ORM at the time (some might argue that Django is an ORM first with some ancilliary functionality). The templating solutions generally sucked (Jinja wouldn't exist for another few years). Only Pylons came close but the ecosystem needed to make Pylons usable was barren and devs were constantly reinventing the wheel. Django came along and suddenly you could build your entire application from start to finish working on nothing but your business logic. By the time the ecosystem flourished properly, Django was the way to do things. Node never really had that problem. Pretty much right away we had Express, Sequelize, Pug, and so much more. There was simply never a problem that a metaframework could come along and solve for Node besides convenience like there was with Django.
IMHO one of the biggest advantage of Laravel is PHP, which let it run on almost every (cheap) webspace. Same for WordPress, but it address a different community.
Yes you can swap things in and out but the price you pay for it is massiv dependency problems on top you have this hunt for the newest thing which is in the JS world beginning to be absurd. You can't make production code like this.
we already had these problems for backend webdev 10y ago, they're called microframeworks. turns out wiring all that components yourself isn't really that nice to do. i used to like be able to choose my own components, it's nice for the first few times but not anymore as setting them up each time has always been hassle.
I came to this conclusion some time ago after working with Django that had everything include and even some cool 3rd party libraries, it became apparent that doing things in the JS world was much easier to swap in and out much faster.
Laravel also allows you to create your own solutions if you are unsatisfied with the ones it provides. The only thing is that they are so good that you rarely want to re-implement the same thing. Not so in JS.
Well, the thing is everything mentionned as being "a strength" are also a weakness. It really depends on how you see things. Been on both side, went back to rails, mainly because I just want something that works that will still be here in 5 years. Its really 2 different public.
"long live JS and god bless the maintainers who made this ecosystem the best one in all of software, it's a shame other communities look at it and think the good is bad" well if you said so
Honestly, you're the one whose opinions I often disagree with, but I actually enjoy it. It's refreshing that we can have different takes and still appreciate the conversation. I prefer simpler approaches and not piecing together a thousand elements. Great video, by the way!
There’s Adonis, but the fact is the JavaScript ecosystem never wanted this paradigm. They wanted Express. They wanted small libraries that you add functionality to. They wanted “control” and “choice” and hated “bloat”. One of many reasons the JS ecosystem is wrong and dumb.
(installing react-virtualized because otherwise I struggle to render a scrollable list of 1000 items, which the browser can do natively with no lag whatsoever) ah yes I hate bloat (implementing a non-functional slow fake "find" feature since I've broken the one built into the browser) gotta keep the bloat out of my react app
@@t3dotgg Apples to oranges. Much of the JS ecosystem has IMO convinced itself to value the wrong things, by phrasing them as benefits. Being able to choose is the same as being forced to make choices. Having control over tooling means being forced to manage tooling. JS developers often reject better DX because of bad reasons, such as “control”. I’m just jaded because I’ve watched better options come and go and am not particularly keen on where JS is as an ecosystem.
JS ecosystem would massively benefit from developers being able to stick with a single framework for a long time and build deep expertise of building applications with it. Right now they hop from framework to framework for different projects and only build surface level understanding. This is fine for building demos and prokf of concepts but harmful for building production application.
There is a laravel style framework it's called Adonis it just doesn't fit to the narrative of the javascript community of rebuilding the same sht every month.
"it just doesn't fit to the narrative of the javascript community of rebuilding the same sht every month" ironically, that's the same for Angular. People are still complaining about the version 2 rewrite but it's been years. Angular is on version 18 and it's the same Angular but improved.
We can use packages in php too though with composer, if you have used the laravel ecosystem you'll know that the beauty of it are the third party packages. Php also have other great frameworks other than laravel, like symphony, zend, codeigniter, cake php and wordpress that took over most of the websites on the web. Php devs often have the mindset to create profitable solutions, js devs are often wasting their time recreating the wheel.
Completely disagree with the points presented in this video. Companies and founders want "batteries included" solutions that don't have severe debilitating tradeoffs or breaking changes. Perhaps SolidStart + Adonis + Drizzle or Svelte + Adonis + Drizzle is that solution. But regardless, SOMETHING has to wrap all of these into a solution that works well so people can focus on their product rather than implementation details of the code.
As a diehard Laravel developer, I can't stand having to run around finding packages. I purposely tell my team to avoid packages as you never know when that package is going to just stop working. We've ran a project for years on the Laravel stack and each update is pretty seamless. I love watching javascript devs running to the newest tool and spending too much time recoding then just getting a product out the door. The thing that drives me nuts about Javascript is that their is 10,000 ways to write code and every stupid package does things differently.
NestJS is an excellent choice for mid to large-scale projects. Its robust architecture, scalability, and extensive features make it ideal for handling complex applications efficiently.
@@t3dotgg I don't watch you because content is great. I watch you so that I would go away from the hype and do the oposite. So far only react-query was underrated from my part
Laravel or the same kind is a swiss knife while js eco is all tools separated and you pick whatever you need it might be confusing for beginner and these who dont know what they need in js people make tools to solve their problem and most of the time make it FOSS
@@tylerlwsmith Changes to multiple files is not really a big deal though. Nearly everything is similar these days. The verbosity by itself isn't a deal breaker either. The problem with Nestjs is that on surface it promises a readymade architecture that can keep your code organized. But as the app keeps growing, managing that architecture is non trivial. You end up with a lot of circular references which can be hard to debug.
my main want for a laravel-like in javascript is fueled by the "i just want a CRUD generator starter" for your typical backend admin pages and services without enough overhead that i can't extend it to do the same or better with bespoke BYOB parts. I don't think that component of generating the CRUD (templates/ routes/etc) exists in a vacuum though, they almost always exist for a particular frontend piece (vue/react/etc) or go heavy on one specific ORM [which may even influence my decision of which ORM to use] -- everything I found for this stops short and only handles API routes which I take indicates the service-providing-focused nature of the ecosystem.
This story goes back much further. The alternatives to Rails 1.0 were Perl, PHP 4/5, Java Enterprise Edition, and whatever Microsoft was doing. NodeJS wasn't a thing for a long time. The "client", as such, was just the features available in browsers of the time. "MEAN" came in much later. At that time people were really wanting to build heavier JavaScript clients for the first time ever.
Perl and PHP aren't comparable to Rails. Perl and PHP were languages, Rails is a framework built using the Ruby language. What's comparable to Rails in the early days was codeigniter, CakePHP, and later Symfony
This was the dumbest take I ever heard, 8:04 - 8:19 it ends in "...into our own best solution" a JS Frankenstein can't be compared and accounted as better compared to Laravel or Ruby(That is truly open source) I'm a TS/JS Developer but this is absolutely wrong.
I get overwhelm trying to update and get into the modern js based web frontend thing... but even then i'm amazed by how easy it is to just pick the piece that works for you on every aspect of your app instead of having to deal with the quirks of the standard one. is it harder to get into and learn? sure. is it awesome once you get pass that (mostly mental) barrier? it seems to be
"I can't use Laravel or Ruby because it doesn't scale. I'd rather use NodeJs or React"- John Doe, a JS developer who builds apps that will never have more than 100K users or more than 1K request per second.
Js has had its batteries included frameworks, from meteorjs to sailsjs, the problem is the same with anything js, it had about 40 of them with one new every week
Something that is beautiful is that you can choose your tools, or you can adapt to what the company you work for does. It is common that Next.js is used just for the marketing site (weird) but the app is a React SPA with a backend (Express, Java Spring, .Net Core, Rails, PHP/Laravel)
Fair points, it is true that JS provides you a box of legos, and as such is no different from when I was using jQuery and finding libraries people have made for it that solved the problems I was facing (mainly galleries). One thing that I really enjoy with Laravel is that I don't have to setup the boilerplate stuff - I know I'm going to need queue runners, caching, etc, so having those already setup is quite nice - I can just focus on the business logic more.
With stuff like Django or Symfony, you know you can trust what you use and that it won't likely stop being maintained anytime soon. In js, there's many times I've been interested in a tool but because one guy was in charge it stopped being maintainted. It's fine for personal projects but too risky for professional uses. It can be pretty hard to predict what will change or disappear in the next 2 years in JS except for a few big projects
In the roundup what is really missing is the lifetime of these js projects. No real company or there likes the idea that the tech they build upon is gone in a year or two because the creator just found a new toy to play with. Reflect on that for a bit and you'll see how big pita it is for any non startup company to find a stable solution they can rely upon to build their business on. The documentation, blog posts, problems solved on SO also drives from they agree and community size built around a project. That's what companies are looking for. Not, toys or weekend projects.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
I made a mistake. I referred to Ukraine as "The Ukraine", not knowing this phrasing was meant to refer to Ukraine as part of Russia. I fully support Ukraine's right to independence.
It's not much, but I donated another $1000 to Ukraine's efforts to stay independent 🫡
Everyone has rights, I also support for the Ukraine, what about Palestine?
Respect!
forgiven
@@asadrazajutt1 clear difference being Ukraine attacked no one. go away.
Unfollowing you, for polluting code with politics
My 2c - people in javascript seem to be terrified of being opinionated. Every framework has to work with every library. Everything needs adapters. Everything needs "options" that must be decided first. What I want is a no bullshit framework that just has everything I need to start adding value from day 0, and has the longevity and backing to maintain LTS.
Oh no, the voice of logic. Quickly hide away lest they come for you with torches and pitchforks!
Then go build it! I'm sure it's never been tried before! But don't let it be a surprise that people won't adopt it in the first 4-5 years until it's deemed "stable" and "production-ready".
@@dealloc adonis js is basically a laravel porting and has been ready for years and is barely known let alone used, thats too bad since the dev experience is crazy good
I have a top level comment on the video explaining why I think it is, but generally, it's just a package management issue that the JS world hasn't come together to figure out a good solution for. No standardized dependency injection and the perpetual threat of circular dependencies. A monolithic single framework will never really be preferable as long as the dependency injection in PHP doesn't have an equivalent way of working that doesn't break static analysis tools. Same issue with Django, where you can smell the history of PHP in it's design, but is such a pain when it comes to static analysis tools.
@@sharkpyro93 i'm disappointed I did not come across this... I'm hip deep in NestJS right now so too late to back out. Will keep it in mind next time, thank you!
Having a solid stable framework like Rails, Laravel or Django is not equivalent to having 100 bits and pieces of sort of frameworks maintained by a small group. A web framework must solve a consumer problem. The client wants an ERP system, if I'm a ruby dev I know it's Rails what's needed. If I'm a php dev I know it's Symphony I need. If the client wants a basic CRM or a CMS I know I will need Laravel or Django. The frameworks I mentioned are stable, reliable, well maintained, has support and focused innovation. I don't think a js dev can make a decision like that simply based on the consumer requiement. Having too much to choose from is not always a good thing
This is the best comment.
Exactly. Not a ruby/PHP guy here but from my experience in big enterprise, a bighuge percentage of solutions always go for the battle tested options of Spring Boot - and some others for Quarkus / Micronaut / etc. Nobody wants to hedge a bet on something that has not been out there for YEARS and has proven its worth and is still alive and "hungry". There is a reason that React has become the "nobody got fired for buying IBM" of frontend: up to fairly recently, the thing was stable and simply augmented upon itself. Now that the META team and the Vercel team are too intermingled, perhaps its time to start looking elsewhere, esp. if your frontend is JUST frontend and the backend is JUST backend.
Agreed
I think Google has made this stability issue for whole of JS ecosystem. At one time around 2015 it started to settle in JS ecosystem but then Angular 2 came, then it broke everything. I then switched back to Laravel and still sailing smoothly with laravel ecosystem. Never went to JS waves.
"Having too much to choose from is not always a good thing" You read me!
I understand these points but we should acknowledge that the the Javascript Fatigue is a real thing. I am working with javascript/React for years now and I love learning new stuff but needing to relearn things each 3 years and build apps differently is really tiring. Not keeping up has a career cost! Knowing how things are built and being able to discuss it is part of the job interview.
And new projects that are in general more interesting will start using the latest way of doing things. So if you want to join those projects you have to keep up.
I do agree, the beauty of the JS ecosystem is this ease to build things and innovate, but it's also what make it hard to keep up with
I mean, what innovation specifically? Newest JS innovation is literally doing same thing PHP has for millenia.
Don't keep up then. It's OK.
"needing to relearn things each 3 years and build apps differently"
I cannot stress this enough: you don't need to. Whatsoever. Most orgs aren't adopting bleeding edge JS tech.
Not to mention that you don’t need to relearn things. It’s all the same thing.
JS has many issues which lead to never having something as comfortable as PHP. One of them is the lack of focus in the community, no solution is able to take off for long because everyone thinks "I can do better" and proceed to create their own stuff. And no one wants to invest into a framework that has no future.
AdonisJS is for me the Laravel of Javascript. And it is actually inspired by Laravel
Thank you. At least one comment.
😅Trust me, I start the video, pause it a the same time and go straight to comment section to see if someone mention AdonisJS...
and Golang has Goravel
I remember when Adonis came into laravel land as specifically stated they were inspired by it.
came to the comments to check if someone mentioned adonis :)
As someone who started doing vanilla PHP, then Laravel, and now does Javascript (i.e. NestJS), I disagree with this video.
Having a fully fledged framework like Laravel available is incomparable. Laravel is amazing and if my workplace and much of the world wasnt focusing on Javascript based approaches, I'd still prefer to stick with Laravel. The developer experience is unbelievably good compared to JS.
Let's take auth (login and also permissions). In JS, you need to pick the auth framework(s), integrate them with the rest of the application manually, and usually, put some fairly considerable thought into how it works with the rest of your app. In Laravel, I would literally just install the relevant package, and boom, functionality is in - and easy to use as well with little to no thought. (Take the spatie laravel-permission addon for example). Let's also take database event auditing as another example. There is literally an addon you can just install for that. And boom, audit events are logged - including who did it. In Javascript approaches, again, there is no equivalent.
I will say that there is a lot of flexibility that comes with the way the JS ecosystem works, but we absolutely miss out on all these amazing plug-and-play tools that come from the stability of something like laravel. The amount of times i've thought 'we should have a NestJS starter kit with DB + auth + etc at my work' is too many times. Meanwhile with laravel you just HAVE that 'baseline application logic' ready to go (and plug in a few addons while you're there).
problem is NestJs heavily inspired by Angular which Js Devs love to hate
so basically it doesn't exist
I bet if it was React/Jsx inspired, this video would have a different tone
Since you mentioned NestJS, I'm curious what's is your opinion on it? you said it's just lacking on those plug and play features, do you think in general its pros outweigh the cons?
For me I disagree on a fundamental level with the approach they took. DI and AOP in a dynamic/prototype-based language like JavaScript is really uncalled for. Feels like they trying to bring the Java out of Javascript.
And for a number of reasons it's hard for it to compete against popular web frameworks, or even other frameworks within the JS ecosystem itself.
i hate php but i completely agree. at work we use this framework called loco which is a rust framework based on ruby on rails and it's also great. the js ecosystem feels like the wild west and it's also very easy to use bad patterns and write messy/unmaintainable code because of the lack of opinions. flexibility has a lot more disadvantages than advantages in my opinion.
Same thing with Rails, we have devise for user auth, you know how old is this gem? 10+ years old and still alive! It does authentication and signups form also send email to confirm email address, like you said, when JS is banging their head against the wall related to ORM, all these framework got it solved 10 years ago, and it work perfectly today, for audit we have Papertails gem, it's plug-n-play you add it to the model and it just works
@@smoked-old-fashioned-hh7lojust look the ORM mess, like Node has 4 ORMs and the community keeps changing it, like Rails active record is the same for a decade, all the edge cases you can think about they solved because it's super old haha
The fragmentation of the JS ecosystem and the sheer amount of third party libraries is why it’s bad without even going into the quirks of the language itself.
It’s not okay to have dependency trees that go into thousands.
I would much rather use a language where the community understands that third party dependencies are to be used sparingly.
I don't share the view that only JS allows you to make a "customised framework" using only what you want from existing packages. Laravel is also a giant collection of components that we can use individually to create our application infrastructure. You only have to look at the vendor folder created with a new Laravel project to see that there is everything you need to create your solution.
The main problem, for me, is that if there is no common solution adopted by the market, it will be more complex for those entering the universe of a company that has chosen a set of solutions for which I only know how to use half of them, because in my projects I used other types of solutions for the same purpose. When a company is looking for a programmer with experience in Laravel, anyone who knows how to use Laravel is immediately ready to fill that position.
skill issue
@@icemelt7ful says u script kiddie
But you are suppose to be a DEVELOPER that knows Lavarel, not a Laravel developer.
You are suppose to know how to handle databases or emails without Laravel too.
@@neociber24 Let me be a little clearer.
I know how to send emails with PHP's mail() function, or using PHPMailer. I know how to log following the PSR standard, or how to use Monolog to speed up the process. I can create a PHP class to communicate with MySQL via PDO. That's not the point. If a company is going to hire someone for the team to continue a project that was built with a certain stack, you certainly won't be the best person for the job if you haven't mastered that stack. The whole thing about choosing the best options to develop my projects is OK. But if I'm going into a team job, with projects in progress, and I'm not used to using the stack that the team uses, that's going to be a problem, because companies aren't very willing to invest their time in getting you to adapt to the team's stack. That's why many companies are looking for programmers who have mastered Laravel, and not just pure PHP.
@@neociber24
Yes u are supposed to know the theory behind these concepts and how they work, not the different versions of syntax!
There’s always WASTED time in getting to know how the new toy works
I'm a massive, massive fan of Laravel with Inertia and React.
I also love Laravel's grammar and the fact that it gives you pretty much everything you need in an API or service, NPM is fantastic but it's much easier to get into dependency hell.
Dependency hell is a real thing when your app gets just a couple of years old. And it certainly does not help that NPM install by default makes you lock into extremely specific versions of every package.
@@05xpeter Peer dependencies allowing the same versioning as regular packages was a mistake. I've been burned so many times and forced to force install packages due to lazy devs just saying we should use latest peer dependency. Suddenly a package has an update with a breaking change, they force latest version, now everything breaks.
There's also the fun time when you want to update one package, it requires latest, another package requires a different version. Both versions work, but one was decent enough to add a range of tested versions, the other was lazy and just said latest.
@@05xpeter We have a biggish NextJS app that’s less than a year old and I’ve spent the past two weeks in dependency hell. I added a pretty big feature and it INSTALLED THE ENTIRE OF REACT NATIVE.
Even after cleaning that mess up there are some Jest issues where “the environment is not configured for act”or something, which is apparently is caused by a version conflict between React and the test library, but… no idea how to fix it.
And even after all that a recent React change apparently triggers a bug in next/image.
It’s a nightmare.
Adonis is probably closest to Laravel for JS (TS), and it's excellent. I use Adonis whenever Next + Vercel doesn't make sense. APIs to glue various systems together, puppeteer & pdf templating, CRON jobs too big to be severless, etc. The ORM is great, the templating engine is decent, and support for everything from redis to s3 to mail is baked in and works flawlessly. Beyond that, it can be quite modular. IMO, it's also the best option out there if you want fullstack TS HTMX.
Laravel with Inertia/React is by far the fastest way I've found to build a full stack app.
it's easy to say one technology is the best if that technology is the only you've tried
@@kkebo I'vew tried Next, vanilla React + express, Django, and finally Laravel...he's right
@@kkebo I've used a lot of frameworks and haven't found one that is as frictionless as Laravel yet.
Django
@@Tommmmmm2 +1 for laravel. used express, c# and more. laravel has everything.
by the way, i hate php. but i hate less while writing laravel.
Honestly, it ALWAYS boils down to priorities.
If you need ultra high speed parallel stuff. Maybe JS or PHP are not the best language. GO may be an option.
If you're a one man start-up and you need a shit load of things, maybe you don't want to integrate 500 different parties and integrate everything yourself - then choosing PHP with laravel ist a perfectly fine decision.
If you need to move kinda fast in a team and want easy re-hiring, Typescript is perfect for the job.
It just should always boil down to a set of priorities.
Inertiajs not mentioned at all for some reason.
Also :
20$ for hosting
20$ for auth
20$ for database
20$ for queues
20$ for mail
20$ for rate limiting
Yeah nextjs ecosystem is a PERFECT solution to own and control nothing. It is a maintenance dream sprinkled with some good old premature optimisation.
I had an experience with serverless queue service and it was truly a nightmare. it was in down time to time because of its cloud provider (cloud over cloud) and even more my messages got stuck or lost. The price of this decision was too high.
I host nextJS on a 3$ hetzner instance, try to learn some stuff please
You do realise if you can develop a service locally, it can probably run on a VPS? I know! Shocker!
Not everything has to be serverless...
don't wanna pay someone to take care of those? then dont! but yeah, options suck i suppose...
Skill issue
Hi there, Ruby developer and now Elixir/Erlang dev here. Before I start, please don't kill me-just understand my context. So... here we go...
After years of doing web development (around 15 years), I've seen the JS community taking off. Even before the React wave, there were a lot of frameworks and tools. For a JS developer, landing in a new job was crazy because once a developer learned and mastered a tool (framework or library) in JS, in the new job, they had to re-learn everything again. This eventually caused what we call JS Fatigue, leading experienced developers to exit the JS community.
As you grow older, it gets harder to learn new things. Many will say, "Isn't that the goal of an engineer? To stay updated and learn new things?" And I will say yes, but new problems, not new tools. Consider the average age of a JS dev-most are in their 20s and maybe 30s. Eventually, JS Fatigue will reach you, even though it seems more stable now than in the past.
Also, another little rant: why is it the only language without any proper standard library? Why does doing basic stuff require a 3rd party package?
I'd say learning doesn't get harder, but learning the constant reinventing of the wheel is definitely exhausting. Why learn jquery, angular, react, svelte, solid, next, nuxt, remix, vite, etc etc when if you want to build product, you can rely on all batteries included frameworks that are tried and tested by large companies like Stripe, GitHub, Shopify, etc. As an older web dev, I'd rather spend my time learning a new language, game development, a different paradigm like FP, etc. Want to build a saas product quickly, with standards and conventions that have been worked on for over a decade? Then just pick an all batteries included framework and focus on building your product. Don't waste time learning about all the different toolkits, "meta" frameworks, and an infinite amount of packages only to fall into analysis paralysis and get nothing done.
Nuxt is kind of closest to Laravel in JS.
A lot of primitives, a lot of modules from core maintainers.
You can do almost anything out of the box, without spending time to deal with incompatible libraries.
Yeah aldo NestJS. What he mentions applies to pretty much any web scripting language. You can go modular with flask, Sinatra, symfony
It makes sense when you consider how much the Vue community was shared with the Laravel community.
Weird he didn't mention it. Actually, it's not weird.
@@j.r.r.tolkien8724 he wanted to make his point
@@j.r.r.tolkien8724He never mentions Vue, lol
A certain part of this is a bad info - the mentioned ecosystems definitely have their fair share of smaller frameworks. PHP ecosystem is especially rich, from Symfony, to ReactPHP to whatever was the name of that static one that used to be the fastest ttfb in the world. Also, most of these, if not all, existed during and before the Angular era, whereas Theo mentions only Rails. Don't let me start on Java. And it is super duper common to play around with the runtime models, much more common than in the JS world (although that is changing). I think that is where the answer lies - all of these had 10-15 years more to develop, and all of them have more freedom to fool around with the execution model, JS ecosystem is fragmented and often can't pick a lane. This can be good, as we end up with a lot of products and components that are industry leading, but its bad side is that it often feels like our job isn't coding and delivering, but instead figuring out how pieces work together and which pieces to pick.
That really sounds like decision fatigue.
Its the same reason why a lot of people like Angular, is really opinionated.
Yeah backend framework has their stuff stable for years(Mailers/Database migration system/good ORM) and it makes the development easy and fast, like install one lib for this framework and you get auth/basic admin dashboard/audit logs and soon on, with Node you need setup everything everytime and all the time a new library came up you need to integrate or replace, it's a messy environment
I'm interested on your take on how this affects the devs who spend 1-2 years outside the JS ecosystem doing other things not living and breathing the JS coding news. Having myself included in that group I see myself always doubting each and every library decision I'm making thinking that is this gonna be outdated in a year or is there already a better alternative. In Laravel/Rails/Django land the "gotcha"s are documented and you can find workarounds, or then have those fixed by a single pr. But in JS ecosystem the answer is quite often "just change the library". But how do I then know if the other library can accommodate the other features I was using from the last library
I don't need options, I need sh*t to just work. I'll set you up production ready Java Apps in no time. Meanwhile the average React experience I made myself is that something hasn't been connected to something else as it should be and I get ungodly error messages that leave me alone.
The startups don't use the JS framework cause they get started faster, but because they don't know better (in most cases I've seen)
"I'll set you up production ready Java Apps in no time."
Sure buddy 😂 Java/Spring is not as bad as JS world but it's definitely no Laravel/Rails that's for sure.
i feel ashamed when i remember express requires another package just to use json in body, GOD help me
It's ABSOLUTELY god awful that it literally requires body parser to be "somewhat viable" backend lang
First time working with Express it took me a few painful hours to realize multer is needed to handle multipart form data
you shouldn't be ashamed--it's ridiculous, that's the word you're looking for. Somehow it was never acknowledged that it was ridiculous when people where writing all of that boilerplate code back in the day smdh.
You're correct but remember, the all in one frameworks are the best thing for new developers. It makes it easier to quickly learn the important things quickly and later refine them with experience.
Imagine, just imagine a new dev learning Next, I only hope for better days for those kids lol
Not to mention that a junior dev that you need to quickly get through some basic ropes and start doing even the grunt work has a much safer place to do it inside an all-in-one heavily opinionated framework - and actually write some decent-ish productive code.
@@PhilipAlexanderHassialis sure thing I already trained people on Rails and it's quite fast for them to be productive, yeah they don't know much of Ruby at start but with time they become good devs, but with Next, I don't even know where to start is so much to drop, it's crazy and the libraries changing all the damn time
not only new developers, old developers too. Most projects don't really require the modularity js backend land imposes that's the truth. Theo is coping.
PHP is simply better. JS is running in circles around pretending it's moving faster.
This. ^
shots have been fired
Yeap, and this will hurt many people.
Did you really say "no other languages has so much full stack solutions" ?
Omg. PHP alone has 5 very good fullstack solutions along those 2 are the most solid and very known Laravel et Symfony, that 99.99% of the photo devs have heard about.
The 3 others being YII, Codeigniter and CakePHP for people who have a bit more experience.
In the JS world I doubt even 20% of people know about the 3 your just mentioned.
So before making those kind of bold statement, please do some research.
In the JS world there is no fullstack clear winner because the JS ecosystem is way more too prone to hype than other ecosystems.
Having mainly alternatives or options can be good but in the JS world we've passed the "options" phase, there's just too much stuff.
I used codeigniter long time ago, yup PHP has good frameworks, but all are backend happy, don't have much control on the frontend.
If you google search most popular web frameworks you get at least 3 php frameworks in the top 10. These 5 php frameworks serve different purposes. Symphony is for large erp solutions and laravel is for common cms like apps. All the innovation focus on improving the areas they're specialized for. That's the problem with js. JavaScript has too many stuff going on scattered among the community without the focus on specialized innovation, and no one is actually solving industrial problem. Everyone's like, showing off this cool thing they can do with js or trying to patch up some technical flaw in someone elses framework. That's not very meaningful innovation
@@icemelt7ful that's not the point of the video at all. And what you just said is awefully wrong since InertiaJs came out. And actually, even with just Vite, using React, Vue or any other frontend framework is more than easy if you've learned who frontend and backend really works. The issue is, because of FW frameworks and API-driven frameworks, a lot of devs don't even know basic web principles anymore. Now when you say "don't have much control on the frontend", that's actually the case for ALL backend framework by definition, because the frontend is executed in the browser. Things like Next, Nuxt or any SSR based framework don't give you control on the frontend either, it's the frontend framework that does. Those frameworks only makes it to be rendered first in the backend as a strong, but no fronted code will be executed, it will be hydrated and executed on the frontend later one.
💯💯💯
The JS world is hyped, and Prisma is hyped even though it doesn't have some essential features like TypeORM has. However, now Drizzle has come, and many companies that chose Prisma will have to maintain it for the next 3-5 years.
One more difference between PHP and JS developers is that the PHP community built really good backend ecosystem frameworks and didn't touch the frontend. In contrast, the frontend community built poor frontend libraries and is now trying to build a good backend.
The "hype" take is a poor argument. There are 2 types of people in each ecosystems: Those who hype tecnologies and those who build stuff.
In RUclips and Twitter you mainly just found the hype.
Because a framework comes each week doesn't mean a company is rewriting their website each week.
I am a Linux user, and this is what I think when I hear about "ecosystem fragmentation being a good thing": both Microsoft and Apple enforce a one-size fits all solution, Linux is fragmented AF. Now, who has more OS market shares between the three? Don't get me wrong, I'm always the first to push for keeping projects up-to-date with latest updates, but I also have to wear an administrator hat, and be frustrated that we still need to manually integrate authentication to the n-th app we are creating. For what is worth, I think Astro could become a Laravel equivalent. It's integration solution for various components is very promising in that sense. Next.js could also become as such if there was a similar integration solution (e.g. swapping React for Solid, or Vue, etc.) because it already has a solution for server actions. In short, modularization may be good, but if there isn't a Laravel equivalent, then there can never be a popular solution such as Rails or Laravel.
If you consider all computers Linux has the market share and it's not even close. The flexibility it gives you is just what's needed for embedded, server, phones, and all these other use cases
@@niamhleeson3522 And which are the most installed distros for servers? Do you see a lot of servers running Arch? Fragmentation is good, but too much fragmentation isn't.
Remember Linux pre 1999 when you had to compile every package and solve the dependencies on your own? That's the js ecosystem now, Laravel is like the Debian/Ubuntu experience after 2010 where packages are made to work with each other and you can mix and match any service or app
As someone who doesn't know much about web dev (and doesn't really care to tbh; I prefer low-level stuff), I remember picking up JS when I was first learning to program. There wasn't anything inherently wrong with it, but as a new self-learning beginner, the number of options for how to do things was overwhelming. Add that on top of JS's already confusing syntax rules, and you get a very unpleasant beginner experience. While the code might run easily, you stand no chance of figuring out the errors when things do go wrong. That's the only issue I had with it.
In my opinion, JS should not be considered a beginner language, but it is frequently treated like it's the *best* beginner language. I think that's what it boils down to for me. You can do a lot if you know what you're doing, but it'll confuse you more if you don't.
the javascript community is like Honda Civic owners they love it cuz they can mod it till infinity... but some of us rather just buy a AMG Mercedes Benz and call it a day 🤣
8:39 “and the doc that your reading is less than 5 years old”
While I agree with the inverse of this statement, I feel like your statement is flawed here. One of the benefits of the all-in-one frameworks from other languages is maturity and adoption. Sure they have updated docs but a lot of JavaScript projects and frameworks have scattered adoption and are very young (even for svelte, I think one of their major releases and hype peaks was in 2019, just 5 years ago). If you’re new to the web dev scene, it probably is harder to tell apart the frameworks that are hype with no substance and the frameworks that will last.
I desagree on this one. JS/TS needs some type of ruby on rails that dictates a standard to build a good quality truly full stack apps that can handle more than the trivial complexity on the backend. I'm not saying that the backend should be written in JS/TS, maybe it can be go, python or whatever but we are lacking that all in one winning default stack that everyone can use to build and ship fast without headaches and that we can be sure that in 5 years it will not have gone out of fashin and we will be forced to move to the new thing.
To me, it’s testament to Laravel that it’s so great that it’s regarded as the main go-to framework for a language. JavaScript having multiple ‘frameworks’ just shows they’re all not good enough to suit everyone’s needs.
so-so feelings about this one. i think you're skimmin over one thing that is quite nice about the "laravel" approach or in my case Django mostly. it's been solid, battle tested, reliable for many years. it's modular too so I can plug in different auth-systems for example. But I dont have to have the headache of constantly looking for the right choice. The trade-off obviously being the inertance that it brings. Django for frontend is basically dead for anything bigger than a two-minute mockup. But for the backend, the mixture of ORM and Auth being baked in and working worry-free is a plus that i don't see so easily with any JS solution.
Theo do you just not acknowledge vue? Anytime where I'm expecting vue to be mentioned its not, but svelte or solid is.
vue not mentioned :(
I mean tbh svelte and solid directly try to compete with react while vue feels much much different (better even)
Only sponsors
he hates vue. glad he skipped it coz even when he is talking about vue, he does it in a passive aggressive way.
Heheh, i dont kneo why he doesn't acknowledge vue. sponsorship or something??
JS has many issues which lead to never having something as comfortable as PHP. One of them is the lack of focus in the community, no solution is able to take off for long because everyone thinks "I can do better" and proceed to create their own stuff. And no one wants to invest into a framework that has no future.
PHP has been calling me - I think its time to learn it.
Switch to new Language that provide all stuff like using PHP because Laravel is not a best deals. You need to maintain 2 language because all we knew, we still use JS as a client too
@@ngaji_it And what's wrong with writing your app using PHP and JS? PHP and Laravel are stable, fast, well-documented and very much modern. So I don't see your point. The OP should go for learning PHP!
noooooo! I spent 10+ years stuck with PHP, it was terrible. Use Typescript + Adoins.js instead!
this is probably bad advice but php is cool because you don't really have to learn it straight. just start doing stuff with laravel or kirby or even wordpress and you'll pick it up.
@@ar_xiv and then you will be stuck with a bad language that easily breaks and is difficult to debug, while also being painfully slow to write code in (PHP vs any modern statically typed language like Typescript)
There is a big problem with saying people can stay on old versions of stuff, namely it will keep getting harder to find people with experience. Keeping CRA with react class components around for 10 more years and it will be more difficult to find devs than it is for cobel code bases
COBOL
I'm a fan of just using the Go standard library
I'm experimenting with Beego with htmx
Alert!!! Alert!!! Based Sigma Detected!!!
Yea but the standard library doesn't (and shouldn't) provide all the things you get with Laravel. It takes minutes to start Laravel projects with great functionality, and you get all the batteries included.
@@ardavanansari it doesn't provide all things but everything is built on top of std library so it works seamlessly with each other.
we don't need adapter bc std lib connect all it.
Lets say I have made auth lib in js I have to provide a adapter for every framework but in go I just give net/http Handler and works with every library.
@@abhinavadarsh7150 absolutely love that about Go. I just wonder why there is no popular batteries included framework written in Go (which uses the std lib as much as possible). I'm thinking of writing a rudimentary Laravel equivalent in Go, but the community really dislikes using anything outside the std lib.
While the modularity of JS is amazing and allows you to truly create and compose anything you want together it also comes with a great cost. Stability just isn't there as theres too much flexibility and the library probably didnt think about your use case. Also these libraries often depend on other libraries so when it comes to upgrading it's a very painful experience
In PHP land, we can also build things without laravel, pick and choose components/modules that we need. The most popular framework to do that is Symfony (which laravel builds upon), but you don't even need it. There are also Frameworks like Phalcon that runs as a php extension, so you get C-like performance.
One of the great things in PHP-land is actually the PSR. Which has come up with guidelines for not only coding styles, but naming conventions for auto-loading and interfaces for common core functions like Logging, Request, Response, Http Clients, etc. So if your projects/libraries follow the PSR standard, its pretty damn easy to switch components and navigate around because there's a standard to follow.
Agreed, mostly. Laravel only requires about five files in a project to run, and be booted from a plugin in another app. Personally, talk of performance in interpreted languages is moot unless you don't have a database or external service to integrate with, so I think of Phalcon as existing to address the wrong problem. It's doesn't bother weighing of business priorities + cost + maintenance + impact, etc. We built a successful company around an app I built Phalcon and I was hiring, I made the decision to switch to Laravel, based on the idea that I can't nearly guarantee support will exist for it in ten years, nor that developers will want to imagine themselves working with a framework they haven't heard of, and at the very least would likely not help their resume. It also wasn't as easy to set up as vanilla PHP with common extensions, and the community was way smaller.
Turns out, within that year, the libraries I was using for API integrations required a newer PHP version than Phalcon supported, and I would have had to switch anyway.
@@stevenhorton8604 I just mention Phalcon to let people know that it exists, wouldn't really recommend it for anyone lol. It was more relevant in the PHP5 days, its pretty much pointless now.
Laravel + Symfony will work for 99% of the cases. Want some performance boost in a certain area, can write a micro service using swoole; which I've done before. Could I have used something else? Yes, but I just wanted to give swoole a go and it was fun.
I agree with Theo. JS does not need a single-most-popular-framework, and some of us who at times would like that to be so, need to learn to appreciate the differences. That said, I also came here to sing my praises for Symfony, although, you've done a better job than I ever could. Kudos!
I'd say the Nuxt ecosystem is probably the closest thing right now to the "Laravel of the JS world".
Think about it... Laravel was the first major framework to endorse Vue because of it's similar philosophy.
Vue and Nuxt have always been about simplicity, elegance, low barrier to entry, opiniated but still flexible enough for the majority of use cases, and they've always involved the community and their feedback (all things that React isn't and never did).
They've also recently been really focused on creating tooling for the JS community, not tied to just Vue/Nuxt: Vite and the whole UnJS server toolkit including Nitro.
I think you touched on this, but also it kinda flew by. Laravel is so different in this space because it hasn't missed on a lot of things it tries to do. So you mentioned the fact that your T3 Create App thing recommended a DB ORM but through learning you actually don't like the one that it is recommending hence you're using another.
But with Laravel, that doesn't happen. Because it has and always will ship with EloquentORM, and if you don't like that, it's all built with composer so has support for Doctrine or just raw dogging SQL queries and doing your own thing.
Like, the examples you gave as to how easy it is to swap out with JS, affects all package manager based languages?
I think the question still remains, why doesn't JS have a Laravel? And for better or worse it's because the vast amount of people I speak to don't use JS on the backend so it makes no sense to build one. Hence why you get these weird solutions that always have drawbacks.
Btw, the last 3 minutes I really didn't understand, nor get why you brought up when neither is unique to any language, which you state, but then state it's why JS gets funding because it has better traction when those things aren't language agnostic. Laravel legit has about 40 other products which have been cut off as businesses in the PHP community. Again, this isn't JS specific and I really don't know what you're talking about here.
Perhaps I'm misunderstanding. Apologies but this video has missed the mark for me personally.
Well said!
As primarily a Laravel developer, my experience as a relative beginner using Nuxt 3 on Cloudflare Pages is that it comes pretty close in typical use cases.
that's worth knowing thanks for sharing
AdoonisJs is basically a Laravel clone for JS/Typescript 🤫
But not remotely as popular. So I hesitate to learn it.
@@nou4605 a tweet with thousands of likes will convince you then?
The real truth is that client side SPA apps were a mistake, and the HTMX,/Hotwire/Livewire,/Liveview approach will win in the end once everyone realizes how easy they are, and once businesses realize how much faster they can ship features and reduce staff.
Wasn’t expecting that transition from Laravel to react 😂
IDK what he meant by that!! Laravel folks like using React as well.
I think Nuxt is developing an ecosystem like Laravel
Laravel's core is kernel and follows the UNIX design philosophy pretty well. Only about five files (classes or modules) are required. You could have Laravel events signaled over standard pipe to a JavaScript code being run within a library built in Rust within a Python app through pyo3. I built a Laravel app that uses both React server side and Client-side because Laravel's ORM and routes are easier for me.
Thanks for being genuine with laravel, sure js is great, but Laravel is pretty awesome, and the fact that we can use any UI framework ie React or vue or svelte in Laravel, just makes a super awesome framework
As a JS constant user I dislike maintaining JS projects, if you don’t keep updating your packages you will have security issues eventually, it you do you need to upgrade multiple different packages being updated at multiple different times, deal with all types of breaking changes, major NodeJS upgrades, etc.
These updates are much easier to be done in those full blown frameworks like Laravel, Spring, and even Adonis and others since they own more of the ecosystem.
I am personally getting tired of maintaining JS applications and considering using some of these other solutions more often
6 years ago when I became a full stack JS dev (I ended up going back to jvm land for my sanity and that says a lot) it was obvious that enterprise software should have NEVER been built using js in the backend. It's insane how fast libraries become deprecated and then you can't just update to a point release to fix it you have to upgrade to a different version with dozens of breaking changes. It's ridiculous.
I'm too old now that I know LAMP stack was a thing
lol I’m old enough that I remember LAMP was the new cool stack and the old hats thought it was a buzz word 😄
Are you old enough to remember that P did not stand for Php originally?
I'm old enough to remember "Matt's script archive", a bunch of badly written cgi-scripts in Perl4, full of security problems.
If this is a walking-stick-measuring contest, my first server-side web code was CGI in C for CERN httpd, and I was SO happy when Apache came out. I wrote my static site generator with m4 and sed, because I didn't have enough disk quota to install and compile Perl.
@@tomgidden Wonderful times, back when WWW was just one contender for the backbone of Internet hypertext, and things like Gopher and WAIS were in some aspects better...
Back in my day Lamp was a fire. In a cave. Doing finger cube hand calculations.
It is also very easy to exchange components in PHP. The reason why Javascript Devs don't switch to Rails or Laravel is not because Javascript has an advantage and would be easier to compose. The reason is simply that they are Javascript Devs and want to stay there as long as there are no compelling reasons to switch.
*Laughs in Spring Boot*
baseg
Laughs in Spring MVC.
Laughs in NestJs
Spring Boot is awesome, I dont know how people prefer JS ecosystem over Java tbh
@@naughtiousmaximus7853You're kidding
Symfony is on par with laravel.
I think frameworks should be like astro. Pluggable view layer. Templating in whatever framework you want. SSR via wasm. Then the BE can be whatever and the FE is in a web native language.
The benefit of an all-in-one solution is that code bases looks similar. You can onboard new developers easier
The way you described the js ecosystem was how the java ecosystem back in the day - before spring won
for the youngins, java used to have a new MVC framework every week too.
Soon, javascript ecosystem will normalize too. in fact, you can feel it right now with React. Why learn Vue or Svelete or Solid when you're already productive with React.
The more the community moves to something like Nextjs, the more people will just a one stop shop for everything. It's the same thing for Spring and Sprint Boot. Spring was very modular. Once people started just using Spring Boot, nobody used Spring modularly anymore. You're now in Spring world.
Java was never like this, there were always "enterprise" options besides Spring that you could just learn and get a job. Not even close to the same in js land. JS land is anarchy.
@@ShaferHart Those "enterprise" options were JSP and JSF 1 which were both rather horrible.
Haha, yeah, I remember learning JSF, Struts, Stripes and Wicket and hearing about Tapestry, Cocoon, GWT, Seam and Play.
This video does a great job explaining why developers should avoid the JS ecosystem whenever possible.
Theo stated: "This video has attracted a uniquely high number of people leaving dumb comments before watching the video. Try to not be one of those dumb commenters :)"
So here I am leaving a prewatch comment.
Doesn’t he mean: “this uniquely dumb clickbait title has attracted reasonable responses to the dumb title?”
If they haven’t watched the video, the video itself didn’t attract anything.
hey I know you from twitter!
It's more so that he attract a great number of devs outside the JS world which then wonder about how everything seems to go against the common sense of said outside world in JS if this makes sense
I love how Theo never really talks about modern Angular.
You missed the main point. Faster development without spending $20 for different services. To be able to scaffold a project and get things done quickly is way more productive than figuring out which package to glue together or which service to use for what features. It takes way longer just to organize things the right way and test things out. Forget about shipping the product.
JavaScript does not belong in the server.
Edit: at the end of the day the best tool is the tool you are most familiar with.
The reason why I said "JavaScript does not belong in the server" is because the js ecosystem is so bad that, you need a third-party startup company to manage your auth. JavaScript is good at one thing. And that is making a web page more interactive.
There are a lot of other reasons why js doesn't belong in the server but I cannot write an article here.
Says you
For the most part I agree, but for some tasks it can be quite good.
For example at my place of work we have a microservice that runs tasks in the background in dedicated threads. These spend a lot of their time dealing with asyncronous tasks.
JS is perfect for that sort of thing because we don't need fast, we just need it to be easily maintained.
It turns out JS async await, and Promise stack are exactly what we need wrapped up in a language every developer at the company knows. It perfectly fits the requirements we have while it's negatives aren't issues for our need.
That's the biggest lie ever. Maybe in the past pre-2015, however the async nature of it has arguably made PHP not belong on the server in comparison. As it's been the cause of blocking on servers for years.
Using the same language on the backend and front-end is also a pro.
Why?
Use and learn any programming language you want. Use any libraries that you comfortable with.
Thinking about Django when I say this, but I think a large part of the reasons things worked out this way stems from how Django was created at a time when the ecosystem was simply incomplete. There wasn't a fully featured Python ORM at the time (some might argue that Django is an ORM first with some ancilliary functionality). The templating solutions generally sucked (Jinja wouldn't exist for another few years). Only Pylons came close but the ecosystem needed to make Pylons usable was barren and devs were constantly reinventing the wheel. Django came along and suddenly you could build your entire application from start to finish working on nothing but your business logic. By the time the ecosystem flourished properly, Django was the way to do things. Node never really had that problem. Pretty much right away we had Express, Sequelize, Pug, and so much more. There was simply never a problem that a metaframework could come along and solve for Node besides convenience like there was with Django.
11:11 "You could fork it and put it in yourself", okay if you say so daddy theo
IMHO one of the biggest advantage of Laravel is PHP, which let it run on almost every (cheap) webspace. Same for WordPress, but it address a different community.
Yes you can swap things in and out but the price you pay for it is massiv dependency problems on top you have this hunt for the newest thing which is in the JS world beginning to be absurd. You can't make production code like this.
we already had these problems for backend webdev 10y ago, they're called microframeworks. turns out wiring all that components yourself isn't really that nice to do. i used to like be able to choose my own components, it's nice for the first few times but not anymore as setting them up each time has always been hassle.
I came to this conclusion some time ago after working with Django that had everything include and even some cool 3rd party libraries, it became apparent that doing things in the JS world was much easier to swap in and out much faster.
Hey, we have been using/shipping redwood for two years now
Laravel also allows you to create your own solutions if you are unsatisfied with the ones it provides. The only thing is that they are so good that you rarely want to re-implement the same thing. Not so in JS.
Video ended at 1:03 he is being disingenuous on purpose or doesn't know anything about Laravel at all.
Well, the thing is everything mentionned as being "a strength" are also a weakness. It really depends on how you see things. Been on both side, went back to rails, mainly because I just want something that works that will still be here in 5 years. Its really 2 different public.
"long live JS and god bless the maintainers who made this ecosystem the best one in all of software, it's a shame other communities look at it and think the good is bad" well if you said so
Honestly, you're the one whose opinions I often disagree with, but I actually enjoy it. It's refreshing that we can have different takes and still appreciate the conversation. I prefer simpler approaches and not piecing together a thousand elements. Great video, by the way!
There’s Adonis, but the fact is the JavaScript ecosystem never wanted this paradigm. They wanted Express. They wanted small libraries that you add functionality to. They wanted “control” and “choice” and hated “bloat”.
One of many reasons the JS ecosystem is wrong and dumb.
I guess the Unix Philosophy is dumb huh
Microservices are a mistake 🤷
(installing react-virtualized because otherwise I struggle to render a scrollable list of 1000 items, which the browser can do natively with no lag whatsoever) ah yes I hate bloat (implementing a non-functional slow fake "find" feature since I've broken the one built into the browser) gotta keep the bloat out of my react app
@@t3dotgg Apples to oranges. Much of the JS ecosystem has IMO convinced itself to value the wrong things, by phrasing them as benefits.
Being able to choose is the same as being forced to make choices. Having control over tooling means being forced to manage tooling.
JS developers often reject better DX because of bad reasons, such as “control”.
I’m just jaded because I’ve watched better options come and go and am not particularly keen on where JS is as an ecosystem.
@@t3dotggImagine comparing Unix to JS 🤡
JS ecosystem would massively benefit from developers being able to stick with a single framework for a long time and build deep expertise of building applications with it. Right now they hop from framework to framework for different projects and only build surface level understanding. This is fine for building demos and prokf of concepts but harmful for building production application.
Are you angry with vue js?
There is a laravel style framework it's called Adonis it just doesn't fit to the narrative of the javascript community of rebuilding the same sht every month.
Did you watch the video my guy
"it just doesn't fit to the narrative of the javascript community of rebuilding the same sht every month" ironically, that's the same for Angular. People are still complaining about the version 2 rewrite but it's been years. Angular is on version 18 and it's the same Angular but improved.
LOL, 12 minutes of my life wasted watching a guy talk garbage who build drag and drop in 5 years.
We can use packages in php too though with composer, if you have used the laravel ecosystem you'll know that the beauty of it are the third party packages. Php also have other great frameworks other than laravel, like symphony, zend, codeigniter, cake php and wordpress that took over most of the websites on the web. Php devs often have the mindset to create profitable solutions, js devs are often wasting their time recreating the wheel.
Nuxt is nice , gives a lot of stuff packed, then add so,e plugin
Completely disagree with the points presented in this video. Companies and founders want "batteries included" solutions that don't have severe debilitating tradeoffs or breaking changes. Perhaps SolidStart + Adonis + Drizzle or Svelte + Adonis + Drizzle is that solution. But regardless, SOMETHING has to wrap all of these into a solution that works well so people can focus on their product rather than implementation details of the code.
Interesting how you don't point out vuejs at all
I remember Meteor JS trying to accomplish this, but it locked you into using MongoDB.
NestJS and Sails
Yup NestJS even has Sagas so dope
Yeah, was wondering how nestjs fits in.
NestJS mass adoption moment incoming?
@@Kerngebruiker never until they get rid of decorators. (so probably never yeah)
@@upsxace decorators are coming in js as a stable feature. Why you're not liking it anyway?
As a diehard Laravel developer, I can't stand having to run around finding packages. I purposely tell my team to avoid packages as you never know when that package is going to just stop working. We've ran a project for years on the Laravel stack and each update is pretty seamless. I love watching javascript devs running to the newest tool and spending too much time recoding then just getting a product out the door. The thing that drives me nuts about Javascript is that their is 10,000 ways to write code and every stupid package does things differently.
NestJS is an excellent choice for mid to large-scale projects. Its robust architecture, scalability, and extensive features make it ideal for handling complex applications efficiently.
And people say I sound like a paid shill 🙃
@@t3dotgg cuz you are
I cannot imagine using next.js for something bigger than todo app
😂@@maciekdeveloper
@@t3dotgg I don't watch you because content is great. I watch you so that I would go away from the hype and do the oposite. So far only react-query was underrated from my part
Laravel or the same kind is a swiss knife
while js eco is all tools separated and you pick whatever you need it might be confusing for beginner and these who dont know what they need
in js people make tools to solve their problem and most of the time make it FOSS
What do you think of Nestjs? I'm asking because I am shipping a backend in Nestjs. In 2024.
My experience with NestJS was that it is verbose. Doing anything seemingly required changes to 5 different files. I didn't love it.
@@tylerlwsmith Changes to multiple files is not really a big deal though. Nearly everything is similar these days. The verbosity by itself isn't a deal breaker either. The problem with Nestjs is that on surface it promises a readymade architecture that can keep your code organized. But as the app keeps growing, managing that architecture is non trivial. You end up with a lot of circular references which can be hard to debug.
my main want for a laravel-like in javascript is fueled by the "i just want a CRUD generator starter" for your typical backend admin pages and services without enough overhead that i can't extend it to do the same or better with bespoke BYOB parts. I don't think that component of generating the CRUD (templates/ routes/etc) exists in a vacuum though, they almost always exist for a particular frontend piece (vue/react/etc) or go heavy on one specific ORM [which may even influence my decision of which ORM to use] -- everything I found for this stops short and only handles API routes which I take indicates the service-providing-focused nature of the ecosystem.
Why didn’t you mention MeteorJs which I think is one of the best JS frameworks
It seems that they are afraid to talk about real alternatives like Meteor for fullstack and Vue for frontend.
This story goes back much further. The alternatives to Rails 1.0 were Perl, PHP 4/5, Java Enterprise Edition, and whatever Microsoft was doing. NodeJS wasn't a thing for a long time. The "client", as such, was just the features available in browsers of the time. "MEAN" came in much later. At that time people were really wanting to build heavier JavaScript clients for the first time ever.
Perl and PHP aren't comparable to Rails. Perl and PHP were languages, Rails is a framework built using the Ruby language. What's comparable to Rails in the early days was codeigniter, CakePHP, and later Symfony
Long live PHP, probably my grandson would learn this.
This was the dumbest take I ever heard,
8:04 - 8:19
it ends in "...into our own best solution"
a JS Frankenstein can't be compared and accounted as better compared to Laravel or Ruby(That is truly open source)
I'm a TS/JS Developer but this is absolutely wrong.
I get overwhelm trying to update and get into the modern js based web frontend thing... but even then i'm amazed by how easy it is to just pick the piece that works for you on every aspect of your app instead of having to deal with the quirks of the standard one.
is it harder to get into and learn? sure.
is it awesome once you get pass that (mostly mental) barrier? it seems to be
"I can't use Laravel or Ruby because it doesn't scale. I'd rather use NodeJs or React"- John Doe, a JS developer who builds apps that will never have more than 100K users or more than 1K request per second.
MangoDB -> MongoDB
Ok but be honest. MangoDB sounds delicious.
@@LukePighetti I'll leave you the NoSQL constraints :)
Js has had its batteries included frameworks, from meteorjs to sailsjs, the problem is the same with anything js, it had about 40 of them with one new every week
In linux or android space its called fragmentation
Something that is beautiful is that you can choose your tools, or you can adapt to what the company you work for does.
It is common that Next.js is used just for the marketing site (weird) but the app is a React SPA with a backend (Express, Java Spring, .Net Core, Rails, PHP/Laravel)
Fair points, it is true that JS provides you a box of legos, and as such is no different from when I was using jQuery and finding libraries people have made for it that solved the problems I was facing (mainly galleries). One thing that I really enjoy with Laravel is that I don't have to setup the boilerplate stuff - I know I'm going to need queue runners, caching, etc, so having those already setup is quite nice - I can just focus on the business logic more.
2:19 "Mango DB" lmfao
With stuff like Django or Symfony, you know you can trust what you use and that it won't likely stop being maintained anytime soon. In js, there's many times I've been interested in a tool but because one guy was in charge it stopped being maintainted. It's fine for personal projects but too risky for professional uses. It can be pretty hard to predict what will change or disappear in the next 2 years in JS except for a few big projects
Laravel mentioned! let's goooo
In the roundup what is really missing is the lifetime of these js projects. No real company or there likes the idea that the tech they build upon is gone in a year or two because the creator just found a new toy to play with. Reflect on that for a bit and you'll see how big pita it is for any non startup company to find a stable solution they can rely upon to build their business on. The documentation, blog posts, problems solved on SO also drives from they agree and community size built around a project. That's what companies are looking for. Not, toys or weekend projects.
Adonis Js