Re: CLI vs. GUI
Артём Н. -> debian-russian@lists.debian.org @ Sun, 20 May 2012 21:56:09 +0400:
>> >> Так что писать на коленке презентацию, которая будет выведена плюс-минус
>> >> так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
>> >> подобные поползновения печатать объявления в ворде...), а HTML - уже ни
>> >> в коем разе.
>> АН> Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
>> АН> на то, что все ваши пользователи используют lynx, links, w3m или
>> АН> подобное.
>>
>> Доктор, это ничего, что у меня есть информативный сайт, все HTML
>> которого написаны вручную, старые в vim, новые в emacs? Ключевое слово
>> - "информативный".
АН> Вообще-то, это частный случай, когда требуется преимущественно
АН> подсветка HTML и CSS. С чем VIM неплохо справляется.
Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
файле, отчего все еще проще.
Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя
emacs даже умеет показывать картинки. Лучше б не умел...
>> А если мне нужно интерактивное веб-приложение, то
>> там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
>> ручное редактирование.
АН> Хм... Haml - любопытно.
Угу. Технология создания веб-приложений сводится к тому, что дизайнер
делает дизайн, HTML-верстальщик (это совершенно другой человек)
превращает его в HTML, CSS и набор картинок, а программист превращает
эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
которые динамически заполняются данными. Гуй для HTML при этом может
использоваться в принципе только на втором этапе, но тем верстальщикам,
кто пытается его там использовать, быстро отрывают руки. Ну, или
результат получается, мягко говоря, неюзабельным для пользователя.
>> Как это выглядит, нужно смотреть в браузере и только в браузере.
>> Желательно не в одном.
АН> Как это выглядит и работает нужно проверять в браузере. Обязательно
АН> не в одном, как говорят. По крайней мере, в наиболее популярных
АН> (или в тех, на которых это будет работать, если это нечто
АН> специфическое). И, затем ещё вносить корректировки для конкретных
АН> экземпляров. :-|
Тонкость в том, что если у тебя есть информация, то можно написать
достаточно простой HTML для того, чтобы проверять его нужно было
максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски
обычно не шибко нужны.
>> АН> но графический режим добавляет возможность предосмотра картинок,
>> АН> например. Поддержка мышки и d&d добавляет возможность быстрой
>> АН> компоновки. Меню организуют структуру команд и позволяют быстро
>> АН> найти нужную (они не заменяют горячих клавиш), без использования
>> АН> справки... В итоге, получается GUI (причём, никто не отменяет
>> АН> поддержку консольного режима). По-моему, это очевидно. И чем тут
>> АН> он мешает (при условии, что он спроектирован и реализован
>> АН> грамотно)?
>>
>> Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
>> реальным видом документа. А что этот гуй выдает в код, и какой ужас
>> потом в браузере... Это - практика.
АН> o.O Я разве агитирую за "Фронтпэйдж"? Я предполагаю, что автор
АН> имеет представление о том, что существуют разные средства вывода
АН> (и, если уж быть точным, не обязательно визуальные).
Наличие гуя провоцирует не иметь такого представления.
АН> Но этак даже формочки во всяких "Делфи" возможно вручную делать. Но зачем?
В Delphi - можно, но тяжело и неудобно. А в Tk - удобно...
>> А JS длиннее одного вызова функции в <script> в ручную написанном HTML -
>> это признак того, что у автора слишком много свободного времени, и ему
>> нечем это время занять, кроме как вычисткой потом глюков из результата.
АН> Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один
АН> внешний JS, который включает объект её реализующий? Про "много
АН> свободного времени" - это вы объясните авторам всяких там гуглов и
АН> ещё 100500 сервисов, которые этим JS буквально пронизаны (местами
АН> это даже удобно и, бывает, работает).
Это второй вопрос. Но программа на JS, если она используется, должна
быть в отдельном файле, а не включена в тот же HTML.
Reply to: