Это ты пока кайфуешь. Погоди немного. Сразу видно человека только недавно пересевшего на Андройд. У Андройда отсутствует контроль за ресурсами, то есть в системе полная анархия, всё что угодно лезет куда угодно и когда угодно. Ты хочешь запустить камеру, а в это время какое-то из приложений решило что-то скачать объёмное (апдейт например), всё - жди полминуты (пока камера отлагает). Плюс Андройд сам по себе из коробки довольно шустрый, но если у тебя установлено 50+ приложений (что вообще никак не влияет на производительность на Эппл) - то всё, поздравляю, у тебя не телефон больше, а корыто. Особенно это заметно в эпоху React Native / Flutter (средний лаг рендера в 10/20 раз медленнее Java), когда это всё не работает, тормозит, лагает, и в целом выглядит как ущербное индусо-китайское нечто (как, впрочем, и почти всё современное от крупнейших корпораций).
Андройд редкостная дрянь. Я даже убеждён, что они специально не оптимизируют ядро, что бы не вступать в конкуренцию с Эппл, что бы Эппл их не засудил. Вообще, cамые основные технологические продукты Гугла - Android и Flutter отличаются крайне низкой производительностью, что как бы намекает.
Никто не отрицает, что они зарабатывают меньше. Вот только одна медицина - фактически 2/3 современной медицины это обслуживание интересов эмансипированной женщины, одна абортная инфраструктура это огромная воронка ресурсов, которые при классических семейных ценностях не расходуются, а у нас в стране полмиллиона абортов в год, и это ещё снизился показатель в десять раз от пика. Это мы только медициной начали. Безопасность. Подавляющее большинство мужчин способны за себя и за свою семью постоять. Убираем женщин с улиц - расходы на безопасность можно на порядок сокращать. То есть вся та критика, которая направлена на классический "старый" порядок - это притянутая, вывернутая наизнанку, натянутая на глобус сферическая сова в вакууме. Или другими словами - полный бред. Это мы ещё даже не начинали по всем пунктам разбирать. Если убрать из бюджета современного государства охрану и обеспечение "современной" женщины, то расходы на порядок падают. Причём не факт что на один.
Просто в последние столетие больше всего ущерба нормальному среднему человеку нанесли именно левые, а значит именно их в данный момент я лично воспринимаю как главную угрозу для нормального существования.
Это со стороны политически ангажированных людей всё выстроено в чёткие абстракции - а с моей всё просто: гаси того, от кого проблем больше.
Эмансипированная женщина всегда создаёт больше проблем, чем решает, левачьё десятилетиями отрицало эти факты, но, например по официальной статистике Новой Зеландии - в среднем женщины не приносят прибыли в бюджет, потому что намного больше уходит на их прямое и косвенное социальное обеспечение, чем от них прибыли. Вечная проблема левачья - это упорное отрицание фактов, почему они вечно и обсираются по итогу.
На английском поищите. На русском 99% актуальной информации тупо нет. Если вы ищите только на русском, а потом жалуетесь, что нет требуемой информации - то возникает вопрос к вашей квалификации. Достаточно пройтись по первым десяти англоязычным ссылкам по запросу WHATWG, что бы полностью раскрыть для себя тематику. Если не умеете читать на английском - поставьте плагины для перевода страниц и настройте хороший переводчик, хотя в 2025, уже даже гугловский неплохо справляется. Используйте LLM для перевода, он вам ещё и выжимку из текста сделает.
Движемся мы обратно к ванильному JS без фреймворков на фронтенде, уже давний тренд, увеличивающийся с каждым днём. Во-первых, ванилька в 28 раз быстрее реакта по замерам, во-вторых JS в 2025-от году, это уже не JS 2013-го года, когда React был зарелизен. Нету проблем с кросс-браузерной совместимостью, все свежие стандарты давно реализованы в браузерах и у пользователей в 99 случаях из 100 - актуальный софт на актуальном железе, в JS встроили всё то, что было хорошего в jQuery и не только, и у JS API от HTML5/CSS3 уже повсеместная поддержка, то есть JS уже давно перешагнул всё то за, что его все хейтили, попутно обрастя таким количеством новых API, как, например, Canvas, webGL и прочее, что это уже совершенно другой язык, который, практически во всём круче реакта и любого другого реактоподобного фреймворка, при этом работает на треть порядка быстрее и единственный плюс реакта в данный момент это более короткий синтаксис, что уже не проблема и полностью решилось современными LLM, то есть, по факту, в эпоху LLM - преимуществ у реакта и не осталось, а осталась производительность на треть порядка хуже и куча кодовой базы исполняющаяся в рантайме у пользователя на машине, где уже двести вкладок и после открытия очередного сайта с двумя ссылками и пятью разделами, но на реакте (потому что так лучше продаётся, "сайт на реакте" звучит круто) - сайт благополучно падает вместе с браузером. Отсюда появление проектов вроде такого, при радостном улюлюканьи толпы.
Если промпт точно составлять, то надеется и представлять - не надо, если LLM с достаточной базой знаний и контекстное окно позволяет, то генерация 100% точная будет, правда у меня средний промпт под сто килобайт (кодовая база + комментарии + архитектура проекта + инструкции).
После того, как тема решена - просить составить описание проекта, файлов, их взаимосвязи, текущее состояние, глобальную цель и дальнейшие шаги. Это позволяет относительно "безболезненно" начинать новый диалог.
Я просто собираю в один промпт весь нужный код, описание проекта, комментарии должны быть хорошо прописаны, точные требования, архитектура проекта очень подробно простыми словами описана. Если так делать, то качество генерации практически стопроцентное даже на очень объёмных кусках кода. Промпт, правда, в сто килобайт выходит в среднем, но практически не делаю лишних запросов. Очень сильно качество генерации зависит от того, как LLM умеет разгребать контекст. Gemini вроде контекст большой, но он плохо понимает что ему кормят, приходится до мельчайших мелочей логику прописывать, Claude тут намного лучше. Но, в целом, можно даже от самых элементарных моделей добиться качественной генерации, вопрос желания и усилий. Сейчас уже можно свой проект прямо в LLM встроить, тогда контекст безлимитный, если LLM локальная.
Ищите лучше, я не знаю как вы ищите. JavaScript стандартизируется тремя организациями: WHATWG, W3C, Mozilla Foundation, в данный момент всю работу делает WHATWG, W3C утверждает, Mozilla Foundation молчит и кивает. Вы выше писали:
"Там в другой ветке уже обсуждалось - в этих сообщениях "стандарт JS" = "JS в браузерах", т.е. вместе с DOM и прочим подобным, а не буквально стандарт.
Так JS существует только в рамках браузера и нигде больше! Браузер это реализация исполнения стандарта W3(WWW) - HTML/CSS/JS (в стандарт ещё много чего входит, но это основное), то есть браузер это реалтаймовый интерпретатор W3, JS существует только в этих рамках и больше нигде.
Все остальные применения названия JS - это маркетинг и ничего больше. JS это основная часть стандарта W3, всё, что выходит за пределы этого стандарта - JavaScript-ом не может быть и по определению им не является.
ECMAScript это синтаксис JS, ничего больше, если ваши источники утверждают нечто другое - смените источники.
Этот подход работает с любой LLM и делается даже без специальных программ - вручную. Этакая генерация "супер-промпта". Прекрасно работает и без IDE, даже в чате. Даже из очень старых и простых моделей так можно вытягивать, как из паука-шелкопряда, очень высококачественную генерацию. Я бы даже сказал, что не в десять раз вырастает качество генерации, при правильном подходе, а во все сто. Даже нет необходимости через IDE работать, потому что если промпт правильно составлен, то генерация практически идеальная, если контекстного окна LLM хватило. Конкретно по статье - видно в генерируемом промпте слишком общие выражения. Если более точно задавать команду LLM, не давая LLM вообще никакой возможности ошибиться, то можно огромную, 100%-работающую кодовую базу получить с первого раза, на любой задаче, если хватает базы знаний и контекстного окна. Можно вытягивать настолько качественный код с настольно базовых LLM, что для многих это покажется невероятным.
Да какая разница, что большинство здесь думает? Это полный бред. Синоним - не синоним, для большинства - не большинства... То что вы называете JS на самом деле называется ECMAScript, у ECMAScript множество разнообразных реализаций, а JS это совершенно другой стандарт, который по объёму в пятьдесят раз больше ECMAScript. На Хабре то ли люди в 1995-ом году застряли, когда это ещё синонимы были, либо сидят люди, которые в фронтенде вообще ничего не понимают (а зная как обстоят дела в России с фронтенд индустрией - тут удивляться нечему), то ли просто кроме бэкендеров на сайте никого нет. Я так подозреваю, что все три утверждения правда в той или иной степени. ECMAScript постоянно называют JS, даже Node.JS называется JS, хотя это просто маркетинг, в ноде от JS только родство по ECMAScript (что там написано на официальном сайте - мне плевать, просто маркетинг, что бы несведущие проще понимали), нода в реальности и JS это абсолютно разные вещи. Просто смешно, заходишь на айтишный, "серьёзный" сайт, где все на пафосе, и объясняешь разницу между JavaScript, Node.JS и ECMAScript. Может ещё стоить объяснить что JavaScript и Java - это разные вещи, или это за тридцать лет более менее усвоили?
Так это и есть стандартизированный JS. Да-да, все API JS давно стандартизированы W3C, WHATWG и Mozilla Foundation, причём в эпоху HTML5/CSS3 ведущую роль давно уже играет WHATWG. ECMAScript это абсолютно другой стандарт. Мда, приходится на айтишном сайте объяснять базу фронтенда. Ну думал, что здесь один бэкендеры собираются.
А Flutter это редкостное bloatware, о чём известно всем за пределами Хабра. Первый раз я встречаю, что бы на каком-либо айтишном сайте собрались люди, которые отрицали бы тормознутость flutter, это вообще аксиома и всем известно, что flutter ужасно лагает на любом функционале отличном от базового. Если что, вот замеры: https://blog.theodo.com/2023/09/ios-rendering-performance
Я конечно, понимаю, что я тут процентов 5% населения сайта выдергиваю из их зоны комфорта, где flutter это "продвинутая технология от гугла", которая "не может лагать", но на любом айтишном сайте, кроме хабра, лагающий flutter это просто общеизвестная истина. Тут просто люди очень боятся за свою зону комфорта, а мне, просто случайно на Хабр затесавшемуся - потратить рейтинг на доброе дело не жалко, flutter это дико ущербная технология, и об этом должно знать максимальное количество людей, и минуса от хабровского echo chamber - мне как-то не особо страшны.
Скажите, а Gemini 2.5 Pro имеет в себе какие-либо способы сделать так, что бы у Flutter скорость рендеринга выросла? Потому что сейчас у Flutter явные проблемы, рендер одного элемента происходит с средней задержкой в полсекунды и вплоть до полутра секунд на большом количестве элементов. Очень хотелось бы знать.
Если речь о С-подобных языках, и вы хорошо знакомы с одним из них - то ОК. Я же например, как и многие, знаю только JS, потому что JS настолько объёмный (весь стандарт JS в 50 раз больше стандарта ECMAScript), что либо ты развиваешься в JS до конца либо ты его так и не освоишь полностью. Поэтому для работающих c JS - LLM это подарок просто, потому что я могу что угодно без особых усилий на любом C-подобном языке собрать. И так же это действует и в обратную сторону, если вам нужно что-то собрать на JS, а вы знаете только C-подобный язык, то это подарок просто. Опять-таки, есть много не С-образных языков разнообразнейшего применения, для них это так же применимо. И, я вам скажу, что все современные LLM с JS работают в рамках фронтенда абсолютно безошибочно, потому что браузер это статичное окружение, то есть если база знаний современная и контекстного окна хватает (или проект встроен в LLM и контекст безлимитный), то вероятность ошибки околонулевая. Вот с CSS есть проблемы, потому что это текстовый векторный редактор, по сути, и все LLM очень плохо понимают редактирование вектора, но для написания JS-скелета - вам CSS особо и не нужен, потом руками сделаете.
А вы не пробовали сосредоточится на том, что bloatware фреймворк, называющийся Flutter, имеет задержку рендера элементов от полусекунды до полутра секунд, т.е., он, по факту, непригоден для полноценного продакшена, кроме таких ситуаций, как прототипирование и быстрый запуск.
Это ты пока кайфуешь. Погоди немного. Сразу видно человека только недавно пересевшего на Андройд. У Андройда отсутствует контроль за ресурсами, то есть в системе полная анархия, всё что угодно лезет куда угодно и когда угодно. Ты хочешь запустить камеру, а в это время какое-то из приложений решило что-то скачать объёмное (апдейт например), всё - жди полминуты (пока камера отлагает). Плюс Андройд сам по себе из коробки довольно шустрый, но если у тебя установлено 50+ приложений (что вообще никак не влияет на производительность на Эппл) - то всё, поздравляю, у тебя не телефон больше, а корыто. Особенно это заметно в эпоху React Native / Flutter (средний лаг рендера в 10/20 раз медленнее Java), когда это всё не работает, тормозит, лагает, и в целом выглядит как ущербное индусо-китайское нечто (как, впрочем, и почти всё современное от крупнейших корпораций).
Андройд редкостная дрянь. Я даже убеждён, что они специально не оптимизируют ядро, что бы не вступать в конкуренцию с Эппл, что бы Эппл их не засудил. Вообще, cамые основные технологические продукты Гугла - Android и Flutter отличаются крайне низкой производительностью, что как бы намекает.
Никто не отрицает, что они зарабатывают меньше. Вот только одна медицина - фактически 2/3 современной медицины это обслуживание интересов эмансипированной женщины, одна абортная инфраструктура это огромная воронка ресурсов, которые при классических семейных ценностях не расходуются, а у нас в стране полмиллиона абортов в год, и это ещё снизился показатель в десять раз от пика. Это мы только медициной начали. Безопасность. Подавляющее большинство мужчин способны за себя и за свою семью постоять. Убираем женщин с улиц - расходы на безопасность можно на порядок сокращать. То есть вся та критика, которая направлена на классический "старый" порядок - это притянутая, вывернутая наизнанку, натянутая на глобус сферическая сова в вакууме. Или другими словами - полный бред. Это мы ещё даже не начинали по всем пунктам разбирать. Если убрать из бюджета современного государства охрану и обеспечение "современной" женщины, то расходы на порядок падают. Причём не факт что на один.
Ни к кому я себя не отношу. К адекватам. Барин/партком/депутат - Ване без разницы, кто его плетью бьёт.
https://www.roiw.org/2016/n3/7.pdf
Просто в последние столетие больше всего ущерба нормальному среднему человеку нанесли именно левые, а значит именно их в данный момент я лично воспринимаю как главную угрозу для нормального существования.
Это со стороны политически ангажированных людей всё выстроено в чёткие абстракции - а с моей всё просто: гаси того, от кого проблем больше.
Эмансипированная женщина всегда создаёт больше проблем, чем решает, левачьё десятилетиями отрицало эти факты, но, например по официальной статистике Новой Зеландии - в среднем женщины не приносят прибыли в бюджет, потому что намного больше уходит на их прямое и косвенное социальное обеспечение, чем от них прибыли. Вечная проблема левачья - это упорное отрицание фактов, почему они вечно и обсираются по итогу.
На английском поищите. На русском 99% актуальной информации тупо нет. Если вы ищите только на русском, а потом жалуетесь, что нет требуемой информации - то возникает вопрос к вашей квалификации. Достаточно пройтись по первым десяти англоязычным ссылкам по запросу WHATWG, что бы полностью раскрыть для себя тематику. Если не умеете читать на английском - поставьте плагины для перевода страниц и настройте хороший переводчик, хотя в 2025, уже даже гугловский неплохо справляется. Используйте LLM для перевода, он вам ещё и выжимку из текста сделает.
Движемся мы обратно к ванильному JS без фреймворков на фронтенде, уже давний тренд, увеличивающийся с каждым днём. Во-первых, ванилька в 28 раз быстрее реакта по замерам, во-вторых JS в 2025-от году, это уже не JS 2013-го года, когда React был зарелизен. Нету проблем с кросс-браузерной совместимостью, все свежие стандарты давно реализованы в браузерах и у пользователей в 99 случаях из 100 - актуальный софт на актуальном железе, в JS встроили всё то, что было хорошего в jQuery и не только, и у JS API от HTML5/CSS3 уже повсеместная поддержка, то есть JS уже давно перешагнул всё то за, что его все хейтили, попутно обрастя таким количеством новых API, как, например, Canvas, webGL и прочее, что это уже совершенно другой язык, который, практически во всём круче реакта и любого другого реактоподобного фреймворка, при этом работает на треть порядка быстрее и единственный плюс реакта в данный момент это более короткий синтаксис, что уже не проблема и полностью решилось современными LLM, то есть, по факту, в эпоху LLM - преимуществ у реакта и не осталось, а осталась производительность на треть порядка хуже и куча кодовой базы исполняющаяся в рантайме у пользователя на машине, где уже двести вкладок и после открытия очередного сайта с двумя ссылками и пятью разделами, но на реакте (потому что так лучше продаётся, "сайт на реакте" звучит круто) - сайт благополучно падает вместе с браузером. Отсюда появление проектов вроде такого, при радостном улюлюканьи толпы.
Если промпт точно составлять, то надеется и представлять - не надо, если LLM с достаточной базой знаний и контекстное окно позволяет, то генерация 100% точная будет, правда у меня средний промпт под сто килобайт (кодовая база + комментарии + архитектура проекта + инструкции).
Я просто собираю в один промпт весь нужный код, описание проекта, комментарии должны быть хорошо прописаны, точные требования, архитектура проекта очень подробно простыми словами описана. Если так делать, то качество генерации практически стопроцентное даже на очень объёмных кусках кода. Промпт, правда, в сто килобайт выходит в среднем, но практически не делаю лишних запросов. Очень сильно качество генерации зависит от того, как LLM умеет разгребать контекст. Gemini вроде контекст большой, но он плохо понимает что ему кормят, приходится до мельчайших мелочей логику прописывать, Claude тут намного лучше. Но, в целом, можно даже от самых элементарных моделей добиться качественной генерации, вопрос желания и усилий. Сейчас уже можно свой проект прямо в LLM встроить, тогда контекст безлимитный, если LLM локальная.
Ищите лучше, я не знаю как вы ищите. JavaScript стандартизируется тремя организациями: WHATWG, W3C, Mozilla Foundation, в данный момент всю работу делает WHATWG, W3C утверждает, Mozilla Foundation молчит и кивает. Вы выше писали:
Так JS существует только в рамках браузера и нигде больше! Браузер это реализация исполнения стандарта W3(WWW) - HTML/CSS/JS (в стандарт ещё много чего входит, но это основное), то есть браузер это реалтаймовый интерпретатор W3, JS существует только в этих рамках и больше нигде.
Все остальные применения названия JS - это маркетинг и ничего больше. JS это основная часть стандарта W3, всё, что выходит за пределы этого стандарта - JavaScript-ом не может быть и по определению им не является.
ECMAScript это синтаксис JS, ничего больше, если ваши источники утверждают нечто другое - смените источники.
Этот подход работает с любой LLM и делается даже без специальных программ - вручную. Этакая генерация "супер-промпта". Прекрасно работает и без IDE, даже в чате. Даже из очень старых и простых моделей так можно вытягивать, как из паука-шелкопряда, очень высококачественную генерацию. Я бы даже сказал, что не в десять раз вырастает качество генерации, при правильном подходе, а во все сто. Даже нет необходимости через IDE работать, потому что если промпт правильно составлен, то генерация практически идеальная, если контекстного окна LLM хватило. Конкретно по статье - видно в генерируемом промпте слишком общие выражения. Если более точно задавать команду LLM, не давая LLM вообще никакой возможности ошибиться, то можно огромную, 100%-работающую кодовую базу получить с первого раза, на любой задаче, если хватает базы знаний и контекстного окна. Можно вытягивать настолько качественный код с настольно базовых LLM, что для многих это покажется невероятным.
Ну давайте встретимся, посмотрим, что вы из себя представляете.
Да какая разница, что большинство здесь думает? Это полный бред. Синоним - не синоним, для большинства - не большинства... То что вы называете JS на самом деле называется ECMAScript, у ECMAScript множество разнообразных реализаций, а JS это совершенно другой стандарт, который по объёму в пятьдесят раз больше ECMAScript. На Хабре то ли люди в 1995-ом году застряли, когда это ещё синонимы были, либо сидят люди, которые в фронтенде вообще ничего не понимают (а зная как обстоят дела в России с фронтенд индустрией - тут удивляться нечему), то ли просто кроме бэкендеров на сайте никого нет. Я так подозреваю, что все три утверждения правда в той или иной степени. ECMAScript постоянно называют JS, даже Node.JS называется JS, хотя это просто маркетинг, в ноде от JS только родство по ECMAScript (что там написано на официальном сайте - мне плевать, просто маркетинг, что бы несведущие проще понимали), нода в реальности и JS это абсолютно разные вещи. Просто смешно, заходишь на айтишный, "серьёзный" сайт, где все на пафосе, и объясняешь разницу между JavaScript, Node.JS и ECMAScript. Может ещё стоить объяснить что JavaScript и Java - это разные вещи, или это за тридцать лет более менее усвоили?
Так это и есть стандартизированный JS. Да-да, все API JS давно стандартизированы W3C, WHATWG и Mozilla Foundation, причём в эпоху HTML5/CSS3 ведущую роль давно уже играет WHATWG. ECMAScript это абсолютно другой стандарт. Мда, приходится на айтишном сайте объяснять базу фронтенда. Ну думал, что здесь один бэкендеры собираются.
А Flutter это редкостное bloatware, о чём известно всем за пределами Хабра. Первый раз я встречаю, что бы на каком-либо айтишном сайте собрались люди, которые отрицали бы тормознутость flutter, это вообще аксиома и всем известно, что flutter ужасно лагает на любом функционале отличном от базового. Если что, вот замеры: https://blog.theodo.com/2023/09/ios-rendering-performance
Я конечно, понимаю, что я тут процентов 5% населения сайта выдергиваю из их зоны комфорта, где flutter это "продвинутая технология от гугла", которая "не может лагать", но на любом айтишном сайте, кроме хабра, лагающий flutter это просто общеизвестная истина. Тут просто люди очень боятся за свою зону комфорта, а мне, просто случайно на Хабр затесавшемуся - потратить рейтинг на доброе дело не жалко, flutter это дико ущербная технология, и об этом должно знать максимальное количество людей, и минуса от хабровского echo chamber - мне как-то не особо страшны.
Да это просто ответ на то, как он начал бегать по моим комментариям.
Скажите, а Gemini 2.5 Pro имеет в себе какие-либо способы сделать так, что бы у Flutter скорость рендеринга выросла? Потому что сейчас у Flutter явные проблемы, рендер одного элемента происходит с средней задержкой в полсекунды и вплоть до полутра секунд на большом количестве элементов. Очень хотелось бы знать.
А почему вы всегда пишите, подчеркивая жирным выделением разные слова? Вы считаете, что ваш поток сознания таким образом становится ценнее?
Если речь о С-подобных языках, и вы хорошо знакомы с одним из них - то ОК. Я же например, как и многие, знаю только JS, потому что JS настолько объёмный (весь стандарт JS в 50 раз больше стандарта ECMAScript), что либо ты развиваешься в JS до конца либо ты его так и не освоишь полностью. Поэтому для работающих c JS - LLM это подарок просто, потому что я могу что угодно без особых усилий на любом C-подобном языке собрать. И так же это действует и в обратную сторону, если вам нужно что-то собрать на JS, а вы знаете только C-подобный язык, то это подарок просто. Опять-таки, есть много не С-образных языков разнообразнейшего применения, для них это так же применимо. И, я вам скажу, что все современные LLM с JS работают в рамках фронтенда абсолютно безошибочно, потому что браузер это статичное окружение, то есть если база знаний современная и контекстного окна хватает (или проект встроен в LLM и контекст безлимитный), то вероятность ошибки околонулевая. Вот с CSS есть проблемы, потому что это текстовый векторный редактор, по сути, и все LLM очень плохо понимают редактирование вектора, но для написания JS-скелета - вам CSS особо и не нужен, потом руками сделаете.
А вы не пробовали сосредоточится на том, что bloatware фреймворк, называющийся Flutter, имеет задержку рендера элементов от полусекунды до полутра секунд, т.е., он, по факту, непригоден для полноценного продакшена, кроме таких ситуаций, как прототипирование и быстрый запуск.