Чому JavaScript — перспективна мова програмування? Поради початківцям

Привіт! Мене звати Інна Іващук, і я Senior Software Engineer у GlobalLogic. Впевнена, ви помітили, наскільки зросла кількість веб-продуктів за останні 10 років. Це викликало активний розвиток веб-технологій та основної мови веб-програмування JavaScript, яка дозволяє створювати застосунки та сайти за сучасними стандартами.

Вона вже виходить за межі браузера і застосовується для написання мобільних та десктопних застосунків, веб-серверів тощо. Тож JavaScript має перспективи й залишається однією з найпопулярніших для старту кар’єри в програмуванні. В першу чергу, завдяки своїй універсальності та відносній простоті написання програмних інструкцій, адже для запуску першого рядка коду фахівцю знадобиться тільки браузер.

Детальніше про те, як розвиватись початківцю у JavaScript-напрямку без метушні й штудіювання тони теорії, розповім на прикладах в матеріалі. Ці поради стануть у пригоді спеціалістам, які почали вивчати чи тільки мають намір вивчити цю мову, і не мають комерційного досвіду на проєктах.

Що таке JavaScript

JavaScript — високорівнева мова програмування, яка підтримує імперативний, функціональний, подієво-орієнтований підходи. Вона має динамічну типізацію та застосовується для запису послідовних операцій — «сценаріїв» чи «скриптів». Такі послідовності зазвичай інтерпретуються, а не компілюються, а тому не потребують додаткових програм чи інструментів перетворення в інший рівень кодування.

Кожен веб-застосунок чи сайт побудований з використанням трьох технологій — HTML, CSS та JavaScript. Остання виступає «мозком» розробки й відповідає за інтерактивність й взаємодію з користувачем.

Варто зазначити, що все частіше компанії не обмежуються роботою із JavaScript лише в браузері, а й користуються платформою Node.js, середовищем виконання JavaScript-коду, для написання серверних застосунків. Яскравими прикладами проєктів за такої комбінації є Netflix та PayPal.

Тож багатоплановість застосування — це ще кілька балів до перспективності JavaScript.

Історія довжиною у чверть століття

Як все починалось? 1995 рік. Компанія Netscape Communications прокладає собі стежку у сфері веб-технологій й відвойовує позиції у першого браузера NCSA Mosaic. Веб потребував легкої мови, якою просто програмувати. Так з’явилася ідея скриптової мови Mocha, з якою можна працювати в браузері.

Водночас Sun Microsystems завершувала роботу над своєю мовою програмування Java. І Netscape були готові інтегрувати їхню мову у свій браузер. Але Java призначалася для більш обізнаної в програмуванні аудиторії. Це суперечило призначенню Mocha, що мала стати провідником між Java і користувачами, які потребували її для розробки веб-сайтів.

Після доопрацювання прототип Mocha почали використовувати в Netscape Communicator й він отримав назву LiveScript. А у грудні 1995 року угода між Netscape Communications і Sun була закрита. Так народилася мова JavaScript, а Java служила для створення складних компонентів у браузері.

У 2015-му нова версія мови, ES6, дала JavaScript друге життя — з’явилися нові стандарти, можливість працювати з константами та виконувати багато функцій при скороченому коді. Цей реліз — єдиний, що підтримується всіма браузерами, хоча є й покращені версії.

У 2020 році JavaScript вперше випередила Java, і стала найпопулярнішою мовою програмування. Згідно з рейтингом DOU, у 2021 році цією мовою пишуть 18% розробників, і вона залишається на першому місці.

Динамічність та універсальність — переваги й будова JavaScript

HTML, CSS, JavaScript — це три кити, на яких працюють веб-застосунки. HTML — каркас, CSS — приємне візуальне оформлення (в CSS3 з’явилась можливість реалізовувати й анімації), а JavaScript — логіка, інтерактивність та взаємодія з користувачем. Коли на сторінці ви бачите динамічні елементи, з якими можна взаємодіяти — вмикати аудіо- або відеопрогравач, будувати маршрут на карті тощо — можете бути певні, що не обійшлося без JavaScript. Тож Front-end або JavaScript-інженеру (розробнику) потрібні всі три технології. Але давайте спершу розглянемо детальніше JavaScript.

Основні особливості цієї мови — динамічність, гнучкість роботи з функціями та універсальність. Вона підтримується всіма сучасними браузерами, легко інтегрується з версткою (HTML) та дає змогу налаштувати комунікацію з сервером. Серед інших переваг:

  • Тип даних визначається, коли змінній або константі присвоюється значення.
  • В JavaScript функції можна як виконувати, так і повертати, передавати їх як параметри іншим функціями і привласнювати як значення змінних.
  • Методологія об’єктно-орієнтованого програмування дає змогу представити програму у вигляді сукупності об’єктів.
  • Дозволяє частково перенести бізнес-логіку із сервера на сторону користувача, тобто виконувати код в браузері, що своєю чергою зменшує навантаження на сервери.
  • JavaScript має розвинену інфраструктуру та активну спільноту. Так, веб-розробники можуть працювати з великою кількістю бібліотек і фреймворків як React, Angular і Vue, декількома пакувальниками, як Webpack, Gulp, та допоміжними бібліотеками як Lodash, axios, та іншими.

Недоліки: оновлення, файли та інтерпретація

З одного боку, JavaScript — це просто, оскільки вже в браузері можна побачити результат. З іншого — це постійні оновлення, за якими потрібно слідкувати.

Варто вказати й на декілька обмежень. Основне — це робота з файловою системою, тобто недоступне зчитування файлів. Крім того, JavaScript не підтримує віддалений доступ до системи, а тому мову незручно використовувати для мережевих застосунків.

Особливу увагу потрібно звертати на захист на стороні клієнта, адже деякі недогляди й помилки в коді можуть використати зловмисники.

Крім того, код JavaScript також може по-різному інтерпретуватися браузерами, а старі версії як IE 9 (Internet Explorer 9) взагалі не підтримує. Через те, що деякі браузери зчитують JavaScript-код дещо інакше, сайт чи веб-застосунок може некоректно відображатися чи працювати. Динамічну типізацію також іноді вважають недоліком. Але це можна виправити, використовуючи TypeScript (транспайлер для JavaScript).

Навчатися можна будь-де: рекомендації початківцям

На старті вивчення мов програмування початківців лякає складність. Наприклад, використання компіляторів, як в інших популярних мовах програмування — Java, C#. На відміну від інших, JavaScript не потребує компіляції коду для його виконання в браузері, а тому вважається однією з найпростіших мов для старту. Виглядає все приблизно так: написали код у файлі з розширенням .js й підключили його до файлу з розширенням .html. А потім відкрили в браузері й побачили результат.

Можна починати вчити JavaScript хоч зі школи. А для мотивації — буквально кілька місяців тому до нас на проєкт потрапив 17-річний JS-розробник. Він дуже круто виконує свої завдання, і мені здається, що його чекає чудове майбутнє в цій сфері.

Вчити програмування на JavaScript відносно легко — навіть для того, хто раніше не стикався із розробкою. Багато дій візуалізуються в процесі, написання програм швидке, а обсяг коду менший порівняно з іншими мовами. До того ж, існують бібліотеки й фреймворки для роботи із JavaScript, які дозволяють писати більш гнучкий код. І якщо спочатку JavaScript-інженери працювали виключно з самою мовою, то сьогодні доступні додаткові інструменти.

Для успішного старту в ІТ початківцю бажано отримати базові технічні знання — наприклад, знати, що таке алгоритми та структури даних, й загалом орієнтуватися в галузі. Оскільки це веб-розробка, інженер має розуміти HTML, CSS, JavaScript та обрати один із популярних фреймворків/бібліотек — React, Vue або Angular.

Навчатись можна будь-де — університет, кемпи, самоосвіта. Але якщо є бажання все-таки пройти курс і отримати сертифікат, тоді рекомендую шукати курси або тренінги від IT-компаній, які досить часто абсолютно безкоштовні. Основна мета таких тренінгів — це навчання нових спеціалістів, які потенційно можуть приєднатись до компанії, а не виключно проведення курсів.

Якщо ви обираєте самонавчання, то рекомендую такі платформи як Udemy, Coursera чи той же YouTube — він безкоштовний і переповнений інформацією про те, з чого почати вчити JavaScript. Тут можна знайти й чимало тренінгів для початківців.

Надавати перевагу варто англомовному контенту, оскільки одразу зростає його якість. Чого тільки вартий курс про алгоритми і структури даних CS50, створений в Гарварді.

Студентам і колегам завжди раджу вчити й покращувати англійську мову. Загалом якісного контенту, що пов’язаний із веб-напрямком, та документації англійською набагато більше. Тож зі знанням мови перед вами відкривається більше можливостей в ІТ. Навіть код писати набагато простіше!

Варто зазначити, що програмісту не завадить бути посидючим та вміти концентруватись. Спочатку вам доведеться читати багато технічної літератури й переглядати тренінги, курси, а потім — повторювати на практиці й навчатись, створювати свої прості або складні проєкти. Тому, щоб зберігати мотивацію й зосереджуватись на задачах, важливо розуміти, для чого вам мова JavaScript.

Перспективи JavaScript

Кожна компанія хоче бути представленою ​​в інтернеті й вирізнятися серед інших. Для цього їм потрібен зручний та інтерактивний сайт. Готові шаблони не такі цікаві, тому верстку і наповнення довіряють програмістам. На JavaScript можна писати будь-які веб-застосунки. І це значно збільшує попит на JavaScript-програмістів — пропозицій для них у середньому в чотири рази більше, ніж для Java або 1С — близько 22% відкритих позицій у 2021 році.

