Стандарты есть везде. И если говорить про вэб то я уж лучше буду использовать его, потому что он популярнее, что говорит о том что обратная совместимость там будет поддерживаться достаточное время(пример - переход на es6)

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

IE deprecated и почти всем заказчикам нахрен не нужен, а остальные прекрасно работают и так.

З.Ы. Если не работаешь с гос. заказом =)

в общем, пока вижу только аргументы явно неопытного в вебовых технологиях человека.

в общем, пока вижу только аргументы явно неопытного в вебовых технологиях человека.

+1

З.Ы. Если не работаешь с гос. заказом =)

в том числе поэтому я и сказал "почти всем", а не "всем"

O_O хорошая теория, но нет )

Т.е. вы реально считаете, что в браузере можно сделать все?)

Т.е. вы реально считаете, что в браузере можно сделать все?)

нет, кофе сварить в нем нельзя например

нет, кофе сварить в нем нельзя например

HTTP/1.1 418 I'm a teapot

но если говорить про UI для клиент-серверных приложений то все там делается QT и GTK закопать

но если говорить про UI для клиент-серверных приложений то все там делается QT и GTK закопать

все бы вам закопать, однако. Вертикальное выравнивание уже завезли? А центрирование div'а внутри другого div'а?

и вообще, как до redux ничего могло не быть, если первый коммит в redux был в конце мая 2015ого, а куча CQRS либ еще в 2014 были?

все бы вам закопать, однако. Вертикальное выравнивание уже завезли? А центрирование div'а внутри другого div'а?

дохера времени назад.

ясно. о веб-технологиях Вам, коллега, не известно почти что ничего. из этого делаем вывод, что разговор неконструктивен от слова совсем.

Поверь, не все можно сделать в браузере. Про "не слишком большие потери производительности" - забавно, улыбнуло. Про скорость разработки - еще веселее. Вы реально верите, что написать гуй для простенькой софтинки на Qt/QML или GTK - это дольше, чем сваять браузерную весию? Секрет популярности вообще не в скорости разработки. Секрет исключительно в стоимости (веб-дизайнер относительно недорог. Плюсом - единожды написанный сайт всегда можно упаковать в пакет и выдать это за десктопное приложение).

Я понимаю что далеко не всё возможно с использованием браузера, но такие большие возможности не нужны широкому кругу разработчиков. Если человеку нужно больше возможностей для разработки его интерфейса то это повод реализовать свои задумки с использованием более низкоуровневой библиотеки(не используя для этого браузер). Такие задачи будут, но люди сталкиваются с ними не так часто. Насчет gui на qt, qml, gtk и прочих - это всё конечно здорово, но не все языки имеют в своём арсенале биндинги к этим библиотекам. Эти библиотеки сложнее тогоже react+material-ui по понятным причинам. Документация к этим библиотекам объёмна и порой требует очень детального изучения для понимания. Тестировать этот код не совсем удобно. Про скорость - скорее всего интерфейс это не основной "тормоз" в системе. Скорость с которой работают веб интерфейсы на сегодняшний день(на современном железе) довольно приемлема и не ставит лично меня перед выбором. Предполагаю что с течением времени ситуация будет только улучшаться.

дохера времени назад.

центрирование через маргин авто или уже завезли по-человечески и я все пропустил?

центрирование через маргин авто или уже завезли по-человечески и я все пропустил?

ты все пропустил.

центрирование через маргин авто или уже завезли по-человечески и я все пропустил?

вот и я про человечные методы... а мне все про "css умеет рисовать в 3D"

имхо, фронт уныл и максимально рутинен. почти все его задачи - это формошлепство. любая интересная фича с точки зрения продукта - это разнообразыне телодвижения на беке, и уг на фронте. на беке решаются задачи как хранить данные, искать их, держать нагрузку, да дохера всего, а что на фронте? там в большистве случаев только две задачаи: 1. иди и рисуй json-ответ от севреа, 2. отправь json, с тем как потыкался юзер в интерфейсе. и большиство этих задач вполне успешно решали предсвителями MV-семейств, типа ангуляра. по-моему, народу стало просто скучно - ты ограничен рамками браузера, у тебя на выбор всего один язык, 90% работы это просто отображение данных... ну и начали городить всякие транспайлеры, новые системы сборки, имуутабельность с функциональщиной, типа у нас тут уан дирекшн дата флоу, а не херня какая-нибудь

Ага, платформа-то одна... Только вот есть IE, Chrome, Opera, Firefox и прочие... Все с "местечковыми причудами"

На сегодняшний день отличия уже не сильно существенны :)

все бы вам закопать, однако. Вертикальное выравнивание уже завезли? А центрирование div'а внутри другого div'а?

left: 50%; transform: transitionX(-50%);^ тип того Вертикальное тоже так можно сделать емнип

имхо, фронт уныл и максимально рутинен. почти все его задачи - это формошлепство. любая интересная фича с точки зрения продукта - это разнообразыне телодвижения на беке, и уг на фронте. на беке решаются задачи как хранить данные, искать их, держать нагрузку, да дохера всего, а что на фронте? там в большистве случаев только две задачаи: 1. иди и рисуй json-ответ от севреа, 2. отправь json, с тем как потыкался юзер в интерфейсе. и большиство этих задач вполне успешно решали предсвителями MV-семейств, типа ангуляра. по-моему, народу стало просто скучно - ты ограничен рамками браузера, у тебя на выбор всего один язык, 90% работы это просто отображение данных... ну и начали городить всякие транспайлеры, новые системы сборки, имуутабельность с функциональщиной, типа у нас тут уан дирекшн дата флоу, а не херня какая-нибудь

ты SPA полноценный делал?

left: 50%; transform: transitionX(-50%);^ тип того Вертикальное тоже так можно сделать емнип

фу.

left: 50%; transform: transitionX(-50%);^ тип того Вертикальное тоже так можно сделать емнип

вообще display: flex

вообще display: flex

вот-вот.

ты SPA полноценный делал?

делал

фу.

Ну я для примера :)

Ну я для примера :)

не надо такое для примера

Про flex не много знаю

имхо, фронт уныл и максимально рутинен. почти все его задачи - это формошлепство. любая интересная фича с точки зрения продукта - это разнообразыне телодвижения на беке, и уг на фронте. на беке решаются задачи как хранить данные, искать их, держать нагрузку, да дохера всего, а что на фронте? там в большистве случаев только две задачаи: 1. иди и рисуй json-ответ от севреа, 2. отправь json, с тем как потыкался юзер в интерфейсе. и большиство этих задач вполне успешно решали предсвителями MV-семейств, типа ангуляра. по-моему, народу стало просто скучно - ты ограничен рамками браузера, у тебя на выбор всего один язык, 90% работы это просто отображение данных... ну и начали городить всякие транспайлеры, новые системы сборки, имуутабельность с функциональщиной, типа у нас тут уан дирекшн дата флоу, а не херня какая-нибудь

еще одна клевая идея, но нет )

делал

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

имхо, бек уныл и максимально рутинен. почти все его задачи - это формошлепство. любая интересная фича с точки зрения продукта - это разнообразыне телодвижения на фронте, и уг на беке. на фронте решаются задачи как отобразить данные, искать их, обеспечивать ввод, да дохера всего, а что на беке? там в большистве случаев только две задачаи: 1. найди в базе данные и преврати их в json, 2. прими json от пользователя и сохрани их в базу. и большиство этих задач вполне успешно решали предсвителями CGI-семейств, типа php. по-моему, народу стало просто скучно - ты ограничен рамками апача, у тебя на выбор всего один язык, 90% работы это просто запросы к БД... ну и начали городить всякие фреймворки, новые языки, имуутабельность с функциональщиной, типа у нас тут уан дирекшн дата флоу, а не херня какая-нибудь

имхо, бек уныл и максимально рутинен. почти все его задачи - это формошлепство. любая интересная фича с точки зрения продукта - это разнообразыне телодвижения на фронте, и уг на беке. на фронте решаются задачи как отобразить данные, искать их, обеспечивать ввод, да дохера всего, а что на беке? там в большистве случаев только две задачаи: 1. найди в базе данные и преврати их в json, 2. прими json от пользователя и сохрани их в базу. и большиство этих задач вполне успешно решали предсвителями CGI-семейств, типа php. по-моему, народу стало просто скучно - ты ограничен рамками апача, у тебя на выбор всего один язык, 90% работы это просто запросы к БД... ну и начали городить всякие фреймворки, новые языки, имуутабельность с функциональщиной, типа у нас тут уан дирекшн дата флоу, а не херня какая-нибудь

тоолсто)

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

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

угу. вся интересная логика на бэке

имхо, бек уныл и максимально рутинен. почти все его задачи - это формошлепство. любая интересная фича с точки зрения продукта - это разнообразыне телодвижения на фронте, и уг на беке. на фронте решаются задачи как отобразить данные, искать их, обеспечивать ввод, да дохера всего, а что на беке? там в большистве случаев только две задачаи: 1. найди в базе данные и преврати их в json, 2. прими json от пользователя и сохрани их в базу. и большиство этих задач вполне успешно решали предсвителями CGI-семейств, типа php. по-моему, народу стало просто скучно - ты ограничен рамками апача, у тебя на выбор всего один язык, 90% работы это просто запросы к БД... ну и начали городить всякие фреймворки, новые языки, имуутабельность с функциональщиной, типа у нас тут уан дирекшн дата флоу, а не херня какая-нибудь

А потом появляется задача "напиши базу" :)

фронт - голимая отрисовка

фронт - голимая отрисовка

+100500, спа у тебя, не спа... один хер. разница лишь в твоем способе рисования

И фронт по сравнению с ней выглядит рутинной формотыкалкой :)

огромное количество функциональности бэкенда можно перенести на SPA и удешевить обслуживание бэка.

фронт - голимая отрисовка

Хм, попробуй нарисовать wisywig для email-рассылки, критерии просты - адаптивность, удобство, понятность ;)

Хм, попробуй нарисовать wisywig для email-рассылки, критерии просты - адаптивность, удобство, понятность ;)

Звучит как задача для ux дизайнера

Фронт ещё и про интерфейс, анимации. А это уже область большая и интересная

Хм, попробуй нарисовать wisywig для email-рассылки, критерии просты - адаптивность, удобство, понятность ;)

плюсую.

огромное количество функциональности бэкенда можно перенести на SPA и удешевить обслуживание бэка.

огромное количество функциональности фронтэнда можно перенести на бэк и удешевить обслуживание фронта

огромное количество функциональности бэкенда можно перенести на SPA и удешевить обслуживание бэка.

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

Звучит как задача для ux дизайнера

Ну, реализовать само собой ещё)

огромное количество функциональности фронтэнда можно перенести на бэк и удешевить обслуживание фронта

угу. и платить больше за серверы. гениально.

В которой кодинг монотонный и рутинной, а вся проблема в слове "удобно"

Ну, реализовать само собой ещё)

Реализация как раз уныла и монотонная.

угу. и платить больше за серверы. гениально.

это имеет значение когда у тебя счёт серверов рендерящих шаблоны идёт хотябы на десятки. тоесть в россии таких контор штук 50 максимум

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

я и сам фулстек, плюс коллега — из не-"сравнительно" дорогих фронтендеров.

Реализация как раз уныла и монотонная.

А пацаны то и не знали, оказывается из юзеровского ввода так легко сделать адаптивную верстку

Что аж рутина

А пацаны то и не знали, оказывается из юзеровского ввода так легко сделать адаптивную верстку

ну. и при этом совместимую со всеми актуальными почтовыми клиентами.

ну. и при этом совместимую со всеми актуальными почтовыми клиентами.

А это само собой разумеющееся

и чтобы видео на фон с фоллбэком вешалось

Я понимаю что далеко не всё возможно с использованием браузера, но такие большие возможности не нужны широкому кругу разработчиков. Если человеку нужно больше возможностей для разработки его интерфейса то это повод реализовать свои задумки с использованием более низкоуровневой библиотеки(не используя для этого браузер). Такие задачи будут, но люди сталкиваются с ними не так часто. Насчет gui на qt, qml, gtk и прочих - это всё конечно здорово, но не все языки имеют в своём арсенале биндинги к этим библиотекам. Эти библиотеки сложнее тогоже react+material-ui по понятным причинам. Документация к этим библиотекам объёмна и порой требует очень детального изучения для понимания. Тестировать этот код не совсем удобно. Про скорость - скорее всего интерфейс это не основной "тормоз" в системе. Скорость с которой работают веб интерфейсы на сегодняшний день(на современном железе) довольно приемлема и не ставит лично меня перед выбором. Предполагаю что с течением времени ситуация будет только улучшаться.

Тут есть несколько нюансов: 1. Я говорю, что весь вопрос в стоимости разработки, мне рассказывают про "прогрессивность технологии" и "обширные перспективы". Имхо, весь хайп базируется на 3 вещах: наличии хреновой уймы недорогих специалистов разной степени профессионализма, возможности переноса веб<->десктоп (т.е. отсутствие необходимости "переписывать и поддерживать"), обратная совместимость. 2. Внутри у всей этой хрени, как ни оборачивай все это в красиывые фреймворки, один фиг html+css+js, а проблемы с этим есть. HTML - язык разметки ГИПЕРТЕКСТА, все "интерактивные" части привязаны к нему сильно сбоку и скотчем. 3. Собственно, для распространенных клиент-серверных вещей оно нормально. Другое дело, что часто слышатся призывы "похоронить" всяческие "низкоуровневые библиотеки". На выходе имеем десктопные приложения из 1 кнопки, упакованные в отдельный браузер... 4. Причина энтузиазма во всей этой ситуации, прежде всего, в том, что любой специалист по веб-фронтенду может задеплоить свое приложение на десктоп, не переучиваясь на новую технологию. Круто - да? Лучше ли данное решение, чем нативное приложение? Нет, йопта. 5. Ну и по поводу "простоты". Вы уж меня извините, но тот же QML сильно более прост, логичен и интуитивен, чем html+css+js. Сравните "anchors.centerIn: parent" с тем примером выравнивания, который тут приводился.

@kirilldanshin @tokenizer да, это рутина потому что не требует каких-то особых алгоритмов и в общем является достаточно повседневным классом задач для фронтэндщика того же

А пацаны то и не знали, оказывается из юзеровского ввода так легко сделать адаптивную верстку

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

более того, в этом процессе 50-60% работы делать долэен UX Designer

кто выберет css обмазываться?

@kirilldanshin @tokenizer да, это рутина потому что не требует каких-то особых алгоритмов и в общем является достаточно повседневным классом задач для фронтэндщика того же

Нихрена.

Нихрена.

в каком месте нихрена?

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

Вообще не в ту степь

в каком месте нихрена?

в любом. 95% фронтендеров не умеют в разработку редакторов писем

в любом. 95% фронтендеров не умеют в разработку редакторов писем

какие там особо интересные задачи встречаются?

95% бэкендеров умеют только из пхп сходить в базу )

ERROR: S client not available

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

О! Шалаш из костылей - унесу в "избранное")

Холивар уровня "мне не нравятся комиксы, поэтому я считаю, что это скучно"

какие там особо интересные задачи встречаются?

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

какие там особо интересные задачи встречаются?

очень редко, например работа с webGL чтобы делать 3д карты, webRTC всяике, или audi API. но так то да, ничего интересного. как в зеленом слонике, сидишь такой у толчка/бразуера тебе дают json-вилку и говорят, что надо отрисовывать. иди рисуй, вот тебе звуздочки, бабель, вебпак...

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

а в каком месте это интересные не рутинные задачи?

генерирвоать горы костылей это так увлекательно и не рутинно, да

очень редко, например работа с webGL чтобы делать 3д карты, webRTC всяике, или audi API. но так то да, ничего интересного. как в зеленом слонике, сидишь такой у толчка/бразуера тебе дают json-вилку и говорят, что надо отрисовывать. иди рисуй, вот тебе звуздочки, бабель, вебпак...

это о редакторах писем, а не о том, что ты говоришь вопрос был

это о редакторах писем, а не о том, что ты говоришь вопрос был

ааа, сорян тогда

а в каком месте это интересные не рутинные задачи?

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

Тут есть несколько нюансов: 1. Я говорю, что весь вопрос в стоимости разработки, мне рассказывают про "прогрессивность технологии" и "обширные перспективы". Имхо, весь хайп базируется на 3 вещах: наличии хреновой уймы недорогих специалистов разной степени профессионализма, возможности переноса веб<->десктоп (т.е. отсутствие необходимости "переписывать и поддерживать"), обратная совместимость. 2. Внутри у всей этой хрени, как ни оборачивай все это в красиывые фреймворки, один фиг html+css+js, а проблемы с этим есть. HTML - язык разметки ГИПЕРТЕКСТА, все "интерактивные" части привязаны к нему сильно сбоку и скотчем. 3. Собственно, для распространенных клиент-серверных вещей оно нормально. Другое дело, что часто слышатся призывы "похоронить" всяческие "низкоуровневые библиотеки". На выходе имеем десктопные приложения из 1 кнопки, упакованные в отдельный браузер... 4. Причина энтузиазма во всей этой ситуации, прежде всего, в том, что любой специалист по веб-фронтенду может задеплоить свое приложение на десктоп, не переучиваясь на новую технологию. Круто - да? Лучше ли данное решение, чем нативное приложение? Нет, йопта. 5. Ну и по поводу "простоты". Вы уж меня извините, но тот же QML сильно более прост, логичен и интуитивен, чем html+css+js. Сравните "anchors.centerIn: parent" с тем примером выравнивания, который тут приводился.

1. Тк стоимость разработки как раз копеечная, уйма специалистов с фронта. 2. Не всегда, на сегодняшний день эти технологии в чистом виде отходят на задний план, посмотрите на модульный css в react 3. Никто не говорит "похоронить". Я говорил про то что они не нужны большинству для решения ежедневных задач, пусть даже и из 1 кнопки(сегодня это одна кнопка, завтра SPA из овердофига страниц, так что почему бы и нет) 4. Плюсы способны покрыть большинство минусов для наиболее распространенных задач. Снова, зачем мне тратить драгоценное время на изучение qt или чего-то другого если я могу использовать то что знаю и оставить качество на достойном уровне? 5. В таких вещах - может быть, но когда кодовая база разрастается то разобраться становится тяжелее. Я за ним не следил, может с 2010 года там много всего поменялось, но в тот момент это была "та ещё лапша"

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

Монотонно выяснять какие костыли в каком почтовом клиенте нужны и делать костыли в формировании вывода? В каком месте это не рутина? Это как раз пример наиярчайший рутинной тупой работы

этот чатик сейчас о чем?

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

1. в XHTML генерить письма без блочной верстки 2. гора костылей 3. Адаптировать пользовательский ввод И где "быстрота разработки", и в чем преимущества над нативом?

1. в XHTML генерить письма без блочной верстки 2. гора костылей 3. Адаптировать пользовательский ввод И где "быстрота разработки", и в чем преимущества над нативом?

бля. ты гонишь? письма ты на QT пользователям отправлять будешь?

этот чатик сейчас о чем?

Back end vs frontend

Back end vs frontend

Fight! :D

Есть мнение, что фронтендеров наоборот не хватает

бля. ты гонишь? письма ты на QT пользователям отправлять будешь?

ну вот для отправки писем таки и придуманы "протоколы отправки писем". SMTP вот, говорят, был какой-то...

ИМХО: ненавижу фронт, но назвать его скучным - бред, на фронте интересных задач не мало, если конечно не говнобложик делаете

Есть мнение, что фронтендеров наоборот не хватает

ну, собственно, в этой каше реально на все разработчиков не хватит

ну вот для отправки писем таки и придуманы "протоколы отправки писем". SMTP вот, говорят, был какой-то...

100к реципиентов....

ну вот для отправки писем таки и придуманы "протоколы отправки писем". SMTP вот, говорят, был какой-то...

да я не о протоколе, а о содержимом.

и? Вы таки считаете, что веб-морда сервера делает что-то принципиально иное, чем клиент-серверное приложение на Qt? Т.е. в случае использования браузера каким-то магическим образом SMTP останется незадействованным?

Монотонно выяснять какие костыли в каком почтовом клиенте нужны и делать костыли в формировании вывода? В каком месте это не рутина? Это как раз пример наиярчайший рутинной тупой работы

да в том, что последние месяцы в фронте не надо постоянно этим заниматься, а тут креативность провлять надо, изобретательность ?

и? Вы таки считаете, что веб-морда сервера делает что-то принципиально иное, чем клиент-серверное приложение на Qt? Т.е. в случае использования браузера каким-то магическим образом SMTP останется незадействованным?

я еще раз спрашиваю. ты хочешь сраное письмо на qt верстать и получить поддержку клиента одного человека? нахрен тогда вообще кому-то твои письма?

да в том, что последние месяцы в фронте не надо постоянно этим заниматься, а тут креативность провлять надо, изобретательность ?

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

Там нет простора для полета мысли.

вы сделайте изоморфную СПА

вы сделайте изоморфную СПА

сделали

вот там простор для полета мысли

Призываю закончить оффтоп :) Все профессии нужны, все профессии важны. Каждому интересно то, чем он занимается