Frontend — туманные перспективы

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Frontend разработка в последние годы развивается бурным темпом, но как показывает текущие состояние дел — в Frontend community явно наблюдаются отсутствие специалистов.

Примером этому могут служить разработка Angular 2 (изначальное создание AtScript который был почти калькой TypeScript, breaking changes в между RC), React+Redux best practices (inline стили, использовать Redux store для хранение информации о статусе запроса), огромное кол-во популярных библиотек которые не очень качественно написаны.

Нет, конечно существуют хорошие проекты, но их реально единицы.

На днях говорил с товарищем, спрашивал, могу ли я посоветовать хорошего frontend разработчика на один проект — после недолгих раздумий сказал, что знаю кучу хорошего backend разработчиков, но не могу посоветовать ему ни одного frontend, на что он ответил мне что backend и сам без труда бы нашел.

Так вот к чему я. Как-то туманно видится перспектива развития Frontend community. К примеру для Java есть куча книг и действительно хороших практик, а вот frontend особо ничего не знаю (разве что JS Good Parts и книга о паттернах от Османи), и развивается довольно в стремном направление рождая не качественные технологии (такие как Angular 1 к примеру) и решения.

Может мне все это мерещится? Может мне не везет попасть в коллектив с хорошими специалистами?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

вся справа в джс. ніхто не хоче їм обмазуватись, коли навколо є купа годних мов

якби фронт можна було писати на чомусь іншому, крім джс — подібних топіків не було б

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

Frontend разработка в последние годы развивается бурным темпом, но как показывает текущие состояние дел — в Frontend community явно наблюдаются отсутствие специалистов.
Примером этому могут служить разработка Angular 2 (изначальное создание AtScript который был почти калькой TypeScript, breaking changes в между RC)

Бугага! Автор, на вас так пиво діє, чи що?! Ви це серйозно?! Саме формулювання питання «в Frontend community явно наблюдаются отсутствие специалистов» і далі якимось дивом ви намагаєтесь це аргументувати «изначальное создание AtScript который был почти калькой TypeScript, breaking changes в между RC».

Іншими словами, ви говорите: «щось я бачу погане ком’юніті, бо є брікін ченджес, коли вже був RC». Як перше пов’язане із другим?

Якщо говорити за «хреново, що є breaking changes, коли вже було оголошено RC», то давайте оцінимо що саме зробила команда Angular 2 фактично за 2 роки свого існування, і чи легко було обійтись без breaking changes. Для цього зайдемо й почитаємо Angular 2: FEATURES & BENEFITS

Люди за два роки написали фреймворк, який практично повністю охоплює динамічний фронтенд, відмінну здатність до тестування, хорошу підтримку рідної мобільної розробки, Angular CLI, анімацію, стилі, SEO-оптимізацію, робота офлайн, рендерінг на:
— platform-browser-dynamic (тут дінамік означає, що код не скомпільовано в так званий AoT (Ahead of Time compilation))
— platform-browser (тут вже використовується AoT)
— platform-server
— platform-webworker-dynamic
— platform-webworker

За два роки! І ви кажете що вони хренові спеціалісти, бо є breaking changes? ... Ви б змогли обійтись без breaking changes? Думаю якщо поставити собі самоціль, то це можна забезпечити, тільки то вже буде дуже сумнівне рішення.

К примеру для Java есть куча книг и действительно хороших практик, а вот frontend особо ничего не знаю (разве что JS Good Parts и книга о паттернах от Османи), и развивается довольно в стремном направление рождая не качественные технологии (такие как Angular 1 к примеру) и решения.

Дві величезні різниці є, можна сказати — між ними прірва, коли порівнювати Java vs. Angular (мова програмування vs. фреймворк!). По-перше, джава на п’ять років старша, по друге Java, образно кажучи, сама диктує що вона буде робити і як, і їй не треба приймати правила гри розробників різних браузерів, та самої JavaScript...

Корочше... не серйозно все це.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вы просто сравниваете разные вещи! Проведем аналогию:
бэкэнд — специалист — это автомеханик. Он работает с деталями сделанными по стандартам, стандартными инструментами, у него есть методы диагностики, есть опыт, есть чертежи, есть инструкции как и что собирать.
фронтендщик — это как дизайнер модной одежды. Главное — оригинальность, мода, эпатаж, впечатление. Никаких шаблонов, никаких старых подходов — только смелый полет фантазии.
А вы хотите что бы такой дизайнер сшил вам строгий, надежный, банальный костюм?!
Софт для бизнеса и софт для юзеров — это две большие разницы! Жабаскрипт или другие языки — все суть инструменты. Просто одни инструменты — это инструменты инженера: надежные, продуманные, проверенные, стандартизированные. А другие инструменты — это инструменты «самоделкина — экспериментатора», который пытается из двух телевизоров собрать тостер.
Секрет в том, что бизнесу нужна правильная логика, а интерфейс — вторичен. Можно сделать рабочий сайт вообще без строчки жабасрипта! И он будет нормально выглядеть во всех браузерах, будет соответствовать стандартам, будет поддерживать и «читалки» и тач интерфейс, и индексацию контента и закладки на страницы и вперед-назад навигацию в браузере... «Тонкий клиент» придумали еще в прошлом веке — и он продолжает работать как задумано.
Нахрена наворачивать SPA на жабаскрипте? Ну это же типа модно! Не просто сайт — а «приложение». А по-сути попытка возврата к «толстому клиенту», от которого как раз и отказывались из-за излишней сложности, ненадежности и тяжеловесности. И все эти модные жабасринт фреймвоки — это попытка изобрести Делфи для жабаскрипта! Что бы снова можно было формошлепать мышкой.

бизнесу нужна правильная логика, а интерфейс — вторичен

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

Вебщики найменш кваліфікаовані з усіх програмістів. В JavaScript і web—програмування ідуть всілякі різні люди (які нічого крім JavaScript не бачили) тому ще це популярно і це не так складно як умовний c++. Вчора ти верстав під Wordpress а завтра вже верстаєш і пишеш під Node.js. Всілякі лямбла—програмісти підтвердять.

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

Назовите любое английское слово и скорей всего окажется, что им уже назван какой-нибудь MVC фреймворк.
мужно даже русское, например балалайка =)

github.com/finom/balalaika и (оно же в списке npm либ) www.npmjs.com/package/balalaika

или матрешка:
github.com/matreshkajs/matreshka

Туманные перспективы

I’m just going to move back to the backend. I just can’t handle these many changes and versions and editions and compilers and transpilers. The JavaScript community is insane if it thinks anyone can keep up with this.

Междутем, статья устарела —
code.facebook.com/...e-manager-for-javascript

в во втором полугодии 2016 уже нужно использовать yarn. Оставайтесь с нами.

Фок, оце я слоупок... Я ще гульпіка не зносив...

вынесу отдельным постом, чтобы не объяснять каждому

О преимуществах «полной перерисовки» в плане скорости разработки перед SPA, а то мне стали аргументировать что она одинакова, а то и SPA быстрее разрабатывать.
Каждый плюс — это два минуса. И наоборот, из двух минусов можно слепить плюс.

Полная перерисовка — приводит к отсутствию состояния у страницы. Ну там в кукисах с пяток параметров. то есть — полная перерисовка — это иммутабельность страницы.

А это значит что в обсуждении преимуществ и недостатков обоих подходов мы можем применить все рассуждения в холиварах — мутабельность vs иммутабельность.

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

И как применение иммутабельности как главного принципа в дизайне влияет на скорость разработки.

и в случаях SOAP vs REST — тоже.

мутабельность vs иммутабельность
Ну і які б ви назвали плюси вашої «иммутабельности», скажімо коли заходимо на ось цю тему. Кожен хто заходить, я думаю, зразу відчуває «иммутабельность», але сходу плюси не спостерігає.
Ну і які б ви назвали плюси вашої «иммутабельности»
більшість сторінок в інеті — імутабельни, а для таких випадків використовуєця або паджинація, або pajax. так що плюси тим хто платить — відомі.

бо цей випадок аніяк не пришвидшує — «скорость разработки SPA»

вынесу...каждому

Наступала эра pwa, доу решил еще побыть типа древним

Web sites are for consumption what Web apps are for creation
www.visionmobile.com/...ps-what-the-experts-think

зачем для создания Web sites использовать технологии для разработки Web apps, которые увеличивают время разработки(что приведет к удорожанию даже если бы стоимость человеко-часа была одинакова для любого уровня специалистов) непонятно с какой бизнес выгодой?

Из своего опыта: многим разработчикам не хочется заниматься front-end разработкой, так как на практике специалисту зачастую еще требуется заниматся верткой и UX. Например, я в свободное время гораздо чаще ковыряю Javascript, чем PHP (обожаю всякие там реакты, функциональное программирование и прочие интересные вещи), но я никогда не пишу, что претендую на должность frontend-разработчика в резюме. Причина: не хочу влезать в CSS.

просто не умеешь его готовить ©

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

та это наброс был, понятное дело не все любят верстать
мне, например, иногда нравится, потому что много думать особо не надо: поменял — проверил, работает как надо, погнал дальше

надо не иметь визуальный кретинизм , чтобы верстать)

Да ладно вам. Чего все так не любят играться с CSS и версткой в принципе? С появлением таких технологий как SASS, Jade и Gulp — играться с версткой стало одно удовольствие :)

Да оно даже без Sass нормально, если соблюдается BEM и все стили раскиданы по Javascript-компонентам. Тут проблема не столько в воркфлоу, а в том что, как выше написали, не умею и не нравится.

Тому що оформляти прості документи з CSS ще нормально а от робити щось складніше це, в більшості виадків, костилі.

Когда-то искали фронт-эндщиков на проект.
Клиенту вдруг захотелось джаваскрипта — срочно и непонятно зачем, ну, т.е. конечную цель клиент не раскрывал.
Сошлись на том, что принудили джависта заняться джаваскриптоложеством.

Море коментов но никто не вспомнил о actionscript flex. Только ленивый не танцевал на костях флеша, утопили альтернативу теперь ешьте что дают в три горла и не нужно ныть что вкус не тоти джс уже не торт.

ActionScript 3 был очень не плох, жаль что не было arrow function

Саме він частково і вбив флеш. Чого тільки варта декларація обробника події...

Really? Lol Есть альтернатива библиотека signal. Избавляет не только от декларации но и от течки памяти

Если бы его не укантропупили все бы было со временем. Ибо акшенскрипт шел в ногу со стандартом ecma одним из первых позволил писать хмл прямо в коде! НИКТО до сих пор также не умеет. Ни дарт ни тайпскрипт ни сотоварищи типа кофескриптов и прочий хлам

FF підтримував E4X до 20ї версії. Потім вони вирізали цю фічу.
The E4X standard was deprecated by the Mozilla Foundation in 2014.

ну справедливости ради надо сказать что и адоби руку приложил. Надо было с самого начала проталкивать нативную поддержку AS3 и флеш в браузерах а не делать это закрытым плагином

Адобе вынудил рынок поступить так. Слишком многие ретранслировали мысль сердобольного джобса вот и наступила новая эпоха консольного фронтенда. Что же до нативной поддержки, даже гугл не может протолкнуть свой дарт дальше даже при наличии целого своего браузера! А майкрософт не может протолкнуть свой тайпскрипт имея так же плеяду своих браузеров. К кому претензии? Если даже люди влияющие непосредственно на рынок браузеров не могут договориься?

В JS (как языке, так и community) очень долго не было никаких телодвижений. Был JQuery, был Ajax и этого хватало («кнопочки ведь подсвечивались» и хватит).
Но тут — О Боги — язык и сообщество вокруг него начали меняться, начали искать пути сделать UI и UX лучше, быстрее, адаптивнее и т.д. А знаете, как на это отреагировали люди не из JS комьюнити? «Хахаха, хипстеры, пишут со своими нодами и вебпаками». Да ну вас нах*р, товарищи недовольные. Все вам не так. Или вы вините язык в том, что не можете писать на нем так, как пишите на джаве/сишарпе/руби? Так давайте все языки обвинять, на них ведь не получится писать так, как на ассемблере.
А особенно смешит сравнение джавы и джс. Джава уже давно устаканилась, у джс идет активное развитие, и жаловаться на то, что «книги устаревают» это глупо. Есть воркшопы, есть прекрасные ресурсы для обучения со свежей информацией. Чтобы научиться готовить джс — надо УЧИТЬСЯ ГОТОВИТЬ ДЖС, а не только жаловаться, что книжек нет (а они есть, просто надо уметь искать).

вообщето JS и Java как языки примерно одинакового возраста, JS немного младше, конечно стоит отметить что активно использоватся он стал условно недавно.

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

тут вроде никто не жаловался на устаревание книг.

К примеру для Java есть куча книг и действительно хороших практик, а вот frontend особо ничего не знаю (разве что JS Good Parts и книга о паттернах от Османи),
 — Ваши слова.
ак раз JS сообщество ринулись на новые технологии без понимания зачем и для чего, и начало плодить не самые лучшие решения, и самое плохое, преподносит их как хорошие
 — я уже написал, зачем создаются новые технологии в джс. Нам нужен лучший UX.

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

Нам нужен лучший UX.
кому именно — нам?

Пользователям Интернета.

да ну :)

вот есть для них, пользователей интернета — форумный формат общения.

и что в нем можно улучшить настолько, что старые технологии не годятся?

тот же формат соц сети — разве убил форумы на phpBB?

или, для реализации плагина BuddyPress («соц сеть» для Wordpress сайта) — надо юзать Ember и никак иначе? пользователи не поймут если это не на Ангуляре?

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

Да много чего можно улучшить, на самом деле.
так я и спросил — назовите сходу пару-тройку вещей, раз вы отчетливо их видите.
аналогичного опыту использования десктопных/мобильных приложений
для сайтов новостей как правило есть приложения. я ими — не пользуюсь. пробовал — никаких особых выгод не заметил.
старые технологии для написания форумов
как пользователю мне не важно на каких технологиях сделан форум.
так я и спросил — назовите сходу пару-тройку вещей, раз вы отчетливо их видите.
Добавить обновления в реальном времени, оповещения, возможно прикрутить html history api для более быстрого серфинга, добавить поддержки кеша. Для понимания что из этого и много другого лучше нам нужен UX
для сайтов новостей как правило есть приложения. я ими — не пользуюсь. пробовал — никаких особых выгод не заметил.
Мобильное приложение к примеру может слать алерты и иметь виджеты для рабочего стола.
как пользователю мне не важно на каких технологиях сделан форум.
Пора глотнуть эликсира молодости. Технологии и правда неважны, но некоторые вещи просто нельзя сделать без использования новых технологий.
Добавить обновления в реальном времени, оповещения,
можно. особенно учитывая рекомендации по продуктивной работе — отключать любые уведомления, даже о приходе корпоративной почты — очень востребованный функционал :)
Мобильное приложение к примеру может слать алерты и иметь виджеты для рабочего стола.
может.
поставить таких парочку — и так в новостях день проведешь :) через пару таких дней заметишь, что новости какие-то все одинаковые. и на 99% — бесполезные для тебя лично. и вначале отключишь этот функционал.
а через месяц тебе система сообщит — вы не запускали это приложения ни разу в течении 30 дней — может его удалить?
Технологии и правда неважны, но некоторые вещи просто нельзя сделать без использования новых технологий.
некоторые да.

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

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

Да и это только один пункт из списка с тех позиций приведенного списка + не ограничено длинного списка «и много другого», где перечислять можно еще очень многое.

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

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

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

некоторые да.
пример из мира гаджетов Google Glass.
на более старой элементной базе — и не сделать.
И как мы видим вокруг — каждый третий на Западе носит Google Glass, а у нас каждый 7ой.
Дайте подумать... обработка изображений с помощью Canvas при загрузке аватара прямо в браузере по моему намного удобнее чем сообщение о «файл сильно большой», «файл неправильного формата» или действия вроде «вырежь сам и дай мне уже обработанную картинку!», но врядли это можно сделать без поддержки Canvas. Нельзя например было сделать работу со звуком или видео не имея HTML Video\Audio API, необходимо было использовать сторонние плагины вроде Flash, это как пример что новое упрощает использование старого. Или к примеру WebGL в 3d картах, их 3d-шность только один из аспектов, раньше невозможно было отрисовать карту в браузере, слишком много данных для Canvas или SVG, отрисовка иногда занимала больше минуты. Следовательно нельзя было делать никаких операций над картой прямо в браузере. Ни повернуть(надписи не поворачивались), ни наклонить чтобы сравнить высоту зданий(перспективу нельзя построить с плоским рисунком) ни какого либо фильтра(перерисовывать можно только на сервере), не говоря уже о том чтобы что-то дорисовать в визуальном редакторе прямо на карте(Как это делают в OpenStreetMap).
Так надо форум популяризовать или правила корпоративной работы соблюсти?
речь не о правилах корпоративной работы.

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

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

конечно я впадаю в крайность. И приложениями люди пользуются, и виджетами
Просто я вас призываю не путать маркетинг buzz с действительностью. Когда будете общаться с потенциальным клиентом — да, а тут-то зачем?

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

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

но в целом... вот беру ваш пример и себя как обычного пользователя
> при загрузке аватара прямо в браузере
+ да, круто, мне понравилась эта фича
> Нельзя например было сделать работу со звуком или видео не имея Flash
— я не заметил например на Yuotube, когда он перешел с Flash на HTML. Если бы браузеры последних версий не ругались, то не знал бы и сейчас, где там Flash а где HTML
> Следовательно нельзя было делать никаких операций над картой прямо в браузере
± - на смарте и сейчас практически низя. так то пользуюсь приложениями. на десктопе как когда, браузер рисует с приемлимой скоростью, но приложение по прежнему работает быстрее.
> не говоря уже о том чтобы что-то дорисовать в визуальном редакторе прямо на карте
— не знаю, не рисовал. Но наверное это важная фича. Ведь известно что на тех же форумах контент создают не более 5% посетителей. Вот для привлечения этого процента, да, «вики» технологии полезны.

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

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

чтобы _примечания_ отмечать
чтобы код
~~~ C
puts("Hello word");
~~#
оформлять
* потому что пишу — быстро
* выделять и тыкать мышкой во всякие панели — долго

уж **много** лет жду этой супер технологии от интернета...

И как мы видим вокруг — каждый третий на Западе носит Google Glass, а у нас каждый 7ой
Возможно я что-то пропустил в дискуссии (попалось на глаза только это сообщение), но где каждый 3-й носит Google Glass???
Я вообще кроме как на видео в Youtube Google Glass не видел (да и вообще, насколько я понял проект провалился).
но где каждый 3-й носит Google Glass???
это был сарказм :)

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

Нові технології для UX як раз не розробляються. Переносяться давно всім відомі з бекенда. І це жодним чином не впливає на UX, тільки додає певних проблем.

Элементарное отсутствие перезагрузки страниц при каждом действии уже меняет UX в лучшую сторону.
И о каких таких технологиях из бекенда идет речь?

Элементарное отсутствие перезагрузки страниц при каждом действии уже меняет UX в лучшую сторону
для этого не обязательны технологии SPA. Page AJAX — справляется.

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

Зараз з цим вже немає проблем. Є доступ до API історії браузера. Не зовсім на 100% те, що хотілося, але краще ніж зовсім нічого

Ага, только вот данные могут меняться, а и толку от тех закешированных данных в истории браузера?

Історія браузера не для збереження даних. Вона для посилання на певні ресурси. Організовуйте UI таким чином, щоб користувач мав можливість відтворити все те, що він бачить перед собою в певний час.

Організовуйте UI
я посетитель сайта. как я могу это сделать?

Звернутися до розробників або скористуватися можливостями сайта в плані налаштування.

Звернутися до розробників
а кто им будет за это платить? я?

Тоді не звертайтеся до розробників. Я не бачу проблем.

проблема у незрілості ком’юніті, якє вигадує проблеми користувачів, яких вони не мають :)

цей топік наочно це демонструє.

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

Ваші слова? Ви вигадали цей патерн за користувачів? Про яку незрілість ком’юніті ви розповідаєте тоді?

Ви вигадали цей патерн за користувачів?
цей патерн давно в чеклістах наприклад для фільтру по товарах

гугліть — Чеклист для фильтров на сайтах

Про яку незрілість ком’юніті ви розповідаєте тоді?
про ту саму, яка не знає цього. хоча ж:

Уніфіко́ваний ідентифіка́тор ресу́рсів (англ. Uniform Resource Identifier, URI) — компактний рядок літер, який однозначно ідентифікує окремий абстрактний чи фізичний ресурс

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

зате впевнено береця розповідати що користувачам потрібен SPA на ангулярі.

Ще раз. В SPA немає проблем із випадком

коли користувач повинен мати можливість вислати лінк на документ(транзакцію) в системі, або репорт з обраними фільтрами, сортуванням і такє інше.
Для цього необхідно правильно організувати роботу із хісторі браузера. Для цього додатково необхідно, щоб UI був організований таким чином, щоб в будь який час відновити той саме вигляд, що й був у користувача на момент копіювання посилання. І ангуляри та інші фреймворки тут ні до чого, бо з ними також можна зробити аналогічну функціональність.
В SPA немає проблем із випадком
звісно що немає.

бо я ж її вигадав:

Ви вигадали цей патерн за користувачів?
Для цього необхідно правильно організувати роботу із хісторі браузера.
на що ще ви хочете відкрити мені очі? :D
І ангуляри та інші фреймворки тут ні до чого, бо з ними також можна зробити аналогічну функціональність.
звісно що можна. і роблять.

але вам слід перечитати обговорення. бо на це «можна зробити» вже відповідав.

Всякі такі штуки ускладнують створення програми і в контексті WWW вони частенько ускладнюють користування сайтом.

могут.

как часто и по какой причине они меняются? вот глобально, в интернете?

Є доступ до API історії браузера
у кого, у посетителя сайта?

У скрипта, який буде працювати в SPA.

то есть посетитель сайта должен писать скрипты?

Я не розумію вашої логіки. Що ви хочете сказати?

що ми балакаємо про потреби користувачів. а ви відповідаєте про про програмістів, та їх бачення — проблем користувачів.

Тобто задача програміста не реалізовувати потреби користувачів? Я взагалі не можу збагнути, до чого тут це. Можете розгорнути думку більш детально?

у користувачів нема потреби в «ангулярі».

і в нових технологіях — які не дають їм нічого нового.

Це не правда. Ви без «ангулярів» створите, наприклад, щось подібне до google-excel, з якими можна працювали онлайн? Для бекенда або ж навіть для якогось там jQuery — це недосяжний космос.

Розумію, що ви скажете «це нікому не потрібне», але це теж буде не правдою.

Та взяти саме ближче — наші коментарі на цьому форумі, хіба не додають зручності ось такі коментарі?

Ви ще десь вище писали про проблему «посилатись на конкретний коментар». Не чітко зрозумів чи це укол в бік SPA, але із цим SPA справляється якраз легко: ось вам лінк на конкретну вибрану гілку обговорення. Можете перейти на якусь іншу сторінку, повернутись назад і все працюватиме як очікується.

Гугл докс, скорее всего делал бы на ванила джс

Скорее Closure library был создан в результате гугл докс, а по факту ванила джс

Ви без «ангулярів» створите, наприклад, щось подібне до google-excel
так користувачам потрібен ангуляр чи google-excel?

по другє — я ніде не казав що він взагалі не потрібен.

Ви ще десь вище писали про проблему «посилатись на конкретний коментар».
по третє я цю проблему вирішував не одноразово.

тому що користувачів відсутність дратує. і мене як користувача теж.

але із цим SPA справляється
SPA не може ні з чим справлятись, бо то паттерн.
Ця проблема з лінками відома ще до моди на SPA,

Фреймворк може мати такі можливості, а може й не мати.

Можете перейти на якусь іншу сторінку, повернутись назад і все працюватиме як очікується.
і це я робив теж.

взагалі я не зрозумів чому мої опоненти вірішили розповісти мені про азбуку веб розробкі? ;)

взагалі я не зрозумів чому мої опоненти вірішили розповісти мені про азбуку веб розробкі?
Може треба висловлювати думку якось більш розгорнуто?
Та взяти саме ближче — наші коментарі на цьому форумі, хіба не додають зручності ось такі коментарі?
Скролл спотыкается на полностью загруженной странице, а каментов всего 16... =)
На 8-ми — работает нормально.

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

А, це ви мабуть тримаєте за повзунок і прокручуєте. Так, там є така проблема при лінивому дозавантаженні коментарів. Якщо прокручувати колесиком, то ривків по-ідеї не повинно бути.

Це проблеми верстки, я точно не верстальник, хоч і пишу динамічний фронтенд.

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

Это если их не очень много и если продумана архитектура фронтенда. А вот в противном случае без фреймворка гораздо, ГОРАЗДО больше шансов получить дерьмо, а не приложение, которым можно гордиться.

Фреймворк не врятує від кривих рук, нестачі досвіду, неправильного UX тощо.

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

Фреймворк не гарантує написання гарного продукту. Тому що гарний код та гарний продукт взагалі не тотожні речі. Гугл Вейв писали явно люди із дуже високою кваліфікацією. І де зараз той гуглєвєйв?

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

Я не говорю, что каждый сайт, сделанный без фреймворка — дерьмо О_о

Тут ще треба визначитися, що саме мається на увазі під словом «фреймворк». Популярні хайперські рішення, чи власні теж.

Я тут подивився, що не той пост прокоментував. Тому був втрачений контекст :(
Асинхронність була перенесена з бекенда, бо там вона існувала давно. Але через те, що вона реалізована в JS доволі таки дивно (а раніше і взагалі псевдоасінхронно), ми отримали ряд пов’язаних із цим проблем. Наче все виглядає чинно, можна поліпшити UX, але вилізають такі речі як перевантаження та переускладнення коду на стороні клієнта. А це фрізи браузерів, утікання пам’яті, надмірне споживання батарейки тощо. Нещодавно задовбував FB, бо вони щось зламали в своєму коді, інтерфейс перестав працювати в одному з браузерів. Я отримав непрацюючий ресурс через переускладнення системи в цілому.

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

Лучший UX в вебе — у Крейгслиста. Но хипсто-макакам этого не понять, им обязательно надо загадить новомодными веб-фреймворками весь интернет. Paypal стал на порядок хуже старого, новый Hostelworld лагает с секундными рывками и стал абсолютно негодным, Facebook раскаляет проц при длинной прокрутке вниз. Шлак (Slack) дисконнектится без объективных причин, и тоже периодически по жести грузит проц.

Core i7/16 Gb RAM/SSD, всё нативное — летает.

Moй менталитет в этой ублюдской ситуации тотального дегро таков: технологии должно быть не менее десяти лет, чтобы применять её в боевом production. За это время ликвидируются детские болячки, прикрываются дырки в безопасности, да и просто нежизнеспособный fad сходит с горизонта.

Но тут — О Боги — язык и сообщество вокруг него начали меняться, начали искать пути сделать UI и UX лучше, быстрее, адаптивнее и т.д.
не это причина.

причины
1. в потребности бизнеса перевести свои приложения с десктопными GUI в облака, с Web UI.
2. появления сервисов с агроменной посещаемостью типа фейсбука с твитерами, где требуется — персонализированное содержание.

т.е. — это не JS комьюнити решило меняться, улучшаться.

оно просто двинулось слегка мозгами на этой почве, ведь если на сайте достаточно чтобы кнопочки подсвечивались — то этого — ДОСТАТОЧНО!

Угу. И чтобы каждый раз странички перезагружались, тоже достаточно. Вот лично Вам больше нравится работать с веб-сайтом, когда при каждом вашем действии будет blank screen или симпатичные спинерки?
Да и сейчас, ну практически любому худо-бедному сайту, ИМХО, нужно что-то большее помимо светящихся кнопочек.

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

если клик на «Развернуть» работает больше 700мс — то какая разница что сайт сделан на ангуляре — для посетителя сайта?

когда при каждом вашем действии будет blank screen или симпатичные спинерки?
на сайтах гугла они постоянно. что в gmail, что в Google+.
Да и сейчас, ну практически любому худо-бедному сайту, ИМХО, нужно что-то большее помимо светящихся кнопочек.

что именно? вот для доу — что такого нужно то?

хорошо, не для доу — для Reddit — каких UI свистелок там не хватает?

Хорошо. Перед тем, как ответить на ваши вопросы, пожалуйста, ответьте на мой. Если бы у ДОУ было бы нативное приложениие, вы бы пользовались им или продолжали пользоваться сайтом? Это с учетом того, что нативное приложениие выглядело бы в духе ОС и что в нем не было бы даже «комфортных» перегрузок менее 700мс?

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

для интересующих меня разделов хватает RSS клиента и браузера для чтения коментов.

вот редитовским с смарта да, пользуюсь чаще.

клиент для гугль+ - удалил. он работает тяжелее чем браузер на смарте.

нативное приложениие выглядело бы в духе ОС
если речь о десктопе — то мне это не нужно.

Для смарта да, возможно. Хотя доу на моем смарте работает вполне хорошо. Тьму постов написано мной с смарта :)

но вот что мне нравится в смартовских приложениях — сложно копипастить :) причем нередко — копипастить там в браузере, чем в нативном приложении.

Видел на Хабре недавно статистику (сейчас не смогу найти, но найду и прикреплю к комментарию). Согласно этой статистике, на телефонах больше используют таки нативные приложения. И вот было бы здорово, если бы UX в браузере >= нативного UX.
Я не говорю, что это нужно абсолютно каждому сайту и что в любой ситуации надо срочно подключать реакт. Нужно уметь держать себя в руках и использовать фреймворк тогда, когда он нужен :)

Чому б це в ньому не було перезавантажень менше 700 мс?

Когда мерещится... сами понимаете.

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

React+Redux качественный продукт? Скорее вовремя появившийся, для отдельного продукта React не был завершенным, но в то время всем уже надоел Angular 1 и многие смотрели «что то новенькое», не потому что старого не хватало, просто новенькое понимаете ли, новые технологии! Так сначала люди нашли React с красивыми цифрами, раздался бум, 80% народа не знали о чем говорят но кивали что знают, а потом к нему начали искать еще пару кусков, чтоб получить что-то рабочее(вспомните сколько было комбинаций React с различными библиотеками и фреймворками. Но главным тут был бренд React, хотя каждая его отдельная интерпретация с другими библиотеками были совершенно разными продуктами.

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

С фронтенд ничего не происходит, просто к нему добрался маркетинг и то самое пресловутое community, где половина народу не знает к чему миксины в объектах, а с лямбда программированием вообще не знакома, но дружно кивает в такт таким же болванчикам.

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

Angular 1, это как и любой продукт хорошая вещь для своих задач, например того же «сайта с рецептиками»,
вот этого никак не пойму — почему один из самых тяжелых js фреймворков
(Ext JS конечно лидер, я вживую видел, то что недавно о нем в habrahabr.ru/...y/oleg-bunin/blog/311096 рассказано)
уверенно предлагают как хороший выбор для «сайта с рецептиками». зачем он там? какие преимущества его применения скажем перед условным «ворпдрессом с няшной адаптивной темой, страницами скомпонованными каким-нить page builder’ом и тройкой jquery плагинов-свистоперделок»?

я о преимуществах в сроках разработки и конечной стоимости для заказчика.

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

вот только... почему за «простой в изучении» условный вордпресс ругают, а ангуляр хвалят?

т.е. — почему миллионы мух в одних случаях ошибаются, а в других — выбирают лучшее?

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

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

1. делаем на пыхе плюс jQuery
2. делаем на ангуляре

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

следующий этап: добавить поля для ввода телефонов, кол-во заранее неизвестное.

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

1. Делаем на голом SQL
2. Берем Hibernate, Doctrine

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

Сайтик с рецептами — в чем там сложность чтобы применять — тяжелый фреймворк?

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

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

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

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

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

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

И еще раз
о каком UI идет речь?

давайте посмотрим на www.apache.org
что там ангулярить то?
а тут — nv.ua
а тут — www.mirigrushek.com.ua

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

и какие осязаемые выгоды для бизнеса дает выбор 2?

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

вот глянул www.amazon.com.

и даже внутрь не смотрел, потому что он ведет себя как обычный сайт с перерисовкой.
кликнул фильтры... попробуйте :)

но в третий раз

вы не понимаете разницы между представлением информации для пассивного ее просмотра и — диалоговой работы с пользователем?

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

Ну лично я с вами согласен, выгоднее нанять человека не знающего ангуляр, ему платить меньше надо.
а где тут выгода?)

Сделать более простой продукт.
Получить большую выгоду сейчас
Вложить больше денег на рекламу в начальном этапе
Заработать больше в целом.

Деньги обычно делают не самые качественные продукты.

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

качество — это отношение функциональности к себестоимости.

если ботинки носятся месяц, а стоят 1ну гривну — это СУПЕРкачество! это бомба!

а если ботинки носятся десять лет, а стоят миллион — то некачественные ботинки.

а вот в идеальном, перфекциониском мире да, качество — это какая-то величина, указывающая на степень приближения к идеалу, Абсолюту — Богу.

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

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

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

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

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

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

если ПРИ одинаковой стоимости человека-часа специалистов длительность разработки разная, то более дорогим как в виде прямых затрат, так и косвенных (недополученная прибыль, или вообще — убытки ввиду опередившего конкурента) будет проект который делается — дольше.

если не поняли, а я знаю что программисты болеют перфекционизмом до упоротости, и не понимают о чем речь, для закрепления материала:

будем считать что рейт фрилансера-ремеслинка на «jQuery» и ангулярщика — одинаков
если скорость разработки зависит от выбранной технологии — то какова связь между выбранной технологией, и стоимостью проекта?

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

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

но вы ж не начинающий, так откуда у вас аргумент про ваяние руками?

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

Сергей есть фреймоврк с готовым функционалом. Разработка на готовом функционале не может быть дороже и дольше, при учете что проект в себя этот функционал включает, как вы все выше и написали, а «сайт рецептиков» обычно включает.

«Тьма CMS» вроде не лишает нас этой работы? Есть плагины, да у плагинов обычно есть готовый внешний вид, абсолютно согласен. Но это не про то что мы говорим, такие сайты не наша работа, это уже к кмсникам. А мы там где дизайнер нарисует что-то, что надо будет верстать. Плагины тут не в помеху, мы все равно свяжемся с их стандартным апи.

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

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

У фильтров с сео проблем обычно нет, гугл давно умеет кликать по кнопкам, тем более есть различные ариа атрибуты и микродата. Для особых случаев есть Phantomjs, но гугл уверен что-то аналогичное как раз и использует.

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

«Тьма CMS» вроде не лишает нас этой работы?
я и не говорил что лишает этой работы.

пример
ни Ruby, ни Java, ни ASP с .NET — не лишили работы PHP программистов за мноооого лет, по меркам IT. И наоборот.
Хотя ведь PHP все эти годы нещадно критикуется. С теми же тезисами — качество решений на пыхе мерзкое, язык дрянной, подход древний, и т.д.

в чем же дело? в этой теме и пытался пояснить — в чем:

после несколько лет работал над площадками для млм(хайлоад, биг дата)
... а в том дело что появление новых предметных областей типа хайлоад, биг дата — не убило ранее существовавшие предметные области.

но «упоротые фронтедеры» этого не слышат. и статистика им ни по чем
PHP is used by 81.9% of all the websites whose server-side programming language we know. w3techs.com/...es/details/pl-php/all/all

влом искать подобную о «jQuery» vs Angular. Тем более что такая как аргумент нужна по новым проектам. но думаю разница тоже будет сильно в пользу «jQuery» (в кавычках потому что не о нем конкретно речь)

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

то есть не понял, вы, «ангулярщики» там, где были и есть кмсники годами?
что в этом нового?

Ext JS
вот это тру ентрепрайз фреймворк, а не ангуляр, но в своей среде он более чем оправдан, и не кисло ускоряет/упрощает разработку

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

а о том спрашиваю, что часто встречал

Angular 1, это как и любой продукт хорошая вещь для своих задач, например того же «сайта с рецептиками»

и никак не пойму — накуя для сайта с рецептиками — ангуляр, если любой ремесленник фрилансер делает его «на вордпрессе»? причем не только UI, а под ключ, с админкой, и всем прочим.

или, как ниже писал

надо забиндить три поля на форме ввода. и все, остальной сайт — статика. и зачем для этого энтерпрайз фреймворк, если для того же «умершего» jQuery тьма мини либ pub-sub, да и ваяется такая на коленке за часик-два, если не хочется использовать чью-то?

и никак не пойму — накуя для сайта с рецептиками — ангуляр, если любой ремесленник фрилансер делает его «на вордпрессе»?
вот видите, не я один замечаю проблему с комьюнити :)
вот видите, не я один замечаю проблему с комьюнити :)
да, не вы один.

утрировано говоря одна из ярких проблем — в какой-то вычурной заоблачности

если смотреть технически и бизнесово на потребность в применении js либ и фреймоврков, то ИМХО они делятся на три группы:
1. когда надо украсить статику интерактивным или персональными элементами. тогда оправдано применять решения уровня «jQuery UI»
2. когда есть отдельные, персонализированные, интерактивные страницы для — обычного пользователя — тогда целесообразно применять решения уровня «Backbone»
3. Когда это энтерпрайзный сайт, для офисных работников, или когда информация на нем — сплошь персонализирована, со сложным UI — тогда ангуляр, эмбер, сенча и прочие.
(3а) когда это «фейсбук» с ахриненной посещаемостью ...

но когда читаешь мнения фронтендового комьюнити, то создается ощущение что сайтов вида 1 и 2 — не существует. а те что есть — устаревшее гуано, если там не применяются технологии из п3. а лучше — из 3а, ведь на сайтик с рецептами будут приходить миллионы посетителей в день! и каждому надо предоставить персональный список рецептов! вычисленный с помощью «IBM Watson»

примерно как с пхп — годами его бекендщики оплевывают, умер уже под мегатоннами этой слюны. а как посмотришь в реальный мир...

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

бекбон вцелом неплохо заменяем реактом
не вопрос. все можно чем-то заменить.

вопрос — с какой целью, и сколько это будет стоить. по времени и деньгам.

имеется ввиду в новых проектах, а не старых

да, надо бы мне тудушник на React’е сделать, для освоения...

Потому что у него плюс как и у Backbone — он не фреймворк, а view библиотека, то есть не навязывает ничего проекту. Это особенно ценно когда к существующему надо прикрутить в некоторых местах UI.

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

Як це Реакт не нав’язує? Спробуйте зробити stateless систему на ньому :)

Спробуйте зробити stateless систему на ньому :)
я його ще не мацав, все ніяк не викрою часу поседіти за volicon.github.io/NestedTypes
Gaperton(Vlad Balin): «React ValueLinks, это конечно, хорошо, но пришло время рассказать о нашей основной технологии, которая лежит в основе продуктов Volicon/Verizon.»

але запитав у гугла

stateless React js

поспіхом продививсь, не помітив що то є якась фундаментальна проблема.

можно подробнее? что значит «stateless система» в этом контексте?

Система, яка не зберігає дані (їх стан) на стороні JS.

фрагмент текста? красивая CSS-анимация? о чем речь?

Мова йде про варіант організації UI, коли він не зберігає стан. Прийшли дані із сервера (це можуть бути не дані, а, наприклад, інструкції якомусь проміжному рендер-модулю, або події), і вони одразу відправляються на відображення. Самі дані викидаються.

а, чтоб при стандартном подходе «клади в стор, а компонент уже отрендерит» не держать данные в сторе после успешного рендеринга, так?

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

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

Ой, та ладно вам 200 рядків кода — це при умові, що кожен рядок по кілометру довжиною =)

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

Ок, припустимо маємо ваших 200 рядків немінімізованого коду. Яку функціональність матиме сайт із рецептами, завдяки цьому коду? Валідація даних, відправка на сервер і редагування однієї формочки — це все?

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

А на беке это писать не надо будет?

так вам бекенд все равно писать придется скорее всего

А так эти 200 рядков будут на беке. А вообще подгрузка рецептов не больше 20 строк, остальное структура. Вопрос привычки скорее чем реально какое то препятствие использовать ангуляр для сайта рецептов, как по мне так он для такого создан идеально.

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

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

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

и никак не пойму — накуя для сайта с рецептиками — ангуляр
Схоже ви повірили тим коментаторам, які говорили про 6 МБ коду для Angular. Насправді ж, мінімізований Angular 1.4.3 важить 51 КБ, а мінімізований jQuery 3.1.1 важить 35 КБ, тобто між ними різниця всього у 16 КБ, але Angular забезпечує комплексний підхід, модульність і т.д.

до чого тут розмір, коли я вказую на більш важливі критерії:

час розробки та її вартість.

Якщо говорити про час та вартість, то хоча й Angular розробники дорожчі, але і якість їньої роботи повища, ніж у jQuery розробників. Причому якість роботи в більшій мірі продиктована, повторюсь, завдяки комплексному підходу Angular.

але і якість їньої роботи повища
— Вчера на улице ко мне подошла старуха и предложила купить вечную иглу для примуса. Вы знаете, Адам, я не купил. Мне не нужна вечная игла, я не хочу жить вечно
«Золотой теленок»
ніж у jQuery розробників
а у програмстів на Haskell в середньому рівень вище ніж у програмістів на PHP.

то чому сайти й досі робляця в основному на PHP?

дивина...

просто для справки: в процентах, это чуть меньше 50% разницы.

Для довідки: наша оця аватарочка 25×25 px для коментарів — важить 1.1 КБ, тобто 16 КБ різниці, це майже «ні що». Думаю жодна людина не зможе розрізнити швидкість завантаження файлів 35 і 51 КБ при адекватному, навіть мобільному інтернеті.

Мне кажется несколько некорректно сравнивать вес инструмента и готового изделия.

ангуляр 1 хорош когда много формочек и надо с ними чето делать чуть больше чем простая валидация и высылать на сервер.

чем вам не угодил Angular 2? Что мешает писать на TypeScript грамотный, с точки зрения ООП код, а потом просто конвертировать его в js?

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

TypeScript грамотный, с точки зрения ООП код
дело не в языке, JS сам по себе нормальный язык, вопрос в тех кто это использует

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

просто если JS твой первый язык, то легко сломать мозг не в ту сторону

Если изучать с детства, лет с 10-12, то JS все же лучше турбо-паскаля к примеру с его синим экраном и лучше той же Java, где всё как в анекдоте: «Чтобы пошутить с непрограммистом, надо провести лекцию на 40 минут».

Вспоминаю свои 12 лет и Паскаль — сплошные расстройства. Visual Fox Pro 6 в 13 лет — счастье и эйфория. Тут на JS человек сел и за полчаса наваял какую-то хрень типа бегающего колобка, которая даже не правильно но как-то работает.

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

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

просто замыкания ради приватных членов класса, или наследование через прототипы, это немного не в духе классического ООП. Или тонкости с приведением типов. Это всё немного не в ту сторону ломает мозг, как мне кажеться.

Да, классическое ООП лучше изучать на чем-то другом. Но с другой стороны — после классического ООП сложно адаптироваться к JS. А если человек в будущем будет работать только с JS — то оно ему и надо для кругозора.

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

Преимущество джаваскрипта как раз в том, что можно пощупать и функциональщину и ООП. Что вполне себе расширяет кругозор.

Это добро нынче много где есть

Мне кажется сначала нужно усвоить одну парадигму, а не делать кашу в голове

1. Берёшь джс
2. Осваиваешь ООП
3. Когда освоишь, начинаешь осваивать ФП на знакомом языке в знакомой среде.
4.???
5. PROFIT

А зачем применять ооп по тюрнингу в лямбда программировании? Вам не кажется что это равносильно «лезть не в свое дело, со своими знаниями»?

Если вы про лямбда выражения, то как по мне они упрощает код. В java такой метод широко используется и почему бы не использовать и во фронтенде. К тому же в ангуляре никто не заставляет так писать код, можно использовать обычный js без аннотаций, лямбда, интерфейсов и всего новомодного. По поводу

«лезть не в свое дело, со своими знаниями»
, я так не думаю. Всё-таки ts разрабатывал Хейлсберг, а у него есть опыт в создании языков програмирования.

Кость, вы явно не поняли о чем речь.

это обычно Backend который согласен делать Frontend, обратная комбинация встречается редко

обратная комбинация это рак для бекенда

А что уважаемые коллеги думаете про Play? Как он в обращении, получше других фреймворков?

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

Ещё один срачетред «бекендщики против фронтендщиков».

он не так планировался, но как-то в это скатился...

Потому что некоторые бекендщики прям как веганы

Зато фронтендщики практически поголовно хипстеры

Я думал только мне так кажется с колокольни бекенда

Зато курсов по фронтенду — тьма... знать бы какие годные ((( особенно интересен js

Frontend community

Что такое , как его осязить , определения и описание плиз приведите. А то жалуетесь непойми на что.

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

Ничего себе слабо выглядят. Что значит слабо ? Рискну предположить что речь идет о некой стандартизации, закручивания гаек и дружном маршировании по линтеру. Где судя по стройности шага и ровности шеренги можно судить на сколько крут тот или иной юнит . К счастью такого нет и надеюсь никогда не будет в мире FE. Скорость устаревания технологий довольно высока и не позволяет сделать один раз и на все случаи жизни и это еще не учитывая обширности понятия FE. Многие области FE не являются новыми, будь то gl , audio и тому подобное, многие топики развивались параллельно и включаются в FE на уже довольно продвинутом уровне , конечно с нуля, не будучи экспертом в том или ином топике пытаться почитать «книгу по фронту» и ожидать того что за 24 часа будешь кодить как бог — глупо.

Где судя по стройности шага и ровности шеренги можно судить на сколько крут тот или иной юнит
стандарты должны быть (и они таки есть), но они могут быть разными — главное качественными! а не такими которую создают излишнюю сложность в угоду крику «вау! это круто!» — это то о чем я говорю, и то почему я называю это сообщество слабым.

Мне сложно так вот навскидку вспомнить хоть один в «угоду» стандарт. Все стандартизируется, все работает.
Напрашивается пример, приведу свой. Когда стабильная сборка с поддержкой канваса вышла (март десятого если не ошибаюсь?) , это было вау и круто, когда все кругом уныло рисовали линии и пытались осилить бейзера — я портировала свои игры написанные под ведроид, сделала маленький фреймвекрк который мало кому оказался понятен. Что тут показательно — технология действительно крутая, есть стандарт и есть демонстрация использования. Но сделать нечто подобное у вчераверстальщика тямки не хватит , фреймверк оказался г**но, эвенты не так хендлит, луп медленный и фпс не тот .. вобщем , дежавю, это все комьюнити слабое, неиначе )

не могу ничего сказать о вашей либе, и на гитхабе у вас из canvas related только gixi.

вы ведь сами только что пожаловались на комьюнити —

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

мне кажеться что нужно или не учитывать часть «сообщества», или просто выделить часть «сообщества.» Просто когда говоришь с FE девом, ты ему про паттерны, а он тебе про то что весь фронт это говнокод, лапша на jQuery и вообще всё это нормально, то понимаешь что так оно и будет говнисто, потому что если человек так делает, то он так и пишет, а другим это всё поддерживать. Не надо ровняться на «вчераверстальщиков», как на FE комьюнити. :)

К сожалению неправильные наблюдения и выводы . «мир фронтенда» надо запомнить )))

К сожалению неправильные наблюдения и выводы
Можно по подробнее? О своих выводах — я ничего не говорил)

Если мышку навести, там стрелкавверхцитируемый показываетя

не удобная совсем фича, лушче бы что бы по клику — страница перезагружалась :D

это сообщение было не в ответ на ваше.

у меня наблюдения правильные, они в принципе инными не могут быть по определению — а в выводах я и не уверен, потому и тему создал

я называю это сообщество слабым

А что им делать ? Парады хороводить, да пресс качать ? Ну слабенькие, беззащитные.. Макеев бледненький стал последнее время, у Дэнчика нервный срыв похоже.. еще многим здоровье удаление пада подорвало . Высылайте витамины, будем исправлять )))

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

Ну не знаю. Ember очень качественный по моему мнению, и развивается. И хорошие аддоны есть (а кто-то их пишет, значит специалисты тоже есть). Да, там встречаются ошибки, но я отношусь к этому с пониманием. Всё-таки opensource, люди тратят время и усилия, и дают результат (что немаловажно, так как идеально можно долго писать и никогда не написать).

Ember — по сравнение с другими очень даже ничего, но что пугает что у него в разы меньше популярности :(

Да, как-то и работы на нем меньше. Хотя в текущем его состоянии, когда ember-cli стал фактически стандартом, работать с ember очень удобно. Недавно я узнал про аддон ember-cli-nwjs, который позволяет писать десктопные приложения, используя node-webkit. Поигрался немного в свободное время — очень интересно. Можно даже писать так, что будет и фронт для веба, и десктопное приложение (где можно работу с файлами например прикрутить) с одних исходников.

Вот Ember Data пока всё ещё не очень. Слишком ограничивает — проще написать API под ember-data, чем наоборот, адаптировать приложение под API.

потому что туманная перспектива самого фронтенда. Когда закончится яваскриптовое безумие и пройдет мода на ангуляры и прочие клиентские извращения — фронтэнд займет то место что занимал еще лет пять назад. И не будет никаких проблем со специалистами, просто потому что проекты перестанут быть в три раза трудоемкими и дорогими только потому что модно писать с явскриптовыми фреймворками при том что конечному пользаку пофиг как там написано лишь бы не тупили мобильные браузеры переваривая сотни калбеков, биндингов и ивентов. Будущее за облачными (то есть бэкэнд) вычислениями и тонкими клентами. Просто потому что проще дешевле и масштабируемее.

.

Ну-ну. От веб-приложения (именно приложения, а не сайтика с рецептами или смех...ками) пользователь ждет такой же отзывчивости, как от приложения десктопного. А для этого как минимум нужен ajax. А фреймворки используют не потому что модно, а потому что когда на странице больше 3х элементов, которые загружаются ajax’ом, начинается АД. Писать без js вообще? Ну удачи там в 90х.

каким чудом аякс обеспечивает отзывчивость? Она зависит от ответа сервака а не от аякса.
экономия трафика? Сомнительно. Во первых народ не на диалапе сидит разницы в загрузке по времени нет (не считая идиотов делающих страницы размером в несколько мегабайт)
а небоьшой выиграш по скорости загрузки компенсируется проигрышем изза открытия фоновых http соединений которые как и любые соединения требуют апаратных и програмных ресурсов.
И кстати щас в отличие от 90х рулят флэт дизайн и гугле стайл — какие вообще там могут быть проблемы с отзывчивостью.
И еще раз — больше всего тупят как раз страницы с яваскриптовыми фреймворками — просто потому что веб перезжает на мобильные браузеры.
И раздражает пользака не загрузка страницы — это привычно и естественно — а когда тыкаешь пальцем а страница не реагирует потому что аякс не отработал еще- не открыл соединение не сходил на сервак не загрузил данные не распарсил json , не распарсил DOM чтобы найти и изменить элементы и т.д..

И кто сказал писать без js? Утрирование — это как правило признак отсутствия аргументации.

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

каким чудом аякс обеспечивает отзывчивость?
Когда жмешь на кнопочку и за 0.5-1с обновляется 1 табличка — это лучше выглядит и удобней, чем когда жмешь на кнопочку, и секунды 4 обновляется вся страница.
а когда тыкаешь пальцем а страница не реагирует потому что аякс не отработал еще
Тут зависит от разработчика (ну и от того, на вчера это писалось или по-нормальному). Например, есть возможность не показывать приложение, пока оно не загрузится. Вместо приложения — спиннер.
Когда жмешь на кнопочку и за 0.5-1с обновляется 1 табличка — это лучше выглядит и удобней, чем когда жмешь на кнопочку, и секунды 4 обновляется вся страница.
Даже не представляю как надо написать чтобы страница грузилась 4 секунды. Если речь об обработке серьезного обьема данных на сервере то аякс тут никак не поможет.
Не надо фантазировать. Подавляющее большинство вменяемо написаных сайтов в инете грузятся за полсекунды секунду без всякого яваскрипта.
Тут зависит от разработчика (ну и от того, на вчера это писалось или по-нормальному). Например, есть возможность не показывать приложение, пока оно не загрузится. Вместо приложения — спиннер.
вы серьезно думаете что пользаку есть до этого дело?
Впрочем вы сами ответили — все зависит от тараканов у голове разработчика. А я вообще то имею ввиду сайты для людей а не для реализации програмистских хотелок.
Даже не представляю как надо написать чтобы страница грузилась 4 секунды
Да легко c2n.me/3CKx616

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

Ember-приложение, с мегабайтами жаваскрипта :) c2n.me/3CKAQhA
А вот и сами мегабайтные js-ки c2n.me/3CKBB6j
URL не скажу, ибо NDA

и что в таком приложении грузилось бы дольше если бы не было яваскрипта?
кстати на моей странице тупят как раз ваши любимые яваскрипты — точнее не ваши а гугловские и яндексовские (счетчики для аналитики) так что низачет

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

еще раз — какое дело до этого конечному пользователю НЕПРОГРАММИСТУ?
а вот владельцу сайта, который переплачивает за подобное усложнение страницы дело есть — его кошелек.
сформировать html на серваке традиционным способом гораздо проще просто потому что нет промежуточных слоев перекодировок данных в json и обратно и прочеего.
Не надо мне впаривать — я начал програмировать раньше чем вы начали под стол пешком ходить — и могу сравнивать все решения. В том числе и клиентские — как раз приходится доделывать проект на флексе за любителями клиентских апликух которых выгнал заказчик.

сформировать html на серваке традиционным способом гораздо проще просто потому что нет промежуточных слоев перекодировок данных в json и обратно и прочеего.
Ой как же сложно использовать готовую библиотеку для сериализации или на худой конец вызвать json_encode
Не надо мне впаривать — я начал програмировать раньше чем вы начали под стол пешком ходить
Если уж мы перешли на личности, то вы уверены, что программировали, а не говнокодили, дедушка?
я начал програмировать раньше чем вы начали под стол пешком ходить
дедуля остыньте )))

После сеньора и эксперта должен идти новый «статус» — мамонт. Дается только за выслугу лет.

«Динозавр» же :) В Глобале когда-то давным-давно такие грамоты давали старожилам

Не надо мне впаривать — я начал програмировать раньше чем вы начали под стол пешком ходить — и могу сравнивать все решения.
і це типу вважати аргументом?

ну вот текущая страница при 22 коментах грузится 1,5 секунды, но тут оптимизировано судя по всему, но и сама страница проще некуда

значит кривой бекенд. Или навесили наверно какой нибудь ORM
или сервак слабоват — по любому яваскрипт тут бы ничем не помог

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

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

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

Приведу пример. Возьмем любую из тем на ДОУ с количеством комментариев 1к+. У меня такие страницы грузятся адски долго. И представьте ситуацию: листаю я страницу, хочу оставить комментарий. Ввожу, отправляю (обычной формой, никакого аякса) и жду еще 10 секунд, пока страница вновь загрузится. И так несколько раз.

Конкретно до того перезагружается или нет — да, пользователю нет никакого дела. Пользователь ожидает результата и отзывчивости. Если равносильно по скорости (аякс или перезагрузка) — то пользователю без разницы.
это касается подавляюзего большинста сайтов. Просто сайтов для людей
Возьмем любую из тем на ДОУ с количеством комментариев 1к+.
ну кто ж им доктор что они грузят тышу коментов на страницу -пагинация бы помогла -форумы вполне справляются — мало кто перечитывает все старые коменты.
А если и так — я бы предпочел загрузить все коменты в чем кадый раз пожгружать — даже если там полкилобайта все равно инет или сервак могут тупить.
Тормоза с подтягиванием коментов в соцсетях при скролинге меня например раздражают — предпочел бы пагинацию.

Но даже если подтягивать аяксом то вполне можно обойтись кодом на jquery — нникаких ангуляров метеоров реактов и прочих для такого дела нафиг не надо и соответственно спецов по ним.

пагинация бы помогла -форумы вполне справляются
На формах линейная структура комментариев. С древовидной сложнее запагинировать. В любом случае это просто пример, когда лучше обновить один элемент, а не тянуть всю страницу заново.
Тормоза с подтягиванием коментов в соцсетях при скролинге меня например раздражают — предпочел бы пагинацию.
Вот тут согласен с вами.
можно обойтись кодом на jquery — нникаких ангуляров метеоров реактов
Можно обойтись кодом на чистом яваскрипте, а не тянуть либу размером с энгулар ради одного метода.
есть дело до того перегружается страница или нет?
есть, можно приятно лицезреть оставшуюся часть сайта, а не мелькание белого экрана и новой отрисовки того что уже есть
вы серезно думаете что конечному пользователю (а их милионы только в нашей стране) никогда в жизни не слышавшего таких слов как яваскрпт фронтэнд бэкенд и т.д. есть дело до того перегружается страница или нет?
Конечно. Это п****ц как раздражает.
Подавляющее большинство вменяемо написаных сайтов в инете грузятся за полсекунды секунду без всякого яваскрипта
Можно примеры со ссылками?

99 процентов посещаемых сайтов — выбирайте любой.

следует различать 99% сайтов, на которых находятся текст, картинки, ссылки и пара кнопок и полноценные веб приложения, у них как бы цели разные. Javascript разработчики не нужны для 99% сайтов, там обойдемся верстальщиками-шаблонистами.

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

согласен, ниша узкая, но прибыльная

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

а какие РЕАЛЬНЫЕ (а не юношеские понты) проблемы с 90ми и PHP?
Вы вообще видели инет в 90х? Сомневаюсь иначе знали бы сколько тогда стоил персональный комп не говоря уже об инете.
Вы как пацанва рассуждающая о жизни в СССр со слов родителей.
Я технарь и предпочитаю обсуждать ТЕХНИЧЕСКИЕ вопросы — «не круто» и прочие «аргументы» оставте для девчонок.
ТЕХНИЧЕСКИХ аргументов в пользу переноса логики приложения на фронтэнд (особенно в эпоху дешевых облачных вычислений) я не услышал. ни с точки зрения техники, ни с точки зрения производительности труда и стоимости, ни с точки зрения требований КОНЕЧНОГО пользователя.

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

Та норм, всегда ж так делали

Цей кейс легко реалізується без перезавантаження сторінки. Я прихильник серверної валідації даних, і на це є 3 причини:
1. Логіку валідації не треба розмазувати тоненьким шаром по трьох підсистемах, а достатньо буде зібрати її в одному місці
2. Фронт не має потужностей та всього того набору даних, щоб зробити валідацію дійсно зручною.
3. Краща валідація — відсутність валідації для кінцевого користувача. Це не означає не те, що її взагалі не треба проводити, а те, що для всіх буде кращим, якщо система буде намагатися по максимуму вгадати, що саме вводив користувач. Машін льорнін і все таке. І це можливо зробити без болю тільки на серверсайді

окей, похоже, у нас абсолютно разная точка зрения, что такое удобство.
возможно, вы даже length для полей не проставляете? Ну, серверсайд ж разберется, не?

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

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

в момент, когда сервис за меня начнет дополнять адрес по данным из похожих заказов, я перейду к конкурентам.
Ви пощось плутаєте. Ваш приклад не з тієї області. Саджест та машін льорнін — різні речі.

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

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

Вы вообще видели инет в 90х?
видел, благо повезло и дома все было
Я технарь и предпочитаю обсуждать ТЕХНИЧЕСКИЕ вопросы
проблемы с 90ми и PHP?
UX страдает как минимум:
— полная перезагрузка режет глаз,
— невозможно создать анимации переходов,
— пагинация — не удобно, удобно елозить колесиком до бесконечности
А если данные которые вы передаете на сайт так же используются в мобильном приложении? тоже шаблон отправите?
Что вы имеете против REST архитектуры кроме «я писал на пхп 15 лет назад и меня до сих пор все устраивает»?
удобно елозить колесиком до бесконечности
Удобно елозить если оно плавно скролится, а не когда страница подгружается ступеньками о которое колесико весьма уныло спотыкается, в большинстве случаев.

Что говорит о скорости вашего интернета, перезагрузка страницы была бы еще хуже

up to 40Mbps.
Конечно, на i5 6600 /16Gb Ram все, как правило, норм. Но это как-то «слегка» жЫрно для странички в интернете!
На более «слабых» устройствах же...

Фейсбук скрол логает исключительно из-за интернета, джс работает куда быстрее чем ваш глаз воспринимает

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

видимо вы не знаете что стоит за вашим юзер экспириенсом

хорошо, но чем бы вы обьяснили, что в одной сетке на ноуте с core i3 1.4Ghz 8Gb и упомянутым выше i5 такая большая разница?
Ну и насчет глаз:
1) DOU: i.piccy.info/...12/103627/1074540/dou.png
2) Facebook: i.piccy.info/...1/254301/1074540/face.png

да уж... не смотрел на ФБ через веб тулз...
но так или иначе сама по себе подгрузка джсом не должна создавать неприятного эффекта, но они там явно перегузили фронт, правда не очень ясно чем...

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

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

мода на фронтэнд пройдет
это не «мода», а «потребность рынка». и не «пройдет», а, возможно, «перестанет быть востребованным»

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

Facebook без Ajax представляешь себе? А Google Maps?

Як говориться в психології, перша стадія сприйняття неминучого — заперечення...

Не пройде мода на фронтенд, поки буде інтернет і ми будемо ходити через HTTP. Теперішній стан справ показує, що JS на фронтенд перетягує майже усю бізнеслогіку, шаблонізацію і т.д. Для бекенда залишається вже не так і багато:
— видати файли, дані з БД, збереження даних
— валідація даних
— безпека, авторизація

