Web-технология vs Скорость разработки и производительность

    Продолжая тему предыдущего поста, прокомментирую слова tushev:
    А еще интерфейс в старинной OS/2 требовал на порядки меньше ресурсов CPU и памяти.
    Да, это действительно так – на порядки.

    У меня нет универсального решения, и конечно я понимаю, что есть реальность, данная нам сегодня в ощущениях (исторические наслоения в виде HTML и CSS всех версий, HTTP). И очень тяжело что-либо изменить глобально. Но я хочу, чтобы каждый разработчик задумался над абсурдностью современного состояния дел в web-технологии. Иначе кардинального решения не будет ни у кого и никогда. Поэтому приведу факты, наводящие на размышления.

    Пример UI 20-летней давности, который я предлагаю сначала воспроизвести всем апологетам HTML и CSS на этих языках, прежде чем минусовать «карму»:




    Двадцать лет назад, весной 1992 года, компания IBM представила операционную систему OS/2 2.0. Стандартная встроенная функция GpiBox в ее API, вызов которой можно было написать в коде за 5 секунд, умела рисовать прямоугольники с заданными радиусами закругления углов.

    С помощью стандартной функции GpiSetModelTransformMatrix эти прямоугольники можно было подвергнуть аффинным преобразованиям типа поворота, переноса, растяжения и наклона в любых сочетаниях, причем эти преобразования могли “каскадироваться” друг с другом операционной системой (чтобы не грузить геометрией голову прикладного программиста).

    В рисовании можно было управлять толщиной линий, способом их соединения и режимом прорисовки концов, примерно как в современном векторном пакете Corel.

    Графика в ОС была векторная. Любую отрисованную фигуру можно было конвертировать в путь отсечения. В стандартном API поддерживалось отсечение по произвольной форме. Не только по квадрату или какому-нибудь эллипсу – границу можно было конструировать даже из кривых Безье в сочетании с контурами букв векторного шрифта Adobe!

    Отсечение могло содержать дырки (вложенные, пересекающиеся и само-пересекающиеся фигуры). Можно было комбинировать множество областей отсечения, пересекая или объединяя их друг с другом.

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

    Примерно 20 лет назад графическая карта Tseng Labs ET4000 с двумя мегабайтами памяти, где-то минус двенадцатого по сравнению с современными графическими картами поколения, рисовывала 925 прямоугольников с закругленными углами в секунду. Или же 243 прямоугольника в секунду применяя к ним отсечение по эллипсу со звездообразной дыркой внутри него. Вот данные реального теста:

    Test: Normal drawing without clipping.
       Speed: 9579.350 markers per second.
       Speed: 10841.799 lines per second.
       Speed: 924.878 round box (1/4 screen) per second.
       Speed: 508.562 filled box per second.
       Speed: 928.161 polylines with 32 vertex per second.
       Speed: 21.150 pattern-filled polygons with 32 vertex per second.
       Speed: 0.286 tricky winding polygons with 512 vertex per second.
       Speed: 55.076 filled and randomly declined ellipses per second.
       Speed: 14.684 randomly scaled bitmaps (320x200 pixels) per second.
       Speed: 17.191 nested polygons with 256 vertex per second.
    

    Test: Drawing with clipping by an ellipse with the star-shaped polygonal hole.
       Speed: 3808.684 markers per second.
       Speed: 1126.427 lines per second.
       Speed: 243.402 round box (1/4 screen) per second.
       Speed: 57.427 filled box per second.
       Speed: 71.152 polylines with 32 vertex per second.
       Speed: 26.752 pattern-filled polygons with 32 vertex per second.
       Speed: 0.250 tricky winding polygons with 512 vertex per second.
       Speed: 68.130 filled and randomly declined ellipses per second.
       Speed: 26.885 randomly scaled bitmaps (320x200 pixels) per second.
       Speed: 26.160 nested polygons with 256 vertex per second.
    

    А теперь “добро пожаловать в реальный мир”:

    Web-программист высшей квалификации, если ему поручить сделать это без готовых toolkit-ов и не передирая из них чужой код, потратит пару дней на то, чтобы БЕЗГЛЮЧНО запрограммировать рисование квадрата с закругленными углами в актуальных версиях браузеров, оставив IE 6 за скобкой.

    Ему придется использовать для этого HTML, CSS, JavaScript, заготовить вспомогательные PNG-файлы и может быть даже VML/SVG, если нужно в полной мере поддержать гибкость задания параметров. При этом ни о каком отсечении по эллипсу со звездообразной дыркой внутри не может быть и речи… :)

    Не может быть и речи о том, чтобы точно и кроссбраузерно определить, попал ли курсор мыши внутрь этого квадрата или остался за пределами его закругленного угла…

    При этом современное решение будет рисовать несколько десятков квадратов в секунду на карте плюс двенадцатого (по сравнению с 1992 годом) поколения и процесс их кривой прорисовки по кусочкам можно будет видеть прямо на экране.

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

    Похожие публикации

    Комментарии 251

      +11
      Ужас. И что теперь без всего этого делать?
      Отсутствие множества инсталяций и глюков связанных с ними,
      благодаря браузеру, лично меня очень радует.
      А от принципа минимализма в дизайне (антоним которого мы видим на вашей картинке) я вообще в восторге.
        +28
        Есть не только twitter и pinterest. :) Посмотрите на реальные приложения для профессионального использования. В приложениях для работы еще и не такие интерфейсы требуются и реально используются на практике. И когда их реализуют в web, то из-за несовершенства языков разметки получается полный отстой – интерфейс глючит, он не pixel perfect, не эргономичен — так как удобные контролы сложны в реализации (хотя для пользователя просты).

        Вообще же интерфейс не должен быть “простым” или “сложным”, это не та шкала оценки.

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

        Да, интерфейс должен быть с минимальным порогом вхождения, по возможности. Но простота – не самоцель. Потому, что всегда за какой-то границей простота вместо ускорения работы пользователя начинает замедлять ее – ему требуется больше кликов, возникает хождение по разным частям интерфейса для сбора всех нужных данных, а что-то просто нельзя сделать в простом интерфейсе и это начинают делать вручную.
          +1
          Такое чувство, что вы пытаетесь в вебе сделать авто кад, или 3д макс. Задавались себе вопросом, зачем? На то он и веб, что он не загружен монструозными интерфейсами и всё сводится до простоты как в плане отображения так и в восприятии. Два последних ваших абзаца можно заносить в виде вступления книги «Проектируем интерфейсы для чайников». Но как это влияет на язык, на котором эти интерфейсы пишутся? Не как.
            +31
            Веб не загружен сложными интерфейсами не потому, что он веб. А потому, что их там невозможно делать.

            Если в вебе есть гуглдокс — нет причин не появиться там автокаду и 3дмаксу.
              0
              Я и не спорю. Сам лично работал в большой компании над веб-мылом с календарём ивентов и тп для бизнес клиентов. Достаточно большое приложение, выполняющее весь функционал настольного приложения. Естественно занимался вёрсткой. Скажу честно, больше времени понадобилось выпелить то, что делали до меня. Уж не кому как мне знать, что делать веб интерфейсы возможно и достаточно просто, если хватает знаний.

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

              Вы тут сам с собой заключили пари смотрю.
                +10
                Я пари не заключал. Я уверен, что гуглдокс — это убогий тормознутый клон нормального настольного софта.

                Если автокад сделают на html — это будет убогий тормознутый клон настольного софта.

                Вашего веб-мыла я не видел, но догадываюсь.
                  0
                  Любая программа, сделанная по образу и подобию другой будет называться клоном.

                  А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса? Причём заметьте за бесплатно. Да, я знаю, что опен офис (либре офис) тоже бесплатен и хорошо работает, но ему не нужно при этом поддерживать огромное количество серверов для своей работы.

                  Гугло докс годный для быстрых заметок, для шаринга документов не высокой сложности, не более. И опишите какие именно глюки при работе с ним вы испытываете.
                    0
                    И почему тормознуть нужно списывать сразу на интерфейс? Сам интерфейс тормозит не может, он по своей сути не отличается от обычного блога по принципам. Тормозит код, который выполняет действия передаваемые интерфейсом. Тормозит браузер, который ещё не достаточно оптимизировал свои парсеры. Нативное приложение всегда будет быстрее чем браузерное. Для примера запустите приложение нативно и в виртуальной машине, в первом случае будет быстрее. Брайзер — это наслоение, от сюда и не высокая скорость по сравнению с нативным приложением.
                      +5
                      Если из примерно 4-х создателей браузеров тормозит у 4-х — это в консерватории что-то не так.
                        –2
                        Давайте называть вещи своими именами. Тормозит JS, так как логика написана именно на нём. Почему он тормозит, потому что нет единого парсера, которым бы занималась одна компания и которая его оптимизировала. Потому что кроме парсера ещё куча других прослоек у браузера.

                        Грубо говоря

                        Нативное приложение:
                        Компилятор(Код => Фреймворк => C++) => ассемблер

                        Веб приложение:
                        JS код => Интерпретатор => Рендер => Компилятор(Код => Фреймворк => C++) => ассемблер
                          +2
                          > JS код => Интерпретатор => Рендер => Компилятор(Код => Фреймворк => C++) => ассемблер

                          Ничего не понятно, но оч красиво. А можно такую же для .NET?
                            –2
                            Смысл — в браузере много прослоек, конец )
                              +6
                              Мне горько разрушать вашу внутреннюю гармонию, но в дотнете их не особо меньше.
                                0
                                Я не знаю .NET так же само как вы не знаете JS. )
                                  +2
                                  Судя по отсутствию примера нормально работающего сайта, JS не знает никто.
                                    +1
                                    Могу показать свой. Правда я им особо не хвалюсь, так как делался он на протяжении нескольких лет на разных стадиях моих знаний. Так что по хорошему нужно переделать всё.

                                    screensider.com
                                      +1
                                      Надпись «Loading ()» на каждый клик мне понравилась.
                                        –2
                                        В дев версии уже нет её, и подгрузка данных почти незаметна, но показать я её вам пока не могу. )
                                          +2
                                          Ок, наконец нашли один сайт, который почти не тормозит.
                                            0
                                            Через пол годика вернёмся к этому вопросу, надеюсь получится вас переубедить )
                                        0
                                        кстати, у Вас сейчас там сейчас картинка с домом и трубой, сделайте анимированный дым, вообще хорошо будет… )
                                          0
                                          Ахах, это скриншот дня, каждый день меняется автоматом )
                                            0
                                            ну вот первый раз открыв, засмотрелся… ) что, если реализация, пусть не всегда, но чего-то… что, привлекало бы… но, это так ) то, что показалось )
                                              0
                                              Было бы время, с удовольствием. )
                              0
                              Вы прямо открываете новое направление в коммерческой разработке. Если какая-нибудь компания выпустит стороннюю машину для JavaScript, сильно выигрывающую по производительности, то она даже сможе ее продать для применения в корпоративных системах со сложной бизнес-логикой и высокими требованиями по времени реакции на команды оператора.
                                +3
                                Давайте называть вещи своими именами. Тормозит JS, так как логика написана именно на нём. Почему он тормозит, потому что нет единого парсера, которым бы занималась одна компания и которая его оптимизировала. Потому что кроме парсера ещё куча других прослоек у браузера.

                                Вы ошибаетесь. JS практически не тормозит. Тормозят манипуляции с DOM. JS здесь ни при чём.
                                  0
                                  Но опять же, это не проблема синтаксиса языка, это проблема реализации её в браузере. С другой стороны сколько нужно генерировать элементов чтобы начало тормозить? Грид лист на 9000 строк будет не удобен в читке пользователем, будет грузить сервер и канал. Для этого и делают пейджинацию, проблема решена.
                                    0
                                    Почему не делают пагинацию в Excel? Вернее вроде она есть там, но не дефолтный режим.
                                      –3
                                      Потому что и в Excel мало встречаются психи, которые вместо того чтобы разделять документ на листы, делают 9000 записей.

                                      9000 элементов в прокручиваемом списке можно и веб реализовать чтобы не тормозило. Делаем так, что бы отображались только видимые элементы, то бишь, при скроле в зависимости от направления одни ноды будут удаляться, другие добавляться. Я уверен что по такому принципу и ексель делает, а не выводит сразу 9000 записей.
                                        0
                                        Думаете мало? Я так не уверен. Прайсы например. Также как и в том, что Excel динамически подгружает показываемые ячейки — если и есть динамика, то на уровне ОС (своп или отображаемые на память файлы).
                                          0
                                          Мы можем только гадать.
                            0
                            > Любая программа, сделанная по образу и подобию другой будет называться клоном

                            Ну да, я так и написал. А к чему это?

                            > А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса?

                            Такой же смысл, как и в любом другом месте. Вы намекаете, что в вебе милисекунды отклика не бывает? Ну да, об этом и топик. Строго говоря есть quakelive.com, но я не уверен, что установка плагина к браузеру — это про веб.

                            > Гугло докс годный для быстрых заметок, для шаринга документов не высокой сложности, не более.

                            Кто б спорил. У меня ощущение, что вы мне пытаетесь объяснить, что веб-приложения убогими получаются. Я в курсе. Даже знаю почему.
                              0
                              Отклик не зависит от интерфейса, на каком языке разметки он не был бы написан. Тормозит код, который обрабатывает действия, передаваемые интерфейсом. Либо из-за того, что его так написали, не занимаясь оптимизацией, либо от плохой координации проекта, либо из-за того, что современные браузеры ещё не достаточно шутры чтобы выполнять сложные дейтсвия. Если вы до сих пор так думаете, что хтмл / цсс вина долго отклика интерфейса, нам больше не о чем говорить дальше.

                              А в гугле, далеко не всегда хорошо пишут код. Любая компания не застрахована от не достаточно компетентных людей
                                0
                                Ну покажите сложный сайт, где код написан хорошо и ничего не тормозит, чего на гугл то пенять.
                                  0
                                  Вы читаете что я пишу? Краткая цитата «Отклик не зависит от языка разметки на котором написан интерфейс, отклик зависит от того как написан код». Я говорю только про разметку и не более, и вопрос тормознутости кода не начинал обсуждать.
                                    –1
                                    А вы топик читали?
                                      0
                                      Автор топика вообще не вникал в суть того, что тормозит.
                                      0
                                      Не попадался еще ни один «тяжелый» сайт, который бы работал без задержек. Скажете, у всех разработчиков поголовно руки кривые?
                                        0
                                        А вы можете себе представить, что многие задержки случаются из-за того, что клиент передаёт / принимает информацию от сервера? И что задержка зависит уже совершенно не от кода, не от браузера, не от ос, и даже не от железа, используемого вами? А от провайдера и от отдалённости сервера сайта от вашего местоположения. Чем больше передаётся информации тем больше задержка.

                                        Если у вас тормозят сайты, пора бы задуматься о чистке системы или смене железа.
                                          0
                                          Но почему-то, скажем, нативное приложение для Google+ работает значительно резвее, чем веб-версия, причем даже открытая в родном браузере. И задержек тоже никаких нет, точнее, от них приложение не виснет, а показывает крутилку.

                                          Если у вас тормозят сайты, пора бы задуматься о чистке системы или смене железа.
                                          Я думаю, что железо, на котором на Ultra High идет кризис (как хрестоматийный пример) и рендерятся модели в максе, вполне достаточно, чтобы отобразить сайт.
                                            –2
                                            Если брать нативное приложение под андроид, то оно отображает гораздо меньше информации за раз, а значит на подготовку информации сервером и загрузку клиентом нужно меньше времени.

                                            > рендерятся модели в максе
                                            Значит отношения в вебу вы не имете, и как он устроен тоже не знаете. О чём тогда дальше говорить?
                                              0
                                              По-вашему, невозможно работать в максе и разбираться в вебе? Так или иначе, не нужно быть поваром, чтобы оценить вкус блюда. Задержки и торможения интерфейса в вебе заметны любому.
                                                –1
                                                Нет, потому что нужно работать в этой сфере, а не априори рассуждать его минус не зная дела. А вы, как минимум, не знаете, что в отличии от оффлайн приложений, когда информация хранится на вашем винчестере, информация в вебе хранится на серверах, и чтобы она попасть к вам в браузер, ей нужно сначала свариться на сервере после чего пропутешествовать по проводам и магистралям. Данная задержка называется ping. Плюс к задержке добавляется время скачки, аналогично тому как качается фильм.

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

                                                Вот мой сайт, построен полностью на JS. На нём есть только задержки подгрузки контента.

                                                screensider.com/
                                                  0
                                                  Еще раз говорю — конечному пользователю пофиг, пинги там, сервер тормозит или просто задуматься решил. Он видит, что у него повисает браузер на несколько секунд. А нативное приложение показывает крутилку. И вы мне так и не ответили, чем, скажем, Google+ или Ag.ru, или еще какой-нибудь тяжелый сайт настолько вычислительно тяжелее игрового движка. Для меня кажется диковатой идея, что у всех поголовно разработчиков руки кривые и они не умеют делать сайты. Это какая-то системная проблема — проблема технологии как таковой. Собственно, об этом и пост, и об этом же я написал. Сайты тормозят. Не все, не всегда, но часто. Натив тормозит реже.

                                                  А карма из-за вашего идиотского аргумента «кто не в вебдеве, тот дурак и априорно не может ничего знать».

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

                                                    Почему нативное приложение быстрее работает чем веб сайт?
                                                    Потому что файлы разметки, стили, вёрстка, код, изображения оформления, пиктограммы, иконки, хранятся у вас на диске. Подгружается только информация в виде 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 евро в месяц.

                                                    Почему мой сайт не страдает задержками?
                                                    Мой сайт, грубо говоря, построен по принципам, которые я описал в первом вопросе. Отличие от второго вопроса только в том, что при первом заходе — при старте, он выкачивает сразу все стили, картинки оформления, вёрстку и код. А дальше он, как и нативное приложение, принимает контент в виде «голого» массива. Так как вёрстка заранее загружена, подстановка контента в вёрстку происходит на вашем железе. Тем самым мой сервер не загружается этой операцией, и может выдавать контент достаточно быстро.

                                                    > А карма из-за вашего идиотского аргумента «кто не в вебдеве, тот дурак и априорно не может ничего знать».

                                                    Я вас не в коем случае не оскорблял, даже между срок не было повода. Я вам намекнул на то, что вы оперируетесь какими-то априори догадками. Поймите меня правильно, я не википедия и не большая энциклопедия, чтобы рассказывать о принципах работы веба всем желающим персонально.
                                                      0
                                                      Но ведь «клиент» из первого пункта можно без проблем на JavaScript в вебе сделать. Скачивать JSON, формировать DOM в JavaScript, вставлять в документ, и так далее.
                                                        0
                                                        У меня уже слегка поменялась позиция по этому поводу.

                                                        Мой сайт так и делает, правда давно уже делалось и нужно всё по хорошему переписать. Даже при этом, как вы и подметили, это работает быстрее в плане загрузки, нежели статичный сайт.

                                                        Если планируемый клиент достаточно не сложный по функционалу, то можно и через тот же PhoneGap сделать клиент на привычном html \ js \ css. Проблемы начинаются с большим количеством данных, например огромным количеством картинок (~30к, 4 колонки), которые нужно подгружать по скроллу. Не давно делали подобную задачу, так решили отображать картинки через канвас. Если грамотно оперировать ресурсами, то такой клиент будет ни чуть не хуже нативного.
                                +2
                                «А какой смысл в вебе держать полноценную версию софта, с которым вы серьёзно работаете, и вам важна каждая мили секунда отклика интерфейса?»

                                Смысл такой: с десктопным софтом вы привязаны к одному компьютеру. С вебовским — можете спокойно переходить с одного девайса на другой, и везде находить ваши открытые документы именно в том состоянии, в котором вы их оставили.

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

                                Для документов, которые осмысленно мерджить нельзя (графика, CAD, u-name-it), это весьма перспективный подход.
                                  0
                                  По крайней мере он сохраняет каждую правку, визуально видно.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Ну значит технические средства еще не готовы. О чем и топик.
                                  +3
                                  > гуглдокс — это убогий тормознутый клон нормального настольного

                                  Хух. А то я думал что это один я считаю что все эти javascript приложения это какие-то странные монстры и должны быть заменены чем то более совершенным.

                                    +3
                                    Да откуда вы все люди? Кем вы работаете? И кто зомбирует ваш мозг?

                                    Я переустановил виндовс, клиент мне прислал .docx, а у меня из программ только хром стоит, а открыл docs, открыл файл, почитал, написал, сохранил. Профит.

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

                                    Если мне понадобится, написать, серьезный труд на 3000 страниц, я скорее всего воспользуюсь Word, но если у меня нет необходимости держать его открытым больше 30 минут, все преимущества у docs.

                                      0
                                      А если бы у вас был Ворд 2010 и хром. Вы бы тоже открывали через гугл докс? ;)
                                      PS. Я, как часто пользующийся вордом могу сказать, что он стартует меньше чем за секунду. А семерка прописывает любые приложения в быстрый старт, если вы ими часто пользуетесь.
                                        +2
                                        У меня на ноуте с i5 с 6 гигами оператвки и семеркой, но офис открывается много дольше чем просто нажать «просмотреть» в гмейле. И просмотреть это один клик, а сохранить, открыть, потом еще и удалить, если он не нужен — зачем усложнять жизнь?
                                        Но при этом я против облачного хранения, и, если надо что-то написать или оформить, я открою Ворд. Каждому инструменту свое применение.
                                          0
                                          Сравните с офисом 2003 хотя бы (а лучше с офисом 97) — открываться будет быстрее, давая на порядок больше возможностей.
                                            0
                                            Да всякие ситуации бывают. Иногда так иногда так удобно. Вот тут товарищь сказал про файл. В таком случае все несколько иначе.

                                            Ситуаций много. У каждого есть мозг. Зачем плодить лишние сущности и изобретать ситуации?
                                          0
                                          Но документ, который поддерживают Google Docs — это документ уровня Word 2.0, с ним его и надо сравнивать по быстродействию. А он, напомню, на 386 работал.
                                    0
                                    Не интерфейсами едины. Там еще есть такая малозаметная за интерфейсами вещь, как контент.
                                  +4
                                  Довольно сложно ожидать, что интерфейс как на картинке способен экономить время (если не сравнивать с бумажными вариантами).
                                  +1
                                  Самое смешное, во всех этих сравнениях с OS/2 в том, что единственные квадратики со скруглениями — на кнопках. А в браузерах теги выводящие кнопки, выводят их со скруглениями (и не только), что называется из коробки, даже в IE 6 (и более древних).

                                  По сути в статье речь идет о кастомных кнопках. А тут уже можно поспорить, где проще сделать кнопочки, нарисованные дизайнером в фотошопе, в HTML или в OS/2?
                                  –3
                                  спасибо, подро… тьфу… понастольгировал :)

                                  а вообще усложнение процесса всегда дает работу. нам.
                                    +2
                                    Что значит «без готовых toolkit-ов»? А OS/2 API тогда что?
                                      +6
                                      OS/2 API — это примерно то же, что и браузер со своими CSS. А тулкит — это сторонняя библиотека.
                                        0
                                        Да ладно. Можно подумать что раньше писали на голом API без каких было библиотек :)

                                        Хотя соглашусь с общей мыслью. Связка HTML + CSS + JS меня, как программиста на C++ и C#, вгоняет в уныние своими конструкциями. Единственный плюс для меня был в JS — это была хорошая практика асинхронного программирования (после «синхронных» программ на C++, так сказать встряска для мозга — другой подход, другое мышление).
                                          0
                                          Можно подумать что раньше писали на голом API без каких было библиотек
                                          Не напоминайте. У меня был «весёлый» опыт написания гуёвого кода даже в отсутствие сишной стандартной библиотеки, только WinCE API через syscall'ы.
                                            0
                                            WinCE + API :) И чем вы так провинились? :)

                                              0
                                              Видимо, программировали под Windows в условиях жёсткой экономии ресурсов. :)
                                            0
                                            Связка HTML + CSS + JS меня, как программиста на C++ и C#, вгоняет в уныние своими конструкциями.


                                            Может это потому что вы именно программист, а из трех перечисленного вами, только JS является языком программирования? А он скажем прямо не образец идельного синтаксиса.

                                              –1
                                              а из трех перечисленного вами, только JS является языком программирования


                                              А что такое тогда такое C++ и С#?
                                                0
                                                Три перечисленные вами: HTML + CSS + JS
                                                  0
                                                  А вы вот о чем. :) Ну так тут речь именно о связке. Как-то сами по себе CSS и JS мне не нужны. А голый HTML уже давно в прошлом.
                                                0
                                                Формально они ЯП не являются, но практически — да. Они указывает машине что ей делать с данными. Другое дело, что HTML+CSS являются декларативными языками, а C* — императивными. Вот с этим может быть проблема «уныния».
                                                –2
                                                C++ и C# вгонят в неменьшее уныние веб-технолога/верстальщика
                                                  +1
                                                  Ну, например XAML, меня в такое не вгоняет. Хотя это по сути ближе к HTML+CSS, чем к программированию.
                                              0
                                              OS/2 API скорее всего представляет собой набор заголовочных файлов, используемых для линковки и компиляции конечного нативного приложения и кроме уровня абстракции (необходимого, впрочем, imho) ничего более не утяжеляет.
                                              Опять же — не знаю, может, не прав. ;)
                                              +2
                                              Согласен с автором. Мне приходиться отдавать предпочтение Qt для быстрой разработки кроссплатформенного интерфейса. А хотелось бы иметь возможность быстрой разработки GUI для web.
                                                +1
                                                QML для браузеров сделать можно (помоему даже сделали), но вряд-ли он будет популярен.
                                                +6
                                                Вот привязались же вы к этой форме. Да, ее за 5 минут на коленке не собрать.
                                                Ну вот сделаем новый язык, и для него найдется точно такое же нетривиальное задание, будьте уверены. Начнем опять писать о тупиковости этого языка? Только из-за того, что разработчику понадобилось чуть больше времени, чтобы пошевелить мозгами и написать чуть больше кода?
                                                  +2
                                                  Что-то я не понял как повлияет «новый язык разметки» на скорость отрисовки финтиклюшек.
                                                    +3
                                                    Если в нем будет, например, round box как стандартное средство, то на современной карте их можно будет рисовать 900 тысяч штук в секунду, наверное (примерно). Потому, что не потребуется тянуть с сервера PNG и рисовать квадрат декодируя пожатую растровую графику его по мере ее подкачки. А это в свою очередь сейчас, чтобы страничка отображалась в IE 8 хотя бы, а не только в FF и Chrome. Допустим, пройдет еще 3 года и вопрос конкретно с round box закроется, так как минимальной версией IE будет девятая. А что со всем остальным? Как нормально сверстать хотя бы такой блокнотик с закладками на CSS/HTML без извращений и большого количества JS кода вовсе не ради динамики, а прямо для самой отрисовки и позиционирования? Макетирование на JS — это бред сивой кобылы. Представьте себе, что верстку газет и журналов приходилось бы делать через написание скриптов на JS под каждый номер заново.
                                                      +3
                                                      Очень-очень давно такое было возможно. Только вместо JS был postscript. Он и сейчас есть но большинство думают что это формат, а не язык.
                                                        0
                                                        А еще был display-postscript, в NeXT.
                                                          0
                                                          Интересно, почему больше нигде не применяется. Штука интересная.
                                                            +1
                                                            Почему не применяется? Интерфейс в макоси работает на похожей технологии. А конкретно за display postscript большие лицензионные отчисления надо платить.
                                                        +5
                                                        Если вам нужны какие-то фиговины этакие в HTML/CSS — так уверен, половина этих фиговин уже есть в том же CSS3. Скругленный и повернутый прямоугольник — свойства border-radius и transform. Те браузеры, в которых эти свойства реализуются, обязаны поддерживать правильные события с мышкой. Если не поддерживают — пожалуйста, сообщайте о багах.
                                                        Какой смысл ныть «вот, я хочу это и это, а из-за мерзких старых браузеров надо три дня голову ломать и все равно криво будет»? Просто не используйте старые браузеры и не верстайте под них — заодно больше народа пересядет на новые браузеры со всеми рюшечками. Или вы думаете, что создав какой-то новый язык оформления и размертки, его сразу начнут поддерживать IE 7 и Firefox 2.0?
                                                          +26
                                                          Смотрю вы ничего для себя не подчеркнули с прошлой статьи.

                                                          > Если в нем будет, например, round box как стандартное средство, то на современной карте их можно будет рисовать 900 тысяч штук в секунду, наверное (примерно).

                                                          А причём тут CSS, цсс — это набор стандартов, которые реализуются браузером. В первую очередь нужно ругать браузеры за «медленную», по вашим словам, отрисовку.

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

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

                                                          И что из этого всего вы предлагаете, кроме нытья, ничего.
                                                          А теперь перейдём к реалиям. Удаляем хтмл и цсс, тратим 5 лет на создание нового layout'a, превращаем веб в ос/2. Дальше если сил хватит, делаем софт — рендер всего этого, если нет — описываем спецификацию. Через 2 года выходит софт, ещё через 2 его портируют под линукс и мак ос, ещё через 2 кое как появляется мобильные версии. Дело подхватывает другая компания и выпускает свой софт. Но не поддерживает спецификации полностью, а в некоторых моментах реализует по своему, как ей виднее. Но этой компании удаётся удачно продвинуть свой продукт. Появляется третяя и четвёртая, начинает наследовать наработки второй, чтобы быть в теме, и реализовует свои фичи, которые требует рынок нынче. Тем временем, первую компанию начинает лихорадить и внутри, одна половина команды за то чтобы разрабатывать новый стандарт, другая за то чтобы просто ввести фичи, которые понаделали производители софта. Компания принимает решение, что создавать новый стандарт каждые 10 лет не выгодно, так как только на внедрение нужно 10 лет и начинает плясать относительно наработок других компаний.
                                                            +1
                                                            Можно сделать небольшое изменение в вашем сценарии — написать один рендерер, сделать его кроссплатформенным и распространять по свободной лицензии. Тогда один и тот же рендерер сможет использоваться в разных продуктах — примерно как WebKit используется в Safari и Chrome.
                                                              0
                                                              Да можно и не начинать с чистого листа, а взять тот-же WebKit за основу.
                                                                0
                                                                Я тоже об этом подумал. Но если реально посмотреть на вещи, — в существующем раскладе вряд ли что-то можно изменить. Ну не согласятся FF и IE выкинуть все свои наработки и начать использовать WebKit.
                                                                Разве что, создать общий комитет по слиянию кода в один рендерер… но звучит это нереально.
                                                                  0
                                                                  В любом случае, прежде чем пытаться стандартизировать новую технологию, необходима самая первая реализация. Эта реализация должна показать жизнеспособность новых принципов, положенных в основу технологии, и позволяет попробовать ее в деле.
                                                                +1
                                                                В идеале да. Я тоже приверженец идеи, что такую штуку должна разрабатывать одна группа людей. Но тогда браузерам фактически не чем будет конкурировать, они не позволят такой стандартизации, что очень печально. А если делать общий комитет, то один уже есть — w3c, перетягивания одеяла.
                                                                  0
                                                                  Этот вопрос можно решить и иначе — нужно так ясно описать правила обсчета layout, что разная имплементация в разных браузерах станет невозможной без грубого нарушения стандарта. Я считаю, что базовый язык описания разметки должен быть абсолютно детерминистичным и гарантировать bit exact воспроизводилось картинки на любом устройстве — естественно при использовании одного и того же шрифта и при одинаковых размерах окна. Такой детерминизм нужен для того, чтобы разработчикам сайта не приходилось вообще задаваться мыслью «а как это будет показано у клиента?». У клиента всегда будет показано точно так же, как у них самих. Браузеры должны конкурировать между собой соревнуясь в скорости отрисовки, закачки и наборе своих собственных встроенных фич. А не в том, как именно они рисуют страницу.
                                                                    0
                                                                    Ладно, обойду с другой стороны.
                                                                    Невозможно написать идеальный стандарт с первого раза, кто бы не говорил что, всегда будут баги. Всегда с появлением новых требований рынка, стандарт нужно будет улучшать.

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

                                                                    Ок, делаем в ядре возможность авто обновления вне зависимости от браузера. Не будем оговоривать, какие баги это может вызвать в браузере, который пилил свой функционал под определённые версии ядра. Ввести принудительное обновление мы не сможем, так как такой браузер с большой вероятность запретят в ЕС. Нужно делать уведомления о том, что ядро обновится. После чего найдутся какие-то проценты людей, которые будут говорить, что стандарт 1 был быстрее и стабильнее, и не станут дальше получать обновления ядра. Пример с фф 3.6 например.
                                                                +2
                                                                Вам уже отвечали, что в газетах и журналах блоки имеют фиксированный размер и фактически абсолютное позиционирование. А если вы видели, что в газетах, где-то динамически переключаются страницы или блоки меняют свою ширину, отсыпьте грибов.

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

                                                                Кроме того, не знаю как верстаются газеты, а при верстке книг обычно на финальном этапе происходит тонкая настройка макета. Например оптимизируется взаимное расположение блоков с графикой, и связанного по смыслу текста. Разумеется такие оптимизации возможны только если размер страницы фиксирован. Все эти тонкие настройки невозможны при «резиновой» верстке.
                                                                  0
                                                                  В порядке бреда: А если сделать расширяемый язык разметки, базовые конструкции (препроцессор) которого бы описывали синтаксис, семантику и визуализацию (пожалуй даже сенсоризацию или как ещё назвать, в общем не только для глаз, но и для других органов чувств) произвольных конструкций (новых тегов) единым формальным способом во внешних документах. Продвинутые браузеры предоставляли бы нативную реализацию популярных производных тегов (типа виртуальной машины), устаревшие бы работали в режиме непосредственной интерпретации. Всё везде бы показывалось и т. п. одинаково только с разной скоростью.

                                                                  В общем что-то вроде XML, но описывающее не только синтаксис, но и семантику и базовую визуализацию. Разработчики документов (верстальщики) расширяли бы язык под свои требования в процессе вёрстки (конечно, используя сторонние наработки), разработчики браузеров наиболее популярные (для начала, скажем, тот же HTML5+CSS3) бы реализовывали нативно, а остальные интерпретировались бы на лету или в режиме JIT. Кроме нескольких базовых элементов языка (вернее даже метаязыка) всё остальное бы содержалось в документе (плюс ссылки из него).
                                                                    0
                                                                    Как-то это слабо представляется…
                                                                  +4
                                                                  Представьте себе, что верстку газет и журналов приходилось бы делать через написание скриптов на JS под каждый номер заново.
                                                                  Не под каждый номер, а под каждое издательство. Сделал один раз себе табы, настроил по вкусу — используй.
                                                                  Как нормально сверстать хотя бы такой блокнотик с закладками на CSS/HTML без извращений
                                                                  Есть же плагины, которые делают табы в html, чем они не подошли? Ну нет такого в стандарте html, но есть же инструмент. Какая разница, много там js или мало? Визуально это незаметно, отрисовывается всё моментально, никакой разметки в js разумеется нет.

                                                                  Знаете, вы, мне кажется, вообще пропогандируете использование какого-то метаязыка типа asp.net webforms — положил контрол, он сгенерил html. Нет, спасибо, уже проходили.
                                                                    0
                                                                    в html все есть.
                                                                      +1
                                                                      Знаю, что есть. Я имел в виду, что автор, наверное, хочет поддержку в табов прямо в разметке, без css.
                                                                      0
                                                                      Плагины глючат — поиск безглючного перед покупкой уже сам по себе работа, :) они нередко негативно интерферируют друг с другом или требуют изменений в разметке под них в коде документа. Когда плагинов много их загрузка или даже пустые запросы для валидации кэша (через ETag и If-Modified-Since) вносят большую latency, из-за которой страницы сайта грузятся медленно (даже если все они лежат на сервере в кэше в памяти). Все это делает интерфейс тормозным, с большой latency. Посмотрите на страницу какого-нибудь обычного сайта, сделанного на CMS типа Joomla или Drupal. Если сайт не совсем простенький – на нем как раз-таки поставлена куча платных плагинов. Они подключают десятки разных фреймворков и темплейтов. В результате страница тянет десятки файлов с сервера каждый из которых нужно каждый раз заново валидировать, так как на сайте могла поменяться версия плагина или CMS.
                                                                        +1
                                                                        Так можно объединить скрипты в один, если их на странице 100500, никто ж не мешает, latency уйдёт. Это всё решается за два часа, когда появляется реальная проблема.
                                                                        Сейчас на каждом сайте графика весом до 0.5..1МБ, что делает плагины практически незаметными. То есть, пофиг на скрипт, размер которого 50кб: всё равно у большинства сейчас инет шустрый и задержки в 0.2 секунды ни один человек не заметит.
                                                                        Проблемы с Джумлой или Друпалом, в-основном, из-за кривой серверной части. Точно так же есть десктопные приложения, написанные на каком-нибудь монстре вроде Infragistics, Telerik или DevExpress. Ещё спорный вопрос, что загрузится быстрее: веб-сайт или такое вот приложение-монстр.
                                                                        Вы раздуваете из мухи слона. Путаете недостатки говнокодеров-адептов Rottenapid Application Development и недостатки html/css/js.
                                                                      +13
                                                                      Есть понятие формата, которое вы себе, судя по уже второму посту, плохо представляете. Нужно думать не о переносе конкретной реализации блокнотика из операционной системы в веб, а о решении той же задачи, которую решал блокнотик.

                                                                      Очевидно, этот блокнотик был придуман, чтобы разместить в одном окне ограниченного размера как можно больше элементов управления. Даже если оставить в стороне уродливость внешнего вида, такое решение с вкладками не является очень хорошим примером интерфейса, так как пользователь не знает (или не помнит, ведь окном настройки не пользуются постоянно) плотность заполнения каждой вкладки и не имеет представления о том, сколько еще параметров можно изменить.

                                                                      Проблема нехватки места в вебе прекрасно решается прокруткой. Поэтому, чтобы решить ту же задачу, нужно поместить друг под другом содержимое каждой вкладки, используя крупные заголовки. У такого метода целая куча плюсов. К прокрутке привыкли все. На больших экранах пользователь увидит сразу всю форму. Таким образом, на HTML/CSS блокнотика нет, но задача, которую он выполнял, решается.

                                                                      При проектировании интерфейсов не нужно забывать о формате.
                                                                        0
                                                                        Часто ещё делают коллапс блоки, при нажатии на который открывается под тайтлом его содержимое.
                                                                    +9
                                                                    Критикуя — предлагай! (с)
                                                                      +3
                                                                      Объясните несведущему, помню еще 5 лет назад громко трубили о приходе векторной графики в веб в лице svg, уже вроде бы и все браузеры поддерживают его нативно, так почему же воз и ныне там? Альтернатива от МС в лице silverlight/wpf реально очень удобны.
                                                                        +3
                                                                        Да даже не хочется лезть в дебри всего этого (HTML, CSS) после решения задач к примеру на технологии Silverlight(удобно, продуктивно, одно удовольствие в процессе разработки, красиво).
                                                                          0
                                                                          Вот, кстати, MS разработала связку Expression + Blender, позволяющую с легкостью разрабатывать интерфейсы для web. Но отрисовкой занимается в этом случае не браузер, а модуль Silverlight.
                                                                          +1
                                                                          O RLY? IE8 и ниже: 10% в России. 90% браузеров поддерживают SVG. Silverlight нет у половины.
                                                                          +3
                                                                          Главное содержимое и его семантика, а не дырки в звездах.
                                                                            +9
                                                                            > Web-программист высшей квалификации, если ему поручить сделать это без готовых toolkit-ов и не передирая из них чужой код, потратит пару дней на то, чтобы БЕЗГЛЮЧНО запрограммировать рисование квадрата с закругленными углами в актуальных версиях браузеров, оставив IE 6 за скобкой.

                                                                            > Ему придется использовать для этого HTML, CSS, JavaScript, заготовить вспомогательные PNG-файлы и может быть даже VML/SVG, если нужно в полной мере поддержать гибкость задания параметров.

                                                                            Серьезно? Для того чтобы только нарисовать квадрат с закругленными углами, вашему «Web-программисту высшей квалификации» нужно все это?
                                                                              0
                                                                              Эмм… Как сделать скруглённые углы для IE7/8 без использования сторонних библиотек?

                                                                              А даже если с ними, то они как раз и используют html, css, javascript, vml или png.
                                                                                0
                                                                                Давайте абстрагируемся от старых браузеров и будем рассматривать то, что есть сейчас. Ведь если и выйдет новый язык разметки, он не сразу обзаведётся поддержкой всех и вся и не займёт 100% рынка за один уикенд.
                                                                                  +4
                                                                                  Верно. Но скруглённые углы — это меньшее из зол на самом деле. Сложные интерфейсы — вот в чём беда.

                                                                                  А все эти extjs, библиотеки для построения интерфейсов gmail, gdocs и прочих и иже с ними это такой мрак в плане того, как именно на уровне html они работают, что просто слов нет.
                                                                                  +2
                                                                                  > Эмм… Как сделать скруглённые углы для IE7/8 без использования сторонних библиотек?

                                                                                  Картинками. Так даже и в IE6 и прочем аналогичном будет работать. А иначе (и чтобы на всяком древнем г. работало) — никак.
                                                                                  Но даже и тут работы никак не на «пару дней для Web-программиста высшей квалификации».
                                                                                    +3
                                                                                    Правильно, картинками придётся городить огород, теряя при этом семантику, простоту и удобство поддержки. При этом, если потребуется изменить углы, или декор, придётся переделывать кучу картинок, ну и так далее. А если углов много и они разные — то проще воспользоваться неким более универсальным решением, как раз из области vml и прочих извращений.

                                                                                    А если огорода с картинками не городить — то придётся использовать либо сторонние библиотеки (которые его построят за вас). либо подобное решение написать самому. Что реально может занять много времени.

                                                                                    Но в целом согласен, автор немного сгущает краски. Но в плане отсутствия нормальных инструментов построения интерфейсов в вебе он полностью прав.
                                                                                      +2
                                                                                      Все дело в том, что огород придется городить, если задаться целью сделать интерфейс, одинаковый как для современных браузеров, и для браузеров 10-ти летней давности. Если же строить интерфейс со всеми красивостями только для относительно современных браузеров, учитывая их возможности — то и проблем то особых нет.
                                                                                        0
                                                                                        IE8 — относительно новый браузер. И он ещё долго будет в вебе. XP будет жить долго.
                                                                                          0
                                                                                          Мне интересно что c IE8 станет когда Google перестанет его поддерживать, а это случится сразу после выхода IE10.
                                                                                            0
                                                                                            Им и так уже, по разным источникам, пользуются от 10 до 14% на апрель этого года.
                                                                                            Против 16-22% на декабрь-январь.
                                                                                              +1
                                                                                              Прозреваю, что пользователи IE8 в этом случае принуждены будут поневоле перейти на Chrome (как на то, возможно, надеются в Google), а рáвно и на Firefox, и на Opera.
                                                                                  +6
                                                                                  Пример UI 20-летней давности, который я предлагаю сначала воспроизвести всем апологетам HTML и CSS на этих языках, прежде чем минусовать «карму»:
                                                                                  Пример резидентного вируса 30-летней давности, который я предлагаю сначала воспроизвести всем аплогетам TeX и LaTeX на этих языках, прежде чем минусовать «карму»…
                                                                                    +10
                                                                                    Короче, бред это всё. Или я не понял чего? Что вы опять к этой OS/2 привязались. HTML при разных там своих возможных недостатках был задуман и является средством РАЗМЕТКИ, по определению, а не средством построения GUI. Реально разницы не видите никакой? Поэтому вообще странный цикл заметок.
                                                                                      +18
                                                                                      Вот именно. Современный веб требует средств построения GUI, а не разметки текста. Веб — это уже давно не набор слинкованных страничек.
                                                                                        0
                                                                                        Всё верно, так я с этим и не спорю. Я о том, что инструменту предъявляются нехарактерные претензии. Но при этом текст, слинкованные страницы и прочее вроде как тоже нужны, на что удобное средство для их реализации предлагается заменить?
                                                                                          +4
                                                                                          Предлагается оставить инструмент разметки текста для текста, а все элементы управления делать на чём-то более адекватном этой задачи. Сейчас этот инструмент используется для всего подряд.
                                                                                            –1
                                                                                            Есть флеш с флексом, а ещё лучше сильверлайт. Но, есть другая группа веб разработчиков, которые уверены, что веб должен быть нативным. Как бы компромисс найти, и надоумить w3c шевелится в этом плане, ни кто не знает.
                                                                                              +2
                                                                                              Я бы сказал, что другая группа разработчиков уверена, что веб должен быть открытым и кроссплатформенным.
                                                                                                0
                                                                                                Я тоже в этом уверен )
                                                                                    +2
                                                                                    Мне кажется, что все же есть разница между web-интерфейсом и какой-нибудь типовой текстовой страницей. И если первое подразумевает некоторую сложность верстки (закладки, слайдеры, диалоговые окна, тултипы и т.д. ), то типовая страница создается на HTML + CSS на раз-два, собственно, для чего и был создан HTML, не?

                                                                                    Так как стандартов на современные интерфейсы нет, то и жаловаться не на что.

                                                                                    Кстати, инетересно, было бы попробоватьна UI двадцатилетней давности сверстать сайт, наверняка задача не из простых.
                                                                                      +3
                                                                                      > Так как стандартов на современные интерфейсы нет, то и жаловаться не на что.

                                                                                      Отличная цитата. Если бы в вебе был стандарт оформления как в системе, тогда можно было бы писать средства для написания GUI, которые следовали бы чётко описано дизайну форм и контролов. Но тогда какой бы это уже был веб? Копнём глубже, и посмотрим с другой стороны.

                                                                                      Появился набор семантических котролов: табы, модальные окна и тп. Они умеют вид такой, какой пропсиан в некой спецификации «дизайна контролов». Так как веб не ограничен один оформлением, мы будем иметь следующую картину. Дизайнер взял, да и добавил картинку на табу, интересно как программист будет реализовывать эту картинку используя стандартные контролы? Нам уже и так хватает опыта, что нельзя полностью кастамизировать select, input type=«file» вообще приходится скрывать и делать сверху фейковую кнопку, и таких контролов достаточно много.

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

                                                                                      ПС. Чтобы написать кастомный select, понадобится порядка 30 минут времени. Которой при случае сможет работать и без жс, отображая просто стандартный контрол.
                                                                                        +2
                                                                                        Нам уже и так хватает опыта, что нельзя полностью кастамизировать select, input type=«file» вообще приходится скрывать и делать сверху фейковую кнопку, и таких контролов достаточно много.

                                                                                        Так input-type-file это вобще тема для отдельного разговора. Он и должен выглядеть определенным способом, поскольку предназначен для совершения привилегированных действий. Фактически мы разрешаем интернету вылезти из песочницы и забрать файл с жесткого диска. Это как окно ввода пароля для совершения административных действий.
                                                                                          +1
                                                                                          Скажи это дизайнерам. Есть понятие дизайн и оформление сайта. Везде на сайте будут красивые кнопочки, и тут вдруг хардкорный инпут со стандартной кнопкой. Не считаете это убогим? Самым глупым было сделать этот контрол одним целым. Куда бы удобнее было где-то так:

                                                                                          <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>
                                                                                          
                                                                                      +1
                                                                                      А упомянутая Вами компания Adobe разве не для этого Flash создала? Для RIA- предложили Flex где весь код приложения это XML+AS компилируется в swf и используется на любой платформе (а для тех кто любит standalone- приготовили Adobe AIR), правда работает не во всех браузерах, но тем не менее.
                                                                                        –3
                                                                                        Учитесь выбирать конкретный инструмент под конкретную задачу.
                                                                                          +8
                                                                                          Пока я занимался разработкой standalone-приложений, время, затраченное на реализацию интерфейса составляло около 10-15% от общего времени разработки. Но после перехода в сторону web заметил, что реализация и отладка нормальных интерфейсов занимает гораздо больше времени, а эпичные грабли могут вылезти там, где их совершенно не ждешь. В Standalone граблей хватало при разработке бизнес-логики, но с интерфейсом проблем не было никогда. Многие на первый взгляд простые вещи (например, двухуровневая статистика по клику на точку графика \ сектор диаграммы) в html+css+js превращаются в настоящий ад.
                                                                                          Отсюда возникает проблема неопределенности сроков, а это уже серьёзно.

                                                                                          Поэтому можно с уверенностью сказать, что разработка для web более трудозатратна, чем разработка standalone-приложения со схожим техзаданием. С другой стороны, в долгосрочной перспективе такое приложение гораздо проще поддерживать, распространять и обновлять.
                                                                                            +2
                                                                                            Просто в вебе идёт разделение на верстальщика и программиста. Хороший программист по факту не очень хороший верстальщик. А проблемы с неопределенностью сроков отпадают при появлении опыта, как и в любом другом деле.
                                                                                              +1
                                                                                              Это разделение в web весьма условно. К примеру я интерфейсы web-приложения делаю сам, в то время как порезать макет сайта — отдаю верстальщику. Просто лично мне не интересно верстать сайт, это больше машинальная работа.

                                                                                              Точно так же как в OS/2 эти формочки скорее всего не программисты рисовали, а проектировщики интерфейсов.
                                                                                                0
                                                                                                Ну в общем я это и имел ввиду.
                                                                                                +4
                                                                                                мне кажется, что это искусственные трудности. Есть такая концепция — RAD, быстрая разработка приложений. И пока я работал в рамках этой концепции, мне было не влом раскидать по форме кнопочки, чтобы оно просто работало.

                                                                                                В сухом остатке для описания формы мне нужно было покликать мышкой и написать обработчики на том же языке программирования. В случае с web только для интерфейса мне приходится пользоваться как минимум двумя языками (html+css, javascript), которые к тому же очень по-разному интерпретируются на клиентских машинах. А не дай б-г придётся делать печатные формы — это вообще будет триллер.

                                                                                                В сухом остатке для создания мало-мальски рабочего интерфейса необходимо знать javascript, HTML, CSS, а также особенности работы двух последних на добром десятке различных платформ. Беда лишь в том, что всё это, как правило, не имеет ни малейшего отношения к ТЗ.
                                                                                                  +1
                                                                                                  я всегда буду перечитывать пост перед отправкой. я всегда буду перечитывать пост перед отправкой. я всегда буду перечитывать пост перед отправкой. я всегда буду перечитывать пост перед отправкой.
                                                                                                +2
                                                                                                Когда я занимался разработкой standalone-приложений, время, затраченное на реализацию интерфейса составляло 80% общего рабочего времени. Мало-мальски нестандартные фичи компонентов, типа анимации прокрутки таблицы, или нестандартного скроллбара с превью прямо в полосе, оказывались адски сложными задачами, которые проще решать с нуля.
                                                                                                С переходом на веб все эти вещи перестали быть программными бутафориями, приобретя кристально ясную структуру, наглядность, возможность смены стилизации и отдельного подключения кода.

                                                                                                Поэтому можно с уверенностью сказать, что разработка интерфейса standalone более трудозатратна, чем разработка интерфейса web-приложения со схожим техзаданием.
                                                                                                  +1
                                                                                                  Я немного переиначу.

                                                                                                  Разработка интерфейса standalone приложение будет быстра только в том случае, если будут использоваться только стандартные контролы и поведение ОС.

                                                                                                  Но когда в процесс вмешивается дизайнер, а это сейчас частое явление, тогда построение интерфейса будет сводится к нагромождению хаков над этими стандартными контролами. Веб не содержит конролы, он гибкий, от этого на нём можно сделать всё.
                                                                                                    0
                                                                                                    Вот проблема, пожалуй, в том, что есть много ситуаций, где «стандартных серых контролов» хватило бы — но при этом с много более сложным поведением, чем предоставляет HTML — хоть с грида того же начиная и привязок к БД. Только инструментов нет соответствующих. Образно говоря, Delphi для Web нужно.

                                                                                                    В конце концов, тот корпоративный софт, который сейчас пишется на джаве/дотнете, а дальше неминуемо переберётся в браузеры — там же не красоты нужны, а удобный, быстро реализуемый функционал.
                                                                                                      0
                                                                                                      Главное сразу описать, чтобы этом набор элементов следовал оформлению ос, и не как иначе. Тогда можно будет говорить клиенту, тыкая в спецификацию, что розового котёнка на квладку не поместить. А если он хочет этого котёнка, за отдельную плату делаем свой кастомный контрол.
                                                                                                        0
                                                                                                        Вы про какую ОС? Которая стоит у вас, у представителя заказчика, у их клиентов?
                                                                                                          0
                                                                                                          ОС, в которой был открыт браузер. Или вы предлагаете абстрагироваться от ОС вообще, собрать вместе группу дизайнеров со всего света, которые нарисуют эти конролы, и которые вне зависимости от ОС и браузера будут одинаковыми?
                                                                                                            0
                                                                                                            Bingo.
                                                                                                              0
                                                                                                              Вообще не плохо было бы. Тем более, что браузеры используют, похоже, свои собственные контролы. По крайней мере как-то кастомизируют стандартные (глубоких исследований не проводил, но в трёх браузерах под одной осью контролы разные).
                                                                                                                0
                                                                                                                Под линуксом в KDE давно ещё помню, что инпуты были стилизированные под тёмную тему. От сюда и пошло золотое правило задавать инпутам не только цвет шрифта, а ещё и фон.

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

                                                                                                                  Не совсем так, все контролы прописаны в стандарте, и их поводение. А вот их вид — оформление нет.
                                                                                                                    0
                                                                                                                    Про поведение-то понятно, я как раз про внешний вид. С другой стороны понятно, что, например, в консольном или мобильном браузере так кнопку не нарисуешь, как в графическом.
                                                                                                                      0
                                                                                                                      Угу, она там просто будет не удобной.
                                                                                                                    0
                                                                                                                    Пожалуй самый известный пример такой библиотеки, которая все контролы рисует сама, это QT. Вторая — это библиотека Swing в Java. Конечно есть много других, но менее известных.
                                                                                                          +1
                                                                                                          Дополню.

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

                                                                                                          А уж развлечения на тему локализации — вообще превращались в нечто из области эзотерики. «Вот этот набор контролов есть только во французской версии», ага. И при поддержке 20ти языков — число формочек достигало невероятных цифр. И это — в Delphi, тогдашнем RAD нумер один.

                                                                                                          Это сейчас хорошо — UTF рулит, а в 90е нарисовать на формочке одновременно японский и китайский было возможно только в том случае, если мы написали свой отдельный edit box с блэкджеком, полностью саморисованный.

                                                                                                          Сравните с нынешней ситуацией — картинки подложить в случае если клиент некрофил ;-)
                                                                                                        +2
                                                                                                        Мне кажется нельзя сравнивать создание интерфейса на 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 сайтов уже приходит понимание процесса.
                                                                                                          +4
                                                                                                          Мне кажется, что вы не совсем понимаете автора. Он лишь утверждает что часто (и со временем все чаще) требуется сделать сайт (web-приложение) со сложным GUI, а HTML+JS+CSS для этого подходят плохо. Да, «HTML не язык программирования, это средство описания.». Замена требуется для создания GUI, а простые странички личного блога Васи можно делать все тем же HTML, он для этого и создавался.
                                                                                                            +1
                                                                                                            Понял, но напомните пожалуйста, чем ему не подходит, например extjs? В примерах есть подобные формы, как он показал(картинка из OS/2): http://www.sencha.com/products/extjs/examples/
                                                                                                              0
                                                                                                              Кстати да, хороший пример. На этом конструкторе просто и быстро построить веб приложение.
                                                                                                                0
                                                                                                                На сколько ч понимаю скорость работы такого пиложегия булдет оставлять желать лучьшего, особенно на мобильных платформах.
                                                                                                                  +2
                                                                                                                  Для начало нужно задаться вопросом «удобно ли будет на мобильной ос таким приложением пользоваться». Откройте любое мобильное приложение и сравните его с десктопным хотя бы, разница ощутимая.
                                                                                                                    +1
                                                                                                                    Производительность вполне на уровне, но переносить подобные интерфейсы в мобильный мир — глупо. У той же сенчи для этого есть другой продукт, с более «родными» элементами управления.
                                                                                                                      +2
                                                                                                                      OS/2 на мобильных платформах? Не, не слышал.
                                                                                                                      +1
                                                                                                                      Посмотрел на код простейших табов dev.sencha.com/deploy/ext-4.1.0-gpl/examples/tabs/tabs.html. Мнений, конечно, может быть много разных, но по моему никак простой эту смесь HTML+CSS+JS(+ExtJS) не назовёшь. Использовать подобные решения, конечно, проще чем писать их с нуля, но хуже чем если бы был специализированный язык проектирования интерфейсов (или поддержка подобных возможностей средствами HTML).
                                                                                                                        0
                                                                                                                        Действительно очень плохой пример и далеко не семантичен.
                                                                                                                          0
                                                                                                                          Вы просто прикиньте реализацию диалога настройки ОS/2 на С (даже не на С++), фото которого приведено в статье, и расслабьтесь. После этого extjs вам покажется праздником…
                                                                                                                            0
                                                                                                                            Не знаю, с полуосью только баловался, вспомнить могу вин3.1 или свою реализацию меню и мыши под ега/вга режимы в дос :) Но это когда ыбло, те же лет 20 назад, теперь хочется большего…
                                                                                                                              0
                                                                                                                              А в win3.1 это еще круче было. По документированию, простоте отладки и многим прочим разным вещам ext.js заруливает GUI интерфейсы напрочь. И это вообще говоря, очевидно. Как-никак C это язык системного программирования. А ext.js специализируется на интерфейсах…
                                                                                                                    +5
                                                                                                                    Согласен с утверждением «HTML для GUI подходит плохо!» первой и второй статей. Но сейчас тут опять будет простыня комментариев «не трожжж HTML, все хорошо» и «HTML какафка, закапываем». Проблему вы обозначили, а ничего не предложили, и все на протяжении двух статей именно этого и ждут.
                                                                                                                    Конечно одному написать спецификацию долгое и сложное занятие, но, хотя бы, опишите вашу розовую мечту в общих словах. Вдруг всем понравится, весь хабр соберется и напишет спецификацию, а там и первую реализацию.

                                                                                                                    Вот, например, в Enlightenment (И когда они WM допилят? E16 был очень клевой штукой.) есть библиотека Edje,
                                                                                                                    библиотека, отделяющая внешний вид от кода (оформление задаётся в виде загружаемого из файла шаблона). По своей сути Edje занимает нишу где-то между HTML+CSS и Flash/PSD/SVG. При помощи данной библиотеки можно сформировать насыщенный пользовательский интерфейс, снабжённый анимированными визуальными эффектами и поддерживающий динамическое оформление (внешний вид можно полностью поменять просто сменив EDJ-шаблон и не трогая код, при этом, в отличие от визуальных тем, порядок расположения элементов может быть произвольно изменён).

                                                                                                                    Вот это похоже на вашу розовую мечту? Может быть ее надо в браузер впилить и будет счастье?

                                                                                                                    Ждем описания чего вы хотите в более подробном виде, а не просто «звезды с дырками».
                                                                                                                      –1
                                                                                                                      Да ладно, пока гугл все устраивает. А вот когда перестанет устаивать (когда хром будет доминировать среди браузеров), они быстренько придумают более продвинутый язык разметки, и так же быстренько напишут спецификации. Ну а фф и остальным придется в ускоренном темпе это все реализовывать. И ни у кого не возникнет вопроса «а с чего это мы должны реализовывать фишки, придуманные гуглом?», им _придется_ это сделать, если они не хотят потерять свои доли на рынке браузеров.
                                                                                                                        +5
                                                                                                                        Если HTML = разметка, то для построения UI нужен другой язык. Тогда браузер превращается из приложения в конструктор приложений.

                                                                                                                        Выглядеть это может так. Заходим неким гипотетическим браузером FF15.UI или ChromUIm на сервер ui://mycoolapp.com/. С него грузится файл index.ui и файл index.html. В index.ui описан интерфейс приложения, все эти кнопочки, закладки и прочие свистелки-перделки. В index.html — только документ, который данное приложение должно отобразить. Внешний вид браузера меняется согласно тем настройкам, которые указаны в index.ui.
                                                                                                                          +1
                                                                                                                          Ну а что, было бы круто.
                                                                                                                            +7
                                                                                                                            Поздравляю, вы только что изобрели XUL.
                                                                                                                              0
                                                                                                                              правда чтоли? и где можно посмотреть на веб-приложение, которое скачивается с сайта и использует XUL?
                                                                                                                                –3
                                                                                                                                это был бы полный аллес капут с точки зрения безопасности и того, насколько пользовтель контролирует происходящее в его компе пока он ходят по непонятно каким сайтам.
                                                                                                                                  0
                                                                                                                                  Посмотрите, пожалуйста, в подразделе «XUL examples» в документации к Ample SDK.
                                                                                                                                    0
                                                                                                                                    Очень интересные примеры. По-моему, именно об этом и говорил топикстартер — html+css+js используются для трансляции с языка разметки интерфейса более высокого уровня.
                                                                                                                                    Я думаю, что Мозилла могла бы реализовать в своём браузере нативную поддержку XUL, раз уж они его продвигают.
                                                                                                                                      0
                                                                                                                                      Нативнее чем это уже реализовано реализовать не возможно. Потому что весь UI в их продуктах построен на XULRunner и XUL. Так что нативнее некуда.

                                                                                                                                      Если вопрос с загрузке XUL файлов на HTML страницы в вебе, то из-за кроссбраузерности в этом нет смысла. Но технически препятствий к этому нет: XUL-Enhanced Web Apps.
                                                                                                                                +2
                                                                                                                                XUL?
                                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                  +3
                                                                                                                                  Фанатам линуксовой консоли пробовали дать почитать? :)
                                                                                                                                  +2
                                                                                                                                  Меня поражает эта статья. Автор, ты хочешь палкой докторской колбасы забить гвозль и удивляешься, че так хреново получается. А я вам скажу: в жопу эту тяжелость и RICH клиенты всегда и всюду. Только вот че-то все в сторону минималзима идут. Наверное просто так. Эволюция не в ту сторону пошла :)

                                                                                                                                  Так что я бы наверное придержался мнения: никуда мигрировать ПОКА ЧТО не нужно. а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.

                                                                                                                                  HTML/CSS/JS выполняет свою работу. Когда перестанет справляться появится что-то более мощное, что заменит их. Да и уже сегодня есть туева куча JS фреймворков облегчающая жизнь, да и кое-что по-тяжелее (GWT, Vaadin).
                                                                                                                                    0
                                                                                                                                    а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.
                                                                                                                                    Но тогда придется поддерживать N нативных приложений. А веб-приложение одно на все платформы. Хотя с развитием управляемого кода и легкой кроссплатформенности этот разрыв будет нивелироваться.
                                                                                                                                      +2
                                                                                                                                      GWT, Vaadin, ExtJS, jQuery нынче позволяют сделать бОльшую часть свистелок-перделок без проблем.
                                                                                                                                    +17
                                                                                                                                    Web-программист высшей квалификации, если ему поручить сделать это без готовых toolkit-ов и не передирая из них чужой код, потратит пару дней на то, чтобы БЕЗГЛЮЧНО запрограммировать рисование квадрата с закруглёнными углами в актуальных версиях браузеров, оставив IE 6 за скобкой.

                                                                                                                                    По данным caniuse.com оценка получается куда более оптимистическою: «border-radius» работает (если учесть варианты с префиксами «-moz-» и «-webkit») во всех современных браузерах, кроме Эксплорера ранее девятой версии и Оперы ранее версии 10.5.

                                                                                                                                    Так что Web-программист высшей квалификации запишет код свойства «border-radius» (потратив на это не больше пары-тройки десятков секунд), затем подключит движок «prefix-free» для подстановки префиксов (или просто пару раз скопипастит свойство да прибавит к нему префиксы наизусть) и движок «CSS3 PIE» для обеспечения поддержки IE.

                                                                                                                                    И это даже нельзя будет назвать программированием — это будет декларативным описанием кривизны углов, не более того.

                                                                                                                                    Примечание: Web-программист высшей квалификации, который соглашается работать без использования готового чужого кода — это, уж извините, не Web-программист высшей квалификации, а оксюморон.

                                                                                                                                    А не то у Вас получается фантасмагорическое мучительство этого бедняги в дýхе «Процесса» Кафки. Что-то такое: «велосипедист мирового уровня, если его принудить проехать этот велотрек без чужих велосипедов и чужих инструментов и не передирая из них материалы и элементы конструкции, потратит денёк только на то, чтобы кремнёвым ножом освежевать быка и недельку на последующее дубление кож для мехов той кузни, где станет он долго и мучительно выковывать ободы своего велосипеда — и это мы ещё не приблизились к рассказу о том, сколько лет потратит он на горнорудное дело и нефтехимию».
                                                                                                                                      +2
                                                                                                                                      Подключать полифиллы — плохая практика, так как сильно замедляется загрузка страниц и производительность. 90% поддерживающих браузеров (по статистике в России) и так уже достаточно. Остальные 10% переживут.
                                                                                                                                        +7
                                                                                                                                        CSS3 PIE использует файл(ы) «.htc», так что никак не воздействует на загрузку и производительность страниц ни в одном браузере, кроме Internet Explorer.

                                                                                                                                        Так вот: если стоит именно задача любой ценою достичь закругления, то пользователи, которые не способны сменить Internet Explorer на другой (более понимающий CSS3) браузер самостоятельно — или убедить в этой необходимости своего системного администратора — должны страдать от замедления. Во-первых, этого никак не выйдет избегнуть в программном отношении (цели ж достигнуть как-то надо); во-вторых, страдания имеют и воспитательный эффект в отношении пользователей.
                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                            +4
                                                                                                                                            С клиентам сразу обсуждается этот вопрос, в денежном эквиваленте. Зачастую, ему подходит вариант, когда в ИЕ нету всех красот, зато есть хорошая производительность.
                                                                                                                                        0
                                                                                                                                        Ну да, за исключением IE 7 и 8, которые в сумме сейчас стоят у 17% пользователей.
                                                                                                                                        –2
                                                                                                                                        Чем вам не нравится ExtJS или Qooxdoo?
                                                                                                                                          +2
                                                                                                                                          Не знаю как Qooxdoo, а ExtJS жутко тормозит, не говоря уже о том что пропущенная запятая в js коде автоматом ломает весь интерфейс. Для сложных админок хорошо использовать, не более того.
                                                                                                                                            +4
                                                                                                                                            Скажите, а пропущенная скобка в xml разметке интерфейса к чему приводит? Используйте валидаторы, современные IDE (к примеру, webstorm, пропустить запятую в JSON`е будет почти невозможно).

                                                                                                                                            И что за железо и браузер у вас, что ExtJS тормозит? Используем в достаточно комплексных приложениях, где большие и сложные гриды (с различными кастомными рендерами ячеек), сложные формы, используем активно вкладки, т.е. «копирование» десктопных UI, именно проблем с производительностью не встречали (extjs 3.x).
                                                                                                                                              +2
                                                                                                                                              IDE использовать не хочется (каждому свое, мне нравится Sublime Text 2), но пропущенная запятая — бог с ней, сам принцип формирования интерфейса с помощью js кажется ущербным. А по поводу железа — лично у меня на i7 и последнем хроме вообще проблем нет, но если открыть это-же приложение на нетбуке с атомом или айфоне 3GS? Я вот пробовал, результаты не порадовали.
                                                                                                                                                +1
                                                                                                                                                О да! Производительность многих сайтов (Хабра, например) на хоть немного не современном железе падает существенно.
                                                                                                                                                  +1
                                                                                                                                                  Почему вам подход ExtJS кажется ущербным, ИМХО перенос интерфейса в описательный формат JSON очень удобен, сильно ли это для вас хуже, чем XML?

                                                                                                                                                  Я на нетбуке пробовал, из под убунту в хромиуме, вполне рабочая система, может не летает, но лагов в UI мешающих работе или, которые были бы действительно некомфортными — не встречал (опять же, говорю про 3тий extjs, в четвертом с гридами были проблемы). Про ваше приложение сложно сказать, возможно есть какие-то излишние вложения (панель в панель), от которых можно отказаться, смотреть надо конкретный, конечно, случай.

                                                                                                                                                  На айфоне с extjs в принципе проблемы, также как на андроиде, к примеру, пропадут скролы в комбобоксах и гридах. Да и подобные UI не предназначены для мобильных платформ с тач-интерфейсами. Иначе мы приходим к тому, что было на винмобайлах, но там хотя бы был стилус потоньше пальца:)
                                                                                                                                                    +2
                                                                                                                                                    Ничего против JSON самого по себе не имею. Но вот смотрите, показательный код из книги по 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, а о том, что он медленно работает.
                                                                                                                                                      –1
                                                                                                                                                      Вы в веб часто работаете, я имею ввиду часто делаете сайты? Вы часто верстаете дизайн, который нарисовал дизайнер? В отличии от ОС, где оформление является стандартом для этой ОС, в вебе нет стандарта оформления. Завтра дизайнер нарисует модальное окно с 4 бордерами, что вы будете делать со своим нативным контролом?
                                                                                                                                                        +1
                                                                                                                                                        Не совсем понимаю, каким образом отсутствие стандартов относится к странной логике ExtJS, ну да ладно. Я верстаю редко, но с html/css/js знаком далеко не первый день. Насчет отсутствия стандартов согласен, но разве это хорошо? Можно посмотреть на платформы где они есть (Mac), там плохие и некрасивые тулзы? Да даже Sparrow как пример юзерфрендли интерфейса взять, это же песня. Хотя… чем меньше стандартов и больше хаков, тем больше хлеба верстальщикам, верно?
                                                                                                                                                          0
                                                                                                                                                          Так, имеем дело с программером технического скалада ума. Вам я говорю не о тулзах а оформлении и о дизайне. Веб тем и отличается, что он индивидуале и разнообразен. Люди склоны к совершенствованию, люди склоны к творчеству, поиску новаторских идей. Если бы были такие жесткие правила как вы описываете, ещё бы долго у apple был интерфейс lisa. Люди хотят выделить свой сайт, придать ему фир. стиль, свой уникальный, веб полностью позволяет это делать. Это его фишка.
                                                                                                                                                            +2
                                                                                                                                                            Знаете, я (думаю как и многие) предпочел бы, чтобы 90% сайтов были удобными и привычными в использовании, пофиг на внешний вид — контент рулит. Не