З JavaScript працює 60% інженерів, а завдяки зрозумілості й багатоплановості цієї мови, її обирає більшість молодих спеціалістів без комерційного досвіду. Хтось далі заглиблюється у тонкощі веб-розробки, а хтось отримує базові навички в програмуванні та починає вивчати мови на кшталт Java, Python, C++, щоб спробувати свої сили в інших напрямках.

Якщо навіть з часом популярність JavaScript зменшиться, завжди можна вивчити іншу мову програмування і поєднувати інструменти. Розробники — постійні студенти. Наприклад, поява нової бібліотеки вимагає певного часу на її опанування. Тому спеціаліст, котрий засвоїв базові принципи програмування, може швидко опанувати іншу мову. Як кожна професія змінюється й адаптується під потреби суспільства, так і мови програмування вдосконалюються згідно з новими технологічними задачами на ринку.

Більше досвіду — більше знань

Сфера JavaScript-розробки швидко розвивається. За останні п’ять років з’явилось стільки бібліотек й фреймворків, що фізично не вистачає часу все спробувати. Навіть є меми про те, що кожного дня з’являється новий JavaScript-фреймворк. Це підтверджує попит на мову з боку клієнтів та компаній, а отже спеціалісти ще мають, куди розвиватись у професії.

Починати завжди страшно. Проте не варто хвилюватись й судомно 24/7 займатись програмуванням (хоча часом корисно). Ви зможете вивчити цю професію. Варто лише докласти зусилля — вчитися та практикуватися. Рекомендую також для мотивації придумати свій власний проєкт, який можна буде використовувати як місце, де буде поєднуватись пройдена теорія з практикою. Так ви матимете свій власний проєкт, який можна показати на інтерв’ю, а далі — розвиватимете навички на комерційних проєктах та нарощуватимете експертизу, щоб відкривати нові двері в ІТ.

Рухатися кар’єрними сходами можна в різних напрямках. Наприклад, спеціаліст може вирости до Senior або стати Team Lead і займатися організаційними завданнями, допомагаючи команді. Або стати крутим архітектором і проєктувати нові веб-застосунки, враховуючи всі деталі й нюанси.

А у стосунках із JavaScript сценарій базовий — чим більше досвіду, тим більше знань.

👍НравитсяПонравилось12
В избранноеВ избранном3
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Все-таки чому JavaScript, а не TypeScript, наприклад? TS теж активно розвивається, і на ньому можна писати повноцінні веб-додатки.

У 2020 році JavaScript вперше випередила Java, і стала найпопулярнішою мовою програмування. Згідно з рейтингом DOU, у 2021 році цією мовою пишуть 18% розробників, і вона залишається на першому місці.

У цих рейтингах є один маленький нюанс, про який чомусь ніхто не згадує.
Java — мова для бекенда (про GWT вже можна забути). JavaScript — як для фронт-енду, так і для бек-енду (NodeJS). Тому якщо ви хочете писати сайти, зрозуміло, що ви оберете JS, а от якщо серверні додатки — тут можна вибрати і Java, і JS.
Тому якщо скласти рейтинг топ-мов для серверного програмування, не впевнений, що JS буде навіть у п’ятірці.

TypeScript витрачає більше електрики.

Ещё нужно будет 350 тысяч фреймворков выучить...

А чому не радите якихось книжок?

На жаль, досить невелика кількість новачків використовують книги під час навчання. Книги, які однозначну можу рекомендувати — це «Алгоритми і структури даних» Н. Вірт або «Вступ до алгоритмів» Т. Кормен.

JS это лидер по принуждению. Увы, когда у бизнеса встала необходимость делать в браузерах что-то сложнее чем смена цвета кнопки — у инженеров/браузеров все что было это ЖС.
Вся инфраструктура вокруг ЖС это борьба с его проблемами, подпирание костылей новыми костылями. Астанавитесь)
Перестаньте пинать дохлую лошадь)

Ну в этом её перспективность, потому что в обозримом будущем альтернатив не видно. Переписать всю существующую инфраструктуру для web в общем-то овердофига бабла.

За останні п’ять років з’явилось стільки бібліотек й фреймворків, що фізично не вистачає часу все спробувати. Навіть є меми про те, що кожного дня з’являється новий JavaScript-фреймворк.

Ти ба! Навіть меми. Ого!

Програмісти не інженери. Не варто писати оце потворне застосунок.

Senior Software Engineer

Нащо Кожне Слово Писати З Заголовної Букви?

JavaScript, яка дозволяє створювати застосунки та сайти за сучасними стандартами

Тобто без JavaScript за сучасними стандартами не вийде?

Тож JavaScript має перспективи й залишається однією з найпопулярніших для старту кар’єри в програмуванні. В першу чергу, завдяки своїй універсальності та відносній простоті написання програмних інструкцій, адже для запуску першого рядка коду фахівцю знадобиться тільки браузер.

Те що для запуску першого рядка коду фахівцю знадобиться тільки браузер і початк кар’єри в програмуванні погано вʼяжуться. Якийсь несерʼйозний фахівець виходить.

Детальніше про те, як розвиватись початківцю у JavaScript-напрямку без метушні й штудіювання тони теорії, розповім на прикладах в матеріалі.

Коми зайві.

Ці поради стануть у пригоді спеціалістам, які почали вивчати чи тільки мають намір вивчити цю мову, і не мають комерційного досвіду на проєктах.

Хто такі ці спеціалісти?

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

Тобто програма написана на JavaScript виконується ЦП напряму?

Кожен веб-застосунок чи сайт побудований з використанням трьох технологій — HTML, CSS та JavaScript. Остання виступає «мозком» розробки й відповідає за інтерактивність й взаємодію з користувачем.

Не кожен. Мабуть честь бути мозком все ж закріплена за програмістом.

Яскравими прикладами проєктів за такої комбінації є Netflix та PayPal.

Проєкти за такої комбінації.

а Java служила для створення складних компонентів у браузері.

Слугувала.

та виконувати багато функцій при скороченому коді.

Як звучить!

Коли на сторінці ви бачите динамічні елементи, з якими можна взаємодіяти — вмикати аудіо- або відеопрогравач, будувати маршрут на карті тощо — можете бути певні, що не обійшлося без JavaScript.

Аудіо і відео працюють і без JavaScript.

легко інтегрується з версткою (HTML)

Це як розуміти?

Крім того, код JavaScript також може по-різному інтерпретуватися браузерами, а старі версії як IE 9 (Internet Explorer 9) взагалі не підтримує.

JavaScript не підтримує IE 9? Оце так новина.

На старті вивчення мов програмування початківців лякає складність. Наприклад, використання компіляторів, як в інших популярних мовах програмування — Java, C#. На відміну від інших, JavaScript не потребує компіляції коду для його виконання в браузері, а тому вважається однією з найпростіших мов для старту.

F9 в Visual studio це дуже складно? І знову якийсь дивний звʼязок з відсутність компілятора і «а тому вважається однією з найпростіших мов для старту».

Навчатись можна будь-де — університет, кемпи, самоосвіта.

А де самоосвіта? Що таке кемпи?

Кожна компанія хоче бути представленою ​​в інтернеті й вирізнятися серед інших. Для цього їм потрібен зручний та інтерактивний сайт. Готові шаблони не такі цікаві, тому верстку і наповнення довіряють програмістам.

Internet пишеться з заголовної. Чому саме зручний та інтерактивний? Може якийсь інший? Програмісти ж не для верстання. Для верстання верстальщики.

Тобто без JavaScript за сучасними стандартами не вийде?

Динаміки не буде.

Коми зайві.

Ні.

Яка доля сучасних сторінок може працювати без динаміки?

Дякую за такий детальний розбір (корисно вчитись на чужих помилках, але можна і на своїх). І спробую відповісти на деякі із них:

JavaScript не підтримує IE 9

 Схоже, що при публікації зникла частина тексту, так як малось на увазі, що деякі нові синтаксичні конструкції JS не працюють без поліфілів

F9 в Visual studio це дуже складно?

У випадку Java без JRE не обійтись, а також додаткових змінних середовища

Якщо ви обираєте самонавчання, то рекомендую такі платформи як Udemy, Coursera чи той же YouTube

Дані платформи для самонавчання

кемпи?

Безкоштовні внутрішні тренінги, які організовує досить велика кількість ІТ компаній
На рахунок написання «Senior Software Engineer» — це вже питання до англійської мови, чому це у них так прийнято писати :)

що деякі нові синтаксичні конструкції JS не працюють без поліфілів

А деякі взагалі не поліфіляться, наприклад Proxy

Чого я точно нікому б не порадив — це обирати JS як першу мову програмування. Може скластися дуже хибне враження про програмування в цілому. Взагалі, жодну інтерпретовану динамічну мову не порадив би. :) А JS — особливо.

Взагалі, жодну інтерпретовану динамічну мову не порадив би. :)

На дуже перший погляд виглядає розумно... але тільки на перший.
Ті, хто починав програмування ще у маш. кодах — вони наскільки спотворені? Фактично, вони зробили все сучасне програмування, від Fortran і Cobol до LISP :) а машинна мова — вона 1) інтерпретована, 2) динамічна, 3) зі слабкою типізацією (все є біти і байти). Тому що не так?

Я би сказав, що мови, непридатні для первісної освіти, це ті, які
1) Формують погані звички у використанні базових універсальних принципів. В історії було багато таких. Наприклад, Fortran III (і раніше), у якому все через goto і типів майже нема. Такі, де все робиться через глобальні змінні. І так далі.
2) Які мають слабку типізацію. Це особливе розширення аспекту про погані звички: контроль типів критично важливий для розуміння того, що в даних і як з ними працювати. (Приклади як раз для JS і схожих мов: чому платіжна картка 4.149123e+15? Чому число «123qe» визвало відмову від драйвера SQL? Що записано у рядку Çäåñü áûë êîò?)
3) Перевантажені несуттєвими деталями. (Дивимся на Cobol.)
4) Ну і методологічне — які відірвані від типових цікавих тем для учня. (Тут як раз JS «на коні» — майже всі хочуть зробити веб-сторінку, від якої б ахнули друзі.)

А _динамічність_ сама по собі тут якщо і впливає, то не напряму. Он LISP динамічний, але це типово нікому не заважає :)

Наприклад, Fortran III (і раніше), у якому все через goto і типів майже нема.

Може для когось це виглядатиме дивним, але я саме з Фортрана й починав. Коли я вчився в середній школі, інші компілятори буле недоступні. ;) Не кажучи вже про літературу.

А _динамічність_ сама по собі тут якщо і впливає, то не напряму. Он LISP динамічний, але це типово нікому не заважає :)

Мені взагалі не заважає динамічність. Ось C#, який на даний момент є моєю головною мовою, наприклад, має тим dynamic. І він мені взагалі не заважає. За останні десять років я використовував його двічі. Тобто зазвичай я про нього взагалі не згадую, тому не заважає. :D

а машинна мова — вона 1) інтерпретована, 2) динамічна, 3) зі слабкою типізацією (все є біти і байти). Тому що не так?

Наскільки я пам’ятаю (останній раз користувався ASM років тридцять тому), все ж таки не динамічна. Певні типи даних там є. Залежать від архітектури конкретного проца. А не так те, що зараз нею майже ніхто не користується. ;) Якщо вона така гарна, більшість апок розробляли б нею, навіщо взагалі всі ці компайлери, інтерпретатори? Кому вони взагалі потрібні, якщо є така чудова машинна мова? :D

Може для когось це виглядатиме дивним, але я саме з Фортрана й починав.

Ну і я починав з нього. Тому і згадую (хоча це вже був, і у ваші часи теж, Fortran IV, а не III — тут це принципово).

Ось C#, який на даний момент є моєю головною мовою, наприклад, має тим dynamic. І він мені взагалі не заважає.

А чому не заважає? Тому, що в C# доступна статичність, де її можна і треба використовувати, на всіх рівнях (і примітивні типи, і класи). Там, де статичність, вам гарантовані риси рантайму, які можна використати для 100500 різних оптимізацій. А де статичности не треба — там вже dynamic і таке інше.
А якщо у вас не було б такої можливости — як це діється в JS (можна на ходу змінити прототип обʼєкту, навіть самого Object) — то було б негарно, мʼяко кажучи.

За останні десять років я використовував його двічі. Тобто зазвичай я про нього взагалі не згадую, тому не заважає. :D

Ok. Але «під капотом» його багато. Наприклад, у задачі читання-формування JSON він буде.

Наскільки я пам’ятаю (останній раз користувався ASM років тридцять тому), все ж таки не динамічна. Певні типи даних там є. Залежать від архітектури конкретного проца.

І знову — не плутайте. Використання, наприклад, числа в команді ADD — це _сильна_ типізація. Але вона _динамічна_ у сенсі, що у наступній команді той же самий набір бітів буде проінтерпретовано інакше.
Дві вісі — сильність/слабкість і статичність/динамічність — ортогональні.

Ось наприклад задача типу

double *a, *b, *c, *d, *r;
for (i = 0; i < N; i++) {
  if (a[i] > b[i]) { r[i] = c[i]; } else { r[i] = d[i]; }
}
у векторізації перетворюється в те, що
1) порівняння дає вектор _масок_ (всі біти 0 або 1) того ж розміру;
2) вхідні числа (double) маскуються бітовими операціями (v.and, v.andn) і результати обʼєднуються (v.or).

У той же час на рівні хоча б C виконати бітові and, or над числами double — не можна, такі операції просто не дозволені на них. А в асемблері — все можна.

Якщо вона така гарна, більшість апок розробляли б нею, навіщо взагалі всі ці компайлери, інтерпретатори? Кому вони взагалі потрібні, якщо є така чудова машинна мова? :D

Я не казав, що машинна мова гарна :) до кого питання?

Не знаю, що саме Ви намагаєтесь тут довести, мій поінт полягає в тому, що рекомендувати JS як першу мову програмування будь кому, — м’яко кажучи, дуже контроверсійна ідея. Для того, щоб зрозуміти, що варто, а чого не варто робити в JS, потрібна вже певна дорослість, певний досвід роботи з більш розвинутими мовами програмування, певні гарні звички та знайомство з найкращими практиками. Також потрібно дуже чітке розуміння недоліків цієї мови і потрібні певні методи обходу цих недоліків. Тобто освічений та досвідчений розробник може працювати більш-меньш з чим завгодно, навіть з JS. І навіть серед дуже досвідчених розробників, більщість за можливості віддає перевагу іншим мовам програмування. ;)

Новачку краще починати з чогось строго типізованого, хоча б за для того, щоб усвідомити всі переваги компілятора у порівнянні з інтерпретатором. Інакше дуже легко формуються погані звички, а ітогом є тони лайнокоду. :) Тобто стаття містить принаймні одне дуже хибне твердження.

Про деталі можно сперечатися нескінченно, але, вибачте, це не дуже цікаво.

Новачку краще починати з чогось строго типізованого, хоча б за для того, щоб усвідомити всі переваги компілятора у порівнянні з інтерпретатором.

Чтобы понять преимущества нужно набить шишки и там, и там и понять разницу. Поэтому с чего бы новичок не начал, сравнивать свой (ограниченный) опыт ему будет не с чем и никаких преимуществ он понять не в состоянии (как и недостатков, очевидно).

Майже в кожній мові є щось на кшталт dynamic або object. Тобто писати код в найгіршому стилі JS можна більш-меньш будь на чому. І завжди знаходяться люди, які в певний момент починають програмувати в такому стилі. Але навпаки (писати на JS строго типізований код) — ніяк. Тому краще все ж таки починати з чогось строго типізованого. Хоча б з TS, якщо немає іншої альтернативи. ;)

Не знаю, що саме Ви намагаєтесь тут довести, мій поінт полягає в тому, що рекомендувати JS як першу мову програмування будь кому, — м’яко кажучи, дуже контроверсійна ідея.

З цим згоден.

Про деталі можно сперечатися нескінченно, але, вибачте, це не дуже цікаво.

А от саме деталі обгрунтування у вас некоректні, що і доводив.
Ну раз не цікаво — ok, можна зупинитись на цьому.

Мне нравится, что теперь славу самого гавняного языка носит жаба скрипт, а не php. В этом его основная заслуга ящитаю

Если вдруг кому интересна более детальная история появления и развития JS как языка, то рекомендую вот эту беседу www.youtube.com/...​atch?v=vaOLr5TOZgg&t=263s
Артем Кобзарь очень хорошо прошелся по всем вехам, по нынешнему состоянию и по перспективам.

Один з ТікТок трендів — питають порад у IT мільйонерів. Практично всі рекомендують вчити Python і вриватись у DS / ML / AI :)

Чтобы работать на этих миллионеров :-)))

А у грудні 1995 року угода між Netscape Communications і Sun була закрита. Так народилася мова JavaScript, а Java служила для створення складних компонентів у браузері.

У 2015-му нова версія мови, ES6, дала JavaScript друге життя

Back in Time, херасе, 20 лет вперёд, ничего ж до 2015 не происходило)

Угу, некошерно, даже упущен 2006- вершина богохульства для староверов :)
Как и 2010-го — рождение спасителей всия веб.

Скорее бы эта богомерзакая поделка сдохла, вместе со своими нодами/нпм и перестала уродовать мир.

А чому Elm? Я так розумію, Elm тільки для front-end, а JavaScript для бекенда теж (NodeJs)

Одна из самых больших проблем JS — структуры данных. Например, ключом {} может быть только строка. Множеств нет вообще. И т. д.

Одна из самых больших проблем JS — структуры данных. Например, ключом {} может быть только строка. Множеств нет вообще. И т. д.

шта?
i.imgur.com/P6Nxq6i.png

О, это я отстал от жизни и заодно подтвердил закон Каннингема. Буду знать, вдруг придется снова что-то делать на JS.

Впрочем, счастья от этого Map что-то не очень много.
let m = new Map()
m.set(1, 2)
m.get(1)
→ 2 // OK
m.set([3, 4], 5)
m.get([3, 4])
→ undefined // :-(

Ну і все правильно, тому що ви використовуєту літерал масиву. Використання літералу масиву створює новий масив на місці. Ви сетите один масив, а коли використовуєте «get» інший масив. Об’єкти в JavaScript порівнюються за посиланням на область в пам’яті.

const cityPopulationMap = new Map();
const kyivCity = [’Kyiv’, 11]

cityPopulationMap.set(kyivCity, 2884000);
cityPopulationMap.get(kyivCity);

=> 2884000 // works like a charm

Почему оно так работает, ясно. А вот как решить типичную задачу, совсем не ясно.

let first_name = get_first_name();
let last_name = get_last_name();
let existing_user = users_by_full_name.get([last_name, first_name]);
if(existing_user !== undefined) ...

Сделать из lastName и firstName строку? Взять от lastName и firstName хеш?

Сначала думал это написать, но там

userS_by_full_name

так что уже плоской структурой не получится.

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

Цікаво, а є взагалі хоч одна мова програмування, яка за замовчанням порівнює масиви за їхнім змістом? Я щось жодної пригадати не зміг...

спробував python 3 — здається вміє

user@localhost:~> python3
Python 3.8.12 (default, Aug 31 2021, 01:23:42) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = [1,2,3]
>>> b = [1,2,3]
>>> a == b
True
>>> c = [1,2]
>>> a == c
False
>>> id(a)
140291588406464
>>> id(b)
140291587907712
>>> id(c)
140291588395584
>>> d = a
>>> id(d)
140291588406464

Але що до кейса, який розглядається вишче це безсенсовно. Бо python не може створити dictionary індексований масивом. Упс...

Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = [1,2,3]
>>> b = [1,2,3]
>>> a == b
True
>>> dict = {}
>>> dict[a] = "123"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
Тобто автоматично обробити кейс описаний вишче компілятор Python так само не взмозі. Є в мене підозра, що жоден компілятор так не працює, але це — не точно. :)

Він явним чином каже, що ключ має бути hashable, тобто, має мати метод __hash__()
У list цього методу нема.
А для кастомних релізацій треба просто акуратно реалізувати методи __eq__ та __hash__ (у документації описано) і можна ставити його в ключ

Так само і в більшості інших мов. Наприклад в C#. Тре тільки імплементувати Equals() & Hash() і все запрацює. Йшлося про те, що так має працювати «з коробки». ;)

В Питоне для этого используются кортежи: {(1, 2): 3}

Які на відміну від масивів в JS є immutable. Чи не в цьому справа?

Ні, не в цьому.

>>> a = (1,2)
>>> b = (1,2)
>>> id(a), id(b)
(140310789033408, 140310789046720)
>>> a == b
True
>>> a is b
False
>>> c = {}
>>> c[a] = 111
>>> c[b]
111

Immutability дає тільки дозвіл індексувати словники. Порівняння кортежів працює 1:1 з таким же для списків.

Immutability дає тільки дозвіл індексувати словники.

Я саме про це й казав. Читайте тред спочатку. ;)

Читайте тред спочатку. ;)

Читав. Те на що відповідав — що ваше ріторичне питання

Які на відміну від масивів в JS є immutable. Чи не в цьому справа?

не має ніякого відношення до можливости порівняння за змістом: вона одинакова для пари списків і пари кортежів. І тому початковий приклад, переведений на кортежі, працюватиме без проблем у Python.

(Я не думаю, що вам для передачі параметрів у функцію треба _мутабельний_ список/масив.)

І тому початковий приклад, переведений на кортежі, працюватиме без проблем у Python.
Які на відміну від масивів в JS є immutable. Чи не в цьому справа?

Точно читали? Ну, ОК. Тоді більш питань не маю. Дякую.

Точно читали?

Саме так, і зрозумів, що принциповим у треді є сам факт використання складних даних як ключів і їх порівняння за змістом, а не побічні деталі, що тут треба кортеж.

Тоді більш питань не маю. Дякую.

Це добре :)

Ну... по-перше, tuple... По-друге одне діло повідомити про помилку, за якою можна загуглити та знайти рішення. Інша справа, коли ми мовчки проковтнули, а потім видали неочікувану поведінку.

Мій поінт був в тому, що використовувати масиви в якості ключа для dictionary навряд можливо в будь-якій мові програмування. Те, що рішення для будь-якої задачі завжди можно знайти, я досить добре розумію. Дякую. :)

Те, що рішення для будь-якої задачі завжди можно знайти, я досить добре розумію.

Тут проблема у тому, що ми навіть не завжди зможемо зрозуміти, що рішення не працює. Наприклад, Map використовується для кешування. Якщо хтось почне використовувати у якості ключа масив, то це нічого не зламає, воно буде працювати, просто там, де у якості ключа буде масив, там не буде використовуватися кеш. Але це треба ще помітити :)

Ну, використовувати в якості ключа для map/dictionary масив, це на мою думку взагалі дуже контроверсійна ідея. Я навряд зробив би таке в будь-якому випадку. Саме тому в мене виникла думка, що навряд будь-який компілятор дозволить таке робити. Від цієї ідеї просто тхне неоптимальністю, тобто потенційними проблемами з performance. А що як в масиві тисяча елементів? А якщо сто тисяч? А якщо він ще й не immutable, як в JS, ідея виглядає просто вкрай нерозумною.

Tuple інколи використовується у Python. Я не бачу у цьому великої проблеми, сам там робив. Просто мова не дозволяє, ось й думка не виникає. Тобто серіалізувати у строки, я потім рахувати хеш це більш оптимально?

Неоптимальність то взагалі не про JS, як на мене. Якщо в масиві 1000 елементів? А якщо ключ-рядок близько гігабайту? До речі, рядок це теж масив символів. Взагалі, основний сценарій, коли у нас вже працює рішення, де використовується лише строка, наприклад. І у нас виникає потреба додати туди додатковий прапорець. Тобто замість строки виникає tuple з двох елементів, ціле та строка.

Або мемоізація значень функції, ну скільки у нас може бути аргументів? 1000? Вряд чи більше десяти.

Ну технически частично:

const key1 = [1, 2, 3];
const key2 = [1, 2, 3];

const obj = {
  [key1]: "secret"
};

console.log(obj);
console.log(obj[key2]); //secret 
немного более универсально, но с непозволительным извращением:
Array.prototype.toString = function () {
  return JSON.stringify(this);
};

const key1 = [1, 2, 3, [4,5]];
const key2 = [1, 2, 3, [4,5]];

const obj = {
  [key1]: "secret"
};

console.log(obj);
console.log(obj[key2]); //secret 

Хотя бы C++: std::vector{1, 2} == std::vector{1, 2}

Це не компайлер так працює, а стандартна бібліотека. std:vector — це не масив в класичному розумінні слова. Це клас, тобто те, як працює оператор == визначається кодом стандартного класу. Приклад — трохи некоректний. ;)

Цікаво. Дякую. Спробую запам’ятати. Це вочевидь повинно означати, що порівняння досить великих масивів в цих мовах може бути досить недешевою операцією. Бо вочевидь робиться через порівняння кожного елемента масива. На мій смак набагато краще коли такі речі можна робити тільки в явному вигляді. Таке...

Це вочевидь повинно означати, що порівняння досить великих масивів в цих мовах може бути досить недешевою операцією.

Python: `a == b` - порівняння за змістом, `a is b` - порівняння за посиланням. Коли останнього досить, воно напряму і викликається.

На мій смак набагато краще коли такі речі можна робити тільки в явному вигляді.

Тут і є явний вигляд (для того, кто знає мову хоч трохи).

досить великих масивів в цих мовах може бути досить недешевою операцією

Звідки там великі масиви? Чому ви їх скрізь бачите? Зазвичай для великих масивів є окремі типи на кшталт numpy arrays у Python. У функціональних мовах взагалі не масиви, а списки (list). Це лише у JS незрозумілий то ли бык, толи тур.

Map это связь 1:1. Так что никак, если только это не кэш со списком тезок. Потому только обходом массива аж через целый users.filter() :)

Ключем може бути строка або символ, множини є
developer.mozilla.org/...​ects/Set?retiredLocale=uk

Так часто надо не строку и не символ, а кортеж.

Угу, а самому написать 20 строчек или взять готовую 100500 реализаций непосильная же задача была, что проблема «одна из самых больших»? Всегда всего нет- классов «не было», а как добавили ключевое слово поверх конструктора- о, все уже есть :)

Куча boilerplate — как сформировать литерал Map из имеющихся ключей и значений?

Существующий Object, который почти работает, как надо, но постоянно пытается поставить подножку.

let [html, head, meta1, meta2, ..._] = document.querySelectorAll("*«)
let m = {}
m[html] = «html»
m[head] = «head»
m[meta1] = «meta1»
m[meta2] = «meta2»

m[html] // «html»
m[meta1] // «meta2»

Если уж очень хочется...

let [html, head, meta1, meta2] = document.querySelectorAll("*");

const map = new Map([
  [html, "html"],
  [head, "head"],
  [meta1, "meta1"],
  [meta2, "meta2"]
]);
JavaScript перспективна мова програмування

WAT???

Коронавірус також дуже популярний, але ж ви не прагнете стати його носієм?

JavaScript наскільки «заразний», що навіть в Java 8 з’явились парадигми функціонального програмування, наприклад Stream API :)
Я за підхід, коли інженер знає хоча б дві різних мови програмування)

aspnet core слизан с популярных node,js веб фреймворков.

Сам JavaScript це приблизно з десяток діалектів, а ще є фреймворки, які фактично змінюють ЖабаСкрипт до невпізнаваності.

Стрім апі в жабі, до речі, в більшості випадків є злом. Так, він скорочує код. Ціною нечитабельності. Є випадки, коли саме стрім апі робить код гарним — але це навіть не 10% від того хламу, який на ньому пишуть «бо так модно».

JavaScript наскільки «заразний», що навіть в Java 8 з’явились парадигми функціонального програмування, наприклад Stream API :)

Який звʼязок? Їх могли взяти із 100500 інших мов. Он C# значно ближче.

Я за підхід, коли інженер знає хоча б дві різних мови програмування)

Але JS не мусить входити до їх складу :)

Ну... JavaScript я бы не относил к функциональным языкам программирования. Да, там можно объявить анонимную функцию, а где её сейчас нельзя объявить?

JavaScript я бы не относил к функциональным языкам программирования.

Сейчас жёсткой границы нет. Но да, если в основных конструкциях процедурность, то это процедурный язык. Чисто функциональные это такие, где процедурности нет вообще, ну кроме необходимости сериализации общения с внешней средой (знаменитая монада IO;)) С этой точки зрения даже LISP (а тем более Erlang) это плебс от функциональности.

Да, там можно объявить анонимную функцию, а где её сейчас нельзя объявить?

Важна не анонимность, а наличие функций как first-class citizen с возможностью создавать, передавать созданное и творить замыкания (и, вследствие, карринг). Где нет — ну хоть в C :)
Но это таки 1/4 от движения к ФП.

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

Для меня функциональные языки это типизация, это паттерн-матчинг и алгебраическая теория типов, это отсутствие циклов, это запрет мутабельности.

На самом деле всё это вторично. Основная идея — это чтобы в языке надо было описывать, _что_ надо получить, а не _как_. Мы работаем с данными и описываем, какими правилами/формулами эти данные вычислять, и оформляем эти правила в виде функциональных зависимостей результатов от входных данных.
Всё остальное вытекает из этого, в частности:
— Типизация: чем точнее мы определим типы каждого данного, тем легче нам будет с ним работать, разбираясь, какие действия допустимы (не складывать число со строкой), какие диапазоны значений реальны и т.п.
— Иммутабельность: всякие «x=x+1» означают, что это новое x — это другое x.
— Паттерн-матчинг: комфортная и программно верифицируемая версия развилки условия в математическом виде (декларативный вид условия вместо процедурного позволяет автоматизацию над ним).
И прочая и прочая.
Но в реализации мы всё равно имеем процедурное исполнение в компьютере (с которым надо иметь интерфейсы) и широкий спектр средств начиная от самых процедурных до самых абстрактных :)
А то, что вы говорите... ну да, это высокий уровень. Но мы в теме, где даже простые foreach/map/filter/reduce уже «функциональное» потому что оно не записывается через цикл :))

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

Первое — боюсь, у вас тут даже Евклида реализовать не получится :) а как иначе доказывать основные свойства?
Ну разве что записать обоснование, почему тут вызов допустим. Но по-моему именно _структурная_ сложность тут немного побоку. Должно быть достаточно показать любую монотонно убывающую характеристику от аргументов.
Доказательство как аргумент — такого не видел, есть ссылка на букварь?

Основная идея — это чтобы в языке надо было описывать, _что_ надо получить, а не _как_

Это ты перепутал декларативные языки с функциональными.
В декларативных (вроде пролога, скл) нужно действительно описывать что нужно получить, а не как. Суть фунциональных языков в попытке описать фрактальную структуру мира, принципы самоподобия. Поэтому те области, которые хорошо ложатся на фракталы (а они почти везде ибо это основа из основ) там хорошо применима функциональщина.

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

Это ты перепутал декларативные языки с функциональными.
В декларативных (вроде пролога, скл) нужно действительно описывать что нужно получить, а не как.

Нет, декларативные делают ещё один шаг дальше: они вообще не описывают метод получения результата, они описывают требования к результату. Prolog — как раз такой случай.
SQL — он где-то посредине, он может быть переложен собственно в операции реляционного исчисления и оттуда уже исполнен. Но вкусность не в этом, а в том, как он в какой-то из этих форм анализируется и оптимизируется.
Хотя грань здесь, безусловно, не жёсткая.

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

:))
По-моему, это уже сильно дальше. Но прикольно :)

Нет, декларативные делают ещё один шаг дальше: они вообще не описывают метод получения результата, они описывают требования к результату. Prolog — как раз такой случай.
SQL — он где-то посредине, он может быть переложен собственно в операции реляционного исчисления и оттуда уже исполнен.

Опять же, это философия. Prolog как раз задаёт жёсткую схему выполнения, которой можно управлять отсечениями и другими конструкциями. Там какой-либо вариабельности у интерпретатора особо и нетъ.

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

Основная идея — это чтобы в языке надо было описывать, _что_ надо получить, а не _как_.

Ну... тут больше философии и субъективной точки зрения.

Но мы в теме, где даже простые foreach/map/filter/reduce уже «функциональное» потому что оно не записывается через цикл :))

foreach да, а остальное легко записывается через рекурсию, если у нас рекурсивное представление списка.

Первое — боюсь, у вас тут даже Евклида реализовать не получится

Еквклид реализовывается элементарно, потому что у нас есть структурное уменьшение рекурсии по обоим аргументам (они оба строго меньше, чем предыдущие значения). А вот написать вычисление элементов какой-нить сиракузской последовательности мы не сможем, по крайней мере пока не представим конструктивное доказательство того, что это вычисление заканчивается (гипотеза Коллаца).

Доказательство как аргумент — такого не видел, есть ссылка на букварь?

Любой язык с зависимыми типами, например, лично я курю Agda. Например, достаточно тривиальное определение вектора и получение n-го элемента из него:

data 𝕍 {ℓ} (A : Set ℓ) : ℕ → Set ℓ where   
  [] : 𝕍 A 0                               
  _::_ : {n : ℕ} → A → 𝕍 A n → 𝕍 A (suc n) 

nth𝕍 : ∀ {ℓ}{A : Set ℓ}{m : ℕ} → (n : ℕ) → n < m ≡ tt → 𝕍 A m → A     
nth𝕍 0 _ (x :: _) = x                                                  
nth𝕍 (suc n) p (_ :: xs) = nth𝕍 n p xs                                 
nth𝕍 (suc n) () []                                                     
nth𝕍 0 () []               

соответственно функция nth𝕍 принимает среди обязательных параметров некоторое число n, доказательство того, что n < m, и вектор элементов типа A длины m, а на выходе получает n-ый элемент вектора (tt это значение True из 𝔹).

Пример взят из книги
Verified Functional Programming in Agda (ACM Books)

Не наскільки а настільки. Настільки що навіть... А можна знати дві однакові мови? Якщо вони однакові, то виходить що людина все таки знає одну мову.

Дякую за статтю, для тих хто ще обирає мову мабуть буде корисно.
Але було б краще розкрити ідеологію JS. Бо причина його бурного росту не тільки в тому, що замкнулось коло між пропозицією розробників, яка веде до збільшення проектів на JS.
Хейтери дуже часто не розуміють, або недооцінюють, потужність JS який пішов іншим шляхом. І замість об’єктів в ньому з’явились прототипи, вони інші але потужні, якщо зрозуміти що це таке і як працює. Дивна поведінка з доступом до змінних за межами функції дозволяє вирішувати багато практичних задач набагато легше, лаконічніше і елегантніше ніж в інших мовах. Асинхронність вже була з коробки ще тоді, коли інші мови навіть мріяти про неї не могли, а велика кількість варіантів роботи з асинхронністю, це є лише етапи еволюції, в той час як в інших мовах все часто залишається в замороженому стані. По суті, пакетний менеджер в node.js створив революцію, коли легкість створення модулів та продумані прості правила semver вибухово створили купу різного оточення, драйверів та сахару на вколо мови.
Тому трохи не розумію як люди можуть ненавидіти киць, коли вони їх не готували і не вживали )))

Про JS можна розповідати довго, як і про його ідеологію) А краще один раз спробувати. щоб зрозуміти, що це «смачно» )))

Хейтери дуже часто не розуміють, або недооцінюють, потужність JS який пішов іншим шляхом

С одной стороны — вы правы что не любят JS те, кто не до конца понимают его и не умеют использовать его достоинтсва что бы делать на нем элегантные решения.
Но с другой: в реальных проектах я почему-то не видел этих елегантных решений! Наоборот — по моим ощущениям JavaScript код для понимания намного сложнее. Начиная от того, что глядя на функцию сложно представить что она ожидает на вход! Потом функции внутри функций, замыкания, колбеки ... возможно если долго с этим работать то все просто и прозрачно.
У меня предвзятое мнение — я начинал с ООП языков и мне сложно переучиваться. Но молодежь, которая приходит на фронтенд и знает только JS — точно так же теряется в чужом коде!
На мой взляд беда JavaScript как раз в его излишней гибкости. Если ООП языки сокрашают сложность путем строгой типизации и инкапсуляции, если они «навязывают» девелоперам ограничения — то в JavaScript чем больше кода — тем больше он усложняется! А что бы писать код, который не будет сложным — нужно уметь правильно пользоваться JavaScript и иметь опыт!.
В этом JS чем-то напоминает С++: там то же можно все, включая программы в одну строку из непонятных символов. Но освоить правильное использование — не проще, чем научиться жонглировать. А без этого будут утечки памяти и указатели «в никуда».

Потужність — фізичне поняття: робота, виконана за одиницю часу. Що таке потужний JavaScript і потужні обʼєкти? Вони швидко перетворюють електрику?

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

І шо?

високорівнева мова програмування, яка підтримує імперативний, функціональний, подієво-орієнтований підходи

Так наче ж криво-боко, але підтримує ООП, хоч без модифікаторів доступу))

Мультипарадигменна мова програмування все ж таки :)

Почему? ООП с натяжкой + прототипное наследование (спасибо Self)? Так это вроде одного поля ягоды, пусть и семантика отличается

Сродни проституции: этому дала, этому дала и этому дала...

Але з модифікаторами свідомості — вони потрібні щоб розуміти той код коли він вже написаний (і працює звісно ж не так, як задумав автор, а як задумав — він не скаже)

Ви будете здивовані, якщо виділите час ознайомитись з тим що увійшло в специфікацію 2022 року.

Private модификатор есть уже. Записывается через #

але ж то експериментальна фіча, із всіма витікаючими наслідками

У JS один недостаток — JS.
Язык спроектированный для простых скриптов чуть ли не за пару дней, с ошибками в спецификации(которые давно уже стали фичами) — типичная жертва взрывного роста этих ваших интернетов.

ЖС виграв у всіх інших скриптових мов для браузерів через те, що його впровадив netskape

А «вибух» стався сильно пізніше

Если бы не взрыв, то js так и остался бы языком для небольших скриптов в браузере.

скоріше витік лайна

Выиграл у VB.Script? По причине того, что VB.Script поддерживал только IE?

І у JScript

По причині, що нетскейп був трошки кращий у впровадженні іновацій
Ну просто зірки так склались

Ну это просто диалекты одного языка, там даже стандарты одинаковые поддерживались.

конструктивне зауваження. якщо повністю ігнорувати 20+ років розвитку цієї мови.

Без слез на «развитие» смотреть нельзя. Тайпскрипты с кофискриптами и аналогами появились наверное исключительно из-за прогрессивности js и непрерывного его улучшения.

TypeScript з’явився як інструмент для роботи з тим самим JS. І створений він для вирішення доволі конкретних проблеми, а не тому що хтось ненавидів JS та хотів писати хоч на чомусь, аби не на JS.

JS — це сьогодення, як до ньго не відносся. В нього є свої плюси та свої мінуси, як в будь-якої іншої мови.

TypeScript з’явився як інструмент для роботи з тим самим JS. І створений він для вирішення доволі конкретних проблеми

А я то не знал. Спасибо что просветил.

JS — це сьогодення, як до ньго не відносся. В нього є свої плюси та свої мінуси, як в будь-якої іншої мови.

Кэп очевидность, спасибо за констатацию очевидности. Опять таки, без этого твоего замечания я бы и не сообразил, что js один из самых массовых языков программирования.

айпскрипты с кофискриптами и аналогами появились наверное исключительно из-за прогрессивности js и непрерывного его улучшения.

Нет, он появлился для толпы свитчеров с «прогрессивных» ЯП, которые в JS, «написанного за 3 дня», не умели, а адаптироваться надо было быстро.

ну да, система типов тайпскрипта аналогична системам типов «прогрессивных» языках, он джавы до гоу и не ломает мозги при первом знакомстве. Или нет?
А может проблема в том, что JS изначально не был предназначен для проектов в миллионы LOC и шаг вправо-влево ведет к «пропало все»? И это таки реальная проблема которая достала в том числе и «свитчера» Хейлсберга настолько, что он чуть ли самостоятельно первую версию TS написал?

По этой логике любой ЯП без явной типизации уже не предназначен для «проектов в миллионы LOC». Это зона ответственности инструментов для документирования, к ЯП это не имеет отношения.

шаг вправо-влево ведет к «пропало все»

Это баги свитчеров, в олдов JS ничего не «пропадает», а там где надо уточнить есть инструменты документирования.

И это таки реальная проблема которая достала в том числе и «свитчера»

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

что он чуть ли самостоятельно первую версию TS написал?

А должны были кто написать? Боги? И спустить человечеству как преподношение? )

По этой логике любой ЯП без явной типизации уже не предназначен для «проектов в миллионы LOC».

разве что в вашем воображении. Язык без явной типизации может быть компилируемым(и как следствие, иметь лучшие код анализ/рефакторинг тулы), иметь нормальную инкапсуляцию и модульность, нормальную базовую библиотеку со старта, банально многопоточность с примитивами синхронизации и тд и тп. Имха, отсутсвие типизации это скорее минус чем плюс на проектах выше 100к LOC, но это холивар.

Это баги свитчеров, в олдов JS ничего не «пропадает», а там где надо уточнить есть инструменты документирования.

Тут прекрасно все. Давай как то из волшебных эльфий как то ближе к реалиям опустимся.
1. Возьмем какой то средний проект, эдак года на 3 и девов на 15. Со средним бюджетом. По каким то причинам, его решили пилить на js. Внезапно(вне зависимости от языка программирования), 15 «олдов» с 5 летним опытом нанять не получится. Миллион причин, от бюджета до психологии(членомеряние и конфликты в таком коллективе неизбежно, не говоря уже о рутинных задачах, которые никто не хочет делать).
2. Надо брать людей с меньшим опытом.
3. Люди всегда факапят. А не «олды» — чаще. Если инструменты или процессы делают так, что их факапы не идут дальше локального енва, это решает проблему огромного числа факапов. Люди просто вынуждены делать «как надо». Под тайм прессингом, ктото будет читать доку и следовать ей, если надо просто решить проблему СРОЧНО? Серьезно? Код ревью частично это решает, но и код ревьюверы могут быть под тайм прессингом или просто заняты своими задачами.

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

Я чот подозреваю что ты не загуглил кто такой Хейлсберг.

Язык без явной типизации может быть компилируемым

JS и есть компилируемый язык без явной типизации, просто компиляция отложенная и в runtime, не очень понятно в чем поинт.

иметь нормальную инкапсуляцию и модульность

А кто сказал что такое «нормальная» инкапсуляция? В JS она нормальная, как и модульность. Но не в то, ни в другое вникать не хотят, потому что на «не такая». Вам как семантику на уровне ЯП для каждой фичи не дай, то все — по вашему ее нет.

нормальную базовую библиотеку со старта

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

банально многопоточность с примитивами синхронизации

Как зайцу стоп сигнал. Накой ему многопоточность с дедлоками и самовыпил, если один их потоков навернется? Типичный кейс- как и ожидалось, отсутствие геморроя, считается недостатком. Может и mem_alloc в JS всунем, а?
Всегда в этом месте хочется услышать что такое Вы собрались там делать, для чего нужно активные межпоточное взаимодействие с синхронизацией средствами ОС с минимальными задержками? Да, чего JS (надеюсь не за фронт хоть речь) не хватает, так это семафоров с мютексами ммм))

Имха, отсутсвие типизации это скорее минус чем плюс на проектах выше 100к LOC, но это холивар.

Сколько бы не было строк, весь код это композиция маленьких кусков, т.е функций и модулей. Если код читаем на 1000к без типов, то и на 100к он будет читаем, только и того что внешние интерфейсы модулей лучше бы таки задокументировать, а то время идет, люди меняются, по крайней мере для сложных кейсов с множеством опций или вариантов вызова. И в принципе, d.ts файлы тоже как вариант норм для всего экспортируемого, только вот сам TS в коде и его бюрократическая дотошность с дженериками в три слоя на любителя, а любители это преимущественно свитчеры.

«олдов» с 5 летним опытом

если 5 лет это со времени как первую строчку на ЯП написал, то это не олд :)
TS это не упрощение входа в кодинг, это упрощение входа для свитчеров. С TS можно так выстрелить в ногу, что пока заставишь проект собираться, то борода отрастет. И это если нет ошибок в типах в импортируемых модулях, а они есть, и там опять пляски с переопределением. Мазохизм...

Если инструменты или процессы делают так, что их факапы не идут дальше локального енва

TS это инструмент, не дающий квадратное всунуть в круглое (на самом деле квадратное с левыми засечками не дает всунуть в квадратное с левыми засечками на 1мм шире). Он не гарантирует правильную работу кода вообще (как и типы в рантайм), а что гарантирует- тесты. А тесты вряд ли будут работать если в самому коде таки всунули квадратное в круглое. Потому тратить время лучше на тесты, нежели на прослойку.

Под тайм прессингом, ктото будет читать доку и следовать ей, если надо просто решить проблему СРОЧНО?

Инструменты документирования это не сам внешний файл, это те же аннотации JSDoc, которые понимает IDE и по которых потом уже можно сгенерировать файл доков для людей, с интерфейсами, комметами и примерами- ctrl+q на функции и читай.
К тому же, на прошлые годы IDE серьезно улучшили хинты для кода вообще без аннотаций. Простые кейсы отлавливает на ура. Зачем там излишняя дотошность ценой ручного аннотирования всего подряд непонятно. Основное и сложное описал и достаточно.

Я чот подозреваю что ты не загуглил кто такой Хейлсберг.

ко-автор ряда типизируемых языков- или по твоему это божество, постулаты которого не оспоримы? Есть куча разных авторов ЯП. У человека десятилетия мир был одним, и он подвел под свое мировоззрение то, что в него не вписывалось.

JS и есть компилируемый язык без явной типизации, просто компиляция отложенная и в runtime, не очень понятно в чем поинт.

В том, что ты не понимаешь разницу между компиляцией и интерпретацией. Дальше не читал.

В том, что ты не понимаешь разницу между компиляцией и интерпретацией. Дальше не читал.

Ясненько. А ты точно ее понимаешь? :) А ну-ка, будь добр, подскажи как там называется штука в движке JS, которая оптимизирует-деоптимизирует код js после первичной интерпретации AST в байткод? Не компилятор ли часом? Никак не могу прочитать... вот тут v8.dev/docs/turbofan

TurboFan is one of V8’s optimizing compilers

перечитай с выражением, что там написано. И правильно выдели болдом нужные слова.

И правильно выдели болдом нужные слова.

Ну пока что никак... может просветишь мну?

могу, но не хочу. Там на поверхности, прилагательное, которое радикально меняет смысл существительного.

то прилагательное ни на что не влияет. Если компилятор после интерпретатора есть, то он есть. Хотя, может ты им подскажешь, как обойтись без промежуточной штуки на пути компилированию исходников динамического ЯП на ходу, чтобы тебя не смущало слово «оптимизирующий».

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

Java в твоем определении какой, небось же компилируемый? Так вот, JS ровно тоже. Разница только в том, когда эта компиляция происходит, и сохраняется ли байт код на диск. Если бы код на Java передавались на целевую платформу в виде текста, и компилировались там непосредственно перед началом выполнения без промежуточного сохранения байткода на диск, стал бы Java интерпретируемым? Или же само наличие в нем компилятора позволяет ей относиться к компилируемым ЯП, вне зависимости где и когда она происходит? Что там, что там компиляция в байт код. Если конечно совсем придираться, то это не то, ни другое в его каноническом виде.

Если же фазы компиляции и выполнения не отделимы(или же сложно отделимы друг от друга), то язык называется интерпретируемым.

У вас конечно обоих позиции сомнительные, но тут я поддержу Мозгового. Причина очень проста: его подход практичен с точки зрения производительности и ограничений рантайма, а твой — нет.
Да, в принципе все языки, в которых есть eval(), можно считать интерпретируемыми. В JS он есть. В C++ нет (построение полного eval() значило бы тащить за собой весь GCC/Clang/etc.) Но в теме про свойства JS в плане защищённости от ошибок программиста, поддержки IDE, статического анализатор и т.п. это неважно. А важно — 1) какие ограничения язык выставляет на действия в нём, в плане контроля действий и защиты от ошибок, 2) какие возможности по оптимизации того, что можно оптимизировать в принципе (вплоть до машкода).
И вот второе имеется на достаточно высоком уровне, а первое хотя бы детектируется рантаймом (даже где он не имеет права ограничить всякие хаки).

А делить по возможности отделения фаз... ну пусть где-то язык просто парсят до AST, где-от переводят в LLVM IR... всё равно надо собрать под целевую платформу (и точить под это на всех уровнях), так что это тоже неизбежная фаза деплоймента.
Повторюсь: твоё определение непрактично.

Повторюсь: твоё определение непрактично

я с попкорном обсужу любые другие определения компилируемых и интерпретируемых языков программирования

Да, в принципе все языки, в которых есть eval(), можно считать интерпретируемыми.

Можно. В том же C# есть аналог eval, который кроет eval как бык овцу, но тем не менее, C# почемуто считается компилируемым.

А делить по возможности отделения фаз... ну пусть где-то язык просто парсят до AST, где-от переводят в LLVM IR... всё равно надо собрать под целевую платформу (и точить под это на всех уровнях), так что это тоже неизбежная фаза деплоймента.

Повторюсь, явное отделение стадии компиляции(ок, построения ast) от остальных дает некислые преимущества для тулзов, которые помогают работать с кодом.
Ну и той, если мое наколенное определение отличия компилируемых языков от интерпретируемых, давайте ваше, обсудим.

В том же C# есть аналог eval, который кроет eval как бык овцу, но тем не менее, C# почемуто считается компилируемым.

Если вы про Expression, там не парсятся исходники, там используется уже далеко ушедшее внутреннее представление.
Как раз по вашему определению и получается, что интерпретации тут нет.

Ну и той, если мое наколенное определение отличия компилируемых языков от интерпретируемых, давайте ваше, обсудим.

Предлагаю позицию по эффективности между вариантами «всё парсится заново из исходника» до «доведено до машинных команд при максимуме укладки на типы данных процессора», по шкале например от 0 до 100%.

Если вы про Expression, там не парсятся исходники, там используется уже далеко ушедшее внутреннее представление.

Нет, я не про Expression а про Reflection.

Предлагаю позицию по эффективности между вариантами «всё парсится заново из исходника» до «доведено до машинных команд при максимуме укладки на типы данных процессора», по шкале например от 0 до 100%.

Эффективность чего? Исполняемого кода? ИМХА в 99 случаях из 100 это ни на что не влияет.

Нет, я не про Expression а про Reflection.

Я бы не назвал его «аналогом eval»... хотя тут по сути неважно.

Эффективность чего? Исполняемого кода? ИМХА в 99 случаях из 100 это ни на что не влияет.

Это другой вопрос, но таки влияет — иначе зачем бы у JS вместо полной интерпретации делали JIT движки? И почему тогда работы на C++, Java, etc. не уменьшается? ;)

Я бы не назвал его «аналогом eval»... хотя тут по сути неважно.

Это в десятки раз улучшенный eval. Но суть то сохранена: генерация кода в рантайме(в смысле в reflection и это тоже можно делать).

Это другой вопрос, но таки влияет

Скажем так: по сравнению с проблемами девелопмента, вызванными в том числе и интерпретацией кода в JS, проблемы перфоманса вторичны, с моей точки зрения.

Скажем так: по сравнению с проблемами девелопмента, вызванными в том числе и интерпретацией кода в JS, проблемы перфоманса вторичны, с моей точки зрения.

Ну это 1) не совсем так там где есть подпорки типа TS, 2) временно, пока не прижало отсутствие роста ресурсов компьютеров.
Но ближайшие лет 5 ожидаем потрясений.

1) не совсем так там где есть подпорки типа TS

Для триллионов строк написанного кода, который надо сапортить и развивать не меняя глобально, подпорки TS остаются фантазиями. Я бы даже сказал что TS — отдельный язык программирования, как C++ отличается от С(а в первых версиях ЕМНИП С++ сначала транслировался в С).

2) временно, пока не прижало отсутствие роста ресурсов компьютеров.

Веб асембли пойдут в массы и там хоть на ассемблере :)

до слез. Ты так ничо и не понял.

Давайте вкратце расскажу, чтобы вы не ругались.
После парсинга JS в АСТ, а из АСТ-а в специфичный виртуальной машине байткод происходит первичная интерпретация этого байткода и генерируется профиль.
Далее, происходит компиляция baseline (или low-tier) компилятором (в хроме это Sparkplug, о нем можно почитать тут — v8.dev/blog/sparkplug),
а «горячие методы» из профиля компилируются оптимизирующим (он же high-tier) компилятором с применением всех возможных оптимизаций.

Вкратце, так.

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

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

Хм, и кто это там такое обсуждал? Мы там обсуждали, что JS не является интерпретируемым языком уже лет 15 как, и что его можно считать компилируемым языком с отложенной компиляцией, т.е с нюансами реализации, потому он не являеться его канонической формой.
Для любителей применять школьные определения:

к группе интерпретируемых относят языки, в которых операторы программы друг за другом отдельно транслируются и сразу выполняются (интерпретируются)[3] с помощью специальной программы-интерпретатора (что противопоставляется[1] компилируемым языкам, в которых все операторы программы заранее оттранслированы в объектный код[3])

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

что его можно считать компилируемым языком с отложенной компиляцией, т.е с нюансами реализации,

function f (i) {   if(i===1){     console.log('aaaaa');   }   else     bullshit } f(1);
В общем-то «нюансы реализации» — это вот такие прекрасные примеры исполняемого кода.
Как там в определении? «ВСЕ операторы программы ЗАРАНЕЕ оттранслированы....».... Я вот и вижу как ВСЕ и как ЗАРАНЕЕ в примере.
BTW, в моем «школьном» определении явно написано про «ЗАРАНЕЕ» и не совсем явно подразумевается «ВСЕ». Но такое.

вот такие прекрасные примеры исполняемого кода.

Ну и? Что с этого? С таким же успехом это может быть код на любом ЯП, если компиляция отложенная до загрузки исходников в виртуальную машину. Или сорсы на С++ каким то магическим образом не дают написать в них бред, если его не компилировать сразу, а только непосредственно перед исполнением файла?
Если код валиден и его можно скомпилировать, то он компилируется и перекомпилируется- это все что нам нужно знать.
Выполнив

node --print-bytecode test.js
для кода
'use strict';

function testFunction(x){
  console.log(x++);
}

testFunction(10);
что же мы увидим?
[generated bytecode for function: testFunction (0x01d97f3b7261 <SharedFunctionInfo testFunction>)]
Bytecode length: 25
Parameter count 2
Register count 3
Frame size 24
OSR nesting level: 0
Bytecode Age: 0
   46 S> 000001D97F3B7C16 @    0 : 21 00 00          LdaGlobal [0], [0]
         000001D97F3B7C19 @    3 : c2                Star1 
   54 E> 000001D97F3B7C1A @    4 : 2d f9 01 02       LdaNamedProperty r1, [1], [2]
         000001D97F3B7C1E @    8 : c3                Star0 
         000001D97F3B7C1F @    9 : 0b 03             Ldar a0
         000001D97F3B7C21 @   11 : 74 04             ToNumeric [4]
         000001D97F3B7C23 @   13 : c1                Star2 
         000001D97F3B7C24 @   14 : 50 04             Inc [4]
         000001D97F3B7C26 @   16 : 18 03             Star a0
   54 E> 000001D97F3B7C28 @   18 : 5d fa f9 f8 05    CallProperty1 r0, r1, r2, [5]
         000001D97F3B7C2D @   23 : 0e                LdaUndefined 
   65 S> 000001D97F3B7C2E @   24 : a8                Return 
Constant pool (size = 2)
Это часом там не байт код или похоже, что команды по очереди интерпретируются и выполняются по PC указателю?
Как там в определении?

Так же в определении написано " в которых операторы программы друг за другом отдельно транслируются и сразу выполняются«. Этому определению 100 лет уже, когда еще не было таких сложных движков.
Если уж программа в несколько заходов таки компилируется на уровне функций в байткод и потом уже только это байт код может выполнятся, то это уже никак нельзя назвать «отдельной трансляцией команд».
Теоретически, вряд ли что то помешало сохранить байткод после проходов всех компиляторов в файл и уже его передавать целевой платформе на выполнение. Вот только его размерчик будет внушительный, как и время максимально «глубокой» компиляции.

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

Только вот в «любом ЯП» сначала компилируется ЗАРАНЕЕ и ВЕСЬ и затем исполняется.
Можно сколько угодно тянуть сову на глобус, но в приведенном тобой определении компиляции написано, что код должен компилироваться ЗАРАНЕЕ и ВЕСЬ. Байт код это прекрасно, в тех же C#/Java код компилируется не в инструкции процессора, а в промежуточный байт код, но ЗАРАНЕЕ и ВЕСЬ. Поэтому это компилируемые языки, а JS — нет, даже при наличии оптимизирующего компилятора и каком то промежуточном байт коде, в который интерпретируется только исполняемая часть кода.

Повторюсь. Заранее, не заранее — код обрабатывает КОМПИЛЯТОР. В определении интерпретируемого языка четко написано его метод исполнения- трансляция и выполнение команд по отдельности. Когда выполняется компиляция неважно, она выполняется и она компиляция ведь, не интерпретация.
Ты бы Java не назвал интерпретируемой, если бы ее компилятор не имел возможности сохранять скомпилированный код на диск а сразу передавал его на исполнение виртуальной машине? Или таки назвал бы? Потому парирование словом ЗАРАНЕЕ и ВЕСЬ бессмысленно. Ни одно, ни другое не влияет на факт компиляции кода, а не его интерпретации. Пусть оно не совсем классическая форма компилятора, и не все признаки совпадают с определением со времен ламповых мейнфреймов, когда они были простыми и имели четкие границы, но ЯП куда ближе к компилируемым по существенных признаках- наличие байткода и компиляция на уровне функций/модулей.

а JS — нет, даже при наличии оптимизирующего компилятора

В JS и базовый, и оптимизирующий это все компиляторы, нету там нынче в основных звеньях интерпретатора.

Повторюсь. Заранее, не заранее — код обрабатывает КОМПИЛЯТОР.

Не ЗАРАНЕЕ и не ВЕСЬ.

(что противопоставляется[1] компилируемым языкам, в которых все операторы программы заранее оттранслированы в объектный код[3])

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

Называй JS как угодно, но он не попадает под приведенное тобою же определение компилируемых языков.

Называй JS как угодно, но он не попадает под приведенное тобою же определение интерпретируемых языков :), особенно при отсутствии интерпретатора и наличия компиляторов. По хорошему, тут надо особая промежуточная категория, которая все же ближе к компилируемым. Нельзя назвать что то интерпретируемым, если там нет интерпретатора- логично же?

Это — реальная проблема языка, которая непосредственно следует из его истории.

Если линтеры не отловят, то отловят тесты, которые хоть в каком то виде должны быть в коммерческой разработке. Ты же не пишешь в блокноте, IDE подчеркнет возможные косяки, этого в 99% случаев достаточно. Ну и TS же запилен для таких, кто привык к «спокойствию», когда над ним всегда висит надзиратель, и бьёт его по руках за каждый чих, когда он сидит не по ГОСТу- ну там надзиратель можно мне поднять руку? Можно- пиши в бланке запрос на поднятие руки, опиши время, вектор и скорость, я рассмотрю и одобрю, тогда операция поднятия руки наверняка будет безошибочной, и ты не воткнешь ею себе в глаз... :)

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

Я соглашусь с тем, что категоризация компилируемый/интерпретируемый несколько подустарела и JS гдет посредине.

Если линтеры не отловят, то отловят тесты, которые хоть в карм то виде должны быть в коммерческой разработке.

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

Ну и TS же запилен для таких, кто привык к «спокойствию», когда над ним всегда висит надзиратель, и бьёт его по руках за каждый чих, когда он сидит не по ГОСТу.

Так и надо, инструмент(и процесс) должен минимизировать human factor и не давать сделать какую нить полную херню. Даже если ОЧЕНЬ надо, времени нет, начальство нервничает и так далее по списку.

Я соглашусь с тем, что категоризация компилируемый/интерпретируемый несколько подустарела и JS гдет посредине.

Ну наконец-то мы за сутки пришли практически к консенсусу :)

В том числе и без линтером(и с линтером

IDE уже сама по себе имеет базовый линтер, потому делает предположение о типах и структурах по мере сил. Она конечно иногда ошибается, но зато это бесплатно- ты не тратишь время на дополнительное декларирование структуры или типизации для несущественных мест, в основном приватных, а ограничиваешься только публичными/экспортируемыми.
Ну а с включенными внешними линтерами в пайплайнах CI тебе придется разбираться с варнингами, иначе ж не пропустит, в том числе по кодстайлу. Так что и на чистом JS разработка полна надзирателей нынче. Это не написал в блокноте и выкатил в прод, а там хопа — undefined is not a function :)

Она конечно иногда ошибается, но зато это бесплатно- ты не тратишь время на дополнительное декларирование структуры или типизации для несущественных мест, в основном приватных, а ограничиваешься только публичными/экспортируемыми.

А потом надо сделать рефакторинг, и там где для компилируемых языков ИДЕ все делает сама и не ошибается никогда. Что, в случае банальных переименований, экстракции методов и прочего невозможного автоматически в мире JS, с лихвой окупает пару минут на тайпинг типов десятка переменных. И даже тестов ранать не надо.

Ну а с включенными внешними линтерами в пайплайнах CI тебе придется разбираться с варнингами, иначе ж не пропустит, в том числе по кодстайлу. Так что и на чистом JS разработка полна надзирателей нынче. Это не написал в блокноте и выкатил в прод, а там хопа — undefined is not a function :)

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

«олдов» с 5 летним опытом

Це сарказм, правда?

я даже скобочки поставил, чтобы вопросов не было.

По этой логике любой ЯП без явной типизации уже не предназначен для «проектов в миллионы LOC»

И это верно. Потому что чем меньше возможностей статической проверки (компиляторами, линтерами...) с гарантией результата (что в рантайме ничего не будет искорёжено), тем легче это верифицировать — начиная от банальной визуальной верификации и кончая математическим доказательством верности.

Разделение статической и динамической типизации, слабой и сильной должно быть явным. Где-то это явный тип, например, dynamic. Где-то, наоборот, явное объявление типа для статики и отсутствие такового для динамики. Но если в языке нет возможности статической типизации, «проекты в миллионы LOC» будут страдать от сотен тысяч невыявленных багов.

JS плох не возможностью слабой и динамической типизаций, не прототипами и т.п., а отсутствием возможности сделать сильную и статическую, запретить смену прототипа, и ещё 100500 вещей в рантайме вплоть до убийства Object (хорошая шутка для node-интерпретатора, «я что-то нажал и всё исчезло»).

Это баги свитчеров, в олдов JS ничего не «пропадает», а там где надо уточнить есть инструменты документирования.

Ну да, «не-свитчеры» это те, кто сам в себе воспитал внутренний интерпретатор, который всё это проверяет на ходу ;)
Только вот где взять таких киборгов;)

Инструмент решает свою задачу, но это не означает, что без него у других «реальные проблемы» и все без него это Г.

Ну у тех, кто пишет однострочный onclick, проблемы таки нет :)

конструктивне зауваження. якщо повністю ігнорувати 20+ років розвитку цієї мови.

, і тих мегатон лайна, що за ті 20+ років накодили, а ситуація «дешевше переписати з нуля» є константою, та не залежить від кількості вкладених тисяч людино-годин.

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

20 лет бурного развития как-бы намекают на кучу архитектурных просчётов-недочётов при создании и костыли для их исправления и проблемы с обратной совместимостью.

Тим не менш, він цілком придатний до використання і за 20 років суттєво змінився. Так працює еволюція — клієнтський веб ніхто не сприймав всерйоз, але він поступово став дуже важливим в нашому житті.

Із TypeScript можна писати значно складніші скрипти.

Это уже совершенно другая история, ts хорош.

JS можно и нужно ненавидеть. Но количество пакетов в нпм нельзя игнорировать. Там есть уже все на любой вкус и выбор. Каличному го еще лет 10 догонять по развитости.

На самом деле оно все так всегда и происходит. С был придуман для решения конкретных инженерных проблем и пошел в массы. Для борьюы с его недостатками придумали С++ и он тоже пошел в массы. Затем его стали улучшать, превратив в монстра. А академический паскаль не стал массовым, хотя и была пара хороших попыток.
Просто с js вышло внезапнее и как то эпичней, шоле. Язык для простеньких скриптов применяют везде, со всеми приятными последствиями.

но с ts таки сейчас попроще жить.

Раджу вам поцікавитись історією створення мови, а не просто повторювати мантру «спроектований за декілька днів».

youtu.be/nLcF2Av2D5k

Раджу пересмотреть свое же видео, особенно внимательно с 2:30 до 3:30.

Ну якщо, ви не можете спочатку продивитись відео, і охопити весь шлях становлення мови, а судите по одній хвилині, і біжите одразу в коменти із своїми висновками, то далі немає сенсу говорити.

Я говорил про начальное проектирование языка за пару дней, а не про «весь путь его развития». Не надо подменять понятия.

ошибками в спецификации

Интересно. Можно пример?

VBScript там тоже был на старте, но как-то не зашёл.
В JS что-то было всё таки.

поддержка нетскейпа, а затем и всеми остальными браузерами. Можно еще и сервелат вспомнить, с (по большому счету) единственным но фатальным недостатком.

Сервелат думав конкурувати з флешем, а не з жс

Швидкість і фічі жс в той час виглядали дуже погано

Сервелат думав конкурувати з флешем, а не з жс

я к тому, что фатальным недостатком сервелата, с моей точки зрения, была монобраузерность. В полную противоположность js с самого начала.
Написал и ie6 вспомнил, свят-свят :). Нынешние "олды js"© даже не в курсе, что это такое :)

А він не був плагіном, як флеш?
Бо я пам’ятаю, що були якісь длл під хром для нього
docs.microsoft.com/...​ht-not-work-google-chrome
І він доречі ще існує

ЖС в той час також був сильно різний під кожен браузер

ie6 — був норм
Сумісність між ним, 7 і фоксом — ось що було гємором

Сумісність між ним, 7 і фоксом — ось що було гємором

я именно про это. Когда шло требование ie6 compatibility, то все, можно вешаться. Емнип jquery тогда еще не было.

він не був плагіном, як флеш?

емнип он стал плагином, но слишком поздно и слишком криво :)

jquery тогда еще не было

був і інші були
Але викручувались через жс тільки в крайньому випадку

Навіть девтулзи під 6 портували

Дякую, хороша стаття, але TypeScript заслуговує на ширшу згадку.

Наприклад, стосовно «ES6 підтримується усіма браузерами, а пізніші версії — не факт», то тут дуже добре допоможе TypeScript, бо код може бути написаний хоч на ES2020, а вже транспіляцію можна робити хоч в JavaScript ES6 (рекомендується писати ES2015), хоч у пізніші версії.

тайпскрипт здесь вообще непричем, транспилятор переваривает на входе как код с тайпскрипта, так и обычный js

то тут дуже добре допоможе TypeScript

Вся разработка [на фронте] идет через трансляторы+поллифилы так что TS тут таки не при чем.

Подписаться на комментарии