Які б ви аргументи не наводили, але таки можна зекономити купу трафіка, процесорного часу сервака, I/O сервака..., коли використовувати нелюбиме вами новомодне SPA, бо раз завантажив базу сторінки — і все, друге звернення дозавантажує тільки те, що раніше не завантажив.

Ще кращі справи із кешуванням даних, бо SPA завантажує зар́аз html-файл, кешує його, і навіть якщо на цьому шаблоні пізніше щось буде динамічно змінюватись — JS може це зробити без завантаження нового шаблона.

Те ж саме стосується авторизації: у SPA вам достатньо раз залогітитись, і далі, якщо вам не треба витягувати конфіденційну інфу з БД або робити якісь зміни в БД, ви вже не будете смикати систему авторизації на бекенді за кожним переходом...

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

Юзеркейс 2: интернет-магазин, требуется реализовать кнопку «в избранное» и «в сравнения»

Юзеркейс 3: интернет-магазин, требуется собирать статистику через google analystic.

Юзеркейс 4: график, отображающий информацию в реальном времени

Юзеркейс 5: разнообразные чаты и прочее

Как бы вы решили эти задачи на чистом html и php (или что там у вас в бэкэнде)?

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

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

Мне на Qt норм, пишу на линуксе, компилирую для мака и винды. Изменения минимальные, например для мака, вместо комбобокса — кнопка на 4 состояния — и то, это не обязательно.

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

начну с не так:
1. для сервисов с высокой посещаемостью — вынос html рендеринга в браузер клиента — ощутимая экономия на серверных ресурсах. Когда содержимое в браузере у каждого клиента — индивидуальное (например его емайл ящик), то закешировать на сервере не получится, из-за бессмысленности.
2. если генерить такой html по каждому клику пользователя (открыл письмо, посортировал по адресатам, нажал ответить и т.д.) то при пиковых нагрузках, когда это делают десятки+ тысяч посетителей — серверных мощностей может перестать хватать, и начнутся — тормоза.
3. SPA для энтерпрайз приложений — гуглить «typical enterprise UI screenshot» и смотреть картинки. У таких приложений посещаемость много ниже чем у «гымайл», но элементы интерфейса очень сильно связаны друг с другом лихими правилами обновления, при этом так же заполнены данными по индивидуальным правилам, фильтрам, и уже запрос и агрегация только данных — недешевы. Облако конечно справится, но за расход процессорного времени — придется платить.

Из примеров стоимости, просто переход на более быструю версию пыха:
— Сколько мы сэкономили в деньгах? Давайте посчитаем. Кластер серверов приложений у нас состоит из 600 с лишним серверов. Снизив использование CPU в два раза, мы получаем экономию примерно в 300 серверов. Добавив начальную цену такого «железа» (порядка 4000$ за каждый) и амортизацию, получаем около миллиона долларов экономии плюс около ста тысяч в год на хостинге!
Badoo перешли на PHP7 и сэкономили $1M — habrahabr.ru/...ompany/badoo/blog/279047

теперь о так:
— уже не один год замечаю как все сильнее тупит gmail.com, даже после того как наконец загрузит скрипты. Особенно это стало заметно в режиме inbox. У меня конечно древняя машинка, на Phenom II x4, но это единственное приложение которое мне об этом напоминает.
— стоимость разработки джс фронтенда много выше серверного рендеринга. при этом чтобы добиться его быстрой работы на смартах — нужно отдельно работать. Правда со смартами отдельная история, там и полный классический рендеринг страниц не годится.

