Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 251
Ужас. И что теперь без всего этого делать?
Отсутствие множества инсталяций и глюков связанных с ними,
благодаря браузеру, лично меня очень радует.
А от принципа минимализма в дизайне (антоним которого мы видим на вашей картинке) я вообще в восторге.
Отсутствие множества инсталяций и глюков связанных с ними,
благодаря браузеру, лично меня очень радует.
А от принципа минимализма в дизайне (антоним которого мы видим на вашей картинке) я вообще в восторге.
Есть не только twitter и pinterest. :) Посмотрите на реальные приложения для профессионального использования. В приложениях для работы еще и не такие интерфейсы требуются и реально используются на практике. И когда их реализуют в web, то из-за несовершенства языков разметки получается полный отстой – интерфейс глючит, он не pixel perfect, не эргономичен — так как удобные контролы сложны в реализации (хотя для пользователя просты).
Вообще же интерфейс не должен быть “простым” или “сложным”, это не та шкала оценки.
Интерфейс должен экономить нервную энергию и как важнейший из критериев – реально ускорять работу человека. Позволяя ему или сэкономить минуты, или же повысить свою производительность труда, производя больше полезных действий за единицу времени – при равной или меньшей нервной нагрузке.
Да, интерфейс должен быть с минимальным порогом вхождения, по возможности. Но простота – не самоцель. Потому, что всегда за какой-то границей простота вместо ускорения работы пользователя начинает замедлять ее – ему требуется больше кликов, возникает хождение по разным частям интерфейса для сбора всех нужных данных, а что-то просто нельзя сделать в простом интерфейсе и это начинают делать вручную.
Вообще же интерфейс не должен быть “простым” или “сложным”, это не та шкала оценки.
Интерфейс должен экономить нервную энергию и как важнейший из критериев – реально ускорять работу человека. Позволяя ему или сэкономить минуты, или же повысить свою производительность труда, производя больше полезных действий за единицу времени – при равной или меньшей нервной нагрузке.
Да, интерфейс должен быть с минимальным порогом вхождения, по возможности. Но простота – не самоцель. Потому, что всегда за какой-то границей простота вместо ускорения работы пользователя начинает замедлять ее – ему требуется больше кликов, возникает хождение по разным частям интерфейса для сбора всех нужных данных, а что-то просто нельзя сделать в простом интерфейсе и это начинают делать вручную.
Такое чувство, что вы пытаетесь в вебе сделать авто кад, или 3д макс. Задавались себе вопросом, зачем? На то он и веб, что он не загружен монструозными интерфейсами и всё сводится до простоты как в плане отображения так и в восприятии. Два последних ваших абзаца можно заносить в виде вступления книги «Проектируем интерфейсы для чайников». Но как это влияет на язык, на котором эти интерфейсы пишутся? Не как.
Веб не загружен сложными интерфейсами не потому, что он веб. А потому, что их там невозможно делать.
Если в вебе есть гуглдокс — нет причин не появиться там автокаду и 3дмаксу.
Если в вебе есть гуглдокс — нет причин не появиться там автокаду и 3дмаксу.
Я и не спорю. Сам лично работал в большой компании над веб-мылом с календарём ивентов и тп для бизнес клиентов. Достаточно большое приложение, выполняющее весь функционал настольного приложения. Естественно занимался вёрсткой. Скажу честно, больше времени понадобилось выпелить то, что делали до меня. Уж не кому как мне знать, что делать веб интерфейсы возможно и достаточно просто, если хватает знаний.
> Веб не загружен сложными интерфейсами не потому, что он веб. А потому, что их там невозможно делать.
> Если в вебе есть гуглдокс — нет причин не появиться там автокаду и 3дмаксу.
Вы тут сам с собой заключили пари смотрю.
> Веб не загружен сложными интерфейсами не потому, что он веб. А потому, что их там невозможно делать.
> Если в вебе есть гуглдокс — нет причин не появиться там автокаду и 3дмаксу.
Вы тут сам с собой заключили пари смотрю.
Я пари не заключал. Я уверен, что гуглдокс — это убогий тормознутый клон нормального настольного софта.
Если автокад сделают на html — это будет убогий тормознутый клон настольного софта.
Вашего веб-мыла я не видел, но догадываюсь.
Если автокад сделают на html — это будет убогий тормознутый клон настольного софта.
Вашего веб-мыла я не видел, но догадываюсь.
Любая программа, сделанная по образу и подобию другой будет называться клоном.
А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса? Причём заметьте за бесплатно. Да, я знаю, что опен офис (либре офис) тоже бесплатен и хорошо работает, но ему не нужно при этом поддерживать огромное количество серверов для своей работы.
Гугло докс годный для быстрых заметок, для шаринга документов не высокой сложности, не более. И опишите какие именно глюки при работе с ним вы испытываете.
А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса? Причём заметьте за бесплатно. Да, я знаю, что опен офис (либре офис) тоже бесплатен и хорошо работает, но ему не нужно при этом поддерживать огромное количество серверов для своей работы.
Гугло докс годный для быстрых заметок, для шаринга документов не высокой сложности, не более. И опишите какие именно глюки при работе с ним вы испытываете.
И почему тормознуть нужно списывать сразу на интерфейс? Сам интерфейс тормозит не может, он по своей сути не отличается от обычного блога по принципам. Тормозит код, который выполняет действия передаваемые интерфейсом. Тормозит браузер, который ещё не достаточно оптимизировал свои парсеры. Нативное приложение всегда будет быстрее чем браузерное. Для примера запустите приложение нативно и в виртуальной машине, в первом случае будет быстрее. Брайзер — это наслоение, от сюда и не высокая скорость по сравнению с нативным приложением.
Если из примерно 4-х создателей браузеров тормозит у 4-х — это в консерватории что-то не так.
Давайте называть вещи своими именами. Тормозит JS, так как логика написана именно на нём. Почему он тормозит, потому что нет единого парсера, которым бы занималась одна компания и которая его оптимизировала. Потому что кроме парсера ещё куча других прослоек у браузера.
Грубо говоря
Нативное приложение:
Компилятор(Код => Фреймворк => C++) => ассемблер
Веб приложение:
JS код => Интерпретатор => Рендер => Компилятор(Код => Фреймворк => C++) => ассемблер
Грубо говоря
Нативное приложение:
Компилятор(Код => Фреймворк => C++) => ассемблер
Веб приложение:
JS код => Интерпретатор => Рендер => Компилятор(Код => Фреймворк => C++) => ассемблер
> JS код => Интерпретатор => Рендер => Компилятор(Код => Фреймворк => C++) => ассемблер
Ничего не понятно, но оч красиво. А можно такую же для .NET?
Ничего не понятно, но оч красиво. А можно такую же для .NET?
Смысл — в браузере много прослоек, конец )
Мне горько разрушать вашу внутреннюю гармонию, но в дотнете их не особо меньше.
Я не знаю .NET так же само как вы не знаете JS. )
Судя по отсутствию примера нормально работающего сайта, JS не знает никто.
Могу показать свой. Правда я им особо не хвалюсь, так как делался он на протяжении нескольких лет на разных стадиях моих знаний. Так что по хорошему нужно переделать всё.
screensider.com
screensider.com
Вы прямо открываете новое направление в коммерческой разработке. Если какая-нибудь компания выпустит стороннюю машину для JavaScript, сильно выигрывающую по производительности, то она даже сможе ее продать для применения в корпоративных системах со сложной бизнес-логикой и высокими требованиями по времени реакции на команды оператора.
Давайте называть вещи своими именами. Тормозит JS, так как логика написана именно на нём. Почему он тормозит, потому что нет единого парсера, которым бы занималась одна компания и которая его оптимизировала. Потому что кроме парсера ещё куча других прослоек у браузера.
Вы ошибаетесь. JS практически не тормозит. Тормозят манипуляции с DOM. JS здесь ни при чём.
Но опять же, это не проблема синтаксиса языка, это проблема реализации её в браузере. С другой стороны сколько нужно генерировать элементов чтобы начало тормозить? Грид лист на 9000 строк будет не удобен в читке пользователем, будет грузить сервер и канал. Для этого и делают пейджинацию, проблема решена.
Почему не делают пагинацию в Excel? Вернее вроде она есть там, но не дефолтный режим.
Потому что и в Excel мало встречаются психи, которые вместо того чтобы разделять документ на листы, делают 9000 записей.
9000 элементов в прокручиваемом списке можно и веб реализовать чтобы не тормозило. Делаем так, что бы отображались только видимые элементы, то бишь, при скроле в зависимости от направления одни ноды будут удаляться, другие добавляться. Я уверен что по такому принципу и ексель делает, а не выводит сразу 9000 записей.
9000 элементов в прокручиваемом списке можно и веб реализовать чтобы не тормозило. Делаем так, что бы отображались только видимые элементы, то бишь, при скроле в зависимости от направления одни ноды будут удаляться, другие добавляться. Я уверен что по такому принципу и ексель делает, а не выводит сразу 9000 записей.
> Любая программа, сделанная по образу и подобию другой будет называться клоном
Ну да, я так и написал. А к чему это?
> А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса?
Такой же смысл, как и в любом другом месте. Вы намекаете, что в вебе милисекунды отклика не бывает? Ну да, об этом и топик. Строго говоря есть quakelive.com, но я не уверен, что установка плагина к браузеру — это про веб.
> Гугло докс годный для быстрых заметок, для шаринга документов не высокой сложности, не более.
Кто б спорил. У меня ощущение, что вы мне пытаетесь объяснить, что веб-приложения убогими получаются. Я в курсе. Даже знаю почему.
Ну да, я так и написал. А к чему это?
> А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса?
Такой же смысл, как и в любом другом месте. Вы намекаете, что в вебе милисекунды отклика не бывает? Ну да, об этом и топик. Строго говоря есть quakelive.com, но я не уверен, что установка плагина к браузеру — это про веб.
> Гугло докс годный для быстрых заметок, для шаринга документов не высокой сложности, не более.
Кто б спорил. У меня ощущение, что вы мне пытаетесь объяснить, что веб-приложения убогими получаются. Я в курсе. Даже знаю почему.
Отклик не зависит от интерфейса, на каком языке разметки он не был бы написан. Тормозит код, который обрабатывает действия, передаваемые интерфейсом. Либо из-за того, что его так написали, не занимаясь оптимизацией, либо от плохой координации проекта, либо из-за того, что современные браузеры ещё не достаточно шутры чтобы выполнять сложные дейтсвия. Если вы до сих пор так думаете, что хтмл / цсс вина долго отклика интерфейса, нам больше не о чем говорить дальше.
А в гугле, далеко не всегда хорошо пишут код. Любая компания не застрахована от не достаточно компетентных людей
А в гугле, далеко не всегда хорошо пишут код. Любая компания не застрахована от не достаточно компетентных людей
Ну покажите сложный сайт, где код написан хорошо и ничего не тормозит, чего на гугл то пенять.
Вы читаете что я пишу? Краткая цитата «Отклик не зависит от языка разметки на котором написан интерфейс, отклик зависит от того как написан код». Я говорю только про разметку и не более, и вопрос тормознутости кода не начинал обсуждать.
А вы топик читали?
Не попадался еще ни один «тяжелый» сайт, который бы работал без задержек. Скажете, у всех разработчиков поголовно руки кривые?
А вы можете себе представить, что многие задержки случаются из-за того, что клиент передаёт / принимает информацию от сервера? И что задержка зависит уже совершенно не от кода, не от браузера, не от ос, и даже не от железа, используемого вами? А от провайдера и от отдалённости сервера сайта от вашего местоположения. Чем больше передаётся информации тем больше задержка.
Если у вас тормозят сайты, пора бы задуматься о чистке системы или смене железа.
Если у вас тормозят сайты, пора бы задуматься о чистке системы или смене железа.
Но почему-то, скажем, нативное приложение для Google+ работает значительно резвее, чем веб-версия, причем даже открытая в родном браузере. И задержек тоже никаких нет, точнее, от них приложение не виснет, а показывает крутилку.
Если у вас тормозят сайты, пора бы задуматься о чистке системы или смене железа.
Я думаю, что железо, на котором на Ultra High идет кризис (как хрестоматийный пример) и рендерятся модели в максе, вполне достаточно, чтобы отобразить сайт.
Если у вас тормозят сайты, пора бы задуматься о чистке системы или смене железа.
Я думаю, что железо, на котором на Ultra High идет кризис (как хрестоматийный пример) и рендерятся модели в максе, вполне достаточно, чтобы отобразить сайт.
Если брать нативное приложение под андроид, то оно отображает гораздо меньше информации за раз, а значит на подготовку информации сервером и загрузку клиентом нужно меньше времени.
> рендерятся модели в максе
Значит отношения в вебу вы не имете, и как он устроен тоже не знаете. О чём тогда дальше говорить?
> рендерятся модели в максе
Значит отношения в вебу вы не имете, и как он устроен тоже не знаете. О чём тогда дальше говорить?
По-вашему, невозможно работать в максе и разбираться в вебе? Так или иначе, не нужно быть поваром, чтобы оценить вкус блюда. Задержки и торможения интерфейса в вебе заметны любому.
Нет, потому что нужно работать в этой сфере, а не априори рассуждать его минус не зная дела. А вы, как минимум, не знаете, что в отличии от оффлайн приложений, когда информация хранится на вашем винчестере, информация в вебе хранится на серверах, и чтобы она попасть к вам в браузер, ей нужно сначала свариться на сервере после чего пропутешествовать по проводам и магистралям. Данная задержка называется ping. Плюс к задержке добавляется время скачки, аналогично тому как качается фильм.
Минус в мою карму вам плюса не делает, а показывает вашу слабость к само овладению. Ни когда не понимал тех, кто минусует за высказывания личного мнения, а тем более в карму. Если это вас как-то обидело или затронуло, заранее извиняюсь.
Вот мой сайт, построен полностью на JS. На нём есть только задержки подгрузки контента.
screensider.com/
Минус в мою карму вам плюса не делает, а показывает вашу слабость к само овладению. Ни когда не понимал тех, кто минусует за высказывания личного мнения, а тем более в карму. Если это вас как-то обидело или затронуло, заранее извиняюсь.
Вот мой сайт, построен полностью на JS. На нём есть только задержки подгрузки контента.
screensider.com/
Еще раз говорю — конечному пользователю пофиг, пинги там, сервер тормозит или просто задуматься решил. Он видит, что у него повисает браузер на несколько секунд. А нативное приложение показывает крутилку. И вы мне так и не ответили, чем, скажем, Google+ или Ag.ru, или еще какой-нибудь тяжелый сайт настолько вычислительно тяжелее игрового движка. Для меня кажется диковатой идея, что у всех поголовно разработчиков руки кривые и они не умеют делать сайты. Это какая-то системная проблема — проблема технологии как таковой. Собственно, об этом и пост, и об этом же я написал. Сайты тормозят. Не все, не всегда, но часто. Натив тормозит реже.
А карма из-за вашего идиотского аргумента «кто не в вебдеве, тот дурак и априорно не может ничего знать».
Вот на вашем сайте все хорошо. А с другими бывают мелкие, но раздражающие проблемы.
А карма из-за вашего идиотского аргумента «кто не в вебдеве, тот дурак и априорно не может ничего знать».
Вот на вашем сайте все хорошо. А с другими бывают мелкие, но раздражающие проблемы.
Хорошо, постараюсь по порядку ответить на все вопросы.
Почему нативное приложение быстрее работает чем веб сайт?
Потому что файлы разметки, стили, вёрстка, код, изображения оформления, пиктограммы, иконки, хранятся у вас на диске. Подгружается только информация в виде json или xml.
То бишь массив голой информации с бд сервера. Когда клиент получает массив информации, он на вашем железе подставляет его в вёрстку. Тем самым сервер не грузится сильно и контент быстро скачивается, так как имеет маленький размер в кб. Всё зависит только от скорость интернета и пинга.
Так почему же веб медленнее?
Потому что все файлы стилей, оформление, картинки оформления хранятся на сервере. Когда вы заходите на сайт, ваш браузер закачивает картинки, стили, вёрстку текущей страницы. Когда вы переходите по страницам сайта, каждый раз закачивается целая страница, содержащая в себе контент, который обременён в вёрстку — оформление.
Этот пример кода эквивалентен тому, что выше, только содержит ещё и вёрстку. Как можно заметить объём информации больше, а значит и скачиваться он будет дольше. К тому же, контент подставляется в вёрстку на железе сервера, что требует ещё некоторое не большое время. Если программист был грамотным, он позаботился о кешировании стилей, изображений, чтобы при смене страницы каждый раз они у вас заново не загружались. А так же включился архивирование (gzip) страницы перед тем, как отдать её вашему браузеру.
Я показал на примерах лишь один небольшой блок на сайте.
Какая разница между веб и нативным приложением?
Чтобы получить доступ к контенту вам нужно скачать и установить это приложение. И так с каждым приложением. Если вы используете веб, кроме браузера вам ничего больше не нужно.
> И вы мне так и не ответили, чем, скажем, Google+ или Ag.ru, или еще какой-нибудь тяжелый сайт настолько вычислительно тяжелее игрового движка
Потому что на вашем железе запускается одна копия движка. И сам движок предоставляет контролы управления монопольно только для вас. Когда речь идёт о сайте, при каждом заходе пользователя, грубо говоря, запускается по одной копии движка. Движок обрабатывает запрос, генерирует контент отдаёт вашему браузеру, после чего программа закрывается. При открытии новой страницы — запускается новая копия движка. Сайты посещает не один человек за одно мгновение времени. Посещений может быть 500 одновременных, тысячи, десятки тысяч. И для каждого запускается новая копия движка, 100 пользователей — 100 движков. По этому при совокупности запросов нужна соответствующая мощность. За мощность к тому же нудно платить. Серверы по уровня вашего железа могут стоить порядка 30-40 евро в месяц.
Почему мой сайт не страдает задержками?
Мой сайт, грубо говоря, построен по принципам, которые я описал в первом вопросе. Отличие от второго вопроса только в том, что при первом заходе — при старте, он выкачивает сразу все стили, картинки оформления, вёрстку и код. А дальше он, как и нативное приложение, принимает контент в виде «голого» массива. Так как вёрстка заранее загружена, подстановка контента в вёрстку происходит на вашем железе. Тем самым мой сервер не загружается этой операцией, и может выдавать контент достаточно быстро.
> А карма из-за вашего идиотского аргумента «кто не в вебдеве, тот дурак и априорно не может ничего знать».
Я вас не в коем случае не оскорблял, даже между срок не было повода. Я вам намекнул на то, что вы оперируетесь какими-то априори догадками. Поймите меня правильно, я не википедия и не большая энциклопедия, чтобы рассказывать о принципах работы веба всем желающим персонально.
Почему нативное приложение быстрее работает чем веб сайт?
Потому что файлы разметки, стили, вёрстка, код, изображения оформления, пиктограммы, иконки, хранятся у вас на диске. Подгружается только информация в виде json или xml.
{"random_screens":[{"id":"6844","filename":"Ms2n32","album_id":"192","album_name":"Call of Duty","album_descr":"Black Ops"},{"id":"15188","filename":"PYwLIw","album_id":"23","album_name":"Battlefield","album_descr":"Bad Company 2"},{"id":"20597","filename":"fwHP1S","album_id":"388","album_name":"Dead Island","album_descr":""},{"id":"23926","filename":"UEXoj2","album_id":"509","album_name":"The Ship","album_descr":""},{"id":"25966","filename":"257Lgn","album_id":"258","album_name":"The Elder Scrolls V","album_descr":"Skyrim"}]}
То бишь массив голой информации с бд сервера. Когда клиент получает массив информации, он на вашем железе подставляет его в вёрстку. Тем самым сервер не грузится сильно и контент быстро скачивается, так как имеет маленький размер в кб. Всё зависит только от скорость интернета и пинга.
Так почему же веб медленнее?
Потому что все файлы стилей, оформление, картинки оформления хранятся на сервере. Когда вы заходите на сайт, ваш браузер закачивает картинки, стили, вёрстку текущей страницы. Когда вы переходите по страницам сайта, каждый раз закачивается целая страница, содержащая в себе контент, который обременён в вёрстку — оформление.
<div class="c-block"><div class="title">Случайные скриншоты</div><div class="descr image random"><div class="inner" style="visibility: visible;"><div class="image-block big loaded"><a href="1702" class="page-link" title="Batman: Arkham Asylum"><img alt="" class="image" src="./images/albums/254/H64rIu-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="10552" class="page-link" title="Driver: San Francisco"><img alt="" class="image" src="./images/albums/390/SbOLA1-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="18542" class="page-link" title="DiRT 3"><img alt="" class="image" src="./images/albums/336/9G40qT-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="19252" class="page-link" title="Team Fortress 2"><img alt="" class="image" src="./images/albums/97/8DS6RH-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="21501" class="page-link" title="The Darkness II"><img alt="" class="image" src="./images/albums/521/CLd2jq-top.jpg" style="display: block;"></a></div></div><div class="inner"><div class="image-block big loaded"><a href="1599" class="page-link" title="Lara Croft and the Guardian of Light"><img alt="" class="image" src="./images/albums/255/zZsnHK-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="6627" class="page-link" title="Singularity"><img alt="" class="image" src="./images/albums/105/JxdbRM-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="7271" class="page-link" title="Killzone 2"><img alt="" class="image" src="./images/albums/392/zYhS1u-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="7525" class="page-link" title="Grand Theft Auto IV"><img alt="" class="image" src="./images/albums/62/JUAEhz-top.jpg" style="display: block;"></a></div><div class="image-block big loaded"><a href="14174" class="page-link" title="World of Warcraft"><img alt="" class="image" src="./images/albums/78/bvAiZ0-top.jpg" style="display: block;"></a></div></div></div></div>
Этот пример кода эквивалентен тому, что выше, только содержит ещё и вёрстку. Как можно заметить объём информации больше, а значит и скачиваться он будет дольше. К тому же, контент подставляется в вёрстку на железе сервера, что требует ещё некоторое не большое время. Если программист был грамотным, он позаботился о кешировании стилей, изображений, чтобы при смене страницы каждый раз они у вас заново не загружались. А так же включился архивирование (gzip) страницы перед тем, как отдать её вашему браузеру.
Я показал на примерах лишь один небольшой блок на сайте.
Какая разница между веб и нативным приложением?
Чтобы получить доступ к контенту вам нужно скачать и установить это приложение. И так с каждым приложением. Если вы используете веб, кроме браузера вам ничего больше не нужно.
> И вы мне так и не ответили, чем, скажем, Google+ или Ag.ru, или еще какой-нибудь тяжелый сайт настолько вычислительно тяжелее игрового движка
Потому что на вашем железе запускается одна копия движка. И сам движок предоставляет контролы управления монопольно только для вас. Когда речь идёт о сайте, при каждом заходе пользователя, грубо говоря, запускается по одной копии движка. Движок обрабатывает запрос, генерирует контент отдаёт вашему браузеру, после чего программа закрывается. При открытии новой страницы — запускается новая копия движка. Сайты посещает не один человек за одно мгновение времени. Посещений может быть 500 одновременных, тысячи, десятки тысяч. И для каждого запускается новая копия движка, 100 пользователей — 100 движков. По этому при совокупности запросов нужна соответствующая мощность. За мощность к тому же нудно платить. Серверы по уровня вашего железа могут стоить порядка 30-40 евро в месяц.
Почему мой сайт не страдает задержками?
Мой сайт, грубо говоря, построен по принципам, которые я описал в первом вопросе. Отличие от второго вопроса только в том, что при первом заходе — при старте, он выкачивает сразу все стили, картинки оформления, вёрстку и код. А дальше он, как и нативное приложение, принимает контент в виде «голого» массива. Так как вёрстка заранее загружена, подстановка контента в вёрстку происходит на вашем железе. Тем самым мой сервер не загружается этой операцией, и может выдавать контент достаточно быстро.
> А карма из-за вашего идиотского аргумента «кто не в вебдеве, тот дурак и априорно не может ничего знать».
Я вас не в коем случае не оскорблял, даже между срок не было повода. Я вам намекнул на то, что вы оперируетесь какими-то априори догадками. Поймите меня правильно, я не википедия и не большая энциклопедия, чтобы рассказывать о принципах работы веба всем желающим персонально.
Но ведь «клиент» из первого пункта можно без проблем на JavaScript в вебе сделать. Скачивать JSON, формировать DOM в JavaScript, вставлять в документ, и так далее.
У меня уже слегка поменялась позиция по этому поводу.
Мой сайт так и делает, правда давно уже делалось и нужно всё по хорошему переписать. Даже при этом, как вы и подметили, это работает быстрее в плане загрузки, нежели статичный сайт.
Если планируемый клиент достаточно не сложный по функционалу, то можно и через тот же PhoneGap сделать клиент на привычном html \ js \ css. Проблемы начинаются с большим количеством данных, например огромным количеством картинок (~30к, 4 колонки), которые нужно подгружать по скроллу. Не давно делали подобную задачу, так решили отображать картинки через канвас. Если грамотно оперировать ресурсами, то такой клиент будет ни чуть не хуже нативного.
Мой сайт так и делает, правда давно уже делалось и нужно всё по хорошему переписать. Даже при этом, как вы и подметили, это работает быстрее в плане загрузки, нежели статичный сайт.
Если планируемый клиент достаточно не сложный по функционалу, то можно и через тот же PhoneGap сделать клиент на привычном html \ js \ css. Проблемы начинаются с большим количеством данных, например огромным количеством картинок (~30к, 4 колонки), которые нужно подгружать по скроллу. Не давно делали подобную задачу, так решили отображать картинки через канвас. Если грамотно оперировать ресурсами, то такой клиент будет ни чуть не хуже нативного.
«А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса?»
Смысл такой: с десктопным софтом вы привязаны к одному компьютеру. С вебовским — можете спокойно переходить с одного девайса на другой, и везде находить ваши открытые документы именно в том состоянии, в котором вы их оставили.
Кстати, я убежден что гуглодокс в реальном времени транслирует изменения всем участникам сессии редактирования вовсе не потому, что это круто. Просто они таким образом избавляются от проблемы версий и мерджинга.
Для документов, которые осмысленно мерджить нельзя (графика, CAD, u-name-it), это весьма перспективный подход.
Смысл такой: с десктопным софтом вы привязаны к одному компьютеру. С вебовским — можете спокойно переходить с одного девайса на другой, и везде находить ваши открытые документы именно в том состоянии, в котором вы их оставили.
Кстати, я убежден что гуглодокс в реальном времени транслирует изменения всем участникам сессии редактирования вовсе не потому, что это круто. Просто они таким образом избавляются от проблемы версий и мерджинга.
Для документов, которые осмысленно мерджить нельзя (графика, CAD, u-name-it), это весьма перспективный подход.
> гуглдокс — это убогий тормознутый клон нормального настольного
Хух. А то я думал что это один я считаю что все эти javascript приложения это какие-то странные монстры и должны быть заменены чем то более совершенным.
Хух. А то я думал что это один я считаю что все эти javascript приложения это какие-то странные монстры и должны быть заменены чем то более совершенным.
Да откуда вы все люди? Кем вы работаете? И кто зомбирует ваш мозг?
Я переустановил виндовс, клиент мне прислал .docx, а у меня из программ только хром стоит, а открыл docs, открыл файл, почитал, написал, сохранил. Профит.
И что только я один радуюсь тому, как быстро открывается docs по сравнению с word, который по умолчанию еще и в автозагрузку, холодный старт прописывает.
Если мне понадобится, написать, серьезный труд на 3000 страниц, я скорее всего воспользуюсь Word, но если у меня нет необходимости держать его открытым больше 30 минут, все преимущества у docs.
Я переустановил виндовс, клиент мне прислал .docx, а у меня из программ только хром стоит, а открыл docs, открыл файл, почитал, написал, сохранил. Профит.
И что только я один радуюсь тому, как быстро открывается docs по сравнению с word, который по умолчанию еще и в автозагрузку, холодный старт прописывает.
Если мне понадобится, написать, серьезный труд на 3000 страниц, я скорее всего воспользуюсь Word, но если у меня нет необходимости держать его открытым больше 30 минут, все преимущества у docs.
А если бы у вас был Ворд 2010 и хром. Вы бы тоже открывали через гугл докс? ;)
PS. Я, как часто пользующийся вордом могу сказать, что он стартует меньше чем за секунду. А семерка прописывает любые приложения в быстрый старт, если вы ими часто пользуетесь.
PS. Я, как часто пользующийся вордом могу сказать, что он стартует меньше чем за секунду. А семерка прописывает любые приложения в быстрый старт, если вы ими часто пользуетесь.
У меня на ноуте с i5 с 6 гигами оператвки и семеркой, но офис открывается много дольше чем просто нажать «просмотреть» в гмейле. И просмотреть это один клик, а сохранить, открыть, потом еще и удалить, если он не нужен — зачем усложнять жизнь?
Но при этом я против облачного хранения, и, если надо что-то написать или оформить, я открою Ворд. Каждому инструменту свое применение.
Но при этом я против облачного хранения, и, если надо что-то написать или оформить, я открою Ворд. Каждому инструменту свое применение.
Сравните с офисом 2003 хотя бы (а лучше с офисом 97) — открываться будет быстрее, давая на порядок больше возможностей.
Да всякие ситуации бывают. Иногда так иногда так удобно. Вот тут товарищь сказал про файл. В таком случае все несколько иначе.
Ситуаций много. У каждого есть мозг. Зачем плодить лишние сущности и изобретать ситуации?
Ситуаций много. У каждого есть мозг. Зачем плодить лишние сущности и изобретать ситуации?
Но документ, который поддерживают Google Docs — это документ уровня Word 2.0, с ним его и надо сравнивать по быстродействию. А он, напомню, на 386 работал.
Не интерфейсами едины. Там еще есть такая малозаметная за интерфейсами вещь, как контент.
Довольно сложно ожидать, что интерфейс как на картинке способен экономить время (если не сравнивать с бумажными вариантами).
Самое смешное, во всех этих сравнениях с OS/2 в том, что единственные квадратики со скруглениями — на кнопках. А в браузерах теги выводящие кнопки, выводят их со скруглениями (и не только), что называется из коробки, даже в IE 6 (и более древних).
По сути в статье речь идет о кастомных кнопках. А тут уже можно поспорить, где проще сделать кнопочки, нарисованные дизайнером в фотошопе, в HTML или в OS/2?
По сути в статье речь идет о кастомных кнопках. А тут уже можно поспорить, где проще сделать кнопочки, нарисованные дизайнером в фотошопе, в HTML или в OS/2?
спасибо, подро… тьфу… понастольгировал :)
а вообще усложнение процесса всегда дает работу. нам.
а вообще усложнение процесса всегда дает работу. нам.
Что значит «без готовых toolkit-ов»? А OS/2 API тогда что?
OS/2 API — это примерно то же, что и браузер со своими CSS. А тулкит — это сторонняя библиотека.
Да ладно. Можно подумать что раньше писали на голом API без каких было библиотек :)
Хотя соглашусь с общей мыслью. Связка HTML + CSS + JS меня, как программиста на C++ и C#, вгоняет в уныние своими конструкциями. Единственный плюс для меня был в JS — это была хорошая практика асинхронного программирования (после «синхронных» программ на C++, так сказать встряска для мозга — другой подход, другое мышление).
Хотя соглашусь с общей мыслью. Связка HTML + CSS + JS меня, как программиста на C++ и C#, вгоняет в уныние своими конструкциями. Единственный плюс для меня был в JS — это была хорошая практика асинхронного программирования (после «синхронных» программ на C++, так сказать встряска для мозга — другой подход, другое мышление).
Можно подумать что раньше писали на голом API без каких было библиотекНе напоминайте. У меня был «весёлый» опыт написания гуёвого кода даже в отсутствие сишной стандартной библиотеки, только WinCE API через syscall'ы.
Связка HTML + CSS + JS меня, как программиста на C++ и C#, вгоняет в уныние своими конструкциями.
Может это потому что вы именно программист, а из трех перечисленного вами, только JS является языком программирования? А он скажем прямо не образец идельного синтаксиса.
а из трех перечисленного вами, только JS является языком программирования
А что такое тогда такое C++ и С#?
Формально они ЯП не являются, но практически — да. Они указывает машине что ей делать с данными. Другое дело, что HTML+CSS являются декларативными языками, а C* — императивными. Вот с этим может быть проблема «уныния».
C++ и C# вгонят в неменьшее уныние веб-технолога/верстальщика
OS/2 API скорее всего представляет собой набор заголовочных файлов, используемых для линковки и компиляции конечного нативного приложения и кроме уровня абстракции (необходимого, впрочем, imho) ничего более не утяжеляет.
Опять же — не знаю, может, не прав. ;)
Опять же — не знаю, может, не прав. ;)
Согласен с автором. Мне приходиться отдавать предпочтение Qt для быстрой разработки кроссплатформенного интерфейса. А хотелось бы иметь возможность быстрой разработки GUI для web.
Вот привязались же вы к этой форме. Да, ее за 5 минут на коленке не собрать.
Ну вот сделаем новый язык, и для него найдется точно такое же нетривиальное задание, будьте уверены. Начнем опять писать о тупиковости этого языка? Только из-за того, что разработчику понадобилось чуть больше времени, чтобы пошевелить мозгами и написать чуть больше кода?
Ну вот сделаем новый язык, и для него найдется точно такое же нетривиальное задание, будьте уверены. Начнем опять писать о тупиковости этого языка? Только из-за того, что разработчику понадобилось чуть больше времени, чтобы пошевелить мозгами и написать чуть больше кода?
Что-то я не понял как повлияет «новый язык разметки» на скорость отрисовки финтиклюшек.
Если в нем будет, например, round box как стандартное средство, то на современной карте их можно будет рисовать 900 тысяч штук в секунду, наверное (примерно). Потому, что не потребуется тянуть с сервера PNG и рисовать квадрат декодируя пожатую растровую графику его по мере ее подкачки. А это в свою очередь сейчас, чтобы страничка отображалась в IE 8 хотя бы, а не только в FF и Chrome. Допустим, пройдет еще 3 года и вопрос конкретно с round box закроется, так как минимальной версией IE будет девятая. А что со всем остальным? Как нормально сверстать хотя бы такой блокнотик с закладками на CSS/HTML без извращений и большого количества JS кода вовсе не ради динамики, а прямо для самой отрисовки и позиционирования? Макетирование на JS — это бред сивой кобылы. Представьте себе, что верстку газет и журналов приходилось бы делать через написание скриптов на JS под каждый номер заново.
Очень-очень давно такое было возможно. Только вместо JS был postscript. Он и сейчас есть но большинство думают что это формат, а не язык.
А еще был display-postscript, в NeXT.
Если вам нужны какие-то фиговины этакие в HTML/CSS — так уверен, половина этих фиговин уже есть в том же CSS3. Скругленный и повернутый прямоугольник — свойства border-radius и transform. Те браузеры, в которых эти свойства реализуются, обязаны поддерживать правильные события с мышкой. Если не поддерживают — пожалуйста, сообщайте о багах.
Какой смысл ныть «вот, я хочу это и это, а из-за мерзких старых браузеров надо три дня голову ломать и все равно криво будет»? Просто не используйте старые браузеры и не верстайте под них — заодно больше народа пересядет на новые браузеры со всеми рюшечками. Или вы думаете, что создав какой-то новый язык оформления и размертки, его сразу начнут поддерживать IE 7 и Firefox 2.0?
Какой смысл ныть «вот, я хочу это и это, а из-за мерзких старых браузеров надо три дня голову ломать и все равно криво будет»? Просто не используйте старые браузеры и не верстайте под них — заодно больше народа пересядет на новые браузеры со всеми рюшечками. Или вы думаете, что создав какой-то новый язык оформления и размертки, его сразу начнут поддерживать IE 7 и Firefox 2.0?
Смотрю вы ничего для себя не подчеркнули с прошлой статьи.
> Если в нем будет, например, round box как стандартное средство, то на современной карте их можно будет рисовать 900 тысяч штук в секунду, наверное (примерно).
А причём тут CSS, цсс — это набор стандартов, которые реализуются браузером. В первую очередь нужно ругать браузеры за «медленную», по вашим словам, отрисовку.
> Представьте себе, что верстку газет и журналов приходилось бы делать через написание скриптов на JS под каждый номер заново.
Вам уже отвечали, что в газетах и журналах блоки имеют фиксированный размер и фактически абсолютное позиционирование. А если вы видели, что в газетах, где-то динамически переключаются страницы или блоки меняют свою ширину, отсыпьте грибов.
И что из этого всего вы предлагаете, кроме нытья, ничего.
А теперь перейдём к реалиям. Удаляем хтмл и цсс, тратим 5 лет на создание нового layout'a, превращаем веб в ос/2. Дальше если сил хватит, делаем софт — рендер всего этого, если нет — описываем спецификацию. Через 2 года выходит софт, ещё через 2 его портируют под линукс и мак ос, ещё через 2 кое как появляется мобильные версии. Дело подхватывает другая компания и выпускает свой софт. Но не поддерживает спецификации полностью, а в некоторых моментах реализует по своему, как ей виднее. Но этой компании удаётся удачно продвинуть свой продукт. Появляется третяя и четвёртая, начинает наследовать наработки второй, чтобы быть в теме, и реализовует свои фичи, которые требует рынок нынче. Тем временем, первую компанию начинает лихорадить и внутри, одна половина команды за то чтобы разрабатывать новый стандарт, другая за то чтобы просто ввести фичи, которые понаделали производители софта. Компания принимает решение, что создавать новый стандарт каждые 10 лет не выгодно, так как только на внедрение нужно 10 лет и начинает плясать относительно наработок других компаний.
> Если в нем будет, например, round box как стандартное средство, то на современной карте их можно будет рисовать 900 тысяч штук в секунду, наверное (примерно).
А причём тут CSS, цсс — это набор стандартов, которые реализуются браузером. В первую очередь нужно ругать браузеры за «медленную», по вашим словам, отрисовку.
> Представьте себе, что верстку газет и журналов приходилось бы делать через написание скриптов на JS под каждый номер заново.
Вам уже отвечали, что в газетах и журналах блоки имеют фиксированный размер и фактически абсолютное позиционирование. А если вы видели, что в газетах, где-то динамически переключаются страницы или блоки меняют свою ширину, отсыпьте грибов.
И что из этого всего вы предлагаете, кроме нытья, ничего.
А теперь перейдём к реалиям. Удаляем хтмл и цсс, тратим 5 лет на создание нового layout'a, превращаем веб в ос/2. Дальше если сил хватит, делаем софт — рендер всего этого, если нет — описываем спецификацию. Через 2 года выходит софт, ещё через 2 его портируют под линукс и мак ос, ещё через 2 кое как появляется мобильные версии. Дело подхватывает другая компания и выпускает свой софт. Но не поддерживает спецификации полностью, а в некоторых моментах реализует по своему, как ей виднее. Но этой компании удаётся удачно продвинуть свой продукт. Появляется третяя и четвёртая, начинает наследовать наработки второй, чтобы быть в теме, и реализовует свои фичи, которые требует рынок нынче. Тем временем, первую компанию начинает лихорадить и внутри, одна половина команды за то чтобы разрабатывать новый стандарт, другая за то чтобы просто ввести фичи, которые понаделали производители софта. Компания принимает решение, что создавать новый стандарт каждые 10 лет не выгодно, так как только на внедрение нужно 10 лет и начинает плясать относительно наработок других компаний.
Можно сделать небольшое изменение в вашем сценарии — написать один рендерер, сделать его кроссплатформенным и распространять по свободной лицензии. Тогда один и тот же рендерер сможет использоваться в разных продуктах — примерно как WebKit используется в Safari и Chrome.
Да можно и не начинать с чистого листа, а взять тот-же WebKit за основу.
В идеале да. Я тоже приверженец идеи, что такую штуку должна разрабатывать одна группа людей. Но тогда браузерам фактически не чем будет конкурировать, они не позволят такой стандартизации, что очень печально. А если делать общий комитет, то один уже есть — w3c, перетягивания одеяла.
Этот вопрос можно решить и иначе — нужно так ясно описать правила обсчета layout, что разная имплементация в разных браузерах станет невозможной без грубого нарушения стандарта. Я считаю, что базовый язык описания разметки должен быть абсолютно детерминистичным и гарантировать bit exact воспроизводилось картинки на любом устройстве — естественно при использовании одного и того же шрифта и при одинаковых размерах окна. Такой детерминизм нужен для того, чтобы разработчикам сайта не приходилось вообще задаваться мыслью «а как это будет показано у клиента?». У клиента всегда будет показано точно так же, как у них самих. Браузеры должны конкурировать между собой соревнуясь в скорости отрисовки, закачки и наборе своих собственных встроенных фич. А не в том, как именно они рисуют страницу.
Ладно, обойду с другой стороны.
Невозможно написать идеальный стандарт с первого раза, кто бы не говорил что, всегда будут баги. Всегда с появлением новых требований рынка, стандарт нужно будет улучшать.
Итак, режиссёр у нас монополист, который разрабатывает ядро для этого языка. Вчера он выпустил версию 1, а завтра версию 2. Разработчики браузеров выпустили свой продукт сегодня с версией 1, другие подождали до завтра и с версией 2. Уже видно, что сайты написанные исходя с версией 2 не будут точно работать с браузерами на версии 1.
Ок, делаем в ядре возможность авто обновления вне зависимости от браузера. Не будем оговоривать, какие баги это может вызвать в браузере, который пилил свой функционал под определённые версии ядра. Ввести принудительное обновление мы не сможем, так как такой браузер с большой вероятность запретят в ЕС. Нужно делать уведомления о том, что ядро обновится. После чего найдутся какие-то проценты людей, которые будут говорить, что стандарт 1 был быстрее и стабильнее, и не станут дальше получать обновления ядра. Пример с фф 3.6 например.
Невозможно написать идеальный стандарт с первого раза, кто бы не говорил что, всегда будут баги. Всегда с появлением новых требований рынка, стандарт нужно будет улучшать.
Итак, режиссёр у нас монополист, который разрабатывает ядро для этого языка. Вчера он выпустил версию 1, а завтра версию 2. Разработчики браузеров выпустили свой продукт сегодня с версией 1, другие подождали до завтра и с версией 2. Уже видно, что сайты написанные исходя с версией 2 не будут точно работать с браузерами на версии 1.
Ок, делаем в ядре возможность авто обновления вне зависимости от браузера. Не будем оговоривать, какие баги это может вызвать в браузере, который пилил свой функционал под определённые версии ядра. Ввести принудительное обновление мы не сможем, так как такой браузер с большой вероятность запретят в ЕС. Нужно делать уведомления о том, что ядро обновится. После чего найдутся какие-то проценты людей, которые будут говорить, что стандарт 1 был быстрее и стабильнее, и не станут дальше получать обновления ядра. Пример с фф 3.6 например.
Вам уже отвечали, что в газетах и журналах блоки имеют фиксированный размер и фактически абсолютное позиционирование. А если вы видели, что в газетах, где-то динамически переключаются страницы или блоки меняют свою ширину, отсыпьте грибов.
Так ведь в газетах блоки не вручную расставляют, делает это программа. Да, эта программа обрабатывает все блоки за раз, и скорее всего не способна перестраивать лэйаут инкрементально при изменениях контента. IMHO это непринципиальное различие.
Кроме того, не знаю как верстаются газеты, а при верстке книг обычно на финальном этапе происходит тонкая настройка макета. Например оптимизируется взаимное расположение блоков с графикой, и связанного по смыслу текста. Разумеется такие оптимизации возможны только если размер страницы фиксирован. Все эти тонкие настройки невозможны при «резиновой» верстке.
В порядке бреда: А если сделать расширяемый язык разметки, базовые конструкции (препроцессор) которого бы описывали синтаксис, семантику и визуализацию (пожалуй даже сенсоризацию или как ещё назвать, в общем не только для глаз, но и для других органов чувств) произвольных конструкций (новых тегов) единым формальным способом во внешних документах. Продвинутые браузеры предоставляли бы нативную реализацию популярных производных тегов (типа виртуальной машины), устаревшие бы работали в режиме непосредственной интерпретации. Всё везде бы показывалось и т. п. одинаково только с разной скоростью.
В общем что-то вроде XML, но описывающее не только синтаксис, но и семантику и базовую визуализацию. Разработчики документов (верстальщики) расширяли бы язык под свои требования в процессе вёрстки (конечно, используя сторонние наработки), разработчики браузеров наиболее популярные (для начала, скажем, тот же HTML5+CSS3) бы реализовывали нативно, а остальные интерпретировались бы на лету или в режиме JIT. Кроме нескольких базовых элементов языка (вернее даже метаязыка) всё остальное бы содержалось в документе (плюс ссылки из него).
В общем что-то вроде XML, но описывающее не только синтаксис, но и семантику и базовую визуализацию. Разработчики документов (верстальщики) расширяли бы язык под свои требования в процессе вёрстки (конечно, используя сторонние наработки), разработчики браузеров наиболее популярные (для начала, скажем, тот же HTML5+CSS3) бы реализовывали нативно, а остальные интерпретировались бы на лету или в режиме JIT. Кроме нескольких базовых элементов языка (вернее даже метаязыка) всё остальное бы содержалось в документе (плюс ссылки из него).
в html все есть.
Плагины глючат — поиск безглючного перед покупкой уже сам по себе работа, :) они нередко негативно интерферируют друг с другом или требуют изменений в разметке под них в коде документа. Когда плагинов много их загрузка или даже пустые запросы для валидации кэша (через ETag и If-Modified-Since) вносят большую latency, из-за которой страницы сайта грузятся медленно (даже если все они лежат на сервере в кэше в памяти). Все это делает интерфейс тормозным, с большой latency. Посмотрите на страницу какого-нибудь обычного сайта, сделанного на CMS типа Joomla или Drupal. Если сайт не совсем простенький – на нем как раз-таки поставлена куча платных плагинов. Они подключают десятки разных фреймворков и темплейтов. В результате страница тянет десятки файлов с сервера каждый из которых нужно каждый раз заново валидировать, так как на сайте могла поменяться версия плагина или CMS.
Есть понятие формата, которое вы себе, судя по уже второму посту, плохо представляете. Нужно думать не о переносе конкретной реализации блокнотика из операционной системы в веб, а о решении той же задачи, которую решал блокнотик.
Очевидно, этот блокнотик был придуман, чтобы разместить в одном окне ограниченного размера как можно больше элементов управления. Даже если оставить в стороне уродливость внешнего вида, такое решение с вкладками не является очень хорошим примером интерфейса, так как пользователь не знает (или не помнит, ведь окном настройки не пользуются постоянно) плотность заполнения каждой вкладки и не имеет представления о том, сколько еще параметров можно изменить.
Проблема нехватки места в вебе прекрасно решается прокруткой. Поэтому, чтобы решить ту же задачу, нужно поместить друг под другом содержимое каждой вкладки, используя крупные заголовки. У такого метода целая куча плюсов. К прокрутке привыкли все. На больших экранах пользователь увидит сразу всю форму. Таким образом, на HTML/CSS блокнотика нет, но задача, которую он выполнял, решается.
При проектировании интерфейсов не нужно забывать о формате.
Очевидно, этот блокнотик был придуман, чтобы разместить в одном окне ограниченного размера как можно больше элементов управления. Даже если оставить в стороне уродливость внешнего вида, такое решение с вкладками не является очень хорошим примером интерфейса, так как пользователь не знает (или не помнит, ведь окном настройки не пользуются постоянно) плотность заполнения каждой вкладки и не имеет представления о том, сколько еще параметров можно изменить.
Проблема нехватки места в вебе прекрасно решается прокруткой. Поэтому, чтобы решить ту же задачу, нужно поместить друг под другом содержимое каждой вкладки, используя крупные заголовки. У такого метода целая куча плюсов. К прокрутке привыкли все. На больших экранах пользователь увидит сразу всю форму. Таким образом, на HTML/CSS блокнотика нет, но задача, которую он выполнял, решается.
При проектировании интерфейсов не нужно забывать о формате.
Критикуя — предлагай! (с)
Объясните несведущему, помню еще 5 лет назад громко трубили о приходе векторной графики в веб в лице svg, уже вроде бы и все браузеры поддерживают его нативно, так почему же воз и ныне там? Альтернатива от МС в лице silverlight/wpf реально очень удобны.
Главное содержимое и его семантика, а не дырки в звездах.
> Web-программист высшей квалификации, если ему поручить сделать это без готовых toolkit-ов и не передирая из них чужой код, потратит пару дней на то, чтобы БЕЗГЛЮЧНО запрограммировать рисование квадрата с закругленными углами в актуальных версиях браузеров, оставив IE 6 за скобкой.
> Ему придется использовать для этого HTML, CSS, JavaScript, заготовить вспомогательные PNG-файлы и может быть даже VML/SVG, если нужно в полной мере поддержать гибкость задания параметров.
Серьезно? Для того чтобы только нарисовать квадрат с закругленными углами, вашему «Web-программисту высшей квалификации» нужно все это?
> Ему придется использовать для этого HTML, CSS, JavaScript, заготовить вспомогательные PNG-файлы и может быть даже VML/SVG, если нужно в полной мере поддержать гибкость задания параметров.
Серьезно? Для того чтобы только нарисовать квадрат с закругленными углами, вашему «Web-программисту высшей квалификации» нужно все это?
Эмм… Как сделать скруглённые углы для IE7/8 без использования сторонних библиотек?
А даже если с ними, то они как раз и используют html, css, javascript, vml или png.
А даже если с ними, то они как раз и используют html, css, javascript, vml или png.
Давайте абстрагируемся от старых браузеров и будем рассматривать то, что есть сейчас. Ведь если и выйдет новый язык разметки, он не сразу обзаведётся поддержкой всех и вся и не займёт 100% рынка за один уикенд.
> Эмм… Как сделать скруглённые углы для IE7/8 без использования сторонних библиотек?
Картинками. Так даже и в IE6 и прочем аналогичном будет работать. А иначе (и чтобы на всяком древнем г. работало) — никак.
Но даже и тут работы никак не на «пару дней для Web-программиста высшей квалификации».
Картинками. Так даже и в IE6 и прочем аналогичном будет работать. А иначе (и чтобы на всяком древнем г. работало) — никак.
Но даже и тут работы никак не на «пару дней для Web-программиста высшей квалификации».
Правильно, картинками придётся городить огород, теряя при этом семантику, простоту и удобство поддержки. При этом, если потребуется изменить углы, или декор, придётся переделывать кучу картинок, ну и так далее. А если углов много и они разные — то проще воспользоваться неким более универсальным решением, как раз из области vml и прочих извращений.
А если огорода с картинками не городить — то придётся использовать либо сторонние библиотеки (которые его построят за вас). либо подобное решение написать самому. Что реально может занять много времени.
Но в целом согласен, автор немного сгущает краски. Но в плане отсутствия нормальных инструментов построения интерфейсов в вебе он полностью прав.
А если огорода с картинками не городить — то придётся использовать либо сторонние библиотеки (которые его построят за вас). либо подобное решение написать самому. Что реально может занять много времени.
Но в целом согласен, автор немного сгущает краски. Но в плане отсутствия нормальных инструментов построения интерфейсов в вебе он полностью прав.
Все дело в том, что огород придется городить, если задаться целью сделать интерфейс, одинаковый как для современных браузеров, и для браузеров 10-ти летней давности. Если же строить интерфейс со всеми красивостями только для относительно современных браузеров, учитывая их возможности — то и проблем то особых нет.
Пример UI 20-летней давности, который я предлагаю сначала воспроизвести всем апологетам HTML и CSS на этих языках, прежде чем минусовать «карму»:Пример резидентного вируса 30-летней давности, который я предлагаю сначала воспроизвести всем аплогетам TeX и LaTeX на этих языках, прежде чем минусовать «карму»…
Короче, бред это всё. Или я не понял чего? Что вы опять к этой OS/2 привязались. HTML при разных там своих возможных недостатках был задуман и является средством РАЗМЕТКИ, по определению, а не средством построения GUI. Реально разницы не видите никакой? Поэтому вообще странный цикл заметок.
Вот именно. Современный веб требует средств построения GUI, а не разметки текста. Веб — это уже давно не набор слинкованных страничек.
Всё верно, так я с этим и не спорю. Я о том, что инструменту предъявляются нехарактерные претензии. Но при этом текст, слинкованные страницы и прочее вроде как тоже нужны, на что удобное средство для их реализации предлагается заменить?
Предлагается оставить инструмент разметки текста для текста, а все элементы управления делать на чём-то более адекватном этой задачи. Сейчас этот инструмент используется для всего подряд.
Мне кажется, что все же есть разница между web-интерфейсом и какой-нибудь типовой текстовой страницей. И если первое подразумевает некоторую сложность верстки (закладки, слайдеры, диалоговые окна, тултипы и т.д. ), то типовая страница создается на HTML + CSS на раз-два, собственно, для чего и был создан HTML, не?
Так как стандартов на современные интерфейсы нет, то и жаловаться не на что.
Кстати, инетересно, было бы попробоватьна UI двадцатилетней давности сверстать сайт, наверняка задача не из простых.
Так как стандартов на современные интерфейсы нет, то и жаловаться не на что.
Кстати, инетересно, было бы попробоватьна UI двадцатилетней давности сверстать сайт, наверняка задача не из простых.
> Так как стандартов на современные интерфейсы нет, то и жаловаться не на что.
Отличная цитата. Если бы в вебе был стандарт оформления как в системе, тогда можно было бы писать средства для написания GUI, которые следовали бы чётко описано дизайну форм и контролов. Но тогда какой бы это уже был веб? Копнём глубже, и посмотрим с другой стороны.
Появился набор семантических котролов: табы, модальные окна и тп. Они умеют вид такой, какой пропсиан в некой спецификации «дизайна контролов». Так как веб не ограничен один оформлением, мы будем иметь следующую картину. Дизайнер взял, да и добавил картинку на табу, интересно как программист будет реализовывать эту картинку используя стандартные контролы? Нам уже и так хватает опыта, что нельзя полностью кастамизировать select, input type=«file» вообще приходится скрывать и делать сверху фейковую кнопку, и таких контролов достаточно много.
Выходит заранее прописанные в спецификации контролы не выход. И программист потратит больше времени на осознание того, что стандартными средставми это не сделать, чем если бы он взялся сразу писать нужный контрол сам под текущую задачу.
ПС. Чтобы написать кастомный select, понадобится порядка 30 минут времени. Которой при случае сможет работать и без жс, отображая просто стандартный контрол.
Отличная цитата. Если бы в вебе был стандарт оформления как в системе, тогда можно было бы писать средства для написания GUI, которые следовали бы чётко описано дизайну форм и контролов. Но тогда какой бы это уже был веб? Копнём глубже, и посмотрим с другой стороны.
Появился набор семантических котролов: табы, модальные окна и тп. Они умеют вид такой, какой пропсиан в некой спецификации «дизайна контролов». Так как веб не ограничен один оформлением, мы будем иметь следующую картину. Дизайнер взял, да и добавил картинку на табу, интересно как программист будет реализовывать эту картинку используя стандартные контролы? Нам уже и так хватает опыта, что нельзя полностью кастамизировать select, input type=«file» вообще приходится скрывать и делать сверху фейковую кнопку, и таких контролов достаточно много.
Выходит заранее прописанные в спецификации контролы не выход. И программист потратит больше времени на осознание того, что стандартными средставми это не сделать, чем если бы он взялся сразу писать нужный контрол сам под текущую задачу.
ПС. Чтобы написать кастомный select, понадобится порядка 30 минут времени. Которой при случае сможет работать и без жс, отображая просто стандартный контрол.
Нам уже и так хватает опыта, что нельзя полностью кастамизировать select, input type=«file» вообще приходится скрывать и делать сверху фейковую кнопку, и таких контролов достаточно много.
Так input-type-file это вобще тема для отдельного разговора. Он и должен выглядеть определенным способом, поскольку предназначен для совершения привилегированных действий. Фактически мы разрешаем интернету вылезти из песочницы и забрать файл с жесткого диска. Это как окно ввода пароля для совершения административных действий.
Скажи это дизайнерам. Есть понятие дизайн и оформление сайта. Везде на сайте будут красивые кнопочки, и тут вдруг хардкорный инпут со стандартной кнопкой. Не считаете это убогим? Самым глупым было сделать этот контрол одним целым. Куда бы удобнее было где-то так:
Или же сделать кнопку главной, а инпут не обязательным вспомогательным элементом.
А чтоб сейчас стилизировать этот контрол нужно делать что-то вроде этого:
<input type="file" name="add-file">
<input type="button" for="add-file">
Или же сделать кнопку главной, а инпут не обязательным вспомогательным элементом.
<input type="text" for="add-file">
<input type="browse" name="add-file">
А чтоб сейчас стилизировать этот контрол нужно делать что-то вроде этого:
.browse-button {
float: left;
position: relative;
overflow: hidden;
cursor: pointer;
}
.browse-button input[type="button"] {
cursor: pointer;
}
.browse-button input[type="file"] {
width: 150px;
position: absolute;
top: 0;
right: 0;
opacity: 0;
//filter:progid:DXImageTransform.Microsoft.Alpha(opacity=0);
cursor: pointer;
}
<div class="browse-button">
<input type="button" value="Browse" />
<input type="file" size="20" />
</div>
А упомянутая Вами компания Adobe разве не для этого Flash создала? Для RIA- предложили Flex где весь код приложения это XML+AS компилируется в swf и используется на любой платформе (а для тех кто любит standalone- приготовили Adobe AIR), правда работает не во всех браузерах, но тем не менее.
Учитесь выбирать конкретный инструмент под конкретную задачу.
Пока я занимался разработкой standalone-приложений, время, затраченное на реализацию интерфейса составляло около 10-15% от общего времени разработки. Но после перехода в сторону web заметил, что реализация и отладка нормальных интерфейсов занимает гораздо больше времени, а эпичные грабли могут вылезти там, где их совершенно не ждешь. В Standalone граблей хватало при разработке бизнес-логики, но с интерфейсом проблем не было никогда. Многие на первый взгляд простые вещи (например, двухуровневая статистика по клику на точку графика \ сектор диаграммы) в html+css+js превращаются в настоящий ад.
Отсюда возникает проблема неопределенности сроков, а это уже серьёзно.
Поэтому можно с уверенностью сказать, что разработка для web более трудозатратна, чем разработка standalone-приложения со схожим техзаданием. С другой стороны, в долгосрочной перспективе такое приложение гораздо проще поддерживать, распространять и обновлять.
Отсюда возникает проблема неопределенности сроков, а это уже серьёзно.
Поэтому можно с уверенностью сказать, что разработка для web более трудозатратна, чем разработка standalone-приложения со схожим техзаданием. С другой стороны, в долгосрочной перспективе такое приложение гораздо проще поддерживать, распространять и обновлять.
Просто в вебе идёт разделение на верстальщика и программиста. Хороший программист по факту не очень хороший верстальщик. А проблемы с неопределенностью сроков отпадают при появлении опыта, как и в любом другом деле.
Это разделение в web весьма условно. К примеру я интерфейсы web-приложения делаю сам, в то время как порезать макет сайта — отдаю верстальщику. Просто лично мне не интересно верстать сайт, это больше машинальная работа.
Точно так же как в OS/2 эти формочки скорее всего не программисты рисовали, а проектировщики интерфейсов.
Точно так же как в OS/2 эти формочки скорее всего не программисты рисовали, а проектировщики интерфейсов.
мне кажется, что это искусственные трудности. Есть такая концепция — RAD, быстрая разработка приложений. И пока я работал в рамках этой концепции, мне было не влом раскидать по форме кнопочки, чтобы оно просто работало.
В сухом остатке для описания формы мне нужно было покликать мышкой и написать обработчики на том же языке программирования. В случае с web только для интерфейса мне приходится пользоваться как минимум двумя языками (html+css, javascript), которые к тому же очень по-разному интерпретируются на клиентских машинах. А не дай б-г придётся делать печатные формы — это вообще будет триллер.
В сухом остатке для создания мало-мальски рабочего интерфейса необходимо знать javascript, HTML, CSS, а также особенности работы двух последних на добром десятке различных платформ. Беда лишь в том, что всё это, как правило, не имеет ни малейшего отношения к ТЗ.
В сухом остатке для описания формы мне нужно было покликать мышкой и написать обработчики на том же языке программирования. В случае с web только для интерфейса мне приходится пользоваться как минимум двумя языками (html+css, javascript), которые к тому же очень по-разному интерпретируются на клиентских машинах. А не дай б-г придётся делать печатные формы — это вообще будет триллер.
В сухом остатке для создания мало-мальски рабочего интерфейса необходимо знать javascript, HTML, CSS, а также особенности работы двух последних на добром десятке различных платформ. Беда лишь в том, что всё это, как правило, не имеет ни малейшего отношения к ТЗ.
Когда я занимался разработкой standalone-приложений, время, затраченное на реализацию интерфейса составляло 80% общего рабочего времени. Мало-мальски нестандартные фичи компонентов, типа анимации прокрутки таблицы, или нестандартного скроллбара с превью прямо в полосе, оказывались адски сложными задачами, которые проще решать с нуля.
С переходом на веб все эти вещи перестали быть программными бутафориями, приобретя кристально ясную структуру, наглядность, возможность смены стилизации и отдельного подключения кода.
Поэтому можно с уверенностью сказать, что разработка интерфейса standalone более трудозатратна, чем разработка интерфейса web-приложения со схожим техзаданием.
С переходом на веб все эти вещи перестали быть программными бутафориями, приобретя кристально ясную структуру, наглядность, возможность смены стилизации и отдельного подключения кода.
Поэтому можно с уверенностью сказать, что разработка интерфейса standalone более трудозатратна, чем разработка интерфейса web-приложения со схожим техзаданием.
Я немного переиначу.
Разработка интерфейса standalone приложение будет быстра только в том случае, если будут использоваться только стандартные контролы и поведение ОС.
Но когда в процесс вмешивается дизайнер, а это сейчас частое явление, тогда построение интерфейса будет сводится к нагромождению хаков над этими стандартными контролами. Веб не содержит конролы, он гибкий, от этого на нём можно сделать всё.
Разработка интерфейса standalone приложение будет быстра только в том случае, если будут использоваться только стандартные контролы и поведение ОС.
Но когда в процесс вмешивается дизайнер, а это сейчас частое явление, тогда построение интерфейса будет сводится к нагромождению хаков над этими стандартными контролами. Веб не содержит конролы, он гибкий, от этого на нём можно сделать всё.
Вот проблема, пожалуй, в том, что есть много ситуаций, где «стандартных серых контролов» хватило бы — но при этом с много более сложным поведением, чем предоставляет HTML — хоть с грида того же начиная и привязок к БД. Только инструментов нет соответствующих. Образно говоря, Delphi для Web нужно.
В конце концов, тот корпоративный софт, который сейчас пишется на джаве/дотнете, а дальше неминуемо переберётся в браузеры — там же не красоты нужны, а удобный, быстро реализуемый функционал.
В конце концов, тот корпоративный софт, который сейчас пишется на джаве/дотнете, а дальше неминуемо переберётся в браузеры — там же не красоты нужны, а удобный, быстро реализуемый функционал.
Главное сразу описать, чтобы этом набор элементов следовал оформлению ос, и не как иначе. Тогда можно будет говорить клиенту, тыкая в спецификацию, что розового котёнка на квладку не поместить. А если он хочет этого котёнка, за отдельную плату делаем свой кастомный контрол.
Вы про какую ОС? Которая стоит у вас, у представителя заказчика, у их клиентов?
ОС, в которой был открыт браузер. Или вы предлагаете абстрагироваться от ОС вообще, собрать вместе группу дизайнеров со всего света, которые нарисуют эти конролы, и которые вне зависимости от ОС и браузера будут одинаковыми?
Bingo.
Вообще не плохо было бы. Тем более, что браузеры используют, похоже, свои собственные контролы. По крайней мере как-то кастомизируют стандартные (глубоких исследований не проводил, но в трёх браузерах под одной осью контролы разные).
Под линуксом в KDE давно ещё помню, что инпуты были стилизированные под тёмную тему. От сюда и пошло золотое правило задавать инпутам не только цвет шрифта, а ещё и фон.
Вот почему если уж и стоит делать стандартные контролы, то и вид они должны иметь везде одинаковый.
Вот почему если уж и стоит делать стандартные контролы, то и вид они должны иметь везде одинаковый.
> Тем более, что браузеры используют, похоже, свои собственные контролы
Не совсем так, все контролы прописаны в стандарте, и их поводение. А вот их вид — оформление нет.
Не совсем так, все контролы прописаны в стандарте, и их поводение. А вот их вид — оформление нет.
Пожалуй самый известный пример такой библиотеки, которая все контролы рисует сама, это QT. Вторая — это библиотека Swing в Java. Конечно есть много других, но менее известных.
Дополню.
В упоминаемые 90е годы рисовать приходилось массу всего, начиная от тулбаров и заканчивая своими деревьями и таблицами. Занимало это уйму времени и в силу тормознутости тогдашнего железа еще и обвешивалось кучей хаков — эти события всегда считаем, а эти слишком старые, а тут вообще рыбу заворачиваем.
А уж развлечения на тему локализации — вообще превращались в нечто из области эзотерики. «Вот этот набор контролов есть только во французской версии», ага. И при поддержке 20ти языков — число формочек достигало невероятных цифр. И это — в Delphi, тогдашнем RAD нумер один.
Это сейчас хорошо — UTF рулит, а в 90е нарисовать на формочке одновременно японский и китайский было возможно только в том случае, если мы написали свой отдельный edit box с блэкджеком, полностью саморисованный.
Сравните с нынешней ситуацией — картинки подложить в случае если клиент некрофил ;-)
В упоминаемые 90е годы рисовать приходилось массу всего, начиная от тулбаров и заканчивая своими деревьями и таблицами. Занимало это уйму времени и в силу тормознутости тогдашнего железа еще и обвешивалось кучей хаков — эти события всегда считаем, а эти слишком старые, а тут вообще рыбу заворачиваем.
А уж развлечения на тему локализации — вообще превращались в нечто из области эзотерики. «Вот этот набор контролов есть только во французской версии», ага. И при поддержке 20ти языков — число формочек достигало невероятных цифр. И это — в Delphi, тогдашнем RAD нумер один.
Это сейчас хорошо — UTF рулит, а в 90е нарисовать на формочке одновременно японский и китайский было возможно только в том случае, если мы написали свой отдельный edit box с блэкджеком, полностью саморисованный.
Сравните с нынешней ситуацией — картинки подложить в случае если клиент некрофил ;-)
Мне кажется нельзя сравнивать создание интерфейса на OS/2 и HTML+CSS. Ваше OS/2 API привязанно к платформе. Естественно оно будет быстро и безглючно отрисовываться. На HTML можно реализовать интерфейс, который будет корректно отображаться в любом браузере, на любой операционной системе(в том числе и на мобильных устройствах).
Скорость разработки интерфейса естественно выше для OS/2, это API предназначена(сужу по вашим словам) специально для GUI. HTML же изначально был сделан не совсем для этого(конечно я могу ошибаться в исторических реалиях).
По поводу скорости, не забывайте, что программа в OS/2 сама ответственна за свой интерфейс, да и вообще работоспособность, вы именно программируете интерфейс. А HTML+CSS+и т.д. предназначены для обработки браузером, таким образом вы не напрямую передаете на дисплей линии, а через еще одного человека(IE, Firefox, Chrome и прочие), а вот как быстро он передаст — вопрос к нему. HTML не язык программирования, это средство описания.
Не забывайте, что в Web есть устоявшиеся технологии и стандарты. Даже если вам или кому либо еще удастся разработать новый язык разметки врят ли он сумеет продвинуть его в массы. А даже если сумеет, как выше правильно сказали, ему придется ждать смерти старых браузеров. Да и кто сказал, что его творение через 5 лет не будет тормозить так же?
Кстати о скорости отрисовки, поправьте меня, но такого рода проблемы могут быть ведь только при медленном интернете и кучи картинок или при очень тормознутой(загруженной) машине.
P.S. А вообще пытайтесь, ябоюсь не люблю верстать, но после 1-2 сайтов уже приходит понимание процесса.
Скорость разработки интерфейса естественно выше для OS/2, это API предназначена(сужу по вашим словам) специально для GUI. HTML же изначально был сделан не совсем для этого(конечно я могу ошибаться в исторических реалиях).
По поводу скорости, не забывайте, что программа в OS/2 сама ответственна за свой интерфейс, да и вообще работоспособность, вы именно программируете интерфейс. А HTML+CSS+и т.д. предназначены для обработки браузером, таким образом вы не напрямую передаете на дисплей линии, а через еще одного человека(IE, Firefox, Chrome и прочие), а вот как быстро он передаст — вопрос к нему. HTML не язык программирования, это средство описания.
Не забывайте, что в Web есть устоявшиеся технологии и стандарты. Даже если вам или кому либо еще удастся разработать новый язык разметки врят ли он сумеет продвинуть его в массы. А даже если сумеет, как выше правильно сказали, ему придется ждать смерти старых браузеров. Да и кто сказал, что его творение через 5 лет не будет тормозить так же?
Кстати о скорости отрисовки, поправьте меня, но такого рода проблемы могут быть ведь только при медленном интернете и кучи картинок или при очень тормознутой(загруженной) машине.
P.S. А вообще пытайтесь, я
Мне кажется, что вы не совсем понимаете автора. Он лишь утверждает что часто (и со временем все чаще) требуется сделать сайт (web-приложение) со сложным GUI, а HTML+JS+CSS для этого подходят плохо. Да, «HTML не язык программирования, это средство описания.». Замена требуется для создания GUI, а простые странички личного блога Васи можно делать все тем же HTML, он для этого и создавался.
Понял, но напомните пожалуйста, чем ему не подходит, например extjs? В примерах есть подобные формы, как он показал(картинка из OS/2): http://www.sencha.com/products/extjs/examples/
Кстати да, хороший пример. На этом конструкторе просто и быстро построить веб приложение.
На сколько ч понимаю скорость работы такого пиложегия булдет оставлять желать лучьшего, особенно на мобильных платформах.
Для начало нужно задаться вопросом «удобно ли будет на мобильной ос таким приложением пользоваться». Откройте любое мобильное приложение и сравните его с десктопным хотя бы, разница ощутимая.
Производительность вполне на уровне, но переносить подобные интерфейсы в мобильный мир — глупо. У той же сенчи для этого есть другой продукт, с более «родными» элементами управления.
OS/2 на мобильных платформах? Не, не слышал.
Посмотрел на код простейших табов dev.sencha.com/deploy/ext-4.1.0-gpl/examples/tabs/tabs.html. Мнений, конечно, может быть много разных, но по моему никак простой эту смесь HTML+CSS+JS(+ExtJS) не назовёшь. Использовать подобные решения, конечно, проще чем писать их с нуля, но хуже чем если бы был специализированный язык проектирования интерфейсов (или поддержка подобных возможностей средствами HTML).
Действительно очень плохой пример и далеко не семантичен.
Вы просто прикиньте реализацию диалога настройки ОS/2 на С (даже не на С++), фото которого приведено в статье, и расслабьтесь. После этого extjs вам покажется праздником…
Согласен с утверждением «HTML для GUI подходит плохо!» первой и второй статей. Но сейчас тут опять будет простыня комментариев «не трожжж HTML, все хорошо» и «HTML какафка, закапываем». Проблему вы обозначили, а ничего не предложили, и все на протяжении двух статей именно этого и ждут.
Конечно одному написать спецификацию долгое и сложное занятие, но, хотя бы, опишите вашу розовую мечту в общих словах. Вдруг всем понравится, весь хабр соберется и напишет спецификацию, а там и первую реализацию.
Вот, например, в Enlightenment (И когда они WM допилят? E16 был очень клевой штукой.) есть библиотека Edje,
Вот это похоже на вашу розовую мечту? Может быть ее надо в браузер впилить и будет счастье?
Ждем описания чего вы хотите в более подробном виде, а не просто «звезды с дырками».
Конечно одному написать спецификацию долгое и сложное занятие, но, хотя бы, опишите вашу розовую мечту в общих словах. Вдруг всем понравится, весь хабр соберется и напишет спецификацию, а там и первую реализацию.
Вот, например, в Enlightenment (И когда они WM допилят? E16 был очень клевой штукой.) есть библиотека Edje,
библиотека, отделяющая внешний вид от кода (оформление задаётся в виде загружаемого из файла шаблона). По своей сути Edje занимает нишу где-то между HTML+CSS и Flash/PSD/SVG. При помощи данной библиотеки можно сформировать насыщенный пользовательский интерфейс, снабжённый анимированными визуальными эффектами и поддерживающий динамическое оформление (внешний вид можно полностью поменять просто сменив EDJ-шаблон и не трогая код, при этом, в отличие от визуальных тем, порядок расположения элементов может быть произвольно изменён).
Вот это похоже на вашу розовую мечту? Может быть ее надо в браузер впилить и будет счастье?
Ждем описания чего вы хотите в более подробном виде, а не просто «звезды с дырками».
Да ладно, пока гугл все устраивает. А вот когда перестанет устаивать (когда хром будет доминировать среди браузеров), они быстренько придумают более продвинутый язык разметки, и так же быстренько напишут спецификации. Ну а фф и остальным придется в ускоренном темпе это все реализовывать. И ни у кого не возникнет вопроса «а с чего это мы должны реализовывать фишки, придуманные гуглом?», им _придется_ это сделать, если они не хотят потерять свои доли на рынке браузеров.
Если HTML = разметка, то для построения UI нужен другой язык. Тогда браузер превращается из приложения в конструктор приложений.
Выглядеть это может так. Заходим неким гипотетическим браузером FF15.UI или ChromUIm на сервер ui://mycoolapp.com/. С него грузится файл
Выглядеть это может так. Заходим неким гипотетическим браузером FF15.UI или ChromUIm на сервер ui://mycoolapp.com/. С него грузится файл
index.ui и файл index.html. В index.ui описан интерфейс приложения, все эти кнопочки, закладки и прочие свистелки-перделки. В index.html — только документ, который данное приложение должно отобразить. Внешний вид браузера меняется согласно тем настройкам, которые указаны в index.ui. Ну а что, было бы круто.
Поздравляю, вы только что изобрели XUL.
правда чтоли? и где можно посмотреть на веб-приложение, которое скачивается с сайта и использует XUL?
это был бы полный аллес капут с точки зрения безопасности и того, насколько пользовтель контролирует происходящее в его компе пока он ходят по непонятно каким сайтам.
Посмотрите, пожалуйста, в подразделе «XUL examples» в документации к Ample SDK.
Очень интересные примеры. По-моему, именно об этом и говорил топикстартер — html+css+js используются для трансляции с языка разметки интерфейса более высокого уровня.
Я думаю, что Мозилла могла бы реализовать в своём браузере нативную поддержку XUL, раз уж они его продвигают.
Я думаю, что Мозилла могла бы реализовать в своём браузере нативную поддержку XUL, раз уж они его продвигают.
Нативнее чем это уже реализовано реализовать не возможно. Потому что весь UI в их продуктах построен на XULRunner и XUL. Так что нативнее некуда.
Если вопрос с загрузке XUL файлов на HTML страницы в вебе, то из-за кроссбраузерности в этом нет смысла. Но технически препятствий к этому нет: XUL-Enhanced Web Apps.
Если вопрос с загрузке XUL файлов на HTML страницы в вебе, то из-за кроссбраузерности в этом нет смысла. Но технически препятствий к этому нет: XUL-Enhanced Web Apps.
XUL?
Меня поражает эта статья. Автор, ты хочешь палкой докторской колбасы забить гвозль и удивляешься, че так хреново получается. А я вам скажу: в жопу эту тяжелость и RICH клиенты всегда и всюду. Только вот че-то все в сторону минималзима идут. Наверное просто так. Эволюция не в ту сторону пошла :)
Так что я бы наверное придержался мнения: никуда мигрировать ПОКА ЧТО не нужно. а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.
HTML/CSS/JS выполняет свою работу. Когда перестанет справляться появится что-то более мощное, что заменит их. Да и уже сегодня есть туева куча JS фреймворков облегчающая жизнь, да и кое-что по-тяжелее (GWT, Vaadin).
Так что я бы наверное придержался мнения: никуда мигрировать ПОКА ЧТО не нужно. а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.
HTML/CSS/JS выполняет свою работу. Когда перестанет справляться появится что-то более мощное, что заменит их. Да и уже сегодня есть туева куча JS фреймворков облегчающая жизнь, да и кое-что по-тяжелее (GWT, Vaadin).
а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.
Но тогда придется поддерживать N нативных приложений. А веб-приложение одно на все платформы. Хотя с развитием управляемого кода и легкой кроссплатформенности этот разрыв будет нивелироваться.
Но тогда придется поддерживать N нативных приложений. А веб-приложение одно на все платформы. Хотя с развитием управляемого кода и легкой кроссплатформенности этот разрыв будет нивелироваться.
Web-программист высшей квалификации, если ему поручить сделать это без готовыхtoolkit-ов и не передирая из них чужой код, потратит пару дней на то, чтобы БЕЗГЛЮЧНО запрограммировать рисование квадрата с закруглёнными углами в актуальных версиях браузеров, оставив IE 6 за скобкой.
По данным caniuse.com оценка получается куда более оптимистическою: «border-radius» работает (если учесть варианты с префиксами
Так что
И это даже нельзя будет назвать программированием — это будет декларативным описанием кривизны углов, не более того.
Примечание: Web-программист высшей квалификации, который соглашается работать без использования готового чужого кода —
А не то у Вас получается фантасмагорическое мучительство этого бедняги в дýхе «Процесса» Кафки.
CSS3 PIE использует файл(ы) «.htc», так что никак не воздействует на загрузку и производительность страниц ни в одном браузере, кроме Internet Explorer.
Так вот: если стоит именно задача любой ценою достичь закругления, то пользователи, которые не способны сменить Internet Explorer на другой (более понимающий CSS3) браузер самостоятельно — или убедить в этой необходимости своего системного администратора — должны страдать от замедления.Во-первых, этого никак не выйдет избегнуть в программном отношении (цели ж достигнуть как-то надо); во-вторых, страдания имеют и воспитательный эффект в отношении пользователей.
Так вот: если стоит именно задача любой ценою достичь закругления, то пользователи, которые не способны сменить Internet Explorer на другой (более понимающий CSS3) браузер самостоятельно — или убедить в этой необходимости своего системного администратора — должны страдать от замедления.
Ну да, за исключением IE 7 и 8, которые в сумме сейчас стоят у 17% пользователей.
Чем вам не нравится ExtJS или Qooxdoo?
Не знаю как Qooxdoo, а ExtJS жутко тормозит, не говоря уже о том что пропущенная запятая в js коде автоматом ломает весь интерфейс. Для сложных админок хорошо использовать, не более того.
Скажите, а пропущенная скобка в xml разметке интерфейса к чему приводит? Используйте валидаторы, современные IDE (к примеру, webstorm, пропустить запятую в JSON`е будет почти невозможно).
И что за железо и браузер у вас, что ExtJS тормозит? Используем в достаточно комплексных приложениях, где большие и сложные гриды (с различными кастомными рендерами ячеек), сложные формы, используем активно вкладки, т.е. «копирование» десктопных UI, именно проблем с производительностью не встречали (extjs 3.x).
И что за железо и браузер у вас, что ExtJS тормозит? Используем в достаточно комплексных приложениях, где большие и сложные гриды (с различными кастомными рендерами ячеек), сложные формы, используем активно вкладки, т.е. «копирование» десктопных UI, именно проблем с производительностью не встречали (extjs 3.x).
IDE использовать не хочется (каждому свое, мне нравится Sublime Text 2), но пропущенная запятая — бог с ней, сам принцип формирования интерфейса с помощью js кажется ущербным. А по поводу железа — лично у меня на i7 и последнем хроме вообще проблем нет, но если открыть это-же приложение на нетбуке с атомом или айфоне 3GS? Я вот пробовал, результаты не порадовали.
О да! Производительность многих сайтов (Хабра, например) на хоть немного не современном железе падает существенно.
Почему вам подход ExtJS кажется ущербным, ИМХО перенос интерфейса в описательный формат JSON очень удобен, сильно ли это для вас хуже, чем XML?
Я на нетбуке пробовал, из под убунту в хромиуме, вполне рабочая система, может не летает, но лагов в UI мешающих работе или, которые были бы действительно некомфортными — не встречал (опять же, говорю про 3тий extjs, в четвертом с гридами были проблемы). Про ваше приложение сложно сказать, возможно есть какие-то излишние вложения (панель в панель), от которых можно отказаться, смотреть надо конкретный, конечно, случай.
На айфоне с extjs в принципе проблемы, также как на андроиде, к примеру, пропадут скролы в комбобоксах и гридах. Да и подобные UI не предназначены для мобильных платформ с тач-интерфейсами. Иначе мы приходим к тому, что было на винмобайлах, но там хотя бы был стилус потоньше пальца:)
Я на нетбуке пробовал, из под убунту в хромиуме, вполне рабочая система, может не летает, но лагов в UI мешающих работе или, которые были бы действительно некомфортными — не встречал (опять же, говорю про 3тий extjs, в четвертом с гридами были проблемы). Про ваше приложение сложно сказать, возможно есть какие-то излишние вложения (панель в панель), от которых можно отказаться, смотреть надо конкретный, конечно, случай.
На айфоне с extjs в принципе проблемы, также как на андроиде, к примеру, пропадут скролы в комбобоксах и гридах. Да и подобные UI не предназначены для мобильных платформ с тач-интерфейсами. Иначе мы приходим к тому, что было на винмобайлах, но там хотя бы был стилус потоньше пальца:)
Ничего против JSON самого по себе не имею. Но вот смотрите, показательный код из книги по ExtJS:
Мне кажется странным такой подход, то есть мы как-бы пытаемся избавиться от HTML+CSS (и правильно пытаемся, язык разметки текста плохо подходит для построения RIA приложений), но для стилизации все еще вынуждены использовать CSS. Где тут логика? Смешались в кучу кони, люди… По поводу производительности — только что зашел на оф. демки ExtJS 4 с Kindle Fire — мне такой юзер экспириенс не нужен. Я говорил не о том, что хочу получить мобильный UI от ExtJS, а о том, что он медленно работает.
var column = Ext.create('Ext.window.Window', {
title: 'Column Layout',
width: 400,
layout:'column',
defaults: {
height: 60,
bodyStyle: 'padding:10px'
},
items: [panel1, panel2, panel3]
});
column.show();
Мне кажется странным такой подход, то есть мы как-бы пытаемся избавиться от HTML+CSS (и правильно пытаемся, язык разметки текста плохо подходит для построения RIA приложений), но для стилизации все еще вынуждены использовать CSS. Где тут логика? Смешались в кучу кони, люди… По поводу производительности — только что зашел на оф. демки ExtJS 4 с Kindle Fire — мне такой юзер экспириенс не нужен. Я говорил не о том, что хочу получить мобильный UI от ExtJS, а о том, что он медленно работает.
Вы в веб часто работаете, я имею ввиду часто делаете сайты? Вы часто верстаете дизайн, который нарисовал дизайнер? В отличии от ОС, где оформление является стандартом для этой ОС, в вебе нет стандарта оформления. Завтра дизайнер нарисует модальное окно с 4 бордерами, что вы будете делать со своим нативным контролом?
Не совсем понимаю, каким образом отсутствие стандартов относится к странной логике ExtJS, ну да ладно. Я верстаю редко, но с html/css/js знаком далеко не первый день. Насчет отсутствия стандартов согласен, но разве это хорошо? Можно посмотреть на платформы где они есть (Mac), там плохие и некрасивые тулзы? Да даже Sparrow как пример юзерфрендли интерфейса взять, это же песня. Хотя… чем меньше стандартов и больше хаков, тем больше хлеба верстальщикам, верно?
Так, имеем дело с программером технического скалада ума. Вам я говорю не о тулзах а оформлении и о дизайне. Веб тем и отличается, что он индивидуале и разнообразен. Люди склоны к совершенствованию, люди склоны к творчеству, поиску новаторских идей. Если бы были такие жесткие правила как вы описываете, ещё бы долго у apple был интерфейс lisa. Люди хотят выделить свой сайт, придать ему фир. стиль, свой уникальный, веб полностью позволяет это делать. Это его фишка.
Знаете, я (думаю как и многие) предпочел бы, чтобы 90% сайтов были удобными и привычными в использовании, пофиг на внешний вид — контент рулит. Недаром Twitter Bootstrap и иже с ними в последнее время набрали неплохие обороты. А остальные 10% — да, промо сайты и какой-то особенный дизайн. Сейчас же интернет пестрит кастомными контролами и прочей дрянью, которая вроде как неплохо выглядит, но иногда сразу и не поймешь что это такое вообще. Вот как дизайнер травы хапнул и накидал psd, а верстальщик все это сверстал. Только вот на UX дизайнера часто денег жалеют, лучше уж тогда чтобы привычно все было :)
Можно реальную статистику. Если по вашему интернет ограничивается твиттером и соц сетями, дальше говорить не о чем с вами.
Простите, статистику конкретно о чем? Я говорил о своем личном впечатлении — интернет разобщен, нет единого стандарта по проектированию интерфейсов (и это плохо!), многие лепят дизайн поэффектней не задумываясь о юзабилити и привычках пользователя, полный разброс и шатание. Если в ваших глазах интернет выглядит иначе, я вам ничего не смогу доказать даже после 100500 сообщений. Ветка про ExtJS и RIA скатилась в полный офтопик, я закругляюсь.
Юзабилити это не только внешний вид контрола, это ещё и его размещение. Даже используя тулкит, можно расставить контролы так, что будет удобно аж никому. Пример тому скрин ос/2 автора топика.
Sencha вам предоставляет инструмент, как вы им будете пользоваться — ваше дело. Ничего страшного в CSS нет. Я понимаю, когда CSS критикуют из-за различных «хаков», чтобы сделать что-то определенного вида. Но здесь он используется совершенно логично, задает внешний вид контенту.
Ну я вам сказал, что с 4ым у них проблема с производительностью, они это особо не скрывают, более того, открыто говорят, что extjs не предназначен для мобильных платформ (я тут это 3ий раз повторяю). Это все же не фрэймворк для создания сайтов (поэтому см.выше), для мобильных приложений у них другие решения, разработчикам это надо учитывать.
Ну я вам сказал, что с 4ым у них проблема с производительностью, они это особо не скрывают, более того, открыто говорят, что extjs не предназначен для мобильных платформ (я тут это 3ий раз повторяю). Это все же не фрэймворк для создания сайтов (поэтому см.выше), для мобильных приложений у них другие решения, разработчикам это надо учитывать.
Насколько я понял эту статью, автор говорит о том, что стандартная связка html+css+js плохо подходит для создания интерфейсов сложных веб приложений (и с этим я согласен). zim32 спросил чем не устраивает ExtJS, мы выяснили, что для тюнинга внешнего вида нам все равно приходится использовать старый добрый css, то есть к RAD мы не приходим, только и всего.
Насчет четверки — если у них проблема с производительностью то это их проблема, какие варианты — использовать бесконечно легаси третью версию? Про мобильные я уже говорил — вашу мысль понял, никто не требует от ExtJS mobile UI (для этого есть Sencha Touch). Планшет был приведен как пример слабого устройства с более-менее нормальным разрешением экрана, можете его мысленно заменить на нетбук, у которого в фоне висит скайп, дропбокс, работает хром с 20 открытыми вкладками и еще где-то гимп на втором рабочем столе.
Насчет четверки — если у них проблема с производительностью то это их проблема, какие варианты — использовать бесконечно легаси третью версию? Про мобильные я уже говорил — вашу мысль понял, никто не требует от ExtJS mobile UI (для этого есть Sencha Touch). Планшет был приведен как пример слабого устройства с более-менее нормальным разрешением экрана, можете его мысленно заменить на нетбук, у которого в фоне висит скайп, дропбокс, работает хром с 20 открытыми вкладками и еще где-то гимп на втором рабочем столе.
Но здесь он используется совершенно логично, задает внешний вид контенту.
Я бы не сказал. Здесь мы с помощью JS задаём свойства CSS (наверное, так выглядит, хотя и есть странности). Куда логичнее было бы задать окну класс, который описан в CSS, или изменить стиль HTML элемента, если не представляется возможным сделать это средствами CSS напрямую.
Я бы не сказал. Здесь мы с помощью JS задаём свойства CSS (наверное, так выглядит, хотя и есть странности). Куда логичнее было бы задать окну класс, который описан в CSS, или изменить стиль HTML элемента, если не представляется возможным сделать это средствами CSS напрямую.
Нет, ну класс там в итоге тоже задается, и вообще можно сделать все что угодно, мне просто не нравится такое смешение подходов…
Как по мне было бы идеально отделить пять вещей:
— данные (собственно контент) — вполне нормально подойдёт HTML с некоторыми модификациями
— представление данных — CSS, может с некоторыми модификациями
— описание интерфейса (набора контролов, с базовыми алгоритмами) — можно что-то XML-based
— представление интерфейса, включая различные варианты раскладок контролов, включая контент как контрол — сильно модифицированный CSS, в частности адаптивный под разные устройства «лёгким движением руки»
— переопределение базовых алгоритмов интерфейса — JavaScript вполне пойдёт
— данные (собственно контент) — вполне нормально подойдёт HTML с некоторыми модификациями
— представление данных — CSS, может с некоторыми модификациями
— описание интерфейса (набора контролов, с базовыми алгоритмами) — можно что-то XML-based
— представление интерфейса, включая различные варианты раскладок контролов, включая контент как контрол — сильно модифицированный CSS, в частности адаптивный под разные устройства «лёгким движением руки»
— переопределение базовых алгоритмов интерфейса — JavaScript вполне пойдёт
> сильно модифицированный CSS, в частности адаптивный под разные устройства «лёгким движением руки»
Уже есть, на хабре где-то была статья, которая хорошо демонстрирует стандарт.
www.w3.org/TR/css3-mediaqueries/
Уже есть, на хабре где-то была статья, которая хорошо демонстрирует стандарт.
www.w3.org/TR/css3-mediaqueries/
А ещё четвёртый ExtJS здорово тормозит. А Qooxdoo ещё дальше чем Dojo от народа
Окей. Тогда давайте всё делать честно. Вы рисуете на экране этот интерфейс без тулкитов, апи, виджетов и прочего в системном приложении, а я — в браузере.
походу автор просто тролль :)
извиняюсь за прямоту.
извиняюсь за прямоту.
Забавное нынче время.
Читать данную дискусию, когда мозилла пилит «Boot To Gecko»,
когда миго переросла в Tizen c HTML.
Читать данную дискусию, когда мозилла пилит «Boot To Gecko»,
когда миго переросла в Tizen c HTML.
Ну нам же по барабану, что код получаем по сети, он не нативный, что там еще есть dom модель, мы его можем спокойно в любой момент быстро изменить, там может быть куча javascript обработчиков (все это не бинарный код, прошу заметить), UTF-8 и много много другого.
Опять негодование по поводу html/css. Вообще как и прошлом посте — не могу понять, что автор вообще хочет донести. Сравнивать интерфейс операционной системы и html/css, ну ладно, у каждого свои тараканы в голове. Но вот надо было еще сравнить производительность видеокарты Tseng Labs ET4000 и Web-программиста высшей квалификации, причем оценка видеокарты в секундах, а труженика web`a «потратит пару дней на то».
Что связка HTML+CSS+JS плохо подходит для разработки интерфейсов, а приемлемой альтернативы (для веба и/или кроссплатформенной) нет. Не смотря на то, что грань между интерфейсом (пользовательским) операционной системой, вернее приложений для неё, и веб-приложений для многих пользователей уже исчезла. Запускают одно единственное приложение — браузер — и работают в нём. Но вот для разработчиков, как кажется автору, проще разработать UI для конкретной ОС (или даже кроссплатформенной), чем реализовывать его посредством HTML сотоварищи.
Это очень плохой интерфейс в плане современного UI.
Левое меню не выровненное и от того плохо читается.
Содержимое inputs тоже не выравнены с labels.
Кнопки листания очень маленькие, да и не нужны.
Впрочем фиг с ним, это я просто опровергаю ваш не понятно на чем обоснованный тезис: «какой крааасивый интерфейс».
web-программист высшей квалификации не будет этого делать. Пусть не тратит себя на подобное, а занимается чем-то серьезным, например, проектирует высоконагрузочную архитектуру. Этим займется верстальщик, обычный (хотя и выше среднефрилансерского уровня). Пол-дня ему на это.
HTML никогда и не был предназначен для рисования. Даже сейчас это всего лишь баловство и проба сил, практики, вроде меня, смотрят, поощряют, и ждут к чему хорошему это может привести.
==
Я не понимаю почему вы упорно игнорируете основные отличия HTML от всего того о чем вы мечтаете. Вам ведь даже не раз уже объясняли.
Первое. HTML это поток, в котором многие вещи генерируются динамически, речь даже не идет о Ajax на фронте. Нормальный верстальщик предусматривает всякие «а что если, слева будет много-много элементов меню», «а если тут будет много текста», «а если сюда мы картинку вставим», «а если вот этого вот, того что сверху, не будет, что тогда с пустым местом». И потом программисты не отвлекаясь на оформление (html — это оформление, с их точки зрения) делаю свою работу и не парят себе мозг, переделывая каждый раз интерфейс. Я многие вещи, даже в Photoshop не рисую, просто потому что в HTML быстрее. Мне не надо двигать кучу блоков по линеечке, я просто меняю 10px на 13px и смотрю как дизайнер помирает от зависти.
Второе. Я могу не парясь создать интерфейс под все актуальные браузеры, и даже не зная о существовании какого-нить Maxton, в нем все равно будет большая часть работать, а скорее всего все будет работать. А теперь, ВНИМАНИЕ, покажите мне человека, способ, или какую-нибудь гравицапу, которая сделает мне интерфейс под все OS или скажем под все мобильные платформы.
Левое меню не выровненное и от того плохо читается.
Содержимое inputs тоже не выравнены с labels.
Кнопки листания очень маленькие, да и не нужны.
Впрочем фиг с ним, это я просто опровергаю ваш не понятно на чем обоснованный тезис: «какой крааасивый интерфейс».
Web-программист высшей квалификации, если ему поручить сделать это без готовых toolkit-ов и не передирая из них чужой код, потратит пару дней на то, чтобы БЕЗГЛЮЧНО запрограммировать рисование квадрата с закругленными углами в актуальных версиях браузеров, оставив IE 6 за скобкой.
web-программист высшей квалификации не будет этого делать. Пусть не тратит себя на подобное, а занимается чем-то серьезным, например, проектирует высоконагрузочную архитектуру. Этим займется верстальщик, обычный (хотя и выше среднефрилансерского уровня). Пол-дня ему на это.
Ему придется использовать для этого HTML, CSS, JavaScript, заготовить вспомогательные PNG-файлы и может быть даже VML/SVG, если нужно в полной мере поддержать гибкость задания параметров. При этом ни о каком отсечении по эллипсу со звездообразной дыркой внутри не может быть и речи… :)
HTML никогда и не был предназначен для рисования. Даже сейчас это всего лишь баловство и проба сил, практики, вроде меня, смотрят, поощряют, и ждут к чему хорошему это может привести.
==
Я не понимаю почему вы упорно игнорируете основные отличия HTML от всего того о чем вы мечтаете. Вам ведь даже не раз уже объясняли.
Первое. HTML это поток, в котором многие вещи генерируются динамически, речь даже не идет о Ajax на фронте. Нормальный верстальщик предусматривает всякие «а что если, слева будет много-много элементов меню», «а если тут будет много текста», «а если сюда мы картинку вставим», «а если вот этого вот, того что сверху, не будет, что тогда с пустым местом». И потом программисты не отвлекаясь на оформление (html — это оформление, с их точки зрения) делаю свою работу и не парят себе мозг, переделывая каждый раз интерфейс. Я многие вещи, даже в Photoshop не рисую, просто потому что в HTML быстрее. Мне не надо двигать кучу блоков по линеечке, я просто меняю 10px на 13px и смотрю как дизайнер помирает от зависти.
Второе. Я могу не парясь создать интерфейс под все актуальные браузеры, и даже не зная о существовании какого-нить Maxton, в нем все равно будет большая часть работать, а скорее всего все будет работать. А теперь, ВНИМАНИЕ, покажите мне человека, способ, или какую-нибудь гравицапу, которая сделает мне интерфейс под все OS или скажем под все мобильные платформы.
У меня на этот счет надежды на canvas(+webgl где нужно) и на его аппаратную поддержку.
А HTML-css будут выполнять роль мета верстки.
Как то так.
PS кстати к примеру уже тот же GTK обладает быэкэном отрисовывающим его в браузере, хотя конечно сам GTK и гном не крутой пример малозатратных по ресурсам систем.
А HTML-css будут выполнять роль мета верстки.
Как то так.
PS кстати к примеру уже тот же GTK обладает быэкэном отрисовывающим его в браузере, хотя конечно сам GTK и гном не крутой пример малозатратных по ресурсам систем.
А вчём надежды? Рисовать интерфейсы как лет 20 назад в BASIC с помощью PLOT и LINE? :)
Более того, на мой взгляд, автор предложил довольно простую задачу и сказал, что программист потратит пару дней. Ну-ну…
Для начала хочется предложить ему сходить на tympanus.net/codrops и посмотреть, какие красивости там на простом html / css. После этого воспроизвести интерфейс OS/2 кажется простой задачей.
Вернусь к задаче. Для начала хочется заметить, что VML вовсе не оставляет IE6 (ныне, кстати, очень малоактульный) за скобкой. Далее. Написать квадрат со скруглениями и на VML, и на SVG крайне просто. Даже не надо ничего считать — есть стандартные возможности языка. Они же предусматривают обычные обработчики событий, так что определить положение курсора — запросто.
Что касается отсечения — в SVG такие возможности есть. И очень много. Если даже чего-то не хватает — возьмите canvas, на котором всё — рисунок, и его можно сколько угодно отсекать. Управление же объектами на canvas реализуется в два счёта — перерисовкой, либо готовым фреймворком, коих уже десятки (и я, кстати, пишу свой, причём уже 2 дня, и он прекрасно, определяет положение курсора и меняет свойства объектов :) — хоть JCScript или LibCanvas.
Для начала хочется предложить ему сходить на tympanus.net/codrops и посмотреть, какие красивости там на простом html / css. После этого воспроизвести интерфейс OS/2 кажется простой задачей.
Вернусь к задаче. Для начала хочется заметить, что VML вовсе не оставляет IE6 (ныне, кстати, очень малоактульный) за скобкой. Далее. Написать квадрат со скруглениями и на VML, и на SVG крайне просто. Даже не надо ничего считать — есть стандартные возможности языка. Они же предусматривают обычные обработчики событий, так что определить положение курсора — запросто.
Что касается отсечения — в SVG такие возможности есть. И очень много. Если даже чего-то не хватает — возьмите canvas, на котором всё — рисунок, и его можно сколько угодно отсекать. Управление же объектами на canvas реализуется в два счёта — перерисовкой, либо готовым фреймворком, коих уже десятки (и я, кстати, пишу свой, причём уже 2 дня, и он прекрасно, определяет положение курсора и меняет свойства объектов :) — хоть JCScript или LibCanvas.
Отличный троллинг.
А веб-программер сделает, к примеру, флеш за час и скажет, что вы не знаете о всех возможных технологиях.
А веб-программер сделает, к примеру, флеш за час и скажет, что вы не знаете о всех возможных технологиях.
> Пример UI 20-летней давности, который я предлагаю сначала воспроизвести всем апологетам HTML и CSS на этих языках
Апологета этого UI хочется попросить воспроизвести обычную такую кнопочку из Google Docs, которая с тенью, сглаживанием шрифта и эллипсовидными скруглениями, на технологиях полуоси.
Апологета этого UI хочется попросить воспроизвести обычную такую кнопочку из Google Docs, которая с тенью, сглаживанием шрифта и эллипсовидными скруглениями, на технологиях полуоси.
Без конкретных предложений, читается как «автор ниасилил»…
Зачем сравнивать «ж%; у с пальцем»? Если вам нужен GUI используйте Qt, GTK, vxWindow и кучу прочих либ, как раз для этого предназначенных. Только одна проблема. На них писать GUI оказывается нифига не легче…
Про тормоза js не понятно. А с чем автор сравнивает? Мало ли причин, по которым конкретно у автора js может тормозить. Может у вас система слабая. Или память заср%на всякими ненужным хламом.
В общем, писать про что-либо «тормоз» без нормальных аргументов и соответствующего пруфа это троллизм. Он вроде как тут запрещен…
Зачем сравнивать «ж%; у с пальцем»? Если вам нужен GUI используйте Qt, GTK, vxWindow и кучу прочих либ, как раз для этого предназначенных. Только одна проблема. На них писать GUI оказывается нифига не легче…
Про тормоза js не понятно. А с чем автор сравнивает? Мало ли причин, по которым конкретно у автора js может тормозить. Может у вас система слабая. Или память заср%на всякими ненужным хламом.
В общем, писать про что-либо «тормоз» без нормальных аргументов и соответствующего пруфа это троллизм. Он вроде как тут запрещен…
> На них писать GUI оказывается нифига не легче
Стандартный GUI (без наворотов типа «иконка розового котенка внутри названия каждого таба») писать НАМНОГО легче. Накидайте интерфейс какого-нибудь простейшего компонента erp системы в Qt Designer, запомните время. Сверстайте это-же на html+css руками, запомните время. Вывод?
Кстати, насчет js согласен — если он и тормозит, вряд ли это проблемы самого языка. V8 — вообще кавай)
Стандартный GUI (без наворотов типа «иконка розового котенка внутри названия каждого таба») писать НАМНОГО легче. Накидайте интерфейс какого-нибудь простейшего компонента erp системы в Qt Designer, запомните время. Сверстайте это-же на html+css руками, запомните время. Вывод?
Кстати, насчет js согласен — если он и тормозит, вряд ли это проблемы самого языка. V8 — вообще кавай)
Я сверстаю за 10-15 минут, не считая скрипта переключения. Потому что я знаю этот язык, а вот в Qt я совсем ноль. )
Потенцально, WebGL позволит рисовать тысячи и сотни тысяч этих квадратов любой формы.
Очередная порция бреда.
Вы, похоже, совсем не сечёте фишку, зачем придумывался веб.
Это вам не эллипсы со звёздочками рисовать в школе на практикуме.
Вы, похоже, совсем не сечёте фишку, зачем придумывался веб.
Это вам не эллипсы со звёздочками рисовать в школе на практикуме.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Web-технология vs Скорость разработки и производительность