Почему не сделали обращение к элементам массива через индекс с отрицательными значениями а в место этого сделали функцию? array[-2] а сделали только array.at(-2). Вполне очевидно обращение через квадратные скобки важней. например array[-2]=123;
@@idldmit Не ужели? А зачем тогда ввели новый метод at() для массивов? он как раз поддерживает отрицательные индексы. Если бы Вы думали, то Вы бы поняли что я говорю не отрицательных индексах, а об синтаксическом сахаре. И тем более раз отрицательного индекса нет, то тогда не будет ошибки, если бы ввели такой синтаксический сахар. Именно потому я и спрашиваю, потому что есть полное понимание что ввод отрицательных индексов как синтаксический сахар не вызовет ошибок в существующем коде. Разве Вам было бы не удобно отсчитывать с конца 3 элемент обращяясь как array[-3] ?
@@PlaceTickets Вот именно, вы хотите сахаром засрать фундаментальный смысл вещей. Оператор [] для массива это обращение к элементу по его индексу. Для всего остального создаются методы на любой вкус. Хотите индексацию с конца? вот вам метод который это позволяет. Завтра кто-то решит что было бы неплохо чтоб array[SomeObject] искал бы объект в массиве и возвращал его индекс. Разве не удобно? А потом бы разбивали себе головы пытаясь дебажить код.
TS не может быть независимым) Хороший конец это добавить все тайпы и плюшки в JS при этом давая возможность выбирать режим, чтобы люди выбирали на каком принципе пишут проект.
JS и так уже несогласованная помойка всего подряд из разных языков понатасканного. Если ещё и добавить режим переключения между слабой и сильной типизацией вообще франкенштейн получится 😂
примерно так же реализовано в питухоне. с него начинал, а сейчас сижу на джаве. товарищ попросил посмотреть лоускил код. сидел и чесал репу, пытаясь понять, какие объекты принимают его функции)
Пишу на TS, но считаю идею перетаскивания конструкций и типов из TS в runtime браузера - полный бред. Место TS на этапе компиляции в dev среде, чтобы выдавать подсказки и контролировать типы данных непосредственно разработчику, в браузере он не нужен, по двум элементарным причинам: 1) Это забьёт ещё больше памяти у пользователей хранением типов в оперативке, а браузер сегодня и так довольно прожорливый софт 2) Это не имеет смысла, так как отладка типов производится уже у разработчика в IDE + пункт 1 3) Без костылей и игрой с ресурсами устройства клиента, это поломает всю обратную совместимость с ранее написанным кодом, мы не получим ничего, кроме тонны легаси
Типизация языка из коробки сильно уменшит потребление ОЗУ и увеличит скорость выполнения кода. Так что если уже и тащить TS в код, то прикручивать основные фичи типизированных языков, иначе это не имеет смысла
Ахахаха бл" Раньше у джунов и так мозг взрывался от области видимости функциональной и глобальной, а сейчас еще и экзотическую область подвезли. Нааайс найс найс найс
Интересно это все, только пару дней назад читал о новинках js. Тоже интересно как и что будет с аннотациями типов, что дойдет до конца. Как-то я пропустил изменение ошибок, спасибо что показал)
Проблема в ТайпСкрипт та, что там уже оверинжиринг давно - намудрили уже такого, что я часто видел врайт онли код. Конструкции вкладывают одну в другую. Тайпинг должен быть, как в ActionScript 3 - вот такой нативный тайпинг будет ок. А то сейчас уже типы описывать дольше, чем логику часто приходится.
Бывают казусы иногда с либами, но все же понимая проект типизация в нынешнем виде проблемой не является, зато уберегает от многих багов и делает код читабельнее. имхо
Либо я что-то недопонял в логике работы новых ShadowRealm, либо на 9-10 минуте после a = b = null должно быть let chosen = weakMap.get() вместо exotic.get()
Мне кажется, что ты всё допонял. Тоже возникли мысли на этот счёт. Например, будь у exotic метод get, который бы что-то делал, то как бы он понял из какой WeakMap брать значения по ключу? Ведь symbolA и symbolB вполне себе могут быть ключами для десятка WeakMap, и из какой мапы конкретно брать значения было бы невозможно выяснить.
Расскажите, есть ли канал, группа, или сайт, где можно следить только за новинками языка. Потому что случайно натыкаться на какое то видео\либо пост в тг о новинках, ну такоеее. А так чтоб зашел и сразу посмотреть все новые фичи и пошел дальше работать. Без лишней мишуры
Мне как в прошлом программисту C# забавно наблюдать за нововведениями в JS, которые в шарпах произошли несколько лет назад.) Но это здорово, потому что многих фичей C# мне в JS сильно не хватает.
@@infotauta9234 Пол кода в определении типов и весь код в нормальном ООП. Я до сих пор в шоке, что в Js нет нормальных классов. Те что есть, не доработаны. Мне страшно становится от той модульной мешанины, которую, например вижу в Реакте. Касаемо PHP, то уже 2 года, как перекатился в PHP и дискомфорта после шарпов не чувствую. PHP имеет нормальную реализацию ООП и кстати типизация у него тоже есть. Проблема PHP, что он как и js однопоточный, а так же нет нормальной возможности работы с сокетами в роли сервера.
@@Dadadadam999 > Проблема PHP, что он как и js однопоточный В JS уже более 10 лет существуют воркер-потоки и взаимодействие с ними через сообщения, вокруг них построена куча фрейворков, которые эти самые веб воркеры активно используют. Так что с разморозкой из криокамеры.
@@АлександрСоловьев-ю9ц2к Web worker, это больше про API. Я же говорил о стандартных возможностях JS. Ты не можешь средствами самого JS не прибегая к API сред выполнения создать Thread. Тебе либо придётся прибегать например к ноде, либо пользоваться API HTML5 для web worker'ов. Но на самом деле и на том спасибо, потому что без потоков совсем как-то грустно было бы.
TS должен остаться отдельным инструментом просто потому что JS интерпретируемый язык, т.е. работает прямая зависимость: чем меньше кода напишешь - быстрее загрузится страница. В свою очередь TS подразумевает написание большего количество строк, чем нужно браузеру для работы. Потому считаю, что текущий концепт превращения TS в JS + минимизация выходных файлов + прочие оптимизации оказывают лучший эффект на итоговую производительность, чем если бы мы могли писать на TS из коробки. Пусть лучше останется прослойкой на этапе разработки, которая самовыпиливается из конечного кода.
@@idldmit У меня, наоборот, примерно 0 желания писать на чистом js. Я бы вообще никому не советовал писать что-либо серьезное на чистом js) А в текущем виде обсуждаемый перенос весьма ограниченный, т.е. он одновременно не может покрыть всех возможностей TS + подразумевает написание более длинных скриптовых файлов. А в целом мне все равно, добавят они это или нет, потому что я не вижу смысла этим пользоваться в том виде, каком они предлагают.
Язык будущего, гибкий, мощный, с гибкой настройкой под любые задачи и стили задачи, (возможность работать с пямятью и многопоточностью, писать в скобках, с отступами. и т д, под верстку, стили, под фронт и бэк, асинхронный и нет, с аннотациями и без, чтобы какой-нибудь конфиг файл - мог настраивать компилятор и т д) Какой нибудь подобный, open source язык от IT гиганта с поддержкой комьюнити - было бы круто получить.Тем более с бумом нейросетей, думаю и она может помочь в его создании. Язык один - под все сферы, с разными фреймворками и либами на выбор, это ли не счастье
В таком варианте израсходуется слишком мало памяти и не надо будет класть новые аргументы функции в стэк и очищать их на каждом шаге. Складывается ощущение что это вместе с иммутабельностью продвигают производители железа.
JS изначально был динамически типизированным, максимально универсальным, таким и должен остаться. Нужна "жёсткая" типизация - tsc в руки. А там мелкомягкие пусть творят своё, сколько им влезет.
Мне кажется можно добавить TS в ваниллу, но при условии, что это никак не помешает разрабатывать без TS. Например при let a = 5; переменной не будет присваиваться number или any, чтобы не возникало ошибок если переменная будет переопределена. Только если явно указать. Ну или завезти что-то вроде 'use strict' -> 'use TS', чтобы уж совсем по желанию, но в это совсем не верится, все уже привыкли так, как привыкли.
так работать не будет, use strict ни как не ломает работу в старых браузерах, use TS не будет работать о слова совсем , ибо преобразования нового js(ts) в старый все так же не будет. Это можно добавить, но использовать такое будут не раньше чем через 5-6 лет? es module нативные в браузере до сих пор люди не используют, даже если разрабатывают под последние две версии браузеров как пример
иммутабельность это прекрасно, главное чтоб гарбич коллекторы у всяких гигачадов не захлёбывались теперь, а мемори юсадж не улетала на орбиту к собрату по имени java ;)
Вместо того чтобы прокачать сборщик мусора, который бы умел удалять недостижимые объекты с перекрестными ссылками, мы придумали новую структуру данных. Это пре напоминает шутку про стандартизацию, когда каждая попытка просто порождает новую, а не заменяет все предыдущие как задумывалось.
Так нельзя, потому что есть 100% много кода, который полагается на то, что ключ из map сам по себе не удалиться. И если «прокачать» gc то весь этот код перестанет работать.
Да, учи. Основы ДжаваСквирта - они и в Африке основы. А потом всё равно дойдёшь до этапа развития, когда надо будет постоянно на всякие МДН бегать подглядывать - тогда и наверстаешь то чего в книге не было.
Я сплайсом менял массив, НЕ надо мне было создавать новый массив. туСплайс - пусть будет, просто не надо называть сплайс не рекомендуемым. Просто люди невнимательны - меняют массив и забывают. У меня никогда не было проблем с мутабельностью.
2:45 офигенный тест на синьора. А не что, что в этом коде нет проблемы, если б методы не изменяли объект, то именно это поведение было ошибочным, так как программист явно осознанно игнорирует возвращаемое значение?
фильтр возвращает новый элемент массива, то есть дополнительно n памяти выделится, они в сахаре добавят обычный цикл for, который начинает перебор с конца, и затраты по памяти будет o(1)
@@MoksDev filter возвращает те же ссылки, и возвращает он новый массив, а не элемент массива. Да, по сложности функции согласен, по тому что выдаёт - filter категорически нет. Но и писалось это как аналог предложенный автором: где идёт [...arr].reverse().find() ,- а не полноценная замена новому методу, особенно в оптимизации нахождения единственного элемента или его индекса.
Почитал их предложение, вообще не понятно зачем это нужно. То есть проверки в рантайме все равно не будет, то есть по-сути никаких различий с тс. Типы останутся лишь аннотацией и будут удаляться при сборке.
Я нисколько не программист, но вот сейчас понял почему 90% людей не хотят засирать свои мозги ВОТ ЭТИМ❗я лучше подожду норм языка программирования с нейросетью и начну изучать
Шо вы молитесь на ту иммутабельность, как на религию. Иногда позно, чтобы было мутабельно. Должно быть и так, и так. И на типизацию молитесь! Иногда хорошо, что тип динамический.
TS не протащат в спеку, и для этого есть сразу несколько объяснений: 1. Майки уже пытались в спеку затащить свои декораторы из TS, и так как они сделаны там крайне ущербно, очень упорно, шли холивары по тому нужно или нет. Итог: принята версия декораторов, которая отличается от TS, и TS придется переделывать свои собственные под стандарт. Из-за позиции, команды отвечающей за спеку, ущербные вещи туда не попадут, пока те кто там рулят, продолжают рулить. 2. Сам TS, точно такой же ущербный, как и его декораторы. Он не обеспечивает гарантию строгих типов. Кто хочет, может сам почитать, об этом, так как об этом самом, не писал только ленивый в свое время. Учитывая позицию команды отвечающей за развитие JS, то майкам никто, не даст протащить свою типизацию в стандарт. Так как в свое время, уже говорили, что если и делать аннотацию и типизацию, до брать её из функциональных языков типа Haskell и Irdis, в нашем случае с js - Rison и ReScript. Так что что бы не пропустить этот пропозал дальше, огромное количество серьезных программистов, лягут костьми.
Типизация из коробки для nodejs может и норм а для браузера это лишнее, либо в любом случае для браузера ради оптимизации его надо будет компилировать в обычный js без типов
ts никогда не захватит js. Отсутствие типизации менять на говнотипизацию... Жаль что сообщество reasonml не развилось, сейчас бы писали адекватный код... А вообще поскорее бы wasm развился, и все будут жить счастливо
все языки берут что-то из других, так что глупо говорить про "мешать"... если б автор ролика не сказал что МС пытается засунуть ТС в ЖС , то вы бы и не дергались узнав что в ЖС, например, появятся интерфейсы или можно будет указывать тип
@@izzy7541 Понятно что удаляется и не будут использоваться в рантайме (хотя кто знает, может умный браузер будет для себя делать какие-то выводы), но при этом как минимум на сервере не будет необходимость транслировать код перед запуском.
@@green.616 Ну то есть вы хотите чтобы транспилировал код нода или браузер? Нода ещё допустим, а в браузере что? Транспилировать на машине клиента? Это же чушь, заставлять браузер клиента чистить аннотации. Они загрузку страниц в больших проектах по 2 секунды ждать будут?
Хотел послушать. Но вероятно автор считает меня дебилом, пытаясь развлекать идиотскими вставками. Если говорите о серьёзных вещах, тоа делайте это без кривлянья! Дизлайк.
Оставьте TS и JS оба одновременно. Дайте людям выбор. TS конечно стал манной небесной когда я впервые его узнал, но на нём разработка усложняется и по времени становится раза в 2-3 дольше, так что пусть лучше будет выбор
Тренажеры HTML Academy (HTML, CSS, JS, React) + Академия + Книга рецептов фронтендера + комьюнити
за 99 рублей:
boosty.to/how-to-learn-it
Какие тренажеры бывают:
htmlacademy.ru/courses#fe-start
Утвержденные изменения в JS
github.com/tc39/proposals/blob/main/finished-proposals.md
О дивный новый JavaScript!
th-cam.com/video/cXF-xfghDEg/w-d-xo.html
Мой телеграмм-канал:
t.me/howToLearnIT
0:00 Взрослый фронтенд
0:56 Стандартизация Js
1:49 Record & Tuple
2:45 toSorted, toSpliced, toReverced, with
4:22 Подписочная
4:58 ShadowRealm API
7:56 WeakMap & Symbols
9:56 FindLast & FindLastIndex
10:44 Error cause
11:11 Shebang
11:51 Typescrpt в JavaScript
#javaScript #js #frontend #фронтенд #programming
Почему не сделали обращение к элементам массива через индекс с отрицательными значениями а в место этого сделали функцию? array[-2] а сделали только array.at(-2). Вполне очевидно обращение через квадратные скобки важней. например array[-2]=123;
@@PlaceTickets удобство и здравый смысл не одно и то же, у массива нет элементов с отрицательным индексом
@@idldmit Не ужели? А зачем тогда ввели новый метод at() для массивов? он как раз поддерживает отрицательные индексы. Если бы Вы думали, то Вы бы поняли что я говорю не отрицательных индексах, а об синтаксическом сахаре. И тем более раз отрицательного индекса нет, то тогда не будет ошибки, если бы ввели такой синтаксический сахар. Именно потому я и спрашиваю, потому что есть полное понимание что ввод отрицательных индексов как синтаксический сахар не вызовет ошибок в существующем коде. Разве Вам было бы не удобно отсчитывать с конца 3 элемент обращяясь как array[-3] ?
@@PlaceTickets Вот именно, вы хотите сахаром засрать фундаментальный смысл вещей. Оператор [] для массива это обращение к элементу по его индексу. Для всего остального создаются методы на любой вкус. Хотите индексацию с конца? вот вам метод который это позволяет. Завтра кто-то решит что было бы неплохо чтоб array[SomeObject] искал бы объект в массиве и возвращал его индекс. Разве не удобно? А потом бы разбивали себе головы пытаясь дебажить код.
Привет, по сравнению в твоим первым видео, очень сильно улучишлся звук - какой микрофон ты сейчас используешь?
последнее аж душу согрело так сильно порадовало)))
12:00 Ооо! EcmaScript 4 (ActionScript) возвращается :)
Такая подача хорошо заходит 👌
Годный контент. Подписался 👍
TS не может быть независимым)
Хороший конец это добавить все тайпы и плюшки в JS при этом давая возможность выбирать режим, чтобы люди выбирали на каком принципе пишут проект.
JS и так уже несогласованная помойка всего подряд из разных языков понатасканного. Если ещё и добавить режим переключения между слабой и сильной типизацией вообще франкенштейн получится 😂
примерно так же реализовано в питухоне. с него начинал, а сейчас сижу на джаве. товарищ попросил посмотреть лоускил код. сидел и чесал репу, пытаясь понять, какие объекты принимают его функции)
очередной "use strict"?
Разве синтаксис JS мешает добавить типы? Нет.
Указать для переменной тип - хорошо.
Не указал - работает как и раньше, ведь динамическая типизация.
надеюсь в этом году канал доберется до отметки в 100к подписчиков! видео как всегда топ
ТайпСкрипт МАСТ ДАЙ!
Пишу на TS, но считаю идею перетаскивания конструкций и типов из TS в runtime браузера - полный бред. Место TS на этапе компиляции в dev среде, чтобы выдавать подсказки и контролировать типы данных непосредственно разработчику, в браузере он не нужен, по двум элементарным причинам:
1) Это забьёт ещё больше памяти у пользователей хранением типов в оперативке, а браузер сегодня и так довольно прожорливый софт
2) Это не имеет смысла, так как отладка типов производится уже у разработчика в IDE + пункт 1
3) Без костылей и игрой с ресурсами устройства клиента, это поломает всю обратную совместимость с ранее написанным кодом, мы не получим ничего, кроме тонны легаси
Типизация языка из коробки сильно уменшит потребление ОЗУ и увеличит скорость выполнения кода. Так что если уже и тащить TS в код, то прикручивать основные фичи типизированных языков, иначе это не имеет смысла
Ахахаха бл"
Раньше у джунов и так мозг взрывался от области видимости функциональной и глобальной, а сейчас еще и экзотическую область подвезли. Нааайс найс найс найс
Надеюсь ещё дождемся pipeline оператора
Энергично. Понравилось.
Привет, Друг 🤝
Спасибо за обзор👍👍👍
Спасибо за видео, интересно
Жду pipe operator и pattern matching
Бросайте фронтенд, переходите на Elixir 😁
Интересно это все, только пару дней назад читал о новинках js. Тоже интересно как и что будет с аннотациями типов, что дойдет до конца.
Как-то я пропустил изменение ошибок, спасибо что показал)
люто респектую хотя обо всём слышал кроме последнего пропозала с тс ту джс. Грамотно всё скомпилировал и подал )
Проблема в ТайпСкрипт та, что там уже оверинжиринг давно - намудрили уже такого, что я часто видел врайт онли код.
Конструкции вкладывают одну в другую.
Тайпинг должен быть, как в ActionScript 3 - вот такой нативный тайпинг будет ок.
А то сейчас уже типы описывать дольше, чем логику часто приходится.
писать типы на тс уже стало искусством, такую уйню мудрят у нас на работе, я в шоке
Бывают казусы иногда с либами, но все же понимая проект типизация в нынешнем виде проблемой не является, зато уберегает от многих багов и делает код читабельнее. имхо
@@ВладиславБирюков-ш5э однако оно того стоит
Либо я что-то недопонял в логике работы новых ShadowRealm, либо на 9-10 минуте после
a = b = null
должно быть
let chosen = weakMap.get() вместо exotic.get()
Мне кажется, что ты всё допонял. Тоже возникли мысли на этот счёт. Например, будь у exotic метод get, который бы что-то делал, то как бы он понял из какой WeakMap брать значения по ключу? Ведь symbolA и symbolB вполне себе могут быть ключами для десятка WeakMap, и из какой мапы конкретно брать значения было бы невозможно выяснить.
Тоже не понял этот момент, наверное опечатка
Расскажите, есть ли канал, группа, или сайт, где можно следить только за новинками языка. Потому что случайно натыкаться на какое то видео\либо пост в тг о новинках, ну такоеее. А так чтоб зашел и сразу посмотреть все новые фичи и пошел дальше работать. Без лишней мишуры
Мне как в прошлом программисту C# забавно наблюдать за нововведениями в JS, которые в шарпах произошли несколько лет назад.)
Но это здорово, потому что многих фичей C# мне в JS сильно не хватает.
Фу Ц решетка.
Пол кода лишь в определении типов.
Вот ПХП и ЯваСкрипт другое дело. Пиши свободно.
@@infotauta9234 Пол кода в определении типов и весь код в нормальном ООП. Я до сих пор в шоке, что в Js нет нормальных классов. Те что есть, не доработаны. Мне страшно становится от той модульной мешанины, которую, например вижу в Реакте.
Касаемо PHP, то уже 2 года, как перекатился в PHP и дискомфорта после шарпов не чувствую. PHP имеет нормальную реализацию ООП и кстати типизация у него тоже есть. Проблема PHP, что он как и js однопоточный, а так же нет нормальной возможности работы с сокетами в роли сервера.
@@Dadadadam999 а зачем перекатываться с решетки на php?
@@Dadadadam999
> Проблема PHP, что он как и js однопоточный
В JS уже более 10 лет существуют воркер-потоки и взаимодействие с ними через сообщения, вокруг них построена куча фрейворков, которые эти самые веб воркеры активно используют. Так что с разморозкой из криокамеры.
@@АлександрСоловьев-ю9ц2к Web worker, это больше про API. Я же говорил о стандартных возможностях JS. Ты не можешь средствами самого JS не прибегая к API сред выполнения создать Thread. Тебе либо придётся прибегать например к ноде, либо пользоваться API HTML5 для web worker'ов. Но на самом деле и на том спасибо, потому что без потоков совсем как-то грустно было бы.
TS должен остаться отдельным инструментом просто потому что JS интерпретируемый язык, т.е. работает прямая зависимость: чем меньше кода напишешь - быстрее загрузится страница. В свою очередь TS подразумевает написание большего количество строк, чем нужно браузеру для работы. Потому считаю, что текущий концепт превращения TS в JS + минимизация выходных файлов + прочие оптимизации оказывают лучший эффект на итоговую производительность, чем если бы мы могли писать на TS из коробки. Пусть лучше останется прослойкой на этапе разработки, которая самовыпиливается из конечного кода.
А чем наличие доп. функционал мешает? ТS не исключает JS, хочешь, продолжай писать на чистом JS...
@@idldmit У меня, наоборот, примерно 0 желания писать на чистом js. Я бы вообще никому не советовал писать что-либо серьезное на чистом js) А в текущем виде обсуждаемый перенос весьма ограниченный, т.е. он одновременно не может покрыть всех возможностей TS + подразумевает написание более длинных скриптовых файлов. А в целом мне все равно, добавят они это или нет, потому что я не вижу смысла этим пользоваться в том виде, каком они предлагают.
Ts компилируется и от типов ничего не остается
@@Ghost2012qte согласен
Доброй ночи. А будут выпуски по JS обучение?
Язык будущего, гибкий, мощный, с гибкой настройкой под любые задачи и стили задачи, (возможность работать с пямятью и многопоточностью, писать в скобках, с отступами. и т д, под верстку, стили, под фронт и бэк, асинхронный и нет, с аннотациями и без, чтобы какой-нибудь конфиг файл - мог настраивать компилятор и т д) Какой нибудь подобный, open source язык от IT гиганта с поддержкой комьюнити - было бы круто получить.Тем более с бумом нейросетей, думаю и она может помочь в его создании. Язык один - под все сферы, с разными фреймворками и либами на выбор, это ли не счастье
Прикольно, пользоваться я конечно в 99% случаев не буду
Вот-вот
with с редаксом было бы удобно. Если бы ещё RTK не был придуман
Когда на 1:19 видишь себя на видео 😏
Какой текстовый редактор или ide используешь ?
А зачем нам делать копию массива и reverse, если можно запустить цикл с последнего элемента?
В таком варианте израсходуется слишком мало памяти и не надо будет класть новые аргументы функции в стэк и очищать их на каждом шаге. Складывается ощущение что это вместе с иммутабельностью продвигают производители железа.
JS изначально был динамически типизированным, максимально универсальным, таким и должен остаться. Нужна "жёсткая" типизация - tsc в руки. А там мелкомягкие пусть творят своё, сколько им влезет.
Шибанг работал по моему еще со времен выхода ноды.
Я писал #!/usr/bin/node - работает уже лет 10. chmod +x файлу - и запускался.
Может у меня терминал такой, но я спецом ничего не выпиливал.
после тс решил пописать на джс и пишу как будто вслепую
Svelte в массы! Native типизации быть!
Можно пример нативной типизации из svelte?
@@JestNest-b8v это 2 разных и не связанных заявления ) Хочется нативной типизации и отдельно хочется роста популярности svelte
@@andreydyugaev1958 а что значит нативная типизация в принципе?
@@JestNest-b8v типизация в стандарта Ecma Script из коробки. Чтобы приросток в виде type script был в целом не нужен.
Мне кажется можно добавить TS в ваниллу, но при условии, что это никак не помешает разрабатывать без TS.
Например при let a = 5; переменной не будет присваиваться number или any, чтобы не возникало ошибок если переменная будет переопределена. Только если явно указать.
Ну или завезти что-то вроде 'use strict' -> 'use TS', чтобы уж совсем по желанию, но в это совсем не верится, все уже привыкли так, как привыкли.
так работать не будет, use strict ни как не ломает работу в старых браузерах, use TS не будет работать о слова совсем , ибо преобразования нового js(ts) в старый все так же не будет. Это можно добавить, но использовать такое будут не раньше чем через 5-6 лет? es module нативные в браузере до сих пор люди не используют, даже если разрабатывают под последние две версии браузеров как пример
А как же многострадальные декораторы со Stage3?
Отличный ролик 👍🔥 Автор можешь написать ссылку на фоновую музыку.
Наконец-то млять. Типы
иммутабельность это прекрасно, главное чтоб гарбич коллекторы у всяких гигачадов не захлёбывались теперь, а мемори юсадж не улетала на орбиту к собрату по имени java ;)
Вместо того чтобы прокачать сборщик мусора, который бы умел удалять недостижимые объекты с перекрестными ссылками, мы придумали новую структуру данных. Это пре напоминает шутку про стандартизацию, когда каждая попытка просто порождает новую, а не заменяет все предыдущие как задумывалось.
Так нельзя, потому что есть 100% много кода, который полагается на то, что ключ из map сам по себе не удалиться. И если «прокачать» gc то весь этот код перестанет работать.
Имеется книга изучаем программирование на javascript для начинающих Эрик Фримен и Элизабед Робсон. Есть сейчас смысл её изучить?
Да, учи. Основы ДжаваСквирта - они и в Африке основы. А потом всё равно дойдёшь до этапа развития, когда надо будет постоянно на всякие МДН бегать подглядывать - тогда и наверстаешь то чего в книге не было.
Есть chatgpt . Берешь пет и делаешь с его помощью, запоминаешь
Я сплайсом менял массив, НЕ надо мне было создавать новый массив.
туСплайс - пусть будет, просто не надо называть сплайс не рекомендуемым.
Просто люди невнимательны - меняют массив и забывают. У меня никогда не было проблем с мутабельностью.
Если использовать новые имутабельные методы массивов, например к tuple, то вернется просто массив или новый tuple?
Новый tuple.
Все классно, но кауз... Это мощно. [ˈkɔːz]
2:45 офигенный тест на синьора. А не что, что в этом коде нет проблемы, если б методы не изменяли объект, то именно это поведение было ошибочным, так как программист явно осознанно игнорирует возвращаемое значение?
10:26
const value = array.filter(o => o.value %2 ===1).at(-1);
фильтр возвращает новый элемент массива, то есть дополнительно n памяти выделится, они в сахаре добавят обычный цикл for, который начинает перебор с конца, и затраты по памяти будет o(1)
@@MoksDev filter возвращает те же ссылки, и возвращает он новый массив, а не элемент массива. Да, по сложности функции согласен, по тому что выдаёт - filter категорически нет. Но и писалось это как аналог предложенный автором: где идёт [...arr].reverse().find() ,- а не полноценная замена новому методу, особенно в оптимизации нахождения единственного элемента или его индекса.
@@termorey опечатаося, новый массив, не элемент, да)
@@MoksDev меня поражают люди, которые заботятся о памяти при использовании JS. Походу, отмотали ни один срок на codewars.
@@KissMyS leetcode хотел сказать? 🤣😂, да ладно, тут же мелочи, код хуже не станет)
Почитал их предложение, вообще не понятно зачем это нужно. То есть проверки в рантайме все равно не будет, то есть по-сути никаких различий с тс. Типы останутся лишь аннотацией и будут удаляться при сборке.
ts Очень крутой если очень много кода и ты уже не понимаешь где и что строгий режим помогает не совершать ошибки
А зачем shebang? для чего он в js?
Делать жс файл исполняемым
а в каких браузерах поддерживается уже?
Пока не в каких
@@reckek1030 ((
Я нисколько не программист, но вот сейчас понял почему 90% людей не хотят засирать свои мозги ВОТ ЭТИМ❗я лучше подожду норм языка программирования с нейросетью и начну изучать
когда услышал, что добавят кортеж в js :00000000
Автор!
Пожалуйста, посмотри в словарь, как правильно произносится слово CAUSE!!!
Ну точно не "каУз"!
Шо вы молитесь на ту иммутабельность, как на религию. Иногда позно, чтобы было мутабельно.
Должно быть и так, и так.
И на типизацию молитесь! Иногда хорошо, что тип динамический.
TS не протащат в спеку, и для этого есть сразу несколько объяснений:
1. Майки уже пытались в спеку затащить свои декораторы из TS, и так как они сделаны там крайне ущербно, очень упорно, шли холивары по тому нужно или нет. Итог: принята версия декораторов, которая отличается от TS, и TS придется переделывать свои собственные под стандарт. Из-за позиции, команды отвечающей за спеку, ущербные вещи туда не попадут, пока те кто там рулят, продолжают рулить.
2. Сам TS, точно такой же ущербный, как и его декораторы. Он не обеспечивает гарантию строгих типов. Кто хочет, может сам почитать, об этом, так как об этом самом, не писал только ленивый в свое время. Учитывая позицию команды отвечающей за развитие JS, то майкам никто, не даст протащить свою типизацию в стандарт. Так как в свое время, уже говорили, что если и делать аннотацию и типизацию, до брать её из функциональных языков типа Haskell и Irdis, в нашем случае с js - Rison и ReScript. Так что что бы не пропустить этот пропозал дальше, огромное количество серьезных программистов, лягут костьми.
Типизация из коробки для nodejs может и норм а для браузера это лишнее, либо в любом случае для браузера ради оптимизации его надо будет компилировать в обычный js без типов
оптимизации чего?)
Ты в любом случае будешь его компилировать
А даже если и нет то ни на что оно не влияет, только на размер пакета
@@kirillbdevмного лишнего кода
TS молодец, но пусть остаётся там, где есть.
Зачем в браузеры тащить оверхед ??
Не, ну почему бы типы не втащить? Но как не обязательную историю, скажем
А как же параша chain?
уснул к концу
типизация всегда хорошо, жду кода ts станет неотъемлемой часть js
вот объекты неизменяемые это кайф настоящий, остальное такое...
ts никогда не захватит js. Отсутствие типизации менять на говнотипизацию... Жаль что сообщество reasonml не развилось, сейчас бы писали адекватный код...
А вообще поскорее бы wasm развился, и все будут жить счастливо
Есть ReScript
@@allenraizel5538 и PureScript ещё)
осталось найти людей, которые будут поддерживать это все )
Дженерики в языке программирования с динамической типизацией.
Нахзачем?
Ну пусть пропихивают всё. Избавимся от TS и продолжим развивать JS.
Сделал знания не актуальными?) Ну ок.
Чувак, что за «зыс»?😅 this -> «вис»
Microsoft может добавить TypeScritp в свой браузер никого не дожидаясь.
на самом деле он уже есть вот только его не рекоминдуют использывать на продакшенах читай в сторону typescriptServices
@@DevOlegKosarev это транспилер, ничего общего с нативной поддержкой.
На словах "умный дядька" показать шизофреника Вассермана - это сарказм был ?
Считаю не нужно мешать js и ts. Видео как всегда топчик 👍👍
все языки берут что-то из других, так что глупо говорить про "мешать"... если б автор ролика не сказал что МС пытается засунуть ТС в ЖС , то вы бы и не дергались узнав что в ЖС, например, появятся интерфейсы или можно будет указывать тип
Год назад перешел на TS и теперь не представляю, как вообще можно писать на JS…)))
bt ты чтоли?
Возможно, то, что я скажу, прозвучит как глупость, поэтому заранее извиняюсь. Но мне одному ShadowRealm напоминает контексты в React.js?
Только не "тапл" а "тьюпл"
Конечно нужно смешать TypeScript и JavaScript. Это не погубит ни то не другое, но упростит использование преимуществ в связке.
А что это даст? При выполнении этого кода все типы удалятся, это же просто аннотации как и сейчас. По сути своей линтер на максималках
@@izzy7541 Понятно что удаляется и не будут использоваться в рантайме (хотя кто знает, может умный браузер будет для себя делать какие-то выводы), но при этом как минимум на сервере не будет необходимость транслировать код перед запуском.
Тесты и аннотация типов это для общего блага. Хорошие практики из коробки.
@@green.616 Ну то есть вы хотите чтобы транспилировал код нода или браузер? Нода ещё допустим, а в браузере что? Транспилировать на машине клиента?
Это же чушь, заставлять браузер клиента чистить аннотации. Они загрузку страниц в больших проектах по 2 секунды ждать будут?
Хотел послушать. Но вероятно автор считает меня дебилом, пытаясь развлекать идиотскими вставками. Если говорите о серьёзных вещах, тоа делайте это без кривлянья!
Дизлайк.
Измененные копии массива, зашибись, все идет к тому, что js будет жрать терабайты памяти скоро и тормозить как засахаренный ruby и python.
TypeScript это JavaScript у которого получилось.
Чувак, поработай над произношением английского
Не дай Боже type script ещё сам не доработан 😅
Оставьте TS и JS оба одновременно. Дайте людям выбор. TS конечно стал манной небесной когда я впервые его узнал, но на нём разработка усложняется и по времени становится раза в 2-3 дольше, так что пусть лучше будет выбор