• 0
    Интересно, что это проект из Ирана — я встречался с его автором, милый парень.
    Lebab это как Babel, только наоборот
  • 0
    А какие детали вы хотите услышать следующий раз?
    HolyJS Moscow: Время экспансии
  • 0
    Да, если было бы полтора часа, то можно было бы успеть. А фразы «это пока только разработка и набор идей» в конце было не достаточно? Плюс в вопросах я довольно явно говорил, что много непонятно и много вопросов есть.
    HolyJS Moscow: Время экспансии
  • 0
    Никогда об этом не задумывался :). А как ты видишь рассказывать о проблеме не упрощая?
    HolyJS Moscow: Время экспансии
  • 0
    У меня есть ощущение, что он то ли лукавит то ли действительно не до конца понимает глубину проблемы, в которую он погружается.

    Когда я начинал только делать Логакс, у меня были прямо приступы панической атаки от понимания сложности. Но тут два варианта — или уйти ничего не сделав. Или начать делать и решать проблемы по ходу их появления :D.
    HolyJS Moscow: Время экспансии
  • +1
    Я бы сам с удовольствием хотел бы послушать кого-то, кто знает все ответы :).

    Тут главная проблема, что тема новая. И тут есть два варианта — не выступать в России и обсуждать идеи с западными разработчиками. Тогда не будет такой ситуации, что никто не знает ответов. Но взамен, когда все ответы найдутся — будет уже поздно, все места заняли другие.

    Или другое — начать обсуждение на ранних этапах, чтобы русские разработчики могли подключиться и влиться в проект. Представьте как выглядит бы доклад по Реакту, когда он только появлялся. Или помните первый доклад Дэна, из которого вырос Редакс.

    Но согласен, каждому своё. Кто-то хочет готовых решений. А кто-то хочет узнать, о чём сейчас думает индустрия и подключиться к обсуждению :).
    HolyJS Moscow: Время экспансии
  • 0
    Кстати, как хранить конечные данные на сервере решаете вы. Так что даты полей можете не хранить, а использовать обычное хранение. Или хранить именно с датами, чтобы мерж работал, даже если клиента не было онлайн более месяца.

    В общем Логакс никак не ограничивает БД на сервер. Свой лог он хранит в отдельном файле и этот лог лишь дополнительная вещь. Его можно смело чистить через неделю.
    Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)
  • 0
    Правильно мыслите — собственно в CRDT примерно так и сделано.

    Но разделение по полям не идеальный способ. Есть типы данных, которые так мержить не получится — например, счётчики или длинный текст (где хочется параллельное редактирование). Для этого и придумали более абстрактный способ — хранить действие.

    Но сборщик мусора в логе и так удаляет все старые значения поля (если это CRDT Map). Так что хранится очень близко к вашей идей. Просто чуть универсальнее для других типов.
    Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)
  • 0
    Прокси большая проблема для обычных веб-сокетов, но если перейти на сокеты поверх SSL (WSS), то большинство проблем решится. Мы стараемся везде в интерфейсе форсить WSS.

    Сокеты — IE 10+, это нормально. Логакс ориентирован на SPA, а для IE <10 SPA создают редко.

    Но, сам Логакс не ограничивает как передаются данные. Просто стандартный драйвер использует веб-сокеты. Можно заменить на AJAX + keep-alive. Или внедрить протокол Логакса внутрь какого-то нибудь корпоративного XML.
    Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)
  • 0
    Да, так можно — но смысла мало. На клиенте всё равно больше кода для AJAX-запроса. Непонятно как понятно и прозрачно интегрировать получение таких же событий с сервера.

    Плюс запуск и обновление сервис-воркера — хитрая задача. В спеке есть не очень очевидные моменты (например, с адресом воркер-файла).

    Ну и преимуществ не будет никаких (в фоне воркер сокет не может держать).
    Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)
  • +2
    Можно сказать, что и идемпотентные. Каждое событие имеет уникальный ID (он же время создания). Когда событие добавляется в лог, то проверяется, нет ли уже такого ID. Так что всё проблема повторной доставки сильно упрощается.
    Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)
  • +1
    Есть две разные задачи в поддержке оффлайна:

    1. Кеширование HTML/JS/CSS-файлов приложение.
    2. Организация работы с данными приложения без связи.

    Эти задачи очень разные. Сервис-воркеры созданы для решения только первой задачи. Для решения второй задачи они не созданы.

    Можно конечно перенести работу с логом в сервис-воркер, но это только усложнит код и уменьшит поддержку браузеров.
    Logux: Connection lost, data synchronized – интервью с Андреем Ситником (Злые Марсиане)
  • 0
    Может быть поэтому PostCSS и уделывает других за счет того, что слишком упрощенно подходит к анализу файлов?


    Не совсем. Многие парсеры в нашем бенчмарке парсят тоже очень приближенно. С другой стороны, csstree парсит всё, как вы хотите, но даже быстрее PostCSS.

    На самом деле, практически весь вопрос скорости парсинга — это токенайзер. Оптимизировать имеет смысл только его. Если парсить всё, то токенов, конечно, будет больше — но не принципиально. Все эти проверки и разбор спецификаций в основном будет происходить уже после токеном. А по моему опыту, что ты будешь делать после токенов уже не особо важно с отношении скорости.
    PostCSS. Будущее после Sass и Less
  • 0
    Привет. Отличный вопрос! Да, ты прав. Написать универсальных парсер всех структур CSS очень сложно.

    Кроме того тех проблем, что ты указал (куча спецификаций) есть ещё более большая — а как делать полифилы или расширения CSS типа CSS Modules?

    Поэтому у PostCSS специально чуть другая философия. На самом деле парсинг состоит из 2 частей — разбор «грамматики» и разбор «смысла». Вот если мы парсим «Вилкой удобно есть суп». Когда мы «парсим» грамматику, мы только определяем, где подлежащие, сказуемое и т. д. Но мы не пытаемся понять конкретный смысл фразы. Потом мы уже по грамматике можем отпарсить смысл, взяв данные по отношению вилки, супа и т. п. (тут бы мы заметили ошибку смысла, так как вилкой не удобно есть суп).

    Тоже самое и в PostCSS. Она парсит только структуру CSS, но не смысл конкретных выражений. Конкретно мы используем эту спецификацию https://www.w3.org/TR/css-syntax-3/

    Если разработчикам плагинов нужен смысл каких-то блоков — они могут использовать специальные допарсеры — postcss-selector-parser, postcss-value-parser и т. п.

    Есть и другой подход — например, csstree парсит всё целиком.

    Но, как я уже писал, на полном парсере (которые будет всё проверять) не написать огромное количество очень нужных CSS-инструментов. Так что такой подход просто не подходит для целей PostCSS.
    PostCSS. Будущее после Sass и Less
  • 0
    Почему PostCSStoNode нет?

    const root = postcss.parse(css)
    
    PostCSS. Будущее после Sass и Less
  • +6
    Это транскрипт старого выступления (я бы его не выкладывал), давай-те я попробую объяснить лучше, чем у меня получалось тогда.

    PostCSS — это фреймворк для разработки CSS-инструментов.

    Вот у вас есть крутая идея минификатора CSS. Или вы хотите написать новые препроцессор. Или вы увидели крутой черновик спецификации и хотите написать полифил. Для всего этого вам нужен парсер, генератор карт-кода, инструменты разработки, обвязка для Grunt, Gulp, webpack.

    PostCSS, как раз даёт всё это — парсер, генератор карт кода, инструменты разработчика, обвязки для сборщиков.

    Но когда несколько инструментов начинают использовать один парсер PostCSS, получается огромный выигрыш от унификации:

    Сейчас у вас Sass парсит исходник, генерирует CSS. Минификатор снова парсит строку. Прасинг — самый долгий процесс в работе CSS-инструментов. Если все инструменты будут использовать один парсер, то зачем нам парсить на каждом шаге — парсим один раз в начале, а между плагинами передаём отпарсенное дерево.

    Кроме того, унификация даёт ещё пару плюсов. Все инструменты становятся совместимы между собой (линтер не будет падать от синтаксиса «CSS4» вашего полифила). Инструмент созданный для одного проекта (парсер битого CSS или вывод ошибки в браузер) становится доступен всем инструментам.

    Собственно в этом и смысл PostCSS. Это платформа для создания новых CSS-инструментов. Чем больше у вас инструментов основанных на PostCSS, тем больше плюсов вы получаете от унификации.
    PostCSS. Будущее после Sass и Less
  • 0
    Да ладно, про Babel или про Sass больше разговоров. Просто у меня в ТвитДеске идёт живой поиск твитов про PostCSS и я всегд влажу в разговор, если его вижу.
    PostCSS. Будущее после Sass и Less
  • 0
    Конкретно по вопросам:

    1. Ядро написано для node.js, но специально не привязано к нему. Достаточно собрать его с помощью browserify или webpack и оно будет прекрасно работать в браузере.
    2. Модули находятся в npm. Но это не проблема, поскольку легко решается с помощью browserify и webpack. Тот же webpack может грузить модули асинхронно.
    3. Да, желательно написать новый Автопрефиксер, так как база данных Can I Use весьма большая, а смысла от неё мало. Но для большинства случаев можно один раз предкомпилировать стили при деплое, а на клиенте просто проставлять значения (не всегда будет работать, но в 99,9% случаев).
    PostCSS. Будущее после Sass и Less
  • 0
    Краткий ответ: лучше используйте CSS-in-JS.

    Моё самый любимый проект — JSS. Но ещё есть интересный CSJS, у которого есть Babel-плагин, способный запускать PostCSS перед сборкой JS на его стилях.

    Так же есть postcss-js, чтобы использовать PostCSS уже в браузере для CSS-in-JS.
    PostCSS. Будущее после Sass и Less
  • 0
    Вы правы, что PreCSS (не PostCSS, а конкретный набор плагин для решения одной задачи) не имеет ничего нового относительно Sass.

    Но то что вы сравниваете PostCSS с Sass — совсем неправильно. PostCSS — фреймворк для создания любых CSS-инструментов. Препроцессор — только одна из множества этих инструментов.

    Вы полностью правы, если вы уже используете препроцессор, который не построен на PostCSS — то вам не надо переходить на препроцессор PreCSS на базе PostCSS. Мы об этом как раз и говорим (это запись выступления годичной давности).

    Но если вы начинаете новый проект и уже используете кучу инструментов на базе PostCSS? Тут у PreCSS появляется главный смысл — чтобы все инструменты были построены на одной фреймворке (PostCSS). В итоге у вас и быстрее сборка (PostCSS один раз парсит и все инструменты уже работают с готовым AST). Между инструментами гарантировано нет конфликтов. Унификация — это всегда круто.
    PostCSS. Будущее после Sass и Less
  • 0
    Это транскрипция выступления, которое было назад :). Я, к сожалению, доступа не имею на редактирование (да и материал устарел изрядно).
    PostCSS. Будущее после Sass и Less
  • 0
    Если плагины не меняют синтаксис (Автопрефиксер, RTLCSS), то подсветка не нужна.

    Для Stylelint есть подсветка ошибок для Atom и Sublime.

    Если вы используете препроцессор PreCSS (который на основе PostCSS-плагинов), то ставьте расширение .pcss — подсветка есть для Atom, Sublime, IDE от JetBrains.
    PostCSS. Будущее после Sass и Less
  • 0
    В тесте плагин на переменные, вложенность, математику, примеси — такой самый популярный набор
    PostCSS. Будущее после Sass и Less
  • 0
    Ничего. Мы и не хороним Sass. Наоборот, советуем не уходить с Sass в старых проектах.
    PostCSS. Будущее после Sass и Less
  • 0
    Был плагин для Express. Но на стороне сервера не выгодно парсить динамически — проще один раз при деплое.

    На стороне клиента можно запускать в теории, но готовое решение из коробки пока никто не сделал :(.
    PostCSS. Будущее после Sass и Less
  • 0
    Вы правы, что PostCSS даёт слишком много свободы и это иногда становится проблемой. Мне тоже нравятся не все плагины.

    Но вы не правы, что «Sass хватает для всего». Препроцессор не равен всем CSS-инструментам. У нас есть очень много задач. Взять хотя бы тот же uncss (нахождение мёртвого CSS по статичному HTML) — полезно и совершенно нельзя сделать на Sass. Или Автопрефиксер. Или Stylelint. Или RCTLCSS.
    PostCSS. Будущее после Sass и Less
  • 0
    А почему вам RTLCSS не кажется качественным? Всё таки WordPress — огромный пользователь. ВКонтакте тоже собирается переходить на RTLCSS.

    А почему вам кажется, что нужно будет выключать RTLCSS чаще, чем писать примесь? Может попробуйте на каком-нибудь маленьком тестовом проекте — вы тогда сразу прочувствуете как удобно стало.
    PostCSS. Будущее после Sass и Less
  • 0
    Я согласен, что PostCSS не захватил все ниши. Но у вас есть логическая ошибка — вы думаете, что CSS-инструмент = препроцессору.

    На самом деле PostCSS стал самый популярным CSS-парсером уже, котрый загружается с npm — графики.

    Причина в том, что PostCSS используется в куче новых CSS-инструментов, которые не являются препроцессорами. CSS Modules, css-loader в webpack, Stylelint, Autoprefixer, cssnano, uncss, RTLCSS.
    PostCSS. Будущее после Sass и Less
  • 0
    Отключить вам нужно в 1—2 местах. А примесь использовать в сотне.

    Практически все люди в Иране, которым я показывал RTLCSS были без ума от него — они явно отлично разбираются с практикой. Так же WordPress использует только RTLCSS и тоже отлично отзывались о её эффективности на CSSConf в Нью-Йорке.

    Я понимаю, что часто хочешь взять что-то старое и не учить, но RTLCSS — «абсолютный хищник» в своей нише. Все кто занимается этим вопросов плотно высоко оценивают его полезность.
    PostCSS. Будущее после Sass и Less
  • 0
    Для каждой локали не надо — один для обычных языков, второй файл для RTL-языков.

    Вообще есть проект, который исправления RTLCSS не в отдельный файл переносит, а дописывает таким «патчем», как в вашем первом комментарии.

    Но автор RTLCSS (он из Египта и постоянно занимается вопросом RTL) считает, что отдельный файл — проще. Всё равно сборка автоматизирована. Зато максимальная оптимизация по размеру и кол-ву запросов (но, опять же, если вы другого мнения это легко изменить — гибкость PostCSS позволяет).
    PostCSS. Будущее после Sass и Less
  • 0
    Понятно, что на практике иногда думать приходиться. Но, например, в репозитории проекта есть перевёрнутый сайт ГитХаба — весьма неплохо, большинство вещей сделано.

    То есть думать придётся, но на порядок меньше.
    PostCSS. Будущее после Sass и Less
  • +1
    Для вас есть синтаксис SugarSS. PostCSS позволяет менять парсеры.
    PostCSS. Будущее после Sass и Less
  • 0
    Есть специальные управляющие комментарии, которыми можно выключить магию (выключить нужно гораздо реже)
    PostCSS. Будущее после Sass и Less
  • 0
    Какой в этом смысл? 99% что я специально написал это правило и специально пренебрег его поддержкой в IE — graceful degradation.


    Сейчас лучше всего этот плагин вызывать из Stylelint — там у вас будет спец. комментарий, чтобы явно указать, что вот в этой строчке всё в порядке — вы добавили graceful degradation. С такими явными комментариями и код понятнее (показано что это graceful degradation) и не получиться забыть где-то вставить продумать graceful degradation.
    PostCSS. Будущее после Sass и Less
  • 0
    Давай-те объясню чуть точнее, как работает RTLCSS, чтобы было понятно, почему его нельзя сделать на Sass.

    Вы пишите обычный код для обычного языка и даже не думаете об арабском:

    .menu { left: 10px; text-align: left; }
    


    Потом запускаете RTLCSS и он выдаёт отдельный файл для арабской локали, где будет:

    .menu { right: 10px; text-align: right; }
    


    То есть RTLCSS похож на Автопрефиксер — он сам находит нужный свойства в вашем CSS (те, которые специфичны для лево-право) и заменяет их на обратное значение.

    В Sass у вас просто нет API для сканирования CSS, только то, что явно указал разработчик в качестве примеси (то есть придётся постоянно думать и легко забыть).
    PostCSS. Будущее после Sass и Less
  • +1
    1. Чтобы был универсальный фреймворк для создания CSS-инструментов (PostCSS), так что инструменты будет легче делать
    2. Чтобы все CSS-инструменты строились на основе одного фреймворка — переиспользовали больше кода, меньше конфликтовали
    PostCSS. Будущее после Sass и Less
  • 0
    Не понял. Можете подробнее описать?
    HTTP/2 уже здесь но спрайт-сеты ещё не умерли
  • +1
    Можно проще — положить куку last_request со временем последнего запроса. Если статика изменилась с последнего запроса — шлём новую версию.
    HTTP/2 уже здесь но спрайт-сеты ещё не умерли
  • 0
    Да, хороший вопрос, как делать CDN на базе HTTP/2. Можно сделать в виде прокси-сервера. Клиент подключается в CDN и запрашивает index.html. CDN проксирует запрос на index.html в главные сервера, а сам в это время начинает отдавать статику (по заранее подготовленной сборщиком таблице зависимостей)
    HTTP/2 уже здесь но спрайт-сеты ещё не умерли
  • 0
    «Замену E-Tag» можно сделать через обычный cookie.
    HTTP/2 уже здесь но спрайт-сеты ещё не умерли