Разве параметры атрибутов данных, используемые в Bootstrap, Angular.js и Ember.js, не противоречат принципам ненавязчивого JavaScript?
Мне всегда говорили, что это хорошая практика (аля "ненавязчивый javascript") отделять JavaScript от разметки HTML. Однако я наблюдаю противоположную тенденцию с рядом новых и популярных фреймворков, таких как Bootstrap, Angular.js и Ember.js. Может кто-нибудь сказать мне, почему это не считается плохой практикой?
2 ответа
Ненавязчивый Javascript - хорошая практика для многих мест в Интернете. Упомянутые вами фреймворки часто используются для создания полноценных приложений Javascript. Во многих из этих приложений опыт без Javascript часто является пустой страницей. В этой среде значение отделения вашей разметки от Javascript относительно низкое.
Я сам задаю тот же вопрос и пришел к следующему выводу:
HTML является языком разметки для представления документов. Семантика, на которую все ссылаются, на самом деле связана с представлением богатых документов. Это включает в себя изображения и ссылки, которые позволяют более богатый опыт. Те же самые принципы могут быть применены к документам Word, где вместо того, чтобы отмечать определенный текст красным, вы можете пометить его как выделение, а затем стилизовать выделение как красный, что будет семантически правильным способом выражения намерения.
Проблема возникает потому, что HTML на самом деле включает в себя элементы, которые позволяют взаимодействие с пользователем - формы. Первоначальный дизайн должен был позволить непрофессионалам создавать простые интерактивные интерфейсы. Когда я проверял различные структуры графического интерфейса рабочего стола, не было такого понятия, как разделение между фактическим представлением и логикой представления, потому что при создании GUI такое разделение не требуется.
Для меня важно то, что вы пишете на основе контента или графического интерфейса. Поскольку HTML служит двум целям, трудно узнать, что обслуживать с сервера. В основном такие сайты, как Википедия и даже Stackru, ориентированы на контент. Это означает, что если они хотят быть доступными для более широкого круга клиентов, таких как боты и старые браузеры, они должны иметь возможность передавать чистый HTML. Я имею в виду две возможные стратегии, когда вы хотите предоставить контент и более богатый пользовательский интерфейс, например, текстовое сообщение, где я пишу этот комментарий. Одним из них является сервер HTML и затем инициализировать графический интерфейс. Это также упоминается как ненавязчивый JavaScript и семантический HTML. Это то, что делают большинство контент-ориентированных сайтов. Это в основном для того, чтобы иметь возможность пользоваться браузерами и ботами, которые позволят сделать их контент более доступным. Другая стратегия будет заключаться в том, чтобы идентифицировать тип клиента и обслуживать другой контент, что может быть надежно достигнуто только на стороне клиента, поскольку в обоих случаях будет использоваться html. Это все еще близко к первой формулировке из-за того, как HTML используется / используется как контент и представление в графическом интерфейсе.
Если вы пишете приложение, которое не предоставляет контент, а представляет собой реальный сервис / процесс, тогда архитектура, подобная AngularJS и аналогичным, подойдет лучше.
По моему опыту, большинство бизнеса должны обеспечить оба. Допустим, у вас есть приложение, которое использует HTML/Javascript, чтобы позволить пользователям создавать рисунки. Это приложение не должно следовать каким-либо ненавязчивым правилам, но оно не сможет работать и в старых браузерах. Но если вы предоставляете общий доступ к рисункам между пользователями, позволяя комментировать и другой контент, то лучше написать эту часть сайта таким образом, чтобы боты и другие клиенты могли легко получить доступ к контенту.