Комментарии 71
Не, js я тоже люблю, прям очень, так что пока наверное попридержу коней с этим бритоном. Штука на любителя, но фаново, спору нет, да )
P.S. правда, уже давно: первым таким языком стал JS
А как же Java? GWT вполне нишу занимал.
Ещё Kotlin со своим Kotlin/JS
Вомзожно я как-то не так понял ответ, но не совсем ясно что такое JWt, который требует наличия чего-то кроме браузера с поддержкой JS на клиентской стороне
и как он связан с Google?
Если речь про JWT
в смысле JSON Web Tokens, то это вроде как открытый стандарт формата представления некоторой структуры данных.
Если речь про GWT, то он не требует на клиентской стороне ничего кроме браузера с поддержкой JS.
Даёшь нормальный питончк на WebasmИспользую в проектах Pyodide.
… Ооо!
Вот походу про это надо было статью писать )
Спасибо, это уже куда интересней )
Расскажете как-нибудь? Хотя бы даже в комментарии, интересен опыт!
Язык правил: Питон.
Тестировать правила решили на клиентской стороне через Python WebAssembly на базе FireFox инициативы Pyodide.
Т.е. Питон интрерпретатор загружается в клиентский браузер как WebAssembly, компилится под платформу браузера и работает достаточно шустро на ресурсах клиента из браузера.
Причины:
— скорость тестов (обработка кода на машине клиента),
— простота эксплуатации (не требуется доп. действий или установок)
— безопасность (пользователь может навредить только сам себе),
— перенос нагрузки на клиента (неудачный код не перегрузит сервер)
Из недостатков:
1. ограниченный набор пакетов (нам для правил достаточно)
2. большой wasm файл для начальный загрузки: 12MBytes (в дальнейшем кешируется)
Картинки:
1. Процесс подгрузки wasm
2. Скорость работы интерпретатора в браузере
Не хотите ли написать статью? Думаю, всем будет интересно почитать подробнее, как с этим работать, какие ограничения.
Сравнение скорости с Cpython упомянули, а сравнение скорости с нативным js? Есть ли какие-нибудь бенчмарки для скриптов в браузере независимо от языка?
Ага, прежде чем будет выполняться наш скрипт, нужно сначала скачать целиком рантайм питона вместе с парсером, виртуальной машиной и стандартной библиотекой на общую сумму более мегабайта.
Зато разработчик сидит у моря и попивает свой смузи.
Куда катится мир?
Ну так вроде у питона целый букет: PyPy.js, Transcript, Skulpt ну и уже помянутые Brython и Pyodide. А да еще Batavia.
для этого же появился Node.js — чтобы яваскриптовики зашли в бекенд
Ничего подобного: «Dahl criticized the limited possibilities of the most popular web server in 2009, Apache HTTP Server, to handle a lot of concurrent connections (up to 10,000 and more) and the most common way of creating code (sequential programming), when code either blocked the entire process or implied multiple execution stacks in the case of simultaneous connections.»
Т.е. изначально цель была писать для бэкенда асинхронный код; и уже исходя из этой цели был выбран (самый популярный на тот момент) язык, который такое поддерживал.
Всегда язык выбирается в соответствии с задачей; а вы постулируете противоположное — «когда в руках молоток, всё вокруг кажется гвоздями». За этот контрпродуктивный подход и минусуем.
Сначала чисто браузерный JS полез в бакэнд
Теперь «Бакэндовский» питон полез во фронтJava первая полезла во фронт
Как, по вашему, связаны Java и JS? Вы такую ересь несете, что неприятно аж.
Первоначально язык назывался Mocha[20][21][22], затем он был переименован в LiveScript[22][23] и предназначался как для программирования на стороне клиента, так и для программирования на стороне сервера (там он должен был называться LiveWire)[19]. На синтаксис оказали влияние языки Си и Java, и, поскольку Java в то время было модным словом[16][19], 4 декабря 1995 года LiveScript переименовали в JavaScript[24], получив соответствующую лицензию у Sun.
Не, сначала произошло разделение на бек и фронт, потом в разных ответвлениях набрали популярность разные языки, а затем закрепилось, как будто так и надо, чтобы разные части писались на разных языках. Но так как язык — это средство объяснения идей программиста машине, то нет объективных причин, почему какой-то язык должен быть только "фронт", а какой-то — "бек". Это скорее один из этапов эволюции — причем не столько языка, сколько сопутствующей инфраструктуры (библиотек, интерпретаторов, компиляторов...)
Столько негодования в комментариях…
Да, понимаю, достойны гореть в аду те, кто тратит батареи юзерских телефонов, их трафик и время на запуски виртуальных машин внутри виртуальных машин.
Но, ведь много есть других применений. Отладочные тулы напилить, админку сделать, свой мониторинг, где не хватает возможностей мейнстримных тулов. И хорошо, что есть возможность покрыть эти задачи, не изучая js и не нанимая фронтендера
Важный момент — для работы с Brython необходим опыт работы с JavaScript, хотя бы базовый уровень. Без этого разобраться будет довольно сложно.
Это нужно изучить фреймворк в 2х направлениях в Bpython и в JS
С приходом ES7 и далее не вижу смысла даже делать прототипы на питоне или на чем-то еще.
Намного забавнее пробовать добавлять Python сразу в броузер.
*разные версии IE, в сумме покрывающие >90% пользователей
броузер— режет глаза.
Один динамический язык поверх другого динамического языка… А можно не надо?
У меня нет проблем с динамическими языками. Я на них не пишу.
Вообще был забавный случай, когда знание специфики обоих языков дало возможность хакнуть игру.
Суть в том, что один сайт, обучающий азам программирования, предлагал научить питону прямо в браузере, через игру на HTML5. В духе "заставьте перса пройти направо", потом "добавьте циклов" и т.д.
С моей искушенной точки зрения было очевидно, что это всего-лишь пародия на Python, и трансляция в JavaScript. Более того, запросов на сервер по каждому нажатию кнопки "запуск" не было, значит парсится и обрабатывается локально.
В общем, я дошел до момента, где я смог написать вдвое меньше кода, чем от меня хотело задание и проверялка. При этом, мой код выдавал верный результат, но эксплуаировал примитивность транслятора:
в JavaScript функция может принимать произвольное число аргументов, и вызывать её можно с любым другим числом аргументов, а все незаполненные будут просто undefined. Python таким не страдает, пока ему явно не скажешь *args
, но Python поверх JavaScript о таком не знал… В итоге получилось без ошибок подсунуть якобы-Python функцию от одного аргумента в место, где она вызывалась игрой с двумя аргументами.
Как прикажете дебажить такие ляпы, если их даже рантайм перестает замечать?
Справедливости ради, в Brython это учли. Видимо, ценой плюс одного слоя проверок при вызове функции.
>>> def f(a):
... print("hi, %s" % a)
...
>>> f(42)
hi, 42
>>> f(42, 37)
Traceback (most recent call last):
File <string>, line 1, in <module>
TypeError: f() takes 1 positional argument but more were given
Знаете, у слова "хакер" изначально не было значения "security breaker". То, чем я занимался с транслятором той игрушки, очень точно описывается понятием "hacking".
Печально, что вы не в состоянии обобщить один пример с игрой на концепцию (не всегда удачной) трансляции одних языков(правил) в другие.
Да, проблемы, потому что это оксюморон.
Вышел новый релиз «Python для браузеров», встречаем Brython 3.9