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

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

Evolution > revolution.

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

Такого рода система требует упор на инкапсуляцию и обратную совместимость по API и данным. Говоря конкретно:

• сетевое API должно быть контролируемым, чтобы обеспечить обратную совместимость. Предлагаемый подход вносит слишком много факторов, влияющих на API
• то, что локальные вызовы и удаленные — это одно и то же — опасное заблуждение. Удаленные вызовы имеют свойство выполняться произвольное время, не выполняться вообще, требовать повтор запроса, при этом клиент не может знать, выполнен ли предыдущий или нет. Насколько я в курсе, пока никто не придумал унифицированную обработку ошибок, пригодную и для локальных, и для удаленных вызовов.
• передача кода по сети значительно усложняет соблюдение обратной совместимости. Никто же не знает, что этот код, пришедший от клиента, будет вызывать?
• Сетевые запросы имеют свойство "застревать" и доходить до получателя сильно позже того, как их отправили. Основные причины — использование очередей сообщений, хитрые механизмы передоставки, CQRS. Так что подход "сначала шлем модель, потом упакованные данные" — не универсален.
• Сложность. HTTP как основной протокол передачи данных прижился благодаря исключительной простоте, гибкости и расширяемости — его смогли приспособить для решения очень многих задач. Описанная в статье "универсальная платформа" может и не оказаться настолько расширяемой либо может оказаться слишком сложной для понимания массами — и что тогда?

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

Используйте вот этот Gulp конфиг.

Даже наскреб каких-то Gulp конифгов для быстрого старта.

Блин, да выучи ты уже галп и напиши свои конфиги. "Я шеф повар и я уже 10 дней не могу приготовить простейший обед. В мусорке я нашел несколько рецептов, смешал их и у меня ничего не получилось."

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

Таких как он золотая рыбка отправляла подумать над разбитым корытом.

Я вот то же в последние пару недель столкнулся, решил выбрать для проекта хорошую библиотку для рендеринга UI(Мочи больше нет рендерить все руками на JS). Это просто зоопарк. Я попробывал React.js, React +TS, Angular.js, Angular 2, emder.js. knockout.js и прочитал еще о такой куче всего что голова кругом. И все они не совместимы и выбрать что-то одно это как хождение по миному полю.

Напомнило:
<_valexey_> jezzarax: там порог вхождения выше
<_valexey_> тебе на asp.net'е hello world настрогать за 10 минут научиться можно (8 минут на запуск студии, 2 на кодинг)
<_valexey_> на java такое не прокатит
<_valexey_> пока скачаешь одну библиотеку, пока другую, пока их xml конфигом на полметра склеишь, пока маппинг для hibernate настроишь, пока базу нарисуешь, пока веб-сервисы поднимешь
<_valexey_> вроде и hello world пишешь, а уже две недели прошло и всем кажется, что это учетная система для малого бизнеса

Чувак просто еще не дорос до Тех Лида (что довольно странно с учётом заявленного опыта).
Тех Лид понимает, что зачем, он не обращает внимания на шелуху, он умеет говорить 'нет'. Потому как он уже все эти мучения прошел не по разу и звоночки в технологиях видит. Это я к тому, что учиться надо не ноя а стиснув зубы и думая головой.

П.С. В TS упаковка в один файл это удобство для редких случаев, когда именно что надо упаковать все или ничего. Это не его задача, в первую очередь он выдает файлы .ts => .js один к одному, потому и настройки упаковки там особой не будет.
П.П.С. Ну и еще автор оригинала просто и привык к C# где экосистема слаженная и 90% боилерплейта за тебя уже написано. JS к этому тоже идет, но понадобится пару лет пока все индастри стандарты и конвенции утрясутся.

я вообще-то в основном собирался получить удовольствие, так что настроился на «zero-tolerance mode» (прим. переводчика: рука не поднялась переводить такую чудесную фразу). Как только что-то начинало раздражать, я бросал это и искал другое, лишь бы ничего не мешало.

Собственно вот и вся проблема.
И это еще неплохо, что автора не раздражало набирать текст на стандартной клавиатуре, а то до сих пор бы и статью свою не написал. Ведь столько возможностей — сенсорная, механическая одного вида, механическая другого, виртуальная, оптическо-лазерная… методы набора опять же — свайп, т9… способы подключения — вайфай, блютуф, провод. И во всех вариантах что-то раздражает, не так ли? Всюду надо прилагать усилия:)

Надо что-то сделать — надо брать первый попавшийся распространенный инструмент и делать, по пути соглашаясь на неудобства и компромиссы, т.к. «миллион леммингов не может ошибаться, по крайней мере сильно». А искать идеальный вариант — это никогда не закончить проект. Мы знаем. Мы так уже 10 лет не можем закончить свой pet-project, но при этом назаканчивали навалом огромных проектов для заказчиков.

Мне кажется что зло не в модели spa, она является естественным продолжением сайтов пологающихся на новые возможности браузеров. Проблема в простоте среды, в которой создать новый фреймворк проще чем написать регулярку для email ;) Но, что не менее важно, в этом же и плюс. Все лишнее можно не использовать и остаться один на один с нодой и браузером.

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

Может для кого-то быстрее и качественнее будет сделать на NodeJS + MongoDB + AngularJS, а вы сразу его выпендрежником посчитайте и собеседование для него усложнится или станет непроходимым вовсе. А все почему? Потому, что вы ищите PHP разработчика и хотите использовать везде в своих проектах MySQL, но в вакансии нигде не написали об этом? А может ваш кандидат плохо знает эти инструменты, но в совершенстве овладел стеком RoR + PostgreSQL?