а в итоге, действительно есть откат к проверенным способам. например React позволяет генерить html на сервере, и нередко часть html там им генерится, а часть — в браузере, где потом почти классическим pajax`ом и собирается.

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

Я согласен с Леонидом в той части, что ajax и фреймворки пихают куда не надо. Например, довелось разрабатывать веб фронтенд для платежной системы одного банка. Функционал был достаточно простой. Выбрали счет, выбрали бенефициара валюту сумму платежа и отправили. Все можно было сделать обычными перегрузками страницы с валидацией на серверной стороне за две недели двум человекам. В итоге это паяли три группы индусов специалистов на Angular и все равно мля недоделали за пол года Карл, были баги, страничка загружалась изза обилия слепленного Browseriфаем JS 6mb долго!
Когда дошло до точки невозврата, никто уже не решался пикнуть что мы идем не туда. Что вместо удобства пользователя вышло только хуже. Страница которая могла перегрузиться за долю секунды, грузилась 10 секунд первоначально и потом тормозила изза обилия скриптов.
А мне по большому счету как пользователю ну совершенно пофиг — мне только надо быстро деньги отправить и забыть об этом.

Причем ведь можно и на аяксе, только брать более легковстные либы, типа бекбона, can.js,vue.js, а то и те что поверх jQuery.

Но — надо ж втулить энтерпрайзного уровня! Иначе ж не современно!

Причем читая фронендщиков — и не поймешь что современно то. Пишут что jQuery умер потому что современно дергать голый DOM API, и при этом чуть надо забиндить три поля — муки выбора — ember или angular? Тьху, прибегает советчик, конечно react с reduxом, вот это будет современно!

страничка загружалась изза обилия слепленного Browseriфаем JS 6mb долго
Минифицировать и gzip’нуть не судьба? 6mb легко ужимаются в пару раз минификацией, и до 600кб gzip’ом. А вообще, все кто говорит что фреймворки пихают куда не надо, почему-то оперируют абсолютно дикими случаями.

Это мне напоминает заказчиков, которых кидают все фрилансеры

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

Ну и есть такая еще фича пользоваться лодашем где можно написать обычным джаваскриптом короче.
Ну люди любят как по-проще. Я вот numeral и moment сразу тащу, если нужно работать с форматированием чисел или датами. Минификация делает эти библиотеки ника не весомеее jquery, но работать удобнее и продуктивнее.

вообше-то речь о другом.

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

Эти решения вообще то должны принимать другие люди.

Щось ви нагородили: 6 МБ... 10 секунд... Мабуть розробникам платили за розмір коду, а тестувалось це все з інтернетом через dial-up. Так? А коли згадати за ваш опис ТЗ зі спадним меню і кнопкою «відправити», і за те що вони ще й писали це все пів року, — виглядає як бредятіна повна, м’яко кажучи.

Якщо функціональності там було побільше, ніж єдина формочка, і вони справді писали це все пів року, то думаю це вони робили на першій версії Angular. Для порівняння, можу навести свій сайт, я написав його рік назад на Angular 1.4, функціональність, яку забезпечує JavaScript, приблизно така:
— транслятор Markdown to HTML
— створення тегів з можливістю drag-and-drop
— true-деревовидні коментарі (на ДОУ лише імітація деревовидності), причому із кращою функціональністю, із лінивим завантаженням (з тисячами коментарів зависання б не помітили)...
— підсвічення синтаксису
— ... ще немало дрібних деталей...

У підсумку, мінімізовані файли JavaScript у мене важать аж 340 КБ.

Навіть якщо б вони писали там якусь складну форму, навіть якщо б це була друга версія Angular, і навіть якщо б вони видавали немінімізований developer’ський варіант файлів, все одно це було б мабуть трохи більше 2 МБ...

У меня в команде практиковали переобучение бекенд (java) специалиста под фулстек (java + react/redux). Могу сказать, что практика довольно успешна, спец получился хороший. Главное что бы бекенд программист имел голову на плечах.
пс это я не про себя если что)

А наоборот с JS -> Java + JS были случаи ?

Не слыхал такого. Пытался перетянуть коллегу с node.js на java, но он упирался со всех сил.

тоже не слыхал такого (хотя конечно, такие случаи конечно есть)

и задумывался, почему? пока сам не копнул js, и не попытался взглянуть так, будто бы я не знал джавы. и — я бы на джаву тоже не переходил :)

ЯП — слишком жидкий, статическая типизация, развесистые иерархии классов и интерфейсов, суровая инженерная инфраструктура (да еще с тьмой xml), тьма каких-то бэст практик которым надо следовать, и отсутствие двух столпов JS
наследования через прототипы и функционального программирования frontender.info/...2-functional-programming

Копните луа ... на джс будете плеваться. Жаль не так распространена.

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

язык это способ мышления, а не инструмент.

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

С другой, если человек может писать декораторы в Java и не может в JS, то что-то надо менять в консерватории.

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

Frontend разработка в последние годы развивается бурным темпом, но как показывает текущие состояние дел — в Frontend community явно наблюдаются отсутствие специалистов.
Примером этому могут служить разработка Angular 2 (изначальное создание AtScript который был почти калькой TypeScript, breaking changes в между RC)

Бугага! Автор, на вас так пиво діє, чи що?! Ви це серйозно?! Саме формулювання питання «в Frontend community явно наблюдаются отсутствие специалистов» і далі якимось дивом ви намагаєтесь це аргументувати «изначальное создание AtScript который был почти калькой TypeScript, breaking changes в между RC».

Іншими словами, ви говорите: «щось я бачу погане ком’юніті, бо є брікін ченджес, коли вже був RC». Як перше пов’язане із другим?

Якщо говорити за «хреново, що є breaking changes, коли вже було оголошено RC», то давайте оцінимо що саме зробила команда Angular 2 фактично за 2 роки свого існування, і чи легко було обійтись без breaking changes. Для цього зайдемо й почитаємо Angular 2: FEATURES & BENEFITS

Люди за два роки написали фреймворк, який практично повністю охоплює динамічний фронтенд, відмінну здатність до тестування, хорошу підтримку рідної мобільної розробки, Angular CLI, анімацію, стилі, SEO-оптимізацію, робота офлайн, рендерінг на:
— platform-browser-dynamic (тут дінамік означає, що код не скомпільовано в так званий AoT (Ahead of Time compilation))
— platform-browser (тут вже використовується AoT)
— platform-server
— platform-webworker-dynamic
— platform-webworker

За два роки! І ви кажете що вони хренові спеціалісти, бо є breaking changes? ... Ви б змогли обійтись без breaking changes? Думаю якщо поставити собі самоціль, то це можна забезпечити, тільки то вже буде дуже сумнівне рішення.

К примеру для Java есть куча книг и действительно хороших практик, а вот frontend особо ничего не знаю (разве что JS Good Parts и книга о паттернах от Османи), и развивается довольно в стремном направление рождая не качественные технологии (такие как Angular 1 к примеру) и решения.

Дві величезні різниці є, можна сказати — між ними прірва, коли порівнювати Java vs. Angular (мова програмування vs. фреймворк!). По-перше, джава на п’ять років старша, по друге Java, образно кажучи, сама диктує що вона буде робити і як, і їй не треба приймати правила гри розробників різних браузерів, та самої JavaScript...

Корочше... не серйозно все це.

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

С десктопами и того страшнее.

речь про (не)идеальные инструменты, а потом резко про «хороших специалистов», потом про коммьюнити.
моё икспердное мнение — недовольство происходящим идет изнутри.
не хватает крутых спецов вокруг(признания окружающих крутыми спецами) — проще шифтнуться туда, где «они есть».

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

вся справа в джс. ніхто не хоче їм обмазуватись, коли навколо є купа годних мов

якби фронт можна було писати на чомусь іншому, крім джс — подібних топіків не було б

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

ті ж самі яйця, тільки в профіль

Если TypeScript по сути является надстройкой над js со штуками которые очень удобно было бы иметь в js, то Dart, ClojureScript компилируются/интерпритируются в js. Если по такой логике утверждать что это всё равно тот же js, то любой ЯП это машинные команды, а значит

ті ж самі яйця, тільки в профіль

зависит от того, приводится ли там null и undefined к false.

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

Щоб ти не казав, але з допомогою js набагато легше обмазатись, ніж іншими мовами.
Так то, звичайно, якщо постаратись, то обмазатись можна чим завгодно

специалист от быдлокодера ничем не отличается. Кто для одного чувака специалист, тот для другого быдлокодер. Красота в глазах наблюдателя. Вы еще бы написали вася -бох, а петя — лох, того же уровня будет :) Пишите на asm.js или WebAssembly в хекс редакторе, по-минимуму обмажитесь и будете двигать что вы там хотели двигать вперёд

Отличается. Специалист делает работу. Быдлокодер — начинает жаловаться на тяжелую жизнь. И язык плохой, и папередники сволочи неправильно написали.

Пишите на asm.js или WebAssembly в хекс редакторе
Зачем мне это? Я в достаточной мере знаю js, чтобы не парясь писать на нём. Ну и конечно не без любимого фреймворка (Ember).

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

Та уж лучше так. Хоть работу делают.

так это же человек-паук! он плетёт паутинку из быдлоспагетти и отличается от остальных ещё хорошей памятью на большие полотнища текста. Это его один из немногих прокачаных скилов. Он становится супермэном на проекте потому что все остальные в его паутинке уже давно запутались и зовут человека паука при каждом чихе, что раздувает самооценку нашего героя.
При любом удобном случае человек паук чморит своих коллег и всячески показывает своё превосходство. Суперсила в том, что его нельзя уволить, иначе всё рассыпется.
Видели таких?

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

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

Я предпочитаю js, но я же не пишу на форуме «обмазываться джавой» в темах про джаву.

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

Я вообще не лезу в темы не своих технологий. Тема про фронт (правда программирование фронта — это js). А ветка комментариев — про обмазывание.

с приходом web assembly и transpilers это уже не так даже в вебе. А фронт ведь есть не только в вебе, Антон (ТС) это упоминает в комменте ниже, а тема про фронт вообще, насколько я понял.

и не только про js a про сферических фронтенд котят в вакууме
Согласен, ветка того стоит, обмазывание сферических фронтенд котят в вакууме это наверное очень весело ахахаха

фронтенд не только джс, и проблема больше с сообществом а не инструментом, как говорится плохому танцору ноги мешают

вы про среднюю температуру по больнице? да, теперь доходит. Кому-то наверное нужна и такая цифра :)

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

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

в том то и дело, что я не делал анализ, был бы анализ то статью писал бы.

просто субъективное мнение. многие best practices во фронтенде лучше вообще никогда не использовать за редкими исключениями

в других комьюнити я такого ужаса не замечал, ну разве что старое РНР комьюнити, оно конечно и сейчас живет, но новое вполне адекватное

многие best practices во фронтенде лучше вообще никогда не использовать за редкими исключениями
Классно, давайте поговорим об этом подробнее! Думаю будет очень всем интересно, какие именно практики и в каких случаях лучше не использовать, кто их использует в коммьюнити «назло маме», почему так получается, и как сделать так, чтобы стало всем лучше.

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

понял, спасибо.

Примером этому могут служить разработка Angular 2 (изначальное создание AtScript который был почти калькой TypeScript, breaking changes в между RC)
да, видел, обсуждали выше
React+Redux best practices (inline стили, использовать Redux store для хранение информации о статусе запроса)
а можете по-подробнее про то где там inline cтили кто использует и почему плохо использовать Redux store для хранения информации о статусе запроса (я просто не работал с Redux, вот и интересуюсь). Погуглил — не нашел так сразу.

React сообщество предлагает использование инлайн стилей через определение объектов, главный аргумент — чтобы все было JS. из реальных аргументов — это решает проблему с тем что по ошибки стили не назначаться на другой DOM элемент.

предлагают их определять JS объектом (но только в реальности CSS удобнее для этого).

в реальности редко когда хватает одного набора стилей, и часто нужны делать комбинации наборов, в CSS это все делается довольно просто и удобно, в JS тоже можно, но выглядит не очень. в конечном счете у вас будут стили написанные через JS, и когда вам надо будет использовать не React (он далеко не для всех задач удобен), а что-то другое, то у вас будет куча проблем.

на эту тему был холивар на медиум в итоге пришли что inline стили хороши для custom layout, когда css не справиться, но собственно в таких случаях всегда JS использовали...

----
есть такой best practice по работе с AJAX и Redux запихивать AJAX в отдельный action, а потом когда приходит ответ, обычно вызывается еще action что все прошло хорошо и данные запишутся в store, или запишется ошибка. в итоге для каждого AJAX создают три поля: isLoading, error и data. вроде норм, но есть маленький момент, store в redux это глобальное хранилище данных клиентского приложения, а состояние об ошибки запроса или его выполнения вы в 99% случаях использовать будете в одном едином компоненте, а каждое изменение в store ведет как правило к пересозданию всех компонент, а в итоге изменится только один и маленький.

а теперь главный вопрос — зачем засорять глобальный store локальными данными?? и это считается best practice

зачем засорять глобальный store локальными данными
Так стор это и есть слепок текущего состояния. У какого-то компонента в конкретный момент времени будет isLoading, у какого-то нет. В чем проблема?

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

Вообще-то да. Стор — это именно слепок состояния, данные, на основе которых реакт-приложение строит текущее DOM-дерево.

Условно говоря, реакт-приложение это функция, которая на входе принимает данные, а возвращает DOM. И как раз благодаря тому самому реактовскому virtual-DOM дереву это выходит вполне себе быстро и не накладно.

Конкретно по хранению состояния отдельного компонента в сторе можно пользоваться простым правилом: если это состояние важно для других компонентов, то да — в стор, если нет — то в локальный стейт компонента. Но это скорее идеологический вопрос. Вот здесь есть пару хороших линок redux.js.org/...ng-state-only-redux-state
Рекомендую ознакомиться, прежде чем надувать щеки и корчить из себя эксперта, развешивающего ярлыки.

вы путаете теплое с мягким, почитайте определение store что ли.

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

хранилище данных, и оно именно так и используется в redux, единственное что они сами не дают определения и оперируют «хранилищем состояние», но в данном случае оно взаимозаменямо на данные

в данном случае оно взаимозаменямо на данные
В данном случае “хранилище данных” это просто ообщенный термин.
В общем, похоже здесь без цитат из доки не обойтись:
The whole state of your app is stored in an object tree inside a single store.
redux.js.org/#the-gist
A store holds the whole state tree of your application.
redux.js.org/docs/api/Store.html
State (also called the state tree) is a broad term, but in the Redux API it usually refers to the single state value that is managed by the store and returned by getState(). It represents the entire state of a Redux application, which is often a deeply nested object.
redux.js.org/docs/Glossary.html#state

Одним словом: хранилище данных которое хранит ТЕКУЩЕЕ СОСТОЯНИЕ ВСЕГО ПРИЛОЖЕНИЯ. В этом и идея редакса — есть слепок состояния, скармливая который функции-отрисовщику (например реакту) можно получить кусок DOM и показать его в браузере.

то есть с «хранилищем данных» вы согласились, хорошо.
а теперь самое интересное, любо хранилище данных хранить

ТЕКУЩЕЕ СОСТОЯНИЕ
данных, но вы заменяете на «всего приложения», тем самым навязывая частный архитектурный подход который вы видели и тем самым сужая то чем есть redux.
отличие redux в том что если есть ссылки на ветку дерева старых данных оно будет уничтожено, ну еще store реализует pub (action)/sub.

ладно, это уже спор о терминах, главное что вы сами подтвердили не состоятельность «best practice» с isLoading/error/data

It represents the entire state of a Redux application
the entire state of a Redux application
the entire state

не, это я объяснять не стану. почитайте за архитектуры, попробуйте проанализировать систему на более высоком уровне

Для особо внимательных продублирую ссылку
redux.js.org/...ng-state-only-redux-state

Do I have to put all my state into Redux? Should I ever use React’s setState()?

There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component’s internal state. Find a balance that works for you, and go with it.

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

There is no «right» answer for this
в большинстве случаев худший вариант записали в «best practices»
в большинстве случаев худший вариант записали в «best practices»
Почему он худший? и каковы объективные причины минусов?

более высокая стоимость разработки, увеличение сложности системы на ровном месте, «мусор» в store (это более субъективная)

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

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

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

обычно «best practice» то что делает системы в большинстве случаев лучше, а не наоборот

ну во-первых предсказуемость поведения значительно облегчит поддержку приложения. Насколько это может быть важно для бизнеса, я думаю, объяснять не надо?
во-вторых, более детализированные состояния и переход между ними могут пригодится в любого рода онлайновых редакторах, например. В любых визардах и т.д. где наличие кнопки UNDO для пользователя будет очень жирным плюсом и киллерфичей с точки зрения бизнеса.
Именно потому уровень детализации состояния целиком и полностью на совести разработчика и именно потому этот уровень (низкийи или высокий) нельзя однозначно отнести в "best practice"/"worst practice".

Антон, Саша, спасибо за конструктив ребята! Почти не поссорились и масса полезных ссылок и информации. Я вот почитаю, поучусь.

спасибо! чето я тупанул, надо было это сразу делать!

Підписатись на коментарі