Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Основная ветка Python адаптирована для сборки для работы в браузере"	+/–
Сообщение от opennews (??), 29-Ноя-21, 08:53
Итан Смит (Ethan Smith), один из основных разработчиков  MyPyC, компилятора модулей  Python в код на языке Си, сообщил о добавлении в кодовую базу CPython (базовая реализация Python) изменений, позволяющих собрать основную ветку CPython для работы внутри браузера, не прибегая к дополнительным патчам. Сборка осуществляется в универсальный низкоуровневый промежуточный код WebAssembly при помощи компилятора Emscripten... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56246
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Основная ветка Python адаптирована для сборки для работы в б..."	+21 +/–
Сообщение от Аноним (1), 29-Ноя-21, 08:53
какой ужос!
Ответить | Правка | Наверх | Cообщить модератору

	158. "Основная ветка Python адаптирована для сборки для работы в б..."	+/–
	Сообщение от Аноним (158), 02-Дек-21, 23:45
	Интересно, а они VBScript уже выпилили везде или нет?
	Ответить | Правка | Наверх | Cообщить модератору

2. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Анто Нимно (?), 29-Ноя-21, 09:01
> ... без привязки в web-браузеру. Отмечается, что для реализации подобной возможности потребует проделать большую работу ... Могло быть лучше.
Ответить | Правка | Наверх | Cообщить модератору

	26. "В основной ветке Python появилась возможность сборки для раб..."	+13 +/–
	Сообщение от ИмяХ (?), 29-Ноя-21, 10:57
	Это хорошо, когда придумывают прослойки для прослоек для работы на прослойках. Программисты без работы не останутся.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "В основной ветке Python появилась возможность сборки для раб..."	+2 +/–
	Сообщение от А (??), 29-Ноя-21, 14:25
	Но плохо, когда перкрывают пути для работы без прослойки.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
	Сообщение от Аноним (94), 29-Ноя-21, 17:49
	Итогом будет google translate с языками программирования.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	121. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (121), 30-Ноя-21, 09:22
	Вообще-то уже есть.
	Ответить | Правка | Наверх | Cообщить модератору

3. "В основной ветке Python появилась возможность сборки для раб..."	+4 +/–
Сообщение от Лолошка (?), 29-Ноя-21, 09:02
Приехали....
Ответить | Правка | Наверх | Cообщить модератору

4. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
Сообщение от Аноним (4), 29-Ноя-21, 09:09
Урааааа! Наконец-то можно хлебать смузи хлебая смузи! Из браузера вообще не надо выходить!
Ответить | Правка | Наверх | Cообщить модератору

	138. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Омномним (?), 30-Ноя-21, 20:57
	Позравляем с успешной разморозкой! У нас тут хромоось рулит и побеждает. Вам понравится!
	Ответить | Правка | Наверх | Cообщить модератору

5. "В основной ветке Python появилась возможность сборки для раб..."	–4 +/–
Сообщение от Аноним (5), 29-Ноя-21, 09:09
Ну жс хотя бы быстрый, но эти смузихлёбы же угробят браузер!
Ответить | Правка | Наверх | Cообщить модератору

	8. "В основной ветке Python появилась возможность сборки для раб..."	+4 +/–
	Сообщение от Аноним (8), 29-Ноя-21, 09:16
	Жс не быстрый, быстрый v8. И v8 не жс. Если питон ускорят в 100 раз, как планируют, то вполне реальная замена. Либо пока что можно не писать такой дрянной код с тысячами абстракций и будет вполне сносно и так.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "В основной ветке Python появилась возможность сборки для раб..."	+2 +/–
	Сообщение от Аноним (59), 29-Ноя-21, 14:12
	Python / PHP / Bash / BrainFuck не медленный...это просто СPython / ... в 10 раз медленнее JavaScript...ой, простите, V8. Ну и что, что 90% браузеров в мире (Chrome и MS Edge) имеют именно V8... Или движок Firefox или Safari медленнее? Так же в десятки раз быстрее Python. Opennet-экперт...как обычно. Это уже бренд.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от Аноним (8), 29-Ноя-21, 14:39
	С ducktape сравнивай. А с каких пор конкуренты в8 ускорились, они с в8 содрали пример? В8 адово жручий, такой питон никому будет не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 29-Ноя-21, 15:12
	Браузерные движки все очень быстрые, все 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 на батарейках. Видимо самая простая интерпретация кода самая энергоэффективная. Хотя мне непонятно почему так.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
	Сообщение от Аноним (61), 29-Ноя-21, 14:17
	> Если питон ускорят в 100 раз Если.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	69. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (59), 29-Ноя-21, 14:31
	Даёшь Нью-Васюки!!! Python будет ускорен в 1000 раз! Весь JavaScript будет переписан на Python!!! Браузеры начнут поддерживать Python как второй язык!!! Python окончательно вытесняет JavaScript!!! Всеобщая и вселенская победа!!! Товарищи, скидываемся по рублю на это благое дело!!!
	Ответить | Правка | Наверх | Cообщить модератору

	79. "В основной ветке Python появилась возможность сборки для раб..."	–4 +/–
	Сообщение от Аноним (79), 29-Ноя-21, 15:25
	Если браузерный код начнут писать на питоне, то лучше я воздержуть от использования таких сайтов.... Обычно квалификация бакендеров выше, чем у фронтендеров в части программирования. Питон и сам по себе не для программирования чего-то ответственного. Но когда его дают совершенно безответственным - это просто страшно.....
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	98. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от Аноним (98), 29-Ноя-21, 21:12
	> Питон и сам по себе не для программирования чего-то ответственного дооооо, сразу видно - иксперт
	Ответить | Правка | Наверх | Cообщить модератору

6. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
Сообщение от Аноним (8), 29-Ноя-21, 09:13
Без жс на этот раз? Ну а что, почему нет. Писать на питоне всяко приятней, чем на жс.
Ответить | Правка | Наверх | Cообщить модератору

	11. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от sudormrf (?), 29-Ноя-21, 09:37
	ЖС хоть компрессить можно, уже вижу эти петабайты пробелов в эфире без гзипа. )
	Ответить | Правка | Наверх | Cообщить модератору

	14. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от ОйойаЙ (?), 29-Ноя-21, 09:48
	Сделают промежуточный слой в виде компрессии и делов-то.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (30), 29-Ноя-21, 11:09
	Так питонокод же в WASM компилять предполагается.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	39. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (39), 29-Ноя-21, 12:03
	нет
	Ответить | Правка | Наверх | Cообщить модератору

	43. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Онаним (?), 29-Ноя-21, 12:11
	И смысл? Полный интертрепатор без JIT, велкам ту зе словнесс хелл.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (39), 29-Ноя-21, 14:00
	Гвидо вон предложил использовать для разработки в браузере. Школьнико-студентов каких-нибудь можно обучать, не устанавливая ничего. А вообще, конечно, всё это практической ценности имеет мало и смысл тут в том, что у кого-то было время сделать это и он получил от этого удовольствие и строку в резюме.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В основной ветке Python появилась возможность сборки для раб..."	–4 +/–
	Сообщение от Аноним (61), 29-Ноя-21, 12:04
	> Писать на питоне всяко приятней, чем на жс Решил тут изучить пихтончик и обнаружил, что его встроенная система аннотаций типов не позволяет нормально ссылаться из методов класса на тип самого класса. Только через строки, лол. Типа -> 'TreeNode', а не -> TreeNode. Ну и при этом нужно постоянно держать в голове, какой модуль в каком порядке грузится, в то время, как в TypeScript есть import type, который из результирующей сборки вырезается и не ведет к циклическим зависимостям. Да и вообще можно ссылаться на типы, объявленные много позже снизу. Без строк мля. Просто ссылаешься и все. Далее, пихонщикам, как чисто бэковским бейсикописателям (разрабами их язык не повернется назвать), еще только предстоит освоить tree shaking, у них там из-за одной библиотечной функции небось придется всю библиотеку в рантайм тащить, а не только ровно эту одну функцию. В общем добро пожаловать в 2005 год, когда из-за пары jquery-функций в рантайм тащили весь jquery. Как говорил бен Ладен, "это вы нас считаете пожирателями оперативы? вот придут наши дети пихтонщики, и вы нас еще добрыми словами вспоминать будете". Далее, пока в васм не завезут нормальный интероп с жс и дом апи, ни о каком быстродействии речь идти не может. Да там банально проще на стороне жс поманипулировать домом, чем вначале подготовить данные, сериализовать в буффер, отправить буффер в васм, потом его оттуда принять, сдекодировать и применить к дому на стороне того же самого жс. Потому что васм к дому доступа не имеет, он может лишь намекнуть жсу, что "было б неплохо, если б ты это вот сюда вот засунул".
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	100. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от Триангулярный (?), 29-Ноя-21, 21:15
	> ссылаться из методов класса на тип самого класса. Только через строки, лол. Типа -> 'TreeNode', а не -> TreeNode Щито, Ълять?
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (61), 30-Ноя-21, 06:45
	пюхтоно-бейсикописатели не в курсе про свои же подобия "инструментов статической типизации"? https://docs.python.org/3/library/typing.html
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Урри (ok), 29-Ноя-21, 13:08
	аксиома-эскобара.avi
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (7), 29-Ноя-21, 09:16
Даёшь а-ля электрон на питоне
Ответить | Правка | Наверх | Cообщить модератору

	72. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноним (72), 29-Ноя-21, 14:34
	А было бы отличненько. Но вообще есть PyQt. Но мобилки из него вырвали
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (30), 29-Ноя-21, 16:28
	PySide? Жив ли он ещё?
	Ответить | Правка | Наверх | Cообщить модератору

9. "В основной ветке Python появилась возможность сборки для раб..."	–6 +/–
Сообщение от Аноним (9), 29-Ноя-21, 09:28
PHP давай, до свидания.
Ответить | Правка | Наверх | Cообщить модератору

	27. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
	Сообщение от Аноним (27), 29-Ноя-21, 11:02
	А зачем Emscripten для этого? На бэке и так можно Python использовать.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (30), 29-Ноя-21, 11:13
	PHP на стороне сервера только. А Python на стороне сервера и так есть: Zope, Django.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	104. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (104), 29-Ноя-21, 23:16
	И никому особо не нужен Вот и пихают во фронт
	Ответить | Правка | Наверх | Cообщить модератору

	36. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от kusb (?), 29-Ноя-21, 11:29
	php client side?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	145. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (145), 30-Ноя-21, 22:16
	просто оставлю это здесь https://www.peachpie.io/2021/08/run-debug-php-browser.html
	Ответить | Правка | Наверх | Cообщить модератору

	146. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (145), 30-Ноя-21, 22:20
	на php можно в blazor https://www.peachpie.io/2021/08/run-debug-php-browser.html который компилируется в webasm полностью а на питоне что? запускать скомилированный интепретатор, который будет запускать искодник питон кода, который будет интерпретироватся? даше файл pyc не сохранить
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

10. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (9), 29-Ноя-21, 09:31
> компилятора модулей Python в код на языке Си А propos. Почему питон компилируют в С, валу компилируют в С, ним компилируют в С, да практически любой язык компилируют в С. Почему ничего не компилируют в передовой раст? 🤷🏻‍♂️
Ответить | Правка | Наверх | Cообщить модератору

	19. "В основной ветке Python появилась возможность сборки для раб..."	–3 +/–
	Сообщение от Аноним (19), 29-Ноя-21, 09:55
	Наверно потому, что Rust не допускает некоторых потенциально небезопасных конструкций. А если другие языки допускают, то транслировать их код в Rust не получится.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноним (19), 29-Ноя-21, 11:09
	Те, кто минусит, хотелось бы почитать ваши соображения. Если они у вас есть, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "В основной ветке Python появилась возможность сборки для раб..."	+2 +/–
	Сообщение от Аноним (101), 29-Ноя-21, 22:22
	Излагать соображения - unsafe. Минусить - safe.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "В основной ветке Python появилась возможность сборки для раб..."	–3 +/–
	Сообщение от Аноним (-), 29-Ноя-21, 10:05
	потому что раст течёт, если только java приделают как нибудь, у них все равно петабайты памяти
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	34. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (8), 29-Ноя-21, 11:13
	Ну действительно пару примитивных батареек подключаешь и уже какой-то дикий жор. Лучше не вспоминать, сколько времени компиляция занимает. Тем временем питон с сотней батареек не жрёт почти ничего.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (80), 29-Ноя-21, 15:26
	> потому что раст течёт А есть пруфы?
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	78. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (80), 29-Ноя-21, 15:24
	> Почему ничего не компилируют в передовой раст? А смысл? Компиляция в Си позволяет просто поддерживать большое количество платформ. Хотя бо́льшая часть языков все же компилируются не в Си, а в байткод LLVM. А компилировать в Rust сильно сложнее, потому что надо аккуратно генерировать код, чтобы удовлетворить borrow checker. Либо писать много unsafe, но тогда чаще всего это не лучше, чем в Си компилировать. Обычно считается все же, что компиляторы сами должны проверять безопасность кода, который они генерируют, а не перекладывать эту задачу на кого-либо. А вот для написания кода руками дополнительные проверки во времени компиляции как раз сильно помогают :) Кстати, насчет байткода LLVM: почему на нем не пишут программы, если крупные компиляторы (вроде Clang) генерируют его из исходного кода? :)
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	109. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:24
	Кстати, а почему? Как байт-код этот выглядит то? Там говорят только совсем совсем недавно оптимизацию хвостового вызова добавили.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "В основной ветке Python появилась возможность сборки для раб..."	+2 +/–
	Сообщение от man man (?), 29-Ноя-21, 23:09
	> практически любой язык компилируют в С нет. если кратко (и заодно грубо, как по приближению, так и вообще): макакские - да, человеческие нет. и должно быть очень стыдно не отличать трансляцию от компиляции. а впрочем, ну вас всех.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

12. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
Сообщение от kai3341 (ok), 29-Ноя-21, 09:38
Лёд тронулся. В течение пары лет появятся питонячьи фреймворки, генерящие DOM с поддержкой virtual DOM. И вот тут я уже буду задавться вопросом -- фронт писать на React или на Python Короче, развесовка по рыночку может измениться
Ответить | Правка | Наверх | Cообщить модератору

	16. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (-), 29-Ноя-21, 09:51
	Просто твои знания устареют и станут не нужными.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "В основной ветке Python появилась возможность сборки для раб..."	–4 +/–
	Сообщение от ИмяХ (?), 29-Ноя-21, 11:03
	Всё новое - хорошо забытое старое. Ещё 15 лет назад пайтонскрипт и джаваскрипт конкурировали между собой за эту веб-нишу. Джваваскипт вышел победителем в этой конкуренции, потому что питон оказался слишком тормозным и жрущим память.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	32. "В основной ветке Python появилась возможность сборки для раб..."	–4 +/–
	Сообщение от Аноним (8), 29-Ноя-21, 11:10
	Глядя на вебню, жрущую гигабайты, лагающую, и вечно текущую… Ну да, ну да, победитель. На бэке то всё равно питон, как ни хотели протащить жс, ничего вменяемого не получается.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 00:02
	> Глядя на вебню, жрущую гигабайты, лагающую, и вечно текущую… Ну да, ну > да, победитель. На бэке то всё равно питон, как ни хотели > протащить жс, ничего вменяемого не получается. Ситуация немного сложнее. За тормоза могу пояснить. Причин несколько Дело в том, что не каждый JS-ный синьор задумывается о структурах данных. 99% структур данных -- это стандартные массивы и Object. И проблема в том, что они не всегда подходят. Например, ребята просто обожают использовать массивы для проверки на включение там, где нужно использовать Set. На ровном месте сложность растёт с линейной до квадратичной. О том, что можно создать собственную структуру данных, знают лишь избранные, а ключевое слово `class`, с которого начинается создание своих структур данных, сегодня в JS подобно ругательству JS-ник сегодня дохера функци-анальщик. Я не против ФП, но против отрыва от реальности. Дело в том, что JS -- это чисто ООП язык, хоть и с функциональными элементами. И оптимизации, гарантированные в ФП, невозможны в JS. В мире JS считается зашкваром перебирание элементов коллекции через `for ... of`. Забавно, что как только я заменил обработку больших коллекций с `forEach` на `for ... of`, приложение резко стало работать ощутимо быстрее. Я не говорю "в топку forEach/map/filter" -- я указываю на ограничения Ещё один рак дохера функци-анальщика -- иммутабельность в каждой дырке. Иммутабельность -- это инструмент, позволяющий реализовать ссылочную прозрачность. Прекрасная штука. При этом JS-ник забывает про цену иммутабельности -- необходимость пересобирать заново структуры данных. Особенно больно на больших списках. И ладно, когда речь о redux. Плохо, когда пересборка структур данных происходит вообще в каждой дырке. Я хочу сказать, что мутабельность -- это тоже инструмент, позволяющий сильно поднять производительность. Как извлечь все выгоды мутабельности и сохранить ссылочную прозрачность -- просто обернуть мутируемую структуру данных в объект с одним ключом Вы прослушали тираду "Дорогие коллеги! Давайте прекращать кодить и учиться программировать!"
	Ответить | Правка | Наверх | Cообщить модератору

	107. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (104), 30-Ноя-21, 00:56
	>> Дорогие коллеги! Давайте прекращать кодить и учиться программировать! А они не поняли Сейчас новую партию коллег с курсов выпустят
	Ответить | Правка | Наверх | Cообщить модератору

	108. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 30-Ноя-21, 03:56
	Как функци-анальщик (велик и могуч русский язык) не соглашусь. Во-первых, я перешёл с функциональной 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 этому способствует.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	117. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 07:39
	Сразу лайк за развёрнутый и конструктивный ответ > 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 > этому способствует. Пфф, на бэке есть альтернативы. На фронте пока нет
	Ответить | Правка | Наверх | Cообщить модератору

	125. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 30-Ноя-21, 12:02
	Хвостовую рекурсию очень легко потерять в ФП. По-сути в обычном коде её и нет, для этого надо специальным образом (считай переписывать) писать функцию. Шаг влево, шаг вправо - и она опять теряется. В Scala даже специальная аннотация, чтобы компилятор выдавал ошибку, если не смог в хвостовую рекурсию. По-ответам я понял что вы используете class-based компоненты React. Я, естественно, говорил про компоненты-функции и hooks. Замыкание невозможно вынести из функции, на то оно и замыкание (как получить доступ к данным из  lexical scope?). А чистых callback в React практически нет, очень мало. Если использовать Set, то добавление объекта в него не поменяет ссылку самого Set. И перерендера компонента не произойдет. Либо иметь отдельный флаг и постоянно их синхронизировать, либо пересоздавать новый Set из старого. А новый из старого можно получить только интегрированием всех элементов. Вот O(1) взлетело до O(N) на добавление элемента в Set и все его преимущества улетели. Я хотел бы посмотреть на код с Set от вас (желательно с функциями-компонентами), как вы это обходите.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (61), 30-Ноя-21, 18:14
	> иметь отдельный флаг и постоянно их синхронизировать, либо пересоздавать новый Set из старого ложная дихотомия. Вот тебе попрактиковаться дизайн апи:     const names = useSet();     // Создастся настоящий Set.     // Но хук вернет не его. Хук вернет прокси над ним.     // К настоящему сету доступа не имеешь.     names.add('Andy');     // Прокси перенаправляет вызов настоящему сету.     // После этого прокси пересоздается, чтоб поменять ссылку.     // А внутренний сет живет до конца лайфсайкла компонента.     names.has('John');     // Прокси перенаправляет вызов настоящему сету.     // Конкретно в has() ссылку менять не требуется - ничего не поменялось. Pеализуется такой апи минут за 10. Ну ладно, за 30, если с юнит-тестами. Под прокси имею в виду "ведет себя как Set, крякает как Set, и может даже умеет проходить условие instanceof Set".
	Ответить | Правка | Наверх | Cообщить модератору

	139. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 30-Ноя-21, 21:30
	Прикольно, кажется я что-то такое раньше пытался сварганить, но Hermes не умел до недавнего времени в Proxy (пишу на React Native). По-сути, как видишь тут надо пересоздавать Proxy каждый раз, возможно с несколькими функциями / замыканиями. Если брать "старый добрый React" с отбрасыванием функций и побыстрее будет. А если брать именно алгоритимическую сложность, то я сначала хотел бы с ней столкнуться в профилировании и переписать именно этот кусок. Но это, наверное, надо миллионнами объектов ворочать (те про коллекции, когда обычно в state пара вложенных объектов, да 20-100 элементов массива)
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 20:57
	> По-ответам я понял что вы используете class-based компоненты React. Я, естественно, говорил > про компоненты-функции и hooks. > Замыкание невозможно вынести из функции, на то оно и замыкание (как получить > доступ к данным из  lexical scope?). А чистых callback в > React практически нет, очень мало. Поэтому я топлю за классы. Класс инстанцируется перед монтированием компонента, в этот момент в this определяются все атрибуты. Впредь render() может быть вызван многократно, но повторного инстанцирования класса не происходит. Значит, ссылки на коллбэки тоже не изменились. PROFIT > Если использовать Set, то добавление объекта в него не поменяет ссылку самого ... Я вообще о другом. Я говорил о структурах данных. О том, что часто вижу паттерн фильтрации массива и исключения из него элементов другого массива. И тут ребята стабильно используют Array.includes вместо Set.has, хотя разница между O(N) и O(1) Что до ссылок -- не бойтесь использовать воображение :) В собственных типах вы вольны определить метод создания поверхностной копии. Если определить мутабельные внутренние контейнеры как приватные члены класса, и работать с ними через API самих типов, то вы получить и производительность мутабельности, и легковесную поверхностную копию
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	154. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 01-Дек-21, 11:04
	> Хвостовую рекурсию очень легко потерять в ФП. По-сути в обычном коде её > и нет, для этого надо специальным образом (считай переписывать) писать функцию. Ну, нет. Сильно от ЯП зависит, в схеме например сложно её не получить. Также сильно от стиля и чистоплотности программиста.
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	110. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:28
	>Дело в том, что JS -- это чисто ООП язык Ну охереть. >Ситуация немного сложнее. За тормоза могу пояснить. Причин несколько Всё немного проще, ненужно ваши сраные реакты месить, а нужно делать максимально простой жс код дополняющий мать её веб страницу, а не рисующий сайт на стороне клиента.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	123. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 09:47
	> Всё немного проще, ненужно ваши сраные реакты месить, а нужно делать максимально > простой жс код дополняющий мать её веб страницу, а не рисующий > сайт на стороне клиента. А пацаны из ФБ то и не знали! Чтобы приложение не тормозило, достаточно старого советского (текст виден только премиум пользователям Opennet)
	Ответить | Правка | Наверх | Cообщить модератору

	124. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 10:53
	Фейсбук эталонный пример мерзкой помойки. Его существовать не должно в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 20:36
	> Фейсбук эталонный пример мерзкой помойки. > Его существовать не должно в принципе. То ли дело контач с одноклассниками!
	Ответить | Правка | Наверх | Cообщить модератору

	155. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 01-Дек-21, 11:09
	Не могу сделать однозначный выбор. Но уверен что линкедин хуже их всех.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kai3341 (ok), 02-Дек-21, 01:48
	> Но уверен что линкедин хуже их всех. Сразу понятно отношение человека к работе
	Ответить | Правка | Наверх | Cообщить модератору

	111. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:36
	>Забавно, что как только я заменил обработку больших коллекций с `forEach` на `for ... of`, приложение резко стало работать ощутимо быстрее. 1. Это выглядит как недороботка движка а не проблема языка. Но я не эксперт. 2. А тут я уверен абсолютно. Ваши большие каллекции и есть первопричина тормозов вашего, гм, приложения. Прекратите пожалуйста у клиента в браузере свои каллекции мурыжить. И сразу веб тормозить перестанет.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	122. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 09:45
	> 1. Это выглядит как недороботка движка а не проблема языка. Но я > не эксперт. Всё крайне просто. На каждый вызов функции создаётся новый фрейм с локальными переменными > 2. А тут я уверен абсолютно. Ваши большие каллекции и есть первопричина > тормозов вашего, гм, приложения. Прекратите пожалуйста у клиента в браузере свои > каллекции мурыжить. И сразу веб тормозить перестанет. Уже бегу доносить пользователям, что им не следует запрашивать тысячи записей, даже если это их сознательное решение. По умолчанию там кстати обычно влетает около сотни записей, но пользователь волен сменить умолчания. В особых случаях может влететь более 10к записей -- это мегабайт 10 данных. С учётом пагинации (да, архаика, но очень экономит ресурсы) накладные расходы нулевые
	Ответить | Правка | Наверх | Cообщить модератору

	133. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 20:13
	> Уже бегу доносить пользователям, что им не следует запрашивать тысячи записей Так это пользователи вас заставляют такие сайты делать? > может влететь более 10к записей -- это мегабайт 10 данных. С > учётом пагинации (да, архаика, но очень экономит ресурсы) накладные расходы нулевые Накладные расходы нулевые на загрузку и парсинг 10к записей? В Жабаскрипт? >накладные расходы нулевые Так вы же точно точно сравнивали с решением выдающим уже готовый ШТМЛ клиентам, вместо вашего реакта? Точно точно сравнили? И разница получилась нулевая?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kai3341 (ok), 30-Ноя-21, 20:25
	> Так вы же точно точно сравнивали с решением выдающим уже готовый ШТМЛ > клиентам, вместо вашего реакта? > Точно точно сравнили? > И разница получилась нулевая? Ооо, теперь понятно. То есть грузить 100500 раз вёрстку вместе с данными, по-вашему, эффективнее, чем подгружать единожды код вёрстки и по мере необходимости подсовывать только данные? > Накладные расходы нулевые на загрузку и парсинг 10к записей? В Жабаскрипт? Загрузка бесплатная -- в этот момент код не исполняется Парсинг тысяч записей занимает единицы секунд -- дёшево для тысяч записей
	Ответить | Правка | Наверх | Cообщить модератору

	150. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноньимъ (ok), 01-Дек-21, 05:27
	Сделайте две реализации и сравните.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kai3341 (ok), 01-Дек-21, 06:08
	> Сделайте две реализации и сравните. Лол. Перевожу на русский язык -- мы не понимаем различия между XML и JSON. HTML является нестрогим подмножеством XML, поэтому "эффективность" и "компактность" XML в полной мере справедлива для HTML. А ведь помимо данных, неэффективно упакованных в XML, мы каждый раз тащим и прочую вёрстку
	Ответить | Правка | Наверх | Cообщить модератору

	153. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноньимъ (ok), 01-Дек-21, 10:50
	Что вы несёте. Речь идёт о том насколько у пользователя сайт тормозит, а не о эффективности XML. И дело вовсе не в том сколько мы тащим, хотя и в этом, а в том в какие моменты времени мы это тащим,  кто как и когда это парсит и отрисовывает. Не говоря уже что кеширование для динамики никогда не работает. И я не понял, вы вначале 10к записей пользователю заливаете, а потом уже на страницы разбиваете? Прекращайте это безобразие! Напишите уже на коленке тест простой и сами сравните хоть на 1000 записей с текстом пускай по 100 слов на запись.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kai3341 (ok), 02-Дек-21, 02:18
	> Что вы несёте. > Речь идёт о том насколько у пользователя сайт тормозит, а не о эффективности XML. Ну то есть мы не в состоянии задать вопрос, по какой именно причине у пользователя тормозит сайт. До джуна не дотягиваете. Подсказываю -- ответить на этот вопрос поможет профайлинг. И прямо говорю -- 99% тормозов происходят из-за медлительной сети > И дело вовсе не в том сколько мы тащим, хотя и в этом, а в том в какие моменты времени мы это тащим, кто как и когда это парсит и отрисовывает. Ага. Отсюда и далее начинаем штудировать, что такое AJAX и REST. Где сильные места и где слабые, что масштабируется и что нет. Даже от джуна требуется понимание этих базовых вещей Из всех тех вещей, которые вы пока ещё не понимаете, хочу обратить внимание на нагрузку на бэкэнд. Рендеринг на бэкэнде потребляет много ресурсов CPU, что заставляет вас масштабировать сервера. Готовы ли вы лишиться части своей ЗП и пустить её на ненужные сервера, которые будут заниматься промышленным форматированием строк и генерацией HTML? Вторая вещь, которую вы до сих пор не понимаете -- пользователь посещает сайт один раз или переходит со страницы на страницу? Сколько дублей данных получит пользователь по медленной сети, если отдавать ему отрендеренный HTML? > Не говоря уже что кеширование для динамики никогда не работает. Да. По этой же причине кэширование динамически отрендеренных HTML страниц тоже не работает. Поздравляю, вы сами сказали, что несёте бред. > И я не понял, вы вначале 10к записей пользователю заливаете, а потом уже на страницы разбиваете? Прекращайте это безобразие! Ничерта вы не поняли. Как именно я сформулировал эту мысль? Прочитайте ещё раз > Напишите уже на коленке тест простой и сами сравните хоть на 1000 записей с текстом пускай по 100 слов на запись. Предыдущие 2 пункта абсурдны и ещё 2 пункта демонстрируют отсутствие знаний. Если цитату вырвать из контекста, то к ней претензий нет -- бэк должен прочитать данные из БД и сериализовать их, потом данные надо передать по сети, потом парсинг происходит минимум за O(N) (алгоритмов парсинга JSON не изучал, поэтому точно не скажу) Только в абсолютном значении разница между 10мкс и 100мкс мало заметна Ещё забавный момент -- накладные расходы на 1 запись получаются меньшими при большем числе записей И тут умный человек бы задал совсем другой вопрос -- уверен ли я, что пользователь прочитает все 10к записей. И тут ответ уже нет. Но я как бы ранее говорил, что умолчания настроены таким образом, чтобы пользователю в среднем влетало 100 записей. Только пользователь сам и сознательно может запросить больше -- я его не сдерживаю
	Ответить | Правка | Наверх | Cообщить модератору

	54. "В основной ветке Python появилась возможность сборки для раб..."	+2 +/–
	Сообщение от Аноним (-), 29-Ноя-21, 13:24
	> Всё новое - хорошо забытое старое. Ещё 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...
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	112. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:37
	А могли бы няшный лисп использовать.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (-), 30-Ноя-21, 12:53
	> А могли бы няшный лисп использовать. Да все что угодно было быстрее ЖС. 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 Но теперь "это было давно и поэтому почти совсем не правда!" и "Вы фсе врети! ЖС быстрый из-за грамотного дизайна, а не потому что гугл и мурзилла вложили сотню миллионов в разработку движка!"
	Ответить | Правка | Наверх | Cообщить модератору

	130. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от man man (?), 30-Ноя-21, 17:04
	> ЖС быстрый > из-за грамотного дизайна > грамотного > дизайна ну ок :/
	Ответить | Правка | Наверх | Cообщить модератору

	136. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (-), 30-Ноя-21, 20:47
	>> ЖС быстрый >> из-за грамотного дизайна >> грамотного >> дизайна > ну ок :/ man sarcasm Ну и да, обычно местные ЖСнкики таким макаром и аргументируют "техническое превосходство" ЖС - "глядите, есть V8, который супер-пупер быстр! Вот!". А то, что до V8 (и мурзиловского аналога) ЖС был самым жручим и тормозным скриптовым ЯП - так "это было давно и поэтому непрвда!"(с)
	Ответить | Правка | Наверх | Cообщить модератору

	148. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
	Сообщение от Аноним (61), 30-Ноя-21, 22:40
	> был был
	Ответить | Правка | Наверх | Cообщить модератору

	105. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (104), 29-Ноя-21, 23:20
	>> Джваваскипт вышел победителем И гугл тут не причём
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	38. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 29-Ноя-21, 11:38
	И тут приходит React Native и ... опять придется смузи ненавистникам плеваться и писать на JavaScript и React.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	55. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от pashev.me (?), 29-Ноя-21, 13:34
	Фронт уже можно писать на Rust, см. https://seed-rs.org/
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	57. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (61), 29-Ноя-21, 13:58
	> a![ >             C!["navbar-item", IF!(matches!(page, Page::TimeTracker(_)) => "is-active"),], >            ... >        ], А теперь сравни это с JSX и задайся вопросом, кому этот руст с сомнительным синтаксисом сдался на фронте. Куда бы он ни компилился -- будет оверхед. В васм? Рантайм-оверхед при boundary crossing. В тот же жс? Рантайм-оверхед для нескучной рустовской стд библиотеки. О, так он еще и на вдоме. Мужик чутка опоздал лет на 5-10, тут на фронте отказ от вдома в пользу гуя, собираемого на этапе компиляции, так что в рантайме вообще не приходится сравнивать реалдом с вдомом.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 29-Ноя-21, 14:20
	Это неправда. Никакого отказа от vdom и в помине нет. Это маргинальные фреймворки, с несколькими пользователями. Во-первых потому что React Native. Во-вторых новый который исправляет недостатки, выявленные в ходе эксплуатации. Убьёт эти фоеймворки "на этапе компиляции" в самом зародыше.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (61), 29-Ноя-21, 14:32
	> Никакого отказа от vdom и в помине нет Найди мне хотя бы одного ярого реакт-разраба (меня например), который бы сказал, что ему нравится вдом и сама идея держать че-то там параллельно реальному дому и делать постоянные сравнения, пусть и shallow (а местами и deep). Реакт дал способ быстро и наглядно оформлять компоненты, за что ему большое спасибо, но в свое время он не додумался реализовать это ничем иным, кроме как вдомом, убеждая всех вокруг, что без вдома тут никак. Сегодня (в 2к21) можно сохранить выразительность реакта безо всякого вдома. Линк для размышлений https://krausest.github.io/js-framework-benchmark/index.html
	Ответить | Правка | Наверх | Cообщить модератору

	74. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 29-Ноя-21, 14:56
	Я, например. Хоть я и пишу на React Native. И уже поэтому от ничего ни за что не откажусь. Ничего похожего для других фреймворков даже близко нет. И с новым React 18 с concurrent rendering, data fetching, suspense и в Web не будет альтернатив. А с Recoil, который умеет доставлять обновления состояния без перерендеринга (пусть с мемоизацией)  всего поддерева... Ну, кто что-то похожее умеет? Все эти идеи быстро разваливаются с medium-size кодом, который в production. И пока не будет 10 крупных компаний, использующих эти compile-time фреймворки в production и платящих (!!!) разработчикам этих компиляторов зарплату для допиливания - использовать их больше чем в Hello World глупо. Поэтому нет никакого перехода, и даже не намечается. Это просто интересные концепты, на поиграться.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (61), 29-Ноя-21, 15:22
	> 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.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
	Сообщение от Аноним (97), 29-Ноя-21, 20:50
	Будет такая же история, как с веб-фреймворками. Пока у тебя 1 запрос в секунду, всё ок. С браузером будет ок, пока 1 обработчик в форме, а если 10, то вкладка виснет и падает. Питон не годен ни для чего, требующего производительности, хоть какой-нибудь. Он не универсален. Он не прост. Код на питоне практически всегда уродлив и непонятен. Проблема в том, что если раньше питонячий кал можно было не устанавливать и не использовать, то теперь его будут незаметно подкладывать в браузер, где будет и не так просто понять, откуда же такие тормоза.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	103. "В основной ветке Python появилась возможность сборки для раб..."	–3 +/–
	Сообщение от kai3341 (ok), 29-Ноя-21, 23:11
	Толсто.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (145), 30-Ноя-21, 22:14
	если сделают транслятор пихтона в js то может быть а если нет - то на кой черт этот vdom если для запуска страницы нужно грузить целый интерпретатор
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

13. "В основной ветке Python появилась возможность сборки для раб..."	+2 +/–
Сообщение от annon (?), 29-Ноя-21, 09:43
Собрать Python под WebAssembly теперь проще чем под Windows?
Ответить | Правка | Наверх | Cообщить модератору

15. "В основной ветке Python появилась возможность сборки для раб..."	+4 +/–
Сообщение от Аноним (15), 29-Ноя-21, 09:49
Сразу надо было. Сколько лет упущено на упоротый JS, из которого всё пытались сделать нормальный ЯП.
Ответить | Правка | Наверх | Cообщить модератору

	18. "В основной ветке Python появилась возможность сборки для раб..."	–8 +/–
	Сообщение от Аноним (-), 29-Ноя-21, 09:53
	ЖабаСкрипт нормальный. Это ты рукожоп.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В основной ветке Python появилась возможность сборки для раб..."	–3 +/–
	Сообщение от Аноним (15), 29-Ноя-21, 10:01
	Не нервничай, малыш.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В основной ветке Python появилась возможность сборки для раб..."	+5 +/–
	Сообщение от Gemorroj (ok), 29-Ноя-21, 10:55
	так питон не лучше.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	52. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Урри (ok), 29-Ноя-21, 13:10
	Как бы плох питон не был, но пальму первенства встратости ЯП у джаваскрипта отобрать он не может.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноним (61), 29-Ноя-21, 14:15
	это как с ключами. Ищешь ищешь, а они все это время у тебя в руках были.
	Ответить | Правка | Наверх | Cообщить модератору

	64. Скрыто модератором	–2 +/–
	Сообщение от Аноним (59), 29-Ноя-21, 14:22
	Выучи его наконец, хватит ныть и страдать. Ещё один ниасилятор. Как старая бабка ворчишь (в разгар рабочего дня)
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	113. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:40
	Может, и делает это очень легко.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	143. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (145), 30-Ноя-21, 22:11
	уж лучше js - там хотябы все нативно и интерпретатор  пхитона не придется загружать в браузере
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

17. "В основной ветке Python появилась возможность сборки для раб..."	+6 +/–
Сообщение от Аноним (19), 29-Ноя-21, 09:52
Астанавитесь!
Ответить | Правка | Наверх | Cообщить модератору

20. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
Сообщение от Аноним (20), 29-Ноя-21, 09:56
Врятли взлетит как тот же brython
Ответить | Правка | Наверх | Cообщить модератору

	142. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (145), 30-Ноя-21, 22:09
	если добавят в vscode.dev - будет неплохо
	Ответить | Правка | Наверх | Cообщить модератору

24. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
Сообщение от Аноним (-), 29-Ноя-21, 10:07
отшитоним все вокруг, быстро дёшево, написал проверил - статейку в журнал и забыл
Ответить | Правка | Наверх | Cообщить модератору

29. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (30), 29-Ноя-21, 11:06
Bash в браузер!
Ответить | Правка | Наверх | Cообщить модератору

	37. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от kusb (?), 29-Ноя-21, 11:30
	x86 asm
	Ответить | Правка | Наверх | Cообщить модератору

35. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
Сообщение от Вебмакака (?), 29-Ноя-21, 11:17
одобряю
Ответить | Правка | Наверх | Cообщить модератору

41. Скрыто модератором	+/–
Сообщение от Аноним (41), 29-Ноя-21, 12:06
Астрологи предсказали, что год макаки будет каждым годом, начиная со следующего. Количество обезьяньего кода возрастёт в 10 раз. Как же они достали со своим вредоносным микроархитектурно-атакующим проприетарным очень хреново реверсящимся (по сравнению с JS) WASMом. У всех нормальных людей он в браузере запрещён. А теперь каждого вынудят включить это говно WASM. Это дискриминация и harrasment! Ну действительно, не на VanillaJS же писать.
Ответить | Правка | Наверх | Cообщить модератору

42. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (42), 29-Ноя-21, 12:07
>позволяющих собрать основную ветку CPython для работы внутри браузера Надеюсь в links2 добавят.
Ответить | Правка | Наверх | Cообщить модератору

	48. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (-), 29-Ноя-21, 12:48
	links2 прогрессивынй браузер?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (42), 29-Ноя-21, 13:06
	Да. Там очень хорошая экономия трафика, да и дизайн приложения классный, сам настраиваешь его себе. Последняя версия 2.25 выходила 3-ого октября. А самое главное то что он под свободной лицензией и не зависит от корпораций. Так что links2 это синоним прогрессивности.
	Ответить | Правка | Наверх | Cообщить модератору

44. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (44), 29-Ноя-21, 12:23
На скриптовых языках нельзя писать полноценные проекты. Это ведет только к тормозам и жеру памяти. Так что ждем, пока поддержку этого питона не добавят прямо в процы.
Ответить | Правка | Наверх | Cообщить модератору

	63. "В основной ветке Python появилась возможность сборки для раб..."	–5 +/–
	Сообщение от Аноним (61), 29-Ноя-21, 14:22
	по крайней мере Java и JavaScript JIT-компилятся, а пхтон типа бейсика, выполняется строка за строкой. Ну максимум AST готовое в *.pyc-запишут и заименуют гордо "СКОМПИЛЕНО!!111"
	Ответить | Правка | Наверх | Cообщить модератору

	68. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
	Сообщение от Аноним (72), 29-Ноя-21, 14:29
	Тот нелепый случай когда кудахтер не разобрался даже с бейсиком, а агонирует на что-то сложнее
	Ответить | Правка | Наверх | Cообщить модератору

	147. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (-), 30-Ноя-21, 22:24
	> по крайней мере 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 files https://doc.pypy.org/en/latest/release-1.0.0.html > PyPy 1.0: JIT compilers for free and more .
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	66. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (59), 29-Ноя-21, 14:27
	Тебя в каком году заморозили? В 2000х? JavaScript - это спецификация (синтаксис и семантика). А как он исполняется - это детали имплементации. V8 - это JIT движок, как и в остальных браузерах, Hermes в бинарь компилит. Интерпретируемый JavaScript можно только в embedded найти. Там он в 30х раз медленее, зато очень энергоэффективен.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	95. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (95), 29-Ноя-21, 18:24
	> пока поддержку этого питона не добавят прямо в процы. Уже проходили с жабой в ARM.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	114. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:44
	А вот жава была божественна как встраиваемый язык. Её для этого и разрабатывали как бы, чтобы на кофеварках интернета вещей работать. Но оракл решил что у него более "интересное" применение для неё, а жёсткая лицензионная политика забила гвоздь в гроб ембеда на жаве.
	Ответить | Правка | Наверх | Cообщить модератору

46. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Константавр (ok), 29-Ноя-21, 12:25
Ага, уже вижу как зловреды изо всех сайтов лезут на полноценном питоне... Как отрубить лишние концы таким штукам в браузере?
Ответить | Правка | Наверх | Cообщить модератору

	53. "В основной ветке Python появилась возможность сборки для раб..."	+3 +/–
	Сообщение от Аноним (53), 29-Ноя-21, 13:15
	Вставьте им лишний пробел в отступы)
	Ответить | Правка | Наверх | Cообщить модератору

47. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
Сообщение от Аноним (-), 29-Ноя-21, 12:47
Что, теперь браузер станет средой разработки языка программирования Питон? Я правильно понял?
Ответить | Правка | Наверх | Cообщить модератору

	51. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
	Сообщение от Аноним (1), 29-Ноя-21, 13:09
	и да и нет
	Ответить | Правка | Наверх | Cообщить модератору

	82. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (30), 29-Ноя-21, 16:23
	Средой разрабоки? Так уже есть Jupyter. И даже через браузер отображает. Ну разве что и Jupyter-сервер в браузер затолкать.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	132. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Аноним (132), 30-Ноя-21, 19:06
	Можно будет писать скрипты на Python для криптомайнинга в браузерах. Но на Расте, наверное, все же эффективней будет.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

67. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (72), 29-Ноя-21, 14:28
Когда они уже чуть больше уделят внимания мобилкам и нормальному гую из коробки? Вот эти все веб-костылики ни о чём
Ответить | Правка | Наверх | Cообщить модератору

	91. "В основной ветке Python появилась возможность сборки для раб..."	+/–
	Сообщение от Не тормози плужок (?), 29-Ноя-21, 17:22
	Кто они, василиска? Это тебе нужно, ты и делай.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
	Сообщение от Аноньимъ (ok), 30-Ноя-21, 06:45
	Мне то же нужно. Где проголосовать за эту василиску?
	Ответить | Правка | Наверх | Cообщить модератору

118. "В основной ветке Python появилась возможность сборки для раб..."	–2 +/–
Сообщение от Простоник (ok), 30-Ноя-21, 08:09
Более тесная интеграция с сервисами github это отлично. Про WASI ... А эта самая WASI  находится в стадии активной рекламы. Таких рекламных компаний было уже много. Или таки кто-то этим уже пользуется в практических целях? И жаль, конечно, что python не очень хорошо поддерживает разработку мобильных приложений. Эта ниша почти потеряна.
Ответить | Правка | Наверх | Cообщить модератору

119. "В основной ветке Python появилась возможность сборки для раб..."	+1 +/–
Сообщение от Tarmik (?), 30-Ноя-21, 08:27
Как и большинство webassembly трансляций - это побудет новостью некоторое время и потом об этом все забудут. (Много игр забыто на этом поприще) Из-за того что webassembly тяжелый, еше питон модули надо туда компилировать. Думаю студенты и останутся его основными пользователями. Да и вроде pypy что быстрее cpython раз в 7 уже портирован под webassembly.
Ответить | Правка | Наверх | Cообщить модератору

120. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Tarmik (?), 30-Ноя-21, 08:31
Сюда допишите как альтернатива 7. Pros / cons не забудьте дописать. Ну и можно потом подождать еще два годика... https://yasoob.me/2019/05/22/running-python-in-the-browser/
Ответить | Правка | Наверх | Cообщить модератору

141. "В основной ветке Python появилась возможность сборки для раб..."	+/–
Сообщение от Аноним (145), 30-Ноя-21, 22:06
ранобрадовались питономакаки это не про фронтенд а про то чтобы без установки пихтона потестить что нибуть на питоне сайты и приложухи на это не сделать - иначе если тащить целый интерпретатор - в дурку сразу заберут
Ответить | Правка | Наверх | Cообщить модератору

149. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
Сообщение от Аноним (149), 01-Дек-21, 02:18
когда же можно будет поиграть в Call of Duty в браузере?
Ответить | Правка | Наверх | Cообщить модератору

152. "В основной ветке Python появилась возможность сборки для раб..."	–1 +/–
Сообщение от Аноним (152), 01-Дек-21, 08:05
PyQt или хотябы Tkinter там работает? Если да, я бы за это даже платил.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема