Десять лет развития веб-технологий

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

Ajax

В 2003 году я учился в шестом классе. В то время интернет-кафе только появлялись в закоулках маленьких уездных городков. The Legend of Mir, Westward Journey Online и другие онлайн-игры первого поколения были невероятно популярны. Я дал хозяину интернет-кафе два юаня, думая, что попробую и зарегистрирую аккаунт, чтобы поиграть. А потом следующий час я застрял на ре-ги-стра-ции ак-ка-ун-та.

В то время у интернет-кафе была пропускная способность 512k. Во время регистрации я заполнил кучу информации, отправил, страница перескочила, бам: «Информация, которую вы заполнили, неверна, заполните заново». Затем она вернулась на страницу регистрации, и этот цикл повторялся. Сейчас я часто думаю: если бы AJAX тогда был широко распространён, я мог бы сэкономить два юаня.

Итак, что такое AJAX?

Прежде всего, AJAX — это технология. В прежних моделях веб-взаимодействия после того, как пользователь нажимал кнопку, например кнопку отправки, ему приходилось ждать окончания долгого обмена данными с сервером, во время которого он ничего не мог делать, разве что покурить. AJAX позволяет при отправке запроса на сервер не ждать результата, а параллельно заниматься другими делами, и когда результат придёт, вернуться и обработать его.

На самом деле технология AJAX была реализована Microsoft ещё в 1998 году. Однако только в феврале 2005 года, когда Jesse James Garrett из Adaptive Path опубликовал статью «Ajax: новый подход к веб-приложениям», и люди, прочитав её, подумали: «О, неплохо, это круто», AJAX получил широкое распространение в больших масштабах.

Появление AJAX значительно улучшило пользовательский опыт веб-сайтов. До сих пор, как бы ни было отстало отечественное IT-развитие, вход и регистрация на всех сайтах реализованы через AJAX-взаимодействие. После заполнения информации пользователи могут узнать, успешна ли отправка, без перезагрузки страницы и исправить там, где есть ошибки.

Кроме того, AJAX как решение для разделения фронтенда и бэкенда был принят большинством не самых отсталых отечественных компаний и косвенно привёл к упадку таких языков веб-скриптов, как PHP.

jQuery

В раннем программировании на JavaScript эффективность кода была крайне низкой, особенно в работе с DOM. Если разработчик хотел добавить событие кнопке, ему приходилось писать длинный повторяющийся кусок кода, чтобы получить кнопку, а затем ещё один длинный повторяющийся кусок кода, чтобы добавить событие. Хотя опытные разработчики инкапсулировали типовые операции, для новичков, которые не умели инкапсулировать, это было несомненно мучительной вещью, особенно в сочетании со всевозможными проблемами совместимости браузеров.

В 2006 году, с целью спасти новичков и позволить им «делать больше», родился jQuery. Значение рождения jQuery состояло, во-первых, в том, что он обеспечил совместимость с IE6, 7, 8 и различными браузерами, разделившими рынок; во-вторых, он значительно упростил операции с DOM и значительно повысил эффективность разработки. jQuery был настолько популярен, что некоторые фронтенд-разработчики умели писать только на jQuery, а не на нативном JavaScript. По сей день не будет преувеличением сказать, что jQuery — «напиши один раз, увидишь везде».

Ещё одно значение jQuery (по моему мнению) в том, что она катализировала интерес людей к фронтенду и его изучению. По сравнению с Linux, при очень низких затратах можно было написать эффект, заставлявший девушку, ничего не понимающую в программировании, сказать: «Оппа, ты крут!», и люди думали: «Ох (опять), неплохо, это здорово». После этого множество библиотек и плагинов на основе jQuery появились как бамбуковые побеги после дождя. Фронтенд-индустрия процветала и развивалась, а веб-разработка вступила в новую эру.

Chrome

Все боевые искусства под небесами — от Google. В эпоху IE6, 7, 8, хотя Firefox тоже медленно бросал вызов позиции IE, он был далеко не столь разрушительным, как Chrome, который Google начал продвигать в 2009 году. Chrome использовал открытый движок Apple WebKit, с хорошими стандартами дизайна и откликом рынка; он способствовал быстрой итерации браузеров и заставил IE полностью исчезнуть в Windows 10.

Запуск браузера Chrome ещё больше упростил порог входа во фронтенд-разработку. Его встроенные инструменты отладки просты в использовании и исключают ошибки. Мы можем легко просматривать состояние сети, порядок загрузки, выполнять отладку по точкам останова и т. д. В то же время функция плагинов Google предоставляет разработчикам большое удобство.

В настоящее время последняя версия Chrome начала использовать движок Blink. В тестовых версиях она уже умеет отслеживать и отлаживать CSS3-анимации. Раньше, чем я вообще мог это представить, Chrome уже реализовал это.

Одним предложением: без Chrome не было бы нового Китая, и мы могли бы использовать только Firefox.

GitHub

