Здравствуйте, Ikemefula, Вы писали:
I>Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.
...используя зоопарк JS-технологий
Беда JS в том, что он никак не войдёт в эпоху взросления, эдакий "вечный студент". Собственно, именно то, что в итоге погубило когда-то Бейсик (хотя были весьма взрослые для того времени диалекты языка, на уровне Паскаля и Си)
Здравствуйте, Mr.Delphist, Вы писали:
I>>Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.
MD>...используя зоопарк JS-технологий
Что за зоопарк JS-технологий?
MD>Беда JS в том, что он никак не войдёт в эпоху взросления, эдакий "вечный студент". Собственно, именно то, что в итоге погубило когда-то Бейсик (хотя были весьма взрослые для того времени диалекты языка, на уровне Паскаля и Си)
Взросление началось уже давно, как на фронтенде, так и на бакенде. Что именно тебя не устраивает?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Ikemefula, Вы писали:
I>>Жээс уже давно уходит от динамической типизации. Его фишка в том, что веб приложения можно писать целиком на нем, а не использовать зоопарк технологий.
MD>...используя зоопарк JS-технологий
MD>Беда JS в том, что он никак не войдёт в эпоху взросления, эдакий "вечный студент". Собственно, именно то, что в итоге погубило когда-то Бейсик (хотя были весьма взрослые для того времени диалекты языка, на уровне Паскаля и Си)
Видмо твое знание JS осталось на уровне стандарта ES3 и IE6. Сейчас в ходу уже ES6+, Node и TypeScript.
Здравствуйте, Ikemefula, Вы писали:
I>>>Что за зоопарк JS-технологий? S>>node_modules. Ну, например. I>node_modules это фолдер, куда зависимости складываются. Kahan это библиотека. Их много, т.к. нод очень популярный.
Одним словом — зоопарк.
Здравствуйте, Sheridan, Вы писали:
I>>>>Что за зоопарк JS-технологий? S>>>node_modules. Ну, например. I>>node_modules это фолдер, куда зависимости складываются. Kahan это библиотека. Их много, т.к. нод очень популярный. S>Одним словом — зоопарк.
Очевидно, нет. Веб приложение, где и дотнет и жээс, гораздо труднее в разработке. Например, потому, что нет шансов вынести общий код и его придется дублировать.
Здравствуйте, Ikemefula, Вы писали:
S>>Одним словом — зоопарк. I>Очевидно, нет. Веб приложение, где и дотнет и жээс, гораздо труднее в разработке. Например, потому, что нет шансов вынести общий код и его придется дублировать.
Ойвэй, так много, так много. Умопомрачитель, невообразимо много. Ажно все структуры данных, которые фронт и бак между собой перебрасывают. Да и то только в том случае, если хочется секса с трансляцией json в структуры а не работы с ним как с объектом.
Здравствуйте, Lazytech, Вы писали:
L>Оказывается, сделать простейший HTTP-сервер на Node.js не сложнее, чем на Flask (который считается простым).
Один опытный JavaScript-программист ещё во времена DHTML 4.0 мне тогда ещё неопытному в 1998 году говорил, что на JS можно сделать всё. И это реально правда даже по меркам того времени.
Здравствуйте, Maniacal, Вы писали:
M>Один опытный JavaScript-программист ещё во времена DHTML 4.0 мне тогда ещё неопытному в 1998 году говорил, что на JS можно сделать всё. И это реально правда даже по меркам того времени.
Я слышал, что в наше время JavaScript-движки стали настолько хороши, что переписывание кода с JavaScript на C или C++ иногда дает прирост по скорости всего в 10-15%. Хотя, насколько я понимаю, JavaScript охоч до памяти...
Здравствуйте, Sheridan, Вы писали:
S>Ойвэй, так много, так много. Умопомрачитель, невообразимо много. Ажно все структуры данных, которые фронт и бак между собой перебрасывают. Да и то только в том случае, если хочется секса с трансляцией json в структуры а не работы с ним как с объектом.
Вся инфраструктура дублируется. Если нужен SEO или что навроде — фактически, два бакенда, жээс и дотнет. Валидация — дважды.
А раз все это дважды, то и тестов в два раза больше.
Теперь нужно приседать с планированием и тщательно трекать зависимости, т.к. в общем случае один деввелопер ни одну фичу сделать не может. Нужно два — бакенд и дотнет. Или искать других, дороже. Фуллстеки как правило хорошо знают только одну часть и сносно — другую. Далеко не везде это приемлемо.
Как следствие — геморрой с АПИ.
Nodejs это неплохо для сервисов которые имеют простую логику, учитывая масштабируемость для бедных из коробки. Например, порывшись на помойке(NPM), можно быстро соорудить бота для телеграмм в режиме "вопрос-ответ". Если бота настигнет успех, то можно будет горизонтально масштабироваться тупым наращиванием инстансов. Быстрота, красота, перспективы..
Как только логика усложняется, так сразу начнётся адъ и Израиль. Невозможно сделать серию запросов, например к корпоративной БД, с кучей данных и зависимостей, не сойдя с ума от спагетти из коллбеков/асинков. Конечно можно написать без спагетти, но язык не просто этому способствует, он практически заставляет это делать. Уже в четвёртой строчке примера от ТС выросла первая макаронина. Можно конечно простую часть типа обёртки на нём написать и дальше мутить микросервисы на Java/C#, но зачем плодить сущности в технологическом стеке компании? Понаиспользуют модных штук, а сеньёр девелопер потом еб..
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, AleksandrN, Вы писали:
I>>>Твои действия? Ну наколупаешь ты на сваггере чего, а дальше что? Дальше все равно придется ждать пока бакенд соизволит взглянуть на этот тикет и реализовать все что нужно.
AN>>Требовать описания API, собрать команду для обсуждения.
I>Ну собрал, ну обсудили, убедились что твой вариант годный.
Для того, что бы убедиться, что реализация интерфейса в одной из частей системы правильная, нужны автоматические тесты.
I>Жди, пока другие закончат свои важные дела или переключайся на другую задачу.
До того, как будут закончены все части, интеграционное и системное тестирование проводить будет затруднительно и нужны будут заглушки. И нужно перед началом разработки разбить каждую часть на подзадачи и команде договориться о сроках, когда будут готовы части, позволяющие произвести предварительное интеграционное тестирование. Как вариант — выделить одного человека, который будет заниматься организацией взаимодействия частей системы.
Но это больше организационный вопрос, чем технический.
Можно использовать кодогенерацию, а разработчики фронта и бэка прикрутят сгенерированный код к своей части. Инстументы для этого есть и для REST и для для других способов взаимодействия.
I>>>Если АПИ на жээсе, ты просто реализуешь это самое АПИ. Если бакендов не устраивает — создадут себе тикет и поправят, если нужно. А большей частью и не нужно.
Ты же сам писал, о разделении ответственности: — "обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа". А теперь пишешь, что фронтендщик полезет бэк исправлять.
Один язык и на фронте и на бэке — удобно, но на прорыв не тянет.
I>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить.
Ты написал, "АПИ не готов", а не "реализация АПИ не готова". Интерфейс и реализация интерфейса — это не одно и тоже. Я тебе именно про интерфейс и писал, т.к. в первом сообщении было именно про него написано.
Здравствуйте, TimurSPB, Вы писали:
TSP>Как только логика усложняется, так сразу начнётся адъ и Израиль. Невозможно сделать серию запросов, например к корпоративной БД, с кучей данных и зависимостей, не сойдя с ума от спагетти из коллбеков/асинков. Конечно можно написать без спагетти, но язык не просто этому способствует, он практически заставляет это делать. Уже в четвёртой строчке примера от ТС выросла первая макаронина. Можно конечно простую часть типа обёртки на нём написать и дальше мутить микросервисы на Java/C#, но зачем плодить сущности в технологическом стеке компании? Понаиспользуют модных штук, а сеньёр девелопер потом еб..
Насколько я понимаю, разработчики на Node.js уже несколько лет как достаточно успешно борются с callback hell:
Я скипнул, поскольку ты вырезаешь серединки фраз, любуйся:
AN>Ты же сам писал, о разделении ответственности: — "обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа". А теперь пишешь, что фронтендщик полезет бэк исправлять.
Ты вырезал серединку, а вот выделеное скромно пропустил:
С ноджээсом получилось выделить промежуточный слой, АПИ, за который отвечают и те и другие. Особых знаний не требуется, кроме хттп — надо представлять HTTP протокол. Соответсвенно, обязанности фронтов это от верстки до этого АПИ, обязанности бакендов от этого АПИ до стораджа. АПИ — общий.
Ради чего ты занялся такой вот непрыкрытой подтасовкой?
AN>Один язык и на фронте и на бэке — удобно, но на прорыв не тянет.
В том то и дело, что это давно прорыв. Каким будет АПИ для клиента, решает клиент. См. Backend-For-Frontend. Здесь не надо спрашивать никаких бакендов, ни ждать, пока они соизволят спуститься с гор. Можно и нужно обходиться безо всякой бюрократии, типа бесконечных митингов, соглашательств между фронтами и бакендами.
Простой принцип — кому надо, тот и делает. АПИ нужен фронтам. Вот они его и пилят. На самом деле бакенды в этом тоже учавствуют, т.к. технически это бакенд, деплоится с бакендом, билдится вместе с ним и тд. Но логически эта часть не что иное, как фронтенд — часть обязанностей с фронта искусственно перетащили на бакенд.
Особенность фронтенда — он меняется дико и часто. Иногда требования меняются буквально на ходу. Все процессы, которые построены на согласованиях, спецификация и прочей бюрократии, не успевают.
Скажем, добавить ровно один индикатор в виде красной точки который означает "свежие новости" означает изменение АПИ.
С т.з. UI изменений почти нет, одна красная точка. Тестируется очень просто — в одном браузере публикуешь новость, в другом браузере видишь точку.
Как правило, бизнес измеряет сложность решений в пикселах. Мало пикселов — ждём изменения уже завтра. Проблема в том, что по твоему подходу надо начать писать спецификации, проводить митинги, согласования и прочие вещи.
Теперь можно иначе — добавляешь роут, пишешь непровальную реализацию, тесты, подсвечиваешь эти три пикселя и делаешь демо.Потом эту фичу может и уберут, мало ли, часто так и бывает. Собирать консилиум, пилить сваггером, документировать, публиковать, апрувать — эдак и
I>>Ты уходишь в сторону — вот представь, всё идеально, архитектура, сваггеры и тд. Осталось реализацию прикрутить.
AN>Ты написал, "АПИ не готов", а не "реализация АПИ не готова". Интерфейс и реализация интерфейса — это не одно и тоже. Я тебе именно про интерфейс и писал, т.к. в первом сообщении было именно про него написано.
Еще раз — я про РЕАЛИЗАЦИЮ, а ты мне про согласование, интерфейы согласование.
Кто будет писать код этого самого АПИ, когда бакенды заняты? Нужна РЕАЛИЗАЦИЯ
Все твои заглушки это компромиссы от плохой жизни, а не рокет саенс.
Здравствуйте, TimurSPB, Вы писали:
TSP>Nodejs это неплохо для сервисов которые имеют простую логику, учитывая масштабируемость для бедных из коробки. Например, порывшись на помойке(NPM), можно быстро соорудить бота для телеграмм в режиме "вопрос-ответ". Если бота настигнет успех, то можно будет горизонтально масштабироваться тупым наращиванием инстансов. Быстрота, красота, перспективы..
Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.
Здравствуйте, Ikemefula, Вы писали:
TSP>>Nodejs это неплохо для сервисов которые имеют простую логику, учитывая масштабируемость для бедных из коробки. Например, порывшись на помойке(NPM), можно быстро соорудить бота для телеграмм в режиме "вопрос-ответ". Если бота настигнет успех, то можно будет горизонтально масштабироваться тупым наращиванием инстансов. Быстрота, красота, перспективы..
I>Time to market. Собтсвенно дальше ты рассказываешь истории в лучшем случае пятилетней давности.
Сейчас пишется огромное количество простых сервисов. Не монументальные памятники инженерной мысли, на века, как в нулевых, а обычные инструменты для бизнеса.
Рабочая сила имеет заоблачные цены, а наклепать сервис, проверить, годится или нет, стоит ли инвестировать, вот эти вещи всегда делаются быстро и задешево.
Здравствуйте, Ikemefula, Вы писали:
I>Еще раз — я про РЕАЛИЗАЦИЮ, а ты мне про согласование, интерфейcы согласование. I>Кто будет писать код этого самого АПИ, когда бакенды заняты? Нужна РЕАЛИЗАЦИЯ I>Все твои заглушки это компромиссы от плохой жизни, а не рокет саенс.
Если у вас фронты пишут за бэков API потому, что бэки заняты чем-то другим, это говорит лишь о том, что у вас что-то очень неладное творится в процессах управления командами.
Здравствуйте, Klikujiskaaan, Вы писали:
I>>Еще раз — я про РЕАЛИЗАЦИЮ, а ты мне про согласование, интерфейcы согласование. I>>Кто будет писать код этого самого АПИ, когда бакенды заняты? Нужна РЕАЛИЗАЦИЯ I>>Все твои заглушки это компромиссы от плохой жизни, а не рокет саенс.
K>Если у вас фронты пишут за бэков API потому, что бэки заняты чем-то другим, это говорит лишь о том, что у вас что-то очень неладное творится в процессах управления командами.
Наоборот, это вы месяцами согласуете вещи, которые делаются от силы за неделю. Автономность разработчика увеличивается, если он может залезть в смежную область и это ускоряет деливери. До кучи, см. Backend For Frontend.
Ты вырезал серединку, а вот выделеное скромно пропустил:
