Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
На мой взгляд это совсем не так.

1) Сам по себе Html5 ничем особо не отличается от предыдущих версий, да есть теги новые разметки типа <header><footer> и.т.п. позволяющие чуть улучшить понимание структуры страницы поисковым роботам ( не уверен что это сильно скажется на поисковых качествах, т.к. все равно в этих тегах будет размещаться разного рода информация и будет требоваться семантический анализ, чтобы отделять мух от котлет. Например кто-то в footer размещает Copyright, кто-то ссылки мелким шрифтом на страницы, кто-то контактную информацию ).
Наиболее значимым введением которое преображает html5 снаружи и делает его отличимым от предыдущих версий можно назвать — <canvas> позволяющий рисовать 2D и 3D объекты в брозуере. Но каким образом нам предлагается этим всем управлять — через JavaScript.

2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
Таким образом разработка на Javascript обойдется очень дорого.

3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.

4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

Итого мое мнение что с приходом Html5 произойдет небольшое смещение реализации части user-интерфейса в javascript, например красивые меню, интерактивные каталоги, сайты визитки, все что не требует сложной логики, основная логика будет реализовываться по прежнему в сервисах на удобных типизированных и объектно-ориентированных языках. Сложные графические вещи типа мультов, игр будут по прежнему делаться на Flash, Silverlight, возможно найдутся энтузиасты которые напишут сложные демки на javascript, но это врятли будет частой практикой в коммерческих проектах.

Здравствуйте, ankf, Вы писали:

A>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>На мой взгляд это совсем не так.

A>1) Сам по себе Html5 ничем особо не отличается от предыдущих версий, да есть теги новые разметки типа <header><footer> и.т.п. позволяющие чуть улучшить понимание структуры страницы поисковым роботам ( не уверен что это сильно скажется на поисковых качествах, т.к. все равно в этих тегах будет размещаться разного рода информация и будет требоваться семантический анализ, чтобы отделять мух от котлет. Например кто-то в footer размещает Copyright, кто-то ссылки мелким шрифтом на страницы, кто-то контактную информацию ).
A>Наиболее значимым введением которое преображает html5 снаружи и делает его отличимым от предыдущих версий можно назвать — <canvas> позволяющий рисовать 2D и 3D объекты в брозуере. Но каким образом нам предлагается этим всем управлять — через JavaScript.
HTML5 — это html+css+js. Это единый стандарт, описывающий много всего сразу.

A>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>Таким образом разработка на Javascript обойдется очень дорого.
По сравнению с другими динамическими языками — также. Кроме того существуют фреймворки, которые компилируют статически типизированный код в js.

A>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.

A>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

A>Итого мое мнение что с приходом Html5 произойдет небольшое смещение реализации части user-интерфейса в javascript, например красивые меню, интерактивные каталоги, сайты визитки, все что не требует сложной логики, основная логика будет реализовываться по прежнему в сервисах на удобных типизированных и объектно-ориентированных языках. Сложные графические вещи типа мультов, игр будут по прежнему делаться на Flash, Silverlight, возможно найдутся энтузиасты которые напишут сложные демки на javascript, но это врятли будет частой практикой в коммерческих проектах.

Здравствуйте, ankf, Вы писали:

a> Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.

Не слушай наркоманов.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ankf, Вы писали:

A>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>На мой взгляд это совсем не так.

A>>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>>Таким образом разработка на Javascript обойдется очень дорого.
G>По сравнению с другими динамическими языками — также. Кроме того существуют фреймворки, которые компилируют статически типизированный код в js.

В данном случае речь о сравнении с java,c#, убийцами которых некоторые называют html5, или actionscript используемый в flash, который отчасти динамичен, но в нем присутствуют нативные сущности для удобной работы с анимацией, в отличии от js.


A>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
G>Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.
css это рулится только отчасти, css можно повлиять на статичный размер/видимость объектов. Но мультиплатформа требует помимо размеров еще и интерактивность с пользователем держать на уровне , одно дело когда одна кнопка на девайсе, другое дело когда кнопок нет, но есть джойстик и т.п..
Также допустим анимация , что с того что в css размер объекта стал меньше, анимация на разном разрешении требует изменения ее логики, например на маленьком экране нужно 5 кадров сделать, на большом 20. не всегда можно пропорционально уменьшать объекты и использовать только относительные координаты.


A>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
G>Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

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

Здравствуйте, ankf, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, ankf, Вы писали:

