Вперше відредагована версія цієї статті з’явилася у випуску 225 журналу .net - найпопулярнішого у світі журналу для веб-дизайнерів та розробників.
@twostepmedia: Де слід робити важкі дії на веб-сторінці? У фронт-енді чи у бекенді?
Леа Веру: Я рішуче прихильник того, щоб робити все, що можна, з клієнтом. Коли ваш код працює на клієнті, він завжди повинен мати справу з однією машиною, незалежно від того, наскільки успішним стане ваш проект.
Все, що ви пишете на сервері, може запустити тисячі разів на секунду, якщо ваш проект увінчається успіхом, тому підтримувати та розширювати його стає все більш складним завданням у міру зростання вашого сайту. Не кажучи вже про зростаючі витрати на розміщення, які дуже рідко можуть бути повністю покриті за рахунок доходу веб-сайту. Звичайно, багато логіки на стороні клієнта може повільно завантажувати сайт, але ми маємо інструменти, щоб цього уникнути, такі як gzipping та obsfucation і, що найголовніше, ліниве завантаження.
@komiska: Ваша робота ВИДИВНА! Хто надихнув вас піти технологічним шляхом?
Л.В .: Дякую! Я не думаю, що мова йшла про те, щоб когось надихнути. Мені просто подобалося робити речі з тих пір, як я пам’ятаю себе. Коли я був дитиною, колись використовував серветки з кухонних губок, щоб робити гаманці та сумочки!
Близько 12 років я виявив, що програмування дозволяє мені будувати корисні речі легше та професійніше, ніж ручна робота. Це мене так зачарувало, що я моментально закохався у програмування і продовжував прагнути покращити його.
@jelmerdemaat: Як @LeaVerou створив @dabblet? З яким фреймворком PHP / іншою технікою заднього плану? Що було найскладнішим?
LV: Dabblet не має бази даних, а код на стороні сервера задіяний мінімальний. Трохи PHP використовується лише для OAuth і створення сторінки результатів для спільного використання без будь-якого хромованого хрому навколо нього (корисно для тестів звітів про помилки). Як ви можете бачити в його статистиці Github, на PHP припадає лише три відсотки дабблетів. Все інше - на стороні клієнта. Це допомагає уникнути ситуації jsfiddle: jsfiddle робить все на сервері, тому тепер, коли це вдалося, його завантаження сервера пройшло через дах, і воно стало повільним.
@_dte: Яка найцікавіша майбутня функція CSS для вас?
ЛВ: Фільтрувати ефекти точно. Вони дозволяють нам робити те, що раніше було неможливо, а не просто важко. Я не дуже схвильований модулями компонування, тому що а) перед тим, як ми зможемо їх використовувати, мине вік, оскільки вони зовсім не погіршуються, б) макет завжди був можливим, просто непотрібно важким. Звичайно, нові модулі макету теж дуже важливі, але мене хвилює не така річ.
Я також дуже захоплений відносними одиницями області перегляду vw і vh і розширення CSS3 attr () функція, яка дозволить нам використовувати attr () в кожному майні.
Я також дуже хотів би бачити інші браузери, крім реалізації Opera об'єкт-придатність і об'єкт-положення, щоб ми могли перестати використовувати фонові хаки для обрізання зображень з іншим співвідношенням сторін.
@gpirie: Яку функцію ви хотіли б бачити в CSS?
ЛВ: А поточний () функція, яка дозволяє посилатися на обчислене значення інших властивостей. Як узагальнення currentColor (який потім став би псевдонімом для струм (колір)). Звичайно, реалізувати таку річ дуже складно, але реальність не завадить мені мріяти!
@kevdog: Які три найпоширеніші помилки CSS?
ЛВ: Найпоширенішою помилкою CSS, яку я бачу, є те, що люди кодують свій CSS з акцентом на результат, а не на чистий, ремонтопридатний, гнучкий код (і вони рідко переробляють). Важливо не тільки те, що щось виглядає прямо зараз, з певним фоном, певним оточенням та певним розміром. Це повинно бути в змозі адаптуватися легко змінюватись, без необхідності переписувати кожне правило про це непередбачуваними способами.
Ви можете подумати, що ніколи нічого не зміните, але, надавши достатньо часу, майже напевно доведеться, що ви помиляєтесь. У цьому можуть допомогти препроцесори CSS. Вони є простим виходом, але вони, безумовно, кращі за недбалий, повторюваний код.
Ще одна помилка - надто багатослівний CSS. Люди не знають про за замовчуванням, тому вони продовжують їх переосмислювати. Вони не знають стенограм, тому натомість продовжують визначати властивості логгена. Бувають випадки, коли ти повинен робити ці речі навмисно, але це не привід робити їх оборонно у всьому.
@kevdog: Якби ви могли змінити щось у специфікації CSS, що б це було?
ЛВ: Є багато припущень, з якими погоджуються майже всі в CSSWG, але не можуть бути додані через порушення існуючого широко розповсюдженого використання в Інтернеті. Зазвичай РГ або взагалі заперечує це, або додає більше властивостей для управління поведінкою, а не змінює за замовчуванням. Я хотів би бачити спосіб увімкнути назад несумісні зміни, щоб існуючі веб-сайти не ламалися. Інші мови давно вирішили цю проблему, але завдяки HTML і CSS ми продовжуємо боротися за зворотну сумісність у вартості хорошого мовного дизайну.
@StuRobson: Як ви думаєте, чи ліниво розробнику використовувати фреймворк або шаблон, волею-неволею, не розуміючи всього, що він робить?
ЛВ: Ні, але я думаю, що розробнику лінь використовувати каркас або шаблон, не маючи особисто потреби, просто тому, що це роблять усі інші. Спроба вирішити проблеми, яких у вас ще немає, контрпродуктивна.
@folktrash: У який момент сталася "знаменитість"? Як ти дізнався? І це допомагає чи заважає євангелізаційній якості / семантиці?
ЛВ: Дякую, але я не впевнений, що мене могли б так називати. Кожен схильний вважати людей, про яких вони чули, більш відомими, ніж люди, про яких вони не мали уявлення. Отже, кожна людина має природну тенденцію завищувати власну славу, яку потрібно штучно (і майже сліпо) врівноважувати, коли ти усвідомлюєш це явище. Також нам слід пам’ятати, що ніхто в нашій галузі насправді не є знаменитістю, ніхто не є іменем.
Тим не менш, 2011 рік був божевільним, і очевидно, що я отримав більше визнання за свою роботу, на яке я міг сподіватися. Це, безумовно, допомагає євангелізувати веб-стандарти. Люди звертають набагато більше уваги, коли я зараз щось кажу, ніж рік тому. Однак це відбувається ціною того, що речі, які я кажу, переоцінюються, люди можуть занадто багато читати в них і нападати на мене за те, що я нібито маю погляди, про які я навіть ніколи не думав. Або іноді, просто за перегляди, крапка.
@Tawreh: Чому ти так фанатично ставишся до жінок у цій галузі? Я розумію необхідність рівності, але ти доводиш це до крайності.
Л. В .: Вперше я чую таке поняття, як "гранична рівність". Рівність ніколи не може бути крайньою, і я сумніваюся, що хтось навіть може сказати щось подібне за інші види дискримінації, такі як расизм. Це "зворотна дискримінація" або "виправлення упередженості", що є крайнім, і я категорично проти цього.
Тим не менш, я взагалі не "фанатичний" щодо жінок у цій галузі, я "фанатичний" проти гендерних стереотипів. Я майже не бачу сексизму в нашій галузі, здається, люди вже давно засвоїли свій урок. Я не думаю, що низька участь жінок у нашій галузі зумовлена тим, що вони вже почуваються небажаними. Це решта нашого гендерного суспільства відганяє жінок від інженерії. Маленькі дівчатка граються з іграшками, які не спонукають їх розвивати свої когнітивні навички так само, як хлопчикові іграшки. Дитячі фільми та іграшки є найгіршим продовжувачем гендерних стереотипів, і я навряд чи бачу там інтерес. Здається, кожен зосереджує свої зусилля на дорослих, замість того, щоб виправляти помилки, а не уникати їх допущення.
@komiska: Чи буде коли-небудь перехід на вагу шрифту?
Л. В .: Цитуючи примітку із специфікації, "це не так просто". У більшості властивостей недостатньо ваг для плавного переходу, і браузер не може генерувати проміжні стани, оскільки немає можливості представити їх у CSS. Тим не менш, ми з часом можемо продовжити перехресне згасання () від CSS4 Image Values застосовуватись до всіх значень CSS, а не лише до зображень, які б вирішили більшість проблем переходу, і дає нам потужний інструмент, який можна використовувати і статично.
