Comments 121
Честно, я сам устал от этого урагана фреймворков. От этих костылей, стоящих на костылях.
Сейчас у меня стек технологий такой:
1) html — Jade
2) css — Stylus
3) js — React.js|Ember|Angular, jquery и миллион мелких плагинов
4) Node.js, express, socket.io
5) Gulp, Webpack(с его не очевидным api и общей сложностью)
И это только то, что я использую каждый день
Дичайший кошмар с фрагментацией, когда очередной форк выходит из употребления быстрее, чем его успеваешь освоить.
Дикое костылестроение, когда явные дыры наспех затыкаются костылями в надежде, что раз OpenSource, то потом кто-нибудь другой их отрефакторит или переделает как надо.
Полнейшее нежелание составлять и поддерживать актуальную документацию, т.ч. сведения всегда приходится собирать по крупицам, причём эти крупицы могут использоваться лишь приблизительно, ибо устарели лет на пять.
Ээээ, а как же require.ensure? или вы думаете те кто пилят такие утилиты дураки?
Статья состоит из нытья о том, что автору кто-то неведомый что-то должен и не отдаёт.
Дали сборщик, дали модули, дали фреймворки — выбирай и радуйся, не пиши велосипеды. Нет, хочу плакаться что библиотека А не полностью совместима с фреймворком Б.
Если вам не нравится то, что есть — дорабатывайте или пишите велосипед. Это же Open Source.
Как дети, честное слово.
С выходом новых стандартов (es7, web components) проблемы решаться сами собой
Новые стандарты не решают накопившиеся проблемы
Новые стандарты сделают неактуальными старые проблемы и породят новые. На смену одним костылям придут другие. Свежесобранные велосипеды обгонят уже существующие, а дальше притормозят и начнут ехать с той же скоростью. Существующие фреймворки обновят первую циферку в версии, потом перестанут быть такими популярными, а потом окончательно падут под напором новых инструментов. Разработчики опять начнут рвать волосы, которые только-только отросли после предыдущей смены стандартов, с дикими криками матеря всех и всё.
Новые проблемы вернут нам старые разговоры о том, что надо существующий зоопарк решений как-то привести в божеский вид, для чего, пожалуй, надо ввести какие-то новые стандарты, которые нам всенепременнейше помогут.
И всё повторится вновь, потому что шоу должно продолжаться.
Проблемы возникают когда, кто-то с благой целью пытаются упростить жизнь другим, и начинает выдумывать новый велосипед (стандарт), поверх не совсем стандартизиованной связки HTTP, HTML, CSS, JS. Дичайше долго реализовывают новые вещи в этих трех… Но. В любой момент времени этой связкой можно пльзоваться без каких либо проблем, и без всяких надстроек.
Вот Только програмисты великий народ с великой ленью (хапанул косяк из доков и давай кодить, а их скурить полностью надо и не один раз). Им проще 100500 раз по… ться с чужими костылями, методологиями и фреймворками… Чем раз в 10 лет выучить простой стандарт, и официальные рекомендации к нему… (Народ до сих пор пользуеться видоизменненной табличной версткой — bootstrap ets.)
Еще плохо, что в новый стандарт ЕS6 напихали всякого, а толку. Например, классы — в интепритируемом языке как гвоздь в подошве, интерпритатор делает двойную работу!!! Спрашивается ЗАЧЕМ??? Что-бы было удобно програмисту недоучке. Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь). Как на меня, Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Если посмотреть, ничего существенно нового не добавилось, все новое это перефразированное старое, в другой подаче — но суть то не поменялась (списки, стрелки, литералы, ..., нафиг не нужные константы). Реально новое, это (игры с параметрами, символы, итераторы и генераторы) но пользы от них не много. И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики (как говорят разработчики МАГИЯ)…
И получаем 100500 разных реализаций, т.к. язык очень гибкий и позволяет их все, и каждый из вариантов с точки зрения его разработчика «истинно правильный».
пользуется потому что flexbox еще не поддерживается на подавляющем большинстве устройств
>> Спрашивается ЗАЧЕМ???
для удобства кодинга. конкретнее — для более лучшего удержания абстракций в голове.
>>Надстройки даже стандартыне не нужны. Работа с ними уж точно не быстрее старого простого стандарта, который разрабатывался с оглядкой на интерплатформность и интерпритабельность.
Кодите просто на функциях, (вам же так сокрость работы нужна). Не используйте абстракции (объекты, структуры, потоки). посмотрим, какими будут ваши большие проекты, и как в них легко будет разобраться другим
>>И не каждый разберется в последних трех, слишком они непривычны и далеки от простой логики
>> Так пусть доучится за 2 недели (два дня потерять, а потом за час долететь).
противоречие, вам так не кажется?
Может быть есть статья какая или что-то подобное про производительность. У любого метода есть свои плюсы и минусы. Спасибо.
И да, нужно будет переписать кучу сайтов на Erlang, всем изучить этот язык, создать индустрию под это дело итд… короче жесть
Не нужно переписывать сайты. Они умирают быстрее, чем успевают состариться естественным образом. Просто нужно новые сайты делать на правильных инструментах, которые правильным образом поддерживают «хуяк-хуяк и в продакшен»-методологию.
Не нужно всем изучать Эрланг. Пусть говносайты делают на говнофреймворках. А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Для бекенда есть достаточно хороших инструментов, которые не позволяют легко отстрелить себе ногу. Но для фронтенда нужно развивать и использовать вещи типа Elm. Тогда будет значительно меньше боли.
Дело не в JavaScript, а изначально в технологии HTML, живой картинки, DOM итд. Никто не знал, к чему это приведет, и что будет такой зоопарк.
> Наша задача, чтобы в приложениях не осталось лажи
Ну т.е. «а давайте все перепишем с нуля?» И опять-же, дело не в JavaScript.
> А к остальным нескольким действительно нужным и так прилагают достаточно усилий и внимания, чтобы с ними всё было хорошо.
Проблема другая — Erlang'a нет в браузерах. А значит пусть вы напишете идеальный код на Erlang, но если пользователь не сможет купить товар/услугу на вашем супер-быстром сайте, то цена вашему сайту — 0.
> плохой помошник PHP на стороне севрвера
Чем же он плох?
> Проблема другая — Erlang'a нет в браузерах
Это не проблема — Erlang компилируется в JavaScript. Elm компилируется в JavaScript. (Даже C++ копилируется в JavaScript или Web Asm :).
Пусть JavaScript останется тем же, чем являются ассемблер или машинные коды (или байткод виртуальной машины). С ним будет работать браузер, но на нем не надо программировать.
>> плохой помошник PHP на стороне севрвера
> Чем же он плох?
Тем же, чем он хорош — низким порогом входа.
А отлаживается он при этом как?
Это как это вы Полимер в устарешие технологии записали? Что еще за бред?
Это как со смартфонами: при выходе нового смартфона множество рассказов, что он стал меньше потреблять энергии и итд. Вы ждете, что новый смартфон будет больше жить на одном заряде. Оправдались ваши ожидания? Нет — он просто стал тоньше.
Другое дело, что бывает сложно объяснить, зачем же вообще нужно так сильно снижать толщину — вроде современные устройства уже и так тонкие, даже чрезмерно.
В результате, поиск качественного телефона для повседневных задач превращается в квест, который осилит не каждый обыватель. Да еще и приложениями норовят закидать так, что телефон тормозит сильнее старичка сделанного 10 лет назад.
Такие дела.
То что чем мы пользуемся сейчас (react+redux+webpack+es6) на голову или даже на две выше чем то с чем приходилось иметь дело ранее. Скорость, удобство разработки, удобство дебага — все в разы лучше.
Вебпак так вообще — несмотря на то что выглядит для нового человека как марсианский конфиг для космолета — очень, _очень_ простой и понятный (именно из-за этого он и выглядит костыльным — там нет привычной магии фрэймворков, нужно очень многое писать самому, понимая что ты делаешь)
А в чем проблема?
gulp.src('path/to/file').pipe(ugilfy()).pipe(gulp.dest('path/to/build'));
Webpack — это прежде всего собириает все ваши файлы в один единый файл. И главная задача этой утилиты — не засорять global scope.
В статье написали, что после сборки получился файл весом 2Мб. Откройте окончательный файл. Там код вашего React, Redux и все остальных библиотек и фреймворков. Потратьте время на изучения webpack — webpack умеет не «включат» файлы в сборку. Тогда бы ваш HTML загружал бы библотеки с CDN, а ваша программа весила бы около 200кб.
Хватить называть чужой труд костылями. Без обид, если не умеете пользоваться — это ваши проблемы.
>> webpack умеет не «включат» файлы в сборку
Да я знаю про IgnorePlugin. Правда так и не получилось добиться того чтобы в рантайме не выскакивало исключение «module not found ...», видимо надо строить граф и смотреть что чего там реквайрит.
После минификации всего и вся получилось 760Кб поправил статью.
Есть такие программисты которые почему то искренне верят в то, что CDN не может упасть а Facebook и Vk работают вечно.
Все что может сломаться — сломается и из-за того что библиотеки у вас на CDN как минимум вы получите просадку в скорости
загрузки, как максимум нерабочий сайт, потому что какая то либа отвалилась.
А во-вторых ссылку на CDN пытаться загрузить первой и если не получилось — тогда грузить со своего сайта. Теоретически кеширование должно помочь сильно сэкономить на времени загрузки скрипта…
А в третьих — нужно ли вообще в один файл собирать? Может http/2.0 всё-таки скоро заработает?
Не упростить сборку, я говорю что сам инструмент очень просто устроен. Это не значит что в нем не нужно разобраться — как раз напротив.
Например uglify плагин вебпака создана для обработки выходящего бандла (всего кода сразу). Что бы применить к одному конкретному файлу (ума не приложу почему только к одному, но пусть) можно использовать uglify-loader:
var file = require("uglify!./path/to/file")
вот и все.
Не, ну ещё, конечно, JS на стороне клиента и вот и всё.
Но как только в требованиях появляется адаптивный интерфейс — 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.
От говнокода ни одна платформа не спасет.
'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
Технологи́ческая сингуля́рность — гипотетический момент, по прошествии которого, по мнению сторонников данной концепции, технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию
Имхо — все довольно просто. Web-разработка в силу разных причин приближается к сингулярности быстрее чем другие области деятельности.
И такой подход уже дает как общее понимание ситуации, так и потенциальные возможности решения проблемы.
В данном случае — нет смысла бороться с тенденцией, для человеческого разума эта область становится слишком сложной (собственно об этом и статья), но можно повернуть ситуацию себе на пользу.
Необходимо создавать интеллектуальные средства разработки, которые смогут автоматизировать использование существующих средств, комбинировать их, дополнять, обновлять… Человеку не обязательно понимать как в деталях работает приложение, если оно работает и его можно легко изменить.
Сейчас «true-программисты» меня заминусят, да и ладно) Интересно, как эти люди вообще представляют себе наступление технологической сингулярности?..
И я не говорю, что этот подход «правильный». Это просто то что нас ждет, хотим мы этого или нет (IMHO). И со временем то же будет в других сферах. Думаете конструируя ИИ через N-лет программист будет задумываться о том как работает каждый искусственный нейрон?
Вообще прогресс мог бы идти быстрее, если бы не браузеры и устройства на которых стоят браузеры (в купе с нерадивыми пользователями, которые не могут обновить браузер).
>>В итоге получаете сборку размером 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
> Дуглас Крокфорд как-то сказал: «Веб — это наиболее враждебная среда разработки, которую только можно представить».
> И он чертовски прав. Это та враждебность, которая даёт мне доступ в мир. Это та «враждебность», которую я называю своим ежедневным вызовом.
> Эта враждебная среда вдохновляет меня. Сделать так, чтобы моя страница рендерилась везде. Написать код таким образом, чтобы страницу мог видеть каждый.
Понимаете, да? Для «них» это вызов, это вдохновляет.
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 когда-то.
Ну и всё, никаких проблем.
Просто надо уметь вовремя остановиться и набирать в проект такие технологии, которые будут достаточными (и не вовлекать новые).
Правда, я работаю над одним приложением несколько лет, а не пилю каждый день новый сайт, так что не знаю, как живут люди в том мире (думал, там еще более упорядоченно всё).
Я выучил 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
2. Отчасти согласен, что тесты нужно писать. И лучше писать тесты на бизнес логику, чем на проверку типов.
3. Уже проходили, загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла (именно так технологии вроде browserify появились на смену тому же require.js)
4. Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал, или другой разработчик напишет перекроет что-то. Опять таки, уже проходили. И именно потому что это не scalable, и само по себе является антипаттерном, в мир JS пришли AMD, CommonsJS, Import/Export, как во всех нормальных языках.
А что делать со сложными зависимостями (мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную) — вообще не понятно
5. Опять таки — почему бы мне не использовать возможности LESS, только потому что по Вашему мнению CSS не так уж плох? Зачем мне писать свои make файлы, если я могу использовать готовый продукт для этого?
6. Насколько маленькие вещи? Вы точно знаете когда маленькие вещи перерастут в большие? Зачем мне потом переписывать то, что я могу написать изначально правильно? Ну и ставить реакт с ангуляром вместе в одном предложении — говорит только о том, что Вы не совсем в теме
Мне кажется, подобные советы вредны даже для написания простеньких сайтов, не говоря уже о более ли менее сложных и больших продуктов
Да
>Они делают код понятнее, выразительнее, более поддерживаемым и т.д
Будут делать. На данный момент мы имеем неподдержиеваемый выхлоп из babel-a плюс (по словам ОПа) 100КБ полифилов
> загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла
Намного это насколько? Сами проверяли или прочитали? В моем проектике около 100 маленьких js файлов. Разница первого запуска в 1.3 раза. Разница последующих запусков отсутствует. Считаю это нормально
> Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал
Одна библиотека — одна глобальная переменная. Обычное явлене в js
>в мир JS пришли AMD, CommonsJS, Import/Export
Import/Export еще не пришли, в том и суть. Остальные способы — страшные костыли, которые канут в лету с приходом Import/Export
> мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную
Вы что-то делаете не так
> Насколько маленькие вещи?
Вам решать.
> Вы точно знаете когда маленькие вещи перерастут в большие?
Обычно знаю. При нормальном разбиении приложения на слои, заменить рендер с какого-нибудь mustache на react не вызывало сложностей.
Во-первых он не решает проблем на клиентской стороне (тот же JS и CSS)
Во-вторых есть ещё много детских болезней:
— отсутствие большого количества обучающего материала и документации
— пока нет инструментов разработки из серии создал проект и запустил. Нужно устанавливать .Net Core, разбираться с VS Code, конфигурировать, подключать библиотеки и т.д.
— неизвестно ещё насколько технология будет принята сообществом. Не умрёт ли она через 2-3 года…
Вторая большая проблема — зоопарк браузеров. Если кто помнит, ActionScript во флеше, так же был изначально слабым языком, который лишь добавил немного скриптов, но с выходом AS 3.0 он стал очень мощным, а так как во флеше лишь один вендор — то все быстро перешли на 3.9. В вебе же даже если кто-то предложит супер альтернативу (например, Dart), разработчикам всё равно нужно поддерживать другие браузеры, а это значит надо использовать конвертеры, со всеми их ограничениями.
Третья проблема — слабость JS. Вот ей богу, были бы поддерживаемые всеми браузерами стандартные механизмы загрузчиков модулей и зависимостей, шаблонизатор, событийные системы для объектов, не было бы столько фреймворков, каждый из которых по своему реализует тот или иной «пробел» в JS. И эти инструменты всё время меняются — если недавно миром царил jQuery, вчера Backbone, а сегодня React.
В итоге получаем слабый JS, тучу фреймворков, толпы их фанатиков, и ад, от которого хочется бежать куда подальше. И мне есть с чем сравнивать, например по сравнению с бэкэнд-разработкой на PHP, у нас тут тишина и спокойствие. Да, есть конкурирующие фреймворки, но топовых можно пересчитать по пальцам.
Да там одних только роутеров 20 штук. Двадцать роутеров!
К-во шаблонизаторов для JS уже тоже достигает критической отметки. Посмотрите тут https://github.com/tj/consolidate.js
Да и есть вопросы про сам фреймворк KoaJS. Ну что в нем такого революционного. Использовали генераторы в async await обертке от бабеля как киллер фичу. Ну неужели нельзя было это сделать в рамках ExpressJS. Зачем создавать еще одну экосистему?
Ну и идея с разделением содержимого и оформления не очень получилась, вроде CSS есть, но при этом html переполнен div'ми добавленными туда только для обеспечения нужного оформления — читаемость ужасная.
Решением было бы 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 года нам не понадобятся существующие фреймворки (но наверняка появятся новые). К тому же за счёт оптимизации выполнения кода в браузере мы можем получить ускорение работы сайтов.
Жаль что вряд-ли это случится…
Грубо говоря как сравнивать инди разработку на готовом движке и ААА проект, когда могут позволить разработать все полностью.
P.S. 10к есть 9 999,99. Как любят писать продавцы ;)
Современная WEB-разработка. Как мы пришли к такому?