>>04104

>анон в одном из предыдущихов тредов ЗАПРОКСИЛ прототип Number, чтобы вешать поля на числа... Он же не будет делать так на работе?

Я тот самый анон. Я программирую уже 20 лет. Все эти 20 помимо прочего я пишу в том числе на js и знаю его в совершенстве.

Я часто показываю какие-то вещи, в ответ на утверждения об ограниченности языка, или когда кто-то несет какую-то дичь, будучи загнан в рамки своего мышления.

Люди перестали изучать возможности, а учат ограничения. Почти все программисты современности обладают магическим мышлением и мало того, что понятия не имею как устроены вещи и инструменты которыми они пользуются. Они даже не интересуются этим.

Вместо того, чтобы изучить феномен графитации и законов по которым она работает, люди пытаются запоминать список предметов, которые точно упадут на землю, если их подросить вверх.

То же самое в программирование. То же самое в жс. То же самое в любом языке или сфере.

Когда я привожу вычурные примеры, по типу того, как примитивы могут обладать изменяемыми свойствами, или как реализовать пайп оператор без пайп оператора, или сделать что-то еще - я лишь покзываю вам то, как мало вы понимаете. Возможно кого-то это подтолкнет к тому, чтобы перестать заниматься мышиной возней с заучиванием бессмыленных правил, вроде таблицы приведения типов, и он один раз посмотри на алгоритм абстрактной операциии этого приведения, который занимает 20 строк, и наконец узнает , что типы приводят не по таблице и заучивать ее не нужно. Нужно просто понять принцип.

Может кто-то отправится выяснить то, как на самом деле устроены объекты на уровне спецификации, и что все ваше взаимодействие с ними совсем не то, каким вы его себе представляете. Узнаете что весь жс основан на весьма ограниченном количестве сообещний, с помощью отправки которых тем или иным сущностям и происходит программирование. Что в жс нет вызовов функций или методом, получения или присвоения свойств - а есть лишь отправка сообщений.

Может кто-то даже наконец поймет, что в жс нет никаких переменных, и на самом деле все они - это свойства объектов с условным классом Scope. И что эти объект выстроены в цепочку наслеования. И внезапно заметит, что с подобным пониманием у него больше не возникнет сложности с пониманием того, ка кработают контексты вызовв в жс, как работает ранее статическое и позднее динамическое связывание.

Ну, а кто-то быть может погрузиться еще глубже и узнает о вещах, вроде того, что код
some(123) = 456
- валидный жс-код, и почему именно.

Наконец, когда хоть кто-то, кого мои увлекательные примеры нестандартных приемов заинтересовали, перестанет заниматься тупым заучиванием правил, а перейдет к изучению принципов из которых эти правила можно вывести - мир станет лучше.

А в реальной работе, о которой ты говоришь во всяком случае, это не применяется в том виде, в которм ты может быть подразумеваешь. Ты не встретишь чтобы кто-то расширял проксей примитив в продакшн корпоративном коде. Но можешь встретить чтобы это было использовано в тестировании. А понимание принципов того, почему это работает, может понадобится например для написания нативных модулей для движков, биндингов к чему-лио и пробросом этого в жс рантаймы.

Ты должен обладать пытливым умом, любопытством и эрудицей. А не стремлением к тому, чтобы вписать себе резюме строчку знания определенной технологии, которую ты на самом деле не знаешь.

Либо ты любишь свое дело. Либо ты будешь выебан по самые гланды, выгоришь и будешь страдать, прозябая в невежестве, так никогда и не поняв, почему у тебя не получается стать мастером своего дела.

>>04725
Нет, имел ввиду Reference Record Type уровня спецификации.
Конструкция some(123) = 123 действительно будет работать, согласно стандарту. В случае если фукнция вернет Reference Type. Это валидная запись, такая же как присваивание любому идентификатору. Если идентификатор неопределен, ты при присваивании так же получишь исключение указывающее на то, что идентификатор не указывает на Reference Record Type. Примеры были выше.

