Наскільки важливим є використання однієї мови для клієнта та сервера?

Я оцінював архітектурні рішення для мобільного проекту, який матиме веб-сервіс / додаток на додаток до рідних додатків і розглядав різні бібліотеки, рамки та стеки, як Meteor , це свого роду "рамка пакетів відкритого стека" , тісно пов'язаний з Node.js .

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

Я намагаюся зрозуміти, чому паритет мови клієнт / сервер вважається святим граалом. Чому паритет мови клієнта / сервера має значення в розробці програмного забезпечення?

web-applications server-side client-side

— Макіта
джерело

Я зауважу, що це не обов'язково чудова річ, особливо коли мова йде про мову.

— Латті

Я мушу визнати, що я ще не досягнув епіфанічного моменту з JS, і тому не зрозумів, чому ви хочете написати серверний код з ним, але це інша тема ..

— Makita

Дякуємо, що ви написали своє перше повідомлення в програмі Stack Exchange. Для отримання додаткової інформації про збільшення кількості голосів та мінімізацію голосів вниз прочитайте FAQ. Можливо, ви проголосували, оскільки ваше запитання більше стосується теми чату, а не конкретної відповіді. Тут може пройти певний час, щоб звикнути до формату. Короткі відповіді, позбавлені деталей, проголосуються. Так само є відповіді, які обговорюють тему. Є деяка середина, де питання або відповідь є конкретним, але досить універсальним і вражає тему з потрібною деталізацією.

— DeveloperDon

Я б навіть заперечував проти цього. Використовуючи однакову мову як для сервера, так і для клієнта, ви ризикуєте заплутатися та особливості мови в спілкуванні.

— Пітер Б

@Makita Я думаю, що це питання справедливе, але люди, як правило, тішаться низовинами, коли просять приклади. Я видалив певні частини оригінального запитання і зосередив ваше питання на тому, чому питання парності мови клієнта / сервера має значення.

— maple_shaft

Відповіді:

З боку PRO:

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

З боку CON:

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

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

Нові рамки Javascript, здається, приходять до нас дуже швидко, і деяка робота проводиться над комплектуванням API для заднього кінця та інструментами для переднього. Можливо, було б розумно зберігати гнучкість та розділяти проблеми між клієнтом та кодом на стороні сервера, щоб ви могли вільно плавати між ними, не затримуючись занадто довго за допомогою певного інструменту.

— DeveloperDon
джерело

Імовірно, сприйнята пільга:

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

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

— jk.
джерело

Це користь, якщо ви розробляєтесь самостійно, оскільки немає «розумового» перемикання між сервером і клієнтом. Якщо ви хочете щось зробити і маєте величезний досвід роботи в JavaScript, ви, мабуть, отримуєте кращі та швидші результати таким чином, але це, мабуть, все ...

— K ..

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

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

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

— jk.

Зауваження про те, що це погана ідея, є невиправданим. Існує безліч мов, які можуть компілювати JavaScript та серверну мову, включаючи Lisp , що насправді є мовою, що використовується в курсі SICP, похвалений у публікації щоденника Джоеля.

— back2dos

@ back2dos сподіваємось, що це уточнює

— jk.

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

Люди

Розробникам потрібно оволодіти єдиною мовою та сформувати єдиний пул. Замість двох пулів експертизи. Це полегшує передачу знань серед них, а також дозволяє їм легше перемикати свою роботу між клієнтською та серверною сторонами. Нарешті, це полегшує спілкування з членами команди "іншої сторони" при обговоренні технічних питань, оскільки вони мають однаковий технічний досвід.

Код

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

... звичайно, є і мінуси, але це вже для іншої посади;)

— дагнелі
джерело