Pull to refresh
0
0
Send message
Мне кажется, для сайтов, которые по сути являются веб-интерфейсом, кабинетом по управлению чем-то.
Почему Вы сделали такой вывод? :)

(Если там хардкорный SQL, то какой же это QB? :^) )
О, норм, спасибо.

Жаль, что это в документации меньше видно, нежели унылые:
andWhere()
и
orWhere()

Раньше считал QB унылым, но вот в Yii видимо не такой унылый :)
> Под капотом всё равно SQL.

Ну это понятно :)

> Aura.SqlQuery — очень добротно выглядит, и никаких проблем использовать с CleverStyle Framework (как и с любым другим).

Я бы не сказал, что ее Query builder чем-то отличается от упомянутых Вами в статье. :)
PHP тоже язык быдла.
Но я имел в виду JS.
:^)
Сайты, которым нужна индексация, не являются теми типами сайтов, для которых оправдано использовать ReactJS.
Это лишь дань моде.

Замечание относительно изоморфности.
То Вы говорите, что круто, что ничего не генерится на сервере, то вдруг круто, что все генерится еще и на сервере.
Как бы можно это понять, если все на том самом коде. Но в статье 2 разные языка.
Да и вряд ли реакт быстро сгенерирует страничку на сервере. Хотя c кешированием ОК.
Только странно, что сайт должен оживать, а не живой сразу.
Зачем 2 раза гонять те же самые данные? :) Сначала в HTML, потом в JSON (JS).
В тенденциях выиграете, в простоте проиграете :)
1. L. Тогда не стоит использовать наследование. :)
2. O. Если писать не публичную библиотеку, то можно не придерживаться этого принципа.
Замечания к Рисунку «Разница в производительности CPU и DRAM»:
1. Во первых он не в асболютных величинах (Или все же там мегагерцы? Просто в 2000 у памяти было явно больше 10 МГц, 100 уж точно)
2. Некорректное соотношение между частотами CPU и DRAM, если это относительные величины.
> ->where($condition)

А как сконструировать условие типа
(a = 'a') AND (b = 'b' OR c = 'c')
или
(a = 'a') OR (b = 'b' AND c = 'c')
?
>Query builder так же слишком далёк

+1. Во фреймворках они какие-то унылые.

>Итак, с подходом стало ясно — будем писать SQL.

Это перебор :)

>Уверен, что портирование таких монстров, как jQuery, потребовало немало приседаний.

То есть он (TS) не совсем совместим с JS?
Чтобы все работало, это все должно быть на TS?
Нафиг такое нужно. :)

П.С. (Утверждения немного преувеличенные)
Что вы к нам (JS) приползли со своим TS. Создайте себе отдельный браузер. :)
Причина популярности JS — кажущаяся простота. Крутые перцы захотели писать на языке быдла, потому что быдло создало большую экосистему, которую перцы не смогли создать.
Необходимость отступов на ровном месте очень противоречива.
Код похож на решето. :)
Хм, таки да, Maria 10.1 + InnoDB не блокируется. :)

Спасибо, буду знать.
А как блокировки в mysql? :^)
Ликбез по типизации:
https://habrahabr.ru/post/161205/
Стоит ли делать миграции БД средствами фреймворка на базе 2 TB?
Также, как и фреймворки на php.

А jQuery хотя бы удобный. :)
>Любой веб-проект на деле намного сложнее чем кажется.

Не спорю.
С морды всей кухни не увидеть.
Но js это более морда и не понимаю, чего там у ФБ такого сложного.

ЛС
Подгрузка ленты
Комменты

Там больше сложностей на бекэнде, а не на фронте.
>Вы хоть раз видели, как кто-либо пишет код проекта плагинами?

Нет.
Сам использую их только для повторного использования.
Но ничто не мешает.

>В том и дело, что «большая часть любителей jQuery» этим даже не заморачивается.

Ну да, это большинству просто не нужно. :) Вы тоже не используете jQuery из-за того, что кто-то что-то не умеет? :)

>А если в проекте собрались «крутые перцы», которые могут написать «по уму», то почему бы им не взять более удобную технологию?

Выходит менее понятно :)
Куча дырявых абстракций.
https://habrahabr.ru/post/308154/#comment_9763712

Удобную, но более сложную, технологию стоит использовать, когда это оправдано.
Для сайта вроде ФБ и проще вряд ли это оправдано.

Кому-то нравиться прыгать с технологии на технологию, а кто-то решает задачи.

Information

Rating
Does not participate
Registered
Activity