@taylorotwell do not step on NextJs' footprints #55533
Replies: 3 comments 1 reply
-
A more modular approach could be beneficial here. But that kind of is the approach of laravel zero, I guess ... |
Beta Was this translation helpful? Give feedback.
-
Laravel is split up quite well into the illuminate domains actually. Let's not forget that Laravel has always expressed itself as full featured for the sake of cohesion. Laravel provides whole systems more so than just features. It's generally accepted that these systems are usually requisite. Having them all from the same tribal knowledge source with the same mission ensures they play well together. Have you ever worked on large applications that use a comparable set of systems that were all home grown? One developer wrote some parts with others in mind then left to work somewhere else now another comes along and works on trying to finish some of those other parts with no knowledge or insight into the former's plans or designs. The result is usually quite messy and at some point becomes very hard to work on. It's true that it must be done carefully, but it's not our design so we'll likely be missing parts of the picture. Moreover we don't own it so it is out of our hands. We can only hope that whatever special sauce has guided @taylorotwell thus far will continue to hold. I suspect it will. It's certainly not unprecedented. In my mind, Laravel has more in common with Linux and cURL than it does with NextJS. Despite a recent spurt of promotions and campaigns, it's still a comparatively quiet backbone of the web, and its success and adoption is still more driven by its usefulness and usability than anything else. And yes, I wrote those three whole paragraphs all on my own. |
Beta Was this translation helpful? Give feedback.
-
Laravel cloud code in laravel: #47448 (comment) |
Beta Was this translation helpful? Give feedback.
-
https://medium.com/dev-simplified/why-companies-are-saying-goodbye-to-next-js-11af0a357588
@taylorotwell
We are writing this here because laravel tends to incorporate more and more overhead that should not be in the framework. Each dev should keep this overhead for his personal needs and use and not push it into the framework.
Beta Was this translation helpful? Give feedback.
All reactions