Занимаюсь последнее время как раз этой темой. Автор пишет очень по делу, но только краем затрагивает пару очень важных вопросов: базовую среду микроприложений и общую UI-библиотеку. Почему это важно — потому что собственно загрузчики/оркестраторы довольно абстрактны и делаются на чистом JS/TS, контракты и общая шина (шины) тоже в общем-то проблем не представляют, а вот динамическое монтирование/отмонтирование в случае SPA сразу же ограничивает полёт фантазии…
Но я так понимаю, это связано со спецификой SSR-ориентированной архитектуры у автора. Пойду почитаю, что там внутри.
… а человек, разбирающийся (действительно разбирающийся) в фундаменталке, называется евангелистом и к практической работе его лучше не допускать. Хотя для всяких PoC он реально незаменим.
Думаю, что такие люди, которые твёрдо знают теорию и при этом так же твёрдо _нюансы_ практики, существуют, но я лично с такими не сталкивался. В смысле — сразу в нескольких областях, в узких темах специалистов много. Это ж ещё надо иметь довольно разный склад характера.
Сам я клонюсь то в теорию, то в практику в зависимости от того, что мне сейчас интереснее (повезло, могу себе позволить) и в результате не знаю ни того, ни другого, а мне за это платят =)
Ну, например, VCL, наличие и качество компонентов и удобство RAD. А также разница в скорости билда сибилдера и дельфи — дело было в ранних 2000х, на всякий случай, тогда это было очень-очень заметно. В приципе dll и сервисы писались у нас тогда время от времени и на Delphi, но для кросс-платформенных модулей вариантов, прямо скажем, было немного.
А про класть формочки в dll — лучше не напоминайте, это была одна из моих тем в то время, плагинные системы и динамически подгружаемые формы. Ох, сколько она крови выпила…
И таки таки формошлёпство на дельфи требовало совсем одного тулчейна и набора умений, а разработка слоёв апп-логики и бизнес-логики сильно другого. Даже людей нанимали совсем разных, ровно как во фронте/бэке сейчас.
А, да, пока вспомнил: по моему мнению в нормальном современном энтерпрайз-вебе настоящий фулл таки очень редкая зверюшка. Потому что ну очень накладно знать, например, ангуляр 7 в обвязке (не на уровне туториалов, а понимая, что там внутре за неонка в деталях) и, скажем, цэшарп с дотнетом так же глубоко — и поддерживать эти знания актуальными сколь-нибудь длительный период.
У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.
Да чёрт его знает, у меня уже ощущение, что мы все говорим об одном и том же, но спотыкаемся на терминологии.
Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?
Скорее первое, чем второе. Дельфя для формочек, Ся для .dll и .so. Совсем разные задачи и подходы (не то, чтобы совсем-совсем нельзя было всё сделать на чём-то одном, но это был бы явный изврат ради изврата, а когда апп-сервер на другой ОС, то и вообще. Хотя — и такое я встречал).
1) Почему «или»? «и». Имеет бэк (пул апп-серверов и за ним субд-сервера) и сам является бэком для веб-клиентов (планшетов).
2) Ну так он же бэк для десктоп-клиента, или нет? По роли он практически совпадает с бэком для веба, если на то пошло, только протоколы разные. У меня в практике были даже апп-сервера с подключаемыми логическими модулями на жабаскрипте (wss, самодельные расширения для vb и js) — прям ноджысы какой-то.
И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
Из-за великолепия и экосистемы, очевидно. На мелких/средних проектах весь ангуляровский явный и неявный бойлерплейт и магия декораторов многих отпугивают. Да, писать легко, но держать всю эту экосистему и принципы в голове (если не постоянно) — очень тяжко. На средних/крупных проектах ангуляр = вендор лок, что тоже не очень радует.
Но вот непонятен такой момент как пайпинг. Простая задача: мне нужно в процессе сборки взять определённый файл в сыром виде, до любой обработки, выполнить эту самую некую обработку и отдать его дальше, в watch-mode — то, что в вебпаке реализуется с помощью Rule.use chaining и его внутренней виртуальной файловой системы — кэша, и то, что как минимум до текущей версии CLI было сломано в CLI-плагине.
Проблема (как минимум со связкой webpack 4, typescript, AOT) в том, что AngularCompilerPlugin игнорирует результаты предыдщих лоадеров и берёт оригинальный исходный файл с диска. Я понимаю, что это больше связано с кэшированием проекта tsc, а не ng, но до определённого момента были стандартные хуки, потом можно было написать файл-трансформер, а теперь остались только совсем хакерские методы прямой работы с AST но они не всегда в принципе возможны. Кстати, с актуальностью плагина тоже печальная ситуация.
Есть ощущение, что «обычный» «прямой» вебпак-сборщик теперь вышел из моды и поддерживается по остаточному принципу. Но, может быть, я чего-то не заметил и теперь такой сценарий может быть реализован прямо из CLI?
Да, это приложение из кучи разных бандлов, которые физически собираются и разворачиваются отдельно — то есть, вебпак не сможет сделать нормальный тришейкинг в любом случае — но при этом пользуются общим стеком технологий. Ядро, свои библиотеки, внешние библиотеки и прикладные пакеты.
Спасибо за статью! Явно очень большая работа проделана и много граблей истоптано в процессе. Как человек, много работающий с вебпаком, не могу не оценить.
Я хочу вставить пять копеек насчёт подхода с externals. У меня под рукой есть один проект, где применён такой приём, там сделано таким образом:
2. В самом webpack.config.js до собственно конфига довольно тривиальный код, который из этой структуры
— делает собственно объект для поля externals
— готовит список файлов для HTML/Webpack DefinePlugin (используется свой загрузчик ассетов, с фолбэком и излишествами)
— копирует каждый целевой файл для текущего окружения в output.
— ну и ещё пара трюков, которые проверяют, нет ли уже такого файла в месте назначения чтобы не делать лишней работы и быстрая грубая проверка через lstat совпадают ли размеры файла с источником на предмет «а вдруг с прошлого билда поменялась версия или переключили прод на дев».
Это позволяет не париться с отслеживанием консистентности. Хотя сам подход, конечно, достаточно специфичен и нужно чётко понимать, когда есть смысл им пользоваться…
С этим я тоже согласен, практическая применимость такой функции сомнительна. Я больше на тему «хорошо бы знать, как создаются объекты и в чём может вылезти разница» — вот это сеньору неплохо бы понимать.
По мне, если соискатель ответит на вопрос «нет ли подвоха в этой функции», даже без примера, то это прекрасно.
Довольно спорно… эта логика невизуальная? Она должна жить в отдельном сервисе без привязки к компоненту. Асинхронная? Имеем события, подписки или какой другой стандартный путь для оповещений. Причём скорее всего даже вообще не-реакт, а чистый js/ts, переиспользуй-не хочу. RxJs, pub/sub, Redux…
Лично у меня ощущения от использования хуков — «как бы получить возможности классовых компонентов и „взрослой“* архитектуры и при этом поменьше вникать в эту самую архитектуру». Не знаю, как по мне рано или поздно всё равно придётся разбираться, только наворочено к этому моменту будет больше и рефакторить придётся тоже больше.
* взрослой = явное управление стейтом и потоками, разделение ответственности, DI, прочий далеко не всем нужный хлам.
Можно и так воспринимать. Если устраивает модель работы ангуляржс, его производительность и ограничения — почему бы и нет? Народ и на jQuery пишет, и на ванилле… вопрос в цене оверхеда (поддержка, багфикс, актуализация, люди) для вас. Может, у вас на рынке полно недорогих ангулярщиков или проект меняется раз в два года — случаи разные бывают.
У ангуляражс по крайней мере очень низкий порог вхождения. В первых десяти процентах кривой =)
Это тут при чём? Я говорю о ситуации, когда нужно обосновать использование замороженой технологии с известными уязвимостями в чувствительном секторе. То, что она 99% рабочая и будет рабочая ещё долго в некоторых случаях вообще не аргумент, потому что менеджмент сразу спрашивает «что будет с платформой через пять лет? как быстро будут устраняться баги? можете ли вы пообещать, что?..»
Из официальных источников. Это LTS, но новых фич не будет, только секьюрити патчи и малоприоритетный багфиксинг. Всем спасибо, всех ждём в новом ангуляре.
Кстати, если посмотреть на топ-100 ангуляр-приложений, то очень много из них были и остаются на ангуляржс и никогда не будут переписаны на ангуляр 2+. А вот для финансового сектора, например, поддержка актуальности стека — критична.
Так а при чём тут реакт? Компонентная модель у него вполне хороша, а что при росте числа связей сложность системы растёт экспоненциально, так это проблема не реакта, а прикладной архитектуры. Для этого придумано много всякого — MVC, MVVM, Reactive streams, управление стейтом…
Компонентная модель здесь вообще никаким боком. Ну разве что можно притянуть, что простой пропагацией пропсов можно обойтись в несложных случаях — но если автор сам себе злобный буратино и не озаботился более серьёзным механизмом контроля потока данных и потока управления при росте сложности, то с тем же успехом можно и прямо на жабаскрипт пенять.
В реакте — снова скажу — что хорошо и плохо сразу так это что задачу можно решить несколькими способами. По уровню хаоса он где-то между ангуляржс и ангуляром: двустороннего байндинга уже нет, но данные можно гонять практически как бог на душу положит. С другой стороны, это совсем не его задача и для этого есть совсем другие инструменты.
мне очень нравится AngularJS. Я слышал про него много плохих общих слов, но мало конкретных минусов, да и те, что называются имеют +\- адекватные решения даже при масштабировании сервиса.
Не всегда, есть в приципе нерешаемые проблемы, но главное для энтерпрайза — он снят с поддержки. Тут даже не в самом ангуляре затык, а в обвязке: jQuery, UI Bootstrap, прочие зависимости, некоторые из которых могут быть заброшены, а некоторые не иметь соместимых комбинаций. Другими словами, устаревающий неподдерживаемый стек. Другие чисто технические вопросы да, как правило можно или решить, или обойти, почти все, но и этого достаточно.
Мелким или короткоживущим, или неразвивающимся проектам может быть и пофигу — на несколько лет ещё хватит.
PS ангуляр 2+ ушёл вообще не туда, по моему скромному мнению. Слишком шарахнулся в противоположную сторону, обжёгшись на первом.
Но я так понимаю, это связано со спецификой SSR-ориентированной архитектуры у автора. Пойду почитаю, что там внутри.
Думаю, что такие люди, которые твёрдо знают теорию и при этом так же твёрдо _нюансы_ практики, существуют, но я лично с такими не сталкивался. В смысле — сразу в нескольких областях, в узких темах специалистов много. Это ж ещё надо иметь довольно разный склад характера.
Сам я клонюсь то в теорию, то в практику в зависимости от того, что мне сейчас интереснее (повезло, могу себе позволить) и в результате не знаю ни того, ни другого, а мне за это платят =)
А про класть формочки в dll — лучше не напоминайте, это была одна из моих тем в то время, плагинные системы и динамически подгружаемые формы. Ох, сколько она крови выпила…
И таки таки формошлёпство на дельфи требовало совсем одного тулчейна и набора умений, а разработка слоёв апп-логики и бизнес-логики сильно другого. Даже людей нанимали совсем разных, ровно как во фронте/бэке сейчас.
А, да, пока вспомнил: по моему мнению в нормальном современном энтерпрайз-вебе настоящий фулл таки очень редкая зверюшка. Потому что ну очень накладно знать, например, ангуляр 7 в обвязке (не на уровне туториалов, а понимая, что там внутре за неонка в деталях) и, скажем, цэшарп с дотнетом так же глубоко — и поддерживать эти знания актуальными сколь-нибудь длительный период.
Да чёрт его знает, у меня уже ощущение, что мы все говорим об одном и том же, но спотыкаемся на терминологии.
Скорее первое, чем второе. Дельфя для формочек, Ся для .dll и .so. Совсем разные задачи и подходы (не то, чтобы совсем-совсем нельзя было всё сделать на чём-то одном, но это был бы явный изврат ради изврата, а когда апп-сервер на другой ОС, то и вообще. Хотя — и такое я встречал).
2) Ну так он же бэк для десктоп-клиента, или нет? По роли он практически совпадает с бэком для веба, если на то пошло, только протоколы разные. У меня в практике были даже апп-сервера с подключаемыми логическими модулями на жабаскрипте (wss, самодельные расширения для vb и js) — прям ноджысы какой-то.
И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
1) Десктоп-клиент держит в себе встроенный веб-сервер, к которому подключаются браузером саб-клиенты для специальных задач.
2) Да собственно апп-сервер и есть бэк декстопа в multitier, нормальная практика, хоть и устаревшая по нынешним временам.
Но вот непонятен такой момент как пайпинг. Простая задача: мне нужно в процессе сборки взять определённый файл в сыром виде, до любой обработки, выполнить эту самую некую обработку и отдать его дальше, в watch-mode — то, что в вебпаке реализуется с помощью Rule.use chaining и его внутренней виртуальной файловой системы — кэша, и то, что как минимум до текущей версии CLI было сломано в CLI-плагине.
Вот, например, похожее issue: github.com/angular/angular-cli/issues/9559 давненько висит.
Проблема (как минимум со связкой webpack 4, typescript, AOT) в том, что AngularCompilerPlugin игнорирует результаты предыдщих лоадеров и берёт оригинальный исходный файл с диска. Я понимаю, что это больше связано с кэшированием проекта tsc, а не ng, но до определённого момента были стандартные хуки, потом можно было написать файл-трансформер, а теперь остались только совсем хакерские методы прямой работы с AST но они не всегда в принципе возможны. Кстати, с актуальностью плагина тоже печальная ситуация.
Есть ощущение, что «обычный» «прямой» вебпак-сборщик теперь вышел из моды и поддерживается по остаточному принципу. Но, может быть, я чего-то не заметил и теперь такой сценарий может быть реализован прямо из CLI?
Я хочу вставить пять копеек насчёт подхода с externals. У меня под рукой есть один проект, где применён такой приём, там сделано таким образом:
1. Файл с конфигом, что-то вроде такого —
2. В самом webpack.config.js до собственно конфига довольно тривиальный код, который из этой структуры
— делает собственно объект для поля externals
— готовит список файлов для HTML/Webpack DefinePlugin (используется свой загрузчик ассетов, с фолбэком и излишествами)
— копирует каждый целевой файл для текущего окружения в output.
— ну и ещё пара трюков, которые проверяют, нет ли уже такого файла в месте назначения чтобы не делать лишней работы и быстрая грубая проверка через lstat совпадают ли размеры файла с источником на предмет «а вдруг с прошлого билда поменялась версия или переключили прод на дев».
Это позволяет не париться с отслеживанием консистентности. Хотя сам подход, конечно, достаточно специфичен и нужно чётко понимать, когда есть смысл им пользоваться…
По мне, если соискатель ответит на вопрос «нет ли подвоха в этой функции», даже без примера, то это прекрасно.
typeof d === 'object'
isObject(d) === false
Лично у меня ощущения от использования хуков — «как бы получить возможности классовых компонентов и „взрослой“* архитектуры и при этом поменьше вникать в эту самую архитектуру». Не знаю, как по мне рано или поздно всё равно придётся разбираться, только наворочено к этому моменту будет больше и рефакторить придётся тоже больше.
* взрослой = явное управление стейтом и потоками, разделение ответственности, DI, прочий далеко не всем нужный хлам.
У ангуляражс по крайней мере очень низкий порог вхождения. В первых десяти процентах кривой =)
Например, вот.
Кстати, если посмотреть на топ-100 ангуляр-приложений, то очень много из них были и остаются на ангуляржс и никогда не будут переписаны на ангуляр 2+. А вот для финансового сектора, например, поддержка актуальности стека — критична.
Компонентная модель здесь вообще никаким боком. Ну разве что можно притянуть, что простой пропагацией пропсов можно обойтись в несложных случаях — но если автор сам себе злобный буратино и не озаботился более серьёзным механизмом контроля потока данных и потока управления при росте сложности, то с тем же успехом можно и прямо на жабаскрипт пенять.
В реакте — снова скажу — что хорошо и плохо сразу так это что задачу можно решить несколькими способами. По уровню хаоса он где-то между ангуляржс и ангуляром: двустороннего байндинга уже нет, но данные можно гонять практически как бог на душу положит. С другой стороны, это совсем не его задача и для этого есть совсем другие инструменты.
Не всегда, есть в приципе нерешаемые проблемы, но главное для энтерпрайза — он снят с поддержки. Тут даже не в самом ангуляре затык, а в обвязке: jQuery, UI Bootstrap, прочие зависимости, некоторые из которых могут быть заброшены, а некоторые не иметь соместимых комбинаций. Другими словами, устаревающий неподдерживаемый стек. Другие чисто технические вопросы да, как правило можно или решить, или обойти, почти все, но и этого достаточно.
Мелким или короткоживущим, или неразвивающимся проектам может быть и пофигу — на несколько лет ещё хватит.
PS ангуляр 2+ ушёл вообще не туда, по моему скромному мнению. Слишком шарахнулся в противоположную сторону, обжёгшись на первом.