И почему вы считаете, что MySQL прост? Наверняка есть люди, которые никогда с ним не работали и для них простым будет тот инструмент, с которым они всю жизнь работали, возможно это будет даже Oracle или Firebird. Они, на ваш взгляд, сложнее или проще чем MySQL?

Модный инструмент — это не всегда только модный инструмент, который люди используют только ради того, чтобы использовать.
Я бы, например, использовал для упомянутой вами выше задачи именно MongoDB в качестве СУБД, т.к. довольно хорошо знаю как с ней работать и она умеет реплицироваться и шардиться из коробки (чем не может похвастаться MySQL). Если реплика сдохнет, то это вообще не проблема. А для надежного шардинга можно использовать схему с shard + replica set. Если сдохнет реплика в шарде, то это опять же не проблема, а вероятность выхода из строя целого шарда, например, с тремя репликами — уже маловероятна.

Какое-то предвзятое у вас отношение к тем кто умеет или хотя бы знает, что можно использовать какой-то не стандартный на ваш взгляд (PHP + MySQL) набор инструментов, который по мнению кандидата будет подходить лучше для решения этой задачи. Не всегда же кандидаты глупее вас. Тем более, что это тестовое задание же, в реальности человек придет в проект с уже подобранным стеком технологий и будет решать задачи на нем (если вы, конечно, не ищите первого человека в проект, который еще не начат).

На собеседованиях я люблю спрашивать простую задачку: вам надо сделать аналог bit.ly, у вас есть три ЦОДа в трех странах. С чего вы начнете?
После пары минут страданий люди начинают выбирать базу данных и почти никогда это не бывает чертов простой MySQL, постоянно пытаются туда засунуть любое говно которое они хотят попробовать лишь вы выпендриться.

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

Да, простите, оговориться надо было сразу — последние 1.5 года я работаю в стартапах. Несмотря на сильные команды, людей мало и все решают всё. Обычно у нас нет тикетов которыми можно кидаться в админов и лоад-тесты крайняя редкость, обычно всё подчиняется парадигме "bug driven development" и это нормально в условиях стартапа когда бежать надо максимально быстро.

И деньги в стартапах, в общем то, общие.
Отсюда и мировоззрение которое коробит анусы и поджигает лица… Или как то так.

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

Что с вами не так? Берите инструменты которые вы знаете. Разобраться во всём нереально.

Я фуллстак веб-разработчик и лид в течении последних трех лет с резюме из двух листов А4 со списком технологий прочитав которые люди не верят что я это всё умею. Идиотизм ситуации которую описывает автор заключается не в том что сейчас огромный зоопарк технологий, а в том что некоторые программисты до сих пор не научились говорить «нет» своим желаниям запихнуть очередное хипстерское говно в проект.

На собеседованиях я люблю спрашивать простую задачку: вам надо сделать аналог bit.ly, у вас есть три ЦОДа в трех странах. С чего вы начнете?
После пары минут страданий люди начинают выбирать базу данных и почти никогда это не бывает чертов простой MySQL, постоянно пытаются туда засунуть любое говно которое они хотят попробовать лишь вы выпендриться.

А проблемы начинаются когда ты их спрашиваешь, окей, вот твоя MongoDB которую ты выбрал. Как ты будешь реплицировать данные на три ЦОДа? Мало кто знает что у неё есть replica-set. Еще меньше людей смогут ответить на вопрос «Окей, что делать если реплика развалилась и одна из нод встала в позу»?

Хватит ныть. Берите те инструменты которые вы знаете.

Вот я тоже веб-разработчик. Где-то года три-четыре назад мне понадобилось для сайтика клиента сделать простенький виндовый нотификатор, чтобы висел в трее, опрашивал сервис по хттп и сигнализировал в случае чего. И ничего, что вы там сверху написали, не произошло, несмотря на то, что весь мой опыт программирования приложений под винду остался в 90-х, в школьных временах.
Я решил что сделаю всё на Visual Basic, поставил студию или что там, и следовал простым мануалам и примерам. Наверняка задача решается специалистом за час, мне понадобился рабочий день, но всё работало.
Это и значит, что инфраструктура и стек технологий — хорошие. Когда ты берёшь простой инструмент (знаете, для простых задач как правило удобно использовать простой инструмент) и делаешь простые вещи без магии и плясок с бубном.

Действительно ли использование всех этих велосипедов является необходимым требованием для разработки?

Фреймворки-всего лишь инструмент. И то что вы выпали из нового потока инструментов не закрывает вам дорогу в веб. Нужно выбрать какой-либо фреймворк из доступных и начать копать в нем.
П.С. взгляд со сторы не веб разработчика.

Именно.

9 лет опыта веб-разработчиком, но три года назад полностью ушел в 3д-графику — сделал из хобби работу.
Все читаю хабр и постепенно понимаю, что вышло столько нового всего, что черт ногу сломит и мне уже назад не вернуться — я капитально устарел в области веба.
И даже разбираться во всех этих велосипедах совсем не хочется — я хочу фырфырфыр и jquery/php/mysql.

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

У меня есть традиция, каждый год, в декабре я переписываю свои ERP-boilerplate`ы на свежий стек. И каждый раз надеюсь что это проживёт дольше чем год. Например в этом декабре, к своему удивлению выкинул из стека Redux и заменил на Baobab.js. Хотя ещё в ноябре думал что Redux это лучшее что может быть для организации архитектуры React приложений.