Само собой, JSX продиктован тем, как устроен React, и в контексте React он может быть предпочтительнее.
Опять таки согласен с коротким HTML, в этом случае может быть вполне резонно, но даже сниппет в статье как по мне уже больше оптимального, для внедрения в JS, размера.
Jade сам по себе может сослужить достаточно мощным DSL, без ущерба читаемости.
Вот сравните jade (379 байт) с html (2176 байт) (желательно отформатировать, чтобы увидеть масштаб преобразований).
Там форма с 7 параметрами конфигурации и в Jade это легко понять. Не сложнее устроен и лежащий рядом JS файл, который использует общие с другими формами абстракции. Но HTML как раз получается достаточно объемным.
Да, можно создать такие контролы в виде отдельных элементов, но это будут слишком большие накладные расходы для подобной задачи.
Как бы вы решили подобную задачу в React? Элемент загружает данные из API в форму, и при сохранении отправляет те же данные с изменениями обратно.
Всё начинается с утверждения что шаблоны это данные, но это только если это строки.
Если же мы используем возможности веб-платформы, то строки превращаются в реальную DOM, которую не мы парсим вручную, а браузер самостоятельно:
Импользование template string вместо <template> элемента значит, что вы игнорируете возможности платформы, которые могут помочь вам распарсить кусок DOM заблаговременно, тем самым увеличив производительность.
А по сравнению с прошлым примером, кода стало меньше за счет удаления прослойки, которая готовила данные в шаблон.
Разница в 8 строк. Но если в первом случае когнитивная нагрузка при работе с файлами небольшая, то с JSX (имхо) когнитивная нагрузка сильно возрастает. К тому же, сама разница в количестве строк по большей части обусловлена самим React. К примеру, в Polymer подобное:
{{#if isOverLimit}}
{{warningText}}
{{/if}}
я решил кастомным методом if:
[[if(isOverLimit, warningText)]]
При чем я его могу таким образом использовать и для аттрибутов, и для свойств DOM элементов, сравните:
Синтаксис сравним по читаемости к template string, такой же краткий, и при этом в HTML формате, позволяя использовать для обработки возможности платформы.
А ещё можно писать не HTML, а Pug/Jade, где читаемость становится ещё лучше (нужно знать синтаксис, но мне кажется, зная CSS вам не составит труда понять что тут происходит):
Если в ход идут миксины, тогда разница становится ещё больше.
В итоге, мне кажется, JSX делает всё только хуже, не позволяя использовать сторонние инструменты вроде Pug/Jade и, по сути, больше решает проблемы синтаксиса самого React.
Ну извините, 8 год не каждый HDD выдержит, а тут ещё и пионеры среди SSD моделей, тем более, явно не самые качественные (учитывая бюджетность аппарата в целом). Все эти трюки для современных SSD (возрастом год 5, не больше) при регулярном выполнении trim не нужны (постоянно включенный trim сильно просаживает производительность).
У меня раз в неделю (иногда реже) full trim под Linux запускается по расписанию. Был SiliconPower Velox V20 с осени 2011 до начала 2015 проработал без заметной просадки скорости, а однажды просто не вышел из спящего режима и перестал определяться системой. Диск SATA2, ещё и с проблемным (судя по отзывам) поколением контроллера.
Так что запустите full trim (должна быть фирменная утилита под Windows) и скорость должна по большей части вернуться.
Покажите мне пальцем хоть на одного пользователя, у которого износился в десктопе/ноутбуке SSD. В смысле износились ячейки, а не внезапно умер контроллер (как это обычно бывает).
У меня глаза кровоточат от исходников. Чувак, ну почитай уже книги чистый или совершенный код.
Вы не поверите, я читал Макконнелла. От корки до корки.
Как этим пользоваться?
Читать документацию для начала, наверное. Статьи можно здесь, на хабре, если с английским туго.
Почему не camelCase в стилях?
В стилях? Потому что 1) Мне не нравится camelCase в целом 2) В CSS более обще принято разделять дефисами и не это кажется эстетически более привлекательным.
Твой пример $Mail->send_to(....) — тут переменная с большой буквы, а имя метода почему-то с маленькой.
А с чего бы им быть одинаковыми? Объекты почти всегда с большой, методы/функции и свойста/переменные почти всегда маленькими буквами. В чём проблема-то?
Пакеты иду идут с маленькой буквы, потом уякс — с большой.
Пакеты О_о?
методы почти везде по 40+ строк, рефакторь, разделяй логику.
У вас религия не позволяет иметь 40+ строк в методе? У меня таких проблем нет.
Удали нафиг .idea из репы, зачем она там?
А вы зайдите в папку и посмотрите что за файлы там лежат. Не будете задавать глупых вопросов и считать меня дураком.
Ты уверен в смысле фразы … fast… framework? Пишешь здесь в примере на одной строчке в одинарных кавычках, а в следующей в двойных, которые заведомо медленнее в силу специфики обработки.
Конечно уверен, я в одной статье даже независимые бенчмарки приводил. Если в вашем коде есть измеримая разница в производительности после замены двойных кавычек на одинарные с конкатенацией — то примеры в студию, иначе это глупости и пустые разговоры. А вот читабельность в подобных примерах сильно выигрывает от двойных кавычек.
Залез в первый случайный файл /core/traits/Permission/Any.php — чувак, это п**здец. Потерял зрения сразу от встроенного SQL запроса. Все, дальше не выносимо смотреть.
Могу приписать почитать какую-нибудь книжку по SQL, облегчит последствия и следующий раз не потеряете сознание.
Со скоростью уверен там будут большие проблемы.
Это уже даже смешно становится:) Раз так уверены, то давайте пример того, что вы считаете быстрым full-stack фреймворком? Только не пишите подобную чушь, давайте бенчмарки, какие-то подтверждения.
В общем вердикт — изучай глубже язык, оптимизируй структуры, обязательна к прочтению книга «Чистый Код» Мартин Р., обязательно больше читать про архитектуру проектов, слабую связанность компонентов… Больше практики на простых проектах, а не замахиваться на то, в чем слабое понимание.
Я вам тоже советую изучать язык. Это может помочь в будущем не писать чушь про кавычки.
Если так хочется сделать фрэймворк, то сделай проще, но с какой-то супер идеей, то, что очень нужно и просто реализуется, но мало где есть или вообще пока такого не сделали, в общем какой-то креатив нужен и тогда народ потянется.
Давайте вы сначала посмотрите документацию, потом сравните с, предположим, Symfony, а потом вернетесь и мы поговорим предметно что проще и что быстрее предметно, а не зазубренными книжными фразами. Контакты мои найти очень просто, всегда рад пообщаться.
И принимай во внимание местные комменты, они в 99% говорят чего реально не хватает или нужно переделать, и не нужно спорить. Если нет реальных аргументов, то переделай — будет больше пользы.
Не нужно спорить? Серьезно, завязывайте свои догмы транслировать, включите мышление, проявите упомянутый вами креатив и осмысление получаемой извне информации.
Конфигурация пишется однажды при создании класса и на основании того, какая у вас структура таблицы. Здесь проблемы нет.
Для чтения и записи данных вы можете сделать удобные обертки со специфичным для конкретной ситуации интерфейсом, заучивать ключи совершенно не нужно.
Это могут быть просто аргументы:
public function set (int $id, string $title, string $content) {
return $this->update($id, $title, $content);
}
Или value object если пожелаете:
public function set (PostInterface $post) {
return $this->update($post->toArray());
}
cs\CRUD делает оба случая возможными, но это вещь, используемая под капотом, поэтому методы данного трейта имеют видимость protected, и им не обязательно знать что-либо об используемых выше объектах.
Также использование под капотом более простых структур данных может быть выгодным с точки зрения количества используемой памяти и производительности, в то время как оптимизация более накладных структур под капотом является невозможной.
Под капотом всё равно SQL. Я вот теперь тоже если что буду как @ MetaDone кидать линк на Aura.SqlQuery — очень добротно выглядит, и никаких проблем использовать с CleverStyle Framework (как и с любым другим).
Всё верно. Фреймворк предоставляет низкоуровневые интерфейсы, которые, тем не менее, достаточно функциональны из коробки (согласитесь, не так часто запрос собирается динамически), и при этом является высокопроизводительным.
На базе этих примитивов можно делать что угодно, к примеру, ниже в комментариях интересный пример с Aura.SqlQuery.
Задача в том, чтобы найти здоровый баланс между самым низким уровнем и огромным количеством абстракций, когда уже не понятно что на самом деле происходит под капотом (к примеру, были у меня несколько раз проблемы с Doctrine во время обновления ownCloud — она неправильно определяла версию СУБД и составляла более изощренные запросы, которые в конкретной версии СУБД ещё не поддерживались, приходилось миграции вручную запускать в консоли; понять что идет не так и где было весьма проблематично).
Как мне выдернуть Ваше творение в свой проект не на CleverStyle Framework?
Во-первых как вы уже упомянули есть куча автономных пакетов, а у CleverStyle Framework цель гибридное, но оптимальное ядро. Соответственно, хотя части и можно разнести по пакетах, есть сомнения, что в этом есть практический смысл.
Практически вся упомянутая в статье логика содержится в четырех классах в core/engines/DB (один общий абстрактный класс и по одному на каждую СУБД). Из специфичного для фреймворка там только использование константы DEBUG. Всё остальное никак не привязано к фреймворку.
Отдельно стоит класс cs\DB, который уже привязан к фреймворку. Он занимается определением того, какую конфигурацию использовать для подключения к БД и управляет соединениями (там же простая балансировка).
Само собой, JSX продиктован тем, как устроен React, и в контексте React он может быть предпочтительнее.
Опять таки согласен с коротким HTML, в этом случае может быть вполне резонно, но даже сниппет в статье как по мне уже больше оптимального, для внедрения в JS, размера.
Jade сам по себе может сослужить достаточно мощным DSL, без ущерба читаемости.
Вот сравните jade (379 байт) с html (2176 байт) (желательно отформатировать, чтобы увидеть масштаб преобразований).
Там форма с 7 параметрами конфигурации и в Jade это легко понять. Не сложнее устроен и лежащий рядом JS файл, который использует общие с другими формами абстракции. Но HTML как раз получается достаточно объемным.
Да, можно создать такие контролы в виде отдельных элементов, но это будут слишком большие накладные расходы для подобной задачи.
Как бы вы решили подобную задачу в React? Элемент загружает данные из API в форму, и при сохранении отправляет те же данные с изменениями обратно.
Всё начинается с утверждения что шаблоны это данные, но это только если это строки.
Если же мы используем возможности веб-платформы, то строки превращаются в реальную DOM, которую не мы парсим вручную, а браузер самостоятельно:
И это будет более производительно, чем манипуляции со строками.
Импользование template string вместо
<template>элемента значит, что вы игнорируете возможности платформы, которые могут помочь вам распарсить кусок DOM заблаговременно, тем самым увеличив производительность.Разница в 8 строк. Но если в первом случае когнитивная нагрузка при работе с файлами небольшая, то с JSX (имхо) когнитивная нагрузка сильно возрастает. К тому же, сама разница в количестве строк по большей части обусловлена самим React. К примеру, в Polymer подобное:
я решил кастомным методом if:
При чем я его могу таким образом использовать и для аттрибутов, и для свойств DOM элементов, сравните:
Синтаксис сравним по читаемости к template string, такой же краткий, и при этом в HTML формате, позволяя использовать для обработки возможности платформы.
А ещё можно писать не HTML, а Pug/Jade, где читаемость становится ещё лучше (нужно знать синтаксис, но мне кажется, зная CSS вам не составит труда понять что тут происходит):
Если в ход идут миксины, тогда разница становится ещё больше.
В итоге, мне кажется, JSX делает всё только хуже, не позволяя использовать сторонние инструменты вроде Pug/Jade и, по сути, больше решает проблемы синтаксиса самого React.
Ну извините, 8 год не каждый HDD выдержит, а тут ещё и пионеры среди SSD моделей, тем более, явно не самые качественные (учитывая бюджетность аппарата в целом). Все эти трюки для современных SSD (возрастом год 5, не больше) при регулярном выполнении trim не нужны (постоянно включенный trim сильно просаживает производительность).
У меня раз в неделю (иногда реже) full trim под Linux запускается по расписанию. Был SiliconPower Velox V20 с осени 2011 до начала 2015 проработал без заметной просадки скорости, а однажды просто не вышел из спящего режима и перестал определяться системой. Диск SATA2, ещё и с проблемным (судя по отзывам) поколением контроллера.
Так что запустите full trim (должна быть фирменная утилита под Windows) и скорость должна по большей части вернуться.
Он наверное из тех самых-самых первых SSD. Им данная статья (тем более на такой машинке) тоже ничем не поможет.
Full trim давно делали?
ssl.verify_peer в поддерживаемых версия PHP (5.6+) уже по-умолчанию true, и это здорово, ибо очень не многие указывали этот параметр явно
Покажите мне пальцем хоть на одного пользователя, у которого износился в десктопе/ноутбуке SSD. В смысле износились ячейки, а не внезапно умер контроллер (как это обычно бывает).
Опять темная тема сломалась:( Как же теперь это читать...
Смущает что в Firefox ничего не изменилось:( У всех остальных видны улучшения.
И чем же вашему пользованию клавиатурой помешают улучшения, предлагаемые в топике?
Каким образом это противоречит содержимому статьи?
Вы не поверите, я читал Макконнелла. От корки до корки.
Читать документацию для начала, наверное. Статьи можно здесь, на хабре, если с английским туго.
В стилях? Потому что 1) Мне не нравится camelCase в целом 2) В CSS более обще принято разделять дефисами и не это кажется эстетически более привлекательным.
А с чего бы им быть одинаковыми? Объекты почти всегда с большой, методы/функции и свойста/переменные почти всегда маленькими буквами. В чём проблема-то?
Пакеты О_о?
У вас религия не позволяет иметь 40+ строк в методе? У меня таких проблем нет.
А вы зайдите в папку и посмотрите что за файлы там лежат. Не будете задавать глупых вопросов и считать меня дураком.
Конечно уверен, я в одной статье даже независимые бенчмарки приводил. Если в вашем коде есть измеримая разница в производительности после замены двойных кавычек на одинарные с конкатенацией — то примеры в студию, иначе это глупости и пустые разговоры. А вот читабельность в подобных примерах сильно выигрывает от двойных кавычек.
Могу приписать почитать какую-нибудь книжку по SQL, облегчит последствия и следующий раз не потеряете сознание.
Это уже даже смешно становится:) Раз так уверены, то давайте пример того, что вы считаете быстрым full-stack фреймворком? Только не пишите подобную чушь, давайте бенчмарки, какие-то подтверждения.
Я вам тоже советую изучать язык. Это может помочь в будущем не писать чушь про кавычки.
Давайте вы сначала посмотрите документацию, потом сравните с, предположим, Symfony, а потом вернетесь и мы поговорим предметно что проще и что быстрее предметно, а не зазубренными книжными фразами. Контакты мои найти очень просто, всегда рад пообщаться.
Не нужно спорить? Серьезно, завязывайте свои догмы транслировать, включите мышление, проявите упомянутый вами креатив и осмысление получаемой извне информации.
Конфигурация пишется однажды при создании класса и на основании того, какая у вас структура таблицы. Здесь проблемы нет.
Для чтения и записи данных вы можете сделать удобные обертки со специфичным для конкретной ситуации интерфейсом, заучивать ключи совершенно не нужно.
Это могут быть просто аргументы:
Или value object если пожелаете:
cs\CRUDделает оба случая возможными, но это вещь, используемая под капотом, поэтому методы данного трейта имеют видимостьprotected, и им не обязательно знать что-либо об используемых выше объектах.Также использование под капотом более простых структур данных может быть выгодным с точки зрения количества используемой памяти и производительности, в то время как оптимизация более накладных структур под капотом является невозможной.
Я следующие слушаю регулярно:
Под капотом всё равно SQL. Я вот теперь тоже если что буду как @ MetaDone кидать линк на Aura.SqlQuery — очень добротно выглядит, и никаких проблем использовать с CleverStyle Framework (как и с любым другим).
Всё верно. Фреймворк предоставляет низкоуровневые интерфейсы, которые, тем не менее, достаточно функциональны из коробки (согласитесь, не так часто запрос собирается динамически), и при этом является высокопроизводительным.
На базе этих примитивов можно делать что угодно, к примеру, ниже в комментариях интересный пример с Aura.SqlQuery.
Задача в том, чтобы найти здоровый баланс между самым низким уровнем и огромным количеством абстракций, когда уже не понятно что на самом деле происходит под капотом (к примеру, были у меня несколько раз проблемы с Doctrine во время обновления ownCloud — она неправильно определяла версию СУБД и составляла более изощренные запросы, которые в конкретной версии СУБД ещё не поддерживались, приходилось миграции вручную запускать в консоли; понять что идет не так и где было весьма проблематично).
Во-первых как вы уже упомянули есть куча автономных пакетов, а у CleverStyle Framework цель гибридное, но оптимальное ядро. Соответственно, хотя части и можно разнести по пакетах, есть сомнения, что в этом есть практический смысл.
Практически вся упомянутая в статье логика содержится в четырех классах в core/engines/DB (один общий абстрактный класс и по одному на каждую СУБД). Из специфичного для фреймворка там только использование константы
DEBUG. Всё остальное никак не привязано к фреймворку.Отдельно стоит класс cs\DB, который уже привязан к фреймворку. Он занимается определением того, какую конфигурацию использовать для подключения к БД и управляет соединениями (там же простая балансировка).
Согласен, в таком контексте есть преимущество, спасибо за пример