С ускорением итераций программных проектов инструменты контроля версий проектов также постоянно развивались, пройдя через CVS, SVN и GIT. На сегодняшний день CVS почти исчез из интернет-индустрии, SVN существует для хранения файлов и документов, а GIT — инструмент контроля версий, созданный создателем ядра Linux Линусом, — теперь является стандартом для версионирования кода. GitHub, опираясь на Git, стал сообществом для совместной работы команд разработчиков! По состоянию на январь 2015 года на GitHub было более десяти миллионов зарегистрированных разработчиков и десятки миллионов проектов с открытым исходным кодом. Среди них китайские разработчики в 2014 году росли на GitHub быстрее всех. Там можно найти почти любой нужный код... например, username..password..

OAUTH

Отличие OAuth1 или OAuth2 от предыдущих методов авторизации состоит в том, что авторизация OAuth не позволяет третьим сторонам получать доступ к информации учётной записи пользователя (например, имени пользователя и пароля).
Предыстория: в наиболее распространённом сервисном сценарии пользователю необходимо воспользоваться сервисами двух разных компаний: войти и пройти аутентификацию в компании A, чтобы скачать контент; затем войти и пройти аутентификацию в компании B, чтобы загрузить контент в сервис компании B, что сложно и отнимает много времени. И пользователь, и компании A и B хотят, чтобы сервисы были совместимы. Это создаёт потребность в проверке личности. Старый механизм с именем пользователя/паролем давал компании A или B разрешение просматривать или даже изменять пользовательские ресурсы другой стороны. Чтобы подтвердить личность и обеспечить совместимость сервисов, Google, Yahoo и Microsoft первыми выступили за создание OAuth 1.0. Позже OAuth 2.0 стал новым планом крупных интернет-компаний, основанным на безопасности HTTPS.

В настоящее время наиболее распространённый сценарий применения — это в основном вход через авторизацию, например WeChat, QQ, Weibo и т. д.

JSON

Хотя JSON — это стандарт, появившийся ещё в 2001 году, широко использоваться он стал только после 2008 года, после того как стали популярны различные AJAX-приложения, iPhone и устройства на Android. Старые сервисные системы в основном были корпоративного уровня, поэтому XML был выгоден для позиционирования корпоративных сервисов в стиле Java. Но для API-сервисов с ограничениями по трафику и простой семантикой XML громоздок, избыточен, сложен для изучения и расходует пропускную способность.

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

Популярность JSON, с другой стороны, отражает одно из преимуществ веб-разработки: независимо от того, на Java, Ruby, PHP или Python написан ваш бэкенд, если вы дадите мне интерфейс в формате JSON, я смогу удержать всю землю.

DJANGO&RAILS

Гибкая разработка сломала модель проектных R&D. В эпоху WEB 2.0 после 2010 года HTML5 возобладал, фронтенд-работу выделили в отдельное направление, и преимущества веб-скриптов вроде PHP уже не были столь очевидны, хотя у него всё ещё были преимущества в CMS и шаблонах форумов. Наибольшее преимущество Django и Rails в том, что они позволяют одному человеку или небольшой команде из двух-трёх человек реализовать полноценный продукт. Возьмём Instagram в качестве примера: изначально два Python-инженера с помощью Django быстро реализовали все серверные функции, а когда начался рост пользователей, они выделили сервисы с большим трафиком и большим объёмом данных.

Несмотря на жестокую реальность и упадок Rails с каждым днём, вопрос лишь во времени, что исчезнет первым — IE8 или Rails, но решения, которые он предложил, до сих пор копируют многие младшие поколения. Люди запомнят этот недолгий расцвет.

Bootstrap

В 2011 году Twitter открыл исходный код фреймворка для веб-GUI. jQuery обеспечивал совместимость JavaScript с разными браузерами, а Bootstrap — совместимость CSS с разными браузерами. Дело дошло до того, что как бэкенд-разработчику вам не нужно было понимать CSS, не нужен был фронтенд-разработчик, не нужен был дизайнер; достаточно было посмотреть документацию Bootstrap, и можно было создать красивую и изящную систему администрирования бэкенда. Похожие распространённые GUI-фреймворки включают Foundation от Zurb и Materialize от Google. Baidu также когда-то выпустила мобильный фреймворк под названием GMU.

Лично мне не нравятся эти GUI-фреймворки, хотя они упрощают CSS и позволяют достичь некоторых классных эффектов, хотя я использовал их в проектах, хотя я не хочу признавать, что я «зелёный чай» (лицемер). Самый большой недостаток этих фреймворков в том, что они все одинаковые. Все страницы выглядят одинаково: одна и та же навигация, одна и та же боковая панель, одни и те же формы и даже одно и то же свечение при наведении на них мыши. Это как если бы у меня было три ноги (хотя у меня действительно есть три ноги), люди сказали бы, что я уникален и мой внешний вид заставляет их глаза загораться. Но если бы у всех было три ноги, веб потерял бы своё очарование. Ещё один недостаток — раздутость: один CSS-файл использует более 100 KB трафика, а большинство его JS-плагинов зависят от jQuery. Вы можете это вытерпеть?

Конечно, идея HTML на основе сетки, предложенная для решения задачи адаптивного дизайна, всё ещё достойна изучения.

NodeJS

Некоторое время я сомневался, относится ли Node к области фронтенда. Я считаю, что относится.

