Что-то в этом вебе слишком много всего

Я к тому что таки мы можем быть в подобной «яме» по «менюшкам». Т.е. может быть даже станет в некотором смысле «заметно лучше» если починить все менюшки на которые жалуется Денис.

ну вот на а/б тестирование не нужно забивать ибо бывают случаи когда например мнение дизайнеров/пиарщиков оказывается менее эффективным чем рандом. все желательно проверять и исследовать если на это есть ресурсы. тогда и ям будет меньше.

а так думаю мы пришли к одинаковому мнению.

Не исчезнувшее меню наблюдал на днях на сайте леруа-мерлен (мышку в сторону убрал и оно не исчезло; но этот эффект наблюдается не всегда)

У меня на luakit там всё работает. Может, это было связано с разовым подвисанием оперы?

Не перемасштабирующееся меню - это ок, но в чём же тогда смысл адаптивности.

Ну это, мне кажется, ты, как программист, должен понимать. Очевидно же, что само по себе ничего не делается. При изменении размеров происходит некоторое событие и посылается сигнал (либо вызывается callback, либо ты сам в цикле отлавливаешь это событие, как в низкоуровневых API XWindow или Windows, в зависимости от реализации). Т. е. если ты прикрутишь к своей страничке javascript, который будет реагировать на это событие и уменьшать или увеличивать шрифт и размеры меню, то оно начнёт масштабироваться. Другой вопрос, насколько это нужно. Ведь так ты можешь в одних случаях получить настолько микроскопический текст, что никто его не сможет прочесть даже через лупу, а в других — необоснованно огромные буквы. Имхо, разумнее ориентироваться на разрешение и размеры экрана и примерно подбирать шрифт и размеры для того или иного класса девайсов. Классов этих, по большому счёту, всего 2: телефоны и компы. Планшеты занимают промежуточное положение, и их можно отнести как к одним, так и к другим.

Вполне можно обойтись и без выпадающих меню.

Тоже верно. В большинстве случаев это не более, чем выпендрёж, и традиционных гиперссылок вполне достаточно.

Тошнит от современного веба, тяжелый, тормозной, переусложненный и от того глючный. Но не вижу ему альтернатив, которые устроили бы всех.

Я думаю, что лёгкая, не тормозная и не переусложнённая альтернатива устроила бы всех... ну разве что кроме впаривателей нового всё более дорогого железа.

Да, в 90-е интернет-магазинов, по-моему, не было

Были конечно же.

Возможно. Я точно не помню. Помню только, что сам в то время ими не пользовался.

Естественно, никакой скриптоты на клиенте для магазина даром не нужно.

Вот это точно.

одной из задач было сделать сайт собираемым из повторно используемых компонент

меня достал vue.js и я не буду его использовать на своём сайте

Если речь идёт об однократном написании повторяющегося html-кода на разных страничках, автоматически включающегося в них, то есть ещё такая простая и понятная штука, как ssi. Но она должна работать на стороне сервера, так что тут многое зависит от хостинга. Просто создаёшь файл *.shtml и включаешь в него #include'ами другие html'ки.

Открой для себя тот факт, что в 2018 году, адаптивность интерфейса зависящаяя от масштабов\размеров окна\вьюпорта, по большей части реализуется средствами CSS.

Сидят тут щебечут об ущербности и тормознутости веба, а сами собираются размер шрифта менять с помощью js.

Так вы этот веб и пишете ущербным, потому что не умеете и не хотите учиться.

Сидят тут щебечут об ущербности и тормознутости веба, а сами собираются размер шрифта менять с помощью js.

Я как раз советовал использовать css и не масштабировать шрифты при каждом изменении окна, ограничившись 2 — 3 его состояниями. Перечитай мой пост ещё раз.

Так вы этот веб и пишете ущербным

Я вообще не пишу веб, кроме пары сайтов-визиток, сделанных для друзей, которых в этом вашем вебе уже и нет. И я этого не скрывал с самого начала. Перечитай мои первые посты в этом треде.

Шрифты надо масштабировать! В обе стороны. Но не жсом, как ты писал. А css. Без применения js вообще.

Шрифты надо масштабировать! В обе стороны.

При каждом изменении окна? Категорически не согласен. Впрочем, на вкус и цвет товарища нет.

Но не жсом, как ты писал. А css.

А можешь привести код css, который реагирует на любое изменение размеров окна браузера? Я не собираюсь тебя ловить на брехне, мне просто действительно это интересно.

media queries

