HTML / CSS / JS

tarasv> чего вам в CSS не хватает чтобы отформатировать ее опираясь на синтаксис HTML?
В данном случае, естественно, не хватает потребности в CSS. Еще раз: 20 лет назад было проще прогнать HTML-заготовку через sed, раз и навсегда настроенный на формат всех страниц сайта. Сейчас было бы проще выплюнуть на экран страницу документа в "родном формате" или визуальное приложение, его рисующее.

Gudleifr> В данном случае, естественно, не хватает потребности в CSS. Еще раз: 20 лет назад было проще прогнать HTML-заготовку через sed, раз и навсегда настроенный на формат всех страниц сайта. Сейчас было бы проще выплюнуть на экран страницу документа в "родном формате" или визуальное приложение, его рисующее.

20 лет назад sed был уже лишним шагом в деплойменте. Все что вы в нем могли сделать основываясь на синтаксисе, а не семантике, было доступно в CSS 1 от 1996.

body {
  тут базовые стили всего документа...
}
p {
  а тут параграфа...
}
h1 {
  а эти заголовки я хочу например с подчеркиванием...
}

и трафика это потребляло меньше чем рапиханные sed-ом по всем тегам атрибуты style.

Gudleifr> В данном случае, естественно, не хватает потребности в CSS. Еще раз: 20 лет назад было проще прогнать HTML-заготовку через sed, раз и навсегда настроенный на формат всех страниц сайта.
А если надо откоррректировать что-то - то опять же прогонять через этот визивиг комбайн, который генерит тонны г**нокода, чтоб у юзера отображалось похоже? И в результате такого г**нокодинга белая страничка с несколькими строками текста начинает весить мегабайты?

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

tarasv> 20 лет назад sed
Я сначала думал, что чел прикалывается. Но похоже что нет - искренне не понимает зачем вообще надо разносить содержание и представление. Такое не объяснишь примерами из серии "на sed аттрибутами тэгов будет длиннее" - это же целая концепция, на которую почти все программы, так или иначе оперирующие форматированным текстом, давно перешли.

tarasv> 20 лет назад sed был уже лишним шагом в деплойменте.
Да он и сейчас полезен. Когда лень что-то делать руками.

tarasv> и трафика это потребляло меньше
Bredonosec> белая страничка с несколькими строками текста начинает весить мегабайты?
CSS весил гораздо больше, т.к. гонял, в основном, мусор.

Bredonosec> опять же прогонять через этот визивиг комбайн?
Да, нажать одну клавишу.

Bredonosec> Чтоб не придумывать нормальный формат
Дык, не придумали же. А преобразуют из нормального в дебильный, а потом - обратно.

tarasv> и трафика это потребляло меньше чем рапиханные sed-ом по всем тегам атрибуты style.
Я тебя умаляю

Потом это разрослось и проще стало пихать оптом ВСЕ описания стиля - хай браузер сам разберется - чем по каждой странице отсылать только стили, нужные ей
Оно надо разруливать зависимости ? А может что забудешь ?

Подобное было на С++ - накидал программу визардом и туда включается stdafx.h в котором просто прорва других заголовочников.
И в довесок к приложению - толстая рантайм библиотека, даже если оттуда используется десятая часть

Татарин> Просто JS оказался плохо задуман, и некоторые последствия "фигак-фигак и в продакшн" (или как сча модно это называть, аджайл-программировани) обошлись всему миру очень дорого. ГОРАЗДО дороже, чем несколько человеко-месяцев хорошего программиста, который мог бы быть потрачен на первую спецификацию.

Спецификация, я подозреваю, была только в голове у Эйка. За 10дней написать спеку и интерпретатор - таких чудес не бывает. Что в общем не большая беда была на том этапе. Беда случилось когда все заинтересованные компании собрались это обсудить и исправить, но в результате просто переругались.

Gudleifr> Да он и сейчас полезен. Когда лень что-то делать руками.

Не ври. "В основном мусор" получается именно "когда лень что-то делать руками". Руки бы отрывал юзерам sed-а и подобного ему г**на.

yacc> Потом это разрослось и проще стало пихать оптом ВСЕ описания стиля - хай браузер сам разберется - чем по каждой странице отсылать только стили, нужные ей

Если это приложение в котором человек работает весь день то почему надо делать по другому? Как минимум CSS лежит в кэше для следующей страницы, а то и распарсеный в памяти. Да и single page app по другому делать не стоит насколько я понимаю.

