JavaScript: от начала до конца

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор ^[1] хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

Bad parts

Из-за того, что язык писался чуть ли не за две недели (это очень мало), в нем был допущен ряд багов. А позже, когда язык вышел и был содран Майкрософтом, уже было поздно что-то менять. Некоторые идеи — это тяжелое наследие Java, от которого взяли синтаксис языка.

Язык программирования со слабой типизацией, с ошибками в реализации, с тяжелым наследием, с особенностями функционального языка вызывает только одно ощущение — «КАК? НУ КАК?» ^[2]. Постоянно пополняемый список «перлов» можно почитать здесь ^[3].

Чтобы не сойти с ума при работе с JavaScript, надо понимать, как работает слабая типизация, как работает область видимости переменных (глобальные переменные зло), как работает this, prototype и конструкторы. Также поможет jshint ^[4], чтобы избегать «плохие части» языка.

Вся эта история более подробно рассказана во второй лекции ^[5] Дугласа Крокфорда ^[6]. А лучше посмотреть все 8-серий ^[7]. Там есть титры ;).

Стоит отметить, что, несмотря на все минусы, у автора получилось сделать первый функциональный язык, c таким широким распространением. У Крокфорда есть вводная статья про функциональную природу JavaScript ^[8].

Базовые вещи, которые нужно понять (следующие из функциональной/асинхронной природы языка) это: что такое control flow ^[9] и как он помогает при работе с асинхронным языком и как работает обработка ошибок (try/catch не всегда помогают ^[10]).

JSON, AJAX и кроссбраузерность

Следующим этапом в развитии JS были JSON ^[11], AJAX и кроссбраузерная разработка ^[12]. Огромный скачок в этом этапе сделан благодаря jQuery. Очень рекомендую ознакомиться с туториалом ^[13] от Джона Резига ^[14] (автор jQuery). В туториале показаны некоторые приемы, использованные при создании jQuery. Или можно посмотреть интересные идеи непосредственно в исходниках jQuery ^[15]. Также интересные приемы рассмотрены в JavaScript patterns ^[16] и в essential js design patterns ^[17]. Если для вас это все еще сложно, то можно ознакомиться с более базовыми вещами здесь: JavaScript Garden ^[18], eloquentjavascript ^[19]

Flash off

HTML5 ^[20] (html5rocks ^[21], diveintohtml5 ^[22]) и CSS3 ^[23] вытеснили Flash из браузеров (ну еще не до конца, но это только вопрос времени ^[24]). Отдельное спасибо за это Стиву Джобсу ^[25]. Теперь в распоряжении у JS есть: Canvas, WebGL, WebSockets, WebWorkers, Audio, Video и т.п. ^[26]

Server-side

Гугл разродился браузером. И ускорил JavaScript до нельзя, подарив всему миру V8. Из которого в свою очередь родился NodeJS ^[27] (by Ryan Dahl ^[28]). Так JS попал и на сервер. Казалось бы куда дальше, и так заняли весь веб-стек технологий. Но и это не конец, JavaScript умудрился вытеснить еще и SQL ^[29]. Спасибо парням из 10gen за MongoDB ^[30]. Еще по теме: SQL to MongoDB ^[31], sql comparison ^[32].

Все уже и сами могут сделать этот вывод, но я это скажу вслух напишу: теперь разработать веб приложение от начала и до конца можно, зная только JavaScript (html и css не в счет).

Ложка дегтя

• NodeJS еще не дошел до версии 1, есть еще ряд не закрытых вопросов. Т. е. понятно, как написать чат на NodeJS, но как быть с большими и сложными проектами?..
• Нет нормальных туториалов, так как технология активно развивается, и они быстро устаревают.
• Разработка модулей происходит стихийно. Многие модули заброшены. Заходишь на Github и видишь, что последний коммит был около года назад.
• Нет «взрослых» фреймворков. Есть «молодые» подающие надежду проекты. Но нет фреймворков уровня рельсов.
  Лирическое отступление

  Есть мнение ^[33], что в последних рельсах очень высокий порог входа, но на самом деле это потому, что в рельсах решены все стандартные задачи и тебе не надо изобретать велосипед каждый раз. Фреймворки для node оставляют много пространства для фантазии (не хватает CoC ^[34]). Если посмотреть на проекты на Express (дефакто веб-фреймворк ^[35]), то вы не найдете и двух одинаковых проектов. Кто-то настройки складывает в config.js ^[36], кто-то центральное приложение делает как модуль для тестирования, кто-то использует синтаксический сахар для автозагрузки модулей ^[37] и т. п.

Скорее всего это «подростковые прыщи», которые со временем пройдут. Но пока это еще актуально.

Дальше больше

Фронтенд разработка

Наконец-то фронтенд разработка выбралась из каменного века, когда все делалось вручную. Появились инструменты для автоматизации ^[38] (инструмент написанный на js специально для этих целей) и менеджер пакетов ^[39] (я знаю, что это не первый менеджер, но будем надеяться, что этим будут пользоваться все). Все это собрано в кучу в проекте yeoman ^[40]. Если говорить про yeoman, нельзя не упомянуть: html5-boilerplate ^[41] и bootstrap ^[42]

