[pangolin]

Krótkie pytanie #php #webdev

#laravel czy #symfony i dlaczego?

[JamesMoriarty]

@pangolin: Phalcon (｡◕‿‿◕｡)

[micke]

@pangolin: Symfony bo to prawie jawovy Spring. Jak php da ci raka to laravel da ci raka z przerzutami do mózgu na złe podejście.

A co do porad to kod framework less i korzystaj z takich komponentów jakie ci najbardziej pasują / są potrzebne

[pangolin]

@JamesMoriarty: Słabo dostępny na hostingach

@micke: Co złego jest w podejściu z laravela?

[JamesMoriarty]

@pangolin: Z technicznego punktu widzenia odpalanie jakiegokolwiek framework'a na zwykłym hostingu to zły pomysł ¯\_(ツ)_/¯

[pangolin]

@JamesMoriarty: Co takiego złego jest w hostingu, że framework na nim to zły pomysł? Trzeba mieć aż taki wpływ na konfigurację serwera aby wszystko dobrze działało?

[Hipodups]

@pangolin: larqvwl niski prog wejscia, ale duza swoboda, przez co podatny na zle praktyki.

[aso824]

@pangolin: Odpowiedź jest tylko jedna - to zależy.
Jak stawiasz małą/średnią appkę i chcesz ją postawić szybko oraz nie sądzisz żeby to się przerodziło w dużą firmę - brałbym Laravel, bo szybciej się w nim tworzy.
Jak tworzysz coś co ma być używane przez lata i rosnąć dowolnie, a przy okazji znasz wzorce (bo z kontekstu zakładam że w czymś innym programowałeś już?) to Symfony będzie lepsze.

Oczywiście możesz postawić małą

[JamesMoriarty]

@pangolin: Przykładowo Symfony do konfiguracji używa zmiennych środowiskowych, a nie wszystkie hostingi na nie zezwalają. Można użyć komponentu dotenv, ale on jest bardziej do dev'a przeznaczony. Jest sporo komend CLI dla Symfony, a hostingi rzadko dają dostęp do SSH, a jak już to mocno okrojony.

Nie zrozum mnie źle. Symfony jak najbardziej pójdzie na hostingu. Są CMS'y, które korzystają z samego framework'a lub jego komponentów. To tylko kwestia tego, że jest

[getin]

hosting współdzielony (lub niewiadomy), mały projekt -> codeigniter
szybkie wejście, krótki projekt, praca w zespole -> laravel
długofalowy projekt, praca w zespole -> symfony
bardzo duży projekt -> co innego niż php ( ͡° ͜ʖ ͡°)

[micke]

@pangolin:

Tłumaczę co jest #!$%@? w Laraverze:
- config przez array php
- Fasady
- Routing
- Walidacja pełna błędów
- Brak kompatybilności z wersjonowaniem MAJOR.MINOR.PATCH (tylko maja 5.MAJOR.PATCH)
- Eloquent -> brak dobrych modeli, masa magicznych metod
- Nadużywanie Magic Methods wszędzie
- Autowire
- Magiczne odwołania do handlerów na podstawie commandów
- Jest wolny i trudny w utrzymaniu gdy ma robić coś więcej

Jak chcesz się uczyć dobrych praktyk

[micke]

@pangolin: A i jeszcze linki:

https://laravel.io/forum/12-21-2014-why-i-am-not-using-laravel

https://www.reddit.com/r/PHP/comments/3bmclk/why_experienced_developers_consider_laravel_as_a/

https://carnage.github.io/2017/02/laravel

[pangolin]

@aso824: W sumie będą dwie mniejsze apki, które po zrobienie nie będą wiele zmieniane + jedna średnia, która jeśli będzie udana to będzie dalej rozbudowywana. Każda z tych aplikacji będzie udostępniała lub korzystała z REST API.
Oprócz zrobienia tego co potrzebuje istotny jest aspekt edukacyjny, aby upiec dwie pieczenie na jednym ogniu.

@JamesMoriarty: Dwóch nie zamierzam mocno rozbudowywać w przyszłości, jedną zależy czy będzie udana. W zasadzie to można by

[Jurigag]

Słabo dostępny na hostingach

@pangolin: przecież i tak strony stawia się na vps/dedykach zwykle

[Jurigag]

bardzo duży projekt -> co innego niż php ( ͡° ͜ʖ ͡°)

@getin: swoole aby się skalowało dobrze ( ͡° ͜ʖ ͡°)