yacc> Оно надо разруливать зависимости ? А может что забудешь ?

Ну вот специально зашел в Фейсбук, чем не пример такого приложения, - 126кб css на 3.5мб трафика. В приложении над которым сейчас работаю, там похуже - 200к на 1.8мб. Но у нас и графики в разы меньше.

yacc> Подобное было на С++ - накидал программу визардом и туда включается stdafx.h в котором просто прорва других заголовочников.

stdafx.h придумали для препарсинга заголовочников. Если он у тебя отключен то будет печалька. Я обычно пускал первую компиляцию нового проекта и шел за чаем. Дальше полет нормальный.

yacc> И в довесок к приложению - толстая рантайм библиотека, даже если оттуда используется десятая часть

Линкер ничего особо лишнего вроде как не тянул. Но я не писал мордатые программы под винду на C++ уже лет 10, могу и не помнить.

tarasv> Если это приложение в котором человек работает весь день то почему надо делать по другому?
Тормозить будет
Вот смотри
tarasv> Ну вот специально зашел в Фейсбук, чем не пример такого приложения, - 126кб css на 3.5мб трафика.
Это таки фб с серьезной командой - таких мало.
На одного него - тонны г-но сайтов где бутстрап займет больше содержимого.
Опять же - ты графику учел, а как бы надо без нее : сам же говорил что страница html с явными стилями по тегами будет больше чем если использовать css ( что при грамотной разработке - действительно так )

tarasv> stdafx.h придумали для препарсинга заголовочников. Если он у тебя отключен то будет печалька.
Это я помню - к нему в довесок шел StdAfx.cpp

tarasv> Линкер ничего особо лишнего вроде как не тянул. Но я не писал мордатые программы под винду на C++ уже лет 10, могу и не помнить.
Я тебя умаляю - можешь скомилировать HelloWorld с простым окном на чистом WinAPI ( с оконной процедурой, там GetMessage и т.п. ) и на MFC/ATL и сравнить размер и зависимости.
Тем более что по умолчанию MSVC рантайм вообще брался из dll, которая обязана быть на машине.

tarasv>> 20 лет назад sed был уже лишним шагом в деплойменте.
Gudleifr> Да он и сейчас полезен. Когда лень что-то делать руками.
Когда лень делать руками - вообще в хтмл не лезут. Берут, ваяют в ворде какую-то хрень, и сохраняют как хтмл. Еще 20 лет назад.

tarasv>> и трафика это потребляло меньше
Bredonosec>> белая страничка с несколькими строками текста начинает весить мегабайты?
Gudleifr> CSS весил гораздо больше, т.к. гонял, в основном, мусор.
Плиз! Давай не гнать пургу,а?
я те самые 20 лет назад вовсю струячил всякую мелочь, и у меня стили цсс занимали где-нибудь 15+-5 строчек, менее полукила, ибо нафиг не надо больше.
И таки да, это включая трюки с псевдоактивным содержимым (ака действия от наведения или нажатия навроде визуального "нажатия кнопки" или выпадения чего угодно) на цсс.
И сам хтмл был компактным, простым и понятным, сходу читаемым, без горы цифромусора.

Bredonosec>> опять же прогонять через этот визивиг комбайн?
Gudleifr> Да, нажать одну клавишу.
и получить гору г**нокода. В котором хз почему что глючит.
и проще выкинуть его и писать заново с нуля, ибо это сгенеренный г**нокод.
Схема абсолютно та же, что "писать странички" в ворде.

Gudleifr> Дык, не придумали же.
речь щас о чем вообще? О разделении содержания и представления в веб? Придумали. И очень красиво.
О каких-то языках прогинга? О чем-то еще?

Bredonosec> речь щас о чем вообще?
А Вам какая разница? Вы же уже ответили.

Но, если угодно, тема посвящена трудностям перехода с классического FORTRAN на современный. Другие языки всплыли по ходу дела, т.к. "современным программистам" приходится объяснять "на кошках".

Gudleifr> Но, если угодно, тема посвящена трудностям перехода с классического FORTRAN на современный.
Да нет там никаких трудностей - новый и старый стиль поддерживает
И добавляет новый возможности, как то, скажем, Фортран 90:

- динамическое выделение памяти
- присваивание или сумма массивов одной операцией ( чего ранее вообще не было )
- указатели на функции
- элементы ООП

yacc> Да нет там никаких трудностей
Согласится ли с этим ТС?

Bredonosec>> речь щас о чем вообще?
Gudleifr> А Вам какая разница?
предпочитаю уточнить тезис, если он неполон или неясен, прежде чем отвечать на него.

Gudleifr> Но, если угодно, тема посвящена
не тема, а конкретный ответ -
Gudleifr> Дык, не придумали же.

Bredonosec> предпочитаю уточнить тезис
Т.е. почему я недоволен лечением HTML путем добавления CSS?
Я же написал: 20 лет назад при решении конкретных задач проще было воспринимать внешние форматы (те же HTTP и HTML) как данные в ощущениях, а вот деревенские ручные методы работы с ними заменять своими - программными. Сейчас же наличие "специального сетевого формата" просто мешает - как мешало Win API делать игрушки, пока не изобрели DirectX.

tarasv>> Если это приложение в котором человек работает весь день то почему надо делать по другому?
yacc> Тормозить будет

Ты имеешь в виду что накодили в CSS такого что назначение стиля в основном идет итерацией по правилам с хитровывенутыми селекторами, а потом прогулкой по DOM для каждого из них? Такое будет безусловно тормозить. Но если основная масса селекторов это тэг, класс, id то чему там тормозить? Назначение стиля идет получением его из распарсеного CSS. В среднем поиск в хашмап O(1) т.е. от размера CSS скорость зависит мало. Память съедается, это да.

yacc> Это таки фб с серьезной командой - таких мало.
yacc> На одного него - тонны г-но сайтов где бутстрап займет больше содержимого.

Потому что бутстрап работает на всем от 4к и до мобильника. Ведь у нас теперь - mobile first.

yacc> Опять же - ты графику учел, а как бы надо без нее : сам же говорил что страница html с явными стилями по тегами будет больше чем если использовать css ( что при грамотной разработке - действительно так )

У fb статической графики 1мб, а что там динамически подгружается уже слишком возючно смотреть.

yacc> Я тебя умаляю - можешь скомилировать HelloWorld с простым окном на чистом WinAPI ( с оконной процедурой, там GetMessage и т.п. ) и на MFC/ATL и сравнить размер и зависимости.

Ты будешь смеяться. У меня MFC в VS не было. Пришлось доставить. MFC 300к release/static против 104к WinAPI release. MFC dll 4.6mb. Так что линкер работает очень прилично.

Gudleifr> Но, если угодно, тема посвящена трудностям перехода с классического FORTRAN на современный.
А они есть? Эти трудности?

Всё, что может Фортран, может любой современный язык.
Собссно, наличие и простота прог прямой трансляции Фортрана в С (для переноса на платформы без нативного Фортрана, например), иллюстрирует этот тезис более чем наглядно.

Фортран по самой своей сути предельно прост. Можно сказать, предельно примитивен.

Из-за чего он и остаётся вполне годным для научных расчётов (где сила языка скорее вредит), и из-за чего ничего достаточно сложного на нём писать нельзя.

Татарин>> Просто JS оказался плохо задуман, и некоторые последствия "фигак-фигак и в продакшн" (или как сча модно это называть, аджайл-программировани) обошлись всему миру очень дорого. ГОРАЗДО дороже, чем несколько человеко-месяцев хорошего программиста, который мог бы быть потрачен на первую спецификацию.
Bredonosec> А можно какой-нибудь пример для большей очевидности мысли?

Можно пару сотен примеров... просто задолбаюсь.

Нажми в Хроме Ф12 и введи последовательно:
3.14 % 5
и
13.14 % 5

И нет, это не глюк и не проблема конкретно Хрома. Это так задуман язык, и в некоторой степени тут есть логика. Теперь попробуй отгадать, какая?

Или вот "упражнение 138": var a = [-1, -10, -0.0001, 0.0000000001, 1, 10], что будет если сказать a.sort()? Вопрос со звёздочкой: какая логика стоИт за этим?
А она, как тот суслик, есть.

Такого я могу понаписать много. Где-то даже видел целые коллекции от людей, которые не понимают логику ЯС и относятся к нему как к очередному языку, который следует привычной логике и здравому смыслу. Нет, логика в ЯС действительно есть. Всё это объяснимо. Всё. Кроме одного: ЗАЧЕМ?! Зачем нужно было изначально мешать кислое с г**ном, если изначально нужно было чуть солёное? ЯС по-своему логичен, но, блин, ЗАЧЕМ он логичен именно по-своему?