MV*

Вместе с Ajax появились и первые «тяжеловесные» библиотеки/фреймворки: ExtJS, YUI и т. п. Но они громоздкие и неудобные. JQuery c другой стороны более легковесный и привычный, но так как это библиотека, а не фреймворк, он и не предлагает метод структуризации кода. На помощь пришел Backbone ^[43]. Следом за Backbone появилось много MV* фреймвокров. О них уже рассказывали: статья на Хабре ^[44], продолжение ^[45] и статья на английском ^[46]. А также можно сравнить фреймворки «на практике», почитав исходники на todomvc ^[47].

Angular ^[48]

Этот фреймворк примечателен тем, что он пытается принести DataBinding ^[49] в JavaScript. Это не единственный фреймворк который это делает. Но авторы на этом не останавливаются и хотят принести нативную поддержку DataBinding в браузеры. Они разрабатывают спецификацию «model driven views» ^[50] вместе с командой Chrome. Ну еще он хорош, потому что есть хорошая документация, видео, заложено тестирование ^[51]. Он довольно легкий и хорошо интегрируется с другими библиотеками.

Meteor ^[52]

Именно за этим фреймворком (и ему подобными) будующее NodeJS. И вот почему, сам по себе JavaScript на сервере это еще то «удовольствие». Мы то с вами понимаем, что все эти рассказы про бешеную производительность ^[53] из-за асинхронности — это только маркетинг. Скорость, отказоустойчивость, способность выдержать нагрузку определяется не ЯП, а архитектурой. От того, как организованы хранение данных (шардинг), кеширование, очередь задач, распределенные вычисления и от отсутствия узких мест (bottleneck) и т. п. Понимая это, я бы лучше выбрал ЯП, на котором легко писать и легко поддерживать большую базу кода, для которого есть много готовых решений (намекаю на RoR). Узкие места, требующие огромной производительности, распределенные вычисления и т. п. можно написать на Erlang ^[54], Java или С.

Но то, что может Meteor, не может предложить ни одна другая технология: полное повторное использование кода с сервера на клиенте (или наоборот), ну и еще маленькая тележка магии (датабиндинг, клиентский хот релоад...).
Его единственное преимущество является и его минусом. Клиентский и серверный код не разрывны. Meteor не очень подходит для тех случаев, когда клиент делается с использованием другой технологии. Например, нативный мобильный или десктопный клиент.
Кстати в ближайшем конкуренте Meteor ^[55] derby этот вопрос решаем. Так как они используют Express и гораздо меньше магии, то к нему можно прикрутить REST API.
Если подумать, это не первая попытка уйти от классического клиент-северного подхода. До этого был, например, GWT. Но все предыдущие попытки были менее эффектны и это был не JavaScript.

Mobile

Мало того, что JS добрался до мобильных браузеров ^[56] и выжил Flash, он еще претендует и на место нативных приложений. Это стало возможно благодаря Adobe Phonegap ^[57] (ядро проекта было отдано в open-source под названием Appache Cordova ^[58]).
Если добавить библиотеки для мобильных устройств, например: jQtouch, Sencha Touch, zepto. То получаться приложения с «нативным интерфейсом». Вот как смешать angular и jqtouch под PhoneGap ^[59]
Если добавить движки для игр ^[60], то получатся мобильные игры и т. п.

Desktop

Давно уже существовали попытки сделать написание десктопных приложений таким же простым, как написание веб приложений. Вот один из последних претендентов — tidesdk ^[61].
Есть другие подобные проекты, о которых ранее рассказывали на Хабре: AppJS ^[62], Node Webkit ^[63].

Заменители JavaScript

После того, как все сообразили, насколько важное место занимает JavaScript, решили придумать что-то более удачное, чем JavaScript. Есть куча ЯП, которые могут быть скомпилированы в JS ^[64]. Среди этих проектов особенно можно выделить:

• coffeescript ^[65] — JS Ruby way. Вот книжка ^[66]
• emscripten ^[67] — Компилятор из LLVM в JavaScript. А в LLVM можно скомпилировать много С/C++ библиотек и не только.
• dartlang ^[68] — JS Google way. Читайте о нем на Хабре ^[69].
• typescriptlang ^[70] — JS Microsoft way. Анонс на Хабре ^[71]

Конечно при таком подходе с языками «посредниками» проблема с дебагом на лицо. Она решается с помощью Source Maps ^[72].

Итого

JavaScript очень своеобразный язык, с родовыми травмами, которые в разные времена пытались решить по разному: jslint, заменители JavaScript, es6 ^[73]. Но не смотря на все проблемы, JavaScript активно развивается и набирает обороты: сообщество растет, инвестиции вливаются ^[74]. Все интересное еще впереди!

Автор: kotiara

Источник ^[75]