Решение проблемы высокой конкурентности всегда было темой, которую любят обсуждать бэкенд-инженеры. Например, в нашей системе мониторинга в реальном времени теоретически каждое соединение порождает новый поток, и каждому новому потоку может потребоваться 2 МБ вспомогательной памяти. В системе с 8 ГБ ОЗУ теоретическое максимальное число одновременных соединений составляет 4 000 пользователей. По мере роста числа пользователей мы хотим, чтобы программа мониторинга поддерживала больше пользователей, а это означает добавление новых серверов. Конечно, это увеличивает затраты на бизнес, особенно затраты на серверы. Помимо роста затрат, есть и техническая проблема: пользователи могут использовать разные серверы для каждого запроса, поэтому любые общие ресурсы должны быть общими для всех серверов. В этот момент технология упирается в узкое место. Node изначально был создан для решения этой проблемы. Решение Node — изменить способ подключения к серверу. Вместо создания нового потока ОС для каждого соединения и выделения для него вспомогательной памяти каждое соединение генерирует событие, которое выполняется внутри процесса движка Node.

Node.js — это серверный язык. В движении за разделение фронтенда и бэкенда он является мощным оружием для фронтенда. В то же время он предоставляет множество программируемых инструментов для автоматизации фронтенда (grunt, bower, gulp и т. д.). Taobao и Baidu всегда с энтузиазмом относились к Node.js, поэтому, естественно, я считаю, что это тенденция. В прошлом году Meituan создала команду Meituan Hotel и выбрала Node в качестве языка бэкенда, взяв на себя большую часть работы над бэкендом. Интересно: с учётом фронтенд-JS плюс Node плюс требования к навыкам UI, не стоит ли теперь называть фронтенд-инженеров инженерами полного стека?

БОЛЬШИЕ ДАННЫЕ

Большие данные — вероятно, самый горячий термин последних нескольких лет. Куча моих однокурсников, услышав, что добыча данных приносит годовую зарплату в 300,000, с воем помчалась работать с базами данных.
Чаще всего, когда мы говорим о больших данных, мы на самом деле говорим о добыче данных, анализе данных, интеллектуальных рекомендациях, анализе в реальном времени и т. д. при огромных объёмах данных. У разных компаний разные технические решения. Я перечислю лишь два успешных отечественных примера:
• Персонализированная электронная коммерция JD.com, со сценариями, включающими такие измерения, как поведение, предпочтения, местоположение, время и дружеские связи; рекомендация разных товаров разным пользователям; и разные пользователи видят разные рейтинги товаров в поиске...
• Карта 8-часовой миграции Дунгуаня от Baidu Maps; умные напоминания Baidu Search
• Функция защиты от нежелательных звонков по номеру телефона в 360 Mobile Guard выбирает 1,000 номеров, наиболее релевантных пользователю, из 256 миллионов помеченных телефонных номеров на основе региона, статуса и тенденций нежелательных звонков пользователя и записывает их в текстовый файл 10k на телефоне пользователя, чтобы обеспечивать защиту от нежелательных звонков без подключения к интернету и без какого-либо сетевого взаимодействия.

HTML5+CSS3

Этот термин в последние годы заездили до смерти. Все говорят об HTML5; если спросить их, что такое HTML5, они не смогут внятно объяснить. Это просто круто, просто эффектно, просто круто и эффектно.

На мой взгляд, HTML5 — это всего лишь то, что стало реальностью благодаря многократно повторённым слухам. Он привлекает гораздо больше внимания, чем функциональность, которую даёт. HTML5 всего лишь предоставляет несколько новых API, как приложение, обновляющееся с 1.0 до 2.0, добавляет функцию «Люди рядом». Более того, его API лишь прощупывают почву на мобильных устройствах. На стороне ПК из-за проблем совместимости он так и не получил официального признания. Разработка для ПК по-прежнему основана на HTML 4.0 + CSS 2 с прогрессивным улучшением. Что касается CSS3, его самая обсуждаемая функция — анимация — тоже уже то, что Flash оставил позади.

Стремительное развитие мобильных устройств ускорило развитие HTML5, а развитие HTML5, в свою очередь, подтолкнуло браузеры к стандартизации.

На этом пути к стандартизации WeChat сыграл незаменимую роль. Такие страницы, как «1024», «Осада нервного кота», «Десятилетие Taobao» и «LEXUS NX», включающие множество элементов HTML5+CSS3, впечатляют.

Кроме того, Microsoft отказалась от кодового имени IE и разработала Edge. Браузеры разных производителей непрерывно стандартизируются, черновик HTML5 был окончательно доработан, а черновик ES6 постоянно реализуется и улучшается. Путь впереди у фронтенда выглядит как широкая открытая дорога, и я полон ожиданий.

Future

3D-игры в браузере? WebOS? Виртуальная реальность?

Наконец, с улучшением производительности пользовательского оборудования, всё большей пропускной способностью сети, системами сенсоров, Retina и растущей зрелостью технологии WebGL, а также бурным развитием O2O — станет ли вышеперечисленное реальностью?

Источник: http://www.cnblogs.com/sussski/p/4634595.html