TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.
У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.
Bad parts
Из-за того, что язык писался чуть ли не за две недели (это очень мало), в нем был допущен ряд багов. А позже, когда язык вышел и был содран Майкрософтом, уже было поздно что-то менять. Некоторые идеи — это тяжелое наследие Java, от которого взяли синтаксис языка.
Язык программирования со слабой типизацией, с ошибками в реализации, с тяжелым наследием, с особенностями функционального языка вызывает только одно ощущение — «КАК? НУ КАК?». Постоянно пополняемый список «перлов» можно почитать здесь.
Чтобы не сойти с ума при работе с JavaScript, надо понимать, как работает слабая типизация, как работает область видимости переменных (глобальные переменные зло), как работает this, prototype и конструкторы. Также поможет jshint, чтобы избегать «плохие части» языка.
Вся эта история более подробно рассказана во второй лекции Дугласа Крокфорда. А лучше посмотреть все 8-серий. Там есть титры ;).
Стоит отметить, что, несмотря на все минусы, у автора получилось сделать первый функциональный язык, c таким широким распространением. У Крокфорда есть вводная статья про функциональную природу JavaScript.
Базовые вещи, которые нужно понять (следующие из функциональной/асинхронной природы языка) это: что такое 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
Гугл разродился браузером. И ускорил JavaScript до нельзя, подарив всему миру 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 в JavaScript. Это не единственный фреймворк который это делает. Но авторы на этом не останавливаются и хотят принести нативную поддержку 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.
Заменители JavaScript
После того, как все сообразили, насколько важное место занимает JavaScript, решили придумать что-то более удачное, чем JavaScript. Есть куча ЯП, которые могут быть скомпилированы в JS. Среди этих проектов особенно можно выделить:
- coffeescript — JS Ruby way. Вот книжка
- emscripten — Компилятор из LLVM в JavaScript. А в LLVM можно скомпилировать много С/C++ библиотек и не только.
- dartlang — JS Google way. Читайте о нем на Хабре.
- typescriptlang — JS Microsoft way. Анонс на Хабре
Конечно при таком подходе с языками «посредниками» проблема с дебагом на лицо. Она решается с помощью Source Maps.
Итого
JavaScript очень своеобразный язык, с родовыми травмами, которые в разные времена пытались решить по разному: jslint, заменители JavaScript, es6. Но не смотря на все проблемы, JavaScript активно развивается и набирает обороты: сообщество растет, инвестиции вливаются. Все интересное еще впереди!
Автор: kotiara
