Comments 439
А надо было подождать всего пять дней.
Да, тут у автора, совпадение? — не думаю… С ноутом как и с кофе — отборные зерна, спец помол, температура и чистота воды и… ФРЕНЧ Пресс!!!)) сколько не пил кофе из пресса — это изврат… И бычками потом жижа воняет. Может не слишком отборный сорт кофе?
Это смотря насколько кривые руки у того, кто эти формы написал.
Если система постоянно использует своп и в ноуте например жесткий диск то в теории все может замедлиться во много раз. В пределе, если предположить что память быстрее диска в 100 раз, то вместо секунды это все будет 100 секунд собираться.
Главное сильной (или слабой?) прожарки.
И оно билдится «всего» 90 секунд?
Всё равно, проект весом около мегабайта билдится 90 секунд?
Это размер исходников или уже опубликованного продукта?
Я конечно понимаю, что SLOC это плохая метрика, но сколько строк в таком проекте, хоть приблизительно для восприятия масштаба?
У меня Gradle за столько 100к строк джавового кода для Android билдит, и я думаю, что это долго, а ту 10к. Как-то грустно.
После мелких изменений в паре файлов повторные билды очень быстрые, в десятки раз быстрее холодного билда с нуля.
Так вот, запустил билд проекта, собрался за пару секунд.
Я недавно, на одном стройобъекте по надобности ненадолго сел за компьютер прораба: давно пожелтевший системник, принтер вроде HP1005, процессор примерно Pentium 1600, внутри Word 2003 для печати документов, эксель для заполнения ежедневных отчетов, и кажется Nanocad для чертежей.
Так вот, вся эта археология работает быстрее и отзывчивей, чем моя рабочая система, с NVME, Ryzen, 16Gb и последними версиями Autocad.
А зависимости в node_modules посчитали?
гораздо проще написать вы фронтендщики говно!Я не писал что фронтенд-программисты говно — собственно, я так и не считаю. Но технологии фронтенда — объективно полный отстой.
Вместо того что бы взять LLVM
Напомнить что произошло с Flash, Java Applets и Unity Web Player, который "просто встроили в браузер"? Я напомню:
- они были постоянно дырявыми, и по факту просто были дырками
- они были привязаны к конкретному производителю
- они не управлялись программистами, а были костылём который был приколочен рядом
- если у пользователя что-то случалось, то цепочка виновных была: сайтостроитель, производитель браузера, операционной систем и только потом производитель плагина. Просто потому что так оно видно для пользователя.
И хоть сейчас и очень заметна монополизация гугла, веб всё равно остаётся областью паритета нескольких сил. Не было бы этого паритета был бы Apple и тот же Гугл со своими 30%.
Я для себя смирился с достаточно простой мыслью: веб это общественнозначимая помойка. И именно поскольку она общественно значимая её будут охранять от vendor lock'а и государства, и сами компании. Но общественное не может быть одновременно хорошим и удобным. Потому что нужно учитывать общее мнение и не может быть Сталина, который стукнет кулаком по столу и отменит поддержку es3 или html.
технологии фронтенда — объективно полный отстой
Да, потому что это наследие. Потому что люди когда придумывали эти технологии они совершенно не думали о проблемах, которые эти технологии будут решать через 20-30 лет. Вспомним хотя бы первые сети, которые не предусматривали шифрования, потому что никому в голову не приходило, что в сети могут пустить домохозяек и хакеров.
Напомнить что произошло с Flash, Java Applets и Unity Web Player, который «просто встроили в браузер»?И ведь Вы не назвали ни одной технической причины. Ну что, принципиально невозможно сделать плагин недырявым? Или может в особенном фронтенде без привязки к одному производителю никак?
Да, потому что это наследие. Потому что люди когда придумывали эти технологии они совершенно не думали о проблемах, которые эти технологии будут решать через 20-30 лет.Да я согласен, что обвинять отцов-основателей бессмысленно. Но сейчас всеми стандартами веба руководит вполне конкретная небольшая группа монополистов, и о своей монополии они заботятся куда больше, чем о каком-либо развитии.
и код будем передавать в виде синтаксического дерева
Вообще-то код на WASM передаётся в бинарном виде.
Ну на мобильники как бы тоже не бинарники летят. Хотя нет, по такой логике только Apple самые лучшие инженеры на этой планете, раз сразу бинарники людям поставляют.
Ну это уже давно обсуждали тысячу раз. Есть вещи для которых определённый подход хорошо, есть для которых плох. То что сейчас веб переживает проблему роста не значит что он говно. Это значит что сейчас люди наберутся злости и произойдёт что-то ещё новое. Тот же wasm является ступенькой к этому новому. Не само новое, а ступенькой к нему.
То что у автора есть проблемы и он огульно поливает грязью целую индустрию без доказательств говорит только о его "профессионализме". Вот только пользы от этого нет. Проблемы эти заметны уже давно и их так же давно пытаются решить. GCC (который компилятор от гугла, а не от GNU), typescript, dart, wasm, webpack, jquery — это всё представители этих самых решений. Это не решения которые "решают проблемы которые сами же создают", а инструменты, попытки сделать что-то лучше и удобнее. Да, сейчас всё обстоит так, что за удобство мы платим скоростью транспиляции, оптимизации, загрузки страницы, рендера страницы etc. Но не волнуйстесь, ничто не вечно под луной, особенно проблемы, которые видны каждому первому проходящему, вроде автора.
Есть вещи для которых определённый подход хорошо, есть для которых плох.Правда? Ну и чем же фронтенд такой особенный, что он не может заранее распарсить JS-код и передавать в браузер уже байткод, который будет компилироваться в машинные коды клиентского девайса?
Автор — сквернословящий чудак, не способный затащить билд фронта в свой бекэндерский проект. Не знаю, насколько это сложно в шарпах, в java-мире это делается элементарно и там всё билдится по одной кнопке. И правильно настроенный билд spa (а не четыре формочки) почему-то занимал меньше минуты.
Так что я напрочь уверен, что его говнокодные формочки можно было сбилдить за ~5-10 секунд при правильной настройке. НО! Он же король разработки! Зачем разбираться в чужом стеке и уметь правильно настраивать, правда? Давайте обосрём и будем довольны. Но почему-то на плюсовиков он не отважился лезть. Полез, почему-то только на фронтендеров.
PS бекэндер на java, с небольшим опытом фронта. И да, я вот или не лезу сам формировать фронтовый билд или не жалуюсь, что долго. Зато в своё время разобрался с мавеном и знаю как легко билд на 15 секунд может выполняться больше минуты… если билд-скрипт написан через жопу.
Хотел бы я посмотреть на эти 0,713 байта после запятой ;-)
А представляете, сколько будет билдиться си-плюсовый код такого размера? :-)
Так-то картинка-мем про сражающихся на стульях программистов и проходящего мимо начальника изначально про плюсовиков была...
У меня, кстати, чуть меньший проект (800Кб) билдится с нуля за секунд 15-20, но у меня не старенький ноутбук, а вполне себе еще «торт» FX-8350. И это никто особо не страдал над скоростью билда, а можно было и пооптимизировать.
Памяти на это всё + VS Code + браузер уходит больше гига, но меньше двух, причём в основном её радостно сжирает хром, а не VS Code или билд.
Ваш пример — как раз хорошая иллюстрация, что современная массовая разработка шагнула куда-то не туда. В Делфи проект аналогичного размера компилировался секунд 15 — 20 на Celeron 600 MHz
У меня файл в 30 строк тайпчекается минуты три с половиной
И это отвратительно
Но из ваших слов (предыдущий комментарий) получается, что инструменты выросли… в чём? Во времени тайпчека?
В любом случае, исходник на 1 экран, который даже не начинает собираться за 3,5 минуты — это не есть хорошо. Я могу за схожее время собрать какой-нибудь огромный проект: только что пересобрал с нуля FreeSWITCH, и даже с учётом автотулзов у меня на полную сборку ушло 2 минуты. А ведь там много файлов по несколько тысяч строк кода…
Да, ждать по две минуты (а периодически приходится делать чистую сборку) — тоже некомфортно, но ждать ещё дольше для тайпчека одного экрана текста… что-то в этом явно не правильно…
Вы бы хоть комментарии писали. Сами не путаетесь в своем коде?
Насколько я знаю, дельфи (как и C++, JS, rust и почти все остальные языки) не позволяет ни формулировать, ни доказывать чего бы то ни было.
А зачем оно нужно для разработки прикладного ПО?
Эмм а можете рассказать мне в чем отличие по обработке с вашей точки зрения?
Как бы и во втором случае тоже надо, особенно если нужно выкинуть лишние функции. Разница начнется когда доедет непосредственно до компиляции.
Что мешает фронтендным менеджерам зависимостей в определенном формате хранить апи этих зависимостей позволяющем не выполнять лишнюю работу?
Вы предлагаете разработчикам NPM добавить ещё и полноценный ABI добавить в стандарт языка и поддерживать его? Не то чтобы я был против, но боюсь, что они не согласятся. Вообще если пойдете, то лучше не в NPM, а к разработчикам Babel, наверное ну или TypeScript. А и лучше сразу WebAssembly нормально поддержать. И опциональную типизацию, наверно.
Что мешает использовать опыт из других языков?
До введения precompiled headers, скорость компиляции файлов для Delphi превосходила компиляцию С++ во много раз.
А что крутого в том что исходники так организованы что в них не разобраться быстро даже при работе в 8 потоков… Человек вообще наверное не понимает, что в них на самом деле написано :) сложность ведь запредельная ;)
И в окружении, во-вторых
JS никогда не будет быстрее классических компилируемых или даже интерпретируемых языков, потому что в нем кучу извращенных костылей, образовавшихся исторически, нужно слепить с кучей библиотек и пакетов (нет, их нельзя собрать заранее или как-то упростить процесс, как вы предлагаете ниже, потому что это будет постоянно создавать проблемы версионирования и консистентности, потому что нативного репозитория тоже не существует), а потом впихнуть это в такой формат, чтобы его понял даже старинный IE…
Полифилы и прочие подпорки занимают от силы 10% от всего того треша что собирается.
потому что это будет постоянно создавать проблемы версионирования и консистентностиА можно по-подробнее? Чем проблемы версионирования бинарников будут отличаться от проблем версионирования исзодников, из которых они собраны?
Звучит, как будто в во втором случае меньше работы, так как часть вещей делается в рантайме
Angular при продовой сборке выкидывает целые неиспользуемые модули и компоненты, проверяет типизацию и вот это все
И да, поэтому он это и делает довольно долго
Т.к. функционально это близкий аналог DCE (dead code elimination) в gcc. Что является достаточно быстрой фазой, т.к. требует однократного прохода по коду программы (разумеется в специальном представлении: IR).
А за описанную вами оптимизацию отвечает Constant propagation (вероятно в gcc называется также, но не уверен).
Это я, возвращаясь к нашим баранам, к тому, что конкретно удаление мёртвого кода мало что говорит о качестве оптимизирующего компилятора.
Во-вторых, меня спросили — я ответил
В смысле, что в современном фронте это тоже есть
Нет. В дельфи подобного размера всегда компилировалось в пару секунд. 20 сек это билд всего с 0, но это крайне редко практикуется
В отличии от TypeScript, в Дельфи нет проблемы вывода типов. То есть в том же Дельфи компилятор может за несколько фаз собрать необходимый набор объектных файлов, причем каждый исходник может быть пройден независимо от других. В TypeScript может быть функция в стиле display = () => convert(this.name), то есть тип функции display определяется функцией convert. А она может, в свою очередь, ссылаться на другую функцию.
Аналогично с выводом типов уже внутри функций — он запускается только после фазы выше, тогда как в Дельфи типы определяются в самой переменной, так что этот пункт можно пропустить.
Как следствие — компиляция в Дельфи крайне хорошо параллелится, не требует много памяти (так как до линковки не надо поднимать в оперативку весь граф зависимостей) и так далее. Тогда как в условных TypeScript/Scala/C# программист может положиться на вывод типов, так что компилятору приходится выполнять больше грязной работы.
В отличии от TypeScript, в Дельфи нет проблемы вывода типов.
Ну так потому что система типов никакущая. Почти как в яве, только еще более никакущая. Нет сложности — нет и проблем.
Если с конкретикой – мне не хватало union types, чтобы можно было Array<number | string> как в Typescript
Берите и пишите на Ceylon. Он тоже на JVM.
Но вообще Union Type в Java можно заменить на библиотеки (это уже официальный подход, см. Optional), запись List<Either<Number, String>> всего лишь немного длиннее.
Вопрос был "что в Java не так".
Я всего лишь предлагаю варианты решения проблемы.
Так-то на запрос "хочу Array<Number | String>" моей первой реакцией будет скорее удивление, потому что там, где я хочу чего-то настолько же странного, лучшей идеей будет сделать нормально именованный тип, чтобы всем было понятно, что это, откуда, кто и как именно этим пользуется в проекте.
Upd: кстати, union'ы в Java вообще-то есть, но не для всех — их можно использовать в catch. Просто упомяну, может кому полезно будет.
А это уже следующая "хотелка", хочу чтобы тип Number | String можно было сделать именованным. И нет, Either<Number, String> — это немного не то (и, кстати, он такой же неименованный).
class Value extends Either<Number, String> {}Не вижу принципиальной разницы между Either и |, вот честно. В чём проблема, в том что это не часть языка?
И я знаю, что Either это неименованный тип. Я его не себе предлагаю использовать — я это предложил вам, как прямой соответствие Number | String. Сам я так обычно не делаю, видимые типы лучше всё-таки именовать.
Принципиальная разница — в том, что за отсутствием в JVM структур Either<Number, String> может быть только отдельным объектом, соответственно его использование всегда немного нагружает GC.
А гипотетический Number | String можно было бы сделать без выделения отдельного объекта под хранение признака Number там или String.
Для value-значений типа String это в обозримом будущем будет стоить вашему приложению потери производительности при сравнении между List<String> и List<String | Number>, потому что первый сможет специализироваться в массив байтов, а второй останется массивом ссылок на Object с некоторым синтаксическим сахарком на уровне компилятора.
Причём, как я уже сказал, за сахаром уже сегодня можно сходить пописать на Ceylon.
Э-э-э, а как это List<String> может оказаться массивом байтов? Может, вы List<Number> имели в виду?
Нет, и String тоже, в теории. Подвижки по value types для того и нужны, чтобы хранить в массивах только один служебный указатель на тип, а сами значения паковать как линейный суп без ссылок. Чтоб массивы были больше похожи на С, причём и массивы внутри ArrayList (иначе смысла мало). Но это, конечно, если String когда-то станет таким типом. Учитывая, что для полноценной поддержки для начала придётся убрать конструкторы — то и Integer таким типом может никогда не стать, для сохранения обратной совместимости.
Зато List<Number> скорее всего никогда как раз не будет паковаться — паковаться будут List<Integer> сотоварищи.
В TypeScript может быть функция в стиле display = () => convert(this.name), то есть тип функции display определяется функцией convert. А она может, в свою очередь, ссылаться на другую функцию
Может, но кто-то во мне подсказывает, что даже если программист расстарался, и там в модулях десятикратная вложенность типов, затянуть всю иерархию типов проекта в одно развесистое дерево в памяти из разных модулей и определить их все — не бог весть какая задача для компьютера, делающего несколько миллиардов операций в секунду. И медленно оно отнюдь не поэтому, а… просто вот так реализовано.
Я сомневаюсь, что «ну просто вот так реализовано» в четырёх реализациях, три из которых независимы совершенно.
А я не сомневаюсь. У меня на компьютере полно мелких утилит, которые жрут ресурсов на порядок больше, чем навороченные IDE пару десятилетий назад. Сейчас все так пишут.
у вас на строчку кода составляется минимум по уравнению на типы, и эта система уравнений потом решается. Поэтому в сотне килострок их может быть очень много.
Да, но ведь 99% из этих уравнений решаются простой подстановкой, и кроме того, не на строчку кода, а на строчку кода, где присутствуют переменные/функции, чьи типы, собственно, нужно выводить. У вас же не в каждой строчке кода используются новые переменные и новые функции?
Алгоритм Хиндли-Милнера пришёл к нам лет 30 назад, когда компьютеры имели смешную по нынешним меркам производительность, и компиляторы Хаскеля справлялись со своей работой и на 386-х процессорах.
Джавовый проект есть на 100к строк код с мавеном — сейчас лень смотреть, но время сборки +линтера в сумме в несколько раз меньше.
Но если говорить про CI то js значительно медленнее чем другие языки-очень медленный туллинг, который написан на джсе, нпм инсталл занимает десятки секунд-и с этим сложно что-то сделать, линтер даже на 1к строк кода запускается и пробегает поряка 5 секунд, тесты также в разы медленнее исполняются.
А на фронте еще куча наворотов поверх самого js.
Меня больше всего прикалывает тот факт, что при этом жавовый код со всеми зависимостями закешированнными из мавена и умеющий дофига всего, может весить меньше frontend проекта с модулями ноды :)
нпм инсталл занимает десятки секунд-и с этим сложно что-то сделать
Yarn 2 Berry уже сделали с этим что-то. PnP называется, почитайте. Выглядит довольно дико на первый взгляд, с непривычки. Но я уже пользуюсь этим и доволен как слон — зависимости хранятся прямо в репе, никакого npm install при деплое.
Автор сам пишет, что не компетентен в разработке компиляторов, но, почему то, рассуждает про то, с какой производительностью и при каких условиях они должны работать. Некомпетентные Блогеры, пожалуйста, Астанавитесь.
У него достаточно компетенций, чтобы заметить, что его огромный бэк собирается куда быстрее 4 форм.
Его неизвестно какой бек (он ничерта не написал, что могло бы послужить для оценки) с предкомпилированными зависимостями и его тухлый, неизвестно что тянущий в зависимостях (но все они не компилированные) фронт.
Достаточно компетенций на что? На сравнение теплого и мягкого? Из статьи совершенно непонятно:
- Взял ли автор правильный инструмент для своей задачи
- Умеет ли он им пользоваться
- Не стреляет ли он себе в ногу намеренно
пусть VDSina выдаст выделенный эпичный сервер, с ноута за 80 тыр заходим по RDP и всё ок
Автор, конечно, перегибает, но ведь это именно та проблема, о которой он пишет. Вместо того, чтобы оптимизировать инструменты, ставим более монструозную железяку.
время программистов дорого
Раз время такое дорогое — почему его не экономят, ведь за то, что программист ждёт окончания компиляции, тоже кто-то платит?
Скорость чтения/записи на диск это то во что ты упираешься пиши хоть на ассемблере. Если твоя программа работает с файлами, выше этой цифры не прыгнешь. Если опускаться на уровень операционной системы она тоже работает с файловой системой, например когда ты запрашивает новый срез memory mapped файла. Не возьмусь утверждать, но вроде винда скидывает дамп памяти на диск при выходе за границы виртуальной памяти процесса. JS код это очень-очень много мелких файлов (node_modules). Билд на SSD и HDD небо и земля, личный опыт.
Не возьмусь утверждать, но вроде винда скидывает дамп памяти на диск при выходе за границы виртуальной памяти процесса.
Конечно скидывает (pagefile.sys), что ещё винде остаётся делать?
Ноутные HDD обычно на 5400 rpm. Да, сегодня для разработки SSD это минимум, а ещё лучше хороший NVMe SSD.
Скорость чтения/записи на диск это то во что ты упираешься пиши хоть на ассемблере.
Это потому, что вы пытаетесь бороться со следствием, а не с причиной:
JS код это очень-очень много мелких файлов (node_modules)
Я не говорю, что надо все бросить и переделать, но сейчас многие даже думать не хотят о том, что что-то может быть построено иначе. Просто используют метод грубой силы, благо возможности есть.
JS пакеты, это тысячи мелких файлов
похоже прогресс примерно здесь пошел не туда
хотя да, зерлинги, большими толпами, рулят :)
С пустяками вроде трехмерного футбола с очень серьезной физикой и графикой, мощным ИИ, и очень серьезными расчетами в реальном времени ноут справляется.
Так напишите систему сборки фронта на видеокарте, если конечно получится. Вся физика и графика замечательно распараллеливается и обсчитывается на видеокартах. Со сборкой кода такое вряд ли прокатит.
ноут за 80 кусков
Печатная машинка конечно дорогая, но вы вроде собирались ноутбук для разработки покупать? Я вот стационарный комп год назад покупал, он мне без видеокарты в 90К обошелся, аналогичный по производительности ноутбук будет все 120К, а то и больше. Но это же рабочий инструмент.
Или не умеет открывать js, html etc файлы?
Процессор 2,5 GHz Intel Core i5
Память 8 ГБ 1333 MHz DDR3
SSD 120Gb
HDD 500GB
Dash Kapeli
Dropbox
VSCode с небольшим проектом
PHPStorm с проектом потяжелее
foobar2000, крутящий flac'и с Джонни Кэшем
SublimeText 3 — 7 окон, примерно 50-60 вкладок
qBittorrent, 14 раздач
Skype
Telegram
ForkLift
AraxisMerge
nvALT (759 файлов-записей)
iTunes
iTerm (zsh) с запущенным webpack
Сервисы: nginx+php-fpm, mysql, elasticsearch, rabbitmq, nodejs
Я это к тому, что нужно код смотреть и искать причину долгого билда.
Не тормозит, вернее, тормоза бывают крайне редко, и я их устраняю.
Может, причина в OS (у меня до сих пор установлена HighSierra), но я склоняюсь к тому, что причина в подходе к настройке.
Пример: nvm (nvm use) при переходе в папку проекта я запускаю вручную, а не даю на управление шеллу, так как начинает страдать отзывчивость. Мне это несложно — аптайм исчисляется неделями.
Моё примерное рабочее окружение описано тут.
Ну, можете заехать и убедиться сами ¯\_(ツ)_/¯
Можно по видеосвязи демонстрацию устроить.
Можно Фила попросить заехать и глянуть, он в этом же городе живёт :-)
Про вкладки хрома, они бывают "разные" одно дело текстовые странички, другое, к примеру вкладки с забором с большим количеством комментариев :)
Я могу. Сейчас их 141.
Ох сколько всего интересного можно запустить на таком железе вместо одной лишь Android Studio
топовейший ноут
80 кусковчто-то не сходится. Такое ощущение, что вы отстали от цен лет на пять. Сейчас топовый ноут дешевле 100-150к найти крайне сложно.
Мы же все сейчас любим удаленку и хотим иметь возможность возить рабочее место с собой.
Стоит 150-200к. Ленова x1 или Мак по вкусу. Оба хороши.
Не хотел бы я таскать ноут за 200к с собой
Для этого изобрели SSH и удалённый рабочий стол. Ставишь дома десктоп с жирными вещами и соединяешься издалека.
Это не работает с разработкой 3D приложений от слова "совсем".
Все будет тормозить, либо вылезать артефакты, что неприемлимо.
Но достаточно давно VMware внедрила PCoIP протокол (пусть он и требовал тогда ускорителей) именно для работы всяких 3D-разработчиков удаленно.
Ну или более новая версия — тот же Parsec (изначально — для стриминга игр, вполне нормально стримит, и он вообще бесплатный).
Недостатки конечно есть но некритичнные:
— ОЧЕНЬ желательны аппаратные кодер и декодер (обычно встроенного в процессор или видеокарту хватает). Если нет — будут лаги и артефакты.
— Канал кушается мегабитами, можно настроить чтобы десятками мегабит кушался если надо совсем уж высокое разрешение. Если канал не держит — будут лаги и артефакты.
Пробовал я Parsec — всё равно не зашло, артефачит, удобство использования не очень.
Страдал с VNC/AnyDesk/NoMachine/X2Go/ещёдесятокспособов, потом в итоге купил ноутбук и будто заново родился.
Для обычной разработки удалённое подключение — нормально, жить можно.
Для 3D графики — при всём желании невозможно ужать гигабиты видеотрафика в мегабиты. Всегда где-то в чём-то будет плохо.
То ли дело ноутбук, летает, работать с 3D одно удовольствие.
Конечно! В хороший ноутбук и в GeForce RTX 3080 влезет!
3dnews.ru/assets/external/illustrations/2020/08/07/1017647/axp1.jpg
Но по дексктопу согласен, отдельным пунктом 34 21:9 монитор или два монитора и где здесь место ноуту не могу сообразить
У Ryzen 3900XT нет интегрированного видеоядра, так что на видеокарту всё-таки придётся раскошелиться дополнительно. Правда, если не играть на машинке, то в цене прибавит не намного, примерно как ещё один блок питания.
Ну вообще-то да, но тогда условие "если есть уже корпус и блок питания" во-первых, перестаёт быть опциональным, а во-вторых превращается из задачи сборки нового компьютера в задачу апгрейда.
Со старой видеокартой я вот именно так и сидел прошедшие полгода, правда не на 3900XT, а на 3800X.
А потом купил RTX 2070S утром в день анонса RTX 3070. Да, до сих пор немного штормит.
А зачем 4к экран? Он ведь не в ем нужен, у кого о глаза не видят этих 4к на 14 дюймах…
Да и последние процессоры часто идут в варианте не 15Вт а 28Вт, что при отсутствии нагрузки на видеоядро уже не так скудно...
На FHD шрифты — это кошмар. Лично для меня 4K в 2020 году — это обязательная штука, как и SSD.
Не видеть разницу между FHD и 4к, даже на 14", может только совсем слепой человек
Ну, у меня где то -7 с копейками зрение
Сорри, но не вижу расхождений в ваших тезисах :)
Был у меня 15.6" ноут с FullHD, с которого перешел на MBP16" с 3072x1920 (наверное, это 3k назвать можно). И разница между 140 и 226 ppi коллосальная в ощущении (хоть у меня и -1.5 зрение примерно). На FullHD на такой диагонали виден "песочек" на шрифтах, на маке уже нет с рабочего расстояния. Хотя на смартфоне, конечно, и 226ppi смущали бы, там 300+ обязательны.
Не видеть разницу между FHD и 4к, даже на 14", может только совсем слепой человек.
Вы видимо забыли закончить: ведь только топовые конфигурации совсем не лагают на 4k. Визуально — нулевое различие для ~80% населения
OS, Идея, браузер, прочее 2Д (и фильмы) прекрасно работает в 4К без каких либо лагов. У меня железка совсем не новая и не топовая: Intel Core i7-6700HQ CPU @ 2.60GHz × 8 / Mesa Intel HD Graphics 530 (SKL GT2)
Ну вот у меня видео подлагивает под W10 на i5 и напрочь тормозит (и возникают всякие зелёные фрагменты) на ubuntu с i3 (на неттопе, который заявлен как 4k ready). Можно, конечно, попытаться списать на ресайзинг под 1080p экраны, но пропорциональное уменьшение картинки это вот вообще не задача для современных видео. И нет, я как не геймер не вижу большого смысла тратить х2-5 денег на железо.
Можно, конечно, попытаться списать на ресайзинг под 1080p экраны, но пропорциональное уменьшение картинки
Вы говорите о просмотре 4К роликов, а PocketM о 4К экранах. 4К экраны ведь не только для просмотра роликов в таком разрешении. Мы тут вроде больше о четкости в целом, скажем, текстов говорили.
Одно время, я работал над проектом на nodejs. Сборка была автоматизирована и проблем с этим не было, но запуск и работа была, скажем так, небыстрой.
Полностью согласен с автором, что существующие средства разработки очень медленные. И жадные до памяти.
P.S. долго думал над «вскод». Сперва показалось, что ошибка/опечатка. Когда дошёл до «жскод», стало понятно. VSCode/Atom/Electron жрут немало ресурсов. С теплотой вспоминаю VS6.
| топовейший ноут
| 80 кусков
что-то не сходится. Такое ощущение, что вы отстали от цен лет на пять. Сейчас топовый ноут дешевле 100-150к найти крайне сложно.
Тут как раз все сходится. Топовейший ноут автору не успели поставить, и автор взял
самое лучшее, что было в наличии — весьма среднюю машинку
хотя и
современный ноут
но это уже всего лишь показатель времени создания ноута, а не уровня его железа.
Тут же от размеров зависит, если устроит 15.6 то вариантов побольше, у автора 8 Гб оперативы ведь, он конечно не топ но за эти деньги вполне можно найти норм проц без видеокарты с ssd да там не будет супер экрана супер батареи но производительности будет немало
потому что ноду изобрели недопрограммисты. Никакой нормальный программист не будет использовать жс ни для чего, кроме как манипулирования хтмл.
1. фронтендеры vs бэкендеры
2. js fameworks: «тормозное гэ» vs «новые технологии, ускоряющие разработку от процесса до релиза»
3. ноут за 80к: «топовый гаджет» vs «бюджетная печатная машинка»
4. кофе с молоком и
Я может что-то не понял, но зачем в этой статье подробности о приготовлении кофе, семейной жизни и терзания по поводу кухни на другом этаже? Такое впечатление что они вставлены ради того, чтобы быть вставлеными.
Ну тут как всегда… есть варианты и другие случаи… Когда еще лучшим из доступных компьютеров был Yamaha MSX, так же известная как КУВТ… Запускаешь компилятор C… Идешь с четвертого этажа на первый в кафе, отстаиваешь очередь, пьешь кофе. Возвращаешься на 4-й этаж по лестнице (лифт был, но у студентов на нем ездить было не принято), смотришь на экран… идешь снова на первый этаж "покурить" с курящими друзьями… Возвращаешься… Ура, освободился соседний компьютер! Запускаешь Zanac и… на самом интересном месте… оно скомпилировалось… Правда, был еще "Трубо-поскакал"… Хоть над ним все и смеялись, но компилировал того же уровня сложности код за минуту-две… Ну да, была тонкость. Примерно максимум объема кода был около 32 килобайт… На C можно было сделать include и скомпилировать пару сотен килобайт кода за раз. Правда толку-то? В компьютере всего 64 килобайта оперативной памяти из которых что-то около 12 килобайт съедал DOS… (А как я радовался, когда придумал способ заменить 3 "матрицы" 64x64x64 float, которые требовались формально для расчета, на две матрицы 64x64! Что такое полтора мегабайта в наше время? У меня сейчас эта небольшая страница Хабра почти 200 мегабайт памяти скушала...)
PS: И не надо говорить про контрол с текстовым редактором. Я в свое время уместил текстовый редактор с синтаксической подсветкой кода в .exe файл 12 килобайт размером. Без сжатий и чего-то подобного. (исходников было что-то около 20 килобайт, ЕМНИП).
Видимо, чтобы показать сколько всего можно успеть сделать за время билда. Описание в подробностях тут — литературный приём.
С уважение, Ваши фронтенд-разработчики.
Сколько нужно сторонних библиотек королю разработки, чтобы сделать четыре формы? Судя по статье, очень много.
Ребят это костыли чистой воды. Сколько уже времени прошло с момента изобретения пакетов и минификации? Лет десять не? И до сих пор сборка и минификация js занимает чудовищное количество времени, жрет чудовищное количество ресурсов, а так же занимает дофига места на диске. Что еще веселее многие nodejs именно приложения просто не работают после минификации и требуют наличия node_modules.
Чтобы избежать вопросов этого не может быть сразу даю ссылку на проект https://github.com/koenkk/zigbee2mqtt
Задача простая взять проект и собрать минифицированную версию которая будет запускаться на ноде. Я ее уже даю раз в третий и каждый раз все заканчивается, сорян товарищ, там либы кривые никак.
И до сих пор сборка и минификация js занимает чудовищное количество времени, жрет чудовищное количество ресурсов, а так же занимает дофига места на диске.
Так нет, не занимает и не жрёт. Если вы делаете нормально. Вот места занимает дофига, да — по той банальной причине, что npm никаких ограничений на содержание пакетов не накладывает, и типичное содержание пакета — это несколько «готовых» версий библиотеки (минифицированных и в разных модульных обертках), плюс весь-весь исходный код. А то еще и пару картинок (для документации) догадаются положить, размером как весь остальной проект.
то еще веселее многие nodejs именно приложения просто не работают после минификации и требуют наличия node_modules.
Я ее уже даю раз в третий и каждый раз все заканчивается, сорян товарищ, там либы кривые никак.
Значит у вас такие программисты, которые даже исключения в минификации настроить не в состоянии, чтоб «кривые либы» тем не менее собирались в единый проект без внешних зависимостей, пусть даже часть кода в них останется не минифицированной.
Так нет, не занимает и не жрёт. Если вы делаете нормально.
Автор как раз на это и указывает. Почему на куче других языков это просто работает, а вот под js мне обязательно делать "нормально"? И да это делать нормально не гарантирует, что оказывается эти пакеты надо и с этим ничего не поделаешь живите так.
Вот места занимает дофига, да — по той банальной причине, что npm никаких ограничений на содержание пакетов не накладывает, и типичное содержание пакета — это несколько «готовых» версий библиотеки (минифицированных и в разных модульных обертках), плюс весь-весь исходный код. А то еще и пару картинок (для документации) догадаются положить, размером как весь остальной проект.
И еще зависимости внутри ага.
Значит у вас такие программисты, которые даже исключения в минификации настроить не в состоянии
Ребят еще раз задам вопрос, а не дофига ли мне надо знать притопов и прихлопов? И более того специфичных знаний о куче упаковки. Если у вас руки прямые вон я ссылку дал. Покажите так сказать мастерство. А то рассказывать что руки кривые это прям всегда прекрасно, а как просишь рассказать как то ой.
Почему на куче других языков это просто работает, а вот под js мне обязательно делать «нормально»?
Нет, не обязательно. Я вам сейчас может картину мира порушу, но — «под js» вам вообще ничего не обязательно билдить. Честное слово. Оно и так работает. На моей позапрошлой работе у меня был очень большой сложный проект почти на мегабайт минифицированного JS, который «билдился» в пределах пяти секунд, и точное количество секунд зависело исключительно от производительности HDD по переносу файлов в папку с дистрибутивами (повальная минификация занимала вообще миллисекунды).
А вот если вы хотите присосаться к мегабайтам чужого кода в экосистеме npm, к крутым фичам, которых совсем даже нет в голом JS, и еще много к чему — вот тогда извините, но да, вам придётся в этом всем хотя бы немного ориентироваться, чтоб оно у вас было «нормально», а не как живописуется в статье.
И еще зависимости внутри ага.
Они не «внутри», а в других пакетах. И да, конечно возможны ситуации, когда десяток-другой пакетов импортировался аж пять раз с разными версиями. Но если вы не пользуетесь мёртвыми пакетами с кучей зависимостей (а зачем ими такими пользоваться?), то таких ситуаций на самом деле сильно меньше, чем может казаться. Скажем, в моем нынешнем рабочем проекте (215Мб node_modules) одни и те же пакеты разных версий занимают 13Мб. Специально недавно интересовался.
Ребят еще раз задам вопрос, а не дофига ли мне надо знать притопов и прихлопов?
Таки вы уже купили весь npm, чтоб весь этот опен-сорс стал вам что-то должен, например то, чтоб у вас было всё хорошо? Если нет, то почему вы считаете, что кто-то другой будет решать ваши проблемы? А для решения ваших проблем вам самому всё ж таки придётся что-то знать.
Если у вас руки прямые вон я ссылку дал.
Но количество денег не указали.
А вот если вы хотите присосаться к мегабайтам чужого кода в экосистеме npm, к крутым фичам, которых совсем даже нет в голом JS, и еще много к чему — вот тогда извините, но да, вам придётся в этом всем хотя бы немного ориентироваться, чтоб оно у вас было «нормально», а не как живописуется в статье.
Еще раз намекну что в других языках, даже в php этого нет. А вот в js и npm есть. И да большинство говорящих делай "нормально" забывают рассказать где почитать как нормально и даже банально дать ссылок на почитать. Или мне обязательно надо самому прочитать референс, дальше поизучать как там минифицируется поразматывать кучу всего и только потом делать "нормально". Мне кажется в какой-то момент мы свернули не туда.
Таки вы уже купили весь npm, чтоб весь этот опен-сорс стал вам что-то должен, например то, чтоб у вас было всё хорошо?
Лол. Теперь вопросы воспринимаются как будто мне должны. Вы вот сами скажите, считаете что та помойка что наблюдается в npm это нормально? Как бы проблеме не один год, а воз и ныне там.
Но количество денег не указали.
Так и запишем, как "нормально" делать мы вам не расскажем это тайные знания. А потом они вопрошают почему люди не делают "нормально".
Еще раз намекну что в других языках, даже в php этого нет.
Так и в js этого нет. Компренде?
Это появляется, когда вы начинаете использовать чужой код, и чем больше вы его используете, тем больше шансов словить разные интересные эффекты. Для php этот принцип тоже отлично работает — были у меня знакомые пхписты, рассказывавшие всякие интересные истории.
И да большинство говорящих делай «нормально» забывают рассказать где почитать как нормально и даже банально дать ссылок на почитать.
Так вы не задаете конкретных вопросов и не приходите с конкретными проблемами. Я не могу сказать вам, что почитать по проблеме «у меня всё плохо», уж извините.
Вы вот сами скажите, считаете что та помойка что наблюдается в npm это нормально?
Да. Более того, я уверен, что любая опенсорс-экосистема неизбежно превращается в помойку с ростом популярности и эволюцией технологий. Вы вот помойку компонентов дельфи видели в годы её расцвета? Я видел.
Так и запишем, как «нормально» делать мы вам не расскажем это тайные знания.
Я вам рассказал еще в позапрошлом посте. Решением проблемы «кривые пакеты не минифицируются правильно» является настройка правил или исключений минификации конкретно для этих пакетов. Или вам нужны инструкции в стиле «для бабушек», в какую конкретно часть экрана ткнуть и на какие кнопки на клавиатуре нажать? Нет уж, это сами.
Это появляется, когда вы начинаете использовать чужой код, и чем больше вы его используете, тем больше шансов словить разные интересные эффекты. Для php этот принцип тоже отлично работает — были у меня знакомые пхписты, рассказывавшие всякие интересные истории.
В php раньше было хуже не спорю. Но сейчас есть compositor
Так вы не задаете конкретных вопросов и не приходите с конкретными проблемами. Я не могу сказать вам, что почитать по проблеме «у меня всё плохо», уж извините.
Я конкретный пример привел. И там вполне конкретная проблема нет?
Я вам рассказал еще в позапрошлом посте. Решением проблемы «кривые пакеты не минифицируются правильно» является настройка правил или исключений минификации конкретно для этих пакетов. Или вам нужны инструкции.
Мне нужен банальный пример. Или где посмотреть это. Я вот смотрел конечно знаете ли сидеть и разматывать и изучать 100500 минификаторов не очень прикольно. А рассказывать я вам дал референс. Ну я тоже могу дать референс.
Я вот смотрел конечно знаете ли сидеть и разматывать и изучать 100500 минификаторов не очень прикольно.
У вас есть конкретная ситуация, выливающаяся в конкретные сообщения об ошибках (когда минифицированный код сломается), почему вы не изучаете её, а пишете про «100500 минификаторов»?
Вы каким конкретно пользовались? Вот его и изучайте. Нет в нем возможности сконфигурировать исключения? Возьмите другой. Есть? Настройте. Минификатор по умолчанию делает что-то небезопасное над кодом? Отключите. И так далее.
Что за отношение «не хочу ничего знать, у меня лапки»?
К примеру потому что про нормальную по вашим словам настройку, про ту самую нормально делай нормально будет нет внятного мануала. Ни для одного минификатора. Есть только референс и начальные туториалы делай так и все. Вот вам начальный туториал, смотрите как клево и вот вам референс. Думаю мне не надо рассказывать что между простым туториалом и референсом пропасть?
Из этого и рождается ваш js уг и компиляция идет медленно. Этому же еще способствует и инфраструктура и настройки по умолчанию и общая культура кода в npm. Если уж вы знаете как и можете написать нормальный мануал you are welcome. Вполне достаточно будет просто описать самые часто встречаемые случаи и как их лучше решать. Такой сборник рецептов. Если знаете сборники рецептов можно просто ими поделиться.
А говорить делай нормально и я умею.
К примеру потому что про нормальную по вашим словам настройку, про ту самую нормально делай нормально будет нет внятного мануала.
Вы это всерьез пишете? Или это уже троллинг, или что-то из серии «сам не слушал, Рабинович напел»?
Нет это не троллинг. Это именно проблема. Ну вот вы мне дали reference. Дальше я беру ставлю, собирается медленно как у автора. Какие мои дальше действия? Давайте откроем документацию и посмотрим. А там про это ничего не говорится.
Я максимум могу подозревать что надо запустить с флагом --timings а потом смотреть каждую подозрительную либу почему же медленно да?
У меня есть обе проблемы. Если уж интересно. И да про второй случай там так же особо ничего не написано. Как и то как найти эту проблему и на каком модуле это происходит.
По поводу тормозов — сколько кода у вас в проекте вашего и внешнего? Сколько файлов? Какой размер получается в итоге? Что еще (помимо минификации) выполняется при билде? Сколько времени и ресурсов занимает каждый шаг билда по отдельности?
Хотите что-то улучшить — диагностируйте, выясните, что конкретно у вас происходит, и в какой момент всё плохо (и плохо ли это, может быть у вас размер кода такой, что оно нормально).
Сколько времени и ресурсов занимает каждый шаг билда по отдельности?
И тут возникает вопрос как это смотреть и диагностировать. Ручками ходить по node_modules?
И тут возникает вопрос как это смотреть и диагностировать.
Эм. Билд-то ваш, а не чей-то. Выполнить каждый шаг билда по отдельности, померить время?
Вопрос про инструменты. Я вот смотрел в эту сторону и вижу только ручками разве что ковыряться. А это не сказать что быстро.
По-другому — только тогда, когда вы инструменты покупаете, а совсем по-другому — когда ежемесячно платите за выделенную техподдержку. Вот тогда ради вас если уж и не расшибутся, то по крайней мере пойдут отрабатывать ваши инциденты, а не скажут «сам вкуривай».
И теперь мы возвращаемся к делай "нормально". По этому и не делают. Потому что банально нельзя просто посмотреть почему и надо разматывать весь node_modules. И рекомендаций кроме запускай 100500 раз и ковыряй в ручную модули никаких нет.
Зато каждый раз рассказать нормально делай могут да. А когда реальная критика доезжает до указания проблем, дискуссия уезжает в это "opensource" вам тут никто ничего не обязан.
Штош больше вопросов не имею :)
Потому что банально нельзя просто посмотреть почему и надо разматывать весь node_modules.
Можно, но это ж надо смотреть (соответствующими инструментами, анализаторами сборки, подробными логами билдов, и так далее), а не ныть на хабре. Первое — сложно, второе — просто. Вот и не делают. Сложно.
И рекомендаций кроме запускай 100500 раз и ковыряй в ручную модули никаких нет.
Я вам предложил список действий к проблеме «билдится долго». Беда в том, что он вам опять не нравится, т.к. опять надо идти разбираться с этим самому, а не то, что вдруг приедет Санта-Клаус и сделает хорошо.
Конечно, я мог бы посмотреть в ваш код и предложить чуть менее общие слова, но т.к. принцип «писать на хабре просто, а вкуривать код сложно» работает и для меня тоже — то не буду. Вам отвечать я могу параллельно с присутствием на совещаниях и разбором входящей почты, например, а вот в код смотреть — уже нет, это куда более затратное занятие.
Штош больше вопросов не имею :)
Опять Санта-Клаус не пришел?
Можно, но это ж надо смотреть (соответствующими инструментами, анализаторами сборки, подробными логами билдов, и так далее),
Я вообще-то про инструменты и спрашивал. На что вы мне же говорите да ручками. Какая-то не стыковочка.
Мне нужны инструменты. А не пространные заявления посмотрите там. Внимательно прочитайте мои вопросы. Вопросы просты. За все это время ни одной ссылки ни на анализатор сборок и подобных инструментов нет. Я делаю вывод что их тупо нет и все ковыряются руками.
Более того никаких мануалов внятных не гуглится. Тут или я не так задаю ключевые слова либо это просто никто не делает и не описывает, а только говорит "нормально" делай.
Так что будут ссылки на какие нибудь анализаторы?
Я вообще-то про инструменты и спрашивал. На что вы мне же говорите да ручками. Какая-то не стыковочка.
Ничего подобного — инструменты скорее всего есть, а вот разбираться вам придётся «ручками».
За все это время ни одной ссылки ни на анализатор сборок и подобных инструментов нет. Я делаю вывод что их тупо нет и все ковыряются руками.
Какие вы ожидаете ссылки, если вы не приходите с полной технической информацией о вашем билде? Анализаторы для разных билд-инструментов тоже разные (внезапно). Гугл их все знает, к слову.
Это уже не говоря про то, что вообще такой диалог напоминает классическое «а если я скажу из окна прыгнуть — вы прыгнете?». Вас не забанили же в гугле, нет?
Более того никаких мануалов внятных не гуглится. Тут или я не так задаю ключевые слова либо это просто никто не делает и не описывает, а только говорит «нормально» делай.
Ага, и при этом вы приходите, говорите «у меня всё плохо», и ждете конкретных указаний и ссылок. Хотите конкретики — приходите со своей конкретикой, а не с «у меня всё не работает и вообще медленно». Почему вы считаете, что вы можете ожидать на хабре конкретики в ответ претензии, которые на stackoverflow вообще бы молча закрыли? Телепаты и на хабре тоже в отпуске.
Я не вижу ни одной ссылки. В гугл и я мигу отправить. У меня webpack стандартный какой анализатор смотреть? Раз уж конкретно надо.
Отлично! А теперь расскажите какой из них вы пользовались.
Еще раз намекну что в других языках, даже в php этого нет.
Ну начнем с того что PHP — это серверный язык. Никто серверные проекты для ноды, написанные на JS, не собирает и уж точно не минифицирует. Минификация — это чисто фронтовая вещь. Максимум вам может транспиляция потребоваться для поддержки неутвержденных возможностей языка. Ну так на PHP Вы просто не сможете использовать неутвержденные возможности языка.
Продолжить можно, упоминавшейся здесь Java. Где проекты, написанные на Java 8 почему-то не работают на Java 6, если им просто установить target=1.6, и точно также требуют различных костылей для сборки под старые Android.
Ещё можно вспомнить про несовместимость C++ библиотек, собранных разными версиями компилятора.
Никто серверные проекты для ноды, написанные на JS, не собирает и уж точно не минифицирует. Минификация — это чисто фронтовая вещь.
Ага и в итоге приложение которое я выше привел которое перекладывает байты из com порта в mqtt транспорт даже после tree shaking занимает 76 мегабайт. А если его попробовать минимифицировать занимает 1.2 мега но перестает работать. Или вы мне хотите сказать что на серверах места же много? Ну как сказать не везде. И сам интерпретатор ноды весит вообщето в переделах 50. Почему мне вот критичен такой размер я уже рассказывал, но повторюсь, мне к примеру надо запихнуть его на arm машину где 128мегабайт флеша под систему.
В java такой вот ерунды нет. Там проект после сборки не требует тащить за собой все либы которые ставились для разработки.
Никто серверные проекты для ноды, написанные на JS, не собирает
Я собираю. В результате получается один небольшой быстро запускаемый js-ник, а не 100500 ненужных файлов, более 9000 из которых приходится загружать при старте.
Минификация — это чисто фронтовая вещь.
Она и на фронте не особо нужна.
Максимум вам может транспиляция потребоваться для поддержки неутвержденных возможностей языка.
И для статической типизации.
и точно также требуют различных костылей для сборки под старые Android.
Потому что на Android нету Java. У Java есть набор правил, которым необходимо следовать, иначе она не работает, и Android их нарушает. Это — одна из причин их суда с создателями Java, ни много ни мало. В общем случае, библиотеки, написанные на Java, вообще не обязаны запускаться на Android.
Безотносительно сборки intelisense на тайпскриптовом проекте работает в разы медленнее того же c# и часто вообще не работает. Можно просто сравнить удобство работы в Rider над C# кодом и Typescript в Webstorm — одни и те же создатели, и такой разный user expirience.
Я на самом деле не холивара ради, ну реально работать феерически неудобно. Я допускаю, что я делаю что-то не так. Но на беке всё работает быстро и удобно из коробки — с фронтом постоянные анальные боли. Был бы очень востребован цикл статей «как работать с фронтендом без боли» или «повышаем удобство разработки на фронтенде»
Если взять i7 и xeon одного поколения и там будут только вычисления без дикого использования памяти, разница может быть 15-20% в пользу ноутбучного i7. Не скажу, что делал всеобъемлющее тестирование, но подобные результаты на разном коде в разные года наблюдал.
Могу предположить, что проблема кроется в браузерах. По их вине фронт это JS, который не приспособлен для сложный проектов из коробки. Если бы у вас фронт был такой, каким JS задумывали — вы бы просто открыли HTML+JS файлик в браузере и увидели результат (вопрос о быстродействии браузера это отдельная тема, вот например).
Тут же происходит натягивание совы на глобус в виде транспайлинга тайпскрипта в JS, статических чеков, компиляции стилей, линковки горы библиотек (для которых происходит почти то же самое, так как они в исходниках), минификации и прочей вакханалии.
Так что не стоит винить фронтэндеров в том, что они не умеют в кодинг. Если бы ваш бэк ограничили только перфокартами я бы посмотрел на время сборки проекта в 1000 строк.
Совсем нет. То, что автор использовал для попытки разжечь холивар, и то, что вы называете "проблемой" — всего лишь запросы пользователей. Вы же отправили этот комментарий в браузере. И я. И автор. Мы все тут используем инструмент, называемый "Хабр" и сделанный на обсуждаемых технологиях. При этом почему-то никому не приходит в голову расстраиваться, что у нас вместо летающих досок из "Назад в будущее" есть максимум электрические самокаты на колёсиках, дрыгающиеся на каждом камушке. Это не проблема, просто вода течёт вниз, а масло — масляное.
Впрочем если вы, уважаемый читатель (я не имею ввиду вас, atamur, я про сферического читателя в вакууме), являетесь непризнанным гением, который знает то, что другим неизвестно, и покажет всем новый мир, свободный от предрассудков и от выученной беспомощности, то тем же лучше для вас — тогда вы будущий миллиардер (если вам повезёт монетизировать вашу уверенность). И как бонус — вы ещё и Прометей, который принесёт людям свет знаний, свергнув сегодняшний ужасный фронтенд в пучину забвения.
Вот только производители браузеров по какой-то причине не хотят сделать нормальные нативные DOM-примитивы, которые позволяли бы не заниматься разного рода извращениями, а писать простой и понятный код, сдабривая его CSS-оформлением. Приведу только один пример, близкий мне. Вот почему для DOM-элемента table нет реализации горизонтальной и вертикальной прокрутки таблицы, размеры которой превышают заданный прямоугольник? Лично мне не понятно.
Ладно раньше, когда Microsoft козлячил, пытаясь двигать свои стандарты поперек сообщества. Но сегодня-то что мешает? Отсюда и разного рода извращения, по разному реализованные у Google, Microsoft и других разработчиков, чтобы реализовать ту же таблицу, которую в Java 1.1 более 20 лет назад можно было сделать с нуля за неделю, а затем использовать в Java-апплетах.
Ну ладно корпорации, которым выгодно создавать на пустом месте рынки сбыта для своей продукции. Но вот почему эта тема не звучит в профессиональном сообществе? Предлагаю поднять этот вопрос на площадке Хабра.
Вот только производители браузеров по какой-то причине не хотят сделать нормальные нативные DOM-примитивы, которые позволяли бы не заниматься разного рода извращениями, а писать простой и понятный код, сдабривая его CSS-оформлением
Вам не кажется забавным читать вперемежку обсуждения про то, что браузеры настолько сложные, что впору говорить о технической монополии, и про то, что разработчики браузеров козлячат и извращаются вместо того, чтобы просто взять и сделать простейшие вещи красиво (и обязательно так, как хочется автору)?
Для начала это будет браузер, ориентированный на корпоративных клиентов, позволяющий писать легкие и быстрые SPA на JS в ООП-стиле без всякого рода прокладок в виде фреймворков. Затем через некоторое время для этого браузера будет реализован веб-офис (почта, текстовый редактор, электронная таблица), который будет не ползать, а летать. Ну а дальше начнется экспансия этого браузера в попсовый интернет, может медленная, а может и взрывная.
легкие и быстрые SPA на JS в ООП-стиле без всякого рода прокладок в виде фреймворковДопустим да, можно сваять свой маленький и лёгкий DSL, чтобы делать нишевые приложения с шахматами и поэтессами. А экспансия будет тоже без прокладок и костылей?
Беглый поиск не показал, что есть какие-либо полифилы для поддержки XUL в других браузерах. Значит вы можете приблизить светлое будущее, занявшись этим :)
1. Для элемента table сделать горизонтальную и вертикальную прокрутку, при этом чтобы элементы td не прокручивались, а лишь менялось содержимое данных таблицы, чтобы можно было делать большие таблицы без просадов по памяти.
2. Сделать нормальные компоновщики в виде html-элементов вместо CSS-костылей в виде Flexbox Layout и Grid Layout.
3. Сделать дочерние окна, в том числе вызываемые alert, prompt и confirm, в виде компонента типа div, для которого можно настраивать содержимое штатным образом и устанавливать режим модальности.
4. Реализовать примитивы типа меню, различных табов и т.д., чтобы не сочинять их каждый раз, а только настраивать их внешний вид средствами CSS.
Это то, что сразу приходит на ум, когда сравниваешь создание интерфейсов на Java и JavaScript. И еще раз подчеркну, речь идет о приложениях типа Excel и 1С, которые востребованы именно в корпоративном секторе.
- position: sticky
- <table>
- <dialog>
- role="tablist" и тд
Речь не идет ни о каких DSL, а только о повышении функциональности существующих DOM-элементов, чтобы ими можно было легко управлять средствами JS. Например:
Есть подозрение, что для этого вам не надо ничего изобретать, надо всего лишь отправиться в ближайшее прошлое на пару десятков лет назад. В прошлое — потому что «этого» уже не существует, «это» уже выпилено из FF, как оказалось. Я про XUL.
Вот например вам табы: Табы, там рядом найдёте много всего интересного, в том числе все ваши 4 пункта. И вот это вот всё было готово к использованию, работало вместе с привычными addEventListener() и стилизовалось через css. Но для целей, о которых вы говорите, особой стилизации и не надо.
Спустя 20 лет это может показаться куцым, но на тот момент это был очень богатый набор возможностей. Почему же не взлетело?
Например, возьмем модули Flexbox Layout и Grid Layout, в которых по какой-то странной причине управление размещением компонентов определено на уровне CSS, а не на уровне HTML. В результате из JS-кода приходится работать не напрямую с DOM, а генерить кучу лишнего кода для работы с CSS-файлами, так как из JS кода нет доступа к модели данных CSS, а это означает периодическое обращение к медленному диску, пусть даже и SSD.
Так вот, теоретически в дополнение к компоновке на уровне CSS можно сделать реализацию компоновки на уровне HTML, чтобы работать из JS напрямую с контейнерами, которые бы автоматически меняли все размеры при добавлении компонентов в ту или иную область. Чтобы просто писать теги
<flex-layout>...</flex-layout><div class="flex-layout">...</div>flex-layout { display: flex;}В общем идея применительно к данному модулю заключается в том, чтобы переместить из CSS в HTML любой функционал, который определяет не внешний вид, а поведение отдельных компонентов страницы. Ну а для совместимости оставить функционал в CSS, который будет работать не напрямую с движком браузера, а через DOM-моделью.
Теоретически, если будет много подобных запросов, то фича будет реализована.
Хотелось бы иметь возможность скрывать таких авторов не только в "Моей ленте", но и в ленте "Все потоки".
Если Вам нужна избранность потоков, то для этого существует настраиваемая «моя лента».
Впрочем, каждый может предложить свою идею в форме фидбека, в комментариях под АМА или где-то еще. Включая идею по фильтрации «всех потоков». Если оно действительно нужно и полезно, а не просто «хотелось бы», то для реализации следует приложить какие-то усилия, а не просто жаловаться на несовершенство мира в первом попавшемся месте. Сделайте, хотя бы, первый шаг.
Спасибо, товарищ воспитатель.
Я часто списываюсь с поддержкой Хабра.
Оставайтесь на линии, ваша язвительность очень важна для нас.
Я же ответил взволнованному товарищу, который зашёл в класс с плохим настроением и стал воспитывать, кому тут какие первые шаги делать надо. ))
P.S. Что вдвойне примечательно, так это то, что у комментатора выше, ведущего беседу в такой довольно негативной интонации, в Профиле заявлены ссылки на Хабраэтикет и на "Неочевидные правила спора".
— Напишите в саппорт.
— Хотелось бы сделать…
— Напишите же.
— Не язвите.
Воспитательность, язвительность, взволнованность, плохое настроение, довольно негативная интонация — это то, что Вы увидели в моих словах, а не то, что я в свои слова вкладывал. Соответственно, Хабраэтикет и правила споров тут не помогут. Предлагаю отвлечься от фантазий о собеседнике и вернуться к затронутой теме.
Я часто списываюсь с поддержкой Хабра.И что они Вам ответили на Ваше предложение ввести фильтр по авторам во всех лентах?
С другой стороны, на разнообразных ресурсах обычно чёрный список учитывается для лент со всем разом. Если вы кого-то заблокировали — вы не хотите его видеть никогда.
Но 20к просмотров же есть)
Это мой первый и последний комментарий под статьями данного автора, вне зависимости от того, насколько меня трогает тема.
И вам того же желаю. Только лишь забвение будет наказанием этому хайпожору.
Вспомнилось
p.s.
Единственный нормальный корпоративный блог. Хотя бы что-то интересное пишут за свои деньги.
У меня ноутбук куплен за 36 т.р. в начале года. Добавлено оперативки до 8 гб. Проекты по типу такого как описывает автор собираются ну пару минут максимум в продакшн режиме. Дев стартует за минуту, а потом в процессе работы HMR работает почти мгновенно. ЧЯДНТ?
Yarn почему-то никто не упомянул. И не предложил выкинуть вскод. Не умеете вы холиварить)
Ждём green code у фронтендеров
Но чертов веб везде, куда ни сунься.
Не понимаю, как люди могут фанатеть от этих убогих технологий.
Я потому и выбрал мобайл
А там/тут теперь тоже "тонкие клиенты", открывающие всё приложение из веб-бандла в системном WebView. Нет сейчас ничего, куда бы оно не просачивалось.
Просто эти люди не видели нормальных технологий и все.
RS-485, 300 бод, сишечка, 8051, вот это вот всё.
Может это и неплохой подход — зачем лишний раз писать кеш на диск, если есть память постоянно запущенного процесса. Но это раздражает, когда нужно быстро переключится на проект и исправить одну строчку. Каждый раз ощущение, что люди писавшие это никогда в глаза не видели нормальных компиляторов. Но видимо это такая вот архитектура.
Поправьте, если я не прав.
Там проблема в том что далеко не все хотрелоадися.
Это потому, что никто пока не осилил писать промежуточные результаты на диск нормально. Инкрементальная компиляция есть, но только в памяти. Да, есть потенциально глючные левые плагины к вебпаку, есть встроенный механизм у TypeScript. Но все это припарки, а не решение.
Думаю основная проблема в том, что на фронте нет единого формата модулей. Теоретически, не вижу проблем сделать так, чтобы компиляция бы чисто склеивала уже минифицированные кусочки. Но пока — не вышло договориться даже как CSS положить в модуль. Это я даже не вспоминаю про SCSS — который ставит себе компилятор сишки и весь тулинг, и натурально себя компилит после инсталляции — примерно такого уровня в NPM бардак.
Вообще-то есть b компилятор SCSS написанный на JS. Не вижу особого смысла использовать сишный биндинг.
Одни делают кривые инструменты, другие колются, но продолжают есть кактус. Фронтенд такой фронтенд.
Простите, но что страшного в настройке вебпака руками? Можно даже не с нуля настраивать, а взять за основу тот конфиг, который был создан CRA.
Я приглядываю за 10-ком проектов по 2-3 фронта — там такое не отбивается
Дык один и тот же конфиг вебпака можно из проекта в проект копировать. Так что связь прямо обратная: чем больше у вас проектов, тем выгоднее по-ковыряться с вебпаком.
Чтобы понять насколько ад — достаточно посмотреть сколько льют в CRA, и в его исходники.
Ну, или несколько раз обновить все зависимости. Когда какой-нибудь там вебпак меняет то, как ему в закидываются параметры, и ты исследуешь креш с undefined. Или там какие-нибудь там версии чего-нибудь совместимы с одними версиями вебпака, а что-нибудь еще не обновили пока. Короче утомляет. При том, что умение готовить вебпак — это уже такой специальный скилл, которого ни у кого еще в команде может и не быть, и ты оказываешься в ситуации типа «либо ты фигачишь, а другие важные дела стоят, либо простаивают команды — потому что загадочны креш на билде».
Короче нет, больше не буду, и никому другому не советую.
Вводя рекурсивные типы авторы тайпскрипта открыли ящик пандоры. Теперь в пару строк можно запросто подвесить вывод типов на 5 секунд и выжрать всю память. И диагностировать это нормальных средств нет. Кроме того, тайпскрипт не умеет толком кешировать промежуточную работу на диск, а это значит, что запуск не в режиме наблюдения приводит к куче лишней работы.
Всё поломать неожиданным способом вообще можно абсолютно всегда. А если вы считаете что нельзя — скорее всего вам не хватает фантазии.
Кроме того, тайпскрипт не умеет толком кешировать промежуточную работу на диск
Тайпскрипт уже умеет в инкрементальные билды с сохранением информации на диск. Правда, это пока всё еще не безпроблемно — может вести к ложноотрицательным прохождениям билда при определенных правках кода (инкрементальный билд проходит, а полный падает).
У меня свой сборщик, который не надо постоянно конфигурировать.
Инкрементальные билды в тайпскрипте — это про проекты, а не не модули. В рамках проекта — никакой инкрементальности.
Инкрементальные билды в тайпскрипте — это про проекты, а не не модули. В рамках проекта — никакой инкрементальности.
Да что вы говорите, неужели. И в tsbuildinfo вы наверное не заглядывали, чтоб увидеть, что ускорение как раз достигается из-за того, что оно «про модули»?
У меня на проекте бек билдится до 15 минут и это монолит, а еще есть пачка микросервисов. Фронт, в который в ходит 10+ репортов — за минуту-две. Нельзя же так вбрасывать без конкретного примера.
А если еще вспомнить про тесты на пр… Час времени на пр, и угадайте какие тесты пробегают за пару минут?))
Впрочем, хочу заметить, что написанный на гребаном джаваскрипте Apex Language Server в VsCode ощутимо тормозит с автокомплитом при редактировании класса в 4000 строк.
Конечно, можно было бы взять вместо вскода идею или вебшторм, которые не хуже умеют жрать процессор и память, но поскольку они на яве, это противоречит условию задачи — костерить жс-тулинг.
Вариант, что дело в прямизне рук автора, которые не в состоянии справиться с созданием вменяемого проекта с 4 формочками, рассматривается? Если это не компетенция автора, а проект чужой, то возможно, стоило бы направить конструктивную критику ту в сторону… но опять же, это противоречит условию задачи.
И, конечно, если костерить предметно, то речь зашла бы про
Но по факту статья про то, что автор вместо эффективного рабочего инструмента купил золотой унитаз за три миллиона монгольских тугриков. Потому что разработчик не обязан уметь в конфигурацию железа. И в разработку, между прочим, тоже.
Возьмем обратную ситуацию, неужели неразбирающийся в бэке кодер не может сделать что-то, что будет чудовищно долго работать/жрать память/билдиться? Там нельзя себе в ногу выстрелить? Что, из-за этого мы будем весь бэкенд мир проклинать?
Если фронтенд такой ужасный, то юзай чистый html, там ничего билдить не надо.
Между тем, на VanillaJS всё прекрасно пишется. А на «просто реакте» пишется проще и с меньшим количеством собственного кода. Беда в том, что люди почему-то думают, что это линейный тренд, и что если одна либа всё здорово упрощает, то 100500 либ упростят всё в 100500 раз больше.
Приведенные выше примеры фреймворков необоснованно усложняют процесс разработки — суть моего аргумента.
Угу, а пользуются ими только потому, что всем вокруг нравится страдать, да и вообще в программисты одних только хардкорных мазохистов берут.
Нет, фреймворки очень даже значимо упрощают разработку. Что никак не отменяет возможности пользоваться ими не по назначению, и самому себе подкладывать грабли.
Ну и на самом деле по-моему никто вообще в мейнстримовых сборщиках не боролся толком за скорость сборки. Тот же rollup боролся за понятность и детерминированность процесса сборки, относительно мутности вебпака, да за вменяемую модульность. А скорости в приоритетах и не стояло.
Пятнадцать лет назад на включение компьютера, открытие письма в электронной почте и распечатывание документа уходило пять минут.
Сейчас столько же. Несмотря на повышенные в сотни раз производительность процессора и объемы памяти.
А что изменилось?
Пятнадцать лет назад на включение компьютера, открытие письма в электронной почте и распечатывание документа уходило пять минут.С этой задачей отлично телефон справится. Он у меня включён постоянно. А у вас? Причём идти по офису до принтера будет дольше, чем достать телефон, зайти в почту и отправить на печать.
Я думаю придет время когда всех jsников будут отлавливать на законодательном уровне.
Смотрю на сборку Java-бекенда, которая гоняет какие-то тесты по 45 минут, а потом на React-фронтенд, где 1200 тестов пробегают за 20 секунд, и задаюсь тем же вопросом, что и автор статьи, только с противоположным знаком.
А на фронте обычные юнит неизвестно что проверяющие.
Интеграционные тесты с вебдрайвером живут отдельно и в эту цифру не входят. Тут сравниваются именно локальные тесты. Строчек кода и сложности и в беке и во фронте примерно одинаково, так что чего там так долго проверять – решительно непонятно.
За фронтенд могу поручиться – тесты падают при наличии багов и проходят при их исправлении. Нормальные тесты, полезные.
Подведем промежуточный итог:
- Долго собирается фронтенд – виноваты криворукие разработчики
- Долго собирается бекенд – все нормально, это интеграционные тесты, так и нужно.
После прочтения статьи и комментариев вывод получается именно такой.
Хорошо, вот сборка:
- mvn install -DskipTests=true – 3мин 30сек
- npm run build – 45 сек
Разница не настолько большая, как с тестами, но все равно есть.
У вас одна из ситуаций:
- кривые билд-скрипты на java pom.xml — это проще пареной репы. При небольшом желании можно время компиляции на порядок-два поднять.
- какая-то из интеграций (или просто дурацкий эксперимент кого-то из разрабов) подтянула кодогенерацию. Это долго.
Возможно. А ещё -T 4 из коммента выше может помочь. Важен не конкретный проект, а общее отношение
- Долго собирается бекенд – в комментарии приходят добрые люди и пытаются помочь
- Долго собирается фронтенд – в комментарии приходят (возможно, те же самые люди) и предлагают сжечь этот фронтенд к чертям собачьим
Как в такой ситуации можно хоть что-то обсуждать?
Интеграция бывает не только с вебдрайвером, но и с базой данных. Когда тест (но лучше группа тестов) настраивает себе окружение на живой базе данных, проходит по своим шагам и потом за собой подчищает, чтобы не мешать остальным. При таком подходе у нас 2800+ тестов бегают на моей машине примерно час, а на слабенькой ноде Jenkins могут и четыре.
Вот здесь уже ответил на похожий комментарий
Там уже тоже ответили, что вы разные вещи сравниваете. Четыре часа на Jenkins идёт не билд, там именно идут тесты, очень тяжёлые тесты с точки зрения количества операций.
А так как вам пальцем потыкать хочется — если я ко времени тестов на своей машине (напомню — это примерно один час) добавлю время полного билда с нуля, то получится два часа, где из одного часа на сам билд — 45 минут идёт именно билд фронтэнда. А знаю я это потому что давным-давно у нас билд шёл 15 минут, но потом мы мигрировали с "устаревшей" технологии (где билд фронтенда был синонимом простой конкатенации файлов, занимавшей меньше десяти секунд на всё про всё) на модный технологический стек на jsx, время билда стало плавно увеличиваться по мере добавления компонентов, и в итоге дошло до часа, причём миграция вообще-то не закончилась, то есть и 3 четверти времени билда на компиляцию пары десятков jsx — это ещё не предел. Плюс это ещё TypeScript втащить не успели.
Кстати, юнит-тесты у нас есть и там и там, и они занимают примерно по три секунде и на фронте, и на беке, со сравнимым числом тестом. И вот они-то у нас являются частью билда, но как легко видеть — их влияние на время прохождения близко к статистической погрешности.
Если билд фронтенда идет 45 минут, то это проблема настройки конкретного билда, а не экосистемы в целом. У нас обычный современный стек (React/Typescript/Webpack), 50k строк кода, и собирается это за 45 секунд без каких-то особых хаков.
Может у вас тоже, если по таймстампам посмотреть, на что именно уходят эти 45 минут, получится оптимизировать как следует?
Нет, это всё же проблема экосистемы, если надо даже компиляцию профилировать, анализировать, и тюнить — а иначе система рождает чудовищ.
И всё-таки, для меня лично странно, что вы не называете проблемной систему, в которой основной инструмент для решения задач нуждается в тонкой настройке чтобы только показывать результаты, сравнимые с аналогичными инструментами в соседних системах, а из коробки заточен в основном под демо-проекты на одну страницу кода и Hello World.
Я прекрасно знаю, что профилированием пайплайна сборки фронтенда можно достигнуть приемлемых результатов скорости сборки. У нас как раз кто-нибудь этим займётся, когда более важных задач не останется. Тем не менее, на бекенде у нас никто компилятор не настраивал — уж поверьте, я эти скрипты читал от и до — и он собирает примерно на порядок больше loc в три раза быстрее.
Блин, на мавене тоже можно написать билд-скрипт так, что он в 2-5 раз больше времени будет идти. Вот легко. И я лет 5 назад вдумчиво так над билдом посидел и нашёл способ его ускорить. Имхо в любом билд-скрипте можно наворотить страшного.
Нет, я согласен, в тулчейне фронта накосячить сильно проще… но в то же время надо понимать, что в тулчейне фронтенда нет ни одного инструмента старше 10 лет… даже до 5 лет вроде не доживают. Когда ж им успеть созреть и вылизаться до более-менее вменяемого результата достигаемого легко?
Конечно, если изначально демонизировать ситуацию, что всё сложно и ничего не получится, то скорее всего так и выйдет.
нуждается в тонкой настройке
Не знаю о какой настройке вы говорите, у нас для этого было достаточно трёх вещей
- Не ставить лишних зависимостей непонятно для чего
- Если всё-таки решили установить – читаем документацию, чтобы понять как правильно готовить
- Перед копированием кода со stackoverflow, разбираемся, что именно он делает
С соблюдением этих простых правил всё становится намного лучше, и не только во фронтенде.
Скажем так, для мавена по моему опыту получается раскладка:
~15% способны составить хороший билд-скрипт или улучшить плохой
~70% способны в целом не такой уж плохой скрипт написать… но оптизимировать его в случае каких-либо проблем не могут.
и ~15% пишут его плохо, в результате минимальное время билда увеличивается как минимум в 2 раза.
И это для сравнительно простого мавена. Те тул-чейны, которые я знаю из мира фронта позволяют себе в ногу стрелять сильно легче, так что и распределение ожидаю там худшего.
PS я не демонизирую, что где-то ужас-ужас. Всё же гораздо проще — найти в себе силы (а главное — время) и разобраться с имеющимся билд-тулом… В общем большинству хватает, что их билд скрипты на выходе дают то, что они ожидают. Время билда для них не критично. Сам таким был, пока не пришлось ребилдить аппликуху по 30 раз за час. И там уже полторы минуты билда стали очень больно кусаться. Закопался-разобрался. Удалось пожать до полуминуты. Был "щаслив".
PPS да, заметил, что ответ был не мне только после того, как написал коммент, так что прошу исходить из этого.
И в C++, и в Java, и в обсуждаемом Javascript.
Я знаю историю про ускорение сборки Java проекта административными методами. Есть истории про выпиливание шаблонной магии в плюсом кода с заменой на внешнюю кодогенерацию. Да и разработчики компиляторов наверняка могут что-то рассказать про ускорение процесса компиляции.
Это правда никак не отменяет сам факт ужаса сложности экосистемы Javascript и скорости сборки, когда за дело берется непрофессионал (читайте — не профессиональный фронтэнд-разработчик).
Так у нас, вроде, — профессиональный фронтенд-разработчик этим занимается. Как я понял, это он был главным евангелистом, в коммитах всегда пишет довольно умные вещи, и всё такое. Но имеем что имеем.
ЧЯДНТ что мне не о чем написать такую статью… :(
А как на Хабре заблокировать автора? Чтобы его статьи не было видно ни в анонсах, ни в рекомендуемых, ни в популярных, а главное — они не приходили в рассылке?
Ну так проблема в винде и дотнете. У меня мак на 8 гигов — норм работается.
У нас проект на SSR, c кучей страниц, с кучей форм, с графиками, с вебсокетами, свистелками, перделками.
И он билдится 2-3 минуты.
Автор, покажи свои четыре формы, я прошу.
Дотнет, студия, райдер, плеер, почтовый клиент, FIFA18, проводник, телега. И это все — 20% моей оперативы
Что — то я очень сильно сомневаюсь, что это съедает всего — то 20% от 8 ГБ ОЗУ. Если бы тут не было ФИФА, то тут бы я с великим сомнением, но поверил бы.
Наверное у автора размер package.json чуть меньше, чем каментов к этой статье :)
Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте — полгода