?

Log in

No account? Create an account

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Пожаловаться Next Entry
День прогнозов
усы2
tonsky
Сегодня мы пытаемся кратко просуммировать, что творится с веб-разработкой в масштабах всего веба, и делаем прогнозы на то, как будет выглядеть веб-разработка через 2-3 года.

Яков-зачинатель (и лучше уже, наверное, не скажешь): http://jakobz.livejournal.com/236681.html
Ваня-продолжатель: http://gliv.livejournal.com/125078.html
UPD: дискуссия размазывается — комментарий Льва: http://lionet.livejournal.com/130032.html

А вот моя версия:

Крупные компании (G) пиарят свои решения: Dart и Angular, что им еще остается делать. Наверное, Dart рано или поздно можно будет использовать, но нужно понимать, что это примерно Джава. Что шаг вперед по сравнению с js, конечно, но всё равно. Принюхиваются к нему пока осторожно. То ли он слишком неамбициозный, то ли все его плюсы сводятся к стратегическим плюсам для самого Гугла, но что-то как то энтузиазма не видно.

Ситуация обстоит так, что если нужно сделать что-то небольшое, всё равно что брать. Вопрос только в том, что брать для большого, разрастающегося проекта. Мне кажется, что сейчас основной вопрос не в выборе языка, а в выборе фреймворка — как организовать код, зависимости, потоки событий, работу с DOM. Чем бы таким обложиться, чтобы не сойти с ума и не сильно воняло. Конкуренты — это старенький backbone, angular, ember, react.

Что касается языка, то писать на чистом JS я особого смысла не вижу. Ну то есть, вот прям вообще уже никаких аргументов за него не осталось. Как язык JS никогда ничем не привлекал. Производительность? Google Closure умеет advanced компиляцию и минификацию кода, в стандарт JS добавлен strict mode, всё это заточки на производительность, которые не работают с ручным кодом, только с кодом, который генерят компиляторы в JS. Отладка? Нормальные компиляторы уже умеют или скоро научатся делать source maps.

В ближайшие 2-3 года:
  • сообщество начнет наконец закапывать JS как язык и оставит его как VM.
  • Chrome введет несовместимые расширения и еще больше углубится в создание своего отдельного web.
  • Dart научится запускать в Chrome нативно, во всех остальных браузерах через js трансляцию.
  • Во фреймворки придет понимание что надо разделять DOM и JS как GPU и CPU и синхронизировать батч-обновления DOM с vsync, раз в кадр.
  • Вместо всех имеющихся фреймворков вырастет какой-то новый, корявый и избыточный, на который все пересядут
  • Фреймворки начнуть строиться вокруг push-state через web sockets по умолчанию.
  • Мы увидим очень много client-side rendering. Гуглу и Яндексу придется deal with it.
  • HTTP/2 примут, но Хром будет поддерживать свою несовместимую версию SPDY 5 и всё это останется уделом маргиналов, потому что трудно вспомнить как именно мы ставили и настраивали себе Апач 10 лет назад чтобы теперь эту красоту на нем включить.
  • ECMAScript Committee предложит следующее поколение стандарта, в котором они продолжат развивать язык и на который можно будет безопасно перейти через очередные 10 лет.
  • Microsoft объявит о внеплановом продлении поддержки IE 6 еще на 5 лет и объявит что поддержка свойства border-radius появится в IE 16.
  • Про single page applications: появится фреймворк/плагин к jQuery/мода перехватывать клики мышки по ссылкам и вместо перехода по ссылке грузить страницу средствами JS и анимировать как-то переход. Будут забывать менять url / html history или наоборот, менять его неправильно, коряво обрабатывать ошибки, js будет ломаться. Будет полный бананас. Мы получим юзабилити флеш-сайта под православным брендом html5.
  • Мобильные браузеры объявят что не будут поддерживать border-radius и box/text-shadow потому что и так ресурсов с гулькин нос. Наступит ренессанс эпохи нарезания картинок с тенюшкой на 9 частей. Мобильные браузеры объявят следом что не будут поддерживать полупрозрачность и смешивание, только булевые маски.
  • Разработчики забьют на адаптивный лайаут и начнут тупо делать отдельные мобильные версии.
  • Появится первый фреймворк, который рендерит сайт полностью внутри canvas.
  • В стандарт CSS 4 добавят переменные. Их не будет поддерживать ни один браузер, а IE 16 будет еще и падать, если где-то увидит переменную.
  • Помимо Майкрософтовской директивы <!--[if !IE]> Chrome введет директиву «if not IE». Изменение будет портировано во все остальные браузеры, включая мобильные, в течение недели.

