Comments 290
Вам о неэффективности связки HTML+JS+CSS (целых 3 (три) инструмента для 1 (одной) задачи), вы показываете примеры того, как используя камень вместо молотка можно построить дом. Логика. В этом посте её нет.
Эта связка как MVC.
Model — HTML, View — CSS, Controller — JavaScript.
Не вижу проблем с эффективностью. Это скорее гибкость.
Model — HTML, View — CSS, Controller — JavaScript.
Не вижу проблем с эффективностью. Это скорее гибкость.
Это все скорее просто V
Там, конечно, не вполне верное соответствие, но уж точно не просто V.
HTML = M + V, JavaScript — C, CSS не имеет точного соответствия в MVC-схеме, но в целом, это часть V.
Более строгого разделения на M и V можно достичь, используя XSLT, но этот подход не приобрел популярности, видимо, потому что это разделение проще сделать на этапе препроцессинга.
HTML = M + V, JavaScript — C, CSS не имеет точного соответствия в MVC-схеме, но в целом, это часть V.
Более строгого разделения на M и V можно достичь, используя XSLT, но этот подход не приобрел популярности, видимо, потому что это разделение проще сделать на этапе препроцессинга.
Да ну? Пока что там всё перемешано в кучу только для представления, на JS пишутся либо модели вместе с контроллерами, либо мосты, передающие управления контроллерам на серверной стороне.
MVC — это XAML. Он конечно ооочень громоздкий и его нужно сильно упрощать, но вот там реально сделать и не такие контролы — был бы инструмент удобный (blend НЕ удобный инструмент)
XAML — MVC? Сам по себе? XAML, если не ошибаюсь, декларативный язык разметки. Без, например, C# далеко не уехать. Ну и стилизация в XAML на любителя (http://msdn.microsoft.com/ru-ru/library/ms745683.aspx). Все эти Setter, Property, Value, BasedOn, TargetType, x:Key. Поэтому, на мой взгляд, в концептуальном плане оно недалеко от связки HTML+CSS+JS ушло, причем в какую сторону, однозначно тоже не скажешь.
XAML это только V, при чем не из MVC, а из MVVM тогда уж
>Эта связка как MVC.
>Model — HTML, View — CSS, Controller — JavaScript.
Вы в корне не понимаете что такое MVC(((
>Model — HTML, View — CSS, Controller — JavaScript.
Вы в корне не понимаете что такое MVC(((
Напротив, на концептуальном уровне прекрасное разделение. Если вынести за скобки всевозможные JS-костыли для недостающих и некорректно работающих CSS-свойств, то каждый инструмент решает собственную задачу. Или вы предлагаете данные, представление и логику в одном формате хранить? Вот это анахронизм как раз.
Конкретная реализация не всегда на высоте, но со смертью IE8 жизнь веб-разработчика заметно облегчится.
Конкретная реализация не всегда на высоте, но со смертью IE8 жизнь веб-разработчика заметно облегчится.
Плохо они решают. И в HTML, и в JS просачивается не то, что логика представления, а его данные. Хотя бы потому что порядок и вложенность тэгов имеет значение для браузера и не только для использования в качестве селекторов CSS, а очень часто изменяют HTML в угоду CSS. А некоторые задачи представления так и вообще без JS толком не решить. Например, я не знаю как средствами CSS сделать чтобы на хабре блоки справа были одной высоты, соответствующей самому высокому сейчас. Не в пикселях, а динамически. По-моему, если и можно, то это будет очень не тривиально.
Еще раз — речь о концепции, а не о реализации. Тут человек высказался в том ключе, что три инструмента решают одну задачу, это неверно, задачи разные, и разделение уместно. То, что CSS сильно недоработан — факт, ну так JS-костыли я уже упомянул.
В том-то и дело, что в концепции HTML начиная чуть ли не с 1.0 (в 2.0 уже точно) заложено представление данных, заведомо визуальные тэги, которые присутствуют и в html5. Не буду вспоминать про
<b>, но такой популярный как <table> имеет в виду именно представление, а не структуру данных.Я об этом написал тредом выше, можно же использовать XML + XSLT, вот там будет строгое разделение данных и представления. Но так никто не делает, потому что это разделение на стороне front-end никому не нужно, вполне достаточно разделения на стороне back-end.
Так с помощью XSLT мы из XML получим HTML+CSS+JS. XML+XSLT тут лишнее звено, если данные не в XML. А зачастую даже если в XML данные, то проще их распарсить, а затем шаблонизировать более «юзер-френдли» шаблонизатором.
Так вы путаете front-end и back-end. XSLT — это front-end, поэтому он в одной линейке с HTML/JS/CSS. Шаблонизаторы — это back-end.
Из XML+XSLT мы получаем только HTML (если, конечно, правильно все делаем), CSS и JS — отдельно. А то, что лишнее звено — ну да, так и есть, но о том и речь: разделение между данными и структурой на стороне front-end, видимо, просто не особенно востребовано.
Из XML+XSLT мы получаем только HTML (если, конечно, правильно все делаем), CSS и JS — отдельно. А то, что лишнее звено — ну да, так и есть, но о том и речь: разделение между данными и структурой на стороне front-end, видимо, просто не особенно востребовано.
Я использовал XSLT на сервер-сайде, именно как шаблонизатор. И, насколько я знаю, я не одинок и в популярных для сервер-сайда языках поддержка xml+xslt есть, что называется, из коробки.
Но суть не в том, а что имея raw-data и имея возможность преобразовать их в любой sgml-подобный язык, преобразовывать их в xml, чтобы потом средствами xslt преобразовать в html (не важно где, на клиенте или на сервере) несколько странно (за исключением особых случаев).
Под html+css+js я имел в виду html документ со
Но суть не в том, а что имея raw-data и имея возможность преобразовать их в любой sgml-подобный язык, преобразовывать их в xml, чтобы потом средствами xslt преобразовать в html (не важно где, на клиенте или на сервере) несколько странно (за исключением особых случаев).
Под html+css+js я имел в виду html документ со
style и script.Ну проблема-то не в том, что это странно. Чего-чего, а промежуточных звеньев и наслоения уровней абстракции в веб-разработке хватает. Да и в разработке вообще.
Тут два варианта — либо не нужно, либо связка XML + XSLT настолько неудобна. В принципе, второй вариант тоже выглядит правдоподобно. Если бы вместо XSLT был некий PHP-подобный шаблонизатор для front-end, вероятно, он бы нашел свое применение.
Тут два варианта — либо не нужно, либо связка XML + XSLT настолько неудобна. В принципе, второй вариант тоже выглядит правдоподобно. Если бы вместо XSLT был некий PHP-подобный шаблонизатор для front-end, вероятно, он бы нашел свое применение.
Ну да, XSLT язык нетривиальный, особенно для тех кто из декларативных только html освоил, нам лучше смарти какой-нибудь или ерб :) Плюс для конвертации на стороне клиента не всё хорошо с поддержкой в браузерах, по крайней мере так было в те времена, когда я активно верстал и радовался если в ТЗ не было требования поддержки IE<5.5 :)
Кстати, интересный вопрос. Я вот почти загорелся мыслью написать такой шаблонизатор. Реализуется довольно тривиально, HTML-скелет с дополнительной метаразметкой на основе атрибутов data-* + данные в формате json в отдельном js-файле. Будет намного проще и интуитивно понятнее, чем мозгодробилка XSLT. JSON генерируется в две-три строчки на любом серверном языке, так что никаких особых танцев с бубнами не потребуется.
Но вот лично вы — будете пользоваться? Я все же не уверен, что такая функциональность в принципе нужна.
Но вот лично вы — будете пользоваться? Я все же не уверен, что такая функциональность в принципе нужна.
<table /> — это структура данных, всё верно.
В Web Content Accessibility Guidelines это отлично объясняется.
В Web Content Accessibility Guidelines это отлично объясняется.
порядок и вложенность тэгов имеет значение для браузера
Это, для семантики. А она для того, чтобы можно было просмотреть данные без CSS.
Я о том, что в угоду CSS приходится, например, переупорядочивать блоки до того семантически упорядоченные, или вводить новые, не несущие вообще никакой семантики. Приходится нарушать семантику документа для того, чтобы семантически корректный документ (а вернее интерфейс приложения с представлением документа в одном из «контролов») визуально выглядел так, как нарисовано на макете.
Я не понимаю в чём суть проблемы.
Можно использовать одни лишь span, strong, em с классами.
И семантика не постарадает, и оформить можно как угодно.
Можно использовать одни лишь span, strong, em с классами.
И семантика не постарадает, и оформить можно как угодно.
В том-то и дело, что как угодно не получается или получается с большим трудом. Когда я даю верстальщику ТЗ и макет и семантический чистый html-код, содержащий всё, что на странице должно отображаться, то он либо просит внести изменения в ТЗ, либо просит разрешения менять html (что тоже изменение ТЗ по сути) — переставлять блоки местами (почему-то очень не любят, когда логически сгруппированные блоки должны отображаться в разных местах и привязываться к другим разным блокам), вводить врапперы или другие невидимые и пустые элементы. В общем мой чистенький и красивый HTML, практически чистый XML сильно изменяется из-за ограниченности CSS. Причём без CSS мой код выглядит в браузере как задумано (не как на макете, а как он должен выглядеть без CSS), а вот то, что потом выдаёт верстальщик…
Если это не так — одно из двух — либо это проблема структуры ваших данных, либо дизайнера, который решил эти данные поразбрасывать как угодно.
По-моему, логично объединить или просто разместить в коде рядом все, например, меню или баннеры — назначение у них одно, а в дизайне они могут быть где угодно — в одном все меню могут быть размещены в столбик слева, в другом справа, а в третьем половина вверху, а половина внизу. Верстальщики в такой ситуации настаивают на том, что для разных дизайнов должен быть разный html, хотя css создавался вроде как как раз для того, чтобы любое визуальное представление элементов html можно было создать не трогая сам html. Выходит за 15+ лет эта задача так и не решена.
По-моему, логично объединить или просто разместить в коде рядом все, например, меню или баннеры — назначение у них одно, а в дизайне они могут быть где угодно — в одном все меню могут быть размещены в столбик слева, в другом справа, а в третьем половина вверху, а половина внизу. Верстальщики в такой ситуации настаивают на том, что для разных дизайнов должен быть разный html, хотя css создавался вроде как как раз для того, чтобы любое визуальное представление элементов html можно было создать не трогая сам html. Выходит за 15+ лет эта задача так и не решена.
>По-моему, логично размещать в коде рядом элементы, которые и на экране будут рядом
Логично не зависеть от капризов дизайнера. Или скажем от того, какой размер у экрана устройства.
>Если определенные элементы по определенным причинам выбиваются из иерархической структуры и должны иметь конкретную позицию — что мешает использовать абсолютное позиционирование и размещать их именно там, где вам надо?
Мне надо разместить выбивающийся блок сразу после другого блока с неизвестной на этапе вёрстки высотой. Не выбивался бы — проблем не было бы, но он выбивается и приходится либо искусственно его туда вводить, либо использовать JS для задачи должной решаться средствами CSS
Логично не зависеть от капризов дизайнера. Или скажем от того, какой размер у экрана устройства.
>Если определенные элементы по определенным причинам выбиваются из иерархической структуры и должны иметь конкретную позицию — что мешает использовать абсолютное позиционирование и размещать их именно там, где вам надо?
Мне надо разместить выбивающийся блок сразу после другого блока с неизвестной на этапе вёрстки высотой. Не выбивался бы — проблем не было бы, но он выбивается и приходится либо искусственно его туда вводить, либо использовать JS для задачи должной решаться средствами CSS
>Используйте конкретные инструменты на конкретных задачах и не пытайтесь перетаскивать идеологии с одних языков и технологий на другие.
HTML прекрасно справляется с разметкой текста, CSS с визуализацией этого размеченного текста. Но приходится использовать их (да ещё с JS зачастую) для решения задачи создания интерфейсов путем размещения блоков текста на экране — нет конкретного инструмента для этой задачи, а существующие (прежде всего CSS) плохо справляются.
HTML прекрасно справляется с разметкой текста, CSS с визуализацией этого размеченного текста. Но приходится использовать их (да ещё с JS зачастую) для решения задачи создания интерфейсов путем размещения блоков текста на экране — нет конкретного инструмента для этой задачи, а существующие (прежде всего CSS) плохо справляются.
Спозиционировать сложно прежде всего. Сама модель затрудняет, мало режимов, позиционировать нормально можно только относительно родителя или предшествующего в коде элемента (да ещё при условии, что он сам в нормальном потоке). Можно было бы в position указывать селектор элемента относительно которого позиционируются элементы, которые попадают под правило — было бы проще намного. Вторая большая половина, тесно связанная с первой — размеры, прежде всего относительные (в процентах) — можно было бы указать что ширина текущего блока равна половине ширины вон того блока, было бы замечательно. А главное, имхо, реализовать это не так сложно, как какой-нибудь сахар из Saas.
UI позиционирование в связке HTML+CSS отсутсвует полностью. Там есть только flow (text based) позиционирование. Сделать какой-либо вменяемый лейаут без JS в принципе невозможно.
Если вы ходите в html-представлении хранить данные, чтобы они не «ломались» от перестановки или изменении html, то специально для такой ситуации в HTML5 предусмотрено Microdata API. При использовании Microdata вам будет практически плевать, что верстальщик сделал с вашим html — с небольшими усилиями вы спроецируете нужную вам структуру данных на любую html-разметку.
Это не семантика, это связка «семантика + разметка». То есть M+V.
О Б-же, да там еще и SQL, который отдает данные(ну или NoSQL база), язык более низкого уровня, который это все еще контроллирует и веб-сервер, который это отдает! И это все решает одну задачу — показ порнушки. Куда катиться мир.
А до сколько инструментов предлагаете свести Вы? До 1 и писать все в императивном стиле? Или все же до 2: декларативный + императивный? Ну вот XAML + C#, аналог CSS там внутри XAML (Setter, Property, Value, BasedOn, TargetType, x:Key и т.п.) — лично мне CSS приятней. Ну и с HTML5 + CSS3 со всеми последними фишками выглядят уже не так уж плохо.
Я бы предложил не свести, а, наоборот, чётко разделить их функции. Сейчас даже при желании это не всегда представляется возможным.
Вы синтаксис с семантикой в одну кучу свалили.
Как написано в википедии, «XAML is a declarative XML-based language created by Microsoft and is used for initializing structured values and objects». Всего навсего. Никакого Setter, Property, Value, BasedOn там нет вообще.
И есть WPF, в котором есть класс Setter, со свойством Property. Если вы с WPF хотите использовать синтаксис CSS — придётся писать что-то вроде ".Setter {Property Property: FontFamily; Value:'Segoe Black'}"
Так что вам не нравится то, XAML или WPF?
Как написано в википедии, «XAML is a declarative XML-based language created by Microsoft and is used for initializing structured values and objects». Всего навсего. Никакого Setter, Property, Value, BasedOn там нет вообще.
И есть WPF, в котором есть класс Setter, со свойством Property. Если вы с WPF хотите использовать синтаксис CSS — придётся писать что-то вроде ".Setter {Property Property: FontFamily; Value:'Segoe Black'}"
Так что вам не нравится то, XAML или WPF?
Если я что-то в кучу и свалил, то вроде XAML с WPF. Спасибо за уточнение.
Обсуждение идет в разрезе разработки приложений с UI, потому, да, я имел в виду WPF. И возможности стилизации мне там, действительно, не очень нравятся синтаксически. Может я и ошибаюсь, но у меня иногда возникает ощущение, что у Microsoft часто бывает цель «надо сделать по-другому, чтобы отличалось». В целом, на мой взгляд, концептуально WPF не сильно превосходит HTML+CSS+JS, при этом по реализации местами превосходит, но и HTML+CSS+JS не стоят на месте.
Обсуждение идет в разрезе разработки приложений с UI, потому, да, я имел в виду WPF. И возможности стилизации мне там, действительно, не очень нравятся синтаксически. Может я и ошибаюсь, но у меня иногда возникает ощущение, что у Microsoft часто бывает цель «надо сделать по-другому, чтобы отличалось». В целом, на мой взгляд, концептуально WPF не сильно превосходит HTML+CSS+JS, при этом по реализации местами превосходит, но и HTML+CSS+JS не стоят на месте.
WPF концептуально сильно превосходит HTML хотя бы тем, что я могу в окно класть не дивы, а объект/xml/что угодно. И на выходе получить полноценный интерфейс. Декларативно, только за счёт шаблонов.
А по реализации оно WPF 5-ти летней давности не догнало и непонятно догонит ли.
А по реализации оно WPF 5-ти летней давности не догнало и непонятно догонит ли.
Не очень понял суть превосходства из 1 абзаца. Не могли бы Вы привести реальный пример?
Я говорю про DataTemplate вообще и TargetType в частности. По ссылке шаблон кладут в ресурсы в это же окно, а ItemsSource задают через binding(а не данными). Но это частность.
Понятно. Мне кажется некорректным сравнивать WPF только с HTML, давайте сравним все же со связкой HTML+CSS+JS, например, так: jsfiddle.net/api/post/library/pure/
На мой взгляд, разрыв уже не настолько большой…
На мой взгляд, разрыв уже не настолько большой…
Видимо мы говорим уже про связку HTML+CSS+JS+angularjs+JQuery+ExtJS+UnderscoreJS+… Ну но коллекционирование костылей я концептуальным преимуществом признать, мягко говоря, не могу )
А вообще где там про DataTemplate я не понял. Меня попросили картинку для привлечения внимания добавить, и там что-то сломалось. jsfiddle.net/vajBW/3/ — куда там новый шаблон то вписывать?
А вообще где там про DataTemplate я не понял. Меня попросили картинку для привлечения внимания добавить, и там что-то сломалось. jsfiddle.net/vajBW/3/ — куда там новый шаблон то вписывать?
Вы начинаете передергивать. Это решение лежит в пределах стека технологий HTML+CSS+JS. Я же не уточняю у Вас, какие using-и и доп. компоненты (типа, telerik-а) Вы используете.
И я пока нигде не говорил, что HTML+CSS+JS концептуально превосходит WPF, я говорил «концептуально WPF не сильно превосходит HTML+CSS+JS».
У HTML+CSS+JS хватает возможностей для развития, несмотря на то, что изобретен он был в 90-х, а не в 2000-х (если не ошибаюсьWPF в 2006 вышел?).
По поводу примера: как Вы можете видеть из исходника, в написанной Вами цепочке все после angularjs в данном примере неактуально. Ели Вы под шаблоном подразумеваете только описание повторяющегося отображения элемента, то в AngularJS это делается с помощью ng-repeat и вложенного в него содержания. Соответственно что хотите, то и повторяйте, где угодно и в каких угодно комбинациях.
И я пока нигде не говорил, что HTML+CSS+JS концептуально превосходит WPF, я говорил «концептуально WPF не сильно превосходит HTML+CSS+JS».
У HTML+CSS+JS хватает возможностей для развития, несмотря на то, что изобретен он был в 90-х, а не в 2000-х (если не ошибаюсьWPF в 2006 вышел?).
По поводу примера: как Вы можете видеть из исходника, в написанной Вами цепочке все после angularjs в данном примере неактуально. Ели Вы под шаблоном подразумеваете только описание повторяющегося отображения элемента, то в AngularJS это делается с помощью ng-repeat и вложенного в него содержания. Соответственно что хотите, то и повторяйте, где угодно и в каких угодно комбинациях.
Я не передёргиваю. Я намекаю, что в на JS можете VM для .NET написать. И считать это HTML+CSS+JS стеком мягко говоря неправильно. Во-первых, нет в HTML конструкций вроде ng-repeat=«todo in todos».Во-вторых вы подерётесь с любителем backboneJS.
В примере я хочу, чтобы среди списка задач показалась картинка с подписью, если я получил такие данные. Без input и span, которые ng-repeat повторяет.
В примере я хочу, чтобы среди списка задач показалась картинка с подписью, если я получил такие данные. Без input и span, которые ng-repeat повторяет.
А сейчас Вы, имхо, утрируете ;) Само собой у них разные модели развития. Microsoft предпочитает создать новое рядом со старым. У HTML+CSS+JS достаточный запас прочности, чтобы развиваться, причем не только усилиями w3c.
Ссылкой ниже, как понимаю, Вы иллюстрируете тезис " нет в HTML конструкций вроде ng-repeat=«todo in todos»". Если есть желание, не проблема будет и валидным сделать, там есть разный синтаксис использования ng* директив. Ну а во-вторых — не подерусь. Зачем? :)
Я не до конца понял что и зачем Вы хотите, но вот: jsfiddle.net/vajBW/4/
Подозреваю, что Вы ищете что-нибудь, что есть в WPF, но нет в AngularJS, чтобы показать превосходство WPF на сферическом примере в вакууме. Это обязательно у Вас получится :) По-крайней мере, в 2012г. ;)
Ссылкой ниже, как понимаю, Вы иллюстрируете тезис " нет в HTML конструкций вроде ng-repeat=«todo in todos»". Если есть желание, не проблема будет и валидным сделать, там есть разный синтаксис использования ng* директив. Ну а во-вторых — не подерусь. Зачем? :)
Я не до конца понял что и зачем Вы хотите, но вот: jsfiddle.net/vajBW/4/
Подозреваю, что Вы ищете что-нибудь, что есть в WPF, но нет в AngularJS, чтобы показать превосходство WPF на сферическом примере в вакууме. Это обязательно у Вас получится :) По-крайней мере, в 2012г. ;)
на любом тьюринг-полном языке можно написать что угодно. Даже на brainfuck. Это не делает их все концептуально равными. И птичий ng-язык — это не HTML. Это ещё одна технология в стеке, ещё один костыль в коллекции.
Я хочу, чтобы в списке отображались те данные, которые есть. И в той же последовательности, как они даны. Вы, видимо, не догнали радости DataTemplate, раз правите данные и создаёте новый список — это лишние движения по созданию лишних сущностей.
Это не сферический пример, посмотрите на страницу поиска яндекса — для новостей один шаблон, для сайтов другой, для видео — третий, и всё одним списком отсортировано на сервере согласно яндексовому рандому.
Я хочу, чтобы в списке отображались те данные, которые есть. И в той же последовательности, как они даны. Вы, видимо, не догнали радости DataTemplate, раз правите данные и создаёте новый список — это лишние движения по созданию лишних сущностей.
Это не сферический пример, посмотрите на страницу поиска яндекса — для новостей один шаблон, для сайтов другой, для видео — третий, и всё одним списком отсортировано на сервере согласно яндексовому рандому.
у любого Тьюринг-полного языка достаточно прочности, чтоб написать что угодно. Это не делает brainfuck концептуально не сильно отстающим. Птичий ng-язык — это ещё одна технология в стеке, ещё одни грабли в коллекции.
Я хочу, чтобы данные данные были отображены одним списком в той же последовательности как они даны, но разными шаблонами. Раз вы редактируете данные и создаёте второй список — видимо вы просто не догнали радостей DataTemplate.
И пример не сферический. Зайдите на страницу результатов поиска яндекса, увидите список из 10 объектов, отсортированных согласно яндексовскому рандому. Но у новостей один шаблон, у картинок — другой, у видео — третий.
И я в AngularJS ничего не ищу, вы его принесли мне в ответ на упоминание DataTemplate.
Я хочу, чтобы данные данные были отображены одним списком в той же последовательности как они даны, но разными шаблонами. Раз вы редактируете данные и создаёте второй список — видимо вы просто не догнали радостей DataTemplate.
И пример не сферический. Зайдите на страницу результатов поиска яндекса, увидите список из 10 объектов, отсортированных согласно яндексовскому рандому. Но у новостей один шаблон, у картинок — другой, у видео — третий.
И я в AngularJS ничего не ищу, вы его принесли мне в ответ на упоминание DataTemplate.
Ок, пример не сферический. Я, как Вы выразились, «не догнал радостей» Вашего примера. Вы же не удосуживаетесь реальные работоспособные примеры приводить, а я, к сожалению, чтению мыслей не обучен.
jsfiddle.net/vajBW/5/
Я так понимаю в WPF это будет реализовано через ItemTemplateSelector и класс-наследник от DataTemplateSelector на C#. Если так, то обратите внимание, что я в своем примере обошелся декларативными возможностями AngularJS.
Но это детали, у меня не было никогда никакого желания доказывать превосходство связки HTML+CSS+JS — рынок докажет, и время покажет, что именно.
И я не считаю AngularJS костылем. Я считаю его одним из вариантов реализации будущих возможностей HTML. И принес я его в ответ на пример к тезису «WPF концептуально сильно превосходит HTML хотя бы тем, что я могу в окно класть не дивы, а объект/xml/что угодно.», чтобы проиллюстрировать, что отрыв не настолько большой, как кажется.
jsfiddle.net/vajBW/5/
Я так понимаю в WPF это будет реализовано через ItemTemplateSelector и класс-наследник от DataTemplateSelector на C#. Если так, то обратите внимание, что я в своем примере обошелся декларативными возможностями AngularJS.
Но это детали, у меня не было никогда никакого желания доказывать превосходство связки HTML+CSS+JS — рынок докажет, и время покажет, что именно.
И я не считаю AngularJS костылем. Я считаю его одним из вариантов реализации будущих возможностей HTML. И принес я его в ответ на пример к тезису «WPF концептуально сильно превосходит HTML хотя бы тем, что я могу в окно класть не дивы, а объект/xml/что угодно.», чтобы проиллюстрировать, что отрыв не настолько большой, как кажется.
Чего-то комментарии пропадают, балуется чтоль кто…
Ссылочку забыл приложить.
Flex.
Связка Flash+MXML+CSS эффективнее?
Возможно именно css + js + html — это отвертка/сверло/паяльник для чего-то более сложного?
в одной руке не удержишь все, но лучше чем молоток.
в одной руке не удержишь все, но лучше чем молоток.
Промахнулся, мало быть ветвью выше.
Можно сделать форму на одном HTML и кнопки будут работать.
Можно использовать ExtJS и забыть о верстке.
Решения есть и они работают.
Можно использовать ExtJS и забыть о верстке.
Решения есть и они работают.
а ajax?
Когда я работал над кастомным решением для построения Rich интерфейсов, аналогичном ExtJS, но в духе WPF, то у меня возникало ощущение, что я пишу браузер поверх другого браузера. С кучей оптимизаций, чтобы избавиться от лишних reflow и repaint. С кучей хаков, чтобы всё это выглядело идентично во всех браузерах. И никак не мог избавиться от ощущения, что если бы я напрямую работал с графической подсистемой, минуя HTML, то вышло бы на порядок проще.
HTML ограничивает разработку сложных интерфейсов. Для магазинов, блогов и разного рода социальных приложений, он отлично подходит, но как только требуется создать сложный интерфейс, то приходится делать множество лишних телодвижений, городить кучу JS кода, склеивающего хрупкую конструкцию из HTML/CSS.
Даже простейшую задачу центрирования одного блока произвольного размера внутри другого довольно сложно решить, не прибегая к хакам. Или ту же задачу растягивания внутреннего блока на всю высоту родительского, скажем, когда нам нужен 100 пиксельный хидер, а за ним 100%-100px блок контента, внутри которого ещё два блока с высотой по 50% от их родителя, и пятипиксельным отступом между ними.
Да, я знаю про flex box, про grid layout, и я буду счастлив, когда их доведут до ума и имплементируют во всех браузерах, хотя и они наверняка не покрывают всех случаев.
HTML ограничивает разработку сложных интерфейсов. Для магазинов, блогов и разного рода социальных приложений, он отлично подходит, но как только требуется создать сложный интерфейс, то приходится делать множество лишних телодвижений, городить кучу JS кода, склеивающего хрупкую конструкцию из HTML/CSS.
Даже простейшую задачу центрирования одного блока произвольного размера внутри другого довольно сложно решить, не прибегая к хакам. Или ту же задачу растягивания внутреннего блока на всю высоту родительского, скажем, когда нам нужен 100 пиксельный хидер, а за ним 100%-100px блок контента, внутри которого ещё два блока с высотой по 50% от их родителя, и пятипиксельным отступом между ними.
Да, я знаю про flex box, про grid layout, и я буду счастлив, когда их доведут до ума и имплементируют во всех браузерах, хотя и они наверняка не покрывают всех случаев.
Всё зависит от задач.
Насколько я понял, ваше решение для Rich-интерфейсов должно было работать на всех платформах.
И если бы оно работало напрямую с графической подсистемой, то пришлось бы писать для двух как минимум (Win и Mac). К тому же, у Google получается делать сложные интерфейсы, а значит это не что-то непостежимое.
Насколько я понял, ваше решение для Rich-интерфейсов должно было работать на всех платформах.
И если бы оно работало напрямую с графической подсистемой, то пришлось бы писать для двух как минимум (Win и Mac). К тому же, у Google получается делать сложные интерфейсы, а значит это не что-то непостежимое.
С другой стороны, у гугл огромная команда разработчиков. У одного только GMail постоянная команда из примерно сотни инженеров. Думаю, что при использовании более удобных технологий людей потребовалось бы меньше, либо они бы выполняли больше эффективной работы.
И да — мне нравится HTML/CSS/JS (концептуально). Проблема, как это часто бывает, в реализации.
И да — мне нравится HTML/CSS/JS (концептуально). Проблема, как это часто бывает, в реализации.
Да RIA даже с использованием фреймворков типа GWT убивает тем, какой код получается уже на этапе написания — при компиляции — и говорить не о чем. На этапе написания очень круто выглядит Vaadin, но у него есть другие проблемы. Но по крайней мере оба эти инструмента позволяют забыть про HTML и JS
Центрирование и растягивание — это, имхо, проблемы CSS, а не HTML.
Если бы в HTML было бы что-то наподобие Grid из XAML, то эти задачи решались бы намного проще. Так что это скорее проблемы HTML. А в CSS можно до бесконечности накручивать layout фиксы.
Не знаком с XAML, но, имхо, не место гридам и другим layout в HTML. Если я решу изменить сетку 3х3 на 2х5 (например при сужении окна или на мобильном девайсе), то хотелось бы не трогать html, а чисто средствами css рулить, скажем применять разные раскладки к элементам с помощью media query.
Если это выглядит костылём в CSS, тогда надо придумывать новый язык для раскладок и интегрировать его с html также как интегрированы css и js. Что-то типа
Если это выглядит костылём в CSS, тогда надо придумывать новый язык для раскладок и интегрировать его с html также как интегрированы css и js. Что-то типа
<link type="layout" href="..."> или ввести тэг layout с функциональностью аналогичной script или style — включение не html кода напрямую (или из внешнего источника). Хотя может даже script хватит с новым type, но имхо не очень семантично
Всё же HTML — это HTML. Если Вам необходимо работать напрямую с ресурсами системы, используйте десктопные API. И нет никакой проблемы :)
Я бы посмотрел как вы забудете о вёрстке, когда придёт время темизировать приложение, или прикручивать не стандартно предусмотренные фичи в интервейсе.
Если нужно темизировать, то при любых технологиях нужно приложить усилия.
Или Вы знаете секрет типа "$newInterface = true"?
Или Вы знаете секрет типа "$newInterface = true"?
Я к тому, что всегда будет необходимость отойти от стандарта, а вместе с этим наткнутся на кучу костылей.
Пусть даже сейчас кто то напишет «мега фреймворк», где новый интерфейс будет включатся одной строкой кода, то завтра понадобиться интерфейс еще новей, для которого придётся перехачить новый «мега фреймворк», или написать похожий заного.
Пусть даже сейчас кто то напишет «мега фреймворк», где новый интерфейс будет включатся одной строкой кода, то завтра понадобиться интерфейс еще новей, для которого придётся перехачить новый «мега фреймворк», или написать похожий заного.
XML+XSLT :) Проблема в том, что при сильно отличающихся темах (не цветами и шрифтами, а компоновкой) на выходе получим html-файлы, которые будут отличаться между собой не только ссылкой на разные css, но и остальным содержанием.
JFYI: Motherfuсker — человек, вступающий в половую связь с своей матерью. Вы уверены, что это подходящая картинка для IT-ресурса?
Это цитата из классического фильма.
Можете кликнуть по картинке и посмотреть сайт от IT-компании.
И не принимайте все близко к сердцу.
Можете кликнуть по картинке и посмотреть сайт от IT-компании.
И не принимайте все близко к сердцу.
Не имел чести созерцать. Он там весь такой?
А, ну как-то не довелось посмотреть. Если оно всё там такое, то и не доведётся.
«Пастернака не читал, но осуждаю!»
Ну и к чему эта замечательная цитата? Я сказал, что «Криминальное чтиво» — унылая поделка унылого режисёра с унылыми актёрами ни о чём? Нет, я сказал, что из-за э… ненормативной лексики, с большой вероятностью я его смотреть не буду. Вот и всё.
«Криминальное чтиво» — это картина о ярких представителях криминального мира. Они что, должны светские беседы вести?
Я вот тоже не люблю, когда люди употребляют ненормативную лексику, но если бы в фильме ее не было, я бы этому фильму просто не поверил.
Я вот тоже не люблю, когда люди употребляют ненормативную лексику, но если бы в фильме ее не было, я бы этому фильму просто не поверил.
А, то есть это фильм про уголовников, которые матерятся (и говорят на фене)? Ну совсем ни малейшего желания смотреть нет. Россия и без того пропитана уголовной культурой, так что увеличивать её количество явно не стоит.
Русифицированный вариант сайта по этой картинке (не такой красивый, к сожалению):
goo.gl/k4IHi
goo.gl/k4IHi
Don't.take.the.word.literally.
Ну нельзя же таким занудой быть. И, кстати, не обязательно со своей…
А я вот знаю как сделать оба интерфейса как на HTML, так и допустим на Qt (хотя не принципиально, можно хоть на чистом WinAPI и Xorg). И с такими сложными интерфейсами усилия по верстанию в HTML кроссбраузерно будут сопоставимы с усилиями написать это на Qt. Вот только вкладка Google+ у меня съедает 134 Мб памяти, а на Qt оно съест на порядок меньше, и работать быстрее будет.
HTML вполне подходит для простеньких страничек вордпреса/друпала/джомлы/сайт-на-коленке, но тот же Google в прямую говорит что веб движется в сторону Rich Internet Applications, а для них HTML+CSS+JavaScript это уже громоздкий и не удобный инструмент.
HTML вполне подходит для простеньких страничек вордпреса/друпала/джомлы/сайт-на-коленке, но тот же Google в прямую говорит что веб движется в сторону Rich Internet Applications, а для них HTML+CSS+JavaScript это уже громоздкий и не удобный инструмент.
А можно будет интерфейс на Qt открыть за 2 секунды без установки всяких программ?
Или обновить без отвлечения внимания пользователя?
Или обновить без отвлечения внимания пользователя?
Ну тогда надо было автору так и написать «Лично я не представляю как сделать вот такой классный контрол любыми другими средствами и ЧТОБЫ ОН ОТКРЫВАЛСЯ ЗА 2 СЕКУНДЫ БЕЗ УСТАНОВКИ ВСЯКИХ ПРОГРАММ и так далее.» Не додумывайте за автора другие плюшки. Он сказал, что не знает как сделать такое не на хтмл, ему ответили. Хотя сделать можно и красивше и на куче других технологиях — флеш, силверлайт, Qt, QML и так далее. Щенячий восторг автора не совсем понятен. Если бы он просто сказал «посмотрите, как круто», это одно, а если он еще и проявляет-выпячивает свою, не скажу некомпетентность, но недостаток знания — это совсем другое.
А можно будет интерфейс на HTML открыть за 2 секунды без установки браузера?
Да, в каждой системе предустановлен браузер.
Ну что ж, удачи вам в написании подобного кросс-браузерного контрола под предустановленные браузеры в MacOS/Linux/Win7/Win8/WinXP ;)
Я привёл пример кроссбраузерных приложений.
Да и сам такие пишу.
Да и сам такие пишу.
А я сам пишу всякие разные плюшки на Qt/QML, поэтому ваши слова «лично я не представляю как сделать вот такой классный контрол любыми другими средствами» вызывают не более, чем улыбку.
Может ещё сравним объём кода/время написания подобного контрола на Qt/QML и на HTML, который будет одинаково работать во всех предустановленных браузерах (вы ведь помните, какой предустановленный браузер в WinXP, верно?)
Может ещё сравним объём кода/время написания подобного контрола на Qt/QML и на HTML, который будет одинаково работать во всех предустановленных браузерах (вы ведь помните, какой предустановленный браузер в WinXP, верно?)
WinXP давно пора на свалку отправить. Как только выйдет Win8 + IE10, и Google откажется от поддержки IE8 (а случится это меньше, чем через полгода), о линейке IE до 9 версии можно будет забыть, как о кошмарном сне.
На попятную? Ожидаемо :)
>WinXP давно пора на свалку отправить
Пора, ага. Вот только она всё ещё представляет собой более 30% мировой статистики (по версии StatCounter). Так что извините, но в данный момент говоря о «кроссбраузерных интерфейсах в предустановленных браузерах» вы говорите в том числе и о IE7. Ну что, вы всё ещё хотите посоревноваться в написании красивых контролов или всё же повремените до наступления светлого будущего, когда IE будет версии 9 и выше?
>WinXP давно пора на свалку отправить
Пора, ага. Вот только она всё ещё представляет собой более 30% мировой статистики (по версии StatCounter). Так что извините, но в данный момент говоря о «кроссбраузерных интерфейсах в предустановленных браузерах» вы говорите в том числе и о IE7. Ну что, вы всё ещё хотите посоревноваться в написании красивых контролов или всё же повремените до наступления светлого будущего, когда IE будет версии 9 и выше?
IE6 уже похоронили. Но даже для него можно сделать рабочее приложение, без супер-штук.
По поводу Qt/QML.
Я не встречал ещё таких плюшек в обычных приложениях, поэтому лично я не представляю.
По поводу Qt/QML.
Я не встречал ещё таких плюшек в обычных приложениях, поэтому лично я не представляю.
>IE6 уже похоронили.
Счастье-то какое! Наконец-то похоронили браузер, вышедший в 2001-м году! :D
>Но даже для него можно сделать рабочее приложение, без супер-штук.
Так мы-то вроде как раз о супер-штуках тут говорим, разве нет?
>Я не встречал ещё таких плюшек в обычных приложениях, поэтому лично я не представляю.
«Я не встречал» != «Этого нет».
// ваш Капитан
Счастье-то какое! Наконец-то похоронили браузер, вышедший в 2001-м году! :D
>Но даже для него можно сделать рабочее приложение, без супер-штук.
Так мы-то вроде как раз о супер-штуках тут говорим, разве нет?
>Я не встречал ещё таких плюшек в обычных приложениях, поэтому лично я не представляю.
«Я не встречал» != «Этого нет».
// ваш Капитан
Спасибо, Капитан!
Firefox 3.5, вышедший в 2009 тоже фактически похоронили.
Потому что веб, как и многое другое, развивается очень интенсивно.
Я говорю о супер штуках для 90% пользователей.
Они кликнут по ссылке и через секунду увидят красивое приложение.
Также, я не отрицаю что это можно сделать даже на ассемблере.
Но я вижу больше таких вещей в вебе, чем где либо. Не спроста, я думаю.
Firefox 3.5, вышедший в 2009 тоже фактически похоронили.
Потому что веб, как и многое другое, развивается очень интенсивно.
Я говорю о супер штуках для 90% пользователей.
Они кликнут по ссылке и через секунду увидят красивое приложение.
Также, я не отрицаю что это можно сделать даже на ассемблере.
Но я вижу больше таких вещей в вебе, чем где либо. Не спроста, я думаю.
Даже в тех, в которых GUI не ставится по умолчанию?
Нет.
А почему нет? Chrome же обновляется незаметно.
Google может говорить о Rich Internet Applications, о не удобности HTML+CSS+JavaScript, но надо также понимать, что за всеми прелестями Dart, Go и прочих (это касается далеко не только гула) стоит также неслабая борьба за долю рынка.
Каждой компании хотелось бы, чтобы и клиентская, и серверная стороны веба писались исключительно на их технологиях, это очень удобно, никого не надо спрашивать, что делать завтра со спецификациями, можно всегда что-то поменять под себя и тд. Кто от этого выиграет понятно, кто проиграет тоже.
Каждой компании хотелось бы, чтобы и клиентская, и серверная стороны веба писались исключительно на их технологиях, это очень удобно, никого не надо спрашивать, что делать завтра со спецификациями, можно всегда что-то поменять под себя и тд. Кто от этого выиграет понятно, кто проиграет тоже.
Google говорит о неудобности HTML+CSS+JavaScript?
Я пропустил что-то интересное?
Я пропустил что-то интересное?
Ну так им не нравится реализация Javascript.
К тому же, они сделали временную конвертацию в JS.
Но они не против CSS и HTML и веб-технологий в целом.
К тому же, они сделали временную конвертацию в JS.
Но они не против CSS и HTML и веб-технологий в целом.
Справедливости ради, утверждал это не я. Но подобные тенденции действительно имеют место.
Когда Google скажут: «Мы против концепта HTML+CSS+скрипты», я удалю этот топик :-)
Двигатель без колёс и руля это не автомобиль и ездить он не сможет!
Для любой массовой технологии найдутся те, кто будет говорить, что «уже не торт», «а давайте все переделаем» и тд… Но html-ю уже более 20 лет, а он по прежнему отлично выполняет свою роль, чтобы там не говорили. Можно долго разводить холивары, но в конечном итоге только время покажет, что должно остаться, а что уйти в историю.
Да, HTML и веб-технологии в целом, дают кучу возможностей для пользователей. Но всегда находятся желающие всё типизировать, чтобы написать одну строчку и больше ничего делать.
Хорошие проекты так не делаются.
В них вкладывают много программисточасов и всё ради пользователя.
Хорошие проекты так не делаются.
В них вкладывают много программисточасов и всё ради пользователя.
HTML прекрасно выполняет свою роль — размечает гипертекст. Проблема в том, что размеченный гипертекст без интерфейсов и оформления сейчас никому не нужен. А вот с построением интерфейсов (прежде всего) и оформлением он справляется уже хуже, даже вкупе с CSS и JS. Не то, чтобы он сотоварищи не справляются вообще, но явно хуже чем специализированные решения. Но другого общего инструмента, доступного на любом (почти) десктопе, ноутбуке, плашете, телефоне и т. п. просто нет.
Специализированные решения на то и специализированные.
Вон, поглядите сколько мобильных платформ придумали (iOS, Android, WP, продолжение следует).
И всё ради единого стабильного интерфейса. Но я люблю разношёрстный веб.
Вон, поглядите сколько мобильных платформ придумали (iOS, Android, WP, продолжение следует).
И всё ради единого стабильного интерфейса. Но я люблю разношёрстный веб.
Вот и получается, что построение интерфейсов (от сложных типа гмыла до «простых „визиток“ и „бложиков“) с помощью html+css+js подобно забиванию гвоздей пассатижами. Пассатижи хороший довольно универсальный инструмент, но вот гвозди лучше забивать молотком, а откусывать шляпки кусачками. А html со товарищи выступают сейчас именно в роли пассатиж — можно сделать очень многое, но для каждого действия найдётся лучший инструмент. Причём уже не только в вебе.
Что за сравнение с вешанием картины?
Мы же космические корабли разрабатываем, а не помещения ремонтируем :-)
Мы же космические корабли разрабатываем, а не помещения ремонтируем :-)
«взгляните ещё раз на интерфейсы Google Plus, Analytics, Facebook и ощутите всю их крутость!» крутость? и это говорит человек который не вылазит с Вконтакте как я предполагаю.
Авторы вбросов предлагали некий сферический движок, и диалог:
— Вот наш новый сайт. Да. Олдскул как в 80х
— Только вот операционочку вам придется поменять, мы ее кстати ссобой принесли, на 14 дискетах.
— Вот наш новый сайт. Да. Олдскул как в 80х
— Только вот операционочку вам придется поменять, мы ее кстати ссобой принесли, на 14 дискетах.
Ну, люди забивают гвозди камнями, и что дальше? HTML — классный язык для разметки текста а не построения RIA интерфейсов, об этом вроде как и говорилось.
Согласен.
—————— 5% комментариев ——————
>Лично я не представляю как сделать вот такой классный контрол любыми другими средствами:
Я представляю, как такой контрол сделать на флеше, под .Net, да вообще на чем угодно!
И будьте серьезны — то что вы ничего кроме JS, HTML, CSS не знаете — не значит, что HTML хорош.
Я представляю, как такой контрол сделать на флеше, под .Net, да вообще на чем угодно!
И будьте серьезны — то что вы ничего кроме JS, HTML, CSS не знаете — не значит, что HTML хорош.
Ага, поэтому появляются всякие Cappuccino, Sprout Core, GWT, и прочие.
Я думаю этот комментарий от читателя хорошее этому объяснение.
Я с ним не согласен, HTML просто не создавался для _интерфейсов_, а сегодня людям нужный _интерфейсы_, а не гипер-текст.
Я вижу, что веб-технологии неплохо развиваются и количество проектов растёт не по часам.
И меня искренне удивляет желание «всё переделать срочно, а то приходится чересчур напрягаться».
И меня искренне удивляет желание «всё переделать срочно, а то приходится чересчур напрягаться».
Я сильно сомневаюсь, что Google свои проекты на голом html+css+js пишет, если не GWT, то какая-то другая абстракция. Я вот на cappuccino напишу такой интерфейс за день, что вы замесяц не сможете на html+css+js.
Это уже не первый из серии странных постов о том как вас удивляют люди, которые предпочитают простоту и лёгкость набору хаков и смутной магии. Только в противогазе стоя в гамаке на лыжах, только хардкор?
Вам нужен специальный язык для интерфейсов? Для мобильных платформ создавались языки, да как-то они все поумирали. Остались Java да Objective-c, прямо очень специальный языки для мобильных ОС и интерфейсов. :)
Вы понимаете, что html это язык разметки? Он создал для разметки документов. Для интерфейсов есть Cocoa, CocoaTouch, Qt, .Net, эта ваша Java (не знаю как там UI компонент называется), а под вязке html+css+js такого тупо нет. Поэтому и придумывают костыли типа GWT и Cappuccino.
Flash был движком для создания анимации. БАМС! И стал движком для создания игр, потокове видео, виджеты итд итп.
Просто время идет и все адаптируются и наращивают функционал.
*и Java не моя и не подносите ее ко мне близко.
Просто время идет и все адаптируются и наращивают функционал.
*и Java не моя и не подносите ее ко мне близко.
Так Flash то развивался, а HTML слоупочил.
Давайте говорить о текущем состоянии дел :-)
Отлично, теперь понятно, почему HTML претендует на другой функционал нежели ему было уготовано? И меня кстати тоже расстраивает, что w3c возможно крупнейший слет слоупоков.
caniuse.com/
Я не вижу недостатка в функционале и возможностях.
Кроме W3C веб развивают Mozilla и Google.
Я не вижу недостатка в функционале и возможностях.
Кроме W3C веб развивают Mozilla и Google.
Вы о Whatwg? Тогда это Apple, Mozilla и Opera. У HTML все еще нет нормального способа использовать шрифты не стандартные, а вы про интерфейсы говорите.
У CSS есть способы.
Авторы вбросов о том, что HTML плохой, все сплошь и рядом десктоп программисты. Представьте, что вы писали на своем любимом языке и вдруг вода стала уходить из вашего озера. Все чаще вы встречаетесь с языками «по ту сторону» вашего понимания. Ощущение, что пытаются приучить к говну, да еще и 3х сортов. Ясно что достопочтимые сэры не обучены писать на ваших html'ях и считают это дело западло. Если же это си программист, то там вообще половое созревание считается пройденым после написания своего фреймворка.
Не стоит обижаться на них. Ну застряли ребята в своем мире и не хотят принимать условия игра на чужом поле, вот и плодят топики «HTML уже не торт, давайте придумаем LMTH!». Т.е писать на html+css+js это ужасный костыль в то время, как на Си мы сеем, пашем и строим используя тысячи костылей для соответствия времени. Такие дела.
Не стоит обижаться на них. Ну застряли ребята в своем мире и не хотят принимать условия игра на чужом поле, вот и плодят топики «HTML уже не торт, давайте придумаем LMTH!». Т.е писать на html+css+js это ужасный костыль в то время, как на Си мы сеем, пашем и строим используя тысячи костылей для соответствия времени. Такие дела.
I agree :-)
Попробую обьяснить как это выглядит с моей стороны.
Я десктоп и мобайл девелопер (и раньше флеш-флекс). И всегда тихо смеюсь в бороду, когда читаю очередную статью в стиле «Вау!!! Смотрите, я седлал скругленные кнопки!!! Это так круто!!»
Так как я знаю, что скругленные кнопки это точно не «Вау!», а дело 2х секунд.
И такой контрол, как привели в примере я б на флексе заестимейтил ну максимум на 2 часа работы.
А в последнее время из чисто маркетинговых причин некоторые компании стали преподносить ХТМЛ как технологию будущего. Мне, лично, это как-то фиолетово, но видимо кого-то это достает. Они и делают вбросы. Или может им подсунули проект на HTML и они, увидев, как у вас все печально, вскипели от негодования.
Я десктоп и мобайл девелопер (и раньше флеш-флекс). И всегда тихо смеюсь в бороду, когда читаю очередную статью в стиле «Вау!!! Смотрите, я седлал скругленные кнопки!!! Это так круто!!»
Так как я знаю, что скругленные кнопки это точно не «Вау!», а дело 2х секунд.
И такой контрол, как привели в примере я б на флексе заестимейтил ну максимум на 2 часа работы.
А в последнее время из чисто маркетинговых причин некоторые компании стали преподносить ХТМЛ как технологию будущего. Мне, лично, это как-то фиолетово, но видимо кого-то это достает. Они и делают вбросы. Или может им подсунули проект на HTML и они, увидев, как у вас все печально, вскипели от негодования.
HTML напрямую зависит от развития браузеров. И с каждым годом количество плюшек растет. Да и один html не ходит, так что можно сделать любую связку, хоть %ваш_любимый_язык% + HTML.
Удивительно бы было если б с каждым годом количество плюшек бы уменьшалось.
> %ваш_любимый_язык% + HTML.
Мы же вроде про интерфейсы говорим, не? И каким это образом вы предлагаете мне для создания контролов в браузере использовать %ваш_любимый_язык%
Посмотрите на это с такой стороны. Сейчас 2012 год. И такие «вау-возможности» (круглый контрол из гугл+), я делал 7 лет назад еще в 6м, если не ошибаюсь, флеше. И тогда это небыло сложно. И тогда это быстро работало.
И расскажу вам одну басню. Мою последнюю игру Microsoft взялся портировать на HTML5 чтоб пропиарить IE9. Так они уже 2 месяца мучаются и не могут нормально оптимизировать рендеринг. При том, что по сравнению с мобильной версией они его очень сильно упростили. И то, что нормально работает на дохлом 600мгц АРМе, у них тормозит на ХТМЛ5 на последнем i7 3ггц.
Так-что я не спорю, гвозди можно забивать молотком, можно забивать камнем, а можно собственными гениталиями. И если кто забил гвоздь своими яйцами — виртуоз и заслуживает всяких похвал. Но это никак не значит, что яйца — лучший инструмент для забивания гвоздей.
> %ваш_любимый_язык% + HTML.
Мы же вроде про интерфейсы говорим, не? И каким это образом вы предлагаете мне для создания контролов в браузере использовать %ваш_любимый_язык%
Посмотрите на это с такой стороны. Сейчас 2012 год. И такие «вау-возможности» (круглый контрол из гугл+), я делал 7 лет назад еще в 6м, если не ошибаюсь, флеше. И тогда это небыло сложно. И тогда это быстро работало.
И расскажу вам одну басню. Мою последнюю игру Microsoft взялся портировать на HTML5 чтоб пропиарить IE9. Так они уже 2 месяца мучаются и не могут нормально оптимизировать рендеринг. При том, что по сравнению с мобильной версией они его очень сильно упростили. И то, что нормально работает на дохлом 600мгц АРМе, у них тормозит на ХТМЛ5 на последнем i7 3ггц.
Так-что я не спорю, гвозди можно забивать молотком, можно забивать камнем, а можно собственными гениталиями. И если кто забил гвоздь своими яйцами — виртуоз и заслуживает всяких похвал. Но это никак не значит, что яйца — лучший инструмент для забивания гвоздей.
Игру? На HTML? Да если ее вообще портируют, это уже значит что HTML сделал огромный шаг в развитии.
Так я не понял, вы какой язык пропагандируете на замену?
Так я не понял, вы какой язык пропагандируете на замену?
Я не пропагандирую замену. Я просто иронизирую над теми, кто думает, что делать кнопки с круглыми углами это «вау!». И, как я указал выше, мне фиолетово, если кто-то забивает гвозди гениталиями.
Но я ставлю свои 50 центов на то, что веб в том виде, в каком он есть сейчас, не станет платформой для программ с богатым интерфейсом.
И вообще дико, что пост человека, который настолько открыто демонстрирует свою техническую ограниченость («Лично я не представляю как сделать вот такой классный контрол любыми другими средствами:») висит на главной.
Но я ставлю свои 50 центов на то, что веб в том виде, в каком он есть сейчас, не станет платформой для программ с богатым интерфейсом.
И вообще дико, что пост человека, который настолько открыто демонстрирует свою техническую ограниченость («Лично я не представляю как сделать вот такой классный контрол любыми другими средствами:») висит на главной.
Нуууууууу, я бы не загадывал. Я честно вообще в интернет не верил. Однако выстрелил собака. А ведь как мы его прикладывали в эхах, мол говно — не поплывет. Оказалось поэтому и поплыл.
Есть обьективные технические причины почему в том виде, в котором сейчас развивается ХТМЛ, он не станет платформой для богатых интерфейсов. На главной сейчас висит порт Wolf-а на хтмл. Игра 20(!!!) летней давности.В опере не работает. Подумайте почему. Наверное не потому что хтмл5 крут.
Ну это уже крайность. Этот как объявить, что 3д движок говно, т.к Кризис на линуксе не запускается. Да да, сейчас браузеры как операционные системы для сайтов.
Да нет. Никто не заявлял, что кризис кроссплатформеный.
А одним из преимуществ ХТМЛ как раз называют кроссплатформенность и открытость. И множество реализаций. Вот только никто не говорит о том, что реализации виртуальной машины разными вендорами впринцыпе не могут работать одинаково. А тут еще проблема со спецификациями — каждый пробует продвинуть свою.
В результате вместо кроссплатформенности имеем фрагментацию. Причем такую, когда даже простые (20 лет прошло!!!) программы работают очень по разному (читай не работают).
А одним из преимуществ ХТМЛ как раз называют кроссплатформенность и открытость. И множество реализаций. Вот только никто не говорит о том, что реализации виртуальной машины разными вендорами впринцыпе не могут работать одинаково. А тут еще проблема со спецификациями — каждый пробует продвинуть свою.
В результате вместо кроссплатформенности имеем фрагментацию. Причем такую, когда даже простые (20 лет прошло!!!) программы работают очень по разному (читай не работают).
Я к примеру предлагаю выпилить HTML, CSS и разогнать W3C, раз портирование игры значит, что «HTML сделал огромный шаг в развитии.»
Я делаю ежедневные веб-приложения для десятков тысяч людей последние 5 лет.
И лично для меня, это важнее, чем игры.
Геймеры могут поставить флеш или плагин при желании.
И лично для меня, это важнее, чем игры.
Геймеры могут поставить флеш или плагин при желании.
Геймеры могут поставить флеш или плагин при желании.
Т.е. вы добровольно признаете, что для разработки чего-то сложного html+css+js просто-напросто непригодны?
Да, конечно.
Сложное и специфическое требует специфического.
Сложное и специфическое требует специфического.
Да в том и дело, что игры — это не нечто специфическое. Я вообще подозреваю, что если кол-во игр не больше количества приложений всех остальных классов, то как минимум является самым первым классом по количеству.
И вообще, спор был именно о том, что html+css+js непригодны для разработки сложного и специфического. Потому, что хтмл — язык разметки гипертекста. А не приложений. Специфика современного интернета под хтмл вообще не подходит. И чем дальше, тем будет хуже.
И вообще, спор был именно о том, что html+css+js непригодны для разработки сложного и специфического. Потому, что хтмл — язык разметки гипертекста. А не приложений. Специфика современного интернета под хтмл вообще не подходит. И чем дальше, тем будет хуже.
Я показал примеры приложений для миллионов ежедневных пользователей.
В игры играют не так много, как кажется тем кто в них играет.
В игры играют не так много, как кажется тем кто в них играет.
Я говорил про игры как самый большой класс приложений по количеству, а не по времени использования. Ладно, давайте возьмем самое часто используемое приложение. Операционную систему. Которая запускает бинарник. Впрочем, что-то я уж сильно передергиваю.
Что я на самом деле хотел сказать: веб не подходит для разработки полноценных приложений. Все, что можно сделать на связке html+css+js можно гораздо лучше и полноценее сделать на других технологиях. А некоторые моменты ваш хваленный html вообще не может, и вряд-ли сможет в ближайшие лет пять.
Что я на самом деле хотел сказать: веб не подходит для разработки полноценных приложений. Все, что можно сделать на связке html+css+js можно гораздо лучше и полноценее сделать на других технологиях. А некоторые моменты ваш хваленный html вообще не может, и вряд-ли сможет в ближайшие лет пять.
Веб полноценно обеспечивает мне 90% повседневных задач.
И это замечательно.
Но если кому-то трудно понять огрехи развития веба и написать больше строчек кода, то он может написать Facebook на Qt и продвинуть его на рынок, например.
И это замечательно.
Но если кому-то трудно понять огрехи развития веба и написать больше строчек кода, то он может написать Facebook на Qt и продвинуть его на рынок, например.
Веб полноценно обеспечивает мне 90% повседневных задач.
Выделил жирным кое-что. Подумайте почему.
Но если кому-то трудно понять огрехи развития веба и написать больше строчек кодаВы сейчас упрекаете десктоп-программистов за то, что они не желают пользоваться кривым, плохо спроектированным инструментом?
то он может написать Facebook на Qt и продвинуть его на рынок, например.Первоначальная идея вообще-то написать не отдельное приложение, а платформу которая будет поддерживать основную фичу веба — возможность практически мгновенно получить что-то, но без остальных качеств веба.
Кстати, а вы в чём разработкой html/js/что_там_ещё занимаетесь?
Ядро Linux портировали :-)
Вот ведь незадача… целое ядро линукса портировали, а мою игрушку не могут :D
Ну и толку, что портировали. Основная претензия была не к тому, что просто портировать не могут, а не могут сделать так, чтобы в неё можно было играть.
Сравнения по скорости с реальным ядром линукса смотрели?
Сравнения по скорости с реальным ядром линукса смотрели?
Ну и бред. На javascript написали виртуальную машину, на которой запустили бинарник.
>Ядро Linux портировали :-)
Вы про вот это, что ли: bellard.org/jslinux/?
Тогда у меня для вас плохие новости: вы ни хера не смыслите в том, о чём говорите. На JS написали эмулятор PC, в котором запускается обычное ядро, написанное на C.
Вы про вот это, что ли: bellard.org/jslinux/?
Тогда у меня для вас плохие новости: вы ни хера не смыслите в том, о чём говорите. На JS написали эмулятор PC, в котором запускается обычное ядро, написанное на C.
Я не автор, но поддерживаю авторов частично. В принципе HTML меня устраивает (хотя XML больше нравится), как и JS (хотя можно было и что-нить другое взять за стандарт, более «оопное» и императивное). Но вот CSS… Как-то он по-моему застрял лет 10 назад — CSS2.1 должны были принять лет 10 назад, а не в прошлом году. И не тем застрял, что закругленных уголков или градиентов не хватало, а своей визуальной моделью, расчётом (вернее его почти полным отсутствием) позиций и размеров.
Да, CSS в текущем виде несколько архаичен. В идеале, HTML следовало бы превратить в «голый» data-container, а все представление передать в CSS, но тормозит здесь именно последний, он явно не дорос до этих целей.
Особенно обидно понимать, что «не дорос» не смотря на то, что создавался с целью отделить представление от данных.
Все же CSS изначально для несколько иных целей предназначался. Смотрите, разделение на данные, представление и логику — это классическая MVC-модель, о чем выше упоминалось. В текущем варианте, разбиение HTML/CSS/JS не тождественно разбиению M/V/C, т.к. в HTML слишком много V, а в CSS — слишком мало.
Но дело в том, что «представление» — в целом достаточно широкое понятие, если все его сплавить в CSS, то мешанина просто перекочует туда из HTML — что, собственно, уже происходит. Поэтому (тут я немного подискутирую сам с собой), возможно, более разумным вариантом было бы ввести дополнтительное разделение на собственно стили (цвета, эффекты и т.д.) и разметку. Но поскольку CSS все же эволюционирует в другую сторону (именно в сторону полного перетягивания представления на себя), это все, скорее, теоретизирование.
Но дело в том, что «представление» — в целом достаточно широкое понятие, если все его сплавить в CSS, то мешанина просто перекочует туда из HTML — что, собственно, уже происходит. Поэтому (тут я немного подискутирую сам с собой), возможно, более разумным вариантом было бы ввести дополнтительное разделение на собственно стили (цвета, эффекты и т.д.) и разметку. Но поскольку CSS все же эволюционирует в другую сторону (именно в сторону полного перетягивания представления на себя), это все, скорее, теоретизирование.
Ну, CSS, слава богу, позволяет разделять оформление и разметку, назначая свойства элементам с одним селектором в нескольких правилах. Где-то считается хорошим стилем, где-то приняты соглашения, но встречается, когда разметка и стили друг от друга отделены (могут быть в разных файлах, могут быть в одном, могут собираться из нескольких в один при деплое). Даже описания шрифтов разбивают на части — размеры отдельно, как влияющие на размеры блоков, а прочее — в другом месте. В общем если не синтаксически, то волевым усилием эту проблему можно решить.
Просто рендерить на лету и обсчитывать все позиции не так просто. Я где-то встречал статью об этом.
Но есть всякие фреймфорки типа LESS. Могут помочь.
Но есть всякие фреймфорки типа LESS. Могут помочь.
LESS разве считает на лету? Афаик, это просто синтаксический сахар для CSS. Никаких динамических качеств он не придаёт. Исхожу хотя бы из того, что он может компилиться на сервере. Хотя могу и ошибаться и LESS каким-то чудом может, скажем, синхронизировать размеры двух блоков.
Да, это просто сахар.
Динамика на клиенте затруднит скорость рендера страницы, но ожидается в будущем.
Также как раньше я и не мечтал о векторной графике в вебе.
Динамика на клиенте затруднит скорость рендера страницы, но ожидается в будущем.
Также как раньше я и не мечтал о векторной графике в вебе.
Да вроде может. Если не путаю, LESS как раз может функционировать как на front-end (через JS), так и на back-end. В последнем случае он просто генерит CSS, а вот в первом, да, еще и придает динамику.
Вы случаем не с лепры?
А можно скриншот с пояснениями, что такого нереально крутого в интерфейсе фейсбука или аналитики? Везде достаточно прозаичная блочная верстка с интерактивными элементами, ничего потрясающего воображения я не нашел. Кружки из Google Plus немного выбиваются из общей канвы, однако и их можно реализовать, например, на XAML.
Можете сравнить с тем скриншотом из 1992 года.
Автор изначального топика сравнивал с ним какой-то урок по CSS.
Вот люди и повелись.
Автор изначального топика сравнивал с ним какой-то урок по CSS.
Вот люди и повелись.
За десять лет цветовая гамма стала поприятнее, добавилась некоторая интерактивность, а вот основные элементы интерфейса (checkbox, radio button, edit box & etc) остались практически в первозданном виде. Сравнение пока неубедительно.
Ну и окна за 20 лет остались окнами.
Я про то, что говорить тогда было лучше, потому что достаточно было написать одну строку совсем не верно.
Есть десятки преимуществ, которые нам дало развитие веба.
Но тот автор решил что от своей лени можно избавиться созданием новой платформы.
Это в корне не правильно, и я не поддерживаю такие идеи.
Я про то, что говорить тогда было лучше, потому что достаточно было написать одну строку совсем не верно.
Есть десятки преимуществ, которые нам дало развитие веба.
Но тот автор решил что от своей лени можно избавиться созданием новой платформы.
Это в корне не правильно, и я не поддерживаю такие идеи.
Да ну, какие же преимущества дало развитие веба? (не путать веб с интернетом)
Не от лени, а от того, что текущая платформа — отстой
Но тот автор решил что от своей лени можно избавиться созданием новой платформы.
Не от лени, а от того, что текущая платформа — отстой
Список того, что появилось можно посмотреть тут: caniuse.com/
Платформа не идеальная, в виду кучи компаний работающей над ней.
Но в тоже время она самая мощная на сегодняшний день.
Платформа не идеальная, в виду кучи компаний работающей над ней.
Но в тоже время она самая мощная на сегодняшний день.
Вы мне дали список того, что появилось в вебе. Какие нам (программистам и пользователям) преимущества дало развитие веба?
Ну если не сможете ответить на предыдущий вопрос, ответьте на другой — что из этого списка нету в других платформах? Я буду рад, если вы найдете хотя-бы что-то, что появилось в вебе раньше.
Ну если не сможете ответить на предыдущий вопрос, ответьте на другой — что из этого списка нету в других платформах? Я буду рад, если вы найдете хотя-бы что-то, что появилось в вебе раньше.
Youtube (video), Twitter (real-time web), Google Docs (svg, canvas, fonts, etc) — я считаю прорывом в том, что я могу увидеть в окне браузера. И я очень рад этому.
Youtube использует флеш, поэтому использование этого сервиса как вашего аргументу по поводу html+css+js…
Twitter — множество людей предпочитают десктоп-клиенты браузеру. Угадайте почему?
Google Docs — ну это не аргумент, это уже было на десктопе.
Twitter — множество людей предпочитают десктоп-клиенты браузеру. Угадайте почему?
Google Docs — ну это не аргумент, это уже было на десктопе.
Есть HTML5-версия Youtube и она готова для мобильных устройств.
Google Docs — это прорыв в веб-технологиях.
Я могу открыть docs.google.com и бесплатно и легко оформить документ.
И для меня это аргумент.
Google Docs — это прорыв в веб-технологиях.
Я могу открыть docs.google.com и бесплатно и легко оформить документ.
И для меня это аргумент.
Есть HTML5-версия Youtube и она готова для мобильных устройств.
Замечательно. Но поздно. Первоначально появился ютуб на флеше, аргумент плохой.
Вообще, вы кажется, не понимаете, чего я от вас хочу.
Да ну, какие же преимущества дало развитие веба?
Давайте я перефразирую свой вопрос. Что такое есть/появилось в этом вашем html+css+js, чего нет на десктопных технологиях?
Нету ничего нового :-)
Если рассматривать каждое приложение отдельно, то да, ничего нового. Обычный клиент-сервер или трехзвенка, да ещё с ненужными слоя. Но вот мне в голову не пришло примера аналогичной технологии/стэка, которые допускали бы работу кучи клиентов от разных вендоров на разных платформах с кучей серверов (в смысле сервисов) от разных вендоров на разных платформах. Чтобы клиент мог загружать в себя приложения с функциональностью от простого вывода форматированного текста до, в принципе, виртуальной машины для других приложений.
О да, и именно это бесит, что такая замечательная технология/стэк является настолько кривой
Это, по-моему, закономерно, когда придумывают удачную технологию для решения одной задачи, она становится популярной, её начинают применять и в других из-за лени по инерции и/или отсутствия других, она впитывает новые идеи и концепции изначально не предусмотренные, но из-за груза BC и популярности серьезные архитектурные изменения вносить не представляется возможным.
>Google Docs — это прорыв в веб-технологиях.
Я могу открыть docs.google.com и бесплатно и легко оформить документ.
А в чём прорыв-то? В том, что теперь в вебе можно делать то, что на десктопе можно было делать уже лет 10 как?
Вы ведь помните, что вопрос звучал «что из этого списка нету в других платформах?» То, что вы привели, можно не хуже (а то и лучше) делать при помощи десктопных приложений.
Я могу открыть docs.google.com и бесплатно и легко оформить документ.
А в чём прорыв-то? В том, что теперь в вебе можно делать то, что на десктопе можно было делать уже лет 10 как?
Вы ведь помните, что вопрос звучал «что из этого списка нету в других платформах?» То, что вы привели, можно не хуже (а то и лучше) делать при помощи десктопных приложений.
>Но в тоже время она самая мощная на сегодняшний день.
Поправочка: самая мощная из известных вам. Это большая разница, как выяснилось.
Поправочка: самая мощная из известных вам. Это большая разница, как выяснилось.
Вот выше пишут — плохо, плохо.
А как же хтмл5?
А как же хтмл5?
Все просто: html — это АСМ. На асме можно написать все, что угодно, но собственно писать, поддерживать, улучшать и развивать — в общем абсолютно все, что хотелось бы делать легче — на html, сцуко, делать долго, неудобно и требует охрененного количества костылей, которые тянутся из проекта в проект.
Прохладная аналогия. На ассемблере писать долго и сложно потому, что он слишком простой и низкоуровневый.
HTML же достаточно высокоуровнев для своих целей. Проблема в том, что цели у него изначально были другие: разметка текста.
HTML же достаточно высокоуровнев для своих целей. Проблема в том, что цели у него изначально были другие: разметка текста.
Скорее не асм, а фортран — с одной стороны высокоуровневый и можно сделать что угодно, а с другой, заточен под узкие задачи и с введением новых уровней абстракций проблема.
html требует очень много затрат для создания сложных интерфейсов, если поглядеть на wpf, то там к примеру есть интересные решения, которые бы помогли развить html, но увы, он развивается не совсем в ту сторону. Сделать бы элементарные макросы, которые позволили бы создавать свои полноценные теги, но нет, это доступно разве что только через xslt.
Очень интересно было бы услышать мнение адептов Adobe AIR. Ведь по сути это и есть ТА САМАЯ заветная платформа, о которой все говорят(AS, Flash, кроссплатформенно, скруглённые уголки за 5 сек) и отчего-то она не так популярна.
Кстати удивительно, как эта платформа не стала трендом. Когда ее анонсировали, я думал — все. Пора учить, иначе без куска хлеба останусь. И вот AIR скатился куда-то.
Ок. Вот вам моё мнение — да, Flash, AIR и Flex и есть та самая заветная платформа. Почему она не столь популярна? Уверен, найдется много людей, которые вам ТОЧНО скажут почему, но моё мнение заключается в том, что самые популярные продукты часто не являются самыми качественными и наоборот.
Я начинал программировать с Flash, но последние неколько лет занимаюсь и JavaScript/HTML/CSS, и чем больше времени я работаю в этом направлении, тем большим ненавистником этой связки я становлюсь. Дело здесь как тех пунктах, которые затронул автор статьи (хотя и их можно победить), так и в общей нестабильности этой комбинации: десятки вариантов поведения и производительности в зависимости от платформы и браузера.
Пара слов о производительности. Не хочется писать длинный трактат, но если кто-нибудь будет учитывать моё мнение — то в проектах с боее-менее сложным UI, Flash в несколько раз более производителен и гибок чем вышеназванная комбинация. И кстати я не буду спорить с любителями HTML5, пусть они решают сами.
В целом JS/HTML/CSS, в том виде в котором это сейчас есть, метафорически напоминает мне стиральную машину с кучей нестиранных вещей и тенденцией к усложнению. Единаственно на что я полагаю надежды в ближайшие 5 лет — это WebGL.
P.S. Я могу приложить несколько ссылок из числа моих работ с HTML5 и Flash, так сказать пруфов, чтобы не быть голословным, но пока не уверен что это будет кому-либо интересно.
Я начинал программировать с Flash, но последние неколько лет занимаюсь и JavaScript/HTML/CSS, и чем больше времени я работаю в этом направлении, тем большим ненавистником этой связки я становлюсь. Дело здесь как тех пунктах, которые затронул автор статьи (хотя и их можно победить), так и в общей нестабильности этой комбинации: десятки вариантов поведения и производительности в зависимости от платформы и браузера.
Пара слов о производительности. Не хочется писать длинный трактат, но если кто-нибудь будет учитывать моё мнение — то в проектах с боее-менее сложным UI, Flash в несколько раз более производителен и гибок чем вышеназванная комбинация. И кстати я не буду спорить с любителями HTML5, пусть они решают сами.
В целом JS/HTML/CSS, в том виде в котором это сейчас есть, метафорически напоминает мне стиральную машину с кучей нестиранных вещей и тенденцией к усложнению. Единаственно на что я полагаю надежды в ближайшие 5 лет — это WebGL.
P.S. Я могу приложить несколько ссылок из числа моих работ с HTML5 и Flash, так сказать пруфов, чтобы не быть голословным, но пока не уверен что это будет кому-либо интересно.
Интересно, прикладывайте.
Могу комментировать один раз в час.
Из оформленного для публикации:
HTML5
www.behance.net/gallery/oDesk-Experiments/2682639
Flash
milkdrop.org/
demo.milkdrop.org/builder/
demo.milkdrop.org/ds/
Обе технологии (Rich JS для HTML5)
demo.milkdrop.org/gravity-carousel/configurator.html
Из оформленного для публикации:
HTML5
www.behance.net/gallery/oDesk-Experiments/2682639
Flash
milkdrop.org/
demo.milkdrop.org/builder/
demo.milkdrop.org/ds/
Обе технологии (Rich JS для HTML5)
demo.milkdrop.org/gravity-carousel/configurator.html
Проблема Flash как платформы в том, что внутри куча багов, которые никто не собирается чинить. Если бы Adobe открыла и стандартизировала платформу, то их бы пришлось чинить (: А так… При всех плюсах пара багов может просто уничтожить проект.
Оно точно кроссплатформенно? Существуют как средства воспроизведения, так и создания хотя бы для трех популярных десктопных платформ и средства воспроизведения для хотя бы «большой двойкисполовиной» мобильных?
Точно, хотя я и не касался этого вопроса в своем комментарии:
en.wikipedia.org/wiki/Adobe_Flash_Player
Вкратце, поддержка воспроизведения в том или ином виде, возможно с оговорками есть:
На десктопах
Windows (начиная с XP), Linux, Solaris, and Mac OS X (с 10.6)
В мобильных
Android, Apple iOS, BlackBerry Tablet OS, Maemo, PS3, PSP, Symbian OS, Wii, Pocket PC, Windows Mobile
Несмотря на то, что список довольно внушительный, я не думаю что сейчас (и пожалуй уже) имеет смысл сравнивать эти платформы в сфере кроссплатформенности, одно можно сказать точно: при разумном спросе Flash мог быть портирован практически на любую платформу.
Возможность компиляции в том или ином виде есть в Windows, Linux и MacOS. Далее я не хочу вдаваться в детали так как это неизбежно приведет к череде уточнений и объяснений.
en.wikipedia.org/wiki/Adobe_Flash_Player
Вкратце, поддержка воспроизведения в том или ином виде, возможно с оговорками есть:
На десктопах
Windows (начиная с XP), Linux, Solaris, and Mac OS X (с 10.6)
В мобильных
Android, Apple iOS, BlackBerry Tablet OS, Maemo, PS3, PSP, Symbian OS, Wii, Pocket PC, Windows Mobile
Несмотря на то, что список довольно внушительный, я не думаю что сейчас (и пожалуй уже) имеет смысл сравнивать эти платформы в сфере кроссплатформенности, одно можно сказать точно: при разумном спросе Flash мог быть портирован практически на любую платформу.
Возможность компиляции в том или ином виде есть в Windows, Linux и MacOS. Далее я не хочу вдаваться в детали так как это неизбежно приведет к череде уточнений и объяснений.
Да. Архитектурно это ТА САМАЯ платформа.
Вот только у нее проблемы с реализацией и маркетингом.
Но в любом случае и в плане кроссплатформенности и в плане возможностей AIR на годы впереди HTML.
Вот только у нее проблемы с реализацией и маркетингом.
Но в любом случае и в плане кроссплатформенности и в плане возможностей AIR на годы впереди HTML.
только вот почему у меня гугл+ тормозит адски, а все остальные сайты — нет?
интерфейс конечно замечательный. но на моём 2.8ГГц+2.8ГБDDR2+GF8400GS безбожно тормозит
Sign up to leave a comment.
HTML уже не торт?!