Я собираюсь добавить обновление к этому, потому что я думаю, что появление JS в клиентской сети было неправильно понято в нескольких ключевых моментах за эти годы.
Это был не Аякс
Я не говорю, что Ajax не был важен для эволюции понимания JS как языка, но борьба за доминирование на стороне клиента была закончена задолго до появления термина Ajax.
Это было не потому, что это была единственная игра в городе
Были Java-апплеты, Flash и VBScript. Я слышал, что в 90-х были даже другие варианты сценариев (но требовались плагины IIRC). Ява очень популярна, но апплеты провалились. Они были уродливы и часто были швейцарским сыром, но, что более важно, я не думаю, что Java хорошо подходил по причинам, о которых я расскажу позже. Flash был очень популярен и имел прочную опору в течение нескольких лет, но даже когда у Flash наконец были варианты SEO, они обычно не использовались, что делало исключительно Flash-сайты очень трудными для обнаружения. Даже сейчас большинство из нас регулярно обновляют Flash, чтобы видеть фильмы, но это настоящая ахиллесова пята. Запатентованная технология в браузерах раздражает. И, конечно, VB, который будет работать только с IE, так что нет.
Правильное место в нужное время важно, но не полный ответ
Да, без веб-волны мы могли бы никогда не увидеть JavaScript или такой популярный язык, как это, так быстро, как мы. Или, может быть, мы бы ...
Это оказалось идеальным инструментом для проблемной области
Я бы сказал, что около 2000-х годов у нас были следующие проблемы:
- IE и Netscape только что согласились начать играть хорошо, следя за тем же стандартом DOM API и CSS, и с тех пор нам приходилось сталкиваться с множеством устаревших кросс-браузерных проблем, которые только начинают становиться управляемыми без помощи инструментов нормализации JS DOM, таких как JQuery пост IE8
- Было целое новое поколение веб-разработчиков / дизайнеров, которые не обязательно были тяжеловесами как программисты, стремящиеся улучшить свою игру после взлома пузыря, когда они перестали давать вам достойную зарплату за то, что они появились за дверью и ничего более чем базовая HTML-грамотность и некоторые навыки работы с фотошопом.
- В городе появился новый ребёнок из CSS, который предлагал интригующие возможности для того, что в конечном итоге будет называться DHTML, (более уместно) DOM Scripting, (сейчас неуместно) HTML5 (zomghtml5!).
Поэтому нам нужен был язык, который был бы глубоким и предлагал возможность фактически структурировать и разрабатывать более совершенное приложение с переносимыми / повторно используемыми компонентами на стороне клиента, но также доступным для людей, которые мало что знали и просто нуждались в вещах. появляться / появляться, когда вы нажимаете кнопку.
Более того, MS, являющаяся неуклюжим / некомпетентным и / или зверьком, который иногда является злодеем, борющимся с анти-конкурентной практикой, не смог по-настоящему прикоснуться к своей несоответствующей реализации DOM API в течение хорошего твердого десятилетия, хотя им и удалось добавьте случайную вещь как оригинальный объект XHR и querySelectors в IE8.
Важно отметить, что примерно к 2005 году нам удалось полностью похоронить сложность, связанную с обработкой кросс-браузерных проблем, что это не было больше серьезной проблемой в JavaScript. Неспособность поддерживать CSS2 должным образом до тех пор, пока они это делали, причиняла значительно больше боли. Чтобы получить представление об объеме и глубине проблем, я рекомендую проверить quirksmode.org . Я не думаю, что это подвиг, который мог бы быть достигнут столь же плавно и во многих библиотеках на Java, конечно, не в VB и определенно не с какой-либо стратегией плагинов, цель которой - обойти весь вопрос, став совершенно новым вид неприятности.
Другие языковые функции, которые имеют большое значение для пользовательского интерфейса:
Функции первого класса. По моему опыту, нет ничего лучше, чем асинхронная обработка и управляемые событиями парадигмы, чем язык, который делает свои функции первоклассными. Обе проблемы регулярно рассматриваются в работе пользовательского интерфейса.
Динамические типы: приведение и проверка типов - очень редкая потребность в JavaScript, которая помогает сохранять код кратким и компактным. Проблемы с пользовательским интерфейсом могут очень быстро усложниться. Надежность кода и абсолютная ясность в отношении потока данных имеют решающее значение для его понимания и изменения / обслуживания.
Это не протекционизм: в течение многих лет кто-то проповедовал, что вам нужно защищать себя от своих собственных ошибок и глупостей, которые другой парень может сделать с вашим кодом, делая кодовые конструкции очень жесткими и негибкими, и невозможно вмешиваться в исходное намерение, которым это было Автор и многие люди слушали. Я не буду говорить, что они всегда неправы (возможно, подумают), но я скажу, что это неправильный подход к веб-интерфейсу, и я верю, что это нечто вроде феномена, который мы проверяли, поддерживали и модифицировали сторонние графические интерфейсы гораздо быстрее и проще, чем такая работа, как правило, выполнялась в более ограниченных языках в прошлом. Возможность быстро и легко изменять вещи на лету значительно упрощает создание схем динамической / плавной архитектуры, которые не требуют огромных затрат косвенных данных и абстракций, что в конечном итоге облегчает понимание того, что, черт возьми, происходит в вашем коде. и упреждающий или обрабатывать исключения гораздо более четко. Проще поддерживать просто за счет того, что можно быть более прямым во всем, что вы делаете, и с гораздо меньшим количеством кода, чем это потребовалось бы с учетом другой философии.
Как JS стал популярным? Он зарекомендовал себя как отличный инструмент для работы снова и снова. Это не тот язык, с которым мы «застряли». Это язык, который, возможно, во многом способствовал эволюции популярных языков. И за это вы можете поблагодарить Брендана Эйха и всех современников, которые помогли воплотить эту идею в голову, за то, что ему понравился Scheme, который больше вдохновлял дизайнеров, а не Java.