Яваскрипт: от начала до конца

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

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

Bad parts

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

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

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

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

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

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

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

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

Flash off

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

Server-side

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

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

Ложка дегтя

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

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

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

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

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

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

MV*

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

Angular

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

Meteor

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

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

Mobile

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

Desktop

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

Заменители яваскрипта

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

• coffeescript — JS Ruby way. Вот книжка
• emscripten — Компилятор из LLVM в яваскрипт. А в LLVM можно скомпилировать много С/C++ библиотек и не только.
• dartlang — JS Google way. Читайте о нем на Хабре.
• typescriptlang — JS Microsoft way. Анонс на Хабре

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

Итого

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