В стандарте на данный момент есть лишь несколько конструкций, которые сейчас работают с Reference Type - это typeof, delete, super, собственно assgnment и несколько прочих.

Именно поэтому typeof some - не бросает исключения в случае если some не определена, в отличии от такого же использованя в любом другом выражении. Потому что typeof принимает не значение, а ссылку.

А delete x.y не производит вычисление y, в случе если он геттер, в отличии от такого же использованя в любом другом выражении, тоже потому что delete принимает ссылку.

И специфкация описывает возможность для окружения использовать ссылки по своему усмотрению. Например когда-то может появиться какое-то WebAPI которе будет оперировать этим типом и в это мне будет ничего удивительного, это не будет каким-то изменением языка - эти возможности заложены в него с самого начала.

Или прямо сейчас ты можешь написать расширение двидка, например в той же ноде, и получить функцию, которая возвращает не значение обычного типа, а Reference Record. И тогда присваивание вызову такой функции будет работать корректно.

Это валидное поведение, такое же, как например экзотические или хостовые объекты (такой как documenta.all, который и функция и undefined и HTMLCollection одновременно). Возможности для реализации сущностей с таким нетипичным поведением описано в стандарте.

Все дело в том, что в жс намного больше базовых типов, чем известные всем восемь основных, доступных из пользовательского кода.

И если разобраться и изучить как они себя ведут, то не будут вызывать удивления или необходимости изучать как-то специально новые фичи языка каждый раз. Потому что все новые фичи основаны на том, что уже есть в спецификации. Все поведение, конструкции, обектная модель и модель исполнения в языке сводится к несколькоим бызовым вещам и принципам. Эти базовые вещи расширялись всего несколько раз - в es3, в es5.1 и в es6. При этом они не менялись, а только чем-то дополнялись.

Что-то я не вдупляю. Автор такого решения задачи, утверждает, что это
Time complexity: O(n)
Space complexity: O(n)
Где тут O(n)? куча циклов, причём есть вложенные.

var topKFrequent = function(nums, k) {
// Create an empty hash map to store the frequency of each element in the array
let hm = {};
// Create an empty array to store the elements based on their frequency
const freq = Array.from({ length: nums.length + 1 }, () => 0);
// Iterate through the input array and add the frequency of each element to the hash map
for (const num of nums) {
hm[num] = (hm[num] || 0) + 1;
}
// Iterate through the hash map and add the elements to the frequency array based on their frequency
for (const key in hm) {
freq[hm[key]] = (freq[hm[key]] || []).concat(key);
}
// Create an empty array to store the top k frequent elements
let ans = [];
// Iterate through the frequency array from the highest frequency to the lowest
for (let j = freq.length - 1; j >= 0; j--) {
// If the current frequency array is not empty, add the elements to the ans array
// and decrement k until k is 0 or the frequency array is empty
for (let i = 0; i < freq[j].length && k > 0; i++) {
ans.push(Number(freq[j]));
k--;
}
}
return ans;
};

>>06795
Angular:

Плюсы:
- Имеет много встроенных функций и модулей, что упрощает разработку.
- Мощный инструмент для создания SPA (Single Page Application).
- Имеет свой язык шаблонов, который упрощает создание пользовательского интерфейса.
- Поддерживается Google.

Минусы:
- Требует большого объема изучения и понимания.
- Большой размер бандла приложения.
- Не самый быстрый фреймворк.

React:

Плюсы:
- Меньший размер бандла приложения.
- Высокая производительность благодаря виртуальной DOM.
- Простота использования и понимания.
- Поддерживается Facebook.

Минусы:
- Не имеет встроенных функций и модулей, что может замедлить разработку.
- Не имеет своего языка шаблонов, что увеличивает сложность создания пользовательского интерфейса.

Сравнение:

Angular и React оба являются мощными фреймворками для создания веб-приложений. Angular предоставляет много встроенных функций и модулей, что делает его хорошим выбором для крупных и сложных проектов. Однако он требует большого объема изучения и понимания, а также имеет большой размер бандла приложения. React, с другой стороны, имеет меньший размер бандла и более высокую производительность благодаря виртуальной DOM. Он также проще в использовании и понимании, но не имеет встроенных функций и модулей, что может замедлить разработку. В целом, выбор между Angular и React зависит от конкретных потребностей проекта и уровня опыта разработчика.

