И создал он три вида api. Options Api для гномов, Class Api для ангуляроподобных эльфов, а последний composition отдал людям. Были и те, кого скверна реакта коснулась, даже их не обделил Эван и перековал рендер функцию, дабы та напрямую с домом не работала.
Не против. Удобно писать свои расширения. Использовал обёртку от vue3, проблем не было. Правда поведение bubble меню раздражает, выделять текст мышкой иногда сложновато, наплыв просходит. Еще кажется были конфликты текстового bubble меню c менюшкой у изображений. В расширение от типтап image можно добавить картинку, но нельзя манипулировать с ней (менять ширину, высоту, алигн). Решение есть у community, но робатает не идеально. К примеру при добавление текста к изображению появляются артефакты. Решение проблемы, создать отдельный параграф специально под картинку. На хабре тоже не идеально работает, дублируются лишние 3 точки
Layers это не особо новая фича. Тока у нее ведь более простое название, монорепка. По сути подход не предлагает ничего нового и можно просто решить проблему реорганизацией структуры.
я точно не помню, но вроде существует правильный порядок по которому браузер принимает css. Display будет более приоритетным, чем background к примеру. То есть в команде это можно решить линтером stylelint-order, можете написать свой пресет и включать форматирование. ИМХО кому как удобнее. Вот только если будете писать не забудьте про утилитарные классы и @apply, ведь сейчас бэм используется уже реже, как и написание через style
Спасибо за статью, но чутка обобщенно. Хотелось бы узнать что лучше / leaflet / openlayers / mapbox? Ты добавил wmts, это кажется просто векторный слой без features, а это самое вкусное. Geoserver это сборка с админкой? То есть это джентльменский набор для карт, а так мы можем все сервисы поднять отдельно в докер?
Дмитрий без обид, но это классический пост про $mol. Напоминает рекламу из боковых баннеров: "У меня теперь стоит как у быка, ведь я принимаю ..." Хотите узнать больше? В этом есть какая-то выгода, помимо саморазрушения? Какой план? Наступать на одни и те же грабли?
архитектура hono изначально была заточена под bun, nodejs просто адаптер, поэтому производительность на node будет ниже. Подружки солёной аёми (elysia) пытались писать адаптер под ноду, но он так и не вышел и скорее всего не выйдет, если bun раньше выпустит поддержку http3.
hattip это разработка brillout, а он вроде работает в vite, поэтому у hattip есть поддежрка vite. Он же разработал vike, который помогает использовать популярные фреймворки для фронта. WinterCG это вроде не стандарт, а больше сообщество которое продвигает совместимость сервера с фронтом и serveless. Типо можно запросто передать запрос от hono к elysia, передача типов аля tRPC, у elysia это Eden (TypeBox), а у hattip telefunc.
По ощущениям работать на бэке c elysia приятнее, но если требуется фронт с поддержкой серверного рендера, то можно воспользовать batijs и собрать сборку для фулстэка.
vue это реактивный фреймворк (поддержка SSR появляется только после подключение сервера на nodejs), а laravel это fullstack php. Чувствуешь разницу? Прости, но как laravel сделает серверный рендер реактивного компонента? Как ты думаешь зачем вообще используем nodejs?
Nuxt это фулстэк фреймворк, он не для фронта только. В режиме SSR, SSG, ISR мы используем на бэкенде nodejs, потому что передать данные от nodejs к бразерному проще, чем это делать в связке php + browser js
а еще SSR добавляет нотку бэкенда, поэтому формально это уже не фронтенд, а фулстэк разработка, а это снижает уровень входа в проект. Автор написал про хуки на фронте, но к этому еще добавляются хуки на бэкенде (к примеру nuxt). Технология на nodejs еще сырая и слишком рано стали использовать по дефолту. Если контент не слишком часто обновляется стоит использовать prerender (SSG, ISR)
Вау, целая статья про гиперссылку и все ради рекламы яндекс сервиса. А теперь скажи Настя, а есть другие замечательные сервисы (вроде htmlbook) которые рассказывают про тэги в html?
Я думаю было бы интереснее, если бы провели тесты для сравнения с современными nodejs фреймворками, например: h3, hattip, elysia, hono, oak. Express-у уже более 10 лет, большая часть компаний перешла на fastify. Nuxt перешел с koa на h3. Сейчас каждый новый js фреймворк хвалиться скоростью, вот только методы проверки спорные
Речь в astro шла о преимуществе над SPA. Я замечал как админки популярных ресурсов написанных в нулевых на php работают значительно быстрее чем после редизайна на React/Vue. Приходиться ждать по 10-15 сек на подгрузку скриптов + загрузка при смене view. Из плюсов анимированные дашборды и куча реактивных цифр и графиков, сменяющихся каждые 3 секунды. То ли ждать пока прогрузиться компонент, то ли все приложение целиком. Наверное по этой причине gitlab состоит из куча инстансов vue.
Плюс в астро можно использовать несколько фреймворков из коробки. Серьезных боевых проектов на астро я пока еще не видел, хз как он там поведет. Про middleware еще не все написано в доках, для хранения nano store, но пока нет примера коммуникации между компонентами (или островами).
У directus (в отличие от strapi) до сих пор нет маркетплейса, и он тока обещает появиться в ближайших версиях. Для поднятие dev версии требуется минимум 8 гб озу (зачем столько?). Немножко напрягает написание плагинов под него, при подключение сторонних библиотек часто возникают ошибки. Плагины можно писать под ts, но читает js, значит под ts нельзя дебажить в реалтайм + сторонние библиотеки будут дублироваться. Про action там свои приколы, в доке есть пример как делать слаги, вот только он использует слаг последнего поста и прописывает их всем. Решил проблему в виде плагина вебхука. Дело в том, что directus старается быть low code решением для бэкенда, в то время как большинство headless cms, больше упираются на работу только с контентом.
Мне не совсем понятна логика поста, при чём здесь мультиплатформинг и directus? Почему не написать как мы выбирали CMS для нашей компании, это же не противоречит правилам хабра, кажется уже так делали
часто в постах фигурирует нативный докер, хотя им неудобно пользоваться. Кому нравится писать километровые команды с кучей аргументов? Кстати ключевая фишка это хранение артефактов, я использовал cypress на gitlab ci и очень быстро перегрузил хранилище тонной мусора, потом узнал что можно настроить авточистку. Был ещё парадокс, после подключение к багтрекингу (кажется sentry) артефакты были доступны всегда, как будто они сохранялись на сервере sentry
Нельзя просто взять и поставить manjaro (я к примеру поставил mapbox) и не занимаюсь всеми этими сегсами
И создал он три вида api. Options Api для гномов, Class Api для ангуляроподобных эльфов, а последний composition отдал людям. Были и те, кого скверна реакта коснулась, даже их не обделил Эван и перековал рендер функцию, дабы та напрямую с домом не работала.
Не против. Удобно писать свои расширения. Использовал обёртку от vue3, проблем не было. Правда поведение bubble меню раздражает, выделять текст мышкой иногда сложновато, наплыв просходит. Еще кажется были конфликты текстового bubble меню c менюшкой у изображений. В расширение от типтап image можно добавить картинку, но нельзя манипулировать с ней (менять ширину, высоту, алигн). Решение есть у community, но робатает не идеально. К примеру при добавление текста к изображению появляются артефакты. Решение проблемы, создать отдельный параграф специально под картинку. На хабре тоже не идеально работает, дублируются лишние 3 точки
а почему не рассматривали tiptap?
а почему не рассматривали tiptap?
Layers это не особо новая фича. Тока у нее ведь более простое название, монорепка. По сути подход не предлагает ничего нового и можно просто решить проблему реорганизацией структуры.
я точно не помню, но вроде существует правильный порядок по которому браузер принимает css. Display будет более приоритетным, чем background к примеру. То есть в команде это можно решить линтером stylelint-order, можете написать свой пресет и включать форматирование. ИМХО кому как удобнее. Вот только если будете писать не забудьте про утилитарные классы и @apply, ведь сейчас бэм используется уже реже, как и написание через style
Спасибо за статью, но чутка обобщенно. Хотелось бы узнать что лучше / leaflet / openlayers / mapbox? Ты добавил wmts, это кажется просто векторный слой без features, а это самое вкусное. Geoserver это сборка с админкой? То есть это джентльменский набор для карт, а так мы можем все сервисы поднять отдельно в докер?
Дмитрий без обид, но это классический пост про
$mol. Напоминает рекламу из боковых баннеров: "У меня теперь стоит как у быка, ведь я принимаю ..." Хотите узнать больше?В этом есть какая-то выгода, помимо саморазрушения? Какой план? Наступать на одни и те же грабли?
архитектура hono изначально была заточена под bun, nodejs просто адаптер, поэтому производительность на node будет ниже. Подружки солёной аёми (elysia) пытались писать адаптер под ноду, но он так и не вышел и скорее всего не выйдет, если bun раньше выпустит поддержку http3.
hattip это разработка brillout, а он вроде работает в vite, поэтому у hattip есть поддежрка vite. Он же разработал vike, который помогает использовать популярные фреймворки для фронта.
WinterCG это вроде не стандарт, а больше сообщество которое продвигает совместимость сервера с фронтом и serveless. Типо можно запросто передать запрос от hono к elysia, передача типов аля tRPC, у elysia это Eden (TypeBox), а у hattip telefunc.
По ощущениям работать на бэке c elysia приятнее, но если требуется фронт с поддержкой серверного рендера, то можно воспользовать batijs и собрать сборку для фулстэка.
vue это реактивный фреймворк (поддержка SSR появляется только после подключение сервера на nodejs), а laravel это fullstack php. Чувствуешь разницу? Прости, но как laravel сделает серверный рендер реактивного компонента? Как ты думаешь зачем вообще используем nodejs?
Nuxt это фулстэк фреймворк, он не для фронта только. В режиме SSR, SSG, ISR мы используем на бэкенде nodejs, потому что передать данные от nodejs к бразерному проще, чем это делать в связке php + browser js
а еще SSR добавляет нотку бэкенда, поэтому формально это уже не фронтенд, а фулстэк разработка, а это снижает уровень входа в проект. Автор написал про хуки на фронте, но к этому еще добавляются хуки на бэкенде (к примеру nuxt). Технология на nodejs еще сырая и слишком рано стали использовать по дефолту. Если контент не слишком часто обновляется стоит использовать prerender (SSG, ISR)
Вау, целая статья про гиперссылку и все ради рекламы яндекс сервиса. А теперь скажи Настя, а есть другие замечательные сервисы (вроде htmlbook) которые рассказывают про тэги в html?
Я думаю было бы интереснее, если бы провели тесты для сравнения с современными nodejs фреймворками, например: h3, hattip, elysia, hono, oak. Express-у уже более 10 лет, большая часть компаний перешла на fastify. Nuxt перешел с koa на h3. Сейчас каждый новый js фреймворк хвалиться скоростью, вот только методы проверки спорные
Речь в astro шла о преимуществе над SPA. Я замечал как админки популярных ресурсов написанных в нулевых на php работают значительно быстрее чем после редизайна на React/Vue. Приходиться ждать по 10-15 сек на подгрузку скриптов + загрузка при смене view. Из плюсов анимированные дашборды и куча реактивных цифр и графиков, сменяющихся каждые 3 секунды. То ли ждать пока прогрузиться компонент, то ли все приложение целиком. Наверное по этой причине gitlab состоит из куча инстансов vue.
Плюс в астро можно использовать несколько фреймворков из коробки. Серьезных боевых проектов на астро я пока еще не видел, хз как он там поведет. Про middleware еще не все написано в доках, для хранения nano store, но пока нет примера коммуникации между компонентами (или островами).
У directus (в отличие от strapi) до сих пор нет маркетплейса, и он тока обещает появиться в ближайших версиях. Для поднятие dev версии требуется минимум 8 гб озу (зачем столько?). Немножко напрягает написание плагинов под него, при подключение сторонних библиотек часто возникают ошибки. Плагины можно писать под ts, но читает js, значит под ts нельзя дебажить в реалтайм + сторонние библиотеки будут дублироваться.
Про action там свои приколы, в доке есть пример как делать слаги, вот только он использует слаг последнего поста и прописывает их всем. Решил проблему в виде плагина вебхука.
Дело в том, что directus старается быть low code решением для бэкенда, в то время как большинство headless cms, больше упираются на работу только с контентом.
Мне не совсем понятна логика поста, при чём здесь мультиплатформинг и directus? Почему не написать как мы выбирали CMS для нашей компании, это же не противоречит правилам хабра, кажется уже так делали
часто в постах фигурирует нативный докер, хотя им неудобно пользоваться. Кому нравится писать километровые команды с кучей аргументов? Кстати ключевая фишка это хранение артефактов, я использовал cypress на gitlab ci и очень быстро перегрузил хранилище тонной мусора, потом узнал что можно настроить авточистку. Был ещё парадокс, после подключение к багтрекингу (кажется sentry) артефакты были доступны всегда, как будто они сохранялись на сервере sentry
Симулятор чтения документации и форумов аля StackOverflow по китайски. Автор статьи ещё смеет утверждать, что симулятор тракториста это скучно
я как-будто прочитал целый учебник по психологии или разом решил посмотреть все видосы Дерека Маллера
Использовать хабр в качестве среды для заметок не лучшая идея, тебе тока репу понизят