...
И заметь, я не говорю про очевидные проблемы (ну или проблемы, которые хотя бы можно ожидать) скриптового языка типа
var a = "1";
a += 1;

это, можно сказать, вполне очевидно. Но вот скажи мне результат ещё одной строки добавленой к предыдущему без использования консоли
a -= 1;

Если смог предсказать и ответить, почему, - ну, ты понял логику ЯС. Но к чему тогда были вопросы?

Татарин> Всё, что может Фортран, может любой современный язык.
Такой ответ ТС не устроил.

Татарин>> Всё, что может Фортран, может любой современный язык.
Gudleifr> Такой ответ ТС не устроил.
Ответ на какой вопрос?

Татарин> Ответ на какой вопрос?
Как в современных условиях запускать программы на старом FORTRAN (и иметь при этом все удобства старой модели работы - например перенос 1 в 1 всех старых наработок и накопленных большевиками библиотек алгоритмов; а заодно - получить и современные удобства, например, инженерную графику).

Татарин>> Ответ на какой вопрос?
Gudleifr> Как в современных условиях запускать программы на старом FORTRAN (и иметь при этом все удобства старой модели работы - например перенос 1 в 1 всех старых наработок и накопленных большевиками библиотек алгоритмов; а заодно - получить и современные удобства, например, инженерную графику).
С главным вопросом всё просто - брать компилятор Фортрана, которые есть.

А вот с графикой сложнее, варианты такие:
а) компилировать Фортран во что-то - либо в бинарник (и включать в проект с графикой на нормальном языке), либо в нормальный язык (и включать в проект исходники);
б) выводить результаты в промежуточный файл, который визуализируется внешними программами;
в) использовать нечто типа gtk-fortran, что само по себе - тот ещё гемморой. Как и GTK вообще, да простят меня его фанаты. Есть и другие варианты, но все они так или иначе проблемны для человека, главная задача которого - всё-таки посчитать и посмотреть, а не возиться в параллельной ему области деятельности с сомнительным результатом.

yacc>> Тормозить будет
tarasv> Ты имеешь в виду что накодили в CSS такого что назначение стиля в основном идет итерацией по правилам с хитровывенутыми селекторами, а потом прогулкой по DOM для каждого из них? Такое будет безусловно тормозить. Но если основная масса селекторов это тэг, класс, id то чему там тормозить?
Если у тебя 90% стилей не используется, а притянуто "за компанию" большим списком - ты парсишь вхолостую

tarasv> Потому что бутстрап работает на всем от 4к и до мобильника. Ведь у нас теперь - mobile first.
Потому что проще написать на нем да плюс выбор потенциальных работ выше.
А то, что там в проекте 90% возможностей не будет использоваться - да и пофиг.

tarasv> Ты будешь смеяться. У меня MFC в VS не было. Пришлось доставить. MFC 300к release/static против 104к WinAPI release. MFC dll 4.6mb. Так что линкер работает очень прилично.
Там в статик точно не использется что-то типа msvcrt в зависимостях ?
Это как бы не mfc - они отдельно

Bredonosec>> предпочитаю уточнить тезис
Gudleifr> Т.е. почему я недоволен лечением HTML путем добавления CSS?
А это НЕ лечение.
Это нормальное грамотное разделение содержимого и представления.

Gudleifr> Я же написал: 20 лет назад при решении конкретных задач проще было воспринимать внешние форматы (те же HTTP и HTML) как данные в ощущениях, а вот деревенские ручные методы работы с ними заменять своими - программными.
это что за "формат данных" http? Это протокол.
То, что было модно наговнокодить что-то в визивиге и кинуть, дескать, и так сойдет, я в курсе и сам. При этом, почему от смены браузера или разрешения экрана или чего угодно всё разваливается и расползается - хрен поймешь, при замене трех слов текста надо полностью заново переписывать от и до, потому что в г**нокоде не понять ничего - "этонормально!"

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



>Сейчас же наличие "специального сетевого формата" просто мешает - как мешало Win API делать игрушки, пока не изобрели DirectX.
наоборот. Для отображения данных он и нужен. И мы сейчас общаемся в таком.
А представь, если б всё было в нередактируемом по определению педофиле? Или в ворде с локингом содержимого на время редактинга одним человеком. Или генерацией нового файла каждый раз сервом.
Короче, пурга это полная - насчет "мешает".