Костыли нас поджидают повсюду: начиная от серверных заголовков призванных обеспечить безопасноть приложений (CSP), заголовков, обеспечивающих взаимодействие между приложениями (Cross-origin resource sharing), и заканчивая инструментариями сборки.
Решая одну проблему, мы создаем пару новых и они уже как снежная лавина несутся, снося все на своем пути. Если сомневаетесь, можете посмотреть статистику вопросов на стековерфлоу, где джаваскрипт уже бесспорный лидер.
Есть в зале люди, которые пытались, к примеру, написать проект на Angular 2 и собрать его, используя Webpack? Это сущий ад.
К примеру, решаете вы использовать ES6 синтаксис, но Typescript говорит, что он не может использовать ваш Map как массив, пока вы не выставите target = es6 (точнее, это вам говорит гугл). Выставляете, но теперь Typescript ругается на дублироване объявлений в es6-shim.d.ts. Убираете эти объявления, но теперь uglify ругается, что он не может понять, что такое let (точнее, это вам говорит гугл, т.к. в ошибке что-то невнятное и не относящееся к let вообще)… Прикручиваете babel. Но теперь Ulgify переименовал [ngClass] в [ngclass] и ангулар ругается, что не знает такого свойства у элемента…
В итоге получаете сборку размером 2 Мб (после минификации 760Кб)! И начинаете писать webpack-костыль, который отложит загрузку каких-то модулей до нужного момента. Причем решается это все ужасно через регулярки.
И этот кошмар повторяется снова и снова.
Ситуация с фреймворками и библиотеками уже напоминает современный мир мобильных телефонов. Нет смысла учить что-то дольше недели, потому что через год оно и так уже морально устареет.
Grunt, Gulp, Broccoli…
R.js, Browserify, SystemJS Builder, Webpack…
Flux, Redux,… поставьте свое
И это тоже продолжается до бесконечности. Какие-то проекты даже не успевают выйти из беты, как уже безнадежно устаревают или не взлетают (Polymer к примеру). Какие-то проекты появляются непонятно зачем и дублируют то что уже есть (WebRX).
Webpack, как по мне, это вообще идеал костылестроения. Спасибо ему хоть за то, что собрал многие костыли в одном месте. (Правда теперь npm полон модулями с неоднозначными названиями по типу raw-loader, base64-loader, сложно же было префиксовать свои лоадеры).
Писать документацию, судя по всему, уже стало не модно. Зачем? Опенсорс же. Человек может открыть исходники, а там, глядишь, разберется и законтрибьюит.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (120)
handicraftsman
14.08.2016 19:02Вспомнив ситуацию в сфере ОС, не особо верю в улучшения — то есть, хорошие решения будут, но не будут популярными, как в случае с GNU/Linux.
Alexey2005
14.08.2016 20:19+2Да вот как раз GNU/Linux — это квинтэссенция всего того, о чём написано в данной заметке.
Дичайший кошмар с фрагментацией, когда очередной форк выходит из употребления быстрее, чем его успеваешь освоить.
Дикое костылестроение, когда явные дыры наспех затыкаются костылями в надежде, что раз OpenSource, то потом кто-нибудь другой их отрефакторит или переделает как надо.
Полнейшее нежелание составлять и поддерживать актуальную документацию, т.ч. сведения всегда приходится собирать по крупицам, причём эти крупицы могут использоваться лишь приблизительно, ибо устарели лет на пять.
splav_asv
14.08.2016 20:59По большей части вы перечислили проблемы семейства *buntu. Для остальных всё (или большая часть) не так актуальны.
handicraftsman
15.08.2016 00:47-3Плюсовал бы, если бы была карма. Причина: сам не убунтоид, использую archlinux.
serg_deep
15.08.2016 09:45Не знаю что там у Вас устаревает, я как пользовался 7 лет назад Debian, так и пользуюсь, так и буду пользоваться. Проблема в данном случае в другом, вокруг JS хайп, по-этому вокруг так много различных пакетов на каждый чих. В таких случаях JS нужен какой-то лидер, а точнее лидер-проект, который бы мог объединить в себе множество людей. Как например ROR. Да я знаю что у него есть и плохая сторона, он стал монополистом и задушил конкуренцию, НО так или иначе, он объедини в себе людей. Подобный проект-лидер и нужен JS.
JustPeople
17.08.2016 23:30против ROR ничего не имею вот только про «объединить в себе множество людей» вы загнули. Рубистов, когда это требуется, днем с огнем ищут вплоть до релокации сотрудников из других регионов. 90% как использовали php так и используют. Имел бы Ruby в целом и RoR в частности столько же последователей сколько имеет JS, ситуация была бы аналогичной.
Fedcomp
14.08.2016 19:03+1> В итоге получаете сборку размером 2 Мб! И начинаете писать webpack костыль, который отложит загрузку каких-то модулей до нужного момента. Причем решается это все ужасно через регулярки.
Ээээ, а как же require.ensure? или вы думаете те кто пилят такие утилиты дураки?zim32
14.08.2016 19:08+3Вы подключаете ангулар модуль, который использует RxJS к примеру и который и знать не знает ни про какой require.ensure
Ohar
15.08.2016 12:21-3Ну так возьмите и допилите этот модуль, чтобы он знал RxJS. Или используйте другой.
Статья состоит из нытья о том, что автору кто-то неведомый что-то должен и не отдаёт.
Дали сборщик, дали модули, дали фреймворки — выбирай и радуйся, не пиши велосипеды. Нет, хочу плакаться что библиотека А не полностью совместима с фреймворком Б.
Если вам не нравится то, что есть — дорабатывайте или пишите велосипед. Это же Open Source.
Как дети, честное слово.
stalkers
14.08.2016 19:31+2С выходом новых стандартов (es7, web components) проблемы решаться сами собой
Новые стандарты не решают накопившиеся проблемы
Новые стандарты сделают неактуальными старые проблемы и породят новые. На смену одним костылям придут другие. Свежесобранные велосипеды обгонят уже существующие, а дальше притормозят и начнут ехать с той же скоростью. Существующие фреймворки обновят первую циферку в версии, потом перестанут быть такими популярными, а потом окончательно падут под напором новых инструментов. Разработчики опять начнут рвать волосы, которые только-только отросли после предыдущей смены стандартов, с дикими криками матеря всех и всё.
Новые проблемы вернут нам старые разговоры о том, что надо существующий зоопарк решений как-то привести в божеский вид, для чего, пожалуй, надо ввести какие-то новые стандарты, которые нам всенепременнейше помогут.
И всё повторится вновь, потому что шоу должно продолжаться.
PretorDH
15.08.2016 02:46+2Согласен…
Проблемы возникают когда, кто-то с благой целью пытаются упростить жизнь другим, и начинает выдумывать новый велосипед (стандарт), поверх не совсем стандартизиованной связки HTTP, HTML, CSS, JS. Дичайше долго реализовывают новые вещи в этих трех… Но. В любой момент времени этой связкой можно пльзоваться без каких либо проблем, и без всяких надстроек.
Вот Только програмисты великий народ с великой ленью (хапанул косяк из доков и давай кодить, а их скурить полностью надо и не один раз). Им проще 100500 раз по… ться с чужими костылями, методологиями и фреймворками… Чем раз в 10 лет выучить простой стандарт, и официальные рекомендации к нему… (Народ до сих пор пользуеться видоизменненной табличной версткой — bootstrap ets.)
Еще плохо, что в новый стандарт ЕS6 напихали всякого, а толку. Например, классы — в интепритируемом языке как гвоздь в подошве, интерпритатор делает двойную работу!!! Спрашивается ЗАЧЕМ??? Что-бы было удобно програмисту недоучке. Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь). Как на меня, Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Если посмотреть, ничего существенно нового не добавилось, все новое это перефразированное старое, в другой подаче — но суть то не поменялась (списки, стрелки, литералы, ..., нафиг не нужные константы). Реально новое, это (игры с параметрами, символы, итераторы и генераторы) но пользы от них не много. И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики (как говорят разработчики МАГИЯ)…maxpsyhos
15.08.2016 04:36>> Что-бы было удобно програмисту недоучке. Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь).
И получаем 100500 разных реализаций, т.к. язык очень гибкий и позволяет их все, и каждый из вариантов с точки зрения его разработчика «истинно правильный».
webmasterx
15.08.2016 04:54>>(Народ до сих пор пользуеться видоизменненной табличной версткой — bootstrap ets.)
пользуется потому что flexbox еще не поддерживается на подавляющем большинстве устройств
>> Спрашивается ЗАЧЕМ???
для удобства кодинга. конкретнее — для более лучшего удержания абстракций в голове.
>>Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Кодите просто на функциях, (вам же так сокрость работы нужна). Не используйте абстракции (объекты, структуры, потоки). посмотрим, какими будут ваши большие проекты, и как в них легко будет разобраться другим
>>И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики
>> Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь).
противоречие, вам так не кажется?
Carduelis
15.08.2016 11:07А вы не могли бы по поводу классов в js поподробнее?
Может быть есть статья какая или что-то подобное про производительность. У любого метода есть свои плюсы и минусы. Спасибо.
davidovsv
14.08.2016 19:47-2Ситуация меняется с отказом от JavaScript в качестве языка разработки (как для сервера, так и для клиента). Хорошие примеры: Erlang/N2O, Elm.
TimsTims
15.08.2016 12:29Выкинув Javascript останется большая дырень с тем, что Erlang не так распространен, и проблему это не решит. Это равнозначно «не пользоваться браузером = проблем не будет».
И да, нужно будет переписать кучу сайтов на Erlang, всем изучить этот язык, создать индустрию под это дело итд… короче жестьdavidovsv
15.08.2016 12:40На клиенте JavaScript нельзя выкинуть, пока это единственный вариант, более-менее поддерживаемвый всеми браузерами. Его и не нужно выкидывать. Наша задача, чтобы в приложениях не осталось лажи. И JavaScript тут плохой помошник. (Также, как, например, PHP на стороне севрвера).
Не нужно переписывать сайты. Они умирают быстрее, чем успевают состариться естественным образом. Просто нужно новые сайты делать на правильных инструментах, которые правильным образом поддерживают «хуяк-хуяк и в продакшен»-методологию.
Не нужно всем изучать Эрланг. Пусть говносайты делают на говнофреймворках. А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Для бекенда есть достаточно хороших инструментов, которые не позволяют легко отстрелить себе ногу. Но для фронтенда нужно развивать и использовать вещи типа Elm. Тогда будет значительно меньше боли.TimsTims
15.08.2016 13:37+1> И JavaScript тут плохой помошник
Дело не в JavaScript, а изначально в технологии HTML, живой картинки, DOM итд. Никто не знал, к чему это приведет, и что будет такой зоопарк.
> Наша задача, чтобы в приложениях не осталось лажи
Ну т.е. «а давайте все перепишем с нуля?» И опять-же, дело не в JavaScript.
> А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Проблема другая — Erlang'a нет в браузерах. А значит пусть вы напишете идеальный код на Erlang, но если пользователь не сможет купить товар/услугу на вашем супер-быстром сайте, то цена вашему сайту — 0.
> плохой помошник PHP на стороне севрвера
Чем же он плох?davidovsv
15.08.2016 17:14-2Вы не поняли, о чем я.
> Проблема другая — Erlang'a нет в браузерах
Это не проблема — Erlang компилируется в JavaScript. Elm компилируется в JavaScript. (Даже C++ копилируется в JavaScript или Web Asm :).
Пусть JavaScript останется тем же, чем являются ассемблер или машинные коды (или байткод виртуальной машины). С ним будет работать браузер, но на нем не надо программировать.
>> плохой помошник PHP на стороне севрвера
> Чем же он плох?
Тем же, чем он хорош — низким порогом входа.
pushist1y
15.08.2016 18:17>Erlang компилируется в JavaScript. Elm компилируется в JavaScript
А отлаживается он при этом как?davidovsv
16.08.2016 07:05Отладка практически не требуется, т.к. большинство (в том числе и логических) ошибок обнаруживаются на этапе компиляции. Но дебагер у него есть, и он умеет на лету подхватывать изменения в коде и ходить по шагам не только вперед, но и назад: http://debug.elm-lang.org/
zim32
15.08.2016 19:30Я вот не пойму. Если в v8 движке джаваскрипт уже тоже компилируется на лету в байт код, то почему нельзя сразу компилировать в этот байт код минуя джаваскрипт тогда?
davidovsv
16.08.2016 07:12Не могу сказать точно, но, вероятно, байткод — внутреннее представление виртуалной машины. У V8 он один, у другой VM может быть другой. Но есть нечто промежуточное — Web Asm.
ZaEzzz
14.08.2016 20:17+1Я не думаю, я уверен — в ближайшем (относительно) будущем что-то изменится. Только не в ту сторону, в которую хотелось бы.
Это как со смартфонами: при выходе нового смартфона множество рассказов, что он стал меньше потреблять энергии и итд. Вы ждете, что новый смартфон будет больше жить на одном заряде. Оправдались ваши ожидания? Нет — он просто стал тоньше.Alexey2005
14.08.2016 20:24+3Так он потому и стал тоньше, что железо стало потреблять на 20% меньше, и значит, появилась возможность снизить толщину, на эти же 20% уменьшив ёмкость батареи.
Другое дело, что бывает сложно объяснить, зачем же вообще нужно так сильно снижать толщину — вроде современные устройства уже и так тонкие, даже чрезмерно.Garbus
14.08.2016 21:57Ну так надо же маркетологам (и прочим) зарабатывать на хлеб? Вот и «воюют», то мегписелями камеры, то экраном, то толщиной и производительностью.
В результате, поиск качественного телефона для повседневных задач превращается в квест, который осилит не каждый обыватель. Да еще и приложениями норовят закидать так, что телефон тормозит сильнее старичка сделанного 10 лет назад.
Vilgelm
15.08.2016 01:55+2Так воевали бы временем автономной работы, хоть польза бы была. Кому эта тонкость вообще нужна.
Mabusius
15.08.2016 10:38Есть линейка телефонов от филипс, главная фишка которых долгая работа. Вы много их видели? Тёлочкам надо чтобы телефон в маленькой сумочке помещался, а заряжать каждый вечер или через день разницы большой нет.
sashamori
15.08.2016 15:17Спросил подругу, которая вечно жалуется на быстро садящийся айфон, какой бы она выбрала новый, такой же толщины, но с большей батареей, или более тонкий, но с такой же батареей как у старого, и, соответственно, коротким временем работы. Она выбрала последнее.
Такие дела.
Psihiatr
14.08.2016 21:56+5Вы еще забыли надвигающийся Dependency Hell в node.js:
tendium
15.08.2016 07:21+3Не хочу умалять заслуг автора статьи по ссылке, но вот это доставило (интересно, это он так шутит?): «I opened up babel-core in vim, then turned off my computer because Ctrl-C wasn’t exiting, then opened babel-core in Sublime Text 2.»
tendium
15.08.2016 07:28+1Черт возьми, да вся статья — сплошной сарказм. Повеселился в общем. Спасибо за ссылку. :)
romanonthego
14.08.2016 21:57+2Жаловаться на текущее состоянии можно только не застав состоянии пару-тройку лет назад.
То что чем мы пользуемся сейчас (react+redux+webpack+es6) на голову или даже на две выше чем то с чем приходилось иметь дело ранее. Скорость, удобство разработки, удобство дебага — все в разы лучше.
Вебпак так вообще — несмотря на то что выглядит для нового человека как марсианский конфиг для космолета — очень, _очень_ простой и понятный (именно из-за этого он и выглядит костыльным — там нет привычной магии фрэймворков, нужно очень многое писать самому, понимая что ты делаешь)zim32
15.08.2016 11:04Я к примеру не могу понять как там сделать простейшую вещь — применить uglify только к одному файлу. И это в инструменте который создан для того чтобы упростить сборку?
Gugic
15.08.2016 11:31А в чем проблема?
gulp.src('path/to/file').pipe(ugilfy()).pipe(gulp.dest('path/to/build'));
GRIM2D
15.08.2016 11:36+1Давайте разберемся. Зачем применять Uglifiy на один файл?
Webpack — это прежде всего собириает все ваши файлы в один единый файл. И главная задача этой утилиты — не засорять global scope.
В статье написали, что после сборки получился файл весом 2Мб. Откройте окончательный файл. Там код вашего React, Redux и все остальных библиотек и фреймворков. Потратьте время на изучения webpack — webpack умеет не «включат» файлы в сборку. Тогда бы ваш HTML загружал бы библотеки с CDN, а ваша программа весила бы около 200кб.
Хватить называть чужой труд костылями. Без обид, если не умеете пользоваться — это ваши проблемы.zim32
15.08.2016 12:18Ну зачем это уже мое лично требование. Вы же не говорите заказчику к примеру «Зачем Вам этот уродский банер, он только отвлекает». Иначе получается что не инструмент для разработчиков, а наоборот. В итоге я должен еще поставить и заюзать gulp (пример типичного костыля)
>> webpack умеет не «включат» файлы в сборку
Да я знаю про IgnorePlugin. Правда так и не получилось добиться того чтобы в рантайме не выскакивало исключение «module not found ...», видимо надо строить граф и смотреть что чего там реквайрит.
После минификации всего и вся получилось 760Кб поправил статью.
DexterHD
15.08.2016 13:27>>> Тогда бы ваш HTML загружал бы библотеки с CDN, а ваша программа весила бы около 200кб.
Есть такие программисты которые почему то искренне верят в то, что CDN не может упасть а Facebook и Vk работают вечно.
Все что может сломаться — сломается и из-за того что библиотеки у вас на CDN как минимум вы получите просадку в скорости
загрузки, как максимум нерабочий сайт, потому что какая то либа отвалилась.
webkumo
15.08.2016 14:33Ну во-первых можно давать ссылку на свой сайт.
А во-вторых ссылку на CDN пытаться загрузить первой и если не получилось — тогда грузить со своего сайта. Теоретически кеширование должно помочь сильно сэкономить на времени загрузки скрипта…
А в третьих — нужно ли вообще в один файл собирать? Может http/2.0 всё-таки скоро заработает?
Chamie
15.08.2016 17:44Вы так говорите, как будто годовой даунтайм нормальных CDN больше или хотя бы сравним с даунтаймом среднего сайта, который его использует.
Alexey2005
15.08.2016 20:11Без gulp, к примеру, не собрать всё в действительно единый файл. Когда мне понадобилось получить на выходе один-единственный html, внутрь которого встроены и css, и js, пришлось ставить gulp, поскольку в webpack я так и не нашёл способа этого сделать — он вставляет в html линки на файлы с кодом, а не сам код.
romanonthego
15.08.2016 11:42+1Не упростить сборку, я говорю что сам инструмент очень просто устроен. Это не значит что в нем не нужно разобраться — как раз напротив.
Например uglify плагин вебпака создана для обработки выходящего бандла (всего кода сразу). Что бы применить к одному конкретному файлу (ума не приложу почему только к одному, но пусть) можно использовать uglify-loader:
var file = require("uglify!./path/to/file")
вот и все.
hzs
14.08.2016 22:20+1Я чувствую себя очень старым, максимум что я могу себе позволить прикрутить в своих проектах, это Bootstrap.
Не, ну ещё, конечно, JS на стороне клиента и вот и всё.
ThunderCat
15.08.2016 09:49+3вот, а я вот думаю, я один такой дурак, который знает 2-3 технологии хорошо, и новые просматривает только с позиции «хм, смотри какую хреновину интересную наворотили, интересно, сколько она протянет, пока ее ченть подобное не переплюнет»?
Odrin
15.08.2016 13:12Видимо, у Вас нет необходимости проходить собеседования на вакансии «Front-end developer». Но есть и те, кто выбрал для себя front-end и при этом стремится к развитию.
ThunderCat
15.08.2016 15:26+2Скажу честно — с ужасом взираю на зоопарк фронтендеровских примочек, которые сегодня требуют от будущих работников, при том что с 90% задач справится стандартный стек из JQ, bootstrap и html5. А в большинстве случаев и натив жс вполне хватает. А если уж совсем честно, то и бутстрап вовсе не везде нужен.
Odrin
15.08.2016 16:32Для каких-то простых задач и небольших приложений — все верно.
Но как только в требованиях появляется адаптивный интерфейс — bootstrap ускоряет процесс разработки и кол-во косяков в разы.
Потом появляется необходимость добавить в интерфейсе datetime picker. Казалось бы — банальный контрол. Но FF все еще не поддерживает type=«datetime»! И снова выбор — взять плагин к jQ или писать самому. Естественно разработчик выбирает jQ, ведь это — уже стандарт; в будущем понадобятся и другие плагины; экономия времени; меньше ошибок. И именно время здесь является первопричиной, ведь за любым проектом стоит бизнес и сроки.
Если проект большой, то очень скоро он превращается в страшного монстра из callback-ов, в этом суть jQ подхода. Поддерживать jQ проекты сложно, а писать прозрачный jQ код — еще сложнее. И чем больше команда разработки, тем эта проблема острее.
Следствием этого становится Angular / React и т.д. Лично Я после 1.5 лет работы с Angular 1/2 вспоминаю все что было до него как страшный сон. Angular и подобные framework'и — это эволюция front-end разработки. Да, Я собрал все грабли и потратил много времени на изучение документации/stackoverflow. Но за это получил четкую архитектуру, понятный и структурированный код и главное — возможность легко разобраться в чужом коде на том же framework'е. Разработчики меняются, а код остается, и его надо сопровождать и развивать.
TS, Babel, AMD, Angular 2 — все это логическое продолжение этой темы.
Вы же не пишите свою реализацию http протокола каждый раз, когда надо написать свой rest api web — сервис. Так что зоопарк библиотек и framework'ов есть в большинстве ЯП и на любой платформе, достаточно вспомнить ту же Java.springimport
15.08.2016 16:57На счет Angular 1 не согласен. Код получается так себе, особенно когда нужно включить 10 зависимостей. Тем более, нет какой-то четкой архитектуры, у всех все разное.
Odrin
16.08.2016 11:31Это проблема исключительно из за несоблюдения style guide. А уж подключение 10 зависимостей — тем более не косяк framework'а.
От говнокода ни одна платформа не спасет.springimport
16.08.2016 15:55Вот простой пример. Как-то не проглядывается читабельность.
'use strict';
customer.controller('CustomerModalAddFormCtrl', ['$scope', '$uibModalInstance', '$window', 'CustomerAPI',
function ($scope, $uibModalInstance, $window, CustomerAPI) {
//…
}
]);
И не надо про зависимости, выше обычный контроллер, который толком еще ничего не делает, а их уже 4 штуки и смотрятся ужасно.Gugic
16.08.2016 22:42Добавьте чуть-чуть ng-annotate и просто разделите код, получится тоже самое, но гораздо лучше:
'use strict' customer.controller('CustomerModalAddFormCtrl', customerController) /*@ngInject*/ function customerController($scope, $uibModalInstance, $window, CustomerAPI) { // ... }
А если добавить es6, typescript и немного декораторов, то будет совсем здорово.
springimport
16.08.2016 23:04А ссылки дадите на примеры?
Gugic
16.08.2016 23:26На днях писал статью (правда она скорее про настройку окружения и про то, как с этим жить).
Про компоненты сами по себе вот тут отлично написали.
Мой велосипед уже в продакшене, полет нормальный. Самодельные декораторы стоит заменить на ng-metadata
Odrin
17.08.2016 10:47+1Как Я и написал, проблема исключительно из за не следования style guide. Кроме того, на 90% уверен, что $scope в контроллере Вам не нужен.
mrsantak
15.08.2016 21:47Меня больше пугают всякие системы сборки/менеджеры зависимостей. Я так-то пишу на Java, к 100500 библиотекам в проекте привык. Но так же и привык к одной системе сборки на весь проект. Там чтобы добавить библиотечку нужно указать пару-тройку зависимостей и всё. А тут открываешь какой-нибудь hello world на react'е и там какой-нибудь babel+npm+webpack при этом у каждого свой конфиг, они как-то согласованы должный быть, и фиг пойми что за что отвечает. В итоге тонешь в попытке разобраться сразу с четырьмя новыми технологиями.
Odrin
16.08.2016 12:05Gradle появился 9 лет назад, Maven 12. WebPack вышел 3 года назад, если смотреть на GitHub, Bower 4 года, NPM 6 лет. (про Gulp не смог найти информацию о первом релизе). Со временем, вероятно, все это разовьется до более удобного инструментария, а все лишнее и неудобное отомрет.
Quiensabe
14.08.2016 22:26-2Технологи?ческая сингуля?рность — гипотетический момент, по прошествии которого, по мнению сторонников данной концепции, технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию
Имхо — все довольно просто. Web-разработка в силу разных причин приближается к сингулярности быстрее чем другие области деятельности.
И такой подход уже дает как общее понимание ситуации, так и потенциальные возможности решения проблемы.zim32
14.08.2016 22:33Какое? rm -rf /?
bertmsk
14.08.2016 23:32+4Не пользоваться фреймворками очевидно же. Максимум jQuery или встроенными модулями/драйверами субд в nodejs. Всё остальное — ересь, за которую «инициативный и прогрессивно мыслящий сотрудник» получает линейкой по рукам и битой по башке.
Quiensabe
15.08.2016 00:34«ересь» — очень подходящее слово. Его как раз активно использовали в похожей ситуации, веков эдак 5 назад.
handicraftsman
15.08.2016 17:10Согласен. Лично я так вообще для вебдева использую только две небольшие либы: для css и для js. Остальное не надо.
Quiensabe
15.08.2016 00:31-2Точно также как вообще бороться с сингулярностью: не можешь победить — возглавь.
В данном случае — нет смысла бороться с тенденцией, для человеческого разума эта область становится слишком сложной (собственно об этом и статья), но можно повернуть ситуацию себе на пользу.
Необходимо создавать интеллектуальные средства разработки, которые смогут автоматизировать использование существующих средств, комбинировать их, дополнять, обновлять… Человеку не обязательно понимать как в деталях работает приложение, если оно работает и его можно легко изменить.
Сейчас «true-программисты» меня заминусят, да и ладно) Интересно, как эти люди вообще представляют себе наступление технологической сингулярности?..
И я не говорю, что этот подход «правильный». Это просто то что нас ждет, хотим мы этого или нет (IMHO). И со временем то же будет в других сферах. Думаете конструируя ИИ через N-лет программист будет задумываться о том как работает каждый искусственный нейрон?
QtRoS
15.08.2016 00:09+9Автор, просто напишу, что я с тобой согласен, и в статье рассмотрена всего лишь маленькая часть проблем. Все началось с того, что изначально статическую страницу решили оживить…
vsb
15.08.2016 00:18+4Просто в вебе много бардака, непродуманных решений и обратной совместимости. С другой стороны востребованность привлекает туда много людей, это порождает очень много разных решений, из которых естественный отбор оставляет лучшие и отбраковывает худшие. Лично я вижу прогресс. Если сравнивать 2005, 2010 и 2015, это очевидно.
Rampages
15.08.2016 06:51-1Добавлю, что скорость изучения у некоторых индивидуумов, довольно разная, и те кто отстают через некоторое время начинают строить костыли на базе своих нынешних знаний и порождают библиотеки и фреймворки, которые существуют в рамках одного проекта и более нигде не нужны.
Вообще прогресс мог бы идти быстрее, если бы не браузеры и устройства на которых стоят браузеры (в купе с нерадивыми пользователями, которые не могут обновить браузер).
Skerrigan
15.08.2016 08:05+1Обновил браузер — хром перестал рисовать тени у строк таблиц. Опять сломали. Который раз по счету уже за последние пять лет. Просто рука-лицо.жпг
webmasterx
15.08.2016 03:31+1Я как раз таки занимаюсь разработкой на ангуляре 2, и заявляю что вы немного перегибаете палку.
>>В итоге получаете сборку размером 2 Мб!
Dev версия? Ну и что? У меня продакш 0.5Мб, и это еще у меня rc4, без lazy load модулей появившихся в rc5
>> Ulgify переименовал [ngClass] в [ngclass]
Неправильно настроили. У большинстве все работает как надо. (UglifyJsPlugin)
А про ситуацию с мертворожденными пакетами, одинаковыми по функционалу и часто забрасываемому — так это же мир JS, это сразу становится понятным еще на первых шагах влево от jQuery, и ситуация может измениться, только если кодить начнут бекэндеры, а не фронтэндеры.
(Ссылка в тему, с последнего дайджеста ) https://medium.com/@FelixIT/%D0%B0%D0%BD%D1%82%D0%B8%D0%BE%D0%B4%D0%B0-%D1%84%D1%80%D0%BE%D0%BD%D1%82%D0%B5%D0%BD%D0%B4%D0%B5%D1%80%D0%B0%D0%BC-53645b26b16a#.3g3dz9do8zim32
15.08.2016 09:51Подскажите, с какими опциями нуждо использовать этот плагин? У меня по дефолту не заработало ничего.
webmasterx
15.08.2016 10:57beautify: false, //prod
mangle: { screw_ie8: true }, //prod
compress: { screw_ie8: true }, //prod
comments: false //prod
pengyou
15.08.2016 08:25вот, кстати, ответ https://habrahabr.ru/post/307468/
> Дуглас Крокфорд как-то сказал: «Веб — это наиболее враждебная среда разработки, которую только можно представить».
> И он чертовски прав. Это та враждебность, которая даёт мне доступ в мир. Это та «враждебность», которую я называю своим ежедневным вызовом.
> Эта враждебная среда вдохновляет меня. Сделать так, чтобы моя страница рендерилась везде. Написать код таким образом, чтобы страницу мог видеть каждый.
Понимаете, да? Для «них» это вызов, это вдохновляет.
kostein
15.08.2016 09:53DOM — я так и не понял почему он так сделан…
bower, man-bower-files, gulp-bower… etc — велосипед с костылями, где автоматизацию нужно автоматизировать ручками.
Любой JS фреймворк вликолепен в написании todo!
Armozlo
15.08.2016 09:53Насколько я понимаю — проблема такая: мы используем новые технологии, но для них не работают старые штуки. Чтобы работали старые штуки, мы используем старые технологии, но они не новые.
В итоге — новые штуки мы использовать можем только с новыми технологиями, для старых их никто не будет реализовывать. А старые штуки мы можем использовать со старыми — пока их реализуют для новых, новые уже станут старыми.
Я бы сравнил это с использованием электрического двигателя для машины. Новая технология — но нет заправок. Пока построят заправки, уже все начнут ездить на водороде.
Так может ездить пока на бензине?
AntonMMF
15.08.2016 09:53Точно такие же мысли были недавно.
Решил начать использовать на проектах ES6, а для конвертации в поддерживаемый код решил использовать связку Gulp+Babel. И всё было хорошо до поры до времени, пока не оказалось, что IE11 отваливается с кодом, созданным Babel. Ок, ладно если бы IE9, я бы исходный код переделал, так уж и быть, но IE11 — это как минимум говорит о том, что меня где обманули или недоговорили правду, когда расхваливали какой Babel хороший, давайте его все использовать. Стал гуглить решение проблемы — единственное, что нашёл, это подключение js-файла с полифилами аж на 100 килобайт. 100 килобайт, Карл! Чтобы заставить сгенерированный Babel код наконец-таки заработать. Мне в чатах подсказали возможный путь решения проблемы, но это абсолютно нездоровая ситуация, когда на каждом углу хвалят инструмент, а этот инструмент требует нехилой такой доработки для реального использования. И да, файлик на 100 килобайт с полифилами помог, но вылезла другая ошибка, на которую в гугле был только открытый тикет в Babel от февраля сего года.
И это далеко не первый случай, когда достаточно наслушался о чём-то, а по факту в продакшене использовать это крайне проблематично. С одной стороны, если не изучать всё это новомодное, то через N лет будешь никем. Но изучение и использование новомодного связано с такими матами и разочарованиями, что иногда вообще жалеешь, что ввязался во front-end когда-то.ivahaev
15.08.2016 10:44+1Как по мне, так если разрабатываешь бизнес-приложение, то можно тупо забить на старые браузеры и диктовать использование своего. Для публичных сайтов – да, такое не подойдёт, а вот для приватных проектов, где чаще всего применяются сложные интерфейсы с извращенной логикой, такой проблемы нет.
Starche
15.08.2016 15:31Спасибо вам за комментарий. Всё думал, переходить ли на ES6(babel) или пока остаться на TypeScript (который уже что-то из ES6 и сам поддерживает, но далеко не всё). Пожалуй останусь на TypeScript — там по крайней мере на IE точно ориентировались, когда писали. Ну и в целом в продакшене у меня пока с ним не возникало проблем
kissarat
15.08.2016 09:53Потому что Angular-way. Я не смог заставить запускатся Angular 2 так как хотел (не через webpack) и забил болт на него… Собственно из-за zone.js, необходимость в котором мне не понятна
Odrin
16.08.2016 12:10Собственно из-за zone.js, необходимость в котором мне не понятна
Dynamic data binding, нет? Какой вообще смысл в Angular без data binding?
sneakyfildy
15.08.2016 10:45((Require, Angular (1.5), LESS, Bootstrap, jQuery) + самописный микс PrototypeJS, чтобы определять и работать с «классами» в стиле ExtJS) * Grunt.
Ну и всё, никаких проблем.
Просто надо уметь вовремя остановиться и набирать в проект такие технологии, которые будут достаточными (и не вовлекать новые).
Правда, я работаю над одним приложением несколько лет, а не пилю каждый день новый сайт, так что не знаю, как живут люди в том мире (думал, там еще более упорядоченно всё).
Jaromir
15.08.2016 12:37«Вредные советы хипстеру»
Я выучил gulp, requirejs, babel, coffescript, browserify и так далее. Typescript стал последней каплей после которой стресс стал перманентным, а душа потребовала простоты и понятности
1. Es6 еще не пришел в браузеры, а значит использовать его еще рано. Вместо этого пишите на es5. Бонус: не нужно транслировать. Выполняется тот код, который вы написали
2. Хорошее покрытие тестами > typescript. Бонус: есть тесты — нет стресса при рефакторинге
3. Js файлы в большинстве случаев не обязательно запаковывать в один. Сравните в вашем проекте скорость загрузки всех ваших js-файлов по отдельности и одного, склеенного. Вспомните о кэшировании. И, возможно, вы решите обойтись без склеивания. Бонус: исчезнет необходимость в упаковщиках и sourcemap
4. Вам не всегда нужны загрузчики. Помните о том, что глобальный environment глобален только в пределах вашей страницы, а не всего браузера. Используйте js module pattern. Пусть каждый ваш js-файл создает одну глобальную переменную с префиксом. Например projectname_mycontroller. Проблемы могут возникнуть только если в вашем проекте не менее тысячи файлов. Бонус: не нужен requirejs. Бонус2: если захотите, можете склеить всё в один файл простым cat file1.js file2.js… > app.js. Но лучше не делайте этого (см. пункт 3)
5. Jade, less и прочие. можно транслировать используя make-файл. Он создавался именно для этой цели — преобразовывать одни файлы в другие если они изменились. Но надеко не всегда в этих инструментах есть необходимость. Простой CSS очень неплох сам по себе если знать все его особенности
6. Вам не всегда нужен react или angular. Найдите минимальную библиотеку или фреймворк, достаточную для вашего проекта. Благо выбор огромен. Используйте те библиотеки, работу которых вы понимаете. Больше магии — больше стресса. Маленькие вещи можно писать на нативных DOM и events. Они уже практически одинаковы во всех браузерах.
В результате я стал менее производительным. Однако появилось полное понимание структуры и работы проекта. А вместе с тем улетучился стресс. А еще исчезла необходимость в nodejsMiKXMan
15.08.2016 18:461. ES6 имеет огромную кучу классных фич, которые я хочу использовать в своем коде. Они делают код понятнее, выразительнее, более поддерживаемым и т.д.
2. Отчасти согласен, что тесты нужно писать. И лучше писать тесты на бизнес логику, чем на проверку типов.
3. Уже проходили, загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла (именно так технологии вроде browserify появились на смену тому же require.js)
4. Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал, или другой разработчик напишет перекроет что-то. Опять таки, уже проходили. И именно потому что это не scalable, и само по себе является антипаттерном, в мир JS пришли AMD, CommonsJS, Import/Export, как во всех нормальных языках.
А что делать со сложными зависимостями (мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную) — вообще не понятно
5. Опять таки — почему бы мне не использовать возможности LESS, только потому что по Вашему мнению CSS не так уж плох? Зачем мне писать свои make файлы, если я могу использовать готовый продукт для этого?
6. Насколько маленькие вещи? Вы точно знаете когда маленькие вещи перерастут в большие? Зачем мне потом переписывать то, что я могу написать изначально правильно? Ну и ставить реакт с ангуляром вместе в одном предложении — говорит только о том, что Вы не совсем в теме
Мне кажется, подобные советы вредны даже для написания простеньких сайтов, не говоря уже о более ли менее сложных и больших продуктовJaromir
15.08.2016 19:42+1> ES6 имеет огромную кучу классных фич, которые я хочу использовать в своем коде
Да
>Они делают код понятнее, выразительнее, более поддерживаемым и т.д
Будут делать. На данный момент мы имеем неподдержиеваемый выхлоп из babel-a плюс (по словам ОПа) 100КБ полифилов
> загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла
Намного это насколько? Сами проверяли или прочитали? В моем проектике около 100 маленьких js файлов. Разница первого запуска в 1.3 раза. Разница последующих запусков отсутствует. Считаю это нормально
> Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал
Одна библиотека — одна глобальная переменная. Обычное явлене в js
>в мир JS пришли AMD, CommonsJS, Import/Export
Import/Export еще не пришли, в том и суть. Остальные способы — страшные костыли, которые канут в лету с приходом Import/Export
> мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную
Вы что-то делаете не так
> Насколько маленькие вещи?
Вам решать.
> Вы точно знаете когда маленькие вещи перерастут в большие?
Обычно знаю. При нормальном разбиении приложения на слои, заменить рендер с какого-нибудь mustache на react не вызывало сложностей.
anushirvan
15.08.2016 13:10asp.net core mvc на первый взгляд выглядит серебряной пулей. Кто-нибудь, кто попробовал, можете отписаться как оно в деле?
zenkz
15.08.2016 18:00Пока опыта мало, но не думаю что это так.
Во-первых он не решает проблем на клиентской стороне (тот же JS и CSS)
Во-вторых есть ещё много детских болезней:
— отсутствие большого количества обучающего материала и документации
— пока нет инструментов разработки из серии создал проект и запустил. Нужно устанавливать .Net Core, разбираться с VS Code, конфигурировать, подключать библиотеки и т.д.
— неизвестно ещё насколько технология будет принята сообществом. Не умрёт ли она через 2-3 года…strapony
17.08.2016 14:10> Нужно устанавливать .Net Core, разбираться с VS Code
VS Community / JetBrains Rider?
> конфигурировать, подключать библиотеки и т.д.
nuget точно такой же, как и в стандартном .net
PaulZi
15.08.2016 13:33+2Вставлю свои 5 копеек. Согласен с автором на все 100%, и вот почему. Изначально JS был языком, который добавил немного динамики в HTML. Например, никто тогда не заморачивался над тем, зачем нужны полноценные классы, и внедрили в него систему на прототипах. Сейчас все поняли, что классы нужны и они появились в ES6, но, опять обрезанные — нет ни private/protected свойств, ни других полноценных возможностей.
Вторая большая проблема — зоопарк браузеров. Если кто помнит, ActionScript во флеше, так же был изначально слабым языком, который лишь добавил немного скриптов, но с выходом AS 3.0 он стал очень мощным, а так как во флеше лишь один вендор — то все быстро перешли на 3.9. В вебе же даже если кто-то предложит супер альтернативу (например, Dart), разработчикам всё равно нужно поддерживать другие браузеры, а это значит надо использовать конвертеры, со всеми их ограничениями.
Третья проблема — слабость JS. Вот ей богу, были бы поддерживаемые всеми браузерами стандартные механизмы загрузчиков модулей и зависимостей, шаблонизатор, событийные системы для объектов, не было бы столько фреймворков, каждый из которых по своему реализует тот или иной «пробел» в JS. И эти инструменты всё время меняются — если недавно миром царил jQuery, вчера Backbone, а сегодня React.
В итоге получаем слабый JS, тучу фреймворков, толпы их фанатиков, и ад, от которого хочется бежать куда подальше. И мне есть с чем сравнивать, например по сравнению с бэкэнд-разработкой на PHP, у нас тут тишина и спокойствие. Да, есть конкурирующие фреймворки, но топовых можно пересчитать по пальцам.zim32
15.08.2016 14:04+3Согласен. Возьмите к примеру вот этот список плагинов для очередного нового модного и продвинутого фреймворка KoaJS (https://github.com/koajs/koa/wiki)
Да там одних только роутеров 20 штук. Двадцать роутеров!
К-во шаблонизаторов для JS уже тоже достигает критической отметки. Посмотрите тут https://github.com/tj/consolidate.js
Да и есть вопросы про сам фреймворк KoaJS. Ну что в нем такого революционного. Использовали генераторы в async await обертке от бабеля как киллер фичу. Ну неужели нельзя было это сделать в рамках ExpressJS. Зачем создавать еще одну экосистему?
shoomyst
16.08.2016 01:03Как бы для этого и был создан Koa, т.к. используют разные подходы. Чтобы Экспрессу перейти на async/await придется переписывать всю экосистему вокруг него. Кому это надо, если большинство устраивает текущий подход. Кого не устраивает, могут перейти на Koa
Alexey2005
15.08.2016 20:26Эта проблема лучше всего решается монополизацией движка. Если останется один-единственный браузерный движок, то его владелец сможет легко, быстро и ни с кем не согласовывая вводить новые фичи. В предельном случае он сможет даже забить на улиточных бюрократов из W3C, прописав собственные стандарты для удобства разработчиков.
worldmind
15.08.2016 13:46+1Как-то недосказано, проблема реально есть, html это язык разметки гипертекста, а теперь его используют как язык разметки интерфейсов и конечно это не может работать хорошо, поэтому и развелось всяких js фреймворков которые пытаются как-то пофиксить проблему, но это костыльный пусть.
Ну и идея с разделением содержимого и оформления не очень получилась, вроде CSS есть, но при этом html переполнен div'ми добавленными туда только для обеспечения нужного оформления — читаемость ужасная.
Aquahawk
15.08.2016 14:05+1Это вы ещё не запустили то что написали. Ибо запустив вы узрите насколько браузеры отличаются.
jaybekster
15.08.2016 16:21Хотелось бы услышать тогда предложение по решению проблемы. Ожидал в конце статьи будет ссылка на новый сборщик и фреймворк от автора, пока всё остальное тлен и костыли, вот вашему вниманию stable :) А предыдущий текст — как предвкушение чего-то нового и молодёжного :)
Jaromir
15.08.2016 16:45Взять любой современный тулкит (например, WPF) и сделать из него «браузер» (кроссплатформенную загрузку и отображение кода). Будет wpf:// вместо http://
PaulZi
15.08.2016 16:47+1Если бы автор предложил свой фреймворк, то это было бы странно, т. к. автор сам и пишет, что слишком много фреймворков.
Решением было бы ES7 реализованный в браузерах с загрузчиком модулей, настоящими классами, и всеми теми функциями, которые сейчас реализованы во фреймворках, но как понимаете, даже если это произойдёт, это дело не ближайшего будущего.
В общем получился пост, открывающий тёмную сторону frontend-разработки и его сложности.
mrigi
15.08.2016 17:22+1А можно просто кодить в миднайт-коммандере вёрстку таблицами и забить на все эти новые веяния. И на удивление школьникам все у вас будет хорошо.
zenkz
15.08.2016 17:39+1А зачем использовать в одном проекте десятки библиотек/фреймворков?
Многим кажется, что лучше использовать готовое решение, чем изобретать велосипед и они с радостью начинают подключать фреймворки и модули к проекту и через пару месяцев/лет разработки проект превращается в монстра, который сложно разрабатывать и поддерживать.
Для себя выбрал следующий стек для веб части проектов:
— HTML5
— CSS3 + Bootstrap
— JS + JQuery + (AngularJS или KnockoutJS или ReactJS) (основное использование — binding и observable-переменные для уменьшения js кода)
Пока не пользуюсь ES6 или TypeScript, потому что не хочу возиться со сборщиками. Когда у современных браузеров будет поддержка этих языков из коробки — с удовольствием перейду на них.
Как я вижу решение этой проблемы:
Шаг 1. Общие стандарты для браузеров — весь HTML, JS, CSS код должен везде отрабатывать одинаково. Если хотят добавить что-то новое, то сначала вводят в стандарт, а потом применяют во всех браузерах.
Шаг 2. Новое поколение языков. К примеру HTML6 + ES7 + CSS4, которые бы покрыли запросы разработчиков и заменили собой фреймворки (к примеру поддержка адаптивного и гибкого дизайна в CSS сделает ненужным bootstrap. Добавление туда же наследования и ещё улучшений сделает ненужным LESS/SASS. То же самое и для JS-ES) — если это сделают удобным для разработчика, то через 2-3 года нам не понадобятся существующие фреймворки (но наверняка появятся новые). К тому же за счёт оптимизации выполнения кода в браузере мы можем получить ускорение работы сайтов.
Жаль что вряд-ли это случится…zim32
15.08.2016 18:06Мне уже кажется что все эти разработчики инструментов лобируют медленное принятие стандартов.
sashabeep
18.08.2016 17:34Читая такие статьи, и все больше убеждаюсь, что с тех пор, как программисты пришли во фронтенд, они притащили туда все свои проблемы из программирования на десктопах. То компилер не тот, то стандарт не тот, то пакет не собирается…
А ребята из Виллабаджо продолжают писать сайты по 10к страниц, нормально работающие везде.Garbus
18.08.2016 18:21А это не последствия подхода? Когда берется результат для сайта с парой десятков страниц, на который нанимают «программиста на час», который за вечер пытается из того что есть, слепить то что надо?
Грубо говоря как сравнивать инди разработку на готовом движке и ААА проект, когда могут позволить разработать все полностью.sashabeep
18.08.2016 18:24Мне непонятно, зачем этот программист для сайта с двумя десятками страниц городит такой огород что волосы дыбом встают.
Chamie
18.08.2016 18:33Это вы «10к» прочитали как «десяток»? «10кбайт» = десяток байт?
Garbus
18.08.2016 19:40Ну тут понятие очень растяжимое. Что считать страницей? Взять для примера википедию, что там считать страницей? Шаблон в котором размещен текст статьи? Сам текст, не включая шаблон? А как быть с комментариями и историей правок? Потому что я очень сомневаюсь, что кто-то станет делать сайт из 10000 «простых» (статических) страничек, не генерируемых из шаблона и неких данных.
P.S. 10к есть 9 999,99. Как любят писать продавцы ;)
A-Stahl
>Как вы думаете изменится ли ситуация в ближайшем времени?
Я плюсовик и с вебом сталкиваюсь редко и очень поверхностно, но с моей колокольни предпосылок для улучшения ситуации не видно.
Откуда вы взяли это голосование? У вас есть основания предполагать(надеяться), что что-то изменится? Какие? Расскажите…
yadobr
Не знаю, как считает автор статьи, но мое мнение такое: Нужен не просто новый ЯП для веба с ООП, но он так же должен вобрать все то лучшее, что появилось в этом «зоопарке технологий».
Честно, я сам устал от этого урагана фреймворков. От этих костылей, стоящих на костылях.
Сейчас у меня стек технологий такой:
1) html — Jade
2) css — Stylus
3) js — React.js|Ember|Angular, jquery и миллион мелких плагинов
4) Node.js, express, socket.io
5) Gulp, Webpack(с его не очевидным api и общей сложностью)
И это только то, что я использую каждый день
yadobr
Забыл добавить, что по идее, это все должно упрощать мою жизнь разработчика, но по факту, только усложняет её.
YNile
Так не пользуйтесь, если усложняет то, разве нет? Или вы имеете ввиду — «усложняет по сравнению с идеальным языком для веба, который сделает все классно»? :)
CGS
Согласен, как кто-то писал на хабре, простые вещи должны оставаться простыми.
SamoilowAlex
sashabeep
Этот язык есть и он называется ActionScript, а дальше вы поняли…