Comments 78
1. Убрать помойку jsx тегов из js, а js из css. У каждого языка как инструмента есть своя цель и область применения. Скорее всего, все подобные извращения перейдут в нативный js, например json-dom.
2. Избавиться от npm с его горой мусора.
3. Выкинуть все эти трекеры, метрики и другие уродства современного веба. Говорите, пересекли черту в 2 мб? Ну так вот 1 мб — это реклама, шпионы, майнеры и трекеры. Ещё 0,99 мб — это бесполезный библиотечный полифил и никогда неиспользуемые методы. Ну и остаётся чистый код на 1000-10 000 строчек, который можно сжать до 100 кб максимум.
Избавиться от npm с его горой мусора.И чем его заменить? По старинке, ручным управлением зависимостями через ctlr-c — ctrl-v? Или таким-же npm, но с вахтёрами?
Так а что в нём ужасного-то?
Окей, давайте разберём этот пакет:
1. files отсутствует, значит весь репозиторий будет установлен
2. .npmignore отсутствует
3. .gitignore пустой
4. 3 дополнительные зависимости (видимо, очень необходимо для сжатия текста!!!)
Теперь посмотрим размер пакета: 41,3 КБ,
и размер самого скрипта сжатия: 4,64 КБ.
Вопрос… Почему размер пакета в 10 раз больше? Почему вместо одного файла я получил 40 файлов? Почему это повторяется для каждого проекта, для каждой зависимости?
Есть же нормальный минификатор – https://www.npmjs.com/package/terser
То есть все ваши претензии к npm заключаются в плохом seo, что гугл показывает не те пакеты в топе?
- Последнее обновление minify-js 3 года назад
- Использовать в 2020 году некий minify-js вместо terser — ну такое.
- Всё вами описанное — претензии к этому самому minify и его мейнтейнеру(хотя он видимо давно не поддерживается в виду его ненужности).
Отсюда опять возникает вопрос: а при чём тут npm и что конкретно ужасно в npm(именно в пакетном менеджере, а не в кривых пакетах в нем опубликованных)?
В общем Akuma прав — вы бьете себе по пальцам молотком и вините в этом молоток.
По старинке, ручным управлением зависимостями через ctlr-c — ctrl-v? Или таким-же npm, но с вахтёрами?
Опять же, мы говорим про разработку, а не деплой. И если молоток — это npm, а саморез — это браузер, то да, нужно постараться, чтобы закрутить его молотком.
Но давайте всё-таки говорить про разработку. Мы пишем код для браузера в чужом окружении. Так почему это окружение должно быть нодовское с его npm, когда есть множество других, например питон? Питон не требует 100500 пакетов и 100 мб места на диске, чтобы собрать и сжать скрипты в один большой бандл.
Архив с исходниками весит 550 КБ
После установки весит 44,5 КБ из которых 23,4 КБ занимает сам скрипт, который ещё и не сжат.
NPM приносит в систему кучу мусора
Так а что вы подразумеваете под мусором? Пакеты опубликованные в npm? Пакеты, которые вы ставите?
Я так и не понял ужачности npm из ваших объяснений. Мне кажется эти ваши "претензии" можно приплести к любому пакетному менеджеру, хоть к тому же composer.
MAM же.
Всем кто не согласен, предлагаю хорошенько покопаться в node_modules своего проекта. Но лучше не стоит так себя расстраивать. Потому что всё это напоминает горящий бордель, в котором у половины проституток вич, а у второй — туберкулёз.
А кто будет назначать этих "вахтёров"? И что вы будете делать, если их мнение по поводу некоторых пакетов отличается от вашего?
За все репозитории не скажу, но в ubuntu закрутили гайки настольно сильно, что большинства нужных пакетов там нет, и их приходится ставить из PPA. Даже собственно Nodejs рекомендует ставить их пакет из стороннего PPA, потому что в основном репозитории пакет не обновлялся уже год.
Там ещё есть история где мейнтейнеры debian репозитория сломали Node, потому что обладали своим особым взглядом на то, как именно она должна собираться.
Кто выигрывает в этой ситуации? Явно не пользователи, потому что единого репозитория пакетов они не получили.
Если открыть старый проект на php, который делал начинающий кодер 10 лет назад, там будет такая же каша из верстки и кода, как в jsx. Удивительно, как можно было наступить на те же грабли сегодня
Экспресс-тест, способен ли разработчик к критическому мышлению, или он просто повторяет что ему внушили – это спросить что он думает про JSX.
Экспресс-тест, способен ли разработчик к критическому мышлению, или он просто повторяет что ему внушили – это спросить, есть ли к него бэкграунд в других областях и есть ли с чем сравнивать
Если это был вопрос ко мне, то да, бэкграунд есть и сравнивать есть с чем. Конкретно про JSX я уже изложил свои рассуждения здесь: https://habr.com/en/post/311226/
А если разработчик задолго до Фейсбука пытался сделать что-то подобное?
не хочу лезть во вкусовщину о том, кому как удобнее
опыт мне говорит о том, что любой нормальный фреймворк делает все, чтобы выстрелить себе в ногу, а за одно бизнесу и коллегам, было как можно сложнее. Реакт почему-то делает это не везде. В JS в целом пока царит Дикий Запад, на устоявшихся платформах о таком вообще не спорят
Но ведь реакт это не фреймворк...
Вода, вода, вода. Svelte!
Давно пора все это дело компилировать, причем вместе с бекендом и базой.
Svelte / Stencil / Angular elements / Polymers / Web components примеры тренда который набирает обороты.
Svelte — не сказал бы что Svelte набирает обороты, несмотря на весь хайп. В нем много спорных решений, которые отталкивают.
Stencil — специализированный инструмент, хорошо подходит для узкого круга задач, но не для большого spa
Angular elements — тоже самое, когда ангуляр-фронту нужно быстро сделать виджет на сайт. Просто чтобы не было обидно, что vue или react можно встраивать.
Polymers — если речь про Polymer, это скорее playground фремворк для экспериментов, чем продакшн.
Web components — попробуйте сделать SPA чисто на них.
А статья то вообще о чем?
Расскажите, пожалуйста, чуть подобнее почему обязательно SPA?
Но фронтенд фреймворки предназначены в основном для SPA, отсюда их сложность, а виджеты можно и нужно просто на js делать, необязательно что-то тащить.
И Web components тут идеально, хотя бы потому что это стандарт.
Видимо, неверно понял мысль про SPA. Почему-то показалось, что возможность SPA — это значимый критерий качества frontend фреймворка.
К сожалению, не могу согласиться с тем, что framework должен уметь SPA. Скорее, SPA — та огромная цена, которую приходится платить из-за отсутствия SSR. Если приложение логически поделить на страницы, файлы с бизнес-логикой будут маленькими, быстрыми и удобными в поддержке. А сейчас всё смешивается в один огромный бандо.
Уверен, если бы у разработчиков библиотек и framework была возможность делать серверный рендеринг, они бы воспользовались этой возможностью и растащили логику на маленькие кусочки.
Но, когда речь идёт сугубо про клиентский код, приходится изобретены велосипеды для асинхронной подгрузки кусочков огромного бандла.
Не согласен. SPA как раз попытка избавиться от SSR со вполне логичным обоснованием: нет смысла грузить 100500 раз одну и ту же разметку, отличающуюся только данными. Загружаем один раз разметку, а потом подгружаем только данные. Вполне же здраво? С легкой руки Microsoft где-то на пике популярности IE идея пошла в массы, но что-то пошло не так…
Я занимаюсь именно SPA, типа сложные админки, личные кабинеты, мессенджеры-звонилки. SSR меня вообще пока что не особо волновало. Там где надо было SSR я брал Vue, но это проекты на пару недель, нормально, и еще не успеваешь налететь на вьюшные грабли.
Насчет «отсутствия SSR» вообще не понял, оно никуда и не девалось, от него ушли намеренно.
От фреймворка кроме SPA мне ничего и не нужно. Размер бандла не особо критичен, т.е. существующие устраивают, а если есть жесткие требования, то вот svelte как раз подойдет. Но это редкость.
И не вижу как размер связан со сложностью поддержки. На поддержку как раз влияет вменяемость фреймворка и средний уровень его программистов. Поэтому я люблю Angular.
Redux вам надоест после копирования пары сотен одинаковых экшенов на каждый чих и вы найдете MobX. На мой взгляд это пока единственное более-менее удачное решение.
Но и с ним вы столкнетесь с тем же, с чем и обычно — данные надо как-то получать и держать в обновленном состоянии. Наворотите запросов-к-апи-в-цикле, потом перейдете к вебсокетам, а потом снова задолбаетесь писать однотипные REST-контроллеры на каждый чих.
И найдете для себя fullstack-фреймворки, которые решают большую кучу проблем и делают ваш код меньше.
Попробуйте DerbyJS. Он не популярен, но он делает ваш код очень маленьким, а работает очень быстро.
Сделайте отдельный сервис, который будет постоянно все это тянуть в вашу БД, а пользователей подписывайте на эти данные.
Понятно что не всё для всего подходит. Так и для Реакта можно придумать шаблон компонента, который приведет только к проблемам.
Но конкретно я прошел примерно такой путь: jQuery — Backbone — Angular — React Redux/Mobx — DerbyJS
И последний мне гораздо больше нравится, потому что я перестал тратить время на рутину. Конечно есть и другие проблемы, как и везде до этого, куда ж без этого.
И от чего конкретно вы хотите освободиться?
Я говорил например про это: habr.com/ru/company/otus/blog/491408
Т.е. я прямо на клиенте делаю model.add('todo', {some:'data', json:1}) и все. Никаких контроллеров, никаких CRUD, ничего этого.
Данные тут же отображаются на этом и других клиентах «сами-по-себе».
// Отдельным процессом
setInterval(() => { model.add('data', getFromExternalApi()); }, 60000);
// На клиентах
model.query('data', {some:1, mongo: query}).subscribe(...);
Это если не хочется делать на клиенте запросы напрямую во внешнее апи, а обычные контроллеры писать тоже почему-то лень.
Есть ещё Asp.net Blazor. Благодаря webassembly можно писать фронтэнд на C# и шарить логику фронтэнда с бэкендом. Вот это уже более интересная тенденция, чем Svelte. Возможно со временем сишарперы ворвутся во фронт, вместе с какими-нибудь питонщиками и даже пхпшниками, и перевернут игру )
Вью который показывает себя лучше в моментах где Angular и Реакт ему уступают.
Какое тонкое и проницательное наблюдение!
И вся статья такая же: "я вот заметил, что появляются новые фреймворки! почему бы это? потому что старые решают задачи не идеально! Цветочно-конфетный период с реактом/ангуляром/вью прошел, и мы теперь ищем что-то новенькое, я вот нашел svelte!"
На мой частный взгляд основная проблема современных библиотек и фреймворков на js заключается в попытке управлять живыми объектами через «поток вывода» (шаблонизатор) и игнорирование всего предыдущего опыта программирования пользовательских интерфейсов.
Как вы думаете, отчего в мире java, например, не появляются каждый год десятки новых JFX?
— Оттого, что JFX решает ВСЕ поставленные задачи, не навязывает вместе с костылями никаких ограничений и вообще ведёт себя прилично.
Отчего в мире JS так упорно отказываются от прямого использования DOM?
— Оттого, что в голове у JS разработчиков плотно засел HTML и они не могут представить себе как можно отказаться от шаблонизации.
Мы всё ещё плотно заняты поиском идеальной серебряной пули, которая убьёт всех без исключения монстров, хотя остальной мир давно понял что чудес не бывает и спокойно продолжает использовать MVC и его производные по вкусу и в зависимости от решаемых задач.
В общем, я плавно подвёл вас дорогие товарищи к w3view, о котором мною была написана пара статей на хабре :). Хотите развития, расширяйте кругозор :).
За сим разрешите откланяться.
PS замечательная фраза «Вам все так же надо вручную думать»
Серебряной Пули нет еще и потому, что люди бывают сильно разные, звучит плоско но эта плоская истина действительно упускается народом в массе, МЫ РАЗНЫЕ, блин, и то что одному «понятно и удобно», другому — чуждо и напряжно.
Есть конечно более объективные моменты и на них желательно и акцентровать в статьях.
JSX вполне себе удобная вещь, компоненты — тоже норм, особенно VUE, реакт мне кажется сложноватым, но важнее другое: контекст задач в которых оценивается инструмент! Я вообще никогда никогда никогда не буду работать с масштабом задач где мне понадобится стопицот контролов с состояниями )
Или вот вам еще пример: игра Godess Kiss, миленькая анимешная тактилка которой уже лет 5 и с первого дня там любой тиск по кнопке приводил к фризу в овер три секунды (!) КАЖДЫЙ клик почти по любой кнопке!
Игра просто все хранит на сервере чтобы не заморачиваться с читерами и преспокойно себе кладет болт на неудобства такого рода для своих игроков и ничего, топовая пилотка там стоит косарь баксов (ах, Лея, услада глах моих) и она у каждого третьего!
Ну и наконец сложные задачи не могут быть простыми и никакой фреймворк не сделает за вас то за что вам платят годовую зарплату среднестатистического россиянина в месяц, а если такой фрейсворк появится — то на следующий день вы станете безработным.
И по теме: лично мне Strapi зашел c Nuxt(Vue) и Graphql. Последний вроде как хорош именно для унификации запросов к разного рода источникам данных.
Чем больше на себя берёт библиотека или фреймворк, тем уже скоуп решаемых задач и больше навязываемых ограничений.
Хорошая библиотека или фреймворк не навязывает единственный способ решения задачи и свои ограничения. Точки расширения, хуки, DI, события и т. п....
Ограничения были и будут, вопрос же выбора платформы и инструмента — прикладной и количественный: «сколько нужно фреймворков, чтобы вкрутить лампочку?»
На просторах СНГ есть этот особый культ «крутизны», когда ты не просто делаешь магазин тормозных колодок а непременно «разрабатываешь энтерпрайз-решение для электронной коммерции», «юзаешь» сторы, стэйты, три типа БД, интеграцию с сервисом ставок и фондовой биржей в Бирмы, все известные топовые плагины анимации и скролла (просто чтоп были ато скажут что лох) и при этом ты то работаешь без сна то сутками самосозерцаешь в банку пива и рубишься в контру.
Пытаясь заглушить стыд от того что не втащил бигдата, а что если на твой сайт зайдет миллиард посетителей!? Что будет с твоей хваленой монгой?
Все не торт, думаешь ты и идешь на хабр за подтверждением своих сомнений…
А продавцу тормозных колодок главное чтобы машинка на сайте была бэха и красного цвета, а 500 баксов ты взял, он в этом уверен свято, за то что она бликует так красивенько когда мышкой наводишь и черт возьми это стоит своих денег!
Настало ли время покинуть виртуальный дом [React'a]?