Не оч согласен javaQest,
1. jQuery удобен в качестве кроссбраузерного серфинга по DOM, в этом его главное преимущество.
2. Кросбраузерное решение в Aякс и событиях
3. Сокращение объема и наглядность кода, всё это основа той же популярности JQ
4 Никто не мешает двигаться нативному js к JQ по серфингу по DOM, ксать именно с возросшей популярностью JQ появилось querySelectorAll, querySelector
5. При реализации в JQ красивой обработки событий postMessage c привязкой к Окнам(табам) и WEB Worker вообщем-то функционально законченный фреймворк для фронтенда. js остаётся лишь математика
6. Кто мешает сделать нативный JQ ? Разработчики ?
7. Зачем делать трудозатратно в обучении, некроссбраузерно, если можно менее затратно и кроссбраузерно.
8. Языковая ограниченность браузера одним нативно-встроенным языком js пока скована лишь Инет-скоростью (возрастающий объём загрузки обновлений и самого движка и пока еще ограниченность объёма и скорости оперативки, желательно чтобы браузер не жрал более 12%)
Хотя я помню времена когда браузеры весили 8-15Mb, сейчас уже под 100. Думаю, что и до возможности двух трёх языковой обработки дойдут, ибо удобно быстро разворачивать сайт за 20 мин. В Инете уже достаточно много сайтов одного создателя на один день. Выполнил задачу и нафиг. Смысл там думать о той же взаимоорганизации js библиотек ?
Сейчас пока конторы-разработчики браузеров больше заняты не удобством развертывания новых средств ресурсо проектирования в Инете, а прибыльным расширением мобильных приложений и сбором инфы от пользователя(многие браузеры разрабатываются поисковиками, есть и внешние заказчики этой инфы).
Последний раз редактировалось Deff, 10.08.2015 в 11:55.
|