mgsmus Proje büyük ise, mobil gibi istemciler olacak ve/veya ekip gerektiriyorsa ya da zamanınız varsa;
API (RESTful ya da GraphQL)
Proje küçükse ve/veya ekip gerektirmiyorsa;
Blade kullanılacaksa;
Livewire
Splade
Blade + Alpine.js
Blade kullanılmayacaksa
Inertia

Bu bilgiler doğrultusunda Livewire araştırıyordum bulduklarım redditten
https://www.reddit.com/r/laravel/comments/w5xayz/livewire_any_experience_on_mediumlarge_size/?sort=new

yukardaki bağlantıdan devamını orjinalini okuyabilirsiniz bir kaçtane kötü yorumu seçtim iyi yorumlarda yok değil

1

I love livewire. Using it for a commercial application with a few thousand users. It’s used for dynamic things like a calculator or product configurator only, not every single page.

Google Translate
Livewire'ı seviyorum. Birkaç bin kullanıcılı ticari bir uygulama için kullanmak. Her sayfa için değil, yalnızca hesap makinesi veya ürün yapılandırıcı gibi dinamik şeyler için kullanılır.

2.

We used Livewire for more than 10 commercial projects now, and as much as it was really easy to implement, from time to time you will hit some obstacles when you have to implement some hacks and sometimes you will not even be able to trace the issues that easily, in the end we moved to VueJS and we are doing much better, takes more time to implement but it feels much much more comfortable

Google Translate
Livewire'ı şu anda 10'dan fazla ticari projede kullandık ve uygulaması gerçekten çok kolay olsa da, zaman zaman bazı hack'ler uygulamak zorunda kaldığınızda bazı engellerle karşılaşacaksınız ve bazen sorunları takip bile edemeyeceksiniz. bu kadar kolay, sonunda VueJS'ye geçtik ve çok daha iyisini yapıyoruz, uygulamak daha fazla zaman alıyor ama çok daha rahat hissettiriyor

3.

Try using livewire anywhere other than local development and tell me it doesn't suck.

Only use it if you want to a) ruin your servers performance and b) give anyone who isn't close to your server a horrible user experience.

Google Translate
Livewire'ı yerel geliştirme dışında herhangi bir yerde kullanmayı deneyin ve bana bunun berbat olmadığını söyleyin.

Yalnızca a) sunucularınızın performansını bozmak ve b) sunucunuza yakın olmayan herkese korkunç bir kullanıcı deneyimi yaşatmak istiyorsanız kullanın.

4. haksızlık yapmamak adına birde iyi bir yorum eklemek istedim

Livewire is the way to go - I have built several large systems. With some sprinkling of AlpineJS. The advantage of Livewire is that all your project is PHP. It simplifies deployment, simplifies tooling, and simplifies hiring. When you put React in with Inertia, you span a small team over two technologies.

Google Translate
Livewire gitmenin yolu - Birkaç büyük sistem kurdum. Biraz AlpineJS serpme ile. Livewire'ın avantajı, tüm projenizin PHP olmasıdır. Dağıtımı basitleştirir, araçları basitleştirir ve işe almayı basitleştirir. Inertia ile React'i dahil ettiğinizde, küçük bir ekibi iki teknolojiye yayıyorsunuz.

5. favorim

Be wary of infitely loading things or letting your component state get out of hand as it could cause a large amount of html to be rendered slowing down response times. For example if you infintely loaded pages in a feed the components html get's larger and since livewire sends the html over the wire this will increase the response size exponentially with each re-render despite only getting say 20 results per page as it's rendering the entire component with the now 10 pages worth of results.

Also working with javascript plugins are a nightmare in alpine which are all way easier to work with using a javascript framework with imports etc. With a javascript framework you also don't have to wait for the page to load either or ensure that a library is loaded before using it. Also some editors can't interpret the javascript inside of an x-data attribute so you don't benefit from your editor as it thinks it's just another html attribute.

Managing complex child components is also a major pain point in livewire as you now need to manually handle re-rendering a parent when something in the child changes that needs to cause the parent to re-render by emitting events. You almost feel compelled to never have child components and just have one mega component for the whole page.

If you want to wire:model some custom class or piece of data that isn't an array, collection, string, int or model you have to manually handle how it is serialized and deserialized during hydration/dehydration of the component state. So something like a simple data transfer object or value object is a pain to maintain if it ever get's changed because now you also need to maintain how it's serialised/deserialised for livewire.

Maybe im just bad and there's some simple solutions to the things I've ran into above but those are some of the things i can think of where you wouldn't have these problems by going with a front end framework.

I've always thought that for small/simple apps livewire is best, and for something more complex/large a more mature framework like react would be better.

Google Translate

Sonsuz bir şekilde yükleme yapmaktan veya bileşen durumunuzun elden çıkmasına izin vermekten kaçının, çünkü bu, yanıt sürelerini yavaşlatan büyük miktarda html'nin oluşturulmasına neden olabilir. Örneğin, sayfaları bir beslemeye sonsuz olarak yüklerseniz, html bileşenleri büyür ve livewire html'yi tel üzerinden gönderdiğinden, bu, tüm bileşeni oluştururken sayfa başına yalnızca 20 sonuç almasına rağmen, her yeniden oluşturmada yanıt boyutunu katlanarak artıracaktır. şimdi 10 sayfalık sonuçla.

Ayrıca javascript eklentileri ile çalışmak, alplerde bir kabustur ve içe aktarma vb. içeren bir javascript çerçevesi kullanarak çalışmak çok daha kolaydır. Bir javascript çerçevesi ile ayrıca sayfanın yüklenmesini beklemeniz veya bir kitaplığın olduğundan emin olmanız gerekmez. kullanmadan önce yüklenir. Ayrıca bazı editörler javascript'i bir x-data özniteliği içinde yorumlayamazlar, bu nedenle editörünüz onu başka bir html özniteliği olarak düşündüğü için yararlanamazsınız.

Karmaşık alt bileşenleri yönetmek, ayrıca, alt öğede olaylar yayarak ebeveynin yeniden oluşturulmasına neden olması gereken bir şey değiştiğinde, bir ebeveynin yeniden oluşturulmasını manuel olarak ele almanız gerektiğinden, livewire'da önemli bir sorun noktasıdır. Neredeyse hiçbir zaman alt bileşenlere sahip olmamaya ve tüm sayfa için yalnızca bir mega bileşene sahip olmaya mecbur hissediyorsunuz.

Bir dizi, koleksiyon, dize, int veya model olmayan bazı özel sınıfları veya veri parçalarını kablolamak istiyorsanız: bileşen durumunun hidrasyonu/dehidrasyonu sırasında nasıl serileştirildiğini ve seri durumdan çıkarıldığını manuel olarak ele almanız gerekir. Bu nedenle, basit bir veri aktarım nesnesi veya değer nesnesi gibi bir şeyin değişmesi durumunda bakımı zahmetlidir çünkü artık livewire için nasıl seri hale getirildiğini/seri hale getirildiğini de korumanız gerekir.

Belki sadece kötüyüm ve yukarıda karşılaştığım şeylere bazı basit çözümler var ama bunlar, bir ön uç çerçeve ile bu sorunları yaşamayacağınız yerlerde düşünebildiğim şeylerden bazıları.

Her zaman küçük/basit uygulamalar için livewire'ın en iyisi olduğunu ve daha karmaşık/büyük bir şey için tepki gibi daha olgun bir çerçevenin daha iyi olacağını düşündüm.