Небольшой вывод по прошлой статье и текущей (поправьте меня, если в моей логике есть брешь): в js мода меняется быстрее чем в индустрии женских сумочек. Поэтому если вы хотите суметь устроиться на работу через пару лет, вам стоит сейчас выбирать конторы, которые запускают много маленьких проектов. В каждом новом проекте можно пробовать ту технологию, которая сейчас в моде. Очень странная ситуация, программисты, которые работают над действительно большими и нужными проектами (а поэтому с большим количеством legacy) оказываются в проигрышной ситуации.
Я про него не забыл, просто у нас в проекте как раз подобная абстракция используется для событийной модели и асинхронного dataflow — но для меня было совершенной загадкой, как React'у удается быстро обновлять DOM при изменениях в данных без использования подобной абстракции. Для меня это было инсайтом — как и то, как тесно это связано с иммутабельностью и функциональной чистотой.
На моём опыте, ваша фраза «И хорошим программистом будет считаться человек, способный за два дня освоить конкретный набор технологий» актуальная уже сейчас. С начала прошлого года мне довелось поработать над тремя frontend проектами с абсолютно разным набором технологии, начинаю со сборщика и фреймворка, заканчивая набором библиотек и плагинов, даже стиль написания кода приходилось соблюдать разный. И только за счёт способности к быстрому обучению и адаптации удалось в этом преуспеть, а не сойти с ума.
Если степень фрагментации технологий продолжит возрастать теми же темпами, то ценность знаний конкретных технологий рано или поздно станет равной нулю. И хорошим программистом будет считаться человек, способный за два дня освоить конкретный набор технологий, которые он увидел впервые, быстро создать на этих технологиях проект, после чего очистить мозг от выученного, т.к. пока проект создавался, данные технологии вышли из употребления и больше никогда не понадобятся.
На backend'е ситуация ещё хуже. Фронтенд хотя бы ограничен одним языком (js), тогда как backend — это целая пачка языков программирования, вокруг каждого из которых громоздится целая гора фреймворков.
При том, что выбор языков носит исключительно косметический характер (в стиле «мне не нравится синтаксис»), т.к. возможности сходны, и вряд ли можно найти такую задачу, которую легко решить к примеру на Python+Django, но невозможно на PHP.
Это IMHO не JavaScript. Это экосистема технологий и приемов, складывающаяся вокруг JavaScript волей случая (в данном посте — даже вокруг фронтенд-разработки).
Когда надо не трепать языком, а работать за деньги с обязательствами перед клиентами и начальством вся эта заднеприводная противоречивость встаёт на пути нормального размеренного трудового процесса. Но, опять же, власть копролита сильнее голоса разума.
Программирую уже 18 лет, из них 11 лет для WEB. Прочитал статью, понял что я почти ничего не знаю. Пора перестать быть самоучкой — велосипедостроителем, и начать изучать готовые велосипеды. И уже на них ездить…
Ну это понятно:) Но ведь и сложность задач возросла. Если надо склепать какой-нить лендинг-пейдж/визитку или там галерейку для сайта на вордпрессе — можно все так же, window.onload = function() {} и вперед, и это нормально. Я бы «удивился», если кто-то предложил использовать react + babel для этого, все либы будут весить гораздо больше пользовательского кода, а выигрыш минимален. Я же говорю, никто не запрещает сейчас делать так же, как и тогда — только если вы попробуете те подходы на сложном приложении, вам будет грустно.
Сейчас везде так. Видели оригинал? Или вот покажи мне сейчас кто-нибудь стэк для написания десктопных приложений, я буду таким же мальчиком. Подозреваю, если бы братьям Райт показали «Конкорд», они бы тоже сказали: «ну да, круто, но у нас вот из говна и палок можно за час собрать, и летает». Сравните телефоны сейчас и во времена Белла. Да, сейчас все сложнее, зато и воможностей больше. А звонить-то можно и по-прежнему.
Это палка о двух концах, имхо. Тогда не было технологий и альтернатив и да, приходилось пользоваться кривым Prototype и тратить кучу времени на то, что сейчас можно сделать за час (та же сборка проекта).
С другой стороны, тогда и порог вхождения был гораздо ниже, изучаешь синтаксис языка, читаешь документацию к Prototype и вперёд фигачить.
То что происходит сейчас замечательно описано в статье, её показать человеку, который только входит во фронтэнд, он с высокими шансами станет как бабушкин мальчик. Делается то всё просто, если знаешь как, а чтобы во вё разобраться надо немеряно времени потратить. Т.е. порог вхождения вырос на порядок как минимум.
Кормлюсь js c 2006, и то, что сейчас происходит, в последние лет 5 — во многом лютый офигенчик.
Что у нас было тогда? Prototype c весьма странной идеей и расплывчатой ответственностью. Примерно такой же Motools. jQuery, чей подход мне не нравился вообще никогда, с его бесконечными отвратительными плагинами. Потом появился переусложненный ExtJS, императивный на всю голову qooxdoo и прочие странные порождения сумрачного корпоративного гения. Единственный приличный был y5, который умер, где и родился — в недрах яндекса. Backbone, при всех его недостатках, был лучом света в темном царстве.
Бандлер/минификатор был либо родом из серверного фреймворка (везде со своими идиосинкразиями), либо самописный (которые моя бабушка описала бы как «мальчик-то он хороший, только дрищется»). Все они писались серверными программистами без малейшего понятия, что же все-таки нужно фронтендеру. RequireJS, опять таки при всех своих недостатках, опять же был лучом света и т.д.
Сборка происходила в лучшем случае Makefile-ом. Это, конечно, довольно универсальная система, но на винде из коробки ее нет. grunt/gulp/webpack более кроссплатформенные решения в этом смысле, плюс не надо переключаться с JS на чей-то эзотерический синтаксис.
Про юнит-тесты я вообще молчу. Да, был, например, QUnit, но в отсутствие нормальной модульной системы и ее поддержки, пользоваться им было довольно грустно.
В общем, сейчас в 99% случаев можно найти «точное такое же, но с перламутровыми пуговицами». И да, никто не запрещает и сейчас писать так же, как в 2003 — все в одном-двух файлах, без сжатия и склейки, без сторонних библиотек. Просто сейчас мы делаем гораздо более сложные вещи, которые в двух файлах уже не уместить (оставим неуместное использование тяжелых фреймворков на простеньких страничках на совести тех, кто так делает).
Вот не уверен я, честно говоря. В языке программирования должна быть стройность и логичность, «внутренняя красота», если можно так сказать. Начиная использовать какую-то новую функциональность языка, в хорошем языке интуитивно понимаешь, что тебя ждёт: как примерно реализован интерфейс, какие методы потокобезопасны, какие нет, как будет проходить обработка ошибок и т.д.
В javascript этого нет и никогда не было. Те же == и ===, null и undefined, родовая травма в виде isNan. Чтобы на нём писать, его надо заучивать, реально. Нужно помнить, что при == будет приведение типов, а при === не будет. Нужно помнить, что в объекте error есть свойство message, которое хранит сообщение об ошибке. Нужно помнить, что проверять есть ли свойство нужно через if(foo.bar), потому что сравнения с null или undefined будет недостаточно. На том же хабре полно статей о подводных камнях js.
Любой язык, которому много лет — это набор костылей. С++, стандарт которого, наверное уже перевалил за 5000 страниц, PHP, создателя которого даже за программиста не считают, Java, ставшая COBOL'ом нашего времени.
21, если быть точным. И в чём он конкретно изменился? «use strict»; появился?
Сейчас на нём можно писать приложения любой степени сложности используя все те костыли, которые указаны в статье. Хотя это не верно, у JS есть принципиальные ограничение, например он не работает с файловой системой, в самом языке нет такой функциональности, она реализуется за счёт внешних модулей (например в составе NodeJs) и в принципе не реализована в среде веб-браузера. То же самое относится к хранению данных, есть внешние библиотеки, реализующие доступ к LocalStorage браузера и базе данных, но это не часть языка, это именно внешняя библиотека, которая в одних браузерах реализована, а в других нет.
JavaScript — это костыль на костыле, пирамида костылей. Хотите что-то реализовать — не забудьте заглянуть на http://caniuse.com чтобы проверить, где эти костыли реализованы.
А корень проблемы — сам javascript, который кривой, косой, написанный за полтора дня на коленке и с минимальной библиотекой базовых классов. Это был отличный язык для веба в 90х и начале нулевых, когда верхом искусства был DHTML (dynamic HTML), где с помощью JS можно было показывать текущее время.
Все эти надстройки, описанные в статье, к сожалению, лишь костыли над кривым языком. И меня реально пугает, что его пытаются тащить во всё более серьёзные вещи, типа веб-серверов и микроконтроллеров.
P.S. Чтобы не было недопонимания, под кривизной JS я подразумеваю то, что он изначально разрабатывался для несложных манипуляций с пользовательским интерфейсом. Он изначально не предполагал многопоточности, серьёзных возможностей для работы с исключениями, быстродействия. Он реально был написан на коленке. Как «Ока», практически. А сейчас из него пытаются Камаз сделать.
Я это понимаю, расстраивает только, что нет стандартов на это, которым бы все старались соответствовать. Webpack замечательная штука, но одновременно с ним появилось ещё 3 аналогичных инструмента. То же самое с фреймворками, есть AngularJs, Angular2, React и 100500 других. С надстройками над js то же самое, TypeScript, CoffeeScript,…
В итоге отрасль дробится на условные «цеха», где все делают одно и то же, но каждый по своему. В итоге реальным профессионалом стать проблематично, появляется новая «фишка» и всех отбрасывает на нулевой уровень. Переход разработчиков с проекта на проект затруднён, вот писал ты 2 года на React, а теперь переходишь на Angular, сколько времени понадобится на адаптацию? Грустно это.
При том, что выбор языков носит исключительно косметический характер (в стиле «мне не нравится синтаксис»), т.к. возможности сходны, и вряд ли можно найти такую задачу, которую легко решить к примеру на Python+Django, но невозможно на PHP.
Ну это понятно:) Но ведь и сложность задач возросла. Если надо склепать какой-нить лендинг-пейдж/визитку или там галерейку для сайта на вордпрессе — можно все так же,
window.onload = function() {}и вперед, и это нормально. Я бы «удивился», если кто-то предложил использовать react + babel для этого, все либы будут весить гораздо больше пользовательского кода, а выигрыш минимален. Я же говорю, никто не запрещает сейчас делать так же, как и тогда — только если вы попробуете те подходы на сложном приложении, вам будет грустно.Сейчас везде так. Видели оригинал? Или вот покажи мне сейчас кто-нибудь стэк для написания десктопных приложений, я буду таким же мальчиком. Подозреваю, если бы братьям Райт показали «Конкорд», они бы тоже сказали: «ну да, круто, но у нас вот из говна и палок можно за час собрать, и летает». Сравните телефоны сейчас и во времена Белла. Да, сейчас все сложнее, зато и воможностей больше. А звонить-то можно и по-прежнему.
С другой стороны, тогда и порог вхождения был гораздо ниже, изучаешь синтаксис языка, читаешь документацию к Prototype и вперёд фигачить.
То что происходит сейчас замечательно описано в статье, её показать человеку, который только входит во фронтэнд, он с высокими шансами станет как бабушкин мальчик. Делается то всё просто, если знаешь как, а чтобы во вё разобраться надо немеряно времени потратить. Т.е. порог вхождения вырос на порядок как минимум.
Кормлюсь js c 2006, и то, что сейчас происходит, в последние лет 5 — во многом лютый офигенчик.
Что у нас было тогда? Prototype c весьма странной идеей и расплывчатой ответственностью. Примерно такой же Motools. jQuery, чей подход мне не нравился вообще никогда, с его бесконечными отвратительными плагинами. Потом появился переусложненный ExtJS, императивный на всю голову qooxdoo и прочие странные порождения сумрачного корпоративного гения. Единственный приличный был y5, который умер, где и родился — в недрах яндекса. Backbone, при всех его недостатках, был лучом света в темном царстве.
Бандлер/минификатор был либо родом из серверного фреймворка (везде со своими идиосинкразиями), либо самописный (которые моя бабушка описала бы как «мальчик-то он хороший, только дрищется»). Все они писались серверными программистами без малейшего понятия, что же все-таки нужно фронтендеру. RequireJS, опять таки при всех своих недостатках, опять же был лучом света и т.д.
Сборка происходила в лучшем случае Makefile-ом. Это, конечно, довольно универсальная система, но на винде из коробки ее нет. grunt/gulp/webpack более кроссплатформенные решения в этом смысле, плюс не надо переключаться с JS на чей-то эзотерический синтаксис.
Про юнит-тесты я вообще молчу. Да, был, например, QUnit, но в отсутствие нормальной модульной системы и ее поддержки, пользоваться им было довольно грустно.
В общем, сейчас в 99% случаев можно найти «точное такое же, но с перламутровыми пуговицами». И да, никто не запрещает и сейчас писать так же, как в 2003 — все в одном-двух файлах, без сжатия и склейки, без сторонних библиотек. Просто сейчас мы делаем гораздо более сложные вещи, которые в двух файлах уже не уместить (оставим неуместное использование тяжелых фреймворков на простеньких страничках на совести тех, кто так делает).
В javascript этого нет и никогда не было. Те же == и ===, null и undefined, родовая травма в виде isNan. Чтобы на нём писать, его надо заучивать, реально. Нужно помнить, что при == будет приведение типов, а при === не будет. Нужно помнить, что в объекте error есть свойство message, которое хранит сообщение об ошибке. Нужно помнить, что проверять есть ли свойство нужно через if(foo.bar), потому что сравнения с null или undefined будет недостаточно. На том же хабре полно статей о подводных камнях js.
Сейчас на нём можно писать приложения любой степени сложности используя все те костыли, которые указаны в статье. Хотя это не верно, у JS есть принципиальные ограничение, например он не работает с файловой системой, в самом языке нет такой функциональности, она реализуется за счёт внешних модулей (например в составе NodeJs) и в принципе не реализована в среде веб-браузера. То же самое относится к хранению данных, есть внешние библиотеки, реализующие доступ к LocalStorage браузера и базе данных, но это не часть языка, это именно внешняя библиотека, которая в одних браузерах реализована, а в других нет.
JavaScript — это костыль на костыле, пирамида костылей. Хотите что-то реализовать — не забудьте заглянуть на http://caniuse.com чтобы проверить, где эти костыли реализованы.
Все эти надстройки, описанные в статье, к сожалению, лишь костыли над кривым языком. И меня реально пугает, что его пытаются тащить во всё более серьёзные вещи, типа веб-серверов и микроконтроллеров.
P.S. Чтобы не было недопонимания, под кривизной JS я подразумеваю то, что он изначально разрабатывался для несложных манипуляций с пользовательским интерфейсом. Он изначально не предполагал многопоточности, серьёзных возможностей для работы с исключениями, быстродействия. Он реально был написан на коленке. Как «Ока», практически. А сейчас из него пытаются Камаз сделать.
В итоге отрасль дробится на условные «цеха», где все делают одно и то же, но каждый по своему. В итоге реальным профессионалом стать проблематично, появляется новая «фишка» и всех отбрасывает на нулевой уровень. Переход разработчиков с проекта на проект затруднён, вот писал ты 2 года на React, а теперь переходишь на Angular, сколько времени понадобится на адаптацию? Грустно это.