JavaScript: где мы сейчас и куда двигаться

Вообще-то плагины не только ДОМ.

JavaScript: где мы сейчас и куда двигаться

>В первую очередь при разработке чего-то большого необходима структура и модульность.

Это так сложно разбить код хотя бы на файлики?

>jQuery структуру не предоставляет

А плагины?

>и большая часть любителей jQuery не способна самостоятельно задать гибкую структуру.

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

JavaScript: где мы сейчас и куда двигаться

Хабр не туда коммент вставил :)

JavaScript: где мы сейчас и куда двигаться

Я не спорю, для многих сайтов (скорее приложений с веб-интерфейсом) больше может подходить какой-то фреймворк.

Но вот как раз фейсбук не такой сайт.

Вот почему у них миллионы строк кода?
Потому что, грубо говоря, не используют jQuery, а городят огороды.

https://habrahabr.ru/post/308148/

Вряд ли стоит писать на голом js.

Не используйте Illuminate Support

То есть на самом деле повторное использование кода — зло? :)

Тогда не используйте вообще фреймворки.

JavaScript: где мы сейчас и куда двигаться

Как по мне, фейсбук (автор Реакта) не тот сайт, для которого нужно было городить огород.
Там хватило бы и jQuery.
Код должен быть понятен большинству, а не только крутым перцам.
Такой код дороже.
А еще фейсбук память жрет.

Зачем нам jQuery?

А так:
https://www.google.com/trends/explore?q=jQuery,AngularJS,%2Fm%2F012l1vxv
?

https://habrahabr.ru/post/308148/

Cистематическая уязвимость сайтов, созданных на CMS 1С-Битрикс

1. Но предалагается, чтобы Битрикс что-то фиксил.
2. Один из способов, но не панацея. xss успешно пролезают через него, если понадеятся только на него.
3. Ну в этом случае сырые данные может не нужны. А в другом нужны.
Допустим name — это логин.
Тогда для фильтрации обработку нужно будет использовать еще в фильтре.
А если мы потом изменим второй параметр в htmlspecialchars($_POST['name'], ENT_QUOTES);
Или захотим вообще вырезать hmtl.
Или нужно пропустить часть html — ссылки, списки, рисунки (в комментрии пользователя к статье).
:)

Cистематическая уязвимость сайтов, созданных на CMS 1С-Битрикс

1. Это не вина Битрикса, что разработчики не думают головой. Такое можно сделать везде.
2. htmlspecialchars и т.п. — не панацея от xss.
3. Часто нужно хранить сырые данные.

Прощай, объектно-ориентированное программирование

Тогда зачем было лепить из ООП дуру, если три кита, на которых он стоит — фигня? :)

П.С.
ООП использую в меру, без фанатизма.

Как мы ускорили PHP-проекты в 40 раз с помощью кэширования

Сорри, немного натупил :)
Но первый вопрос актуален.

Как мы ускорили PHP-проекты в 40 раз с помощью кэширования

Так у вас используется lsyncd для дистрибуции кеша или кеш генерируется обходом бота?
Сколько у вас nginx серверов?
Я понял из предыдущего ответа, что 1.

Как мы ускорили PHP-проекты в 40 раз с помощью кэширования

Вроде написано было 1-3.

+Это же вордпресс со множеством плагинов :)

Как мы ускорили PHP-проекты в 40 раз с помощью кэширования

Вы просто не умеете его готовить :)

Хотя там вроде порядка 40 серверов.
Кеш на каждом отдельный.

Как мы NoSQL в «реляционку» реплицировали

Как правило, SQL натянутый на нереляционные структуры всегда не полноценный

Это уже второй вопрос.
Если движок не позволяет делать группировки/джойны/другое, то это не вина SQL. :)

Это всего лишь язык запросов. :)
Это не сама СУБД.

Это примерно как в чай в большистве случаев добавляют сахар.
Но это не значит, что чай равняется сахару :)

Как мы NoSQL в «реляционку» реплицировали

Промазал веткой почему-то :)

Станет ли Twitter вторым «Yahoo!»

Если там только боты, то не это ли конец? :)

Как мы ускорили PHP-проекты в 40 раз с помощью кэширования

>это привело бы к тому, что если пришел первым HEAD запрос, то он бы попал в кэш и для GET запросов отдавался кэш от HEAD.

Можно было добавить в ключ метод :)

Не знаю, как для фастцги, но прокси позволяет кешировать GET и HEAD (любые другие методы) вместе, отправляя 1 GET запрос на бекэнд.

да, именно так — у каждого свой fastcgi cache

Вы сами себе создали проблему, а потом ее решили костылями :)

Как мы ускорили PHP-проекты в 40 раз с помощью кэширования

кэш на каждом из серверов для одного и того же приложения был свой, пусть и одинаковый.

То есть было примерно так:

upstream php-fpm7.0 {
        server 10.0.0.1;
        server 10.0.0.2;
}

?
И для каждого сервера-бекэнда был свой фастцги-кеш?

использовать lsyncd для дистрибьюции кэша между нодами апстрима

Или выше Вы говорили не о фастцги-кеше, а о кеше приложения?..
Может стоило использовать мемкеш/сетевую фс?
Или у Вас несколько nginx + несколько php?

Соответственно были подтюнены опции fastcgi_cache_path и fastcgi_cache_valid.

Может нужно было просто прописать:

fastcgi_cache_key   $uri;

Могли бы переехать на cloudflare :)

Как мы NoSQL в «реляционку» реплицировали

>Смысл в надежности.(за 8 лет не было серьезных сбоев) и быстроте продукта

Как это достигается? Транзакции пишутся сразу? У меня за 8 лет тоже сбоев не было на mysql. Правда, нагрузок тоже.

>Уточните пожалуйста, что было перепутано?

SQL — это лишь язык запросов, интерфейс доступа, его можно успешно применять и для нереляционных баз.

Вот Сфинкс имеет несколько интерфейсов, в том числе и SQL.

>например создавать индексы прямо в «поддеревьях»

А обновить только один ключ в каше можно? :) Или нужно перезаписывать всю кашу?
Такие индексы будут тупить при обновлении?
Ну и на сколько они эффективны по сравнению с индексом по полю?