Поддерживаю Python, он хорош для целей обучения. А еще я бы советовал перенести задачи из плоскости «как бы это написать на этом языке?» (неважно какой) в плоскость алгоритмических или даже прикладных.
Скажем составить UDP сервер-биржу, которая бы позволила выторговать балы или даже небольшие деньги. «Живые» задачи вызывают здоровый интерес, позитив, а у некоторых даже жажду знаний (желание заниматься этим в не учебное время).
С таким же успехом можно сравнить и vuejs. (сравнивать с angular1 — это не справедливо)
Вы сравниваете «горячее» и «круглое», потому как angular это уже огромная инфраструктура, в то время как react — это только представление, а redux — это менеджер состояний.
Считаю что redux в этом смысле больше следует философии UNIX, чем концепция «давайте сделаем все в одном».
Описание экшенов и прочего — это скорей элемент бизнес-логики чем интерфейсный. Тем более это дает вполне приятно тестировать эту самую логику.
Но если вам не нравиться redux — есть например altjs (mutable state) или другие имплементации flux.
Некоторые компании делают немного иначе. Сначала подготавливают ui-kit (отрисовывают, делают компоненты, тестирую отдельно каждый). А потом в своего рода grid устанавливают их по позициям, прописывают их взаимодействие (не обязательно даже использовать фреймфорки вроде vue/react и другие).
Все же как приятно работать с готовым набором UI, а не генерировать грабли, которые снова ломаются при изменениях.
Ну а репозиторий своих компонентов для веб интерфейсов, для серьезного проекта, наверное должен быть всегда. Иначе просто не рационально делать / собирать фронтенд из горы граблей.
Приведу несколько кейсов (кое-что реализовывал):
1. ваши пользователи любят вайбер (не знают что такое slack или telegram), и вам нужно частенько посылать им смс (по их же подписке), почему бы не перевести это в чат?
2. автоматизированный диалог, пользователь нажимает на кнопку — у него пополняется (или списывается) баланс в внутренней системе (скажем кликнул «выполнил задачу»)
Ну а придумать можно еще много чего. Возможностей гораздо меньше, чем скажем в телеграмме, но тоже не плохо.
Согласен, процедура регистрации выглядит довольно странно, но в моем случае я получил доступ к PA почти сразу.
А далее уже можно создавать несколько ботов.
Как и указал TimsTims — сначала нужно чтобы пользователь подписался на страничку.
Но процесс можно упростить, скажем можно дать пользователю специальную «глубокую» ссылку. Тогда вы точно будете знать кто и откуда пришел, и тогда уже по ID проверять его статус онлайн/офлайн и отсылать сообщения.
смотря что вы имеете ввиду.
Eсли написания лапши на ____ (подставьте свое название, в формате jquery, «свой каркас», etc.) — это я наблюдаю каждый день.
Если long running app, где утечки памяти критичны, где нужно использовать любую возможность (я имею ввиду техническую), если она есть — то не вижу.
по большей части с вами согласен, но есть одно но — как только оговорил Flux все вспомнили react. ))
Ведь есть кейс «без angular/react» (без view слоя, то есть со своим) и c flux.
Ну да и описывать понятие «калькой» — тоже не очень:
Shadow DOM (теневой дом) — https://www.w3.org/TR/shadow-dom/
Virtual DOM — https://habrahabr.ru/post/256965/
Могу предположить что если вы начали 10 лет назад, то писали код для популярного в те времена IE 6.0,
если смотреть в этом ключе — то ваша точка зрения понятна.
Но 21 веке — рассматривать ShadowDOM как «плюс» а не «стандарт», уж извените, звучит печально.
Если отвечать по делу:
возможно вы не заметили, я не упоминал React, и да многие частенько (в том числе и я) используют архитектуру Flux без React-а (потому что она что-то больше чем биндинги).
На абсолютную истину не претендую, но на данный момент я склоняюсь к архитектуре flux.
Появилось чувство что с ней приложения становятся «более полноценными».
По поводу производительности, согласен с комментарием выше (стоит учесть, что никто не обезопасит от написания кривого кода на любой кодовой базе):
https://habrahabr.ru/post/310142/?reply_to=9810878#comment_9810618
Ничего не имею против Angular2, но во многом использовать его в дальнейшем можно:
— в старых проектах в которых он «уже есть»
— в новых, если команда не знает ничего кроме angular
Скажем составить UDP сервер-биржу, которая бы позволила выторговать балы или даже небольшие деньги. «Живые» задачи вызывают здоровый интерес, позитив, а у некоторых даже жажду знаний (желание заниматься этим в не учебное время).
Вы сравниваете «горячее» и «круглое», потому как angular это уже огромная инфраструктура, в то время как react — это только представление, а redux — это менеджер состояний.
Считаю что redux в этом смысле больше следует философии UNIX, чем концепция «давайте сделаем все в одном».
Описание экшенов и прочего — это скорей элемент бизнес-логики чем интерфейсный. Тем более это дает вполне приятно тестировать эту самую логику.
Но если вам не нравиться redux — есть например altjs (mutable state) или другие имплементации flux.
Все же как приятно работать с готовым набором UI, а не генерировать грабли, которые снова ломаются при изменениях.
Ну а репозиторий своих компонентов для веб интерфейсов, для серьезного проекта, наверное должен быть всегда. Иначе просто не рационально делать / собирать фронтенд из горы граблей.
На данный момент таких возможностей нет. В апи сообщения отправляются по id пользователя. Но есть публичный чат — в нем сообщения видны всем
1. ваши пользователи любят вайбер (не знают что такое slack или telegram), и вам нужно частенько посылать им смс (по их же подписке), почему бы не перевести это в чат?
2. автоматизированный диалог, пользователь нажимает на кнопку — у него пополняется (или списывается) баланс в внутренней системе (скажем кликнул «выполнил задачу»)
Ну а придумать можно еще много чего. Возможностей гораздо меньше, чем скажем в телеграмме, но тоже не плохо.
А далее уже можно создавать несколько ботов.
Но процесс можно упростить, скажем можно дать пользователю специальную «глубокую» ссылку. Тогда вы точно будете знать кто и откуда пришел, и тогда уже по ID проверять его статус онлайн/офлайн и отсылать сообщения.
Eсли написания лапши на ____ (подставьте свое название, в формате jquery, «свой каркас», etc.) — это я наблюдаю каждый день.
Если long running app, где утечки памяти критичны, где нужно использовать любую возможность (я имею ввиду техническую), если она есть — то не вижу.
Ведь есть кейс «без angular/react» (без view слоя, то есть со своим) и c flux.
Shadow DOM (теневой дом) — https://www.w3.org/TR/shadow-dom/
Virtual DOM — https://habrahabr.ru/post/256965/
И каким боком тут вообще view layer? или react?
если смотреть в этом ключе — то ваша точка зрения понятна.
Но 21 веке — рассматривать ShadowDOM как «плюс» а не «стандарт», уж извените, звучит печально.
Если отвечать по делу:
возможно вы не заметили, я не упоминал React, и да многие частенько (в том числе и я) используют архитектуру Flux без React-а (потому что она что-то больше чем биндинги).
Появилось чувство что с ней приложения становятся «более полноценными».
По поводу производительности, согласен с комментарием выше (стоит учесть, что никто не обезопасит от написания кривого кода на любой кодовой базе):
https://habrahabr.ru/post/310142/?reply_to=9810878#comment_9810618
— в старых проектах в которых он «уже есть»
— в новых, если команда не знает ничего кроме angular