Point is that all apps tend to get bigger. So why postpone necessary?

I think that I implicit answer this questions in my 2 long answers after it. But for the sake of clarity, I will answer explicity.

I don't think that all apps tend to get bigger. I make for many customers web apps and mobile apps that simple remain as-is since first release, for years. Or they don't have cost for further development, or they close business for other reasons. Or they are happy with current stage. I have even my commercial social network application still running with PHP 5.x and PhalconPHP 1, still being used by several customers. Now nearly 2 years not updated apart minor fixes. Technology move fast, and I see that most of your application is more easy to refactor than upgrade to new one. This happen with an Angular 1 app, with several Ionic app, Phalcon PHP, and I think also for switching from Laravel 4 to 5.

I don't start a project thinking on abstractions immediately, I do that when in phase of polishing the code, when I see necessity of extraction of code. Refactoring is part of that process.

I think an inexperienced programmer starts thinking about abstractions at first, I used to do that too. But it is impossible to predict the evolution of the code unless you do a month of analysis with UML digrams and everything else. They raise development costs that customers are not happy to pay. I'm not saying they don't need to be done, on the contrary, in some projects they are essential. But in small to medium projects they are not. I prefer to keep the code as simple as possible at the beginning, even if that means repeating the code a few times. And only towards the end if I see the need I extract the code. But often this is not necessary.

Again, if you are large company working with many developers, then you may think differently. But being a solo developer or small team, you can't afford to work as a company.

Now, Jetstream/Fortify offer abstractions for handle 2 frontend, which I will never use. And this abstraction make code more complicated to manage. Something that I and other developers don't need make your starting point already complicated.

I hope that I did explain well myself.

May Jetstream be with you.

I don't think that all apps tend to get bigger. I make for many customers web apps and mobile apps that simple remain as-is since first release, for years. Or they don't have cost for further development, or they close business for other reasons.

I'm not sure that those kind of projects qualify to be a part of this discussion. That is mostly a procedural solution, not OOP one.

I don't start a project thinking on abstractions immediately, I do that when in phase of polishing the code, when I see necessity of extraction of code. Refactoring is part of that process.

When you notice that you are missing abstractions, at that point your code is such a mess that you have to spend exponentially more time and energy to fix it.

I think an inexperienced programmer starts thinking about abstractions at first, I used to do that too.

I disagree. Inexperienced programmers do not worry about abstractions, almost never. Experienced worry about abstractions. That is why when someone becomes senior they progress to system architect positions and "only" worry about abstractions and pitfalls.

But it is impossible to predict the evolution of the code unless you do a month of analysis with UML digrams and everything else. They raise development costs that customers are not happy to pay.

Customers always want to pay as little as possible, but that does not justify the cost they will have to pay later when they hit a brick wall. Your job is to explain it to them why you need to do it properly, cause that is the exact reason why they've hired you, to save them money in a long run.

I prefer to keep the code as simple as possible at the beginning, even if that means repeating the code a few times. And only towards the end if I see the need I extract the code. But often this is not necessary.

DRY is allowing you to have even simpler code that is easier to maintain.

But being a solo developer

As I said in my first sentence in this reply, this also should be excluded from this discussion. Hacking a solution is not about quality. It is just about the speed and your initial thoughts. That is a procedural solution situation, not OOP one.

Now, Jetstream/Fortify offer abstractions for handle 2 frontend, which I will never use. And this abstraction make code more complicated to manage.

Only bad abstractions make code harder to manage. Good ones do not. For example Laravel Cashier make it easier to integrate payments into your system. That is the same with Jetstream/Fortify. Are you saying that Jetstream/Fortify implementation is bad?

May the (Laravel) Forge be with you 😁

@bugsysha and @thewebartisan7 I will share a small secret:

OOP is for us (humans) in separating code to various classes, but yet there is no such thing as OOP.

At runtime it's all run procedurally.

Basically our separation is plucked apart and put back together into the lines that the processor can process. The cpu could care less where it all comes from.

But a side note, I don't mind fat models.

@jlrdw I guess you wanted to mention me and not @thewebartisan7 twice?

@bugsysha yes sorry about that.

@jlrdw no problem man. That is a nice philosophical point of view. Never thought about it that way. But since we are humans, we have to write code that we understand or this will get exponentially harder to do anything.

@jlrdw I know that "secret". I am not sure to get your point. I am not saying anything against OOP or separation of code. Working with any MVC framework you are already forced to separate your code in very well manner. With Laravel you have also several others way to separate your logic (form requests, policies, middleware, service providers, resources, etc.).

@bugsysha if working with Laravel standard API is "procedural solution" then we have different view what is a procedural solution. Experienced developer make worry about abstraction when there is need to worry about abstractions. Where there is not, then keep it simple. The refactoring and abstraction stuff, ie polishing code, is something that I enjoy to do, is not something to fix, but rather something to improve. And what I see there is not a general abstraction right for any project, rather is something specific to application/project.

DRY in Jetstream is only to handle multiple frontend which I and most probably you and most of us will never need to manage. It's a solution dedicated to Jetstream. Is not a solution for any end application.

You can't compare Laravel Cashier with Jetstream, first is "an expressive, fluent interface to Stripe's subscription billing services." while second is "a beautifully designed application scaffolding for Laravel.".

Can you see difference?

Last, I am not saying Jetstream implementation is bad, but rather is not appropriate for common usage as what aim to be a "scaffolding application".

In my very first reply I didn't say "stay away from Jetstream, that is bad implementation", but I start with this word "I think that it depend on project that you are working.".

if working with Laravel standard API is "procedural solution" then we have different view what is a procedural solution.

Nah, you got me wrong. See how it is hard to discuss this things without looking at code?

