Я бы не назвал жизнь Пушкина победой в частности на личном уровне. Многие обычные люди доживали свой век гораздо более комфортно и счастливо. И там победы не было даже в контексте этой статьи. У Эйнштейна всё сложилось удачнее, лично для него. Зато самых близких людей он сделал несчастными. Плюс к этому, некоторые могли бы испытывать моральные страдания, будь они хотя бы косвенной причиной такого большого количества достаточно страшных смертей.
побеждает не тот, у кого на момент смерти больше денег в кошельке, а тот, кто пришел к осмысленной идее о том, как должна выглядеть хорошо сбалансированная жизнь
А потом он с этим знанием и уверенностью, что победил, умирает. Так же как и тот у кого больше денег и также как тот, который вообще всю жизнь забивал на работу и деньги. Сомнительная победа в общем-то. А может и не было никакого соревнования в котором можно было победить.
Ну собственно я и сам сказал, что мои представления о full-stack далеки от идеальных. Просто надеялся в комментариях выяснить, почему же фреймворки на разных языках не позволяют добиться той же производительности. Derby меня конечно заинтересовал и как-нибудь о нем я почитаю, однако пока на практике его применить негде как раз из-за необходимости в node.js, поэтому познание будет скорее теоретическое.
Я пытаюсь представить, какой код пересекается на клиенте и сервере, и на ум приходит только валидация передаваемых данных. На клиенте при этом вся интерактивщина и визуальные эффекты, на сервере сохранения данных в БД и извлечение оттуда. Но ведь во многих фреймворках по идее можно писать валидацию только на серверном языке, а на клиенте она будет сгенерирована автоматически. И при таком раскладе я не вижу преимущества в одном языке на обеих сторонах.
Есть правда ещё вариант, когда происходит вызов удаленных процедур (RPC), но мне это всегда казалось сомнительной практикой. Хотя опять же в некоторых фреймворках для этих целей происходит трансляция с серверного языка в клиентский. Но здесь node выигрывает, т.к. ничего транслировать не нужно.
А для чего ещё может потребоваться один язык на обеих сторонах?
Но разве они не через api взаимодействуют? И разве есть какая-то разница, на чем это api написано? Я вот сейчас интересуюсь этим, т.к. не до конца представляю архитектуру full-stack и почему (благодяря каким особенностям реализации) это дает выигрышь по трудозатратам.
Обсуждать языки думаю смысла нет, т.к. есть объективные показатели, по которым хорошо реализованная статическая типизация превосходит динамическую.
Я вот не очень знаком с преимуществами node перед другими языками в данной архитектуре. Не могли бы вы вкратце пояснить, почему всё тоже с серверной стороны нельзя сделать на той же скале? Я только один пример оптимизации видел, когда шаблонизатор на клиенте и сервере — одна и та же js-библиотека, но не вижу пока серьезных причин, почему нельзя сделать так, чтобы на клиенте и на сервере за работу шаблонизатора отвечали библиотеки на разных языках.
А на счет javascript, не понимаю, как можно всерьез его сравнивать опять же со скалой по качеству кода, когда статических проверок этого самого кода меньше чем в php, который, как известно, не является эталоном для подражания и ни одна компания в здравом уме не сменит java/scala на php.
Если учесть, что твиттеру не впервой менять архитектуру, и то, что подобную архитектуру гораздо легче поддерживать, почему при всем при этом им не стоит тоже перейти на node/derby?
И да, позволю себе не согласиться с Дугласом Крокфордом.
Принципиально новым является тот факт, что он об этом сообщил. Т.к. до него никто в открытую не мог об этом говорить из-за закона о патриотизме. А если о чем-то никто не может говорить, то с этим никто не может бороться. Теперь же какие-то суды начались, компании смогли рассказать об этом, т.е. какая-то борьба пошла на официальном и законном уровне.
У нас несколько танкеров с нефтью в плен брали тоже не на суше. И это какие-то африканские нищеброды с лодками и автоматами 80-х годов. А тут проект международной значимости такой протяженностью, что любой желающий сможет подплыть к нему и пилить нажевкой на металлолом пока не устанет и никто его не успеет обнаружить.
Если делать это всё вручную, то звучит достаточно долго, хотя на практике занимает не больше минуты. Но это всё можно автоматизировать, чтобы надо было только скрипт запустить. Просто как я понял, в вашем варианте нет версионности базы и если нужно откатиться на предыдущую версию или на соседнюю ветку, то можно папасть в неработоспособную среду.
Кстати для версионирования базы есть отдельные, более автоматизированные, решения. Тут даже на хабре пару раз писали. Мне просто не очень часто приходится базу синхронизировать, поэтому автоматизацией этого процесса особо не занимался.
А потом он с этим знанием и уверенностью, что победил, умирает. Так же как и тот у кого больше денег и также как тот, который вообще всю жизнь забивал на работу и деньги. Сомнительная победа в общем-то. А может и не было никакого соревнования в котором можно было победить.
Есть правда ещё вариант, когда происходит вызов удаленных процедур (RPC), но мне это всегда казалось сомнительной практикой. Хотя опять же в некоторых фреймворках для этих целей происходит трансляция с серверного языка в клиентский. Но здесь node выигрывает, т.к. ничего транслировать не нужно.
А для чего ещё может потребоваться один язык на обеих сторонах?
Обсуждать языки думаю смысла нет, т.к. есть объективные показатели, по которым хорошо реализованная статическая типизация превосходит динамическую.
А на счет javascript, не понимаю, как можно всерьез его сравнивать опять же со скалой по качеству кода, когда статических проверок этого самого кода меньше чем в php, который, как известно, не является эталоном для подражания и ни одна компания в здравом уме не сменит java/scala на php.
И да, позволю себе не согласиться с Дугласом Крокфордом.
Кстати для версионирования базы есть отдельные, более автоматизированные, решения. Тут даже на хабре пару раз писали. Мне просто не очень часто приходится базу синхронизировать, поэтому автоматизацией этого процесса особо не занимался.