Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 74
Хватит ныть!
Порог вхождения в современный зоопарк веб-технологий от самих методик разработки до конкретных инструментов все выше.
Зарплаты сеньоров все заоблачнее — и это не может не радовать (сарказм)!
Никаких KISS — только фреймворки генерирующие фреймворки на все случаи жизни!
А в итоге все как на картинке:
Зарплаты сеньоров все заоблачнее — и это не может не радовать (сарказм)!
Никаких KISS — только фреймворки генерирующие фреймворки на все случаи жизни!
А в итоге все как на картинке:
Поддержу.
Потеряли, Потеряли… как по мне мы приобрели нечто новое, причем в таком количестве, что это только радует.
Потеряли, Потеряли… как по мне мы приобрели нечто новое, причем в таком количестве, что это только радует.
Раньше люди думали что земля плоская и держится на 3-х китах. Потом — БАЦ — и земля круглая — и даже не в центре вселенной, появилось много разнообразных телескопов, и трудно даже выбрать из всего разнообразия какой тебе подходит — делают они одно и то же, только немного по разному.
Мы фрагментировали и усложнили свое представление о мире. Мы потеряли тот мир! RIP!
Мы фрагментировали и усложнили свое представление о мире. Мы потеряли тот мир! RIP!
И сколько ты не изучай космос и технологии для его изучения, всегда придут новые технологии, которые дадут новые знания о новых объектах и тебе опять придется лезть глубже и глубже в этот стек технологиях. А раньше как все просто было…
просто не было — была куча несовместимых друг с другом технологий, которые не стандартизировались.
сейчас есть стандарты и надстройки над ними — их можно пользовать, можно не пользовать — ну да, работают они по разному, но и решают в основном свои цели (jquery — для простоты, angular — для сложных js приложений, которые работают вживую). Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
сейчас есть стандарты и надстройки над ними — их можно пользовать, можно не пользовать — ну да, работают они по разному, но и решают в основном свои цели (jquery — для простоты, angular — для сложных js приложений, которые работают вживую). Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
*Не надо забывать скрытный тег *
Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
Всё больше народу, который не знает стандарт, а знает лишь свои любимые фреймворки и библиотеки. Скажем, jQuery-программист раньше было шуткой, а теперь реальность. Для поддержки проекта на angular, человеку, писавшему только на jquery, мало поможет его опыт — придется изучать практически всё с нуля.
Web-технологии стали заложниками собственной «стабильности» — они уже давно не удовлетворяют современным потребностям, как по функциональности, так и по программированию оных. Ностальнические технологии «того веба» являются узким местом, которое не решаются реформировать как раз апологеты «совместимости». Но, по-видимому, количество несуразностей ещё не перешло в качественное решение все это разгрести. Опыт HTML5 показывает, что если найдется хороший «локомотив», то остальные дружно согласятся присоединиться к современному поезду.
К сожалению, в W3C сидят не инопланетяне с Сириуса, а те же самые умники, которые занимались браузерными войнами. Можно смело считать, что войны не закончились, а просто перешли в затяжную позиционную фазу. Там по-прежнему каждый тянет одеяло в свою сторону. По-прежнему считают необязательным выполнять предписания совместно принятого стандарта. По-прежнему добавляют вендорные префиксы, особенности реализации. По-прежнему сперва реализовывают в браузерах, а потом ставят всех перед фактом и протаскивают в качестве стандарта.
Причём похоже на то, что во всём W3C нет ни одного верстальщика. Я даже не уверен, что там есть программисты — скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки. Ничем иным просто не объяснить тот факт, что W3C принимает самые дикие, идиотские, неудобные решения, тогда как наиболее типичные случаи вёрстки и программирования до сих пор не покрыты (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:
Причём похоже на то, что во всём W3C нет ни одного верстальщика. Я даже не уверен, что там есть программисты — скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки. Ничем иным просто не объяснить тот факт, что W3C принимает самые дикие, идиотские, неудобные решения, тогда как наиболее типичные случаи вёрстки и программирования до сих пор не покрыты (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:
Мы фрагментировали JavaScript языками, компилируемыми в него.Продукция W3C неюзабельна до такой степени, что приходится придумывать нечто более удобное.
Мы фрагментировали HTML тоннами шаблонизаторов.
Мы фрагментировали CSS препроцессорами наподобие Sass и Less
> скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки
Улыбнуло :)
Улыбнуло :)
как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны
Всё же элементарно! Оборачиваете div в элемент с disply: table-cell;, этот элемент в другой с dsiplay: table;, к внутреннему применяете vertical-align: middle;, а к нужному диву disply: inline-block; и вуаля! Всего пара часов потраченного в пустую времени и уже почти рабочий вариант выравнивания по середине =)
Пользуясь случаем, хотел спросить у верстальщиков, почему табличная верстка это чуть ли не табу в современном вэбе?
То есть я понимаю все прелести идеи «HTML отражает структуру, css отвечает за отображение» и то что таблицы смешивают отображение и структуру данных что эту идею ломает.
Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
То есть я понимаю все прелести идеи «HTML отражает структуру, css отвечает за отображение» и то что таблицы смешивают отображение и структуру данных что эту идею ломает.
Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
Плюсую. Тоже до сих пор этого не понимаю.
У вёрстки на таблицах много особенностей в крайних случаях представления контента (пустые ячейки, диспропорции в заполнении ячеек). При использовании таблиц как каркаса придётся свести их использование к строго ограниченным формам (насколько помню, только одна ячейка в ширину, иначе вылезают краевые особенности). Я это проходил в 2010-м, в новых браузерах могло что-то измениться, но старые всё равно их имеют. Кроме того, дивы гибче в переставлении блоков средствами CSS, хотя тоже не на 100% гибкие.
всё просто. попробуйте перенести сайдбар (скажем, с левой стороны в правую) с помощью одного только CSS в табличной вёрстке и в блочной.
Ясно-понятно что одним css для таблички не обойдешься. Но на блочной, как правило дело так же не ограничивается изменением float или заменой left:5px на right:5px. Тут же выясняется что надо обернуть сайдбар и контент в еще один див, т.к. справа ему хватало относительно позиционированного родителя, а слева уже нет и т.п. И на практике это выливается в то что вам все-равно надо меня шаблон и переносить вывод дочерних элементов в другое место.
Сатанинский смех, а потом вы узнаете что ваш клиент — гос контора которая использует какой-нибудь ужас и ничем другим кроме шестого эксплорера пользоваться не может.
Сатанинский смех, а потом вы узнаете что ваш клиент — гос контора которая использует какой-нибудь ужас и ничем другим кроме шестого эксплорера пользоваться не может.
на практике выливается, что чем опытнее верстальщик, тем лаконичнее вёрстка (без лишних оборачивающих дивов). а чем лаконичнее вёрстка, тем меньше изменений нужно для модификации. а табличную вёрстку лаконичной никогда не назовёшь.
и это я уже не буду говорить про адаптивность, которая является банальным проявлением уважения к пользователям, и которую табличной вёрсткой вы не получите.
и это я уже и не говорю о том, что идейно разметка должна разбивать сайт на смысловые части, а их вид должен абстрагироваться от самих данных, чего табличная вёрстка не даёт.
и это я уже не буду говорить про адаптивность, которая является банальным проявлением уважения к пользователям, и которую табличной вёрсткой вы не получите.
и это я уже и не говорю о том, что идейно разметка должна разбивать сайт на смысловые части, а их вид должен абстрагироваться от самих данных, чего табличная вёрстка не даёт.
Чем отличается DIV от TABLE? Семантика — наше всё! :) Ну и современные браузеры уже позволяют DIV-ы собрать как таблицу (выше пример привели).
В поддержку треда о стандартах W3C и практике.
Попробуйте на досуге указать в xsd что вам нужен набор дочерних элементов встречающихся в любом порядке но с ограничениями на количество. Казалось-бы самый простой вариант.
К примеру нижеприведенные элементы могут следовать в любом порядке но лишь указанное количество раз:
<optinal/> — может встречаться 0 или 1 раз
<optinal-multy/> — может встречаться 0 раз и более
<required/> — строго 1 раз
<required-multy/> — 1 раз и более
С математической точки зрения стандарт полон. Т.е. задать такие ограничения можно. Но на практике это выливается в решение задачек по комбинаторике и записи чуть ли не всех возможных комбинаций sequence и choice.
Попробуйте на досуге указать в xsd что вам нужен набор дочерних элементов встречающихся в любом порядке но с ограничениями на количество. Казалось-бы самый простой вариант.
К примеру нижеприведенные элементы могут следовать в любом порядке но лишь указанное количество раз:
<optinal/> — может встречаться 0 или 1 раз
<optinal-multy/> — может встречаться 0 раз и более
<required/> — строго 1 раз
<required-multy/> — 1 раз и более
С математической точки зрения стандарт полон. Т.е. задать такие ограничения можно. Но на практике это выливается в решение задачек по комбинаторике и записи чуть ли не всех возможных комбинаций sequence и choice.
> (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:
display: flex;
align-items: center;
В современных браузерах работает очень хорошо.
display: flex;
align-items: center;
В современных браузерах работает очень хорошо.
Обычный процесс эволюции. Что в нём страшного? Лучше уж жить в живом хаосе, чем в мёртвой золотой клетке.
На этом пути не надо ограничеватся только клиентским вебом! И сервера мы тоже теряем, смотрите какой беспредел: питон, руби, node.js, asp.net mvc, еще и по нескольку фреймворков у каждого. Нужно вернутся к теплому ламповому PHP (или CGI + bash?) и перестать фрагментировать сервера. Десктопы тоже надо прекращать фрагметировать, не нужно это. Есть же C и Win32 API, зачем этим MFC, WTL, Qt, .NET WinForms, WPF, Java. Переусложения какие-то.
Может автор просто постебал жалобы вроде «веб уже не торт», а я просто не понял.
Может автор просто постебал жалобы вроде «веб уже не торт», а я просто не понял.
Возможно, автор имел в виду немного другое: на протяжении 5-6 лет усиленной стандартизации разработка под Web становилась всё проще и проще. Но в какой-то момент она снова начала становиться сложнее. И это его удручает.
Вся суть поста:
— Вот вам нормальные инструменты вместо этих обрезков технологий для разметки текста
— Нет, хотим дальше жрать говно ложками.
— Вот вам нормальные инструменты вместо этих обрезков технологий для разметки текста
— Нет, хотим дальше жрать говно ложками.
А я верю, что разнообразие — суть эволюции. Да, многие технологии недолговечны, но если они умирают, то они непригодны, и не стоит их содержать на искусственном дыхании. Например, почему мне нужно писать document.getElementsByClassName вместо $(".class"), а затем еще и итерируя, вызывать метод .item(i)? Ведь не составило бы большого труда примерно ту же фунцкциональность таких фреймворков, как jQuery, реализовать нативно. Просто необходимо вдумчиво рассмотреть существующие решения и осторожно их слить во что-то лучшее, при этом минимально, но верно отходя от пережитков — не боясь обратной совместимости. Ведь сейчас никто не напишет document.all['item'].
Почему даже теперь (если я не отстаю от жизни) в CSS нет наследования и примесей, это до сих пор вынуждены делать те же LESS и SASS. Зато появились излишние навороты вроде анимаций, которые, на мой взгляд, больше инкапсулируют (и тщательно от нас скрывают) довольно сложную логику под «разметкой» — и в целом это все очень сильно напоминают стремления инноваций предложить нам две-три кнопки «сделать збс», вместо действительно логично нужных вещей.
И таки да, теперь мы видим кучу вещей, вроде логотипов и мультиков на «чистом html5 и css3», исходник которых еще менее очевиден, чем будучи напсан на js. Но нужно ли это, если теперь без js не будут работать сколь серьезные сайты, а _некоторые_ браузеры вообще выпиливают настройки «запретить js»? Это как гламур — впечатляет, но не насущно.
И если раньше мы имели браузерную войну Netscape\IE\Opera с надписями «best viewed in IE6 800x600», то теперь HTML5 сам раздробился на подмножество себя, и мы, как никогда раньше, имеем фичи, имеющиеся в одних и отсутствующие напрочь в других браузерах.
Хуже того — Win8 IE не включает Flash, а Opera Mini все еще не умеет Ajax, что только затрудняет разработку сайтов, так что приходится использовать все больше библиотек — особенно, учитывая тенденцию веб-приложений все больше подражать дестопным. И это тогда, когда и в помине в вебе не существует что-либо похожее на компоненты, на менеджеры раскладки (layout). Почему так бывает, что текст вполне может «вылезти» за пределы своего контейнера? Почему до сих пор нужно «сбрасывать» стили всякими reset.css? Почему надо использовать хаки и не везде в качестве единиц измерения можно использовать проценты?
Вот где настоящая война, а не одних фреймворков с другими. Скорей, сами библиотеки только помогают хоть как не быть заложниками этой войны, делая простые вещи действительно достижимыми, худо-бедно выполняя первый принцип Веба — кроссплатформенность (и кроссбраузерность).
Почему даже теперь (если я не отстаю от жизни) в CSS нет наследования и примесей, это до сих пор вынуждены делать те же LESS и SASS. Зато появились излишние навороты вроде анимаций, которые, на мой взгляд, больше инкапсулируют (и тщательно от нас скрывают) довольно сложную логику под «разметкой» — и в целом это все очень сильно напоминают стремления инноваций предложить нам две-три кнопки «сделать збс», вместо действительно логично нужных вещей.
И таки да, теперь мы видим кучу вещей, вроде логотипов и мультиков на «чистом html5 и css3», исходник которых еще менее очевиден, чем будучи напсан на js. Но нужно ли это, если теперь без js не будут работать сколь серьезные сайты, а _некоторые_ браузеры вообще выпиливают настройки «запретить js»? Это как гламур — впечатляет, но не насущно.
И если раньше мы имели браузерную войну Netscape\IE\Opera с надписями «best viewed in IE6 800x600», то теперь HTML5 сам раздробился на подмножество себя, и мы, как никогда раньше, имеем фичи, имеющиеся в одних и отсутствующие напрочь в других браузерах.
Хуже того — Win8 IE не включает Flash, а Opera Mini все еще не умеет Ajax, что только затрудняет разработку сайтов, так что приходится использовать все больше библиотек — особенно, учитывая тенденцию веб-приложений все больше подражать дестопным. И это тогда, когда и в помине в вебе не существует что-либо похожее на компоненты, на менеджеры раскладки (layout). Почему так бывает, что текст вполне может «вылезти» за пределы своего контейнера? Почему до сих пор нужно «сбрасывать» стили всякими reset.css? Почему надо использовать хаки и не везде в качестве единиц измерения можно использовать проценты?
Вот где настоящая война, а не одних фреймворков с другими. Скорей, сами библиотеки только помогают хоть как не быть заложниками этой войны, делая простые вещи действительно достижимыми, худо-бедно выполняя первый принцип Веба — кроссплатформенность (и кроссбраузерность).
Opera Mini не умеет Ajax не все еще, а by design, она же рассчитана на супер-медленный gprs.
А разве один из плюсов Аякса не как раз уменьшение трафика? Вместо перезагрузки полностью отрендереренной (на сервере в html) страницы, загружать только изменяющиеся данные?
В общем случае конечно уменьшает, но Мини работает с obml-форматом, который она получает от серверов Оперы. Так что результат аякс-запроса всё равно приходит сначала на большой сервер, потом сжимается и только потом попадает в телефон, на котором обновляется вся страница. Но в итоге по трафику получается всё равно выгода. Вот тут, например, можно почитать более детально: dev.opera.com/articles/view/opera-binary-markup-language/
И плюсом идёт тот факт, что современный жаваскрипт на тех старых телефонах, на которых идёт мини, тормозил бы беспощадно.
И плюсом идёт тот факт, что современный жаваскрипт на тех старых телефонах, на которых идёт мини, тормозил бы беспощадно.
Вот к примеру то, что архитекторы CSS пре-процессора сообщают о принципах конструирования Sass:Автор (John Allsopp) почему-то остановился и не доцитировал :)Не существует формального процесса, по которому мы добавляем новые функции в Sass. Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, Twitter, сообщения в блоге, из других компиляторов CSS, или любого другого источника.…которые, скорее, напоминают Гомера
Ниже полная цитата — точнее, последние два предложения, одно из которых (в корне меняющее смысл) опущено Джоном:
Good ideas can come from anyone from anywhere and we’re happy to consider them from the mailing list, IRC, twitter, blog posts, other css compilers, or any other source. However, most of the time we end up saying no.Что переводится:
Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, твиттера, блогов, других компиляторов CSS, или любого другого источника. Однако в большинстве случаев мы в конце концов скажем «нет».
Давайте уясним одну вещь, стандарты нужны были для браузеров, для того чтобы они поддерживали один стандарт рендеринга. С этим то сейчас полно работы. Если препроцессор или язык-транслятор в js могут развиваться без бюрократических процедур принятия стандартов, то JS, CSS, HTML не могут. Поэтому у таких технологий огромное преимущество в развитии. И статья правда похожа на нытье.
А чем плоха фрагментация?
Конечно, надо было сразу сделать все по правильному. Но мне нравится, что сосуществуют разные подходы, такие как CoffeeScript и Fay, а не какой-то один фиксированный язык или технология.
Конечно, надо было сразу сделать все по правильному. Но мне нравится, что сосуществуют разные подходы, такие как CoffeeScript и Fay, а не какой-то один фиксированный язык или технология.
Занятно, что автор в самом конце упомянул переход от документов и сайтов к приложениям, но ничего не сказал о том, что именно этот переход, по сути, и есть главный источник того, что он называет «потерей Web».
HTML, CSS и JS изначально были и в очень большой степени остаются средствами создания документов (пусть и очень интерактивных теперь), а то, что путем наращивания вокруг них всего перечисленного автором великолепия их удалось заставить быть средствами обеспечивающими визуальное представление и логику приложений — это просто так вышло.
Про зоопарк в UX/UI автор тоже умолчал как-то (это изначально тоже входило в интересы W3C). Хотя технологический зоопарк в Web происходит от специфических требований к UX/UI где-то на половину, а то и на две трети.
Диалектично, что в desktop-приложениях сейчас интерфейсы выглядят на несколько порядков более единообразно, чем в web-приложениях, хотя технически, свободы у desktop-разработчиков «чуть больше». И это всего лишь результат требований заказчиков, а вовсе не технологических обстоятельств.
HTML, CSS и JS изначально были и в очень большой степени остаются средствами создания документов (пусть и очень интерактивных теперь), а то, что путем наращивания вокруг них всего перечисленного автором великолепия их удалось заставить быть средствами обеспечивающими визуальное представление и логику приложений — это просто так вышло.
Про зоопарк в UX/UI автор тоже умолчал как-то (это изначально тоже входило в интересы W3C). Хотя технологический зоопарк в Web происходит от специфических требований к UX/UI где-то на половину, а то и на две трети.
Диалектично, что в desktop-приложениях сейчас интерфейсы выглядят на несколько порядков более единообразно, чем в web-приложениях, хотя технически, свободы у desktop-разработчиков «чуть больше». И это всего лишь результат требований заказчиков, а вовсе не технологических обстоятельств.
VanillaJS framework не содержит консервантов и генномодифицированных продуктов.
Вспомнилось ) 
О чем он?
Я каждый день благодарю бразузерных богов:
За то, что мне не нужно помнить что в ie-дивы, а в nn — слои.
Что я могу использовать разные фреймворки для разных задач.
Что я могу написать приложение для своего телефона (или телевизора), плагин для браузера, скрипт для arduino, или серверный код используя одни и те же технологии.
Что каждый раз когда я сохраняю файл в течении 5 секунд я получаю ошибку, если тесты перестают работать хотя бы в одном браузере.
Что все различия в браузерах зорошо задокументированы и даже если я сомневаюсь, что именно сломалось, я могу найти фикс / полифил за 5 минут.
Что я могу писать код используя любой CSS пре-процессор, вкладывать селекторы в селекторы, использовать переменные и миксины.
Что исходные коды большинства браузеров открыты.
Что разработчики осознают, что не время останавливаться и в результате появляются штуки типо этого: extensiblewebmanifesto.org/
Расскажи мне кто-то в конце 90х, о том как все будет сегодня, я бы уже шел искать криогенную камеру.
Я каждый день благодарю бразузерных богов:
За то, что мне не нужно помнить что в ie-дивы, а в nn — слои.
Что я могу использовать разные фреймворки для разных задач.
Что я могу написать приложение для своего телефона (или телевизора), плагин для браузера, скрипт для arduino, или серверный код используя одни и те же технологии.
Что каждый раз когда я сохраняю файл в течении 5 секунд я получаю ошибку, если тесты перестают работать хотя бы в одном браузере.
Что все различия в браузерах зорошо задокументированы и даже если я сомневаюсь, что именно сломалось, я могу найти фикс / полифил за 5 минут.
Что я могу писать код используя любой CSS пре-процессор, вкладывать селекторы в селекторы, использовать переменные и миксины.
Что исходные коды большинства браузеров открыты.
Что разработчики осознают, что не время останавливаться и в результате появляются штуки типо этого: extensiblewebmanifesto.org/
Расскажи мне кто-то в конце 90х, о том как все будет сегодня, я бы уже шел искать криогенную камеру.
Меня больше беспокоит, что веб скатывается в бездну картиночек, тупых видео и статусов в социальных сетях
а должен быть только код, код, и ещё раз код!
Об этом — как раз статья, на которую ссылается автор и часто цитирует: dashes.com/anil/2012/12/the-web-we-lost.html «The Web We Lost», Anil Dash (December 13, 2012)
Если бы стандарт, который я придумал всё время пытались допились, я бы серьезно призадумался над его качеством, удобством и соответствием нуждам.
Автор путает серверную сторону и браузерную (а препроцессоры живут, как правило, на сервере). А то во времена старого веба все до единого писали на PHP? Не было ни разных языков, ни разных баз данных?
Кроме того, стоит понимать, что путем нагромождения зоопарка из тысяч библиотек, сообщество отсеет действительно хорошие и универсальные идеи и рано или поздно стандартизует их. Эволюция так и происходит — миллионами мутаций, из которых действительно удачных немного. И вполне возможно, что когда-нибудь jquery-селекторы будут реализованы в ядре javascript. Но на всё нужно время.
Кроме того, стоит понимать, что путем нагромождения зоопарка из тысяч библиотек, сообщество отсеет действительно хорошие и универсальные идеи и рано или поздно стандартизует их. Эволюция так и происходит — миллионами мутаций, из которых действительно удачных немного. И вполне возможно, что когда-нибудь jquery-селекторы будут реализованы в ядре javascript. Но на всё нужно время.
а препроцессоры живут, как правило, на сервере
Разве препроцессоры живут обычно не на дев-машине, а на сервер билд-системой деплоится нормальный html/css/js?
jquery-селекторы будут реализованы в ядре javascript
И что они там будут выбирать? DOM в ядре нет.
Все знают, что плохие программисты будут в аду работать на Perl'e.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мы потеряли тот Веб