MR
Это тот же VUE только js заменили на php
Size: a a a
2021 February 10
MR
А синтаксис вью в html, на синтаксис блейда
AS
AK
Это тот же VUE только js заменили на php
не зовсім, але це прям класична реакція на livewire ) типу як так
MR
не зовсім, але це прям класична реакція на livewire ) типу як так
Ну не зовсім, але якщо описувати просто і абстрактно то так)
AK
ну тут сразу пахнет в будущем проблемой кастомизации, жопой чую))
ну github гарно з таким підходом працює і ніби все ок
AS
Также в минусы лайввера можно вынести 1) больше learning curve, 2) инструмент вообщем и целом только под Лару, это приводит к тому что внедрить фронта извне сложнее, а опыт который приобретают разрабы работая с liveware менее универсален и востребован на рынке, чем если бы разрабы работали с React.js instead, for instance
J
Это тот же VUE только js заменили на php
Есть большой опыт на Drupal(надеюсь его тут можно упоминать) - там тоже есть такой ajax-фреймворк, очень удобно было
AK
нужно сделать сложный фронтовый элемент, нужно внедрить фронта мощного, а в пхп его внедрить сложно, отдельные куски не в пхп писать тоже странно выйдет. Это же кажеться старый подход, юзаелся в симфе для постройки форм и в уии для виджетов, а модно и современно фронт на фронт-фрейме пилить
в режимі spa цілком а ось коли багато сторінок такий підхід дозволяє
- покращити тестування
- не дублювати область знань (коли формуєш api не бекенді і те ж саме api юзаєш на фронті)
- покращити кешування та пререндеринг
- покращити тестування
- не дублювати область знань (коли формуєш api не бекенді і те ж саме api юзаєш на фронті)
- покращити кешування та пререндеринг
AS
ну github гарно з таким підходом працює і ніби все ок
а фейсбук и порнхаб гарно працюють на пхп)))
AS
AS
Есть большой опыт на Drupal(надеюсь его тут можно упоминать) - там тоже есть такой ajax-фреймворк, очень удобно было
jquery ?
AK
Также в минусы лайввера можно вынести 1) больше learning curve, 2) инструмент вообщем и целом только под Лару, это приводит к тому что внедрить фронта извне сложнее, а опыт который приобретают разрабы работая с liveware менее универсален и востребован на рынке, чем если бы разрабы работали с React.js instead, for instance
ну власне для таких проектів де треба окремий фронт як на мене ідеально підійде inertiajs
AK
ну власне для таких проектів де треба окремий фронт як на мене ідеально підійде inertiajs
там можна і на рубі бекенд фігачити)
MR
ну власне для таких проектів де треба окремий фронт як на мене ідеально підійде inertiajs
Взагалі не зайшла, двічі пробував використати
MR
Можливо треба дати третій шанс
AK
Взагалі не зайшла, двічі пробував використати
ймовірно просто не було підходящого проекту
AS
в режимі spa цілком а ось коли багато сторінок такий підхід дозволяє
- покращити тестування
- не дублювати область знань (коли формуєш api не бекенді і те ж саме api юзаєш на фронті)
- покращити кешування та пререндеринг
- покращити тестування
- не дублювати область знань (коли формуєш api не бекенді і те ж саме api юзаєш на фронті)
- покращити кешування та пререндеринг
а что значит - не дублировать область знаний, всмысле доку делать не надо
AK
Взагалі не зайшла, двічі пробував використати
якщо це не crm чи spa то цілком імовірно що просто не буде особливо профіту
AS
в режимі spa цілком а ось коли багато сторінок такий підхід дозволяє
- покращити тестування
- не дублювати область знань (коли формуєш api не бекенді і те ж саме api юзаєш на фронті)
- покращити кешування та пререндеринг
- покращити тестування
- не дублювати область знань (коли формуєш api не бекенді і те ж саме api юзаєш на фронті)
- покращити кешування та пререндеринг
это плюсы, а какие недостатки такого подхода, если бы мы делали на React.js, всмысле в сравнении с реактерством ?