Насколько важно использовать один и тот же язык для клиента и сервера?

Я оценивал архитектурные решения для мобильного проекта, который будет иметь веб-сервис / приложение в дополнение к нативным приложениям и рассматривал различные библиотеки, фреймворки и стеки, такие как Meteor , что является своего рода «структурой пакетов с открытым стеком». , тесно связан с Node.js .

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

Я пытаюсь понять, почему паритет языка клиент / сервер считается священным Граалем. Почему клиент-серверный язык имеет значение при разработке программного обеспечения?

web-applications server-side client-side

— Makita
источник

Я бы сказал, что это не обязательно хорошая вещь, особенно когда речь идет о JavaScript.

— Latty

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

— Makita

Спасибо за ваше первое сообщение о программистах Stack Exchange. Для получения дополнительной информации о максимизации количества голосов "за" и о том, как уменьшить число голосов "за", прочитайте FAQ. Возможно, за вас проголосовали, потому что ваш вопрос больше относится к теме чата, чем к конкретному ответу. Это может занять некоторое время, чтобы привыкнуть к формату здесь. Короткие ответы, лишенные подробностей, не принимаются. Так же как и ответы, которые обсуждают тему. Существует некоторая середина, где вопрос или ответ является конкретным, но достаточно универсальным и затрагивает тему с достаточным количеством деталей.

— DeveloperDon

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

— Питер Б

@ Макита Я думаю, что это правильный вопрос, но люди склонны довольствоваться отрицательными голосами, когда спрашивают примеры. Я удалил некоторые части исходного вопроса и сосредоточил ваш вопрос на том, почему имеет значение паритет клиент / сервер.

— maple_shaft

Ответы:

На стороне PRO:

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

На стороне CON:

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

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

Кажется, что новые фреймворки Javascript приходят к нам очень быстро, и проделана определенная работа по объединению API-интерфейсов для внутреннего интерфейса и инструментов для внешнего интерфейса. Возможно, было бы разумно сохранять гибкость и разделять проблемы между клиентским и серверным кодом, чтобы вы могли свободно перемещаться между ними, не слишком надолго застревая с определенным инструментом.

— DeveloperDon
источник

Предположительно, предполагаемые выгоды:

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

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

— JK.
источник

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

— K ..

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

— Майкл Боргвардт

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

— JK.

Замечание о том, что это плохая идея, неоправданно. Существует множество языков, которые можно скомпилировать для JavaScript, и язык на стороне сервера, в том числе Lisp , который фактически является языком, используемым в курсе SICP, отмеченном в блоге Джоэла.

— back2dos

@ back2dos надеюсь, что это проясняет

— JK.

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

люди

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

Код

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

... конечно есть и минусы, но это для другого поста;)

— dagnelies
источник