Справедливости ради, начинается этот цикл с блочного выделения, замены и вставки, которые в принципе есть сейчас во многих редакторах, пусть и чуть по-другому работающие.
зато какое удовольствие потом: настраивай как хочешь, экспериментируй посредством написания кода, пиши свои режимы. Уж не говорю о таких штуках, как org, magit.
Наверное про подобное и должна была быть статья. VSCode приобрёл бешеную популярность за счёт возможности тюнинга плагинами и возможности их написания самому на известном (для фронтендеров) или более-менее привычном для остальных разработчиков. Для VSCode, например, есть Markwhen, поддержка Git у него встроенная, можно ещё кучу всего понаустанавливать, в том числе типа каких-то плагинов для Vim mode, org-mode и так далее. Нужно показывать, чем Emacs круче по сравнению с Vim VSCode, а не хвалиться поддержкой BSD и Соляриса.
GNU Emacs уже много лет, и за это время он пережил не один десяток других редакторов и IDE. Скорее всего, в ближайшие годы он переживёт их ещё немало. Это значит, что ваше время, потраченное на его освоение и написание init.el, не пропадёт даром.
Но пользователи Windows и Mac уже более 30 лет используют привычные сочетания клавиш в разных редакторах и они точно так же уверены, что и в последующие 30 лет, если клавиатуры будут существовать, ничего принципиально в этих сочетаниях не изменится. То есть они уже потратили своё время на освоение приёмов работы с редакторами и не хотят ничего менять.
У GNU Emacs отличная обратная совместимость. Вы называете это говном мамонта и legacy. Я называю это стабильностью. Мы не одинаковы.
Здесь вы сами противопоставляете себя большинству :) Но, справедливости ради, не очень понятно, что именно 20-30-летней давности понадобится современному пользователю?
У GNU Emacs отличная документация. Можете ли вы то же самое сказать про свою IDE?
Так большинство приёмов работы интуитивно понятны как раз благодаря привычности управления, знакомому по опыту работы с другими программами. А вот то, что не понятно, есть или в туториалах, или в гугле / чатгпт.
GNU Emacs быстр, потому что нативно собирается под большинство широко распространённых платформ. У Sublime Text и VS Code есть поддержка Linux, macOS и Windows. Что насчёт *bsd-систем? HP-OS? Solaris?
Многим хватает скорости VSCode, кто-то сидит в IDE на джаве. Да и тот же Sublime или TextMate — довольно шустрые. Поддержка BSD, HP-OS, Solaris? А кто-то с ними вообще сталкивался?
GNU Emacs — современный редактор, находящийся в активной разработке. Не так давно туда добавили поддержку TreeSitter, Emoji и рендеринг шрифтов с использованием возможностей видеокарты. Как дела у пользователей Notepad++? Что там с TreeEditor (помните такой?)?
Вот кажется, что пользователи Notepad++, которым позарез нужны были эмодзи, перешли на VSCode с тонной плагинов :) TreeSitter им вряд ли нужен, потому что у них есть LSP. И, возможно, с поддержкой Yaml у них дела обстоят лучше.
Там немного сложнее: в C++26 добавлена перегрузка для static_assert, позволяющая передать user-generated сообщение. До этого можно было передать только литерал. Однако ассерт ожидает не const char*, а объект с методами data() и size(). То есть, фактически, можно напрямую скормить ему std::vector<char> или std::string, но посимвольная конкатенация для строки немного медленно работает на большом цикле.
На практике это приводит к тому, что разработчики вообще забивают на именование элементов, даже если им нужна семантика. Другой момент — разработчики ленятся искать существующие компоненты и верстают их по месту использования. В отсутствии семантики такое может проскочить ревью, потому что ревьюеры могут не понять, что это за элемент и не предложить использовать уже готовый.
Подход CSS-in-JS тоже плох, но не необходимостью постоянно именовать частные случаи использования компонентов, а перемешиванием кода и стилей. Тогда как постоянное выделение частных стилей свидетельствует об отсутствии системности в дизайне и проектировании компонентов.
Кроме того, подход Tailwind не избавляет от избыточности, если есть некое фиксированное множество наборов атрибутов. Например, стили текстов Heading1, Heading2, Heading3, Primary text, Secondary text. У них могут быть разные гарнитуры, кегли, интервалы и цвета.
Вот именно про это я и говорю. У Content 2 немного поменялись правила, а ленивый разработчик не захотел давать этому изменению никакой семантики. Поддерживать такой код потом очень сложно как раз из-за отсутствия семантики. И как раз в вашем примере возникает вопрос: если вы второму элементу ставите отступ, то нужно ли будет его ставить последующим элементам, и почему отступ здесь сделан маржином, а не увеличением gap грида? Предположим, двум разработчикам дали параллельные задачи: одному — добавить Content 3, а другому — попроавить отступ. Изменения в реальном проекте скорее всего будут в удалённых друг от друга строках, поэтому мерж-конфликта не будет, но после мержа будет не очень хорошо. В проектах вида «наговнокодил, отдал и забыл» это худо-бедно работает. Опять-таки — это самый простой случай.
Что касается специфичности, то это не должно быть проблемой, потому что излишней специфичности селекторов и так не должно быть.
Насчёт «места, где оно должно храниться» — а тут как раз с этим должна помочь семантика. В большинстве случаев это будет стилевой файл того блока, к которому относится элемент.
Ибо это одно и то же, просто детали реализации иные.
Вот об этом и был мой вопрос. Дело в том, что в Solid нет понятия атомов, а @nihil-proсказал, что атомы ему не нравятся. Но если это просто название конкретной реализации, то почему мы сравниваем реализацию с интерфейсом (паттерном) Observable. А если есть какое-то отличие в интерфейсе, то, опять-таки хорошо было бы сослаться на конкретную реализацию, потому что общего интерфейса или паттерна Atom нет.
От классического паттерна Наблюдатель всё-таки у большинства реализаций атомов-обсёрваблов отличие в неявном механизме подписки, что как раз и является киллер-фичей подобных библиотек.
Это может быть хорошо, если написать разметку один раз и забыть об этом, а если у Content 2 чуть-чуть поменяются правила по ошибке или специально, то как потом понимать, как поддерживать это изменение? В случае с классическим подходом это будут разные классы, по названию которых можно определить их назначение, а здесь тупо литералы. Вы же в коде наверняка пытаетесь избавляться от магических констант, а Tailwind, наоборот, поощряет их создание.
в процессе сборки неиспользуемые классы из tailwind не добавляются
Что мешает в проект на CSS или CSS Modules добавить тот же PurgeCSS, который использует Tailwind? Или вы думаете, что Tailwind каким-то магическим образом всё оптимизирует?
Так это всё понятно. Вопрос же был не в отличии реализаций солида и альтернатив, а в отличии концепции атомов и обсёрваблов. Именно потому, что единой терминологии нет. Вот у Карловского минимальная реактивная сущность называетс атомом, здесь — обсёрваблом. Но что уважаемый автор в это вкладывает, заявляя, что атомы ему не нравятся?
Ну если его наказали за что-то другое, но сфабриковав статью 273, то тут в принципе обсуждать по теме нечего...
Судя по приговору суда, вменили преступлением именно установку Zver для нейтрализации средств защиты.
Так не все хотят заниматься бесконечной кастомизацией редактора.
Так если инвестировать время не в емакс, а во что-то другое, то это что-то другое и будет рабочим инструментом. Очевидно же.
Справедливости ради, начинается этот цикл с блочного выделения, замены и вставки, которые в принципе есть сейчас во многих редакторах, пусть и чуть по-другому работающие.
Наверное про подобное и должна была быть статья. VSCode приобрёл бешеную популярность за счёт возможности тюнинга плагинами и возможности их написания самому на известном (для фронтендеров) или более-менее привычном для остальных разработчиков. Для VSCode, например, есть Markwhen, поддержка Git у него встроенная, можно ещё кучу всего понаустанавливать, в том числе типа каких-то плагинов для Vim mode, org-mode и так далее. Нужно показывать, чем Emacs круче по сравнению с
VimVSCode, а не хвалиться поддержкой BSD и Соляриса.Так и для чего выбирать Emacs большинству?
Но пользователи Windows и Mac уже более 30 лет используют привычные сочетания клавиш в разных редакторах и они точно так же уверены, что и в последующие 30 лет, если клавиатуры будут существовать, ничего принципиально в этих сочетаниях не изменится. То есть они уже потратили своё время на освоение приёмов работы с редакторами и не хотят ничего менять.
Здесь вы сами противопоставляете себя большинству :) Но, справедливости ради, не очень понятно, что именно 20-30-летней давности понадобится современному пользователю?
Так большинство приёмов работы интуитивно понятны как раз благодаря привычности управления, знакомому по опыту работы с другими программами. А вот то, что не понятно, есть или в туториалах, или в гугле / чатгпт.
Многим хватает скорости VSCode, кто-то сидит в IDE на джаве. Да и тот же Sublime или TextMate — довольно шустрые. Поддержка BSD, HP-OS, Solaris? А кто-то с ними вообще сталкивался?
Вот кажется, что пользователи Notepad++, которым позарез нужны были эмодзи, перешли на VSCode с тонной плагинов :) TreeSitter им вряд ли нужен, потому что у них есть LSP. И, возможно, с поддержкой Yaml у них дела обстоят лучше.
Только clang показывает часть клеток, да и вообще в ascii, а MSVC вообще собрать в режиме /std:c++20 не может :(
Там немного сложнее: в C++26 добавлена перегрузка для
static_assert, позволяющая передать user-generated сообщение. До этого можно было передать только литерал. Однако ассерт ожидает неconst char*, а объект с методамиdata()иsize(). То есть, фактически, можно напрямую скормить емуstd::vector<char>илиstd::string, но посимвольная конкатенация для строки немного медленно работает на большом цикле.Спасибо! Как раз было интересно, как это в TanStack Router реализовали, но некогда было код анализировать.
На практике это приводит к тому, что разработчики вообще забивают на именование элементов, даже если им нужна семантика. Другой момент — разработчики ленятся искать существующие компоненты и верстают их по месту использования. В отсутствии семантики такое может проскочить ревью, потому что ревьюеры могут не понять, что это за элемент и не предложить использовать уже готовый.
Подход CSS-in-JS тоже плох, но не необходимостью постоянно именовать частные случаи использования компонентов, а перемешиванием кода и стилей. Тогда как постоянное выделение частных стилей свидетельствует об отсутствии системности в дизайне и проектировании компонентов.
Кроме того, подход Tailwind не избавляет от избыточности, если есть некое фиксированное множество наборов атрибутов. Например, стили текстов Heading1, Heading2, Heading3, Primary text, Secondary text. У них могут быть разные гарнитуры, кегли, интервалы и цвета.
Вот именно про это я и говорю. У Content 2 немного поменялись правила, а ленивый разработчик не захотел давать этому изменению никакой семантики. Поддерживать такой код потом очень сложно как раз из-за отсутствия семантики. И как раз в вашем примере возникает вопрос: если вы второму элементу ставите отступ, то нужно ли будет его ставить последующим элементам, и почему отступ здесь сделан маржином, а не увеличением gap грида? Предположим, двум разработчикам дали параллельные задачи: одному — добавить Content 3, а другому — попроавить отступ. Изменения в реальном проекте скорее всего будут в удалённых друг от друга строках, поэтому мерж-конфликта не будет, но после мержа будет не очень хорошо. В проектах вида «наговнокодил, отдал и забыл» это худо-бедно работает. Опять-таки — это самый простой случай.
Что касается специфичности, то это не должно быть проблемой, потому что излишней специфичности селекторов и так не должно быть.
Насчёт «места, где оно должно храниться» — а тут как раз с этим должна помочь семантика. В большинстве случаев это будет стилевой файл того блока, к которому относится элемент.
Вот об этом и был мой вопрос. Дело в том, что в Solid нет понятия атомов, а @nihil-proсказал, что атомы ему не нравятся. Но если это просто название конкретной реализации, то почему мы сравниваем реализацию с интерфейсом (паттерном) Observable. А если есть какое-то отличие в интерфейсе, то, опять-таки хорошо было бы сослаться на конкретную реализацию, потому что общего интерфейса или паттерна Atom нет.
От классического паттерна Наблюдатель всё-таки у большинства реализаций атомов-обсёрваблов отличие в неявном механизме подписки, что как раз и является киллер-фичей подобных библиотек.
Если всё равно классы писать, то зачем
@apply? Проще нативными правилами CSS всё записать тогда.Где здесь код? Это тупо стили. SCSS или что-то подобное.
Это может быть хорошо, если написать разметку один раз и забыть об этом, а если у Content 2 чуть-чуть поменяются правила по ошибке или специально, то как потом понимать, как поддерживать это изменение? В случае с классическим подходом это будут разные классы, по названию которых можно определить их назначение, а здесь тупо литералы. Вы же в коде наверняка пытаетесь избавляться от магических констант, а Tailwind, наоборот, поощряет их создание.
Что мешает в проект на CSS или CSS Modules добавить тот же PurgeCSS, который использует Tailwind? Или вы думаете, что Tailwind каким-то магическим образом всё оптимизирует?
Так это всё понятно. Вопрос же был не в отличии реализаций солида и альтернатив, а в отличии концепции атомов и обсёрваблов. Именно потому, что единой терминологии нет. Вот у Карловского минимальная реактивная сущность называетс атомом, здесь — обсёрваблом. Но что уважаемый автор в это вкладывает, заявляя, что атомы ему не нравятся?