Кстати да, я когда-то давно даже всерьез думал о перекате на руби. А что сейчас с ним?

https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

ой :)

а, уже накидали

но можно же без js рендерить

Кстати да, я когда-то давно даже всерьез думал о перекате на руби. А что сейчас с ним?

развивается, хоть и медленно

но можно же без js рендерить

при помощи?..

но можно же без js рендерить

тогда придется рендерить два раза

Кстати да, я когда-то давно даже всерьез думал о перекате на руби. А что сейчас с ним?

сейчас он умирает потихоньку

один раз без js, один раз в браузере

остались из серьезных проектов только рельсы, chef/puppet, homebrew и metasploit

хероку..

со всем набором сопутствущих чудесных багов

причем вторые уже начинают просасывать salt/ansible, а последний переписывают на питоне активно

развивается, хоть и медленно

И я остался кстати на питоне, потому что мне на тот момент показалось, что руби тащит только из-за рельсов. То есть сфера у него - сугубо веб, хотя знаю, что есть много утилиток, написанных на руби.

тогда придется рендерить два раза

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

И я остался кстати на питоне, потому что мне на тот момент показалось, что руби тащит только из-за рельсов. То есть сфера у него - сугубо веб, хотя знаю, что есть много утилиток, написанных на руби.

у него сфера уже больше управление конфигурацией и DSL

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

это если у тебя поток данных с сервера не изменяет DOM

единственное, что интересного происходит в мире руби - это они обещали в 3.0 выпилить GIL

Все равно, питон гораздо более widely used

но и в питоне к тому времени его тоже выпилят

например, динамическая подгрузка комментариев

это если у тебя поток данных с сервера не изменяет DOM

так пусть изменяет на здоровье, я же так или иначе буду js все равно на клиенте выполнять и вьюхи перерисовывать

так пусть изменяет на здоровье, я же так или иначе буду js все равно на клиенте выполнять и вьюхи перерисовывать

и получаешь два рендеринга - один на серверном языке, один на js

а можно иметь один, на js и там и там

и получаешь два рендеринга - один на серверном языке, один на js

разумеется, потому что js - фронтендный язык, а питон/го/джава - бэкендный

а иметь кучу говна и там и там не надо

Я если честно сомневаюсь, что на серверном рендеринге можно делать современные интерфейсы

ну вот в статье они приводят сайт волмарта, мол, там он используется

Поэтому мне весь этот подход spa и роутинга на клиенте - очень-очень нравится.

смотря что под современными интерфейсами

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

реакт уже все же, отгремел

Да, но там ты рендеришь компонент

теперь что там, вуе

вуй вроде постарше

Теперь вуе, да. Мир фронта - лютый. Там все постоянно меняется

а вообще scala.js наше все

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

а иметь кучу говна и там и там не надо

ну фактически ты сейчас делаешь выбор между использованием плохой методологии (чреватое проблемами нарушение DRY) и использованием посредственного языка в пользу плохой методологии

не то чтобы я тебя не понимаю, но это не очевидный выбор

ну фактически ты сейчас делаешь выбор между использованием плохой методологии (чреватое проблемами нарушение DRY) и использованием посредственного языка в пользу плохой методологии

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

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

+

какие там языки - по большому счету пофиг, но на фронтенде обычно js

нарушение DRY. Сначала ты рисуешь DOM питоном из данных, потом рисуешь остаток того же DOM из данных с помощью JS

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

нарушение DRY. Сначала ты рисуешь DOM питоном из данных, потом рисуешь остаток того же DOM из данных с помощью JS

я могу и вообще js не использовать, это фронтендопроблемы, чего они там хотят

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

мы говорим сейчас конкретно про серверсайд рендеринг

нет нарушения DRY, есть четкое разделение на кнопочки в браузере и серьезную бизнес-логику

мы говорим сейчас конкретно про серверсайд рендеринг

А, ну он то не нужен же

я могу и вообще js не использовать, это фронтендопроблемы, чего они там хотят

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

если ты DOM питоном не рисуешь, то DRY соблюдается, а остальное фронтендопроблемы, действительно

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

да, можно, а можно и сделать набор хэндлеров, которые отдают вьюхи, и подгружать страницу асинхронно по блокам

но, по сути, это будет та же херня

тогда у тебя будет нарушение DRY, когда в страницу свежие данные полетят рендериться

у меня не будет нарушения DRY в принципе, потому что есть четкое разделение между двумя слоями

потому что изначальные ты рендеришь питоном, а новые жаваскриптом

это зависит от подхода, который принят на фронтенде

если им нужна скорость - будут грузить DOM с сервера и не возбухать

если хотят гибко настраивать все - пусть грузят json и рисуют сами

надо из задачи исходить

ну вот серверсайд js позволяет и рыбку съесть, и так далее

серверсайд js не нужен просто

серверсайд js не нужен просто

если отойти от этой простой максимы, внезапно оказывается, что можно и скорость и гибко настраивать

И под поисковики оптимизироваться и не потерять преимущества рисования в браузере через json

И не дублировать рисовалку на js и не на js

А просто сделать рисовалку на js, ту самую, которая перерисовывается через json, и отдавать первый уже отрисованный вариант с сервера

ERROR: S client not available

Не передавая при этом бизнес-логику из нормальных языков в js

руби умерло, пхп умерло, один питон жив!

js тоже умирает!

И под поисковики оптимизироваться и не потерять преимущества рисования в браузере через json

поисковики давно умеют в js, либо умеют нужные вьюхи сами дергать

а что где рендерить - это вопрос к постановке задачи, а не “надо делать так"

Парни, как спарсить всех участников чата в телеграме?

я не вижу никаких преимуществ у js на сервере, хоть убейте, но допускаю, что кому-то это может быть удобно

Парни, как спарсить всех участников чата в телеграме?

В апи разве нет метода получит всех юзеров чата?

https://core.telegram.org/method/messages.getFullChat

Оно?

Если вернуться к питону, есть ли какая-то возможность, чтобы setup.py develop - зеркалил в package_dir? Потому что сама либа, для которой разрабатывается модуль смотрит на package_dir и ждет конфигурационный файл у себя 'внутри'.

Если вернуться к питону, есть ли какая-то возможность, чтобы setup.py develop - зеркалил в package_dir? Потому что сама либа, для которой разрабатывается модуль смотрит на package_dir и ждет конфигурационный файл у себя 'внутри'.

а зачем зеркалить-то? у тебя develop засовывает пакет в глобальную область видимости, как оно и будет в продакшене

я не вижу никаких преимуществ у js на сервере, хоть убейте, но допускаю, что кому-то это может быть удобно

преимущество - если уже знаешь js не надо учить другой язык

преимущество - если уже знаешь js не надо учить другой язык

если знаешь js - надо срочно учить другой нормальный язык

если знаешь js - надо срочно учить другой нормальный язык

то есть js не нормальный язык, а питон нормальный?

то есть js не нормальный язык, а питон нормальный?

именно

именно

определение нормального языка

во всяком случае, куда более нормальный по ряду параметров

а зачем зеркалить-то? у тебя develop засовывает пакет в глобальную область видимости, как оно и будет в продакшене

Да, но сама либа ищет конфиг файл у себя в директории modules. При это тупо os.path.join

Да, но сама либа ищет конфиг файл у себя в директории modules. При это тупо os.path.join

надо конфиг-файл грамотно паковать вместе с пакетом питоновым

определение нормального языка

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

можно долго перечислять

и далеко не все из этого есть у джаваскрипта, а у питона есть

надо конфиг-файл грамотно паковать вместе с пакетом питоновым

Он указан в package_data

Он указан в package_data

а в MANIFEST.in?

а в MANIFEST.in?

а там нет) Вообще нет манифеста

ну вот а зря, сделай

а то конфиг в пакет не попадет в итоге

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

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

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

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

вот и серверсайд на js будут писать только неучи, которые кроме него не умеют в нормальные языки

вот и серверсайд на js будут писать только неучи, которые кроме него не умеют в нормальные языки

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