HTML и компиляторы - PullRequest
       15

HTML и компиляторы

3 голосов
/ 12 июля 2009

Этот вопрос более ориентирован на обсуждение, а не на конкретный вопрос. Написание простого HTML-кода является простым, но написание быстрых, основанных на стандартах, жалоб на лучшие практики SEO, все HTML-страницы, совместимые с браузерами, трудны и занимают много времени.

Но почему это сложно?

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

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

В других областях эта проблема была решена компиляторами языков высокого уровня, которые упрощают синтаксис, оптимизируют производительность, проверяют синтаксическую коррекцию программы перед выполнением.

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

Как вы думаете, возможно ли создать такой язык и компилятор?

Ответы [ 8 ]

6 голосов
/ 12 июля 2009

Боюсь, есть некоторая путаница. В том-то и дело, что писать хороший HTML легко. Очень просто. Писать плохой HTML тоже очень просто, но это ни здесь, ни там.

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

И никакая абстракция не решит этого. Только усилия по улучшению всех браузеров помогут этому; и это не маленький подвиг.

Еще одна проблема, и это более серьезная проблема, заключается в том, что в последнее время HTML злоупотребляли вещами, для которых он никогда не предназначался; приложения, которые выиграли бы очень от реализации в качестве «правильных» настольных приложений, реализуются в HTML и JavaScript, потому что это «легче» для разработчиков на некотором уровне (что, как подчеркивается в вашем посте, является грязным гнилым лежат).

Проблемы совместимости не могут быть легко преодолены; и внедряя вещи на неправильной «платформе», вы настраиваете себя на неудачу. Несчастно.

Интернет не является платформой; это запутанное переплетение опасности и отчаяния. И, конечно же, трубки.

4 голосов
/ 12 июля 2009

Лично я считаю, что при достаточной подготовке почти нет разницы в написании «базового» HTML и HTML-кода, соответствующего стандартам. Даже начиная с нуля, я не думаю, что это сложнее.

Точно так же, как только вы разработали несколько сайтов, любые правила, касающиеся валидации и т. Д., Станут второй натурой

2 голосов
/ 13 июля 2009

Давайте ответим на это так, чтобы это соответствовало вашим ожиданиям, но уважало бы повсеместность HTML.

Если вы хотите использовать язык высокого уровня для HTML, они уже существуют. Любая хорошая вики-система имеет упрощенный синтаксис, который абстрагируется от " ... ... " от пользователя. Это то, для чего создан PHP, и большинство популярных систем блогов и вики используют его.

Отдельная проблема, связанная с вашей жалобой, заключается в том, что язык разметки (HTML) используется в качестве посредника при передаче от приложения (сервера) к средству визуализации (клиенту). Цель приложения может быть потеряна, поскольку разметка - это не код, а язык описания документа.

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

Однако в этой области ведется работа. Посмотрите на XUL , которая пытается решить проблему в браузерах Mozilla; также Prism , который является очень ранней платформой приложений. Также посмотрите на Google GWT или NaCl , которые облегчают безопасную интеграцию "нативного" кода в сети. Проблема со всеми этими imho заключается в том, что они назначают работу клиенту. Я считаю, что единственный надежный способ безопасного взаимодействия клиента и сервера - это либо 1) доверенный облачный посредник, либо 2) виртуализация.

2 голосов
/ 12 июля 2009

То, что вы описываете, является предметно-ориентированным языком для описания HTML-страниц.

0 голосов
/ 15 июля 2009

GWT, Dojo и ExtJS делают именно то, что вы описываете. Да, им требуется JavaScript, но они позволяют избежать запоминания многих «правил» (в большей или меньшей степени в зависимости от технологии).

GWT особенно хороший пример, потому что он даже не требует, чтобы вы вообще занимались HTML, CSS или JS. Вы живете на чистой Java-земле, кросс-компилируете в веб-приложение, и оно просто работает.

0 голосов
/ 13 июля 2009

Настоящая проблема не в написании стандартов, совместимых с HTML. Проблема в том, что HTML + CSS - чрезвычайно сложная система без эталонной реализации, что делает стандарт практически бесполезным, поскольку вы не можете проверить его.

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

вы притворяетесь, что есть один стандарт, но так как ни у кого нет пути проверить на соответствие стандарту, это не настоящий стандарт: это платонический идеал и набор неверных толкований

0 голосов
/ 12 июля 2009

При всем моем уважении у меня сложилось впечатление, что вы сравниваете яблоки и апельсины. Зачем? Вы утверждаете, что современные языки программирования берут на себя бремя написания хорошего кода от разработчика (путем применения оптимизаций). ИМХО, это утверждение не совсем правильно: никакой оптимизирующий компилятор не может компенсировать разработчику, реализующему алгоритм O (n²) , где реализация O (n) также была бы возможна.

Вернемся к исходному вопросу: я понимаю, что вам нужно создавать совместимые со стандартами веб-приложения для кросс-браузеров с меньшими усилиями, чем необходимо сегодня. Возможно, кто-то (или уже) придумал мета-язык, который абстрагирует некоторую сложность написания HTML, но, с другой стороны, это уже сегодня возможно при наличии многих шаблонных сред / CMS. Конечно, вам все равно придется создать план вашего веб-сайта в HTML один раз, чтобы впоследствии его можно было использовать в качестве шаблона, но это то, что метаязыок также не позволит вам избавиться (даже современные компиляторы используют его). ручной сборки на некоторых языках).

0 голосов
/ 12 июля 2009

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

Нелегко отойти от него корпоративным и нетехническим пользователям.

...