A>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>На мой взгляд это совсем не так.

A>>>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>>>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>>>Таким образом разработка на Javascript обойдется очень дорого.
G>>По сравнению с другими динамическими языками — также. Кроме того существуют фреймворки, которые компилируют статически типизированный код в js.

A>В данном случае речь о сравнении с java,c#, убийцами которых некоторые называют html5, или actionscript используемый в flash, который отчасти динамичен, но в нем присутствуют нативные сущности для удобной работы с анимацией, в отличии от js.

Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может. А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.


A>>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
G>>Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.
A>css это рулится только отчасти, css можно повлиять на статичный размер/видимость объектов. Но мультиплатформа требует помимо размеров еще и интерактивность с пользователем держать на уровне , одно дело когда одна кнопка на девайсе, другое дело когда кнопок нет, но есть джойстик и т.п..
A>Также допустим анимация , что с того что в css размер объекта стал меньше, анимация на разном разрешении требует изменения ее логики, например на маленьком экране нужно 5 кадров сделать, на большом 20. не всегда можно пропорционально уменьшать объекты и использовать только относительные координаты.

Это вопрос дизайниа. Давно устоявшийся подход — подсовывать разным клиентам разные представления.


A>>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
G>>Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

A>Про то и речь что в проектах где недопустимо все выкладывать в открытый код, будут по прежнему держать на сервере, что в свою очередь ничем не меняет существующий подход. Врятли кто-то серверный код будет делать на javascript, когда более удобную с точки зрения разработки/безопасности версию можно сделать на том же .net, java.
Именно, а ты что ожидал? Что придет html5 и сразу все на нем писать будут? Пока это только интерфейс (client-side) и ничего другого не предвидится.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ankf, Вы писали:

A>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, ankf, Вы писали:

A>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>На мой взгляд это совсем не так.


G>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
G>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?

Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas. А собственно все описание логики работы этого самого Canvas выносится в javascript.
Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет



A>>>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
G>>>Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.
A>>css это рулится только отчасти, css можно повлиять на статичный размер/видимость объектов. Но мультиплатформа требует помимо размеров еще и интерактивность с пользователем держать на уровне , одно дело когда одна кнопка на девайсе, другое дело когда кнопок нет, но есть джойстик и т.п..
A>>Также допустим анимация , что с того что в css размер объекта стал меньше, анимация на разном разрешении требует изменения ее логики, например на маленьком экране нужно 5 кадров сделать, на большом 20. не всегда можно пропорционально уменьшать объекты и использовать только относительные координаты.

G>Это вопрос дизайниа. Давно устоявшийся подход — подсовывать разным клиентам разные представления.
Не только дизайн ( Layout ), логика ввода-вывода зависит от особенностей устройства.



A>>>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
G>>>Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

A>>Про то и речь что в проектах где недопустимо все выкладывать в открытый код, будут по прежнему держать на сервере, что в свою очередь ничем не меняет существующий подход. Врятли кто-то серверный код будет делать на javascript, когда более удобную с точки зрения разработки/безопасности версию можно сделать на том же .net, java.
G>Именно, а ты что ожидал? Что придет html5 и сразу все на нем писать будут? Пока это только интерфейс (client-side) и ничего другого не предвидится.
Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

Здравствуйте, ankf, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, ankf, Вы писали:

A>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, ankf, Вы писали:

A>>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>>На мой взгляд это совсем не так.


G>>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
A>Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
Так это твое утверждение. Обычно говорят о замене технологий web client side на HTML5.

G>>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

A>Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?
http://ru.wikipedia.org/wiki/Canvas_(HTML)
http://chrome.angrybirds.com/

A>Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
A>для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas.
Серьезные графические вещи во Flash и Silverlight также делаются кодом.

А собственно все описание логики работы этого самого Canvas выносится в javascript.
A>Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
A>Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет
Пример с линией неинтересен. Давай лучше спрайты и эффекты. Упс.. код и там и там...



A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ankf, Вы писали:

A>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, ankf, Вы писали:

A>>>>Здравствуйте, gandjustas, Вы писали:

G>>>>>Здравствуйте, ankf, Вы писали:

A>>>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>>>На мой взгляд это совсем не так.


G>>>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
A>>Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
G>Так это твое утверждение. Обычно говорят о замене технологий web client side на HTML5.

G>>>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

A>>Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?
G>http://ru.wikipedia.org/wiki/Canvas_(HTML)
И ? Приведен пример как на javascript рисуется эллипс. Что собственно никак не объясняет чем же javascript имеет преимущество перед c#,java,actionscript особенно в сложных приложениях.

G>http://chrome.angrybirds.com/
Это вообще шикарны пример, который в javascripte создает флеш объект и его подгружает.
Если отключить flash то не работает


A>>Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
A>>для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas.
G>Серьезные графические вещи во Flash и Silverlight также делаются кодом.
Да только мы возвращаемся к тому что я объяснял в 1м своем посте в п.2) Silverlight это код на .net , типизированный язык с ООП который намного удобнее для разработки такого рода вещей.


G>А собственно все описание логики работы этого самого Canvas выносится в javascript.
A>>Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
A>>Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет
G>Пример с линией неинтересен. Давай лучше спрайты и эффекты. Упс.. код и там и там...

Я к тому и вел что код надо писать, но код на c# и т.д. , особенно где требуется не только линию рисовать, а делать гибкую логику удобнее типизированные ООП языки.


A>>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

G>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.
Скорее наоборот, у SL и Flash есть хорошее и важное преимущество — язык на котором графика описывается.
Поэтому Html5 будет использоваться только на уровне менюшек собственно где и сейчас js работает. Только будет чуть красивше.

Здравствуйте, gandjustas, Вы писали:

g> A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

g> Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.

Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек

Здравствуйте, ankf, Вы писали:

A>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, ankf, Вы писали:

A>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

KV>А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.

Проблема не только в открытости исходников, а еще в том что именно эти исходники исполняются в runtime и легко поддаются отладке, а также подмене.


1) допустим у вас есть некий алгоритм, а может целый движок или облако, который представляет сам по себе коммерческую ценность , когда он находится на server-side вы только передаете входные данные, получаете результат. В случае открытия исходников этого алгоримта ( например перенос на client-side в виде javascript ) его могут легко позаимствовать.

2) различные инъекции, например есть код валидации входных параметров на server-side, в случае когда он переезжает на client-side в java-script, то в приницпе можно вмешаться в работу javascript отладчиком и изменить значения параметров/переменных на невалидные приводящие к некоторой критичной ошибке.
Например сумма платежа ограничивается 15 000 рублей. Если такие проверки будут в javascript то их можно будет обойти и провести транзакцию на большую сумму. Или бизнес-логика , например что сначала нужно проверить валидность в одном сервисе, потом в другом. Если эта цепочка проверок будет в js , то опять же можно обойти.

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

Здравствуйте, ankf, Вы писали:

При оценке рисков информационной безопасности распределенных систем (к классу которых относятся и веб-приложения) актуальные угрозы выявляются на основании данных о точках пересечения потоками данных границ доверия компонентов системы. Для веб-приложений одной из таких точек является TCP-порт железки на серверной стороне, непосредственно торчащей наружу, в интернет. В протоколе HTTP не предусмотрены средства обеспечения целостности и конфиденциальности передаваемых по нему данных...

KV>>А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.
A>Проблема не только в открытости исходников, а еще в том что именно эти исходники исполняются в runtime и легко поддаются отладке, а также подмене.

...т.о., в веб-приложениях, клиентская сторона целиком и полностью находится в недоверенной зоне, соответственно контрмера угрозе подмены данных ("Data tampering", в простонародье. Входит в модель угроз STRIDE) должна быть реализована внутри границы доверия, т.е. на сервере. Иными словами, совершенно не важно, что там на клиенте поддается отладке, а что нет. Сервер должен ожидать что буквально в каждом HTTP-запросе ему приходят данные, которым он не может доверять без дополнительных проверок. За границами доверия подмене подвержен сам клиент, целиком и полностью. И, в свете этого, детали его реализации с т.з. данной угрозы, не имеют значения.

A>1) допустим у вас есть некий алгоритм, а может целый движок или облако, который представляет сам по себе коммерческую ценность , когда он находится на server-side вы только передаете входные данные, получаете результат. В случае открытия исходников этого алгоримта ( например перенос на client-side в виде javascript ) его могут легко позаимствовать.

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

A>2) различные инъекции, например есть код валидации входных параметров на server-side, в случае когда он переезжает на client-side в java-script, то в приницпе можно вмешаться в работу javascript отладчиком и изменить значения параметров/переменных на невалидные приводящие к некоторой критичной ошибке.
A>Например сумма платежа ограничивается 15 000 рублей. Если такие проверки будут в javascript то их можно будет обойти и провести транзакцию на большую сумму. Или бизнес-логика , например что сначала нужно проверить валидность в одном сервисе, потом в другом. Если эта цепочка проверок будет в js , то опять же можно обойти.

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

A>3) Использование сервисов как внешних, так и своих, как правило сервисы требуют параметры для авторизации транзакции , тот же логин пароль, зачастую в открытом виде передается, в случае server-side это не проблема,

Передача пароля в открытом виде по HTTP-каналу всегда является проблемой, вне зависимости от случая client-side или server-side. И всегда является уязвимостью, причем весьма серьезной.

A>если будет в открытую на клиенте обращение к некому сервису с передачей параметров авторизации то понятно что ими легко можно воспользоваться.

Если оно будет в открытую с сервера на какой-нибудь внешний сервис, воспользоваться им атакующему будет не особо сложнее.

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

Здравствуйте, gandjustas, Вы писали:

G>HTML5 — это html+css+js. Это единый стандарт, описывающий много всего сразу.

Ну нет конечно. html5 это собственно html + набор runtime features exposed to JS (local storage, web sockets, etc).
css вообще это работа отдельной WG. С HTML5 никак не связана.
js это вообще даже не W3C детище. W3 комитет к js не имеет никакого отношения вообще.

Здравствуйте, ankf, Вы писали:

A>По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением.

Ну нет конечно. JS имеет две фундаментальные коллекции: array<any> и map<any,any>.

Здравствуйте, ankf, Вы писали:

Безотносительно же безопасности, я считаю, что инструмент должен подбираться под задачу и условия, в которых она решается, а не наоборот. И говорить о том, что HTML5 однозначно и всегда кака, не способная заменить Flash и SL везде и во всем, не очень корректно. Например, на ios-based устройствах нет ни флеша не силверлайта, в отличии от. Проблема же полиморфизма в суровых условиях объектов на прототипах (кстати, а почему проблема-то?), может быть решена генерацией клиентских сценариев на стороне сервера под нужную железку, приславшуюю HTTP-запрос. Причем эта генерация может осуществляться на базе кода на вполне себе статически-типизированном языке. Именно этот подход планируется реализовать в Nemerle.WUI и именно он реализован в GWT, где народ пишет себе на Java и Python и даже не вникает, в общем случае, как именно этот код будет преобразован в клиентский js.

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

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, ankf, Вы писали:

KV>При оценке рисков информационной безопасности распределенных систем (к классу которых относятся и веб-приложения) актуальные угрозы выявляются на основании данных о точках пересечения потоками данных границ доверия компонентов системы. Для веб-приложений одной из таких точек является TCP-порт железки на серверной стороне, непосредственно торчащей наружу, в интернет. В протоколе HTTP не предусмотрены средства обеспечения целостности и конфиденциальности передаваемых по нему данных...

KV>>>А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.
A>>Проблема не только в открытости исходников, а еще в том что именно эти исходники исполняются в runtime и легко поддаются отладке, а также подмене.

KV>...т.о., в веб-приложениях, клиентская сторона целиком и полностью находится в недоверенной зоне, соответственно контрмера угрозе подмены данных ("Data tampering", в простонародье. Входит в модель угроз STRIDE) должна быть реализована внутри границы доверия, т.е. на сервере. Иными словами, совершенно не важно, что там на клиенте поддается отладке, а что нет. Сервер должен ожидать что буквально в каждом HTTP-запросе ему приходят данные, которым он не может доверять без дополнительных проверок. За границами доверия подмене подвержен сам клиент, целиком и полностью. И, в свете этого, детали его реализации с т.з. данной угрозы, не имеют значения.

A>>1) допустим у вас есть некий алгоритм, а может целый движок или облако, который представляет сам по себе коммерческую ценность , когда он находится на server-side вы только передаете входные данные, получаете результат. В случае открытия исходников этого алгоримта ( например перенос на client-side в виде javascript ) его могут легко позаимствовать.

KV>Это не имеет к информационной безопасности никакого отношения. Если есть желание поспорить, прошу озвучить конкретную информационную угрозу (в терминах любой существующей модели), которая реализуется в данном сценарии.

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

KV>Если оно будет в открытую с сервера на какой-нибудь внешний сервис, воспользоваться им атакующему будет не особо сложнее.


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

Если спуститься на землю, то ИБ вводится с целью сокращения убытков компании и целью является недопущение утраты/копирования/изменения данных которые могут привести к убыткам.
При этом нужно учитывать следующее
1) целесообразность, да с точки зрения теории вынос кода на клиента в недоверенную зону особо не отличается что на javascript, что на flash/silverlight, но на практике стоимость взлома javascript и бинарников отличается, поэтому с точки зрения коммерции иногда не допустимо размещать код в javascript, но допускается в бинарном виде.
Например клиент-банк приложение отдается клиенту, но вот исходники этого клиент-банка вам врятли отдадут или предложат клиент-банк в виде javascript, хотя как продукт они коммерческой ценности не имеют, т.к. заточены на конкретный банк и использоваться могут только с этим банком, даже было бы банку
выгодно если ошибки могли исправлять сами клиенты, но это не допустимо именно из-за риска что стоимость взлома и подмены клиента в таком виде существенно снижается.

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

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, ankf, Вы писали:

KV>Безотносительно же безопасности, я считаю, что инструмент должен подбираться под задачу и условия, в которых она решается, а не наоборот. И говорить о том, что HTML5 однозначно и всегда кака, не способная заменить Flash и SL везде и во всем, не очень корректно.

Да собственно никто и не говорит что HTML5 не найдет своего применения, конечно когда нужно нарисовать "летающие снежинки", показать видео или прожужжать чтонибудь ( это условно сложность задачи ) то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.
Поэтому как я уже писал в начальном посте HTML5 войдет в жизнь но не так кардинально как об этом некоторые переживают.

Здравствуйте, ankf, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, ankf, Вы писали:

A>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, ankf, Вы писали:

A>>>>>Здравствуйте, gandjustas, Вы писали:

G>>>>>>Здравствуйте, ankf, Вы писали:

A>>>>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>>>>На мой взгляд это совсем не так.


G>>>>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
A>>>Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
G>>Так это твое утверждение. Обычно говорят о замене технологий web client side на HTML5.

G>>>>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

A>>>Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?
G>>http://ru.wikipedia.org/wiki/Canvas_(HTML)
A>И ? Приведен пример как на javascript рисуется эллипс.
3 минуты в гугле и... http://www.html5canvastutorials.com/advanced/html5-canvas-ovals/

A>Что собственно никак не объясняет чем же javascript имеет преимущество перед c#,java,actionscript особенно в сложных приложениях.
Да никакого не имеет кроме поддержки со стороны производителей браузеров.

G>>http://chrome.angrybirds.com/
A>Это вообще шикарны пример, который в javascripte создает флеш объект и его подгружает.
А developertools говорит что там canvas. Я ему как-то больше доверяю

A>Если отключить flash то не работает
flash там для звуков, это пока "больное место" html5 и js вообще.

A>>>Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
A>>>для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas.
G>>Серьезные графические вещи во Flash и Silverlight также делаются кодом.
A>Да только мы возвращаемся к тому что я объяснял в 1м своем посте в п.2) Silverlight это код на .net , типизированный язык с ООП который намного удобнее для разработки такого рода вещей.
Угу, только для него нужен silverlight plugin, который например на мобильных устройствах отсутствует, как и flash в большинстве своем.


G>>А собственно все описание логики работы этого самого Canvas выносится в javascript.
A>>>Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
A>>>Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет
G>>Пример с линией неинтересен. Давай лучше спрайты и эффекты. Упс.. код и там и там...
A>Я к тому и вел что код надо писать, но код на c# и т.д. , особенно где требуется не только линию рисовать, а делать гибкую логику удобнее типизированные ООП языки.
См выше.


A>>>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

G>>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.
A>Скорее наоборот, у SL и Flash есть хорошее и важное преимущество — язык на котором графика описывается.
Это какой? сложную спрайтовую или 3d графику с анимацией в любом случае надо кодом делать. В случае SL еще понятно, там C# типизированный, хоть какое-то преимущество, а flash вообще сосет. html5 и сразу все везде работает, в том числе на мобильных устройствах (по крайней мере к этому все идет).

A>Поэтому Html5 будет использоваться только на уровне менюшек собственно где и сейчас js работает. Только будет чуть красивше.
Угу, и на уровне игрушек типа angrybirds. Только упс... это сейчас самая популярная игра.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

g>> A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

g>> Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.

H>Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек

Она "единственная" только для PC. А сейчас набирает обороты мобильный веб, куда пока ни один, ни второй не влез.