Comments 15
Ау, люди, кто-нибудь может объяснить как обрывающийся на полуслове текст смог получить, на момент написания сего, оценку +2?
Правильно ли я понимаю, что этот подход - обрезанные псевдоядро и стандартная библиотека, транслирующие код в JS - приводит к тому, что писать приходится в синтаксисе Python, а мыслить в парадигме JS?
А потом удивляемся производительности нынешнего веба...
А php в браузер уже попробовали запихнуть?
Если мне надо порезать хлеб я использую нож, а если съесть тарелку супа то ложку. Похожим образом, если мне надо писать фронтэнд я использую JS, если мне надо написать бэкэнд я использую Python. Зачем мне выдумывать велосипед, если конечно не брать в расчет столь весомое преимущество, как "Сохраняйте ощущение радости от программирования на Python"?)))
А если в некой пралельной вселенной для разрезания хлеба нож не используют, и все режут хлеб только топором. Остальные продукты (колбасу, сыр, масло) все давно уже режут в основном ножами, но для хлеба есть только лишь один топор и больше ничего.
И кто-то внезапно предлагает начать хлеб резать ножом (потому что, внезапно, ножом резать удобней чем топором его рубить). Может стоит попробовать? Да не ну нафиг в каждом доме уже есть топор для хлеба, какой ещё нож - дичь какую-то предлагают. Да и производительность у ножа хуже - топором х**к и отрубил буханку, а ножом надо туда-сюда.
Ваша аналогия подобна котёнку с дверцей. Единственная объективная причина почему фронт пишут на js - да потому что в браузере больше нет нихрена!
Ну не все знают JS. Точнее сказать не все знают JS на профессиональном уровне А есть такое золотое правило - если хочешь реализовать проект, пиши его на том языке, которым лучше всего владеешь. Ну а то, что итоговый код получится не так хорош, как если бы он писался на ванильном JS, то это вопрос к качеству транспиплятора. Понятно, что Brython это пока ещё очень сырое поделие и он не может транспилировать качественно, безглючно и хорошо оптимизированно. Но это дело времени и этапов развития проекта. В теории нет никаких препятствий к тому, чтобы делать транспиляцию по настоящему эффективной.
Как в случае с компиляторами Си сначала они сильно проигрывали нативному коду написанному на Asm, но сейчас сишные компиляторы настолько хороши, что очень мало кому удаётся написать на ассемблере такой же эффективный код, как тот код, который генерирует gcc из сишного файла.
Это не перевод статьи, а выборочная нарезка, с потерей массы полезной информации.
Для интересующихся есть смысл прочитать полный текст статьи.
https://realpython.com/brython-python-in-browser/
Кстати, по поводу более шустрого выполнения Python Scripts в веб-браузере, есть еще WebAssembly Pyodide (Pyodide.org).
Ага, автор всё исправил и мой первый комментарий, который почему-то перекочевал из первой, плохой, версии именно в эту часть, потерял актуальность ибо стало хорошо.
Поэтому прикопаюсь иначе, причём к комментаторам в большей степени - разговор про Python в браузере не хорош без упоминания anvil.works. Что меня там радует, так это логическая завершённость - сервер, браузер и локальная машина гармонично работают вместе, причём строго на Питоне.
Меня смущает постоянное «вот-вот, ещё чуть-чуть подождите, и...» применительно к Brython. Я слежу за этим проектом уже лет 10, и про него до сих пор пишут, что да, проект пока сырой, но дайте срок, и... И такое ощущение, что ещё 10 лет так и будут писать.
Это далеко не первый проект, реализующий не-js синтаксис в браузере, и у всех у них одна и та же судьба: они никогда не станут серьёзным инструментом в отрасли, пока не будет нативной поддержки в браузерах. Как было с VBScript, если кто-то помнит. На текущем этапе развития его эпоха кажется недолгой, но кто застал, те ощущают разницу между тем, как применялся он, и тем, как существуют все альтернативные проекты сегодня.
В целом, их наличие, конечно, говорит о том, что интерес к альтернативам JS огромен, и многие бы ими пользовались, обладай они нативной поддержкой и отраслевым стандартом для браузерной реализации.
Brython: Python в вашем браузере (ч.4)