Владислав Старцев

Куки исключены, браузер не сохраняет их и не хранит историю.

1. Про evercookie слышали? А про Web Fingerprint?
На хакере перечислена масса способов хранить ID на вашем компе без использования Куков и кэша, а технология Web Fingerprint позволяет хранить цифровой отпечаток компа, браузера на сервере банка: Фингерпринтинг конкретного ПК с точностью 99,24%, не спасает даже смена браузера.

Если вы - клиент банка и заходили в его интернет-банкинг, он легко может вас опознать при использовании того же браузера и того же компа.
А если у вас на мобиле установлено приложение интернет-банкинга - вы вообще под колпаком :)

2. Если вы лазите по инету залогиненым в Вконтакте/Яндексе, то через backdoors в их API можно определить ваш профиль и все ваши данные.
Сайт Соцфишинг работает на этом принципе.
Сам банк тоже может использовать соцфишинг и ставить невидимый ифрейм на своё меню, и при клике вы автоматически авторизуетесь через аккаунт, например, Вконтакте. Зная ваш ID на Вконтакте, ваш телефон легко узнаётся, их базы регулярно сливаются и продаются

PS: Узнать как конкретно вас "слил" и каким образом - невозможно без исследования конкретной ситуации.

WordPress — система управления контентом. То есть, ключевая функция — это работа с БД, это предоставление интерфейса (читай админки) через который вы можете просто управлять контентом на сайте.

SPA — архитектура для построения интерфейса. То есть это алгоритм по которому ваш контент как-то отображается.

Совместить их достаточно просто. В общем и целом у вас должно быть две отдельные программы (на одном сервере, или на разных не столь важно)

1. WordPress который будет управлять всем что связано с контентом. Создавать новые записи, рубрики, связывать их и тд.
   
2. SPA, который просто будет принимать инфу от WordPress и как-то её отображать.
   

Оба приложения могут работать абсолютно независимо. Вы можете сделать два разных SPA (например для десктопа и для мобильных) которые будут работать с одной и той же базон полученной от WP. И даже разработкой этих независимых систем могут заниматься разные люди.

Вот статья на эту тему
https://medium.com/@moustachedesign/creating-a-web...

https://developer.wordpress.org/rest-api/

Выучите PHP.
99% открытого бэка - написано на нём.

Программистам не нужны конструкторы сайтов.

www.unheap.com

Что вы там соберетесь создавать?)
Сперва примеры готовых анимаций, теперь сколько из них может обхватить jQuery?
Если по вопросу, то он может сделать все что может css/чистый js(ну я по крайней мере не встречал анимацию которую нельзя сделать на js)

С помощью чего и как можно реализовать вот такую расстановку блоков?

На ум сразу приходит masonry.

на SVG вырез можно сделать хоть в форме котенка

Вопрос, как всегда, поставлен жутко неграмотно, так сказать, по деревенски: без какого бы то ни было видения перспективы, хотя бы на 5 лет вперёд.

Изучать какой-либо современный фреймворк ради *карьеры* - несусветная глупость. 5 лет назад ларавеля не было, а симфони и зенд были в таком виде, что мы бы сейчас обплевались. При том что различия между современными версиями довольно минимальны.

Это, я не знаю, как спросить "хочу быть столяром, какую отвёртку мне изучать, крестовую или шлицевую?".

Изучать, ради карьеры, надо столярное ремесло целиком. В данном случае - программирование. Принципы, на которых устроены фреймворки. Одного этого хватит на те же лет 5. Зато потом не будет проблемы адаптироваться к неизбежным изменениям.

А если считать пределом мечтаний клепание говносайтов на некоем идеальном фреймворке на все времена, то может так случиться, что через 5 лет к условным "ларавельщикам" будут относиться так же, как сейчас к вордпрессникам.

И кстати для изучения принципов симфони подходит лучше

Да - и конечно же, все ответы туда же.
Один решил меряться количеством скачиваний. Ну если судить по такому критерию, то все перечисленное - букашки, которые копошатся под подошвами Вордпресса, с его присными темами и плагинами.

Да, и самое главное я тоже забыл сказать. Коллега xfg в самую точку написал в комментарии:

Фреймоворк - это на самом деле тонюсенькая прослойка над приложением. Это, по сути, система подай-принеси, принять запрос с фронта и отправить ответ. А что именно будет в ответе - решает не фреймворк, он здесь уже не при делах.

Очень на эту тему прочищают мозги доклады и видео Дмитрия Елисеева. У него на сайте как раз появился доклад с PHP Russia 2019, который я горячо рекомендую.

На ту же тему был и доклад Томаша Вотрубы, кстати. Что фреймворки, по сути, можно менять как перчатки, при желании. И у него есть даже инструмент для этого. Но в данном случае речь не об инструменте а о том, что фреймворк- далеко не главная часть приложения, и упираться в изучение фреймворков это все равно что в изучение отверток.

Я был в обсуждениях с некоторыми парнями на счет скорости и удобства и бла бла бла работы на php.

Мне один парень сказал, что php скоро сдохнет. Но ему ответил второй программист:
Он уже дохнет столько лет, что уже выпустили "предсмертную"(сарказм) 7 версию(на момент обсуждения). А сейчас уже готовят 8 версию, которая будет еще быстрее.

И мое мнение.
Php не умрет никогда. Потому что всегда будут две стороны халявщиков.
1. Которая хочет быстро что-то выучить и на этом заработать.
2. Те кто хочет быстро и дешево заказать сайт.
И вот эти две стороны будут генерировать, назовем это, спросом на этот язык.
Конкретно сейчас я не беру в обсуждения профессиональные сайты, которые действительно крутые и действительно достойные внимания и людей которые посвятили этому языку львиную долю своего времени.

Никогда не ведитесь на уговоры разрабатывать какой то веб проект на каком то экзотичном языке, например Питоне или Яве, в результате вы получите костыльный долгострой и дефицит программистов которые будут готовы над ним работать.
Это как в моде - есть всякое эпатажное дерьмо для показов на подиуме, а есть повседневные джинсы с рубашкой, все любят обсуждать эпатаж но носят джинсы.

Лучше использовать sort(). Это нативная, а потому быстрая, функция. Своя функция, если опустить время на создание массива, будет на порядок медленнее.

Таким образом, всё упирается в копирование данных. И здесь могу посоветовать только одно: данные должны быть уже в переменных JS на момент загрузки страницы. Конечно, в самой таблице - тоже, на случай отсутствия JS у пользователя. И каждая сортировка просто формирует таблицу заново.

Ещё вариант, сделать массив непосредственно из DOM-элементов, как-то так (пример):
[...document.querySelectorAll('tr')]
А после применения sort(), можно с помощью insert'ов сделать новую таблицу или даже пушить в существующую. Здесь плюс в том, что вы не меняете оформление и формат таблицы. То есть если другой программист (или вы в будущем) добавит новый столбец, то код, вероятно, не сломается.

К слову, если у вас 100-500 элементов, а на странице редко бывает больше 500, то сортировать можно как угодно, пользователь не заметит разницы.