Can you see difference?

Nope? In general both are first party packages that provide abstractions for problems they are solving.

Last, I am not saying Jetstream implementation is bad, but rather is not appropriate for common usage as what aim to be a "scaffolding application".

So you are against it cause it makes you use Livewire or Inertia?

In my very first reply I didn't say "stay away from Jetstream, that is bad implementation", but I start with this word "I think that it depend on project that you are working.".

So you are saying that Jetstream is an unnecessary abstraction and people should use laravel/ui instead if they do not plan to use Livewire/Inertia? Ofc if developer does not need all what Jetstream is offering.

I'm getting that feeling again that just by working on different kind of apps you and me are talking only about our use-cases.

Nope? In general both are first party packages that provide abstractions for problems they are solving.

We could now speculate with words, but I see Cashier solving 1 problem, extracting logic that can be re-used in several project. While a scaffolding, or boilerplate such as Jetstream doesn't solve 1 problem, has authentication, team, UI for 2 different frontend, etc. But taking into account your answer could be seen as the same.

So you are saying that Jetstream is an unnecessary abstraction and people should use laravel/ui instead if they do not plan to use Livewire/Inertia?

Seem that you finally get my point. Thanks God. I mean exactly that. IF they don't plan to use Livewire/Inertia BUT even if they plan to use Livewire or Inertia there is unecessary abstraction. Because they will use Livewire OR Inertia. Is necessary abstraction only if they use both.

So you are against it cause it makes you use Livewire or Inertia?

This will raise I think another discussion for another week, so I think is better for me to not comment this. It's that fine for you or you would like to hear my opinion regarding this?

We could now speculate with words, but I see Cashier solving 1 problem, extracting logic that can be re-used in several project. While a scaffolding, or boilerplate such as Jetstream doesn't solve 1 problem, has authentication, team, UI for 2 different frontend, etc. But taking into account your answer could be seen as the same.

Solving one or multiple problems does not make a difference in my book if that is what I need.

Seem that you finally get my point. Thanks God. I mean exactly that. IF they don't plan to use Livewire/Inertia BUT even if they plan to use Livewire or Inertia there is unecessary abstraction. Because they will use Livewire OR Inertia. Is necessary abstraction only if they use both.

Then why didn't you say so? I'm always for using and depending on as less as possible cause it is just one more breaking point I have to worry about. And I thought I was bad with words 🤣

This will raise I think another discussion for another week, so I think is better for me to not comment this. It's that fine for you or you would like to hear my opinion regarding this?

I though you've already answered this, but please speak now or forever hold your peace. We are finally on a common path, maybe I can hear something useful.

BUT even if they plan to use Livewire or Inertia there is unecessary abstraction

From this I can see that you do not want to depend on packages and want to do as much is possible manually so you can have full control over it. I can understand that. But as you said, speed at which you develop stuff is also important and we have to measure what matters more to us.

I'm glad we were able to understand each other.

From this I can see that you do not want to depend on packages and want to do as much is possible manually so you can have full control over it.

Yes but I don't want that you maybe misunderstand. I don't want that you think that I want re-invent the wheel. If I need a package, backend or frontend, I am more than happy to use it. But of course if I don't need it, then why I should keep it? Who want?

Now regarding your last questions regarding Livewire and Inertia. First about Livewire. Shortly, it's a good package for those who are not good with JS. It allow to create interactive page writing only PHP. But for a full stack developer who love frontend development like me, then is not solving any problem, rather is adding only new problem to solve. Many love concept of making interactive page without writing JS, and Caleb do good job delivering something that many need. But comparing it to original idea which it come from, which is Phoenix LiveView (https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html), Livewire is just ajax requests vs socket of Phenix LiveView. Totally two different world.

I make the same result of Jetstream with Fortify and now doing the same with Laravel UI, but even better since all page and forms (also auth forms) is loaded via ajax using axios and turbolinks. So the same interactive UI which aim to offer Livewire.

I also think that is still not mature project, but that is minor issue, considering it popularity it will become mature very soon. But at the current stage I would not use it in production.

Alpine has similar issue, I just don't like to put JS inside HTML and trying to get my head around how to solve something that I can quickly and more eleganty do with plain vanilla JS. There is another one which do similar things, https://htmx.org/ and it can be good for developers who can't work with JS.

In my opinion nowday developers must consider to learn also JS, and Livewire has potential to delay this if developer use it.

I could say more things specifically about Livewire that I found, but I think and hope you get my main points.

Inertia on other hand I like a bit more because you still write JS on frontend, and if you change backend, you can still use your frontend, while with Livewire you can't. If I have to choose between the two, then Inertia would be winner. But maybe I am a bit too conservative and still prefer old fashion with API on backend and routes via VueJS (my preferred).

Last thing not less important. I can't work with Tailwind. I really try but I can't. Maybe after so long time working with Bootstrap and other OOCSS I can't change my habit and switch to something so "low-level" to use Adam words. Maybe is only question of habit. I like the Adam TailwindUI, and I consider to use it, but for now I can do just with Bootstrap much faster what I can with tailwind. There are also several things that seem TailwindCSS can't solve. But that is another story.

Yes but I don't want that you maybe misunderstand. I don't want that you think that I want re-invent the wheel. If I need a package, backend or frontend, I am more than happy to use it. But of course if I don't need it, then why I should keep it? Who want?

I wanted to say that you are not reinventing the wheel, but if you need small portion of what that package offers and it is very easy to implement then you would opt out for building it yourself. That is the same approach I use and for example I do not understand why people use spatie permissions package. it is so much simpler than using the package. Almost every 5th question here on Laracasts is about that spatie package.

Thanks for sticking with me on this topic. All best.