А ваши версии?



Я бы предсказал еще расцвет asm.js когда туда придут игры.
Уже сейчас многие c++ игры компилятся в js на ура, и вполне себе производительно работают. Есть ряд проблем - типа того что там gcc 3.2 только, и нету нюансов типа фулскрина и т.п. - но все это технические вещи.

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

(Удалённый комментарий)
В ruby on rails такая штука есть называется turbolinks, и даже кажется по умолчанию включена https://github.com/rails/turbolinks

а ещё все эти single-page-applications затеряются в интернетах, т.к. поисковики не смогут их проиндексировать)

Очень просто ведь: при запросе прямого УРЛа - отдавать полную страницу, далее — перехватывать клики по линкам и подгружать страницы AJAX-ом, меняя УРЛ в браузере через History API. Так индексируется.

Js как ассемблер, думаю, не выстрелит в конечном итоге. Только в каком-то ограниченном виде.

> Появится первый фреймворк, который рендерит сайт полностью внутри canvas.

http://css.dzone.com/articles/zebra-html5-canvas-and-rich-ui

> В стандарт CSS 4 добавят переменные. Их не будет поддерживать ни один браузер, а IE 16 будет еще и падать, если где-то увидит переменную.

https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables

Ну, раз уж такая пьянка пошла: https://github.com/trevorlinton/webkit.js

Во фреймворки придет понимание что надо разделять DOM и JS как GPU и CPU и синхронизировать батч-обновления DOM с vsync, раз в кадр.
уже ж пришло. только это занятие не фреймворка, а для шаблонизатора. В MVC это "V" часть


Про single page applications: появится фреймворк/плагин к jQuery/мода перехватывать клики мышки по ссылкам и вместо перехода по ссылке грузить страницу средствами JS и анимировать как-то переход. Будут забывать менять url / html history или наоборот, менять его неправильно, коряво обрабатывать ошибки, js будет ломаться. ....
уже есть. называется tubrolinks https://github.com/rails/turbolinks


Мобильные браузеры объявят что не будут поддерживать border-radius и box/text-shadow потому что и так ресурсов с гулькин нос. Наступит ренессанс эпохи нарезания картинок с тенюшкой на 9 частей. Мобильные браузеры объявят следом что не будут...
скорее всего браузеры просто научаться кешировать, не перерисовывать, не вычислять то, что не нужно. Возможно появится техника со стороны браузера поддерживающая разметку, которая говорит "вот этот квадрат (блок) изолирован, его можно не перерисовывать", либо просто это будут делать с помощью iframe как тут http://fb.html5isready.com/?action=feed. Нарезать картинки уже не будут. Будут юзать старую библиотеку, которая сама нарезает, основываясь на css (декларативный подход, кстати) http://chikuyonok.ru/2009/02/rocon/


Появится первый фреймворк, который рендерит сайт полностью внутри canvas. https://github.com/trevorlinton/webkit.js

___

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

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

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

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

Наступит ядерная зима

> сказать что тебе надо в сотню раз проще, чем описать как этого достичь

Ньюфаг?

> backbone, angular, ember, react.
Всё говно, кроме react. React я пока что еще не щупал, нечего про него сказать. Зачем это всё нужно, если есть CoffeeScript и Spine.js? Почему все носятся с этим ёбаным AngularJS? Сейчас что, 99-й год? Уже опять модно писать код в аттрибуте onclick?
Судя по всему, нужно валивать из веба. С каждым годом увеличивается степень неадекватности веб-программистов :(

(Удалённый комментарий)
без темы (Анонимно) Развернуть
> Dart научится запускать в Chrome нативно, во всех остальных браузерах через js трансляцию.
"я может сейчас скажу какую-то глупость", но вроде бы тот билд хрома который идёт с Dart SDK уже исполняет дарт нативно. Т.е. оно всё уже есть, вопрос только в том чтобы выкатить это в мейнстримном хроме включеным по умолчанию.

Это примерно как NaCl/PNaCl который на моей памяти выкатили в Хроме ещё в версии 6 или 7, а после несколько раз то включали то выключали по умолчанию.

Они говорили, что там какая-то засада с управлением памятью, и просто так в хром DartVM гладко не вставляется. Работают над этим, недавно какой-то новый GC запилили вместо старого подсчета ссылок.

(Удалённый комментарий)
>Извините, зачем?

Потому что могут!
В этой индустрии, а в мире JS особенно, любое мыслимое извращение в некоторый момент оказывается реализовано.

> Dart научится запускать в Chrome нативно, во всех остальных браузерах через js трансляцию.
какбе коли Г будет создавать собственный веб, никто не мешает им в какой-то момент сделать несовместимую с js фичу. кто победит, и думать не хочу

(Анонимно)
Я ставлю на web components (http://habrahabr.ru/post/210058/)

Опасный он какой-то. Сейчас веб более-менее везде одинаковый, и это хорошо. Сделают Web Components и будет у всех свой ужас.

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

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

Появятся фреймворки на мейнтримных языках для SPA, чтобы хуяк-хуяк и в продакшен. Щас на мейнстримных языках такой, вроде, один (всякие GWT и ASP.NET не считаем же?)

Кнопку "назад" отменят как нерабочую в условиях бесконечных скроллов.

Она уже сейчас часто ведет себя хуй знает как непредсказуемо

> появится фреймворк/плагин к jQuery/мода перехватывать клики
> мышки по ссылкам

http://pjax.heroku.com/?

Со своей стороны надеюсь на
* Расцвет React и вообще идеи separate framework for views
* Backendless сервисы повсюду
* Убийцу JQueryUI с миллионом виджетов со вменяемым API и отделяемой reusable rendering logic
* Еще несколько солидных проектов на isomorhic javascript
* Вменяемая графическая среда для анимации на canvas
* Es.next expansion (generators, weak maps, destructuring), shims для несовместимых платформ
* better CSS compatibility для встроенных HTML элементов (input type="file", select вот это все)
* А еще лучше -- появление какого-нибудь безумного layouting фреймворка на Javascript вместо HTML/CSS, с pluggable реализациями разных медиа, компилирующего результат в DOM или canvas по выбору
* Web components тихо исчезнут и все про них забудут



Dart, TypeScript, Haxe и прочие компиляции в js врят ли станут популярными и будут использоватся только в форсящих это УГ компаниях.
Почему? Потому-что не привносят ничего революционного, а лиш костыли - кому нужна типизация для построения UI, кому сдалась перекомпиляция, когда интерпретатор почти сравним по скорости с машинным кодом?
А вот у КложурСкрипт есть шанс - потомучто идеология не далека от JS и при этом предоставляет самую восстребованную фичу - упрощение асинхронного программирования.

> сообщество начнет наконец закапывать JS как язык и оставит его как VM.
да не будет этого, потомучто не выгодно для отрасли. сейчас любая обезьяна способна делать казуальные веб аппликухи на html/css/js на готовых решениях и делать это быстро. а с развитием Web Components будет еще пиздаче.

Edited at 2014-01-25 08:29 (UTC)