Французский математик Фабрис Беллар (Fabrice Bellard), основавший в своё время проекты QEMU, FFmpeg, BPG, QuickJS, TinyGL и TinyCC, опубликовал новый JavaScript-движок для встраиваемых систем - Micro QuickJS, способный компилировать и выполнять JavaScript-программы, потребляя всего 10 КБ ОЗУ. Вместе с Си-библиотекой движок занимает примерно 100 КБ постоянной памяти. Возможна компиляция JavaScript в байткод и отдельный запуск байткода. Код проекта написан на языке Си и распространяется под лицензией MIT...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64483
Самое весёлое, это когда JSеры пробуют движки типа QuickJS после того, как всю жизнь сидели на V8 и т.д., и ох*евают от того, насколько это неоптимизированный медленный язык без миллиардов инвестиций V8.
У него есть продолжение https://github.com/quickjs-ng/quickjs и какой-то jit https://github.com/bnoordhuis/quickjitДля задач типа разборка жс в yt-dlp самое то. v8 ради такой задачи тащить это слишком.
>Для задач типа разборка жс в yt-dlp самое тону конечно если ты готов полчаса ждать пока код прожуёт
>>Для задач типа разборка жс в yt-dlp самое то
> ну конечно если ты готов полчаса ждать пока код прожуётВ yt-dlp была интерпретация js на питоне раньше. В новой версии из-за закручивания гаек Гуглом ее уже не хватает.
Это была не интерпретация. Там просто обфусцированный код. Уже пробовали сабж вместо в8 и как раз полчаса и потребовалось.
> Это была не интерпретация.Вот тебе https://github.com/yt-dlp/yt-dlp/blob/5ff7a43623e3a92270f66a...
> Там просто обфусцированный код.
js код почти везде пожат.
> Уже пробовали сабж вместо в8 и как раз полчаса и потребовалось.
Пруф? Была новость, что они bun будут использовать в новой версии.
а зачем, если так подумать, на МК разбирать жс в ют-длп ?
который, скорее всего, и не разберётся, т.к может обнаружиться много конструкций, неподдерживаемых урезанным двиглом
"разборка жс в yt-dlp" для тытруба уже вот совсем почти требует ноду/аналог, не то что голый v8гугловэботаобфускациятивоизация, Сэр
>Для задач типа разборка жс в yt-dlp самое то.Так ютуб пишут под v8. Даже не под что там у лисы.
> Самое весёлое, это когда JSеры пробуют движки типа QuickJSJSеры об этих QuickJS и прочем даже и не слышали, лол. Серьезный JS пишется под реальные браузеры и Ноду, а не вот эти вот поделки.
серьёзный и JS это не совместимые слова
> серьёзный и JS это не совместимые словаДа, серьезные программисты сайты Си кодят.
Cерьезные программисты кодят под аппстор и плеймаркет
Серьезные программы типа тапай хомяка?
Пожалуйста продолжайте, у меня попкорн ещё не кончился...
Разве программисты сами кодят? Я всегда думал, что программистам кто-то платит, а они уже за эти деньги кодят.Кто ж виноват, что наниматели ...анские задачи ставят.
А что насчет создателей всякого порнхабов, там что программиты какие-то совсем нетакие?
В том числе. А серьезные музыканты поют про цвет настроения синий. Так работает индустрия. Но понимание этого приходит гораздо позже полового созревания, так что до тебя пока не дойдет.
так в индустрии серьёзные не музыканты, а их хозяева. Многие из нынешних музыкантов больше похожи на тех тряпичных кукол, которые надевают на руку. Прямо заметно порой, как им навязывают конкретный бредовый образ. Не удивлюсь, если от многих из них пахнет как от старой боксёрской перчатки )В остальном, веб для конечного пользователя может порой оказаться сильно лучше того же апстора или плеймаркета. Хотя бы потому, что не надо на каждый чих ставить очередное говноприложение, которое ещё и регулярно требует обновлений, иначе - отказывается работать
>в индустрии серьёзные не музыканты, а их хозяеване понимаю, к чему это сказано. В любой сфере те, кто генерирует деньги дают задачи тем, кто исполняет. Даже в копании ям. Это естественный ход вещей.
Одно дело "напиши мне неплохое музлоу и спой это" и совсем другое - "ты будешь петь то, что тебе написано кем-то другим. Но для соответствия образу, ты должен на своей роже набить энное тату, а то и несколько, выйти редкостным бомжом с энными купленными `звёздами`, изобразить себя редкостным негодяем, поддержать ЛГБТ ибо сие есть спонсоры международные и пролоббировать нариков и приём психоактивных веществ, а так же - `жижу` для парилки с никотином от одного из наших осн. спонсоров, хотя вообще хз кто как и из чего это гамно делает"Так что, разница есть. Особенно с учётом того, что, из-за дыр в законодательстве, конечные певцы/актёры либо поют/изображают что им говорят( в т.ч вне сцены ), либо - тупо идут на ***. Там вплоть до домогательств и прочего. Не нравится - убирайся без права исполнения песен, которые только ты многие годы и исполнял.
> А серьезные музыкантыИграют в консерваториях. Но похоже тебе неизвестно, что это такое, ведь в твоем селе нет ни одной.
> Так работает индустрия
Премию... срочно...
> Но понимание этого приходит гораздо позже полового созревания
Я так понимаю, оно у тебя только началось в твои 40 лет, раз грустные песенки слушаешь про feel blue.
Дальше будет больше открытий.
>Играют в консерваторияхКонсерватория - это школа. Похоже ты так спешил меня опровергнуть, что немного не донес до унитаза.
>Премию... срочно...Кому?
>грустные песенки слушаешь про feel blueЯ такое не слушаю, я просто говорю, что индустрия - это массовое производство и разделение труда. Хочешь с этим спорить - осиль для начала учебник истории, а то непонятно, как с твоим белым шумом спорить.
(Я не про "цвет настроенья синий", а про подразумеваемый паттерн) Отчасти это заставляет задавать вопросы про серьёзность её желательность и осмысленность и что не так с нашим устройством мира. Но ...мне нравятся вещи сделанные для людей, в том числе попса и проприетарные программы, по моему в них может быть больше души, что паразительно. Может быть мы бы потеряли бы что-то важное, если бы мир работал иначе.
Но мир работает так, как он работает, а история не имеет сослагательного наклонения. Я не вижу в целом смысла спорить с ветром или дискутировать с Плутоном, что он не так движется по орбите.P.S. спасибо за контентный комментарий, серьезно.
Серьезные программы - это казуальные миниигры для мобилок, если верить отчётам о доходности.
С отрывом.
Кстати, "тапай хомяка" был написан на жс с реактом. Никто уже не пишет нативные мобильные приложения
Ну не знаю как на СИ, но на СРР точно можно.
Можно, но не нужно.
Кстати да, как то посмотрел сериал Пайрет Бэй, про всеми известной бухту! Там даже была такая шутка, только про php: Мол, почему программист пишет на php?,- потому что он не знает си,- хи-хи-хи;)
никаких "сайтов" нет.
есть веб-приложения, и если ты хочешь, чтобы оно работало быстро, стабильно, и успешно собиралось чз 3 года, там на бэке джава например.
но кнопочками попереливаться и js хватит
В наше время на Питоне пишут и фронт и бек, уже ничему не удивляешься.
Интересно, не знал раньше об этом. Не могли бы вы посоветовать литературы, чтобы лучше разобраться в причинах и понять, почему это так?
Аха. "серьёзный js" - ну ты отжог.
Аналогично с java, когда и без того кривой escape analysis вдруг пропадёт
Так а зачем!?Тот же LUA отличный язык для бизнесслогики.
И применение этого JS тоже примерно для того же.
А если надо данные жевать - пилим биндинг на С и пихаем их в него.В общем со времён Visual Basic ничего и не поменялось.
> Тот же LUA отличный языкwut? Отвратительный ЯП. Автор, наверно, никогда не писал никакую "бизнес-логику" на lua.
Пока да.
Но у меня крутится prosody, он почти весь на LUA и как то вполе живёт.И я писал на Visual Basic, поэтому прекрасно понимаю что нужно разделять управления потоками данных и их обработку, если это не нарушать то трудно уперется в скорость ЯП.
Сразу видно специалиста. Медленным может быть не язык, а интерпретатор. Это первое. Второе, даже Micro QuickJS очень быстро работает без привязки к браузеру.
Без интерпретатора интерпретируемый язык ничто, много вы знаете носителей латыни, ну вот то то же.
Поэтому в данном контексте, я считаю, можно ставить знак =...
достаточно попытаться делать на js операции пообъёмнее в старом IE8 и в каком-нибудь Хруме парулетней свежести. Разница от практически неюзабельно до робит шустро (один и тот же сайт на древних ангуляре и jquery).
Подмножество-убожество. Добавлять встраиваемый язык только для парсинга какого-нить конфига - очень паршивая концепция.
Это зависит от того, с какой нагрузкой и скоростью хочется "парсить".
Часто нужен просто какой то простой скриптовый язык в дополнение к основному ПО.
И требуется например вовсе не скорость, а стабильность и отсутствие зависимостей.
Что протестировал, то только именно то и работает.
А столь компактные варианты интересны во встраиваемой технике.
Тогда и lua подойдёт. И nushell.
Да, lua и использую. Хотя, мне больше JS по душе.
когдато давно прикрутил луа к своему проекту, задача - получить из конфига строку "2 + 3", посчитать и вернуть int, с потенциальным расширением впоследствии прочитать циферку из http... по итогу оказалось проще заменить луа на js, чем пердолится с этой луой и хттр к ней прикручивать
Skill issue, Lua встраивается элементарно.
Там ниасилено было ххп в луа.
lua для конченого юзера слегка это, детеррент.
А вот на жс уже даже домохозяйки три строчки умеют.
а как только надо больше трёх строчек у "фул-стук-node-angular-developer" начинается ступор
Вот насчёт стабильности и зависимостей с JS не очень то понятно.
В том плане что есть LUA, она одна и ей много лет, она маленькая и легко встраивается.
И есть вот эти разные JS движки.Насколько я понимаю индустрия тех же игроделов пологоловно выбрала LUA.
Гнать надо игроделов что не слезают с иглы Lua. Проблема с производительностью игр от крупных студии в том числе вызвана костылями, созданными чтобы не убирать Lua из процесса разработки.
Интересно, не знал об этом. Буду иметь в виду при разработке своих решений.
> Добавлять встраиваемый язык только для парсинга какого-нить конфигаВ смысле "только"? По-твоему, других задач у скриптовых языков, кроме парсинга конфига, не существует?
И зачем вообще тебе целый встраиваемый язык для парсинга конфига, лол?
Конфиги бывают разные. Например, конфиги емакса.
Такой конфиг лисп-машина самого эмакса без раздумий суёт в eval(...)
Потому что в такой конфиг можно засунуть зависимые параметры, или какую то логику типа чтения файлов.
Так же можно описывать иерархию объектов и сами объекты.Конечно можно объекты и в ini описать, но будет это не очень - как regedit делает.
А кроме останется xml, json - они тоже не оч.
> Хранить в конфигах что-то сложнее key-value, причем value - примитивного типа
> Не хранить сложные объекты и описания иерархий в сериализованном видеБатенька, а вы знаете толк в извращениях
Есть же yacc/flex для парсинга. Почему их забросили, интересно.
Что значит забросили :-)? Используют в полный рост. Вместо flex хорош re2c. В так, что ещё использовать?
Отличная новость! Его можно собрать в wasm модуль, чтоб выполнять js из wasm рантайма вне браузера
Он бесспорно молодец. Но файл quickjs.c в 55 тыс строк как-то не очень. Можно же было разбить.
Вы там вручную покопаться собираетесь?
А если с ИИ править и изучать, то в одном файле нормально.
Если нужна встраивоемость и сохранение ресурсов то нужна и модульность. Может мне вовсе ненужна поддержка строковых данных в utf или ещё какая-то модная фигня если я только мигаю светодиодами.
Хм, а на что ты заменишь utf, на UCS‑2?
А зачем их использовать если я ничего никуда не пишу и текст не вывожу? Байткоду кодировка ненужна.
> А зачем их использовать если я ничего никуда не пишу и текст
> не вывожу? Байткоду кодировка ненужна.Ну, значит, тебе и жс ник чему.
Хмм..
Да, именно для встраиваемых систем интересна генерация экземпляра "только под конкретные нужды".
Для встраиваемых систем есть вохможность условной компиляции - хоть из одного файла, хоть из трёх, хоть из 33х
> есть вохможность условной компиляцииВ смысле есть?
Наверное хотите сказать уместна, и полезна.
Да полезна. Но есть ли она в исходниках, или нет, это другой вопрос.И вот, как добавить условную компиляцию, что то урезав для своих задач, или добавить новое.. Так, с этого я и начал. Иначе зачем вообще копаться в исходниках, а не использовать что дали.
а вот и модный js-developer подошёл.
больше 3 строк кода, зовём на помощь ию!
>> js-developerЭто у меня сильно не основной язык, а предпочитаемый из скриптовых.
> больше 3 строк кода, зовём на помощь ию!
Это смотря что делать с ИИ.
Если весь код писать, то результат и качество Вы и сами хорошо представляете.
Но, если разбираться и "перелопачивать", то это инструмент для ускорения.Например, что с ИИ программированием делал в последнее время.
- Переписывал и дописывал проект на ESP32, а компоненты из разных источников, а во всякой версии ESP-IDF ломают API, и бывает сильно, и вручную это править, да по кривой документации, не поспевающий за изменениями, и устаревшим примерам, так себе развлечение, причем с неизвестными сроками.
- ПО для тестов. Перепроверять надо, но сильно быстрее чем руками.
- Из не программирования - редактирование изображений, для хобби, и продолжаю управление умным домом, техникой, браузером..К подсветке синтаксиса привыкли же, и к автодополнению. А когда то даже мышь, и графический интерфейс в штыки воспринимали.
> 55 тыс строкДля профессионала это не проблема.
>> 55 тыс строк
> Для профессионала это не проблема."Не проблема" это только для гордых писателей в одно лицо, типа автора сабжа. А вот именно в профессиональной среде тебе бы коллеги сразу по шапке дали за такое.
Профессионально попроси нейросеть разбить на файлы.
Что вы хорошего написали в этой среде? По шапке они друг другу дают))
Такие "портянки" раньше точно делать было не хорошо. С ними тупо тормозили редакторы, и тем более с фоновой компиляцией.Сейчас такие "портянки" не уже не является проблемой.
Я не говорю, что так хорошо, или удобно, при разборе с ИИ инструментом, а именно то, это сейчас это не уже важно, ибо в простых редакторах профессионалы с этим копаться все равно не станут.Ps: скачал, и уже балуюсь.
Дурову дай по шапке, он наверно не шарит в этом вашем айти) 75к строк:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
Так Телеграм не микросервис, а громадная программа
Это ты не шаришь раз приводишь такой пример (либо сознательно передёргиваешь).
В этом файле тупейшая портянка сериализации (возможно, что вообще автоматически сгенерированная).
Максимально линейный код с минимумом бизнес-логики.А вот за 75к строк б.-л. дадут по шапке практически везде.
> ты не шаришьЯ всего-то поднял несколько k$ на конкурсах телеги, поковыряв этот код. Проблем с длиной файлов у меня лично нет, всё читаемо.
> тупейшая портянка
У среднестатистического крудошлёпа конечно портянки не тупейшие и не линейные, да? Куда там какому-то телеграму на миллиард+ пользователей до него? Ладно, ChatActivity.java оттуда же - 44k строк.
Слушай, а ТЕСТЫ у этих файлов есть? А СОЛИД? А БЕСТ ПРАКТИСЕС?
>А вот именно в профессиональной среде тебе бы коллеги сразу по шапке дали за такое.Мне в профессиональной среде профессиналы давали по шапке, требуя коверкать слова на английском на кодревью. Эти же профессионалы требовали читаемый код и писали функции на 4 экрана. Они же случаи обработки ошибок совали в конец длинного if..elif, осавляя базовый работоспособный случай сверху.
Кто первый надел халат, тот и профессионал.
И добавлю: кто последний пошёл чеклист правил исполнять, тот всю жизнь будет работать над чеклистом правил, а не над кодом.
согласный. про к такому и близко не подойдёт.
mquickjs.c на 18000+ строк.А вообще, у того-же sqlite, рекомендуемый способ включения "Amalgamation", при котором используется специально собранный файл sqlite.c, уже наверное, на 200000+ строк, и ничего, люди пользуются.
> уже наверное, на 200000+ строк, и ничего, люди пользуются.Это сделано для упрощения сборки, к тому же это автоматический процесс. Тут же файл написан вручную и править если что его придется.
Он мог и на секции разбить. Которые ^L.
Для кода на C это нормально и обычная практика.
> Для кода на C это нормально и обычная практика.Вообще в гайдлайнах проектов обычно прописан условный максимальный размер файла и 55 тыс это оч много.
Эпичный чел
Круто такто
Если у тебя такие ограничение по железу зачем тебе джаваскрипт, Фабрис не сказал? А так ради искусства красиво.
Путаем имплементацию и спецификацию?
И чем же JS хуже? Для скриптового языка вполне. Его несуразный дизайн (всякие цепочки прототипов)...но и конкурент Lua не лучше. Python? В общем список и закончился.
Вопрос, наверное, был о целесообразности использования какой-либо скриптоты на железе с 10 килобайт ОЗУ.> Python?
Ну, MicroPython вполне популярен.
Так если открыть сайт и посмотреть на поддерживаемые архитектуры, то эту информацию можно найти. Вот смотри, https://bellard.org/quickjs/ - QuickJS:>> Cosmopolitan binaries running on Linux, Mac, Windows, FreeBSD, OpenBSD, NetBSD for both the ARM64 and x86_64 architectures
Но речь идёт о Micro QuickJS, который написал тот же bellard: https://github.com/bellard/mquickjs
>> It compiles and runs Javascript programs with as low as 10 kB of RAM. The whole engine requires about 100 kB of ROM (ARM Thumb-2 code) including the C library. The speed is comparable to QuickJS.
Т.е. это какая-то урезанная версия которая запустится на всём тоже самом, только с меньшим количеством памяти. А заначит и на каком-нибудь OpenWRT также можете поднять свой сайт или сделать свой софт с JS скриптами. Элементарно легковесный сервер для микроноды под OpenWRT вполне может стать популярным. Всё что нужно - скомпилировать
>> make
>> make install
Современный OpenWRT это минимум 64мб оперативы а то и больше, там и полноценный веб сервер с пхп запросто будет работать.
Так я выше об этом и написал, но мне ответил какой-то Крысюк:>> Ну запихни для начала свою Ноду в микроконтроллер, а мы на тебя посмотрим.
Понимаете? Люди хотят пихать это в микроконтроллер.
На ARM и RISC-V запросто и ноду можно поставить, но вот я захожу на https://repka-pi.ru/products, смотрю изделия репки пи и понимаю что на рынке России стремятся к какой-то универсальности. А вот была бы Repka JS Edition с SDK на JavaScript и софтом позволяющим этот скрипт залить через Usb или по сети Ethernet, а ещё какое-нибудь реле на 230В переменного тока, то и желающих наверняка было бы много. У американцев такого нет вроде, до этого самому додуматься нужно. Причем сделать такое весьма просто, а профит может быть неплохим.
Если у вас чешутся руки в IoT то берите ESP32/ESP8266, накатывайте туда ESPHome/NodeMCU/Tasmota и радуйтесь.И насчёт реле для 220 - будьте осторожны!
Китайцы делают сильно разные по качеству дизайна платы, у некоторых низковольтные линии идут прямо совсем рядом с линиями реле где пускают 220 - это всё легко приводит к пробою а дальше как повезёт.
У правильных модулей коммутируемые контакты реле отделены пропилами в текстолите и унесены максимально далеко от всех остальных дорожек на плате.
>Если у тебя такие ограничение по железу зачем тебе джаваскрипт, Фабрис не сказал?Чтобы под дешёвое железо нанимать дешёвых программистов. Фортеры вымирают, а новых не учат. Вот и будут под особо жирные стмки писать на жс.
Неплохо на самом деле. Один целый абзац в статье конечно можно заменить на короткое предложение что JS работает только в "strict mode" и поддерживает стандарт ES2015. Все в курсе что это. Разработчикам встраиваемых систем стоит задуматься что на Python и JavaScript наибольшее количество разработчиков нынче в мире. Может оно и начнется с какого-нибудь табло для банка показывающего курс валют (на С оно тоже много строк конечно не занимает, я понимаю), но разработчиков встраиваемых систем станет больше. А на носу эволюция роботов.
Сомнительно.
Дети в роблоксе, роблокс на LUA биндингах. А JS это что то дедовское :)
> Все в курсе что это.Кто все-то? Ваш джс пузырик не настолько большой (чего не скажешь про эго, конечно)
>> Кто все-то? Ваш джс пузырик не настолько большой (чего не скажешь про эго, конечно)Зачем вы мне все это пишете? Я этого не понимаю. Вы не понимаете ЯП? Ну так не пользуйтесь, вас никто не заставляет, но вот какая-то злоба вашего комментария чувствуется. Прям ненависть к JS, исполртившая всю жизнь. Сам язык простой, только там web api ещё есть полно если о браузере или node api. И вот этот мужик в своих поделиях такой думает - а зачем нам все это? Выкинем и будем пользоваться только стандартами es. В С в общем-то тоже вроде только 40 ключевых слов, не так-ли? У него и tcc есть, только им почти никто не пользуется. Его задумки интересны, только бессмысленны. Как по мне самое полезное он сделал солянку ffmpeg, больше у него ничего полезного нет.
Будет ли оно ещё быстрее, если вместо js будет строгий ts (чтобы только типизированное всё было) и выбросить eval? Был такой (и где-то ещё используется) Pascal Script.
Оно не для быстроты сделано.
Если вам жевать данные - то пишите С биндинги и дёргайте их.
Тут как раз примеры как делать: https://github.com/bellard/quickjs/tree/master/examples
Примерно по такому принципу и работают альтернативные реализации Питона вроде Micropython (отсутствует половина стандартной библиотеки) & Codon (статичный int и ascii строки против юникодовских).
Так что да, вся быстрота оказывается лишь в отсутствии удобств, а какие-то принципиально существенные проблемы производительности эти реализации обычно не решают.
> Примерно по такому принципу и работают альтернативные реализации Питона вроде Micropython
> (отсутствует половина стандартной библиотеки)Остуствует, потому что это будет уже не micro.
> Codon (статичный int и ascii строки против юникодовских).
У Codon AOT оптимизации. Типы обязательны, классы финальны и многая динамика убрана.
> строгий ts (чтобы только типизированное всё было)ts по определению имеет gradual type system. Она unsound по умолчанию.
Фабрис гений
Ну из всех его поделок взлетели только куема и ффмпег.
И то - его заслуга только первые версии.
Дальше там подхватили развитие и обогащение <s>гогнокодом</s> фичами совсем другие люди ("на зарплате у корпораций").Хотя конечно даже просто основать джва таких проекта это реально достижение.
Он не гений. Просто талантливый математик и продуктивный программист.
просто ))) Если он просто, кто тогда ты? Грязные разводы на полу минус 101 этажа подводного города в Марианской впадине.
Зачем нужен js где-то кроме браузера при существовании java/c# ?
java слишком слишком жирная, c# - это вендорлок винды, и эти язычки в бэкенде подходят только совсем жииирнючих монолитов.
>c# - это вендорлок виндыС разморозкой:
SDK 10.0.101
Downloads for .NET 10.0 SDK (v10.0.101)
OS Installers Binaries
Linux Package manager instructions Arm32 | Arm32 Alpine | Arm64 | Arm64 Alpine | x64 | x64 Alpine>эти язычки в бэкенде подходят только совсем жииирнючих монолитов.
Ой-вей, да ты в своей криокамере проспал и моду на сервисную архитектуру, поди. JS в бэкэнде - вот это натягивание совы на глобус.
И зачем оно надо за пределами венды?
Полно более интересных конкурентов.
> И зачем оно надо за пределами венды?
> Полно более интересных конкурентов.Нет более интересных конкурентов. C# это сейчас золотая середина, которая и в AOT умеет, и безопасна
Повторю: за пределами венды C# практически никто не юзает.На самой венде это больше похоже на то, что синтаксис Visual Basic заменили на С, в том смысле что и быстродействие и доступ к WinAPI уже совсем не те что в обычном С.
>Ой-вей, да ты в своей криокамере проспал и моду на сервисную архитектуру, поди. JS в бэкэнде - вот это натягивание совы на глобус.А в чём преимущество многопоточной джавы перед асинхронной нодой в задачах бэкенда, где всё упирается в io? Получить запрос по api, сделать вызов в БД или очередь, и вернуть данные. Нода точно производительнее жирнючего спринга, особенно если её развернуть в кластере.
> c# - это вендорлок виндыуже 10 лет c# это вторая по популярности технолония на бекенде, в основном в докере под линуксом.
Это выдуманная статистика в мире плюшевых пони.
> уже 10 лет c# это вторая по популярности технолония на бекенде, в
> основном в докере под линуксом.чо вдруг "в основном"? c#, в отличие от модных-молодежных, уникальной конфигурации FROM:cpa4 не требует, большинство решений способны работать просто в линуксе, без ненужных прослоек.
Вот первая по популярности - той да, без докера никуды, потому что единственноверная версия ноды работает только в никаком дистрибутиве.
>> уже 10 лет c# это вторая по популярности технолония на бекенде, в
>> основном в докере под линуксом.
> чо вдруг "в основном"?А кто-то сейчас на голом железе приложения гоняет?
> большинство решений способны работать просто в линуксе, без ненужных прослоек.
Именно так работает дотнет, без ненужных прослоек. Просто в линуксе и всё. Поэтому и любим
>java слишком слишком жирнаяМожно подумать, что node - образец стройности.
Речь не про стройность, а про жииирноту!
Даже без всяких исследований, бэнчмарков и прочего.
Создай обычный crud на ноде для одной энтити и на спринге.
Нода с призмой в этом приложении на старте потребляет несколько десятков мегабайт ОЗУ, спринг с его хибернайтом и jvm - несколько сотен.
Вот и разница.
Джава - это отличный вариант только для богатого энтерпрайза, где на железо можно выкидывать деньги без оглядки.
щас аноним узнает про Java Card, да?
Там совсем другая vm под капотом, обрезок по сути. Речь в теме про нормальную джаву с JVM, которая используется везде в бэкендах.
Например для бинарной программы добавить возможность выполнять внешние сценарии. Нельзя реализовать в программе хотелки пользователей на все случаи жизни, а так они сами допишут что им не хватает.
Можно писать shell-скрипты на JS вместо python запуская quickjs в режиме интерпретатора. Можно использовать как встраиваемый язык, хотя тут есть другие более подходящие кандидатуры, например duktype.
Просто потому что JS более известный, чем другие языки. Не надо путать язык и API/DOM функции в браузере. Конечно у языка есть и свои недостатки, но это далеко от того монстра во что превратили современный веб.
mJS сто лет как существует: https://github.com/cesanta/mjs
Там в issues его тролли-исследователи растерзали уже, учитывая что с 2018 года ничего не коммитят и даже issues не закрывают то можно считать его заброшеным.
Не касаясь размера и быстродействия - код на С очень плохой.
Примеры и описания будут?
По мне код вполне норм, пара мест могла быть лучше.
Функции типа (по памяти, но смысл такой же):
bool is_num(type t) { return t == TYPE_NUM; }То как сделаны структуры, попытка зачем-то имитировать ооп приемчики, когда не надо и тп
Слабовато с примерами.
Вот удивительно. Ещё в восьмидесятые появились языки вроде Standard ML, достаточно выразительные для написания кода, и в то же время достаточно хорошо подходящие для оптимизации. Но нет, берётся недоязык js, который невозможно толком оптимизировать, и засовывается в микроконтроллеры. При этом, что удивительно, берётся не сам js, а некий суррогат, который ещё и не позволит перенести произвольный код.
Так вот почему и в qemu, и в ffmpeg в опциях командной строки голову сломишь — их, оказывается, делал один и тот же человек, и сделал своеобразно))
Из самых быстрых JS-движков, которые я встречал, был только движок, встроенный в заброшенный веб-браузер Opera на движке Presto. Я специально проводил алгоритмические бенчмарки, и Chrome с V8 отставал в сотни и тысячи раз, а Firefox - в миллионы раз на долгой дистанции.
> Из самых быстрых JS-движков, которые я встречал, был только движок, встроенный в
> заброшенный веб-браузер Opera на движке Presto. Я специально проводил алгоритмические
> бенчмарки, и Chrome с V8 отставал в сотни и тысячи раз,
> а Firefox - в миллионы раз на долгой дистанции.Когда тесты то проводились? Давно поди. С тех пор много воды утекло. К тому же нет тестов = нет пруфов. Да и собственно presto (проприетарного замечу) тоже больше нет.
> Когда тесты то проводились? Давно поди. С тех пор много воды утекло.Давно, как раз в последние годы жизни Opera на Presto. Ну и повторил, когда тестировал JS проект году в 2020 - аналогичные результаты.
> К тому же нет тестов = нет пруфов.
А что мне с этих пруфов?
> Да и собственно presto (проприетарного замечу) тоже больше нет.
Что значит нет? "Всё, что попало в интернет, остаётся там навсегда". Скачать до сих пор можно, по крайней мере для винды.
>> К тому же нет тестов = нет пруфов.
> А что мне с этих пруфов?Вы делаете заявление без доказательств.
>> Да и собственно presto (проприетарного замечу) тоже больше нет.
> Что значит нет? "Всё, что попало в интернет, остаётся там навсегда". Скачать
> до сих пор можно, по крайней мере для винды.В нем не откроется большинство сайтов. Исходный код не посмотреть.
> Вы делаете заявление без доказательств.Именно. А нельзя? В жизни так бывает. Вы лучше выберите, что для вас лучше: когда люди вокруг без доказательств не сообщают вам ничего, или когда с доказательствами, но таких сообщений будет очень мало.
> В нем не откроется большинство сайтов.
Доказательства предоставите, что большинство? То-то же.
А я заявляю, что нет - большинство откроются.> Исходный код не посмотреть.
Вообще-то, была новость достаточно давно, что они выложили исходный код на GitHub. Вам тоже это доказывать нужно? Или вы все-таки умеете гуглить? Если сам код не найдётся с первого раз есть зеркала и форки.
"Всё, что попало в интернет, остаётся там навсегда". (с)
>> Вы делаете заявление без доказательств.
> Именно. А нельзя? В жизни так бывает. Вы лучше выберите, что для
> вас лучше: когда люди вокруг без доказательств не сообщают вам ничего,
> или когда с доказательствами, но таких сообщений будет очень мало.Решил circus тут устроить? Да, то твоих глупых заявлений не горячо не холодно. Это просто шум.
>> В нем не откроется большинство сайтов.
> Доказательства предоставите, что большинство? То-то же.
> А я заявляю, что нет - большинство откроются.В своей палате можешь завлять.
>> Исходный код не посмотреть.
> Вообще-то, была новость достаточно давно, что они выложили исходный код на GitHub.
> Вам тоже это доказывать нужно? Или вы все-таки умеете гуглить? Если
> сам код не найдётся с первого раз есть зеркала и форки.Мда... утечку рассматирвать как открытие кода? Это явно не лечится. Хотя, что требовать от любителей старых опер.
> The source code for version 12.15 was leaked to GitHub on February 11, 2016.[27] It remained unnoticed until January 12, 2017 and was taken down two days later in response to a DMCA request.[28][29] Opera Software has confirmed the authenticity of the source code.[30]
на цирк не отвечаю> later in response to a DMCA request
Что я говорил про форки и зеркала? Кто-то не умеет гуглить? Ты же хотела исходный код посмотреть.
> на цирк не отвечаюТы же его устроил, а теперь сливаешь.
>> later in response to a DMCA request
> Что я говорил про форки и зеркала? Кто-то не умеет гуглить? Ты
> же хотела исходный код посмотреть.Дурачка не надо включать. Речь ясно шла про то, что браузер проприетарный. Как был, так и остался. Ох уж эти опероводы. Не зря всегда считала их странными.
ещё раз процитирую тебя тебе> Исходный код не посмотреть.
> ещё раз процитирую тебя тебе
>> Исходный код не посмотреть.И как ты уверен, что это тот же код, который ты исполнял? Клиника. На этом стоит закончить разговор.
> И как ты уверен, что это тот же код, который ты исполнял?Ещё раз процитирую своё сообщение, которые ты назвал цирком:
> В жизни так бывает. Вы лучше выберите, что для вас лучше: когда люди вокруг без доказательств не сообщают вам ничего, или когда с доказательствами, но таких сообщений будет очень мало.
Если тебе действительно интересна эта тема и у тебя нет цели уделать кого-то в споре на opennet.ru и самоутвердиться, то у тебя есть все инструменты, чтобы проверить мои слова.
> Клиника. На этом стоит закончить разговор.
Да, тебе пора на процедуры.
Как же надоел этот JavaScript.
Програмируй на пыхе, лол.
Ты пых нынешний видел? Это уже местами более джава, чем сама джава. Не шмагет.
Да, что вам не нравится?
JavaScript - это основа, как ассемблер, только для веба.
Те, кто критикует JavaScript, обычно недовольны фреймворками, такими как jQuery, NestJS, Vue и другими, или они шокированы минифицированным JS-кодом. Например, Столлман считает что минифицировать плохо, сравнивая это с проприетарным кодом, и утверждает, что нельзя минифицировать код в Open Source проектах. Однако, если не минифицировать код, веб-трафик увеличивается.Сам по себе JavaScript здесь не при чём.
> Да, что вам не нравится?
> JavaScript - это основа, как ассемблер, только для веба.
> Те, кто критикует JavaScript, обычно недовольны фреймворками, такими как jQuery, NestJS,
> Vue и другими, или они шокированы минифицированным JS-кодом. Например, Столлман считает
> что минифицировать плохо, сравнивая это с проприетарным кодом, и утверждает, что
> нельзя минифицировать код в Open Source проектах. Однако, если не минифицировать
> код, веб-трафик увеличивается.
> Сам по себе JavaScript здесь не при чём.Средний размер сайта сегодня больше doom. Вот и думайте.
> Средний размер сайта сегодня больше doom. Вот и думайте.Вот именно: подумайте сами, причина - фреймворки с лишним, ненужным кодом, а не сам JavaScript. Он легок.
>> Средний размер сайта сегодня больше doom. Вот и думайте.
> Вот именно: подумайте сами, причина - фреймворки с лишним, ненужным кодом, а
> не сам JavaScript. Он легок.Всего 847 страниц спецификации ecmascript 2025. v8 наверное тоже очень легкий и собирается за минуту.
> Всего 847 страниц спецификации ecmascript 2025.Путаете тёплое с мягким: спецификации не влияют на сложность, глючность и нагруженность фреймворков. JS – это кирпичи и цемент, пишите на нём – будет быстро. Но, используя фреймворки, вы добровольно лишили себя скорости в угоду сомнительному удобству.
Причём не только себя, но и заставляете страдать ваших пользователей.> v8 наверное тоже очень легкий и собирается за минуту.
Вопросы к Google по V8 и к Mozilla по тормознутейшему SpiderMonkey ¯\_(ツ)_/¯
Реализовать стандарты можно по-разному.
>> Средний размер сайта сегодня больше doom. Вот и думайте.
> Вот именно: подумайте сами, причина - фреймворки с лишним, ненужным кодом, а
> не сам JavaScript. Он легок.Да. Просто нужно делать так чтобы HTML–страницы работали и без JavaScript. Но погодите. Нынче почти никто так не делает а сама идея считается кощунственным святотаством. Некоторые предлагают делать наоборот.
> Да. Просто нужно делать так чтобы HTML–страницы работали и без JavaScript.Нет же. Как вы не поймёте, что тогда они будут ещё тяжелее? JS динамически создаёт только необходимые элементы в зависимости от действий пользователя на странице, это и уменьшает её размер и экономит трафик. Это современный подход к веб-вёрстке.
> Но погодите. Нынче почти никто так не делает а сама идея считается кощунственным святотаством. Некоторые предлагают делать наоборот.
Ну, так не 90-е уже давно.
Мне надоедает отвечать на одно и тоже по кругу снова и снова. Тяжелее они будут в каких–то крайних случаях когда сайтостроители мнят что HTML–страница это программа из–за чего она обростает скриптами и все тривиальные действия которые работают и без них перестают без этих скриптов работать. Открываешь ТыТрубу а там орава скриптов тужыться строя DOM а я в это время наблюдаю серые прямогульники и подёргивания. Ощущения лёгкости чего–то не возникает. Просмотрел одно видео, два, три, закрыл вкладку. Кто и сколько наэкономил? «Лёгкость» эта особенно заметна на дохлых умнофонах — батарейка сжирается на глазах, а корпус греется так что умнофон боязно держать в руках. И Invidious который показывает те же видосы с ТыТрубы и может работать без JavaScript, страницы грузятся почти моментально, нагрузка на умнофон меньше, заряд батареи тратится медленнее.Если не 90-е, то давайте займём компы пользователей напрасной работой чтобы не простаивали а вокруг простой концепции показа форматированного текста с картинками выстроим культ чтобы казаться важными и занять себя работой.
> Мне надоедает отвечать на одно и тоже по кругу снова и снова.Не отвечайте, тут никто не заставляет.
> Тяжелее они будут в каких–то крайних случаях когда сайтостроители мнят что HTML–страница это программа из–за чего она обростает скриптами и все тривиальные действия которые работают и без них перестают без этих скриптов работать.Если мы говорим о мире без JS, то и скриптов, генерирующих элементы на странице, не будет. Вместо этого страницы будут перегружены и содержать много избыточной информации. Собственно, так раньше и было: при навигации на веб-сайтах у нас полностью перерисовывалась страница. Сейчас такое редко можно встретить - загружаются только необходимые элементы благодаря JavaScript.
> из–за чего она обростает скриптами
Ну, скрипты в страницы никто не встраивает. .js-файлы грузятся обычно отдельно от самих страниц, и 1 .js-файл может обслуживать сотни страниц, что экономит веб-трафик.
> Открываешь ТыТрубу а там орава скриптов тужыться строя DOM а я в это время наблюдаю серые прямогульники и подёргивания. Ощущения лёгкости чего–то не возникает.
Это частный случай. Им никто не мешает сделать всё по уму, чтобы у вас возникало ощущение легкости. Если разработчики используют тяжелые фреймворки и неоптимальные подходы, то при чём тут JavaScript, который даёт им возможность делать нормально?
Мне не нравится сам JavaScript. Я считаю что все кто превозносит JavaScript просто ничего другого толком не знают и не видели. Но это ничто по сравнению с тем как мне не нравятся вещи связанные с JavaScript и проистекающие из него. Такие как HTML–страницы которые притворяются нормальными программами, Electron, пихание JavaScript везде, распухание размера HTML–страниц и их прожорливость, распухание браузеров и их прожорливость. А ещё мне не нравятся web–программисты для которых и которыми все эти Electron и создаются.Трафик сильно уменьшиться если перестать напихивать скрипты в HTML–страницы. Уменьшение объёма передаваемых данных это конечно похвально, но что за перевод стрелок с первопричины?
> Я считаю что все кто превозносит JavaScript просто ничего другого толком не знают и не видели.Не важно, что вы там видели. У вас нет выбора в вебе, в вебе это основа. Даже если вы будете WASM использовать, обёртку всё-равно на JS придётся писать.
> мне не нравятся вещи связанные с JavaScript и проистекающие из него.Но JS тут причём? Это всё равно, что винить машинный код за то, что программы на высокоуровневых языках (таких как Java или Python) медленно работают.
Вы можете написать веб-программистам нормальный фреймворк – лёгкий, не такой жирный, как Electron. Они скажут вам спасибо.
Web–программирование это позорное занятие. JavaScript никакой не машинный код и не низкоуровневый язык. Я бы запретил Electron и ему подобные выдумки. Место HTML–страниц в WWW и то они должны работать без JavaScript.
А вы сами то не веб-программист?
Не веб-программист.
> JavaScript никакой не машинный код и не низкоуровневый языкЭто не совсем так. Современные JavaScript-движки (например, V8 в Chrome и Node.js) используют JIT-компиляцию (Just-In-Time). Это значит, что код JavaScript компилируется в машинный код во время выполнения, что позволяет ему достигать производительности, сравнимой с некоторыми компилируемыми языками.
То, что изначально JavaScript был интерпретируемым, не означает, что он остался таковым.
>> JavaScript никакой не машинный код и не низкоуровневый язык
> JavaScript компилируется в машинный кодНо сам то JavaScript не машинный и неизкоуровневый.
> Но сам то JavaScript не машинный и неизкоуровневый.Для веба JavaScript такой же низкоуровневый, как HTML и CSS.
А вот фреймворки, использующие JavaScript, – высокоуровневые. Все тормоза возникают из-за неоптимальных фреймворков. Винить в этом JavaScript – это дитчайшее заблуждение.
>> Но сам то JavaScript не машинный и неизкоуровневый.
> Для веба JavaScript такой же низкоуровневый, как HTML и CSS.
> А вот фреймворки, использующие JavaScript, – высокоуровневые. Все тормоза возникают
> из-за неоптимальных фреймворков. Винить в этом JavaScript – это дитчайшее заблуждение.Это какая–то софистика, натягивание совы на глобус и абсолютно ненужные аналогии. Ещё, наверное, можно договориться до того что когда размечаешь текст тегами HTML, то это программирование и что HTML это как машинные коды.
> Это какая–то софистика, натягивание совы на глобус и абсолютно ненужные аналогии.Я расписал вам ситуацию, как она есть. Никто ничего не натягивает.
> Ещё, наверное, можно договориться до того что когда размечаешь текст тегами
> HTML, то это программирование и что HTML это как машинные коды.Вот здесь вы натягиваете, как раз сову на глобус. Если в HTML/CSS присутствует логика, состояние, взаимодействие с пользователем, то это программирование. Если только «теги и атрибуты», то это разметка, а не программирование.
HTML и CSS постоянно эволюционируют, и многие разработчики, пишущие на сложных фреймворках, не подозревают, что многие динамические вещи уже можно делать на чистом HTML и CSS, и JavaScript для этого можно не использовать в принципе. Те, кого заботит скорость работы, первым делом ищут возможность реализовать такой же функционал на HTML/CSS без JavaScript, а если это невозможно, тогда используют JavaScript. А те, кого не заботит скорость работы, навешивают кучу фреймворков и даже документации их создателей не читают, как оптимизировать. В итоге фронтенд с виду легенького сайта может весить 10GB - реальный случай, который я видел, когда мне такую задачу передал Full-Stack подрядчик.
Часом не о тебе делал видосики некий Panas Drygalo? PURA KODO – веб-студия на чистом коде https://inv.nadeko.net/watch?v=j5PyP3_9-60
нет, первый раз слышу
Вспомнилось "640 килобайт должно хватить всем"
В итоге очень много устройств работает на относительно малом объеме памяти. И в этом ничего такого удивительного нет.
Никто же не будет просто так, скажем, текстовый редактор раздувать бесконечно. Не будет такого, что завтра он будет в ОЗУ занимать 4 Гига(условно).Бизнес-идея в гараж: можно в данное время раздуть любую программу и торговать запасами ОЗУ.
Он ещё упаковщик досовских exe-шников LZEXE в своё время сделал. Прикольный чел.А вот досовскую игрушку Kicks сделал он или нет? Кто помнит?
> Он ещё упаковщик досовских exe-шников LZEXE в своё время сделал.Да!
вот про него кто-то написал:
https://www.ipaidia.gr/wp-content/uploads/2020/12/117-2020-f...
Молодец этот математик - столько полезного сделал и ещё под лицензией MIT !