Помимо media queries, который может реагировать не только на изменение размеров окна, а вообще на множество вещей, от ориентации экрана, до того, что поддерживает браузер, есть еще calc который может зависеть от размеров блоков. Есть относительные единицы измерения - em\rem\wh\vh\%, а не абсолютные px\pt.

И это все при том, что CSS на нормальных ОС исполняется на GPU, в то время как js на CPU.

media queries

Так там как раз используются минимальные и максимальне, а не плавающие границы. Т. е. несколько фиксированных состояний. Как раз то, о чём я говорил.

calc

Вот за наводку на эту штуку спасибо.

относительные единицы измерения - em\rem\wh\vh\%, а не абсолютные px\pt.

Можно, конечно, и с ними заморачиваться, но порой это бывает очень муторно. Имхо, фиксированные размеры в большинстве случаев ведут себя более предсказуемо даже на разных экранах и разрешениях. Особенно когда речь идёт о размерах шрифта. Для больших блоков относительными размерами пользоваться можно. А шрифты, имхо, проще примерно вычислить для нескольких типов и ориентаций экранов, а дальше пусть пользователь сам донастраивает под себя средствами пользовательского интерфейса браузера. Для всех всё равно заранее не угадаешь. Одни плохо видят, и им удобнее огромные буквы, а других эти огромные буквы размером в четверть экрана будут шокировать и раздражать.

в большинстве случаев ведут себя более предсказуемо даже на разных экранах и разрешениях

Сразу видно, что ты не верстал под high DPI и не имел дело с ретина-дисплеями

не имел дело с ретина-дисплеями

Даже слова такого не знал. Всегда был далёк от мира Apple. И что, там на 300 dpi при использовании pt обычных размеров получаются микроскопические буквы? Потому что на принтерах 300 и даже 600 dpi буквы получаются нормальные.

По большей части - да, а вот почему-то есть bootstrap.css и bootstrap.js.

jquery тоже есть.

Ты дурачок какой-то. Честное слово.

Мне нужно что-то типа m4, но для веба. И, видимо, логично его написать на js. Он должен понимать html, js и css, т.е. работать на уровне синтаксического дерева, а не на уровне текста. Т.е. вызов макроса должен выглядеть как html тэг, а его аргументы - это либо атрибуты, либо начинка. У меня уже руки чешутся такой написать, но я просто не могу поверить, что такого ещё нет. И потом сделать из него loader для webpack.

ssi слегка недотягивает.

Чем тебя языки серверных шаблонов не устраивают, можешь объяснить? Jade/pug, haml, slim, вот это всё.

Они всем хороши, но у них есть один фатальный недостаток.

Мне нужно что-то типа m4, но для веба

Помимо упомянутых webcomponents, есть ещё и более традиционные stylesheets, которые, конечно, тоже не дотягивают до m4, но всё-таки позволяют описать в одном месте много параметров оформления, как то шрифты, цвета, размеры, отступы, позиционирование и т. д., а потом обращаться к ним одним словом.

логично его написать на js

Только при использовании js всегда нужно помнить 2 вещи:

1. У пользователя может быть открыто много вкладок с другими js на не самом сильном процессоре. Тогда твой сайт начнёт тормозить, и пользователь будет от него плеваться.
2. Пользователь может просто выключить у себя js. И это не в теории. Я реально знаю таких людей.

Поэтому, имхо, по возможности лучше обходиться вообще без скриптов, а если без них никак, то лучше, чтоб они, опять же, по возможности работали на сервере. Там, по крайней мере, их никто кроме тебя не отключит, а если сервер окажется слабоват, всегда можно поменять хостинг или доплатить за доп. память, выделенные процессоры и т. д. Это, конечно, может стоить денег, но по крайней мере ты можешь хоть как-то контролировать этот процесс. А на машине сёрфера ты вообще ничего контролировать не можешь.

Мне нужно что-то типа m4, но для веба.

Ура, Денис изобрел PHP!

pug - только для html, а код веб-страницы содержит 3 разных языка. Как шаблонизировать два остальных? Это во-первых. Во-вторых, выгода от такой замены синтаксиса вызывает большие сомнения. Подход vue, когда шаблоны представляют из себя куски html, выглядит гораздо приятнее. Кроме того, pugjs.org у меня не открывается. Остальные пока не смотрел.

Я так понял, webcomponents - это пока фантазии и эксперименты. В России одна вакансия.

Но ведь уже решили этот вопрос. Сегодня и html, и css и js описывается на одном единственном языке. На JS.

это пока фантазии и эксперименты

Это стандарт, лол. Все лишь ждут его полной поддержки браузерами. В большинстве он уже реализован, там где нет используют полифилы.

Поэтому, имхо, по возможности лучше обходиться вообще без скриптов

Я пока наивно планирую иметь 2 версии сайта - с js и без. У gmail была (и может быть по сей день есть) «лёгкая» версия почты. В целом же js сегодня является стандартом и многие вещи без него либо никак не сделать, либо это неадекватно трудоёмко.

Спасибо, я википедию прочитал. Ждать мне не нужно, мне нужны технологии, которые могут меня кормить сегодня.

Не понял. Ты имеешь в виду генерацию документа на клиентской стороне или что-то ещё?

Мне нужно что-то типа m4, но для веба. ... но я просто не могу поверить, что такого ещё нет

обзорно. Чего из этого тебе не так ...

На какой угодно стороне. CSS in JS, JS templating, SSR.

Вобще меня всегда удивляло твое стремление смешать сугубо практические вопросы с общефилософской конспирологией. Или вот как здесь задавать прикладной вопрос на n-ацатой странице срача. То есть даже если кто и смог бы из сходного опыта знать ответ ему будет очень сложно продраться через все это:(

Ты меня достал, и я тебя заигнорю. Извини. Я ушёл из твоего лиспа и оставил его в покое. Твоя роль в этом значительна. Ты укрепил лисп сообщество тем самым. И ты меня тоже оставь в покое.

Хорошо. Вот такой вариант я хочу:

1. Парсим html в DOM.
2. Обрабатываем этот DOM.
3. Делаем ему pretty-print или ugly-print в новый файл. 
4. Всё это является лоадером для webpack. 

Я, кстати, не знаю, можно ли вообще так сделать без потери информации об исходном документе. Например, комментарии могут пропасть. Если DOM этого не позволяет, то вместо DOM нужно какое-то иное представление html-файла (дерево грамм. разбора), из которого потом этот файл можно без потерь воссоздать, но похожее на DOM, чтобы не нужно было много лишних знаний для работы с ним.

Главное, что когда я делаю виджет «путь к текущей странице», я мог бы достать title из документа.

комментарии могут пропасть

Что? Комментарии это такой тип DOM ноды.

Госпади. Куда вы лезете в разработку, не зная структур.

Вот с твоей помощью и узнал, спасибо.

Еще раз, PHP - универсальный шаблонизатор и готовый ЯП со всеми плюшками для веба. Люди не вчера начали писать веб и все давно продумали и придумали. Другие языки просто воспроизводят эту тему на разные лады. Теперь модно делать клиентский рендеринг, но суть абсолютно та же - препроцессор, либо в случае реакта транслятор в жс-конструкторы (т.е. хитровыделанный препроцессор от очумелых ручек). Я с трудом улавливаю что ты пытаешься написать, похоже генератор статического сайта, для чего тоже давно есть инструменты для чайников, например jekyll. А так заводишь PHP и пишешь с полпинка (фреймворки тут не понадобятся). Если хочешь влиться во фронтенд, забудь вообще про свои странички. Тебе нужно придумать сервис, приложение, SPA как они это называют. Чуешь разницу между гипертекстовым документом и GUI-приложением? Вот тебе нужен не документ верстать, а делать некий условный вконтактик. Если хочешь именно документы, дорога только в PHP.

Ты уже не первый, кто мне говорит, что надо забить на ноду и брать PHP. Вопрос к тебе такой - является ли нода достаточным костылём, способным заменить PHP, или всё совсем худо? Если ноду можно использовать вместо PHP, то я буду её использовать, даже если она в чём-то хуже, просто для того, чтобы пользоваться более компактным набором инструментов.

Пока всё же вернулся к vue. Удалось его подружить с моими скриптами и адатировать под него «яроклаву», поэтому я всё же могу доделать свой сайт на vue. В целом vue мне не нравится, но думаю, что как-то приспособиться можно.

Мне нужны и документы, и приложения. Но я также свято чту принцип KISS. Я смотрю на все эти генерации javascript функций, генерирующих DOM, и мне чуднО всё это видеть. Должно быть очевидно, что HTML - это декларативный язык высокого уровня, а JS - это процедурный язык низкого уровня. При возможности нужно использовать средства более высокого уровня.

Кроме того, я всегда считал и продолжаю считать, что стоимость слоёв абстракций очень высока. Я всегда 10 раз думаю, перед тем, как внедрить слой абстракции.

jekyll использует Руби - это ещё один лишний навык. Если полезность PHP безспорна, то про Руби я уже не так уверен.

Имхо любые распостраненные языки будут лучше ноды и пхп.

Почему?

Потому, что легче всего по жизни выбирать языки и компилить генту в ожидании момента, когда предстоит кануть в Лету.

Нет, нода не заменяет PHP никак. Начать с того, что нода асинхронная, а значит гарантирован очень специфический воркфлоу, называемый в народе callback hell. Мало-мальски сложную бизнес-логику делать на ноде - прямой путь в дурку. Разумные люди применяют ноду для серверного рендеринга (чтобы реюзать шаблоны) или как прослойку REST API, которая взаимодействует с другим сервисом, реализующим бизнес-логику. Короче, тут надо думать над архитектурой, а не набегать и трясти палкой как макаки. Ну или дерзай, но мне сложно представить как делать бэкенд на огрызках-микрофреймворках, где ты вынужден будешь адски велосипедить, да еще в рамках асинхронщины (сразу забудь про любые синхронные вызовы, ибо один поток, там гуры даже перебор массива делают неблокирующим).

Насчет работы обычно ситуация такая - либо фронтенд и немножко ноды, либо бэкенд на PHP и возможно немножко ноды. Выбирай. Так чтобы фулстек чисто на жс, это скорее миф. Хотя может где-то так и делают, но это будет жестко. Руби советовать не буду, для джунов вакансий нет давно. На питоне вот что-то есть еще, даже фриланс перепадает говорят.

Спасибо! Но как же хвалёный async/await? Я пока ещё не выбрал хранилище данных, но если я выберу postgres, то думаю, что спокойно напишу бизнес-логику на хранимках. Может, и зря я так думаю :) У меня был удачный опыт (MS SQL) и неудачный (Firebird). Хотя смотря что считать удачей. Отладка была адом, зато всё летает.

Но во всяком случае, сейчас я не делаю бекенда, а занимаюсь именно сборкой, т.е nuxt generate - генерирую «как бы статический» сайт на vue.

Но нафига бросать дельфы - оно же уже винтаж!

и за антиквариат мнохо монеты не?

Не, монеты не много за неё.

В целом же js сегодня является стандартом и многие вещи без него либо никак не сделать, либо это неадекватно трудоёмко.

Если речь о том, чтоб потренироваться в написании на js при создании сайта — это одно дело.

А в плане «не сделать» или «очень сложно» — не согласен. Имхо, если сайт чисто информационный и статический, то его не только лучше для пользователя, но и проще сделать вообще без скриптухи. Если на сайте планируется реализовать какой-то поиск по ключевым словам, разную сортировку и/или фильтр по темам, датам и т. д., то нужен скрипт на сервере (php или что угодно ещё из того, что тебе больше нравится), соединённый с БД, к которой и адресуются в конечном итоге запросы. А клиентские скрипты, имхо, нужны для браузерных игрушек и других не очень нужных браузерных приложений (например, можно написать калькулятор, но кому он нужен, учитывая, что в любой ОС калькулятор уже есть), для разных карт, для всяких интерактивных всплывающих окон типа «подпишитесь на нашу рассылку», которые как правило только раздражают, для интеграции со сторонними сервисами, api которых заточен на js ... ну и может для создания доморощенного блога с таким интерфейсом, чтоб легко добавлять статьи, как это делается в LiveJournal и на других движках, без html-вёрстки сайта. Хотя и блог можно сделать только на cgi+субд, но, возможно, добавление клиентских скриптов тут может упростить работу и повысить юзабельность.

Он работать хочет о веб-деву, а не свои странички пилить. Ты где ему заказчиков предлагаешь искать на сайты с чисто серверной динамикой? Автодополнения, валидация форм, подгрузка контента, сортировка, уведомления, интеренет-магазины, crm-системы, да даже простые лэндинги - ты хочешь, чтобы клиенты ахуевали от перезагрузки страниц на каждый чих? Ты как себе это представляешь, лол.

У тебя вообще в голове укладывается, чтобы в строке поиска по товарам\каталогу\списку контактов, после ввода каждой буквы, чтобы показать список автопдополнений перезагружалась вся страница? А чтобы открыть карточку товара переходить на новую странцу? А чтобы открыть изображение в крупном форате со слайдингом - тоже? Или грузить все крупные изображения из старницы каталога сразу?

ты просто не понимаешь что несешь.

И тебе еще может показаться, что если надо что-то динамически подгрузить, это щапиливается тривиально десятком строк, без необходимости сложной логики. Ага. А теперь представь, что у тебя таких функционально динамических элеменетов требующих динамического взаимодействия с сервером на странице десятки. Твой код быстро превратится в неподдерживаемую лапшу, если не будет архитектуры и разбития на компоненты.

Я не говорю о том, что сейчас вообще все пилится максимально на клиенте. И это не прихоть разработчкиов - это требования технических заданий.

Даже если ты насрешь в уши своему профан-клиенту о том, как все будет быстро без этого всего - он посмотит на получившийся результат, и на то, как пестрит вау-эффектами сайт конкруента и не заплатит тебе ни копейки, потому что ты написал ему откровенную зерню, не выполняющую его задачу.

Это все равно, что работать маркетологом, и всем говорить - знаете, навязчивая\вирусная реклама - это зло. Давайте просто напишем - покупайте наш товар. И те кто захотят купят.

И вот тебе мельчайший таск у меня, который я сегодня закрыл. Я фрилансер.

Задача состояла в том, чтобы сделать подсветку HEX-представлении в анализаторе сетевых пакетов. То есть обычный HEX-view - слева байты в 16-ричной системе, справа ascii. При выделении куска текста (в байтах, или в ascii), должен симметрично подсвечиваться кусок в противоположном блоке. Это простейшая вещь. Какой серверной логикой ты будешь реализовывать подобную задачу? Ты смеешься?

да не, он не смеётся.. он упоротый слегона по теме «веб заговняли уууу». Я даже не пойму кто больше упорот, он или Денис.

Но пояснение у тебя хорошее, если и после этого не поймёт, значит там комплексы какие то шибко хитрые, психиатр нужен..

Он работать хочет о веб-деву, а не свои странички пилить.

Ну, я же поэтому и сказал, что если для потренироваться, то да.

чтобы клиенты ахуевали от перезагрузки страниц на каждый чих?

Ну да, с этим согласен. Хотя сейчас на многих сайтах наблюдается противоположная крайность: контент динамически подгружается практически до бесконечности при переходе к концу страницы, занимая всё больше памяти, вместо того, чтоб просто поставить ссылку «далее». Имхо, всё хорошо в меру.

в строке поиска по товарам\каталогу\списку контактов, после ввода каждой буквы, чтобы показать список автопдополнений перезагружалась вся страница?

И это легко решается в рамках несколько иной логики: просто сделай статическую форму combobox аля select, и выбирай себе сколько хочешь безо всяких клиентских скриптов. Не так модно? Зато просто, быстро и надёжно.

все пилится максимально на клиенте. И это не прихоть разработчкиов - это требования технических заданий

Вот с этой тенденцией и надо бороться. Хотя ТС'у, прежде чем бороться, надо сначала как-то утвердиться на этом рынке, создать портфолио, а потом уже старые велосипеды из шкафа доставать, пытаясь диктовать моду. Это я понимаю.

Это все равно, что работать маркетологом, и всем говорить - знаете, навязчивая\вирусная реклама - это зло. Давайте просто напишем - покупайте наш товар. И те кто захотят купят.

М. б. с точки зрения маркетолога просто написать внизу странички мелкими буквами «покупайте наш товар» и наивно. Но навязчивая реклама ещё хуже, и не только для клиента, но и для продавца. С таким чересчур навязчивым продавцом просто не хочется иметь дела. Поэтому маркетологам следовало бы придумать что-то ненавязчивое, но эффективное. Но т. к. в большинстве случаев ни думать, ни тем более рисковать они не хотят, то и идут проторённым путём в никуда. А их роботодатели и клиенты думают, что так надо, потому что все так делают. Это как с проблемой медленных страничек, упоминавшейся в этом треде: пока кто-то не провёл исследований, на этот всем очевидный и без исследований факт никто не обращал внимания, а вот как исследовали, так все сразу засуетились. Надеюсь, лет через десять какой-нибудь умный манагер амазона догадается провести исследование на тему влияния ухода покупателей с тормознутых страниц из-за перенасыщенности клиентскими скриптами. Тогда, м. б., и мода на лёгкие странички возродится. А там, лет через сто, и до исследования навязчивой рекламы дело дойдёт... :-)

При выделении куска текста (в байтах, или в ascii), должен симметрично подсвечиваться кусок в противоположном блоке.

Это как раз тот самый случай, когда без программы на стороне клиента не обойтись. Я же не отрицал, что и такое порой бывает.