Итан Смит (Ethan Smith), один из основных разработчиков MyPyC, компилятора модулей Python в код на языке Си, сообщил о добавлении в кодовую базу CPython (базовая реализация Python) изменений, позволяющих собрать основную ветку CPython для работы внутри браузера, не прибегая к дополнительным патчам. Сборка осуществляется в универсальный низкоуровневый промежуточный код WebAssembly при помощи компилятора Emscripten...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56246
какой ужос!
Интересно, а они VBScript уже выпилили везде или нет?
> ... без привязки в web-браузеру. Отмечается, что для реализации подобной возможности потребует проделать большую работу ...Могло быть лучше.
Это хорошо, когда придумывают прослойки для прослоек для работы на прослойках. Программисты без работы не останутся.
Но плохо, когда перкрывают пути для работы без прослойки.
Итогом будет google translate с языками программирования.
Вообще-то уже есть.
Приехали....
Урааааа! Наконец-то можно хлебать смузи хлебая смузи!Из браузера вообще не надо выходить!
Позравляем с успешной разморозкой!
У нас тут хромоось рулит и побеждает.
Вам понравится!
Ну жс хотя бы быстрый, но эти смузихлёбы же угробят браузер!
Жс не быстрый, быстрый v8. И v8 не жс. Если питон ускорят в 100 раз, как планируют, то вполне реальная замена. Либо пока что можно не писать такой дрянной код с тысячами абстракций и будет вполне сносно и так.
Python / PHP / Bash / BrainFuck не медленный...это просто СPython / ... в 10 раз медленнее JavaScript...ой, простите, V8.Ну и что, что 90% браузеров в мире (Chrome и MS Edge) имеют именно V8...
Или движок Firefox или Safari медленнее? Так же в десятки раз быстрее Python.
Opennet-экперт...как обычно. Это уже бренд.
С ducktape сравнивай. А с каких пор конкуренты в8 ускорились, они с в8 содрали пример? В8 адово жручий, такой питон никому будет не нужен.
Браузерные движки все очень быстрые, все JIT компилируемые. И уже давно. Они могут где-то отставать от V8, но это проценты, ну 30% максимум. Если учесть что V8 медленее чистого С в 2-5 раз обычно, а Python в 30-100 раз.А зачем мне сравнивать с DuckTape, если это движок для embedded? JavaScript это Web в основном, Electron, Node.js. и там везде V8.
И потому что "адово жручий" (видимо by design) Facebook написал движок Hermes, который JavaScript компилирует в бинарный формат, как Java или C#.
А дальше исполняет его, но без JIT. Получается очень быстро (нет стадии парсинга тонны JavaScript в runtime). Память отдает по-максимуму обратно в систему. Очень эффективный. Ничем не отличается от обычного нативного Android приложения. Я думаю даже получше и побыстрее будет.
Его можно и в embedded прикрутить. DuckTape это прям для совсем embedded / iot на батарейках. Видимо самая простая интерпретация кода самая энергоэффективная. Хотя мне непонятно почему так.
> Если питон ускорят в 100 разЕсли.
Даёшь Нью-Васюки!!!Python будет ускорен в 1000 раз! Весь JavaScript будет переписан на Python!!! Браузеры начнут поддерживать Python как второй язык!!!
Python окончательно вытесняет JavaScript!!! Всеобщая и вселенская победа!!!
Товарищи, скидываемся по рублю на это благое дело!!!
Если браузерный код начнут писать на питоне, то лучше я воздержуть от использования таких сайтов.... Обычно квалификация бакендеров выше, чем у фронтендеров в части программирования. Питон и сам по себе не для программирования чего-то ответственного. Но когда его дают совершенно безответственным - это просто страшно.....
> Питон и сам по себе не для программирования чего-то ответственногодооооо, сразу видно - иксперт
Без жс на этот раз? Ну а что, почему нет. Писать на питоне всяко приятней, чем на жс.
ЖС хоть компрессить можно, уже вижу эти петабайты пробелов в эфире без гзипа. )
Сделают промежуточный слой в виде компрессии и делов-то.
Так питонокод же в WASM компилять предполагается.
нет
И смысл? Полный интертрепатор без JIT, велкам ту зе словнесс хелл.
Гвидо вон предложил использовать для разработки в браузере. Школьнико-студентов каких-нибудь можно обучать, не устанавливая ничего.
А вообще, конечно, всё это практической ценности имеет мало и смысл тут в том, что у кого-то было время сделать это и он получил от этого удовольствие и строку в резюме.
> Писать на питоне всяко приятней, чем на жсРешил тут изучить пихтончик и обнаружил, что его встроенная система аннотаций типов не позволяет нормально ссылаться из методов класса на тип самого класса. Только через строки, лол. Типа -> 'TreeNode', а не -> TreeNode. Ну и при этом нужно постоянно держать в голове, какой модуль в каком порядке грузится, в то время, как в TypeScript есть import type, который из результирующей сборки вырезается и не ведет к циклическим зависимостям. Да и вообще можно ссылаться на типы, объявленные много позже снизу. Без строк мля. Просто ссылаешься и все.
Далее, пихонщикам, как чисто бэковским бейсикописателям (разрабами их язык не повернется назвать), еще только предстоит освоить tree shaking, у них там из-за одной библиотечной функции небось придется всю библиотеку в рантайм тащить, а не только ровно эту одну функцию. В общем добро пожаловать в 2005 год, когда из-за пары jquery-функций в рантайм тащили весь jquery. Как говорил бен Ладен, "это вы нас считаете пожирателями оперативы? вот придут наши дети пихтонщики, и вы нас еще добрыми словами вспоминать будете".
Далее, пока в васм не завезут нормальный интероп с жс и дом апи, ни о каком быстродействии речь идти не может. Да там банально проще на стороне жс поманипулировать домом, чем вначале подготовить данные, сериализовать в буффер, отправить буффер в васм, потом его оттуда принять, сдекодировать и применить к дому на стороне того же самого жс. Потому что васм к дому доступа не имеет, он может лишь намекнуть жсу, что "было б неплохо, если б ты это вот сюда вот засунул".
> ссылаться из методов класса на тип самого класса. Только через строки, лол. Типа -> 'TreeNode', а не -> TreeNodeЩито, Ълять?
пюхтоно-бейсикописатели не в курсе про свои же подобия "инструментов статической типизации"?
аксиома-эскобара.avi
Даёшь а-ля электрон на питоне
А было бы отличненько. Но вообще есть PyQt. Но мобилки из него вырвали
PySide? Жив ли он ещё?
PHP давай, до свидания.
А зачем Emscripten для этого? На бэке и так можно Python использовать.
PHP на стороне сервера только. А Python на стороне сервера и так есть: Zope, Django.
И никому особо не нужен
Вот и пихают во фронт
php client side?
просто оставлю это здесь
на php можно в blazor https://www.peachpie.io/2021/08/run-debug-php-browser.html который компилируется в webasm полностьюа на питоне что? запускать скомилированный интепретатор, который будет запускать искодник питон кода, который будет интерпретироватся? даше файл pyc не сохранить
> компилятора модулей Python в код на языке СиА propos. Почему питон компилируют в С, валу компилируют в С, ним компилируют в С, да практически любой язык компилируют в С.
Почему ничего не компилируют в передовой раст? 🤷🏻♂️
Наверно потому, что Rust не допускает некоторых потенциально небезопасных конструкций. А если другие языки допускают, то транслировать их код в Rust не получится.
Те, кто минусит, хотелось бы почитать ваши соображения. Если они у вас есть, конечно.
Излагать соображения - unsafe. Минусить - safe.
потому что раст течёт, если только java приделают как нибудь, у них все равно петабайты памяти
Ну действительно пару примитивных батареек подключаешь и уже какой-то дикий жор. Лучше не вспоминать, сколько времени компиляция занимает. Тем временем питон с сотней батареек не жрёт почти ничего.
> потому что раст течётА есть пруфы?
> Почему ничего не компилируют в передовой раст?А смысл?
Компиляция в Си позволяет просто поддерживать большое количество платформ. Хотя бо́льшая часть языков все же компилируются не в Си, а в байткод LLVM.
А компилировать в Rust сильно сложнее, потому что надо аккуратно генерировать код, чтобы удовлетворить borrow checker. Либо писать много unsafe, но тогда чаще всего это не лучше, чем в Си компилировать.
Обычно считается все же, что компиляторы сами должны проверять безопасность кода, который они генерируют, а не перекладывать эту задачу на кого-либо. А вот для написания кода руками дополнительные проверки во времени компиляции как раз сильно помогают :)
Кстати, насчет байткода LLVM: почему на нем не пишут программы, если крупные компиляторы (вроде Clang) генерируют его из исходного кода? :)
Кстати, а почему? Как байт-код этот выглядит то?Там говорят только совсем совсем недавно оптимизацию хвостового вызова добавили.
> практически любой язык компилируют в Снет. если кратко (и заодно грубо, как по приближению, так и вообще): макакские - да, человеческие нет.
и должно быть очень стыдно не отличать трансляцию от компиляции.
а впрочем, ну вас всех.
Лёд тронулся. В течение пары лет появятся питонячьи фреймворки, генерящие DOM с поддержкой virtual DOM. И вот тут я уже буду задавться вопросом -- фронт писать на React или на PythonКороче, развесовка по рыночку может измениться
Просто твои знания устареют и станут не нужными.
Всё новое - хорошо забытое старое. Ещё 15 лет назад пайтонскрипт и джаваскрипт конкурировали между собой за эту веб-нишу. Джваваскипт вышел победителем в этой конкуренции, потому что питон оказался слишком тормозным и жрущим память.
Глядя на вебню, жрущую гигабайты, лагающую, и вечно текущую… Ну да, ну да, победитель. На бэке то всё равно питон, как ни хотели протащить жс, ничего вменяемого не получается.
> Глядя на вебню, жрущую гигабайты, лагающую, и вечно текущую… Ну да, ну
> да, победитель. На бэке то всё равно питон, как ни хотели
> протащить жс, ничего вменяемого не получается.Ситуация немного сложнее. За тормоза могу пояснить. Причин несколько
Дело в том, что не каждый JS-ный синьор задумывается о структурах данных. 99% структур данных -- это стандартные массивы и Object. И проблема в том, что они не всегда подходят. Например, ребята просто обожают использовать массивы для проверки на включение там, где нужно использовать Set. На ровном месте сложность растёт с линейной до квадратичной. О том, что можно создать собственную структуру данных, знают лишь избранные, а ключевое слово `class`, с которого начинается создание своих структур данных, сегодня в JS подобно ругательству
JS-ник сегодня дохера функци-анальщик. Я не против ФП, но против отрыва от реальности. Дело в том, что JS -- это чисто ООП язык, хоть и с функциональными элементами. И оптимизации, гарантированные в ФП, невозможны в JS. В мире JS считается зашкваром перебирание элементов коллекции через `for ... of`. Забавно, что как только я заменил обработку больших коллекций с `forEach` на `for ... of`, приложение резко стало работать ощутимо быстрее. Я не говорю "в топку forEach/map/filter" -- я указываю на ограничения
Ещё один рак дохера функци-анальщика -- иммутабельность в каждой дырке. Иммутабельность -- это инструмент, позволяющий реализовать ссылочную прозрачность. Прекрасная штука. При этом JS-ник забывает про цену иммутабельности -- необходимость пересобирать заново структуры данных. Особенно больно на больших списках. И ладно, когда речь о redux. Плохо, когда пересборка структур данных происходит вообще в каждой дырке. Я хочу сказать, что мутабельность -- это тоже инструмент, позволяющий сильно поднять производительность. Как извлечь все выгоды мутабельности и сохранить ссылочную прозрачность -- просто обернуть мутируемую структуру данных в объект с одним ключом
Вы прослушали тираду "Дорогие коллеги! Давайте прекращать кодить и учиться программировать!"
>> Дорогие коллеги! Давайте прекращать кодить и учиться программировать!А они не поняли
Сейчас новую партию коллег с курсов выпустят
Как функци-анальщик (велик и могуч русский язык) не соглашусь.Во-первых, я перешёл с функциональной Scala и JavaScript больше ФП, чем ООП в современном виде. forEach / map / flatMap в Scala используется и в хвост и в гриву, и на производительность никто не жаловался.
Во-вторых, это заблуждение. На современных движках эти forEach / map / flatMap по производительности отстают от for of в 2 раза, грубо говоря. Это вообще ничто учитывая производительность, если не ворочать миллионами объектов.
Трансформация данных гораздо удобнее и понятнее, есть явный separation concern чем лапша в цикле.
Конечно можно и одним проходом делать с reduce и аккумулятором с ранним выходом (упс, нельзя).
И только если нужна максимальная производительность имеет смысл использовать обычные циклы.
Все доп. библиотеки обработки данных типа rambda заточены под ФП и переиспользование кода офигенно.
Также накладывает ограничения React, который во-первых пересоздаёт замыкания и отбрасывает их на каждом рендере. А во-вторых использовать его с кастомными типами практически невозможно.
И React это "чистый" ФП... функции... функции функций и т.д.
Да, я лучше список пробегу фильтруя, чем буду тр...ся с Set. По-сути нужно создавать новый Set из старого.
Можно, конечно извратиться используя useRef ссылки, но оно того в 99.99% не стоит.
Те это не моё нежелание, а невозможность / ограничение фреймворка (думаю у других не лучше).
И вообще если вы работаете с миллионными списками вы что-то делаете очень неправильно. А со списком в 100 элементов из БД...его хоть как медленно обрабатывай это миллисекунды.
Наверняка в Node.js другая ситуация, но там гораздо больше ООП, сам API этому способствует.
Сразу лайк за развёрнутый и конструктивный ответ> forEach / map / flatMap в Scala используется и в хвост и в гриву, и на
> производительность никто не жаловался.Не путайте функциональные языки с JS =) К API претензий нет, но есть разница, что под капотом. В ФП-языках оптимизация хвостовой рекурсии гарантируется, в то время как в императивных не всегда допустима
> Во-вторых, это заблуждение. На современных движках эти forEach / map / flatMap
> по производительности отстают от for of в 2 раза, грубо говоря.
> Это вообще ничто учитывая производительность, если не ворочать миллионами объектов.Когда элементов мало -- разницы действительно нет
> Трансформация данных гораздо удобнее и понятнее, есть явный separation concern чем лапша
> в цикле.Вопросов нет. Действительно, когда элементов мало, а их преобразование/обработка сложны и многоэтапны -- forEach/map/etc не просто незаменимы, они best practice
Хозяйке на заметку. Методы map/filter есть только у массивов, но отсутствуют в Set и итераторах. Это зашквар. Для сравнения, в python можно скормить map/filter любой итерируемый объект, получив на выходе генератор. В JS мы умеем только в массивы> Все доп. библиотеки обработки данных типа rambda заточены под ФП и переиспользование
> кода офигенно.Я не знаком с rambda, поэтому поверю вам на слово
> Также накладывает ограничения React, который во-первых пересоздаёт замыкания и отбрасывает
> их на каждом рендереСледовательно, чтобы не пересоздавать замыкания, коллбэки надо выносить из render()
> А во-вторых использовать его с кастомными типами практически невозможно
Не увидел ни единого препятствия. Что я только ни пихал ни в props, ни в redux state. Держи себе в голове ссылочную прозрачность -- и всё.
> И React это "чистый" ФП... функции... функции функций и т.д.
React.PureComponent? Возвращайтесь из мира розовых единорогов :)
> Да, я лучше список пробегу фильтруя, чем буду тр...ся с Set. По-сути
> нужно создавать новый Set из старого."Нас устраивало O(N^2), пока N не начал расти" (с) Хабр
Всегда держим в уме cardinality. На малых объёмах массивы могут оказаться незначительно быстрее Set. А чтобы получить линейную алгоритмическую сложность, стоит применить Set> Можно, конечно извратиться используя useRef ссылки, но оно того в 99.99% не
> стоит.Я не про рефы. Рефы вообще о другом. Кстати, особенно в случае class based компонентов рефы действительно рулят. Особенно когда мы генерим хитрую структуру из того, что накликал/навводит пользователь. Чем гнать тонну данных вверх/вниз, есть смысл на каждом уровне определить метод генерации части этой структуры. Вообще говоря, я пересказываю суть HMVC
> Те это не моё нежелание, а невозможность / ограничение фреймворка (думаю у
> других не лучше)."Не верю!" (с) Станиславский.
> И вообще если вы работаете с миллионными списками вы что-то делаете очень
> неправильно. А со списком в 100 элементов из БД...его хоть как
> медленно обрабатывай это миллисекунды.На самом деле при использовании for ... of разница между 100 элементами и 5000 оказалась не столь существенной. Бэк насиловал БД намного дольше, но fulltext в MySQL -- это пока грустная история
> Наверняка в Node.js другая ситуация, но там гораздо больше ООП, сам API
> этому способствует.Пфф, на бэке есть альтернативы. На фронте пока нет
Хвостовую рекурсию очень легко потерять в ФП. По-сути в обычном коде её и нет, для этого надо специальным образом (считай переписывать) писать функцию. Шаг влево, шаг вправо - и она опять теряется. В Scala даже специальная аннотация, чтобы компилятор выдавал ошибку, если не смог в хвостовую рекурсию.По-ответам я понял что вы используете class-based компоненты React. Я, естественно, говорил про компоненты-функции и hooks.
Замыкание невозможно вынести из функции, на то оно и замыкание (как получить доступ к данным из lexical scope?). А чистых callback в React практически нет, очень мало.
Если использовать Set, то добавление объекта в него не поменяет ссылку самого Set. И перерендера компонента не произойдет. Либо иметь отдельный флаг и постоянно их синхронизировать, либо пересоздавать новый Set из старого. А новый из старого можно получить только интегрированием всех элементов. Вот O(1) взлетело до O(N) на добавление элемента в Set и все его преимущества улетели. Я хотел бы посмотреть на код с Set от вас (желательно с функциями-компонентами), как вы это обходите.
> иметь отдельный флаг и постоянно их синхронизировать, либо пересоздавать новый Set из староголожная дихотомия. Вот тебе попрактиковаться дизайн апи:
const names = useSet();
// Создастся настоящий Set.
// Но хук вернет не его. Хук вернет прокси над ним.
// К настоящему сету доступа не имеешь.names.add('Andy');
// Прокси перенаправляет вызов настоящему сету.
// После этого прокси пересоздается, чтоб поменять ссылку.
// А внутренний сет живет до конца лайфсайкла компонента.names.has('John');
// Прокси перенаправляет вызов настоящему сету.
// Конкретно в has() ссылку менять не требуется - ничего не поменялось.Pеализуется такой апи минут за 10. Ну ладно, за 30, если с юнит-тестами. Под прокси имею в виду "ведет себя как Set, крякает как Set, и может даже умеет проходить условие instanceof Set".
Прикольно, кажется я что-то такое раньше пытался сварганить, но Hermes не умел до недавнего времени в Proxy (пишу на React Native).По-сути, как видишь тут надо пересоздавать Proxy каждый раз, возможно с несколькими функциями / замыканиями. Если брать "старый добрый React" с отбрасыванием функций и побыстрее будет.
А если брать именно алгоритимическую сложность, то я сначала хотел бы с ней столкнуться в профилировании и переписать именно этот кусок. Но это, наверное, надо миллионнами объектов ворочать (те про коллекции, когда обычно в state пара вложенных объектов, да 20-100 элементов массива)
> По-ответам я понял что вы используете class-based компоненты React. Я, естественно, говорил
> про компоненты-функции и hooks.
> Замыкание невозможно вынести из функции, на то оно и замыкание (как получить
> доступ к данным из lexical scope?). А чистых callback в
> React практически нет, очень мало.Поэтому я топлю за классы. Класс инстанцируется перед монтированием компонента, в этот момент в this определяются все атрибуты. Впредь render() может быть вызван многократно, но повторного инстанцирования класса не происходит. Значит, ссылки на коллбэки тоже не изменились. PROFIT
> Если использовать Set, то добавление объекта в него не поменяет ссылку самого ...
Я вообще о другом. Я говорил о структурах данных. О том, что часто вижу паттерн фильтрации массива и исключения из него элементов другого массива. И тут ребята стабильно используют Array.includes вместо Set.has, хотя разница между O(N) и O(1)
Что до ссылок -- не бойтесь использовать воображение :) В собственных типах вы вольны определить метод создания поверхностной копии. Если определить мутабельные внутренние контейнеры как приватные члены класса, и работать с ними через API самих типов, то вы получить и производительность мутабельности, и легковесную поверхностную копию
> Хвостовую рекурсию очень легко потерять в ФП. По-сути в обычном коде её
> и нет, для этого надо специальным образом (считай переписывать) писать функцию.Ну, нет.
Сильно от ЯП зависит, в схеме например сложно её не получить.
Также сильно от стиля и чистоплотности программиста.
>Дело в том, что JS -- это чисто ООП языкНу охереть.
>Ситуация немного сложнее. За тормоза могу пояснить. Причин несколько
Всё немного проще, ненужно ваши сраные реакты месить, а нужно делать максимально простой жс код дополняющий мать её веб страницу, а не рисующий сайт на стороне клиента.
> Всё немного проще, ненужно ваши сраные реакты месить, а нужно делать максимально
> простой жс код дополняющий мать её веб страницу, а не рисующий
> сайт на стороне клиента.А пацаны из ФБ то и не знали! Чтобы приложение не тормозило, достаточно старого советского (текст виден только премиум пользователям Opennet)
Фейсбук эталонный пример мерзкой помойки.
Его существовать не должно в принципе.
> Фейсбук эталонный пример мерзкой помойки.
> Его существовать не должно в принципе.То ли дело контач с одноклассниками!
Не могу сделать однозначный выбор.
Но уверен что линкедин хуже их всех.
> Но уверен что линкедин хуже их всех.Сразу понятно отношение человека к работе
>Забавно, что как только я заменил обработку больших коллекций с `forEach` на `for ... of`, приложение резко стало работать ощутимо быстрее.1. Это выглядит как недороботка движка а не проблема языка. Но я не эксперт.
2. А тут я уверен абсолютно. Ваши большие каллекции и есть первопричина тормозов вашего, гм, приложения. Прекратите пожалуйста у клиента в браузере свои каллекции мурыжить. И сразу веб тормозить перестанет.
> 1. Это выглядит как недороботка движка а не проблема языка. Но я
> не эксперт.Всё крайне просто. На каждый вызов функции создаётся новый фрейм с локальными переменными
> 2. А тут я уверен абсолютно. Ваши большие каллекции и есть первопричина
> тормозов вашего, гм, приложения. Прекратите пожалуйста у клиента в браузере свои
> каллекции мурыжить. И сразу веб тормозить перестанет.Уже бегу доносить пользователям, что им не следует запрашивать тысячи записей, даже если это их сознательное решение. По умолчанию там кстати обычно влетает около сотни записей, но пользователь волен сменить умолчания. В особых случаях может влететь более 10к записей -- это мегабайт 10 данных. С учётом пагинации (да, архаика, но очень экономит ресурсы) накладные расходы нулевые
> Уже бегу доносить пользователям, что им не следует запрашивать тысячи записейТак это пользователи вас заставляют такие сайты делать?
> может влететь более 10к записей -- это мегабайт 10 данных. С
> учётом пагинации (да, архаика, но очень экономит ресурсы) накладные расходы нулевыеНакладные расходы нулевые на загрузку и парсинг 10к записей? В Жабаскрипт?
>накладные расходы нулевые
Так вы же точно точно сравнивали с решением выдающим уже готовый ШТМЛ клиентам, вместо вашего реакта?
Точно точно сравнили?
И разница получилась нулевая?
> Так вы же точно точно сравнивали с решением выдающим уже готовый ШТМЛ
> клиентам, вместо вашего реакта?
> Точно точно сравнили?
> И разница получилась нулевая?Ооо, теперь понятно. То есть грузить 100500 раз вёрстку вместе с данными, по-вашему, эффективнее, чем подгружать единожды код вёрстки и по мере необходимости подсовывать только данные?
> Накладные расходы нулевые на загрузку и парсинг 10к записей? В Жабаскрипт?
Загрузка бесплатная -- в этот момент код не исполняется
Парсинг тысяч записей занимает единицы секунд -- дёшево для тысяч записей
Сделайте две реализации и сравните.
> Сделайте две реализации и сравните.Лол. Перевожу на русский язык -- мы не понимаем различия между XML и JSON. HTML является нестрогим подмножеством XML, поэтому "эффективность" и "компактность" XML в полной мере справедлива для HTML. А ведь помимо данных, неэффективно упакованных в XML, мы каждый раз тащим и прочую вёрстку
Что вы несёте.
Речь идёт о том насколько у пользователя сайт тормозит, а не о эффективности XML.И дело вовсе не в том сколько мы тащим, хотя и в этом, а в том в какие моменты времени мы это тащим, кто как и когда это парсит и отрисовывает.
Не говоря уже что кеширование для динамики никогда не работает.
И я не понял, вы вначале 10к записей пользователю заливаете, а потом уже на страницы разбиваете? Прекращайте это безобразие!
Напишите уже на коленке тест простой и сами сравните хоть на 1000 записей с текстом пускай по 100 слов на запись.
> Что вы несёте.
> Речь идёт о том насколько у пользователя сайт тормозит, а не о эффективности XML.Ну то есть мы не в состоянии задать вопрос, по какой именно причине у пользователя тормозит сайт. До джуна не дотягиваете. Подсказываю -- ответить на этот вопрос поможет профайлинг. И прямо говорю -- 99% тормозов происходят из-за медлительной сети
> И дело вовсе не в том сколько мы тащим, хотя и в этом, а в том в какие моменты времени мы это тащим, кто как и когда это парсит и отрисовывает.
Ага. Отсюда и далее начинаем штудировать, что такое AJAX и REST. Где сильные места и где слабые, что масштабируется и что нет. Даже от джуна требуется понимание этих базовых вещей
Из всех тех вещей, которые вы пока ещё не понимаете, хочу обратить внимание на нагрузку на бэкэнд. Рендеринг на бэкэнде потребляет много ресурсов CPU, что заставляет вас масштабировать сервера. Готовы ли вы лишиться части своей ЗП и пустить её на ненужные сервера, которые будут заниматься промышленным форматированием строк и генерацией HTML?
Вторая вещь, которую вы до сих пор не понимаете -- пользователь посещает сайт один раз или переходит со страницы на страницу? Сколько дублей данных получит пользователь по медленной сети, если отдавать ему отрендеренный HTML?
> Не говоря уже что кеширование для динамики никогда не работает.
Да. По этой же причине кэширование динамически отрендеренных HTML страниц тоже не работает. Поздравляю, вы сами сказали, что несёте бред.
> И я не понял, вы вначале 10к записей пользователю заливаете, а потом уже на страницы разбиваете? Прекращайте это безобразие!
Ничерта вы не поняли. Как именно я сформулировал эту мысль? Прочитайте ещё раз
> Напишите уже на коленке тест простой и сами сравните хоть на 1000 записей с текстом пускай по 100 слов на запись.
Предыдущие 2 пункта абсурдны и ещё 2 пункта демонстрируют отсутствие знаний. Если цитату вырвать из контекста, то к ней претензий нет -- бэк должен прочитать данные из БД и сериализовать их, потом данные надо передать по сети, потом парсинг происходит минимум за O(N) (алгоритмов парсинга JSON не изучал, поэтому точно не скажу)
Только в абсолютном значении разница между 10мкс и 100мкс мало заметна
Ещё забавный момент -- накладные расходы на 1 запись получаются меньшими при большем числе записей
И тут умный человек бы задал совсем другой вопрос -- уверен ли я, что пользователь прочитает все 10к записей. И тут ответ уже нет. Но я как бы ранее говорил, что умолчания настроены таким образом, чтобы пользователю в среднем влетало 100 записей. Только пользователь сам и сознательно может запросить больше -- я его не сдерживаю
> Всё новое - хорошо забытое старое. Ещё 15 лет назад пайтонскрипт и
> джаваскрипт конкурировали между собой за эту веб-нишу. Джваваскипт вышел победителем в
> этой конкуренции, потому что питон оказался слишком тормозным и жрущим память.Жаль только, что о тех событиях ты знаешь только по слухам.
https://web.archive.org/web/20060522132352/http://shootout.a...
https://web.archive.org/web/20060924084722/http://shootout.a...
Тормозной жопоскрипт - в самом конце.
2008:
https://web.archive.org/web/20080616092357/http://shootout.a...
https://web.archive.org/web/20080615141859/http://shootout.a...
А могли бы няшный лисп использовать.
> А могли бы няшный лисп использовать.Да все что угодно было быстрее ЖС.
ratio language score ×
...
6.0 Lua 11.6
7.2 Pike 9.7 1
7.7 Python 9.1
8.4 Tcl 8.3 3
12 PHP 5.9 4
12 Perl 5.6 4
...
15 Icon 4.7 7
17 Ruby 4.1 2
76 JavaScript SpiderMonkey 0.9 9
Но теперь "это было давно и поэтому почти совсем не правда!" и "Вы фсе врети! ЖС быстрый из-за грамотного дизайна, а не потому что гугл и мурзилла вложили сотню миллионов в разработку движка!"
> ЖС быстрый
> из-за грамотного дизайна
> грамотного
> дизайнану ок :/
>> ЖС быстрый
>> из-за грамотного дизайна
>> грамотного
>> дизайна
> ну ок :/man sarcasm
Ну и да, обычно местные ЖСнкики таким макаром и аргументируют "техническое превосходство" ЖС - "глядите, есть V8, который супер-пупер быстр! Вот!".
А то, что до V8 (и мурзиловского аналога) ЖС был самым жручим и тормозным скриптовым ЯП - так "это было давно и поэтому непрвда!"(с)
> былбыл
>> Джваваскипт вышел победителемИ гугл тут не причём
И тут приходит React Native и ... опять придется смузи ненавистникам плеваться и писать на JavaScript и React.
Фронт уже можно писать на Rust, см. https://seed-rs.org/
> a![
> C!["navbar-item", IF!(matches!(page, Page::TimeTracker(_)) => "is-active"),],
> ...
> ],А теперь сравни это с JSX и задайся вопросом, кому этот руст с сомнительным синтаксисом сдался на фронте. Куда бы он ни компилился -- будет оверхед. В васм? Рантайм-оверхед при boundary crossing. В тот же жс? Рантайм-оверхед для нескучной рустовской стд библиотеки.
О, так он еще и на вдоме. Мужик чутка опоздал лет на 5-10, тут на фронте отказ от вдома в пользу гуя, собираемого на этапе компиляции, так что в рантайме вообще не приходится сравнивать реалдом с вдомом.
Это неправда. Никакого отказа от vdom и в помине нет. Это маргинальные фреймворки, с несколькими пользователями.Во-первых потому что React Native. Во-вторых новый который исправляет недостатки, выявленные в ходе эксплуатации.
Убьёт эти фоеймворки "на этапе компиляции" в самом зародыше.
> Никакого отказа от vdom и в помине нетНайди мне хотя бы одного ярого реакт-разраба (меня например), который бы сказал, что ему нравится вдом и сама идея держать че-то там параллельно реальному дому и делать постоянные сравнения, пусть и shallow (а местами и deep). Реакт дал способ быстро и наглядно оформлять компоненты, за что ему большое спасибо, но в свое время он не додумался реализовать это ничем иным, кроме как вдомом, убеждая всех вокруг, что без вдома тут никак. Сегодня (в 2к21) можно сохранить выразительность реакта безо всякого вдома.
Линк для размышлений https://krausest.github.io/js-framework-benchmark/index.html
Я, например. Хоть я и пишу на React Native. И уже поэтому от ничего ни за что не откажусь. Ничего похожего для других фреймворков даже близко нет.И с новым React 18 с concurrent rendering, data fetching, suspense и в Web не будет альтернатив.
А с Recoil, который умеет доставлять обновления состояния без перерендеринга (пусть с мемоизацией) всего поддерева...
Ну, кто что-то похожее умеет?
Все эти идеи быстро разваливаются с medium-size кодом, который в production.И пока не будет 10 крупных компаний, использующих эти compile-time фреймворки в production и платящих (!!!) разработчикам этих компиляторов зарплату для допиливания - использовать их больше чем в Hello World глупо.
Поэтому нет никакого перехода, и даже не намечается.
Это просто интересные концепты, на поиграться.
> concurrent rendering, data fetching, suspenseПишешь так, словно throw promise -- это нечто выдающееся. Повторюсь: реакт здесь и близко не первооткрыватель, всё везде есть.
> Recoil, который умеет доставлять обновления состояния без перерендеринга (пусть с мемоизацией) всего поддерева
Рекоил -- это признание того, что реактовские контексты -- фуфло, и что РЕАКТивную систему для РЕАКТа следует переизобрести заново (лол).
В правильных фреймворках не нужны никакие тысячи-и-один сторонние менеджеры стейта, так как реактивность слишком сильно интегрируется с обновлениями UI, и ее реализация не может быть отложена на потом или доверена сторонним васянам (пусть даже рекоил и пилится тем же пейспуком, с большим опозданием btw).
> Ну, кто что-то похожее умеет?
Все умеют, причем не только в вебе. Еще до всяких реактов был Meteor с ReactiveVar, есть всякие RxJS, а какой-нибудь SolidJS умеет этот твой суспенс и поставляет из коробки реактивный стейт-менеджер. Это я назвал маргинальщину, про топ-5 ты и сам знаешь, что они это все тоже умеют.
> 10 крупных компаний, использующих эти compile-time фреймворки в production
Помню ходил на собеседования в году эдак 2013-15-ых и рассказывал всем, что знаю ВУЭ. Никто о нем и слыхать не слыхивал. How the turn tables.
Будет такая же история, как с веб-фреймворками. Пока у тебя 1 запрос в секунду, всё ок.
С браузером будет ок, пока 1 обработчик в форме, а если 10, то вкладка виснет и падает.
Питон не годен ни для чего, требующего производительности, хоть какой-нибудь. Он не универсален. Он не прост. Код на питоне практически всегда уродлив и непонятен.Проблема в том, что если раньше питонячий кал можно было не устанавливать и не использовать, то теперь его будут незаметно подкладывать в браузер, где будет и не так просто понять, откуда же такие тормоза.
Толсто.
если сделают транслятор пихтона в js то может бытьа если нет - то на кой черт этот vdom если для запуска страницы нужно грузить целый интерпретатор
Собрать Python под WebAssembly теперь проще чем под Windows?
Сразу надо было. Сколько лет упущено на упоротый JS, из которого всё пытались сделать нормальный ЯП.
ЖабаСкрипт нормальный. Это ты рукожоп.
Не нервничай, малыш.
так питон не лучше.
Как бы плох питон не был, но пальму первенства встратости ЯП у джаваскрипта отобрать он не может.
это как с ключами. Ищешь ищешь, а они все это время у тебя в руках были.
Выучи его наконец, хватит ныть и страдать.Ещё один ниасилятор. Как старая бабка ворчишь (в разгар рабочего дня)
Может, и делает это очень легко.
уж лучше js - там хотябы все нативно и интерпретатор пхитона не придется загружать в браузере
Астанавитесь!
Врятли взлетит как тот же brython
если добавят в vscode.dev - будет неплохо
отшитоним все вокруг, быстро дёшево, написал проверил - статейку в журнал и забыл
Bash в браузер!
x86 asm
одобряю
Астрологи предсказали, что год макаки будет каждым годом, начиная со следующего. Количество обезьяньего кода возрастёт в 10 раз.
Как же они достали со своим вредоносным микроархитектурно-атакующим проприетарным очень хреново реверсящимся (по сравнению с JS) WASMом.У всех нормальных людей он в браузере запрещён. А теперь каждого вынудят включить это говно WASM. Это дискриминация и harrasment!
Ну действительно, не на VanillaJS же писать.
>позволяющих собрать основную ветку CPython для работы внутри браузераНадеюсь в links2 добавят.
links2 прогрессивынй браузер?
Да. Там очень хорошая экономия трафика, да и дизайн приложения классный, сам настраиваешь его себе. Последняя версия 2.25 выходила 3-ого октября. А самое главное то что он под свободной лицензией и не зависит от корпораций. Так что links2 это синоним прогрессивности.
На скриптовых языках нельзя писать полноценные проекты. Это ведет только к тормозам и жеру памяти. Так что ждем, пока поддержку этого питона не добавят прямо в процы.
по крайней мере Java и JavaScript JIT-компилятся, а пхтон типа бейсика, выполняется строка за строкой. Ну максимум AST готовое в *.pyc-запишут и заименуют гордо "СКОМПИЛЕНО!!111"
Тот нелепый случай когда кудахтер не разобрался даже с бейсиком, а агонирует на что-то сложнее
> по крайней мере Java и JavaScript JIT-компилятся, а пхтон типа бейсика, выполняется строка за строкой. Ну максимум AST готовое в *.pyc-запишут и заименуют гордо "СКОМПИЛЕНО!!111"Опеннетный Эксперд во все своей красе!
https://docs.python.org/3/glossary.html#term-bytecode
> Python source code is compiled into bytecode, the internal representation of a Python program in the CPython interpreter. The bytecode is also cached in .pyc fileshttps://doc.pypy.org/en/latest/release-1.0.0.html
> PyPy 1.0: JIT compilers for free and more.
Тебя в каком году заморозили? В 2000х?JavaScript - это спецификация (синтаксис и семантика). А как он исполняется - это детали имплементации. V8 - это JIT движок, как и в остальных браузерах, Hermes в бинарь компилит.
Интерпретируемый JavaScript можно только в embedded найти. Там он в 30х раз медленее, зато очень энергоэффективен.
> пока поддержку этого питона не добавят прямо в процы.Уже проходили с жабой в ARM.
А вот жава была божественна как встраиваемый язык. Её для этого и разрабатывали как бы, чтобы на кофеварках интернета вещей работать.
Но оракл решил что у него более "интересное" применение для неё, а жёсткая лицензионная политика забила гвоздь в гроб ембеда на жаве.
Ага, уже вижу как зловреды изо всех сайтов лезут на полноценном питоне... Как отрубить лишние концы таким штукам в браузере?
Вставьте им лишний пробел в отступы)
Что, теперь браузер станет средой разработки языка программирования Питон? Я правильно понял?
и да и нет
Средой разрабоки? Так уже есть Jupyter. И даже через браузер отображает. Ну разве что и Jupyter-сервер в браузер затолкать.
Можно будет писать скрипты на Python для криптомайнинга в браузерах.
Но на Расте, наверное, все же эффективней будет.
Когда они уже чуть больше уделят внимания мобилкам и нормальному гую из коробки? Вот эти все веб-костылики ни о чём
Кто они, василиска? Это тебе нужно, ты и делай.
Мне то же нужно. Где проголосовать за эту василиску?
Более тесная интеграция с сервисами github это отлично.
Про WASI ...
А эта самая WASI находится в стадии активной рекламы. Таких рекламных компаний было уже много. Или таки кто-то этим уже пользуется в практических целях?
И жаль, конечно, что python не очень хорошо поддерживает разработку мобильных приложений. Эта ниша почти потеряна.
Как и большинство webassembly трансляций - это побудет новостью некоторое время и потом об этом все забудут. (Много игр забыто на этом поприще) Из-за того что webassembly тяжелый, еше питон модули надо туда компилировать. Думаю студенты и останутся его основными пользователями.Да и вроде pypy что быстрее cpython раз в 7 уже портирован под webassembly.
Сюда допишите как альтернатива 7.
Pros / cons не забудьте дописать.
Ну и можно потом подождать еще два годика...
ранобрадовались питономакаки это не про фронтенд а про то чтобы без установки пихтона потестить что нибуть на питонесайты и приложухи на это не сделать - иначе если тащить целый интерпретатор - в дурку сразу заберут
когда же можно будет поиграть в Call of Duty в браузере?
PyQt или хотябы Tkinter там работает? Если да, я бы за это даже платил.