>>08344

> работа есть

> работы нет

Кек, у тебя какое-то деформированное понятие о наличии работы.

>>08339

### PRUMPT #1

Конечно! Вот некоторые основные сравнения между Angular, React, Vue и Svelte:

1. Уровень сложности: Angular - самый сложный фреймворк из этих четырех. Он имеет большое количество функций, которые могут быть трудными для новичков. React и Vue также имеют свои нюансы, но они обычно более просты в изучении. Svelte является наиболее простым и легковесным фреймворком из всех, что позволяет быстрее начать разработку.

2. Производительность: Svelte считается одним из самых быстрых фреймворков из-за своего подхода к компиляции кода во время выполнения. React и Vue также достаточно быстры, но страдают от некоторых недостатков в производительности, таких как проблемы с рендерингом больших списков. Angular, хотя он достаточно мощный, может иметь проблемы с производительностью, если его не правильно настроить.

3. Размер приложения: Vue и Svelte имеют меньшие размеры по сравнению с Angular и React, что делает их идеальными для создания небольших приложений или для использования на мобильных устройствах.

4. Экосистема: Angular имеет широкую экосистему и множество инструментов, что делает его хорошим выбором для крупных проектов. React также имеет большую экосистему, но может быть менее прямолинейным в использовании, особенно для новичков. Vue и Svelte относительно новые фреймворки, поэтому их экосистемы не так развиты, как у Angular и React.

5. Сообщество: все четыре фреймворка имеют активные сообщества разработчиков и поддержку изначальных команд. В общем, React и Angular имеют более крупные сообщества, а Vue и Svelte - более небольшие, но растущие с каждым днем.

6. Набор функций: Angular имеет самый полный набор функций, который включает в себя множество инструментов для создания крупных приложений. React и Vue имеют похожий набор функций, но могут требовать использования сторонних библиотек для решения определенных задач. Svelte имеет самый минимальный набор функций, но это может быть и его преимуществом.

Надеюсь, эта информация будет полезной для принятия решения о выборе фреймворка для вашего следующего проекта!

### PRUMPT #2

Angular:

Плюсы:

Широкий набор функций и инструментов для создания крупных приложений.
Компонентный подход, который упрощает разделение приложения на отдельные части.
Мощная система директив, которая позволяет легко манипулировать DOM.
Минусы:

Высокий порог вхождения из-за множества концепций, которые нужно изучать.
Большой размер бандла, что может привести к проблемам с производительностью.
Ограниченное сообщество, по сравнению с другими фреймворками.
React:

Плюсы:

Простой в использовании и быстрый в изучении.
Virtual DOM позволяет минимизировать количество обращений к реальному DOM, что увеличивает производительность.
Большое сообщество и множество сторонних библиотек.
Минусы:

Нужно использовать сторонние библиотеки для решения некоторых задач (например, маршрутизация).
Сложности с управлением состоянием приложения.
Использование JSX может быть непривычным для тех, кто не знаком с JavaScript.
Vue:

Плюсы:

Простой в использовании и быстрый в изучении.
Удобный синтаксис шаблонов и директив.
Отличная производительность и небольшой размер бандла.
Широкая экосистема и сообщество разработчиков.
Минусы:

Меньшее количество инструментов, чем у Angular или React.
Ограниченная поддержка сторонних библиотек.
Нет так много ресурсов и материалов для изучения, как у React или Angular.
Svelte:

Плюсы:

Очень быстрый и эффективный, за счет компиляции кода во время выполнения.
Минимальный размер бандла.
Простой в использовании и легкий в изучении.
Растущая экосистема и сообщество разработчиков.
Минусы:

Меньше функциональности, чем у других фреймворков.
Может быть сложно найти ответы на вопросы и решения проблем, связанные с Svelte.
Недостаточная поддержка сторонних библиотек.