Комментарии 121
НЛО прилетело и опубликовало эту надпись здесь
Не знаю, как считает автор статьи, но мое мнение такое: Нужен не просто новый ЯП для веба с ООП, но он так же должен вобрать все то лучшее, что появилось в этом «зоопарке технологий».
Честно, я сам устал от этого урагана фреймворков. От этих костылей, стоящих на костылях.
Сейчас у меня стек технологий такой:
1) html — Jade
2) css — Stylus
3) js — React.js|Ember|Angular, jquery и миллион мелких плагинов
4) Node.js, express, socket.io
5) Gulp, Webpack(с его не очевидным api и общей сложностью)
И это только то, что я использую каждый день
Честно, я сам устал от этого урагана фреймворков. От этих костылей, стоящих на костылях.
Сейчас у меня стек технологий такой:
1) html — Jade
2) css — Stylus
3) js — React.js|Ember|Angular, jquery и миллион мелких плагинов
4) Node.js, express, socket.io
5) Gulp, Webpack(с его не очевидным api и общей сложностью)
И это только то, что я использую каждый день
Вспомнив ситуацию в сфере ОС, не особо верю в улучшения — то есть, хорошие решения будут, но не будут популярными, как в случае с GNU/Linux.
Да вот как раз GNU/Linux — это квинтэссенция всего того, о чём написано в данной заметке.
Дичайший кошмар с фрагментацией, когда очередной форк выходит из употребления быстрее, чем его успеваешь освоить.
Дикое костылестроение, когда явные дыры наспех затыкаются костылями в надежде, что раз OpenSource, то потом кто-нибудь другой их отрефакторит или переделает как надо.
Полнейшее нежелание составлять и поддерживать актуальную документацию, т.ч. сведения всегда приходится собирать по крупицам, причём эти крупицы могут использоваться лишь приблизительно, ибо устарели лет на пять.
Дичайший кошмар с фрагментацией, когда очередной форк выходит из употребления быстрее, чем его успеваешь освоить.
Дикое костылестроение, когда явные дыры наспех затыкаются костылями в надежде, что раз OpenSource, то потом кто-нибудь другой их отрефакторит или переделает как надо.
Полнейшее нежелание составлять и поддерживать актуальную документацию, т.ч. сведения всегда приходится собирать по крупицам, причём эти крупицы могут использоваться лишь приблизительно, ибо устарели лет на пять.
По большей части вы перечислили проблемы семейства *buntu. Для остальных всё (или большая часть) не так актуальны.
НЛО прилетело и опубликовало эту надпись здесь
против ROR ничего не имею вот только про «объединить в себе множество людей» вы загнули. Рубистов, когда это требуется, днем с огнем ищут вплоть до релокации сотрудников из других регионов. 90% как использовали php так и используют. Имел бы Ruby в целом и RoR в частности столько же последователей сколько имеет JS, ситуация была бы аналогичной.
> В итоге получаете сборку размером 2 Мб! И начинаете писать webpack костыль, который отложит загрузку каких-то модулей до нужного момента. Причем решается это все ужасно через регулярки.
Ээээ, а как же require.ensure? или вы думаете те кто пилят такие утилиты дураки?
Ээээ, а как же require.ensure? или вы думаете те кто пилят такие утилиты дураки?
Вы подключаете ангулар модуль, который использует RxJS к примеру и который и знать не знает ни про какой require.ensure
Ну так возьмите и допилите этот модуль, чтобы он знал RxJS. Или используйте другой.
Статья состоит из нытья о том, что автору кто-то неведомый что-то должен и не отдаёт.
Дали сборщик, дали модули, дали фреймворки — выбирай и радуйся, не пиши велосипеды. Нет, хочу плакаться что библиотека А не полностью совместима с фреймворком Б.
Если вам не нравится то, что есть — дорабатывайте или пишите велосипед. Это же Open Source.
Как дети, честное слово.
Статья состоит из нытья о том, что автору кто-то неведомый что-то должен и не отдаёт.
Дали сборщик, дали модули, дали фреймворки — выбирай и радуйся, не пиши велосипеды. Нет, хочу плакаться что библиотека А не полностью совместима с фреймворком Б.
Если вам не нравится то, что есть — дорабатывайте или пишите велосипед. Это же Open Source.
Как дети, честное слово.
С выходом новых стандартов (es7, web components) проблемы решаться сами собой
Новые стандарты не решают накопившиеся проблемы
Новые стандарты сделают неактуальными старые проблемы и породят новые. На смену одним костылям придут другие. Свежесобранные велосипеды обгонят уже существующие, а дальше притормозят и начнут ехать с той же скоростью. Существующие фреймворки обновят первую циферку в версии, потом перестанут быть такими популярными, а потом окончательно падут под напором новых инструментов. Разработчики опять начнут рвать волосы, которые только-только отросли после предыдущей смены стандартов, с дикими криками матеря всех и всё.
Новые проблемы вернут нам старые разговоры о том, что надо существующий зоопарк решений как-то привести в божеский вид, для чего, пожалуй, надо ввести какие-то новые стандарты, которые нам всенепременнейше помогут.
И всё повторится вновь, потому что шоу должно продолжаться.
Се ля ви, вряд что то изменится.
Согласен…
Проблемы возникают когда, кто-то с благой целью пытаются упростить жизнь другим, и начинает выдумывать новый велосипед (стандарт), поверх не совсем стандартизиованной связки HTTP, HTML, CSS, JS. Дичайше долго реализовывают новые вещи в этих трех… Но. В любой момент времени этой связкой можно пльзоваться без каких либо проблем, и без всяких надстроек.
Вот Только програмисты великий народ с великой ленью (хапанул косяк из доков и давай кодить, а их скурить полностью надо и не один раз). Им проще 100500 раз по… ться с чужими костылями, методологиями и фреймворками… Чем раз в 10 лет выучить простой стандарт, и официальные рекомендации к нему… (Народ до сих пор пользуеться видоизменненной табличной версткой — bootstrap ets.)
Еще плохо, что в новый стандарт ЕS6 напихали всякого, а толку. Например, классы — в интепритируемом языке как гвоздь в подошве, интерпритатор делает двойную работу!!! Спрашивается ЗАЧЕМ??? Что-бы было удобно програмисту недоучке. Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь). Как на меня, Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Если посмотреть, ничего существенно нового не добавилось, все новое это перефразированное старое, в другой подаче — но суть то не поменялась (списки, стрелки, литералы, ..., нафиг не нужные константы). Реально новое, это (игры с параметрами, символы, итераторы и генераторы) но пользы от них не много. И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики (как говорят разработчики МАГИЯ)…
Проблемы возникают когда, кто-то с благой целью пытаются упростить жизнь другим, и начинает выдумывать новый велосипед (стандарт), поверх не совсем стандартизиованной связки HTTP, HTML, CSS, JS. Дичайше долго реализовывают новые вещи в этих трех… Но. В любой момент времени этой связкой можно пльзоваться без каких либо проблем, и без всяких надстроек.
Вот Только програмисты великий народ с великой ленью (хапанул косяк из доков и давай кодить, а их скурить полностью надо и не один раз). Им проще 100500 раз по… ться с чужими костылями, методологиями и фреймворками… Чем раз в 10 лет выучить простой стандарт, и официальные рекомендации к нему… (Народ до сих пор пользуеться видоизменненной табличной версткой — bootstrap ets.)
Еще плохо, что в новый стандарт ЕS6 напихали всякого, а толку. Например, классы — в интепритируемом языке как гвоздь в подошве, интерпритатор делает двойную работу!!! Спрашивается ЗАЧЕМ??? Что-бы было удобно програмисту недоучке. Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь). Как на меня, Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Если посмотреть, ничего существенно нового не добавилось, все новое это перефразированное старое, в другой подаче — но суть то не поменялась (списки, стрелки, литералы, ..., нафиг не нужные константы). Реально новое, это (игры с параметрами, символы, итераторы и генераторы) но пользы от них не много. И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики (как говорят разработчики МАГИЯ)…
>> Что-бы было удобно програмисту недоучке. Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь).
И получаем 100500 разных реализаций, т.к. язык очень гибкий и позволяет их все, и каждый из вариантов с точки зрения его разработчика «истинно правильный».
И получаем 100500 разных реализаций, т.к. язык очень гибкий и позволяет их все, и каждый из вариантов с точки зрения его разработчика «истинно правильный».
>>(Народ до сих пор пользуеться видоизменненной табличной версткой — bootstrap ets.)
пользуется потому что flexbox еще не поддерживается на подавляющем большинстве устройств
>> Спрашивается ЗАЧЕМ???
для удобства кодинга. конкретнее — для более лучшего удержания абстракций в голове.
>>Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Кодите просто на функциях, (вам же так сокрость работы нужна). Не используйте абстракции (объекты, структуры, потоки). посмотрим, какими будут ваши большие проекты, и как в них легко будет разобраться другим
>>И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики
>> Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь).
противоречие, вам так не кажется?
пользуется потому что flexbox еще не поддерживается на подавляющем большинстве устройств
>> Спрашивается ЗАЧЕМ???
для удобства кодинга. конкретнее — для более лучшего удержания абстракций в голове.
>>Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Кодите просто на функциях, (вам же так сокрость работы нужна). Не используйте абстракции (объекты, структуры, потоки). посмотрим, какими будут ваши большие проекты, и как в них легко будет разобраться другим
>>И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики
>> Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь).
противоречие, вам так не кажется?
А вы не могли бы по поводу классов в js поподробнее?
Может быть есть статья какая или что-то подобное про производительность. У любого метода есть свои плюсы и минусы. Спасибо.
Может быть есть статья какая или что-то подобное про производительность. У любого метода есть свои плюсы и минусы. Спасибо.
Ситуация меняется с отказом от JavaScript в качестве языка разработки (как для сервера, так и для клиента). Хорошие примеры: Erlang/N2O, Elm.
Выкинув Javascript останется большая дырень с тем, что Erlang не так распространен, и проблему это не решит. Это равнозначно «не пользоваться браузером = проблем не будет».
И да, нужно будет переписать кучу сайтов на Erlang, всем изучить этот язык, создать индустрию под это дело итд… короче жесть
И да, нужно будет переписать кучу сайтов на Erlang, всем изучить этот язык, создать индустрию под это дело итд… короче жесть
На клиенте JavaScript нельзя выкинуть, пока это единственный вариант, более-менее поддерживаемвый всеми браузерами. Его и не нужно выкидывать. Наша задача, чтобы в приложениях не осталось лажи. И JavaScript тут плохой помошник. (Также, как, например, PHP на стороне севрвера).
Не нужно переписывать сайты. Они умирают быстрее, чем успевают состариться естественным образом. Просто нужно новые сайты делать на правильных инструментах, которые правильным образом поддерживают «хуяк-хуяк и в продакшен»-методологию.
Не нужно всем изучать Эрланг. Пусть говносайты делают на говнофреймворках. А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Для бекенда есть достаточно хороших инструментов, которые не позволяют легко отстрелить себе ногу. Но для фронтенда нужно развивать и использовать вещи типа Elm. Тогда будет значительно меньше боли.
Не нужно переписывать сайты. Они умирают быстрее, чем успевают состариться естественным образом. Просто нужно новые сайты делать на правильных инструментах, которые правильным образом поддерживают «хуяк-хуяк и в продакшен»-методологию.
Не нужно всем изучать Эрланг. Пусть говносайты делают на говнофреймворках. А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Для бекенда есть достаточно хороших инструментов, которые не позволяют легко отстрелить себе ногу. Но для фронтенда нужно развивать и использовать вещи типа Elm. Тогда будет значительно меньше боли.
> И JavaScript тут плохой помошник
Дело не в JavaScript, а изначально в технологии HTML, живой картинки, DOM итд. Никто не знал, к чему это приведет, и что будет такой зоопарк.
> Наша задача, чтобы в приложениях не осталось лажи
Ну т.е. «а давайте все перепишем с нуля?» И опять-же, дело не в JavaScript.
> А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Проблема другая — Erlang'a нет в браузерах. А значит пусть вы напишете идеальный код на Erlang, но если пользователь не сможет купить товар/услугу на вашем супер-быстром сайте, то цена вашему сайту — 0.
> плохой помошник PHP на стороне севрвера
Чем же он плох?
Дело не в JavaScript, а изначально в технологии HTML, живой картинки, DOM итд. Никто не знал, к чему это приведет, и что будет такой зоопарк.
> Наша задача, чтобы в приложениях не осталось лажи
Ну т.е. «а давайте все перепишем с нуля?» И опять-же, дело не в JavaScript.
> А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Проблема другая — Erlang'a нет в браузерах. А значит пусть вы напишете идеальный код на Erlang, но если пользователь не сможет купить товар/услугу на вашем супер-быстром сайте, то цена вашему сайту — 0.
> плохой помошник PHP на стороне севрвера
Чем же он плох?
Вы не поняли, о чем я.
> Проблема другая — Erlang'a нет в браузерах
Это не проблема — Erlang компилируется в JavaScript. Elm компилируется в JavaScript. (Даже C++ копилируется в JavaScript или Web Asm :).
Пусть JavaScript останется тем же, чем являются ассемблер или машинные коды (или байткод виртуальной машины). С ним будет работать браузер, но на нем не надо программировать.
>> плохой помошник PHP на стороне севрвера
> Чем же он плох?
Тем же, чем он хорош — низким порогом входа.
> Проблема другая — Erlang'a нет в браузерах
Это не проблема — Erlang компилируется в JavaScript. Elm компилируется в JavaScript. (Даже C++ копилируется в JavaScript или Web Asm :).
Пусть JavaScript останется тем же, чем являются ассемблер или машинные коды (или байткод виртуальной машины). С ним будет работать браузер, но на нем не надо программировать.
>> плохой помошник PHP на стороне севрвера
> Чем же он плох?
Тем же, чем он хорош — низким порогом входа.
https://habrahabr.ru/post/119839/#comment_3940434 ))
Это как это вы Полимер в устарешие технологии записали? Что еще за бред?
Я не думаю, я уверен — в ближайшем (относительно) будущем что-то изменится. Только не в ту сторону, в которую хотелось бы.
Это как со смартфонами: при выходе нового смартфона множество рассказов, что он стал меньше потреблять энергии и итд. Вы ждете, что новый смартфон будет больше жить на одном заряде. Оправдались ваши ожидания? Нет — он просто стал тоньше.
Это как со смартфонами: при выходе нового смартфона множество рассказов, что он стал меньше потреблять энергии и итд. Вы ждете, что новый смартфон будет больше жить на одном заряде. Оправдались ваши ожидания? Нет — он просто стал тоньше.
Так он потому и стал тоньше, что железо стало потреблять на 20% меньше, и значит, появилась возможность снизить толщину, на эти же 20% уменьшив ёмкость батареи.
Другое дело, что бывает сложно объяснить, зачем же вообще нужно так сильно снижать толщину — вроде современные устройства уже и так тонкие, даже чрезмерно.
Другое дело, что бывает сложно объяснить, зачем же вообще нужно так сильно снижать толщину — вроде современные устройства уже и так тонкие, даже чрезмерно.
Так лучше б высвобожденное место заняла батарейка…
Ну так надо же маркетологам (и прочим) зарабатывать на хлеб? Вот и «воюют», то мегписелями камеры, то экраном, то толщиной и производительностью.
В результате, поиск качественного телефона для повседневных задач превращается в квест, который осилит не каждый обыватель. Да еще и приложениями норовят закидать так, что телефон тормозит сильнее старичка сделанного 10 лет назад.
В результате, поиск качественного телефона для повседневных задач превращается в квест, который осилит не каждый обыватель. Да еще и приложениями норовят закидать так, что телефон тормозит сильнее старичка сделанного 10 лет назад.
Спросил подругу, которая вечно жалуется на быстро садящийся айфон, какой бы она выбрала новый, такой же толщины, но с большей батареей, или более тонкий, но с такой же батареей как у старого, и, соответственно, коротким временем работы. Она выбрала последнее.
Такие дела.
Такие дела.
Вы еще забыли надвигающийся Dependency Hell в node.js:
Не хочу умалять заслуг автора статьи по ссылке, но вот это доставило (интересно, это он так шутит?): «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.»
Черт возьми, да вся статья — сплошной сарказм. Повеселился в общем. Спасибо за ссылку. :)
Жаловаться на текущее состоянии можно только не застав состоянии пару-тройку лет назад.
То что чем мы пользуемся сейчас (react+redux+webpack+es6) на голову или даже на две выше чем то с чем приходилось иметь дело ранее. Скорость, удобство разработки, удобство дебага — все в разы лучше.
Вебпак так вообще — несмотря на то что выглядит для нового человека как марсианский конфиг для космолета — очень, _очень_ простой и понятный (именно из-за этого он и выглядит костыльным — там нет привычной магии фрэймворков, нужно очень многое писать самому, понимая что ты делаешь)
То что чем мы пользуемся сейчас (react+redux+webpack+es6) на голову или даже на две выше чем то с чем приходилось иметь дело ранее. Скорость, удобство разработки, удобство дебага — все в разы лучше.
Вебпак так вообще — несмотря на то что выглядит для нового человека как марсианский конфиг для космолета — очень, _очень_ простой и понятный (именно из-за этого он и выглядит костыльным — там нет привычной магии фрэймворков, нужно очень многое писать самому, понимая что ты делаешь)
Я к примеру не могу понять как там сделать простейшую вещь — применить uglify только к одному файлу. И это в инструменте который создан для того чтобы упростить сборку?
А в чем проблема?
gulp.src('path/to/file').pipe(ugilfy()).pipe(gulp.dest('path/to/build'));
Давайте разберемся. Зачем применять Uglifiy на один файл?
Webpack — это прежде всего собириает все ваши файлы в один единый файл. И главная задача этой утилиты — не засорять global scope.
В статье написали, что после сборки получился файл весом 2Мб. Откройте окончательный файл. Там код вашего React, Redux и все остальных библиотек и фреймворков. Потратьте время на изучения webpack — webpack умеет не «включат» файлы в сборку. Тогда бы ваш HTML загружал бы библотеки с CDN, а ваша программа весила бы около 200кб.
Хватить называть чужой труд костылями. Без обид, если не умеете пользоваться — это ваши проблемы.
Webpack — это прежде всего собириает все ваши файлы в один единый файл. И главная задача этой утилиты — не засорять global scope.
В статье написали, что после сборки получился файл весом 2Мб. Откройте окончательный файл. Там код вашего React, Redux и все остальных библиотек и фреймворков. Потратьте время на изучения webpack — webpack умеет не «включат» файлы в сборку. Тогда бы ваш HTML загружал бы библотеки с CDN, а ваша программа весила бы около 200кб.
Хватить называть чужой труд костылями. Без обид, если не умеете пользоваться — это ваши проблемы.
Ну зачем это уже мое лично требование. Вы же не говорите заказчику к примеру «Зачем Вам этот уродский банер, он только отвлекает». Иначе получается что не инструмент для разработчиков, а наоборот. В итоге я должен еще поставить и заюзать gulp (пример типичного костыля)
>> webpack умеет не «включат» файлы в сборку
Да я знаю про IgnorePlugin. Правда так и не получилось добиться того чтобы в рантайме не выскакивало исключение «module not found ...», видимо надо строить граф и смотреть что чего там реквайрит.
После минификации всего и вся получилось 760Кб поправил статью.
>> webpack умеет не «включат» файлы в сборку
Да я знаю про IgnorePlugin. Правда так и не получилось добиться того чтобы в рантайме не выскакивало исключение «module not found ...», видимо надо строить граф и смотреть что чего там реквайрит.
После минификации всего и вся получилось 760Кб поправил статью.
>>> Тогда бы ваш HTML загружал бы библотеки с CDN, а ваша программа весила бы около 200кб.
Есть такие программисты которые почему то искренне верят в то, что CDN не может упасть а Facebook и Vk работают вечно.
Все что может сломаться — сломается и из-за того что библиотеки у вас на CDN как минимум вы получите просадку в скорости
загрузки, как максимум нерабочий сайт, потому что какая то либа отвалилась.
Есть такие программисты которые почему то искренне верят в то, что CDN не может упасть а Facebook и Vk работают вечно.
Все что может сломаться — сломается и из-за того что библиотеки у вас на CDN как минимум вы получите просадку в скорости
загрузки, как максимум нерабочий сайт, потому что какая то либа отвалилась.
Ну во-первых можно давать ссылку на свой сайт.
А во-вторых ссылку на CDN пытаться загрузить первой и если не получилось — тогда грузить со своего сайта. Теоретически кеширование должно помочь сильно сэкономить на времени загрузки скрипта…
А в третьих — нужно ли вообще в один файл собирать? Может http/2.0 всё-таки скоро заработает?
А во-вторых ссылку на CDN пытаться загрузить первой и если не получилось — тогда грузить со своего сайта. Теоретически кеширование должно помочь сильно сэкономить на времени загрузки скрипта…
А в третьих — нужно ли вообще в один файл собирать? Может http/2.0 всё-таки скоро заработает?
Вы так говорите, как будто годовой даунтайм нормальных CDN больше или хотя бы сравним с даунтаймом среднего сайта, который его использует.
Без gulp, к примеру, не собрать всё в действительно единый файл. Когда мне понадобилось получить на выходе один-единственный html, внутрь которого встроены и css, и js, пришлось ставить gulp, поскольку в webpack я так и не нашёл способа этого сделать — он вставляет в html линки на файлы с кодом, а не сам код.
Не упростить сборку, я говорю что сам инструмент очень просто устроен. Это не значит что в нем не нужно разобраться — как раз напротив.
Например uglify плагин вебпака создана для обработки выходящего бандла (всего кода сразу). Что бы применить к одному конкретному файлу (ума не приложу почему только к одному, но пусть) можно использовать uglify-loader:
var file = require("uglify!./path/to/file")вот и все.
Я чувствую себя очень старым, максимум что я могу себе позволить прикрутить в своих проектах, это Bootstrap.
Не, ну ещё, конечно, JS на стороне клиента и вот и всё.
Не, ну ещё, конечно, JS на стороне клиента и вот и всё.
вот, а я вот думаю, я один такой дурак, который знает 2-3 технологии хорошо, и новые просматривает только с позиции «хм, смотри какую хреновину интересную наворотили, интересно, сколько она протянет, пока ее ченть подобное не переплюнет»?
Видимо, у Вас нет необходимости проходить собеседования на вакансии «Front-end developer». Но есть и те, кто выбрал для себя front-end и при этом стремится к развитию.
Скажу честно — с ужасом взираю на зоопарк фронтендеровских примочек, которые сегодня требуют от будущих работников, при том что с 90% задач справится стандартный стек из JQ, bootstrap и html5. А в большинстве случаев и натив жс вполне хватает. А если уж совсем честно, то и бутстрап вовсе не везде нужен.
Для каких-то простых задач и небольших приложений — все верно.
Но как только в требованиях появляется адаптивный интерфейс — 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.
Но как только в требованиях появляется адаптивный интерфейс — 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.
На счет Angular 1 не согласен. Код получается так себе, особенно когда нужно включить 10 зависимостей. Тем более, нет какой-то четкой архитектуры, у всех все разное.
Это проблема исключительно из за несоблюдения style guide. А уж подключение 10 зависимостей — тем более не косяк framework'а.
От говнокода ни одна платформа не спасет.
От говнокода ни одна платформа не спасет.
Вот простой пример. Как-то не проглядывается читабельность.
'use strict';
customer.controller('CustomerModalAddFormCtrl', ['$scope', '$uibModalInstance', '$window', 'CustomerAPI',
function ($scope, $uibModalInstance, $window, CustomerAPI) {
//…
}
]);
И не надо про зависимости, выше обычный контроллер, который толком еще ничего не делает, а их уже 4 штуки и смотрятся ужасно.
'use strict';
customer.controller('CustomerModalAddFormCtrl', ['$scope', '$uibModalInstance', '$window', 'CustomerAPI',
function ($scope, $uibModalInstance, $window, CustomerAPI) {
//…
}
]);
И не надо про зависимости, выше обычный контроллер, который толком еще ничего не делает, а их уже 4 штуки и смотрятся ужасно.
Добавьте чуть-чуть ng-annotate и просто разделите код, получится тоже самое, но гораздо лучше:
'use strict'
customer.controller('CustomerModalAddFormCtrl', customerController)
/*@ngInject*/
function customerController($scope, $uibModalInstance, $window, CustomerAPI) {
// ...
}А если добавить es6, typescript и немного декораторов, то будет совсем здорово.
А ссылки дадите на примеры?
На днях писал статью (правда она скорее про настройку окружения и про то, как с этим жить).
Про компоненты сами по себе вот тут отлично написали.
Мой велосипед уже в продакшене, полет нормальный. Самодельные декораторы стоит заменить на ng-metadata
Как Я и написал, проблема исключительно из за не следования style guide. Кроме того, на 90% уверен, что $scope в контроллере Вам не нужен.
Меня больше пугают всякие системы сборки/менеджеры зависимостей. Я так-то пишу на Java, к 100500 библиотекам в проекте привык. Но так же и привык к одной системе сборки на весь проект. Там чтобы добавить библиотечку нужно указать пару-тройку зависимостей и всё. А тут открываешь какой-нибудь hello world на react'е и там какой-нибудь babel+npm+webpack при этом у каждого свой конфиг, они как-то согласованы должный быть, и фиг пойми что за что отвечает. В итоге тонешь в попытке разобраться сразу с четырьмя новыми технологиями.
Технологи́ческая сингуля́рность — гипотетический момент, по прошествии которого, по мнению сторонников данной концепции, технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию
Имхо — все довольно просто. Web-разработка в силу разных причин приближается к сингулярности быстрее чем другие области деятельности.
И такой подход уже дает как общее понимание ситуации, так и потенциальные возможности решения проблемы.
Какое? rm -rf /?
Не пользоваться фреймворками очевидно же. Максимум jQuery или встроенными модулями/драйверами субд в nodejs. Всё остальное — ересь, за которую «инициативный и прогрессивно мыслящий сотрудник» получает линейкой по рукам и битой по башке.
Точно также как вообще бороться с сингулярностью: не можешь победить — возглавь.
В данном случае — нет смысла бороться с тенденцией, для человеческого разума эта область становится слишком сложной (собственно об этом и статья), но можно повернуть ситуацию себе на пользу.
Необходимо создавать интеллектуальные средства разработки, которые смогут автоматизировать использование существующих средств, комбинировать их, дополнять, обновлять… Человеку не обязательно понимать как в деталях работает приложение, если оно работает и его можно легко изменить.
Сейчас «true-программисты» меня заминусят, да и ладно) Интересно, как эти люди вообще представляют себе наступление технологической сингулярности?..
И я не говорю, что этот подход «правильный». Это просто то что нас ждет, хотим мы этого или нет (IMHO). И со временем то же будет в других сферах. Думаете конструируя ИИ через N-лет программист будет задумываться о том как работает каждый искусственный нейрон?
В данном случае — нет смысла бороться с тенденцией, для человеческого разума эта область становится слишком сложной (собственно об этом и статья), но можно повернуть ситуацию себе на пользу.
Необходимо создавать интеллектуальные средства разработки, которые смогут автоматизировать использование существующих средств, комбинировать их, дополнять, обновлять… Человеку не обязательно понимать как в деталях работает приложение, если оно работает и его можно легко изменить.
Сейчас «true-программисты» меня заминусят, да и ладно) Интересно, как эти люди вообще представляют себе наступление технологической сингулярности?..
И я не говорю, что этот подход «правильный». Это просто то что нас ждет, хотим мы этого или нет (IMHO). И со временем то же будет в других сферах. Думаете конструируя ИИ через N-лет программист будет задумываться о том как работает каждый искусственный нейрон?
Автор, просто напишу, что я с тобой согласен, и в статье рассмотрена всего лишь маленькая часть проблем. Все началось с того, что изначально статическую страницу решили оживить…
НЛО прилетело и опубликовало эту надпись здесь
Добавлю, что скорость изучения у некоторых индивидуумов, довольно разная, и те кто отстают через некоторое время начинают строить костыли на базе своих нынешних знаний и порождают библиотеки и фреймворки, которые существуют в рамках одного проекта и более нигде не нужны.
Вообще прогресс мог бы идти быстрее, если бы не браузеры и устройства на которых стоят браузеры (в купе с нерадивыми пользователями, которые не могут обновить браузер).
Вообще прогресс мог бы идти быстрее, если бы не браузеры и устройства на которых стоят браузеры (в купе с нерадивыми пользователями, которые не могут обновить браузер).
Я как раз таки занимаюсь разработкой на ангуляре 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#.3g3dz9do8
>>В итоге получаете сборку размером 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#.3g3dz9do8
вот, кстати, ответ https://habrahabr.ru/post/307468/
> Дуглас Крокфорд как-то сказал: «Веб — это наиболее враждебная среда разработки, которую только можно представить».
> И он чертовски прав. Это та враждебность, которая даёт мне доступ в мир. Это та «враждебность», которую я называю своим ежедневным вызовом.
> Эта враждебная среда вдохновляет меня. Сделать так, чтобы моя страница рендерилась везде. Написать код таким образом, чтобы страницу мог видеть каждый.
Понимаете, да? Для «них» это вызов, это вдохновляет.
> Дуглас Крокфорд как-то сказал: «Веб — это наиболее враждебная среда разработки, которую только можно представить».
> И он чертовски прав. Это та враждебность, которая даёт мне доступ в мир. Это та «враждебность», которую я называю своим ежедневным вызовом.
> Эта враждебная среда вдохновляет меня. Сделать так, чтобы моя страница рендерилась везде. Написать код таким образом, чтобы страницу мог видеть каждый.
Понимаете, да? Для «них» это вызов, это вдохновляет.
DOM — я так и не понял почему он так сделан…
bower, man-bower-files, gulp-bower… etc — велосипед с костылями, где автоматизацию нужно автоматизировать ручками.
Любой JS фреймворк вликолепен в написании todo!
bower, man-bower-files, gulp-bower… etc — велосипед с костылями, где автоматизацию нужно автоматизировать ручками.
Любой JS фреймворк вликолепен в написании todo!
Насколько я понимаю — проблема такая: мы используем новые технологии, но для них не работают старые штуки. Чтобы работали старые штуки, мы используем старые технологии, но они не новые.
В итоге — новые штуки мы использовать можем только с новыми технологиями, для старых их никто не будет реализовывать. А старые штуки мы можем использовать со старыми — пока их реализуют для новых, новые уже станут старыми.
Я бы сравнил это с использованием электрического двигателя для машины. Новая технология — но нет заправок. Пока построят заправки, уже все начнут ездить на водороде.
Так может ездить пока на бензине?
В итоге — новые штуки мы использовать можем только с новыми технологиями, для старых их никто не будет реализовывать. А старые штуки мы можем использовать со старыми — пока их реализуют для новых, новые уже станут старыми.
Я бы сравнил это с использованием электрического двигателя для машины. Новая технология — но нет заправок. Пока построят заправки, уже все начнут ездить на водороде.
Так может ездить пока на бензине?
Точно такие же мысли были недавно.
Решил начать использовать на проектах ES6, а для конвертации в поддерживаемый код решил использовать связку Gulp+Babel. И всё было хорошо до поры до времени, пока не оказалось, что IE11 отваливается с кодом, созданным Babel. Ок, ладно если бы IE9, я бы исходный код переделал, так уж и быть, но IE11 — это как минимум говорит о том, что меня где обманули или недоговорили правду, когда расхваливали какой Babel хороший, давайте его все использовать. Стал гуглить решение проблемы — единственное, что нашёл, это подключение js-файла с полифилами аж на 100 килобайт. 100 килобайт, Карл! Чтобы заставить сгенерированный Babel код наконец-таки заработать. Мне в чатах подсказали возможный путь решения проблемы, но это абсолютно нездоровая ситуация, когда на каждом углу хвалят инструмент, а этот инструмент требует нехилой такой доработки для реального использования. И да, файлик на 100 килобайт с полифилами помог, но вылезла другая ошибка, на которую в гугле был только открытый тикет в Babel от февраля сего года.
И это далеко не первый случай, когда достаточно наслушался о чём-то, а по факту в продакшене использовать это крайне проблематично. С одной стороны, если не изучать всё это новомодное, то через N лет будешь никем. Но изучение и использование новомодного связано с такими матами и разочарованиями, что иногда вообще жалеешь, что ввязался во front-end когда-то.
Решил начать использовать на проектах ES6, а для конвертации в поддерживаемый код решил использовать связку Gulp+Babel. И всё было хорошо до поры до времени, пока не оказалось, что IE11 отваливается с кодом, созданным Babel. Ок, ладно если бы IE9, я бы исходный код переделал, так уж и быть, но IE11 — это как минимум говорит о том, что меня где обманули или недоговорили правду, когда расхваливали какой Babel хороший, давайте его все использовать. Стал гуглить решение проблемы — единственное, что нашёл, это подключение js-файла с полифилами аж на 100 килобайт. 100 килобайт, Карл! Чтобы заставить сгенерированный Babel код наконец-таки заработать. Мне в чатах подсказали возможный путь решения проблемы, но это абсолютно нездоровая ситуация, когда на каждом углу хвалят инструмент, а этот инструмент требует нехилой такой доработки для реального использования. И да, файлик на 100 килобайт с полифилами помог, но вылезла другая ошибка, на которую в гугле был только открытый тикет в Babel от февраля сего года.
И это далеко не первый случай, когда достаточно наслушался о чём-то, а по факту в продакшене использовать это крайне проблематично. С одной стороны, если не изучать всё это новомодное, то через N лет будешь никем. Но изучение и использование новомодного связано с такими матами и разочарованиями, что иногда вообще жалеешь, что ввязался во front-end когда-то.
Как по мне, так если разрабатываешь бизнес-приложение, то можно тупо забить на старые браузеры и диктовать использование своего. Для публичных сайтов – да, такое не подойдёт, а вот для приватных проектов, где чаще всего применяются сложные интерфейсы с извращенной логикой, такой проблемы нет.
Спасибо вам за комментарий. Всё думал, переходить ли на ES6(babel) или пока остаться на TypeScript (который уже что-то из ES6 и сам поддерживает, но далеко не всё). Пожалуй останусь на TypeScript — там по крайней мере на IE точно ориентировались, когда писали. Ну и в целом в продакшене у меня пока с ним не возникало проблем
Потому что Angular-way. Я не смог заставить запускатся Angular 2 так как хотел (не через webpack) и забил болт на него… Собственно из-за zone.js, необходимость в котором мне не понятна
((Require, Angular (1.5), LESS, Bootstrap, jQuery) + самописный микс PrototypeJS, чтобы определять и работать с «классами» в стиле ExtJS) * Grunt.
Ну и всё, никаких проблем.
Просто надо уметь вовремя остановиться и набирать в проект такие технологии, которые будут достаточными (и не вовлекать новые).
Правда, я работаю над одним приложением несколько лет, а не пилю каждый день новый сайт, так что не знаю, как живут люди в том мире (думал, там еще более упорядоченно всё).
Ну и всё, никаких проблем.
Просто надо уметь вовремя остановиться и набирать в проект такие технологии, которые будут достаточными (и не вовлекать новые).
Правда, я работаю над одним приложением несколько лет, а не пилю каждый день новый сайт, так что не знаю, как живут люди в том мире (думал, там еще более упорядоченно всё).
На данный момент нахожу привлекательной комбинацию jQuery + Doctrine2 + ZF2
«Вредные советы хипстеру»
Я выучил 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. Они уже практически одинаковы во всех браузерах.
В результате я стал менее производительным. Однако появилось полное понимание структуры и работы проекта. А вместе с тем улетучился стресс. А еще исчезла необходимость в nodejs
Я выучил 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. Они уже практически одинаковы во всех браузерах.
В результате я стал менее производительным. Однако появилось полное понимание структуры и работы проекта. А вместе с тем улетучился стресс. А еще исчезла необходимость в nodejs
1. ES6 имеет огромную кучу классных фич, которые я хочу использовать в своем коде. Они делают код понятнее, выразительнее, более поддерживаемым и т.д.
2. Отчасти согласен, что тесты нужно писать. И лучше писать тесты на бизнес логику, чем на проверку типов.
3. Уже проходили, загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла (именно так технологии вроде browserify появились на смену тому же require.js)
4. Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал, или другой разработчик напишет перекроет что-то. Опять таки, уже проходили. И именно потому что это не scalable, и само по себе является антипаттерном, в мир JS пришли AMD, CommonsJS, Import/Export, как во всех нормальных языках.
А что делать со сложными зависимостями (мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную) — вообще не понятно
5. Опять таки — почему бы мне не использовать возможности LESS, только потому что по Вашему мнению CSS не так уж плох? Зачем мне писать свои make файлы, если я могу использовать готовый продукт для этого?
6. Насколько маленькие вещи? Вы точно знаете когда маленькие вещи перерастут в большие? Зачем мне потом переписывать то, что я могу написать изначально правильно? Ну и ставить реакт с ангуляром вместе в одном предложении — говорит только о том, что Вы не совсем в теме
Мне кажется, подобные советы вредны даже для написания простеньких сайтов, не говоря уже о более ли менее сложных и больших продуктов
2. Отчасти согласен, что тесты нужно писать. И лучше писать тесты на бизнес логику, чем на проверку типов.
3. Уже проходили, загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла (именно так технологии вроде browserify появились на смену тому же require.js)
4. Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал, или другой разработчик напишет перекроет что-то. Опять таки, уже проходили. И именно потому что это не scalable, и само по себе является антипаттерном, в мир JS пришли AMD, CommonsJS, Import/Export, как во всех нормальных языках.
А что делать со сложными зависимостями (мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную) — вообще не понятно
5. Опять таки — почему бы мне не использовать возможности LESS, только потому что по Вашему мнению CSS не так уж плох? Зачем мне писать свои make файлы, если я могу использовать готовый продукт для этого?
6. Насколько маленькие вещи? Вы точно знаете когда маленькие вещи перерастут в большие? Зачем мне потом переписывать то, что я могу написать изначально правильно? Ну и ставить реакт с ангуляром вместе в одном предложении — говорит только о том, что Вы не совсем в теме
Мне кажется, подобные советы вредны даже для написания простеньких сайтов, не говоря уже о более ли менее сложных и больших продуктов
> ES6 имеет огромную кучу классных фич, которые я хочу использовать в своем коде
Да
>Они делают код понятнее, выразительнее, более поддерживаемым и т.д
Будут делать. На данный момент мы имеем неподдержиеваемый выхлоп из babel-a плюс (по словам ОПа) 100КБ полифилов
> загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла
Намного это насколько? Сами проверяли или прочитали? В моем проектике около 100 маленьких js файлов. Разница первого запуска в 1.3 раза. Разница последующих запусков отсутствует. Считаю это нормально
> Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал
Одна библиотека — одна глобальная переменная. Обычное явлене в js
>в мир JS пришли AMD, CommonsJS, Import/Export
Import/Export еще не пришли, в том и суть. Остальные способы — страшные костыли, которые канут в лету с приходом Import/Export
> мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную
Вы что-то делаете не так
> Насколько маленькие вещи?
Вам решать.
> Вы точно знаете когда маленькие вещи перерастут в большие?
Обычно знаю. При нормальном разбиении приложения на слои, заменить рендер с какого-нибудь mustache на react не вызывало сложностей.
Да
>Они делают код понятнее, выразительнее, более поддерживаемым и т.д
Будут делать. На данный момент мы имеем неподдержиеваемый выхлоп из babel-a плюс (по словам ОПа) 100КБ полифилов
> загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла
Намного это насколько? Сами проверяли или прочитали? В моем проектике около 100 маленьких js файлов. Разница первого запуска в 1.3 раза. Разница последующих запусков отсутствует. Считаю это нормально
> Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал
Одна библиотека — одна глобальная переменная. Обычное явлене в js
>в мир JS пришли AMD, CommonsJS, Import/Export
Import/Export еще не пришли, в том и суть. Остальные способы — страшные костыли, которые канут в лету с приходом Import/Export
> мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную
Вы что-то делаете не так
> Насколько маленькие вещи?
Вам решать.
> Вы точно знаете когда маленькие вещи перерастут в большие?
Обычно знаю. При нормальном разбиении приложения на слои, заменить рендер с какого-нибудь mustache на react не вызывало сложностей.
asp.net core mvc на первый взгляд выглядит серебряной пулей. Кто-нибудь, кто попробовал, можете отписаться как оно в деле?
Пока опыта мало, но не думаю что это так.
Во-первых он не решает проблем на клиентской стороне (тот же JS и CSS)
Во-вторых есть ещё много детских болезней:
— отсутствие большого количества обучающего материала и документации
— пока нет инструментов разработки из серии создал проект и запустил. Нужно устанавливать .Net Core, разбираться с VS Code, конфигурировать, подключать библиотеки и т.д.
— неизвестно ещё насколько технология будет принята сообществом. Не умрёт ли она через 2-3 года…
Во-первых он не решает проблем на клиентской стороне (тот же JS и CSS)
Во-вторых есть ещё много детских болезней:
— отсутствие большого количества обучающего материала и документации
— пока нет инструментов разработки из серии создал проект и запустил. Нужно устанавливать .Net Core, разбираться с VS Code, конфигурировать, подключать библиотеки и т.д.
— неизвестно ещё насколько технология будет принята сообществом. Не умрёт ли она через 2-3 года…
Вставлю свои 5 копеек. Согласен с автором на все 100%, и вот почему. Изначально JS был языком, который добавил немного динамики в HTML. Например, никто тогда не заморачивался над тем, зачем нужны полноценные классы, и внедрили в него систему на прототипах. Сейчас все поняли, что классы нужны и они появились в ES6, но, опять обрезанные — нет ни private/protected свойств, ни других полноценных возможностей.
Вторая большая проблема — зоопарк браузеров. Если кто помнит, ActionScript во флеше, так же был изначально слабым языком, который лишь добавил немного скриптов, но с выходом AS 3.0 он стал очень мощным, а так как во флеше лишь один вендор — то все быстро перешли на 3.9. В вебе же даже если кто-то предложит супер альтернативу (например, Dart), разработчикам всё равно нужно поддерживать другие браузеры, а это значит надо использовать конвертеры, со всеми их ограничениями.
Третья проблема — слабость JS. Вот ей богу, были бы поддерживаемые всеми браузерами стандартные механизмы загрузчиков модулей и зависимостей, шаблонизатор, событийные системы для объектов, не было бы столько фреймворков, каждый из которых по своему реализует тот или иной «пробел» в JS. И эти инструменты всё время меняются — если недавно миром царил jQuery, вчера Backbone, а сегодня React.
В итоге получаем слабый JS, тучу фреймворков, толпы их фанатиков, и ад, от которого хочется бежать куда подальше. И мне есть с чем сравнивать, например по сравнению с бэкэнд-разработкой на PHP, у нас тут тишина и спокойствие. Да, есть конкурирующие фреймворки, но топовых можно пересчитать по пальцам.
Вторая большая проблема — зоопарк браузеров. Если кто помнит, ActionScript во флеше, так же был изначально слабым языком, который лишь добавил немного скриптов, но с выходом AS 3.0 он стал очень мощным, а так как во флеше лишь один вендор — то все быстро перешли на 3.9. В вебе же даже если кто-то предложит супер альтернативу (например, Dart), разработчикам всё равно нужно поддерживать другие браузеры, а это значит надо использовать конвертеры, со всеми их ограничениями.
Третья проблема — слабость JS. Вот ей богу, были бы поддерживаемые всеми браузерами стандартные механизмы загрузчиков модулей и зависимостей, шаблонизатор, событийные системы для объектов, не было бы столько фреймворков, каждый из которых по своему реализует тот или иной «пробел» в JS. И эти инструменты всё время меняются — если недавно миром царил jQuery, вчера Backbone, а сегодня React.
В итоге получаем слабый JS, тучу фреймворков, толпы их фанатиков, и ад, от которого хочется бежать куда подальше. И мне есть с чем сравнивать, например по сравнению с бэкэнд-разработкой на PHP, у нас тут тишина и спокойствие. Да, есть конкурирующие фреймворки, но топовых можно пересчитать по пальцам.
Согласен. Возьмите к примеру вот этот список плагинов для очередного нового модного и продвинутого фреймворка KoaJS (https://github.com/koajs/koa/wiki)
Да там одних только роутеров 20 штук. Двадцать роутеров!
К-во шаблонизаторов для JS уже тоже достигает критической отметки. Посмотрите тут https://github.com/tj/consolidate.js
Да и есть вопросы про сам фреймворк KoaJS. Ну что в нем такого революционного. Использовали генераторы в async await обертке от бабеля как киллер фичу. Ну неужели нельзя было это сделать в рамках ExpressJS. Зачем создавать еще одну экосистему?
Да там одних только роутеров 20 штук. Двадцать роутеров!
К-во шаблонизаторов для JS уже тоже достигает критической отметки. Посмотрите тут https://github.com/tj/consolidate.js
Да и есть вопросы про сам фреймворк KoaJS. Ну что в нем такого революционного. Использовали генераторы в async await обертке от бабеля как киллер фичу. Ну неужели нельзя было это сделать в рамках ExpressJS. Зачем создавать еще одну экосистему?
Эта проблема лучше всего решается монополизацией движка. Если останется один-единственный браузерный движок, то его владелец сможет легко, быстро и ни с кем не согласовывая вводить новые фичи. В предельном случае он сможет даже забить на улиточных бюрократов из W3C, прописав собственные стандарты для удобства разработчиков.
Как-то недосказано, проблема реально есть, html это язык разметки гипертекста, а теперь его используют как язык разметки интерфейсов и конечно это не может работать хорошо, поэтому и развелось всяких js фреймворков которые пытаются как-то пофиксить проблему, но это костыльный пусть.
Ну и идея с разделением содержимого и оформления не очень получилась, вроде CSS есть, но при этом html переполнен div'ми добавленными туда только для обеспечения нужного оформления — читаемость ужасная.
Ну и идея с разделением содержимого и оформления не очень получилась, вроде CSS есть, но при этом html переполнен div'ми добавленными туда только для обеспечения нужного оформления — читаемость ужасная.
Это вы ещё не запустили то что написали. Ибо запустив вы узрите насколько браузеры отличаются.
Хотелось бы услышать тогда предложение по решению проблемы. Ожидал в конце статьи будет ссылка на новый сборщик и фреймворк от автора, пока всё остальное тлен и костыли, вот вашему вниманию stable :) А предыдущий текст — как предвкушение чего-то нового и молодёжного :)
Взять любой современный тулкит (например, WPF) и сделать из него «браузер» (кроссплатформенную загрузку и отображение кода). Будет wpf:// вместо http://
Если бы автор предложил свой фреймворк, то это было бы странно, т. к. автор сам и пишет, что слишком много фреймворков.
Решением было бы ES7 реализованный в браузерах с загрузчиком модулей, настоящими классами, и всеми теми функциями, которые сейчас реализованы во фреймворках, но как понимаете, даже если это произойдёт, это дело не ближайшего будущего.
В общем получился пост, открывающий тёмную сторону frontend-разработки и его сложности.
Решением было бы ES7 реализованный в браузерах с загрузчиком модулей, настоящими классами, и всеми теми функциями, которые сейчас реализованы во фреймворках, но как понимаете, даже если это произойдёт, это дело не ближайшего будущего.
В общем получился пост, открывающий тёмную сторону frontend-разработки и его сложности.
НЛО прилетело и опубликовало эту надпись здесь
А зачем использовать в одном проекте десятки библиотек/фреймворков?
Многим кажется, что лучше использовать готовое решение, чем изобретать велосипед и они с радостью начинают подключать фреймворки и модули к проекту и через пару месяцев/лет разработки проект превращается в монстра, который сложно разрабатывать и поддерживать.
Для себя выбрал следующий стек для веб части проектов:
— 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 года нам не понадобятся существующие фреймворки (но наверняка появятся новые). К тому же за счёт оптимизации выполнения кода в браузере мы можем получить ускорение работы сайтов.
Жаль что вряд-ли это случится…
Многим кажется, что лучше использовать готовое решение, чем изобретать велосипед и они с радостью начинают подключать фреймворки и модули к проекту и через пару месяцев/лет разработки проект превращается в монстра, который сложно разрабатывать и поддерживать.
Для себя выбрал следующий стек для веб части проектов:
— 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 года нам не понадобятся существующие фреймворки (но наверняка появятся новые). К тому же за счёт оптимизации выполнения кода в браузере мы можем получить ускорение работы сайтов.
Жаль что вряд-ли это случится…
НЛО прилетело и опубликовало эту надпись здесь
А это не последствия подхода? Когда берется результат для сайта с парой десятков страниц, на который нанимают «программиста на час», который за вечер пытается из того что есть, слепить то что надо?
Грубо говоря как сравнивать инди разработку на готовом движке и ААА проект, когда могут позволить разработать все полностью.
Грубо говоря как сравнивать инди разработку на готовом движке и ААА проект, когда могут позволить разработать все полностью.
НЛО прилетело и опубликовало эту надпись здесь
Это вы «10к» прочитали как «десяток»? «10кбайт» = десяток байт?
Ну тут понятие очень растяжимое. Что считать страницей? Взять для примера википедию, что там считать страницей? Шаблон в котором размещен текст статьи? Сам текст, не включая шаблон? А как быть с комментариями и историей правок? Потому что я очень сомневаюсь, что кто-то станет делать сайт из 10000 «простых» (статических) страничек, не генерируемых из шаблона и неких данных.
P.S. 10к есть 9 999,99. Как любят писать продавцы ;)
P.S. 10к есть 9 999,99. Как любят писать продавцы ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Современная WEB-разработка. Как мы пришли к такому?