Чистий JavaScript: повернення до джерел

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Привіт, я Дмитро Попов, сертифікований Software Engineer. Десять років працюю з JavaScript. Поговорімо про первозданний JavaScript, JS до 2015. JS, який знають піонери й про який, на жаль, не чуло молоде покоління.

JavaScript (JS) — інтерпретована (або JIT) скриптова мова зі слабкою системою типів й динамічною типізацією. Розробив JS Брендан Ейх в 1995 році для браузера Netscape Navigator, нібито за 10 днів. Спершу JS називався LiveScript, а вже потім JavaScript.

Спочатку JavaScript не був таким потужним, як сьогодні, і в основному використовувався для анімацій і чуда, відомого на той час, як Dynamic HTML — попередника DOM. Зараз JavaScript вже вийшов за межі скриптової мови і є мовою загального призначення. Ви можете створювати десктопні та серверні застосунки за допомогою Node.js.

Мова JavaScript стандартизована як ECMAScript, стандартом ECMA-262. Оскільки основне джерело з JavaScript, а саме MDN (Mozilla), посилається на ECMA-262, можна сказати, що JavaScript (JS) — це поточне втілення ECMAScript (ES).

Головні особливості JS:

  • First-class functions.
  • Closure.
  • Scope.
  • Object literals.
  • Implicit boxing.

Вже маючи своє уявлення про філософію JS, я перечитав книгу Дугласа Крокфорда JavaScript: The Good parts, яка вийшла в далекому 2008 році. Колись мене ця книга зацікавила з двох основних причин:

1. Інтригуюча назва. Які ж хороші риси JS? Враховуючи, що навіть у 2012, коли я вивчав JS, ця мова була надзвичайно контроверсійною, навіть для пітоністів.

2. В книзі використані так званні railroad-діаграми для опису граматики. Це дуже цікавий візуальний спосіб опису синтаксису мови програмування. Railroad-діаграми візуальні, на відміну від форми Бекуса-Наура для опису контекстно-вільних граматик. Дуглас Крокфорд є автором JSON, граматику якого він описав у формі МакКімена (спрощена форма Бекуса-Наура).

Дуглас пише в книзі про ECMAScript 3, який вийшов в 1999. ECMAScript 4 відмінили, ECMAScript 5 (2009) додав незначні зміни, зокрема, strict mode (use strict). ES6 (ECMAScript 2015) ввів класи, модулі та інше.

Що я можу відмітити з його слів. JavaScript набрав свою популярність завдяки браузерам. Всі інші спроби типу Java аплети, ActionScript, чи Dart чомусь не прижилися. Хто знає, чому?

Зараз можна програмувати браузер за допомогою JavaScript та WebAssembly. JS, як пише Дуглас Крокфорд, був написаний в поспіху і має багато поганих частин. Думаю, що про поспіх — це міф. JS написаний за стільки, за скільки написаний. Якщо копнути, то виявиться, що C++ та Java також були «на колінці» створені :)

На думку Дугласа DOM API у 2008 було настільки погане, що навіть важко було написати книжку DOM: The Good parts, бо їх там як кіт наплакав. У якому стані зараз DOM API, то інша тема. В книзі «Елегантний JavaScript» також згадано про проблеми з DOM.

Думаю, таку негативну думку сформувала історія навколо Dynamic HTML, XHTML, а також сумісність між Microsoft Internet Explorer та іншими браузерами. Крім того, розгляньмо властивість ChildNodes, яку мають елементні вузли в DOM. Ця властивість містить об’єкт, подібний до масиву, з властивістю length та властивостями, позначеними числами для доступу до дочірніх вузлів. Але це екземпляр типу NodeList, а не реальний JS масив, тому він не має таких методів, як slice і map.

Крім того, немає способу створити новий вузол і негайно додати до нього дітей або атрибутів. Замість цього ви повинні спочатку створити його, а потім додати дочірні елементи та атрибути один за одним, викликаючи побічні ефекти.

Дуглас пише:

JavaScript побудований на деяких дуже хороших і дуже поганих ідеях. Дуже хороші ідеї містять функції, слабку типізацію, динамічні об’єкти та літеральні об’єкти. Погані ідеї містять модель програмування, засновану на глобальних змінних. JavaScript — це перша лямбда-мова, яка стала мейнстрімом. У глибині душі JavaScript має більше спільного з Lisp і Scheme, ніж з Java. Це Lisp в одязі С. Що робить JavaScript надзвичайно потужною мовою.

Тут Дуглас Крокфорд дуже влучно підкреслює, що в JS функції є first class objects, тобто вони можуть бути записані в змінні, передані як аргументи, та повернені як значення, включно зі змиканням (closure), яке було введено в мові Lisp, та каруванням (curring) як в лямбда-численні. Тут C, C++, Java «пасуть задніх», бо саме JavaScript зробив популярними анонімні функції, IIFE, функції першого класу та функції вищих порядків. Інші мови пізніше додали деякі можливості щодо лямбда-функцій.

Далі, для всіх любителів TypeScript, які вважають що це нині неписаний стандарт, Дуглас пише, що слабка типізація в JS є перевагою. Плюсом, а не мінусом. Питання з типами стане ще цікавішим, коли Дуглас дійде до розмови про літеральні об’єкти, які він вважає хорошою рисою.

Якщо використовувати лінтер (JSLint розробив Дуглас Крокфорд), оператор typeof, й тестувати гарно код, тоді навіщо нам строга типізація? Тим паче якщо вона структурна й без автоматичного виведення типів? Для захисту від дурня? А ви впевнені, що дурень пропише типи нормально?

Варто зауважити, що лінтер може виділити subset (підмножину мови), але TypeScript це superset (надмножина), тобто TS додає нові синтаксичні конструкції з певною семантикою.

JS — неохайна мова, яка містить в собі елегантну кращу мову

Так писав Дуглас Крокфорд. TypeScript навпаки робить обгортку над JS. Далі в книзі йдеться про те, як реалізувати метод Object.create та Array.isArray, які зараз вже додані в мову. Автор також пише, що потрібно ввести block scope в JS, що було виконано.

Дуглас також обговорює прототипне наслідування.

Object.getPrototypeOf повертає прототип об’єкта.

Коли створюється об’єкт функції, конструктор функції, який створює об’єкт функції, запускає такий код:

this.prototype = {constructor: this};

Тобто:

function User(name){

this.name = name;

}

const john = new User("John");

console.log(john.constructor===User); //true

console.log(john.__proto__ === User.prototype); //true

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

Є так звана проблема номінальної та структурної перевірки типів. Це вірно, бо відсутність множинного наслідування та ведення «інтерфейсів» якраз розв’язує набридливе питання типів, а не перевикористання методів.

Відсутність множинного наслідування також зумовлене Diamond problem.

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

Дуглас пише:

Багато функцій JavaScript були запозичені з інших мов. Синтаксис походить від Java, функції — зі Scheme, а прототипне успадкування — від Self. Регулярні вирази JavaScript були запозичені з Perl.

Коротко кажучи, хороші сторони ECMAScript3 (JS) за Дугласом Крокфордом — це:

  • Функції як об’єкти першого класу.
  • Динамічні об’єкти з прототипним успадкуванням.
  • Літерали об’єктів і літерали масивів.

Як я розумію, наявність літеральних об’єктів унеможливлює номінальну перевірку типів.

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

Автор, звичайно, жаліється на те, що повертає typeof оператор. Він також критикує застосування стандарту IEEE 754, який веде до 0.2 + 0.1 ≠ 0.3. Він критикує такі штуки як with, eval, == (loose comparison).

У 2018 році, через десять років після публікації JavaScript:The Good parts, Дуглас Крокфорд написав іншу книгу — How JavaScript Works (2018). Де він виступив різко проти використання класів в JS, точніше проти їхньої імітації.

Він також пропонував здихатися ключового слова this та типу null, бо вони створюють більше проблем, ніж користі. Коротше, конфузять. Якщо наявність одразу null та undefined конфузять, уявіть, що в TS є undefined, null, void, never, unknown, any.

Дуглас також проти прямого використання ключового слова new, яке веде до правила, що всі функції-конструктори мають писатися з великої літери, щоб їх випадково не викликали без new, просто як звичайну функцію. А ще він проти використання генераторів, які ввели в ES6, бо в JS це можна зробити краще через змикання (closure).

function counter_constructor() { 

let counter = 0;

 function up() { 

    counter += 1;

    return counter;

 } 

 function down() { 

   counter -= 1;

   return counter;

 } 

    return Object.freeze({ up, down });

 } 

Об’єкт, який повертається, заморожений. Об’єкт не може бути пошкоджений. Об’єкт має стан. Змінна лічильника є приватною властивістю об’єкта. До неї можна отримати доступ лише за допомогою методів. І нам не потрібно користуватися ключовим словом this.

Насправді мінуси в JS, які описує Дуглас Крокфорд, або легко усуваються, або є незначними в порівнянні з плюсами мови JavaScript. JavaScript такий гнучкий, що навіть відома книга Structure and Interpretation of Computer Programs в 2022 році вийшла у JavaScript-версії, хоча в оригіналі вона була чи то на Lisp, чи Scheme. До речі, Lisp не мав статичної типізації, але мав garbage collector. На відміну від JS, який має інфіксну нотацію, Lisp мав префіксну нотацію, схожу на польську нотацію.

Щодо TypeScript, то він зайняв свою нішу. Але величезні набори типів додають випадкову складність (accidental complexity), тобто складність, яка безпосередньо не розв’язує нашу задачу, хоча може давати певні переваги. Тут варто знайти баланс. Крім того, TS не є класичною ООП мовою, бо перейняв прототипне наслідування з JS.

JavaScript (ECMAScript) визначає колекцію вбудованих об’єктів. Ці вбудовані об’єкти містять глобальний об’єкт (global, window); об’єкти, які є фундаментальними для семантики виконання мови, включно з Object, Function, Boolean, Symbol. Та різні об’єкти Error; об’єкти, які представляють і маніпулюють числовими значеннями, включно з Math, Number і Date. Об’єкти обробки тексту String і RegExp. Об’єкти, які є індексованими колекціями значень, включно з Array і дев’ятьма різними типами типізованих масивів, усі елементи яких мають конкретне представлення числових даних. Колекції з ключем, включно з об’єктами Map і Set. Об’єкти, що підтримують структуровані дані, включно з об’єктами JSON, ArrayBuffer, SharedArrayBuffer і DataView. Об’єкти для generator functions та Promise та об’єкти відображення, включно з Proxy та Reflect.

Структура JavaScript:

  1. statement and expression in JS
  2. const, var, let (hoisting, temporary dead zone, immutability)
  3. data type (Primitive types: number, bigint, string, boolean, null, undefined, symbol; Reference types: object, (array, function)), typeof operator
  4. arithmetic operations (+,-,*,/,%). Math object, Math.random();
  5. logic operations (&&, ||, !)
  6. Conditional statement (if, switch), ternary operator
  7. Loops (for, while, do-while, forEach, map, for-of, for-in, ...)
  8. function declaration and function expression, arrow function, IIFE, anonymous function
  9. constructor function, this, .prototype, .__proto__, isPrototypeOf
  10. class, super(), extends, this, getter, setter, instanceof
  11. Promises, async, await, timers, event loop, micro and macro tasks
  12. Generators, new Proxy
  13. new Date, RegExp, JSON.stringify, parseInt, parseFloat, template literals

Методи масиву: reverse, sort, splice, forEach, map, flatMap, filter, find, reducer (sum array), some, includes, concat, length, Array.isArray.

Методи string: padStart, indexOf, substring, length, trim, toUpperCase, replace, replaceAll, match, search.

Методи number: toFixed, toPrecision, toString. Number.isInteger.

Методи об’єкта: Object.seal, .create, .is, .defineProperty, .keys, .values, .entries, .freeze, .hasOwnProperty, .assign.

Методи функцій: bind, call, apply.

Методи new Map, Set: has, add, remove and many others methods from set theory.

Декілька GoF дизайнів ООП-патернів в JS:

const singleton = {text:"hello"}.

Уявляєте, в JS singleton можна реалізувати простим літеральним об’єктом. В багатьох мовах просто немає літеральних об’єктів.

const factory = Object.

Так, Object — це фабрика (factory method), він віддає вам різні типи об’єктів залежно від параметрів. new Object(1), new Object("string«).

Патерн Ітератор:

function* generator(){ 

yield 1;

yield 2;

yield 3;

} 

const gen = generator(); //Генеруємо ітератор console.log(gen.next().value) //1 

Шаблон Прототип в JS, реалізований «з коробки»:

const obj2 = Object.create(obj1);

Патерн Проксі в JS "з коробки" 

const target = { message:"text" };

const handler = { get(target){ 

return "hello";

} };

const proxy = new Proxy(target, handler);

proxy.message // hello 

Патерн (шаблон) Chain of responsibility можна реалізувати з допомогою new Promise. Просто будуєте ланцюжок промісів.

new Promise((resolve, reject) => { }).then(result => { return new Promise();

}).catch(error => { });

Шаблон Observer реалізований в стейт-менеджерах типу Redux, також в RxJS. Він реалізований і в document.addEventListener та EventEmitter.

const evt = new Event("look", { bubbles: true, cancelable: false });

document.dispatchEvent(evt);

Джерела про JS, які згадуються в статті:

👍ПодобаєтьсяСподобалось15
До обраногоВ обраному7
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 набрав свою популярність завдяки браузерам. Всі інші спроби типу Java аплети, ActionScript, чи Dart чомусь не прижилися. Хто знає, чому?

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

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

Поэтому JS просто быстрее и удобнее развивался, а когда его функционал полностью перекрыл всех конкурентов, стал стабильно работать на разных платформах (разных браузеров), на конкурентов забили.

Dart еще неизвестно, просто не взлетел ибо не смог предложить что-то прям кардинально лучше. Люди часто пользуются вещами не потому что они лучше, а потому что привыкли, потому что популярные. И уходить от популярного продукта приходится в основном когда уже совсем (как это случилось с flash — сидели на нем до последнего)

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

Десять років працюю з JavaScript. Поговорімо про первозданний JavaScript, JS до 2015.

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

Google Maps, например, запустили в феврале 2005. Думаете он сильно отличался от текущего? Его как-то написали и запустили до книги Крокфорда за 4 года до этого.

Пишу js с 2002 года, спрашивайте могу рассказать, если вспомню.

ИТ миру очень сильно не повезло, что пришлось создавать стандарт «простого скриптового языка для браузера» в сжатые сроки и принимать с ошибками в спецификации. А затем взрывной рост веба сделал из «простого скриптового языка с ошибками в спецификации, не правившимися десятилетия» монстра. Спасибо Хейлсбергу, он этот ад в чувство привел. Уж сколько на его счету удачных языков программирования, но typescript мне видится вершиной: и обратная совместимость с миллиардами строк говнокода, и все лучшее что можно было взять из предыдущего опыта.

Не повезло, так не повезло. Що ж ми тепер бідненькі будемо робити? Треба валити з цього «IT-міра», поки не піздно.

JS з кожною новою версією стає все краще. Це повільний, але чудовий процес.

Що ж ми тепер бідненькі будемо робити?

Смирится с тем что у нас есть и писать все новое на typescript с включенной опцией strict=true

JavaScript (JS) — інтерпретована (або JIT) скриптова мова

JIT підвезли в JS тільки в 2008 році з виходом Google Chrome на новому двіжку розробленому в датському офісі Гугл, до цього ним там і не пахло. Та і по факту, JIT — це більше про сам компілятор/транслятор, ніж про мову. Зараз JIT є навіть в PHP.

Мова JavaScript стандартизована як ECMAScript, стандартом ECMA-262. Оскільки основне джерело з JavaScript, а саме MDN (Mozilla), посилається на ECMA-262, можна сказати, що JavaScript (JS) — це поточне втілення ECMAScript (ES).

Тут ви щось все разом змішали. ECMAScript (або ECMA-262) — це стандарт, який розробляється Ecma International. JavaScript — це конкретна реалізація ECMA-262, як і, наприклад, ActionScript (колись була така мова на якій писали анімашки для флеш). У Екми є багато інших стандартів, які замплементовані в вигляді різних мов програмування та іншого. Наприклад, стандарт ECMA-404 — це JSON. Ще є стандарти для C#, C++, Dart і тд.

ECMAScript 4 відмінили

Не відмінили, а покинули, бо тоді розробка стандарту велася 2-ма колективами — одним з Майкрософт та іншим під керівництвом Брендана Айка. І коли містер Айк почав тонути в своїх амбіціях (новий стандарт був не сумісний з попередньою версією і мав додати величезну кількість нових фіч, які так чи інакше потім добавили в JS Harmony), то прийшлось робити фінт ушами і прикинутись, що нічого не сталося, і все почалося заново. І перед тим як поносити МС, то хочу напам’ятати, що саме вони добавили в JS XMLHttpRequest, а потім і async/await (і багато іншого).

ECMAScript 5 (2009) додав незначні зміни, зокрема, strict mode (use strict).

Ну якби саме в цьому стандарті добавили вбудовану підтримку JSON, без якої JS нікому і не потрібен був би (не без того, що тоді все було на XML).

Дуглас пише

Я читав книгу дєдушки Дугласа більше 10 років тому і, якщо чесно, то дідуля явно частенько забуває випити таблєтки. Наприклад, він в своїй писанині розпедалював, що бітові операції в JS — зло. Чисто по надуманих причинах, серед яких він вказав low performance, бо типу ці операції виконуються не на залізу, а якось по іншому. Тоді ще Майкрософт тільки виклали в опенсорс свою Чакру, тому я зразу зайшов і подивився, як транслятор опрацьовує такі операції і, як виявилось, то все транслюється та виконується в звичайному С++ коді. Тому дідулі віри немає і книга його сильно overhyped.

Дальше не читав, бо сильно багато ось таких неточностей, що вбивають весь інтерес.

Не вбивають, напиши краще ще, цей комент не гірший за статтю! Я аж не повірив шо на доу

Блін про датський офіс цікаво, це ж блін ледь не весь успіх гуглхрома на цьому стоїть, вчасно щоб Трампу морду цим витирати

Я ж кажу, я продивився статтю і там дальше просто якийсь потік свідомості. Вибіркові напів-цитати Крокфорда, відсилки до Фленагана, рефлексія на TS, якась незрозуміла «структура JavaScript» (структура JS починається з такої штуки як Realms, якщо хтось не читав специфікацію). Автор навіть приплів паттерни «банди чотирьох». Коли у матеріалі немає звʼязності, то це важко коментувати.

Мене просто насторожило цитування Крокфорда. Дідуля заробив собі хорошу репутацію придумавши JSON, а потім похоронив її своїми «the good parts».

А про датський офіс, то це тільки половина історії. Інженери Гугл були і є активними контрибюторами в WebKit від Еппл. ВебКіт це конкретно та частина, яка відповідає за рендеринг HTML та CSS. От в один момент вони форкнули проект, назвали його Blink і почали педалити код під себе. Паралельно з цим найняли одного датчанина, щоб він очолив розробку новітнього JavaScript двіжка, який би доповнив Blink і працював на новій набираючій обороти мульти-процесорній архітектурі. Датчанин цей — не простий дядька. Не пам’ятаю імені, але до Гугла він працював в Sun (кантора, де придумали Джаву і таку парашу як Соляріс), де займався розробкою віртуальної машини для Джава (він створив HotSpot). Саме він завіз в JVM JIT-компіляцію і багато інших плюшок, які потім перекочували в JS двіжок. Двіжок получився дуже крутим і потужним і тому його назвали V8, в честь винайденого в Франції автомобільного двигуна V8. Коли це все діло зібрали до купи, то зʼявився Google Chrome. Потім цей датчанин був замічений за створенням мови програмування Дарт та багатьох інших, але не таких відомих плюшок в гуглі.

ну я думаю гоф було аби проілюструвати шо типу vanillajs може в шаблони, мені сподобалось в принципі, хай сам уже відповідає

ну через пару років буде як ти ) будь лагідним

Паралельно з цим найняли одного датчанина, щоб він очолив розробку новітнього JavaScript двіжка, який би доповнив Blink

Уж извини, тут у человека, который жил и работал в веб-разработке в это время, немного не сошлось.
Все было немного не так:
V8 первая версия — июль 2008
Chrome первая версия — сентябрь 2008
Blink первая версия — 2013 год (5 лет разницы)

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

blog.chromium.org/...​-engine-for-chromium.html
Вот момент расхождения.

lists.webkit.org/...​ev/2013-April/024388.html
А тут WebKit, предлагают очиститься так как Chromium ушел.

Насколько Blink отличается от WebKit я незнаю, не изучал. Apple и Google и другие работали в одной кодовой базе. И с 2008 по 2013 они ни про какие Blink незнали.

WebKit is a lightweight yet powerful rendering engine that emerged out of KHTML in 2001. Its flexibility, performance and thoughtful design made it the obvious choice for Chromium’s rendering engine back when we started. Thanks to the hard work by all in the community, WebKit has thrived and kept pace with the web platform’s growing capabilities since then.

Как-то это не похоже на то что написано сверху Вами.

Я все ще не бачу, що ви хочете мені доказати?

Хром і Хроміум не зʼявилися за один день. До цього Гугл багато років комітив в репо ВебКіта від Епл і паралельно декілька років розробляв В8. Потім це все зліпили в купу і получився Хром і зразу ж зарелізився Хроміум проект (названий в честь «старшого» Хрома, але без фірмових плюшок гугла). А ще через деякий час Гугл зарелізив свій форк ВебКіта під назвою Блінк. Що тут не ясно?

Я вважаю, що праці Дугласа Крокфорда чудові. Як я й написав в статті, багато з його пропозицій було реалізовано в JS.
Він показав сильні сторони JS, а не просто намагався зліпити ще одну Java.

А щодо цього:

Мова JavaScript стандартизована як ECMAScript, стандартом ECMA-262.

Воно сказано абсолютно коректно. Якщо ви любити специфікації, тоді прочитайте перші сторінки специфікації ECMA-262.

На практиці ECMA-262 та ECMAScript утотожнюють часто (зокрема Д.Фленеган), але формально це не точно.

Я вважаю, що праці Дугласа Крокфорда чудові.

Ну, не чудові, а просто терпимі на той час, коли вони писались. Я вже приводив приклад маразму з бітовими операціями в його «працях». Є такі речі, які без такого функціоналу просто не написати.

Вважаю, що читати Крокфорда в 2025 просто шкідливо. Туди ж і Фленагана. Не розумію, як після книг Кайла Сімсона та Ніколаса Закаса, хтось в здоровому глузді ще дивиться в сторону «дідів» з нульових.

І так, я читав специфікацію ECMA-262, щоб краще розібратись, як працює мова. Був навіть час, коли активно підтримував комунікацію з учасниками комітету TC39, бо сильно хотів продвинути свої власні пропоузали, але не зрослось.

Ну якби саме в цьому стандарті добавили вбудовану підтримку JSON, без якої JS нікому і не потрібен був би (не без того, що тоді все було на XML).

Веб-разработчики тех лет пользовались JSON и JSONP за долго до появления стандартного JSON.parse. Вообще когда мы стали пользоваться этим методом, многие были удивлены его ограничениями, но смирились.
Например было непонятно что не стандартного в таком json: {hello: ’world’}

Про що ви говорити? XML був де-факто стандартом практично всі нульові. JSON обійшов XML з «бумом API» десь на рубежі 10-х, але XML продовжував тримати позиції завдяки всяким SOAP-ам та іншим RPC-протоколам, що на ньому будувались. Перехід в мобільний інтернет остаточно вбив XML, як дефолтний АПІ формат, але це вже було після 2010-го року.

Я говорю о том, что мы с 2004 по 2010 пользовались XML довольно мало. С появлением и распространениям AJAX, я лично активно использовал и даже запилил библиотеку в 2005 из разряда indirect AJAX frameworks. Так вот по AJAX мы гоняли в основном не XML в эти годы. Он же неудобен. В основном использовали JSON через eval или выгружая их как строки через серверный язык. XML оставался прерогативой SOAP, это да. А обычный фронт и бек общались через JSON.

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

Перехід в мобільний інтернет остаточно вбив XML

А почему мобильные приложения стали использовать JSON, это кстати вообще загадка, и для iOS и Android это довольно неудобный формат, как и XML впрочем.

JSON гдет на 20% лаконичней чем XML, что в эпоху GPRS было очень существенным бонусом. А третьего стандарта не было вообще, поэтому JSON

XML був де-факто стандартом практично всі нульові.
як дефолтний АПІ формат, але це вже було після 2010-го року.

XML ніколи і не був стандартом в браузері і вже точно не «всі нульові». Тобто він був стандартом для XMLHttpRequest api, але він точно не вистрілив настільки щоб сказати «де факто». До другої половини нульових взагалі не було тренду товстих клієнтів в веб, тому там і не ганяли чисті дані, а html чи навіть eval, ну і звісно різні велосипеди. JSONP для кросдомених та кросбраузерних запитів з’явився як стандарт в 2005м, як узагальнення різних хаків які ганяли дані через скрипт об’єкт, коли з Ajax ще доводилось юзати com об’єкти, а для кросдомених ще й свій XDomainRequest. Після стандартизації і покращення підтримки крос доменного ajax з CORS пішли jQuery.parseJSON і подібне і різних фреймворках, і потім вже добавили в web стандарти. Тобто JSON.parse в 2009м це була вже просто стандартизація API та підходів бібліотек, так само як нові стандарти виходять зараз- спочатку вони реалізуються в бібліотеках, набувають популярності, потім аналогічне API добавляють в стандарти веб, а не JSON з’явився в 2009м і десь після 2010-х він начебто там тільки витіснив XML. По факту витісняти було нічого, крім велосипедів та JSONP.

Святі небеса, що ви несете? Більшість публічних апі популярних сервісів були на XML: фейсбук, твіттер, вконтакті і маса других. З менших хтось ганяв хтмл, хтось текст, хтось навіть джсон. В мобілках взагалі обмазувались різними збоченнями типу SOAP, яка працює поверх хмл. На асп.нет ми взагалі ганяли хмл до останнього. В той же джейКвері вбудовану підтримку джсон завезли тільки в 7-8 роках, а до того приходилось підкладочку json2.js носити з собою, щоб щось серіалізувати/десеріалізувати. Та, блін, весь 4-й стандарт джаваскрипта, що не взлетів, вертівся навколо xml, який мозіла заімплементила і підтримувала в одне рило. Гугл в другій половині 0-х втюхував свій гток, який в браузері працював поверх xmpp, що базується на хмл. Дуров в 2009-2010 році запустив свій жаба-сервер для месседжинга, який працював поверх xmpp.

Джсон почав взлітати десь в 2005-6, але він не став стандартом за один день. На це пішло років 10. Я пам’ятаю ще ті статті за 2014-2016, де в заголовках були питання на кшталт «is xml finally dead?».

Ця дискусія напоминає мені срачі «флеш проти хтмл5». Парочка ентузіастів, які перейшли на новий хтмл5, в усе горло кричали, що флеш мертвий, а флеш після того ще років 10 був де-факто стандартом індустрії. Навіть після офіційного депрекейшена технології флеш ще декілька років був на коні.

Більшість публічних апі популярних сервісів були на XML: фейсбук, твіттер, вконтакті і маса других.

Ну нехай в популярних сервісів був бекенд з XML. І що? Воно з браузера використовувалось? Крім XML у цих сервісів був і JSONP API, бо XML був дійсно стандартом, але не в браузері. XML в браузері не прижився, і коли постала задача активного асинхронного обміну практично відразу з plain text/html пересіли на JSONP, який стандартизували в 2005му. З чого ви зробили висновок що XML був стандартом де факто в браузері не зрозуміло, хоча може ви в цілому говорили, але у комента ще вище контекст про JSON.parse то відповідно JS і браузер.
В веб проектах після 2007-2008 він якщо і використовувався, то тільки тому що бекнд легасі й не на PHP, який тоді займав 70% ринку, а на всяких там АСП і подібному. В Делфі і куча подібного теж дьоргали бекенд через XML тільки, але це ж не браузер.

В той же джейКвері вбудовану підтримку джсон завезли тільки в 7-8 роках

Можливо, але як я сказав тоді був JSONP в топі, а не JSON, як раз через те що це було кроссбраузерно і кросдоменно. Ну і самі ж кажете, що імплементація парсера в JQuery не була першою. Та і взагалі специфікація JSON ніщо інше, як просто об’єктний літерал JS- це не те що треба було придумувати і проваджувати, воно вже існувало в JSONP. Ще раніше особливо не було потреби в асинхронній передачі структурованих даних, ганяли просто там пару рядків плейн текста чи вже відрендерений html для обнови сторінки без перезавантаження. Сервісів у яких клієнт використовував «дорослий» XML було дуже мало відносно масштабу всього веба, тому як тут можна використовувати термін «де факто стандарт»? Де факто стандартом він був на інших типах клієнтів, чи при між сервісній взаємодії.

Джсон почав взлітати десь в 2005-6, але він не став стандартом за один день. На це пішло років 10.

Тобто до 2015? 😁 Ну не знаю, у вас якийсь альтернативний всесвіт вебу. В браузері XML ніхто ніколи не любив, тому і використовували малий проміжок часу і по великій нужді, коли не треба було чіпати бекенд, бо і так працює, та і він один для всіх типів клієнтів був.

де в заголовках були питання на кшталт «is xml finally dead?».

Навіть зараз можна надибати сервіси з JSONP як альтеративою. Яке відношення має стан «мертвий», до стану «стандарту»? XML може ніколи і не помре зовсім, хіба в цьому суть? Якусь частку «ринку» він все одно буде мати, і може не один десяток років.

Ця дискусія напоминає мені срачі «флеш проти хтмл5».

Тільки от флеш був мультимедійним стандартом в браузері і тривалий час, а от по факту масовості використання XML ні. Якась значна активність може і була в 2003-2006 роках, раніше 2006го я не застав, але на «дефакто» не тягнула ніяк.

Я зрозумів. Тепер я бачу, що ви абсолютно не відбиваєте в тому, що пишете. JSONP у вас стандартизували в 2005? Дуже смішно. Пропоузал зʼявився тільки в грудні 2005, а більш-менше широку підтримку JSONP здобув тільки під кінець декади, а потім зразу і загнувся.

Про пхп ще смішніше. Популярні фреймворки типу Yii, Symfony, CodeIgniter додали первокласну підтримку джсона тільки на рубежі декад, а деякі ще пізніше (з 2011 по 2014 рік). Мабуть, тільки в Зенд фреймворку була нормальна підтримка джсона з перших днів.

Про джейКвері ви знову самі собі щось вигадуєте. В джейКвері в 2006/7 роках була підтримка через поліфіл, а потім цей поліфіл вмерджили в кодову базу фреймворка.

Інше не буду коментувати, бо то вже повний брєд. Соррі.

Тепер я бачу, що ви абсолютно не відбиваєте в тому, що пишете.

Ну нехай, добре що ви хоч відбиваєте 🙃

JSONP у вас стандартизували в 2005? Дуже смішно. Пропоузал зʼявився тільки в грудні 2005

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

а більш-менше широку підтримку JSONP здобув тільки під кінець декади

Під самий кінець декади вже на звичайному аяксі+json почали робили запити, і бум прийшовся десь на 2009-2011, і логічно що JSONP довго не жив, бо був просто костилем-декоратором, поки підтримка аяксу, особливо з КОРСом не отримав широку підтримку браузерів. Звісно до умовного ентерпрайзу це докотилося з величезною затримкою, а от відносно дрібні проекти стали юзати це дуже швидко, а кількісно їх значно більше, щоб говорити про веб зі сторони клієнта в цілому.

В джейКвері в 2006/7 роках була підтримка через поліфіл, а потім цей поліфіл вмерджили в кодову базу фреймворка.

Ну так чудесно. Хоча цікаво нащо, якщо тільки в 2011-2014 роках серверні фреймворки стали розуміти серіалізацію в json і всюди в баузері до тих пір був хмл.

Специфікація це ї є стандартизація

Ні, не є. Специфікації JSONP в 2005 не було. Був proposal. Це різні речі. Більше того, специфікації JSONP в принципі ніколи не існувало, бо JSONP — це техніка, а не технологія. Вчіть матчасть, як говорять.

Поддерживая тему JSONP в jQuery его как фичу добавили в 1.2 (Sep 2007)
А просто ajax с json поддержка 1.1.1 через eval (Jan 2007)
Тогда правда jQuery еще не использовал, вкатывался на версии 1.3 где-то.

Ні, не є. Специфікації JSONP в 2005 не було. Був proposal.

А ваш «proposal» це що? :) Часом не заокеанське слово для специфікації, яку хтось має розглянути для затвердження кудись? Чи кому воно пропонується?

Специфіка́ція (англ. specification) — формалізований опис властивостей, характеристик і функцій об’єктів.

Не було специфікацій REST, був значить proposal. Proposal воно стає якщо хтось його має розглядати та включати в стандарти, а як ви самі сказали JSONP це підхід, а не технологія, і ніякий комітет його не мав розглядати, тому ніякий це не proposal в сучасному значені комюніті. Розробник виклав свою специфікацію, маніфест техніки чи як ви ще це назвете, люди це помітили і активно почали імплементувати всі кому не лінь в свої бібліотеках.

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

Я вам рекомендую, наприклад, взяти комітет TC39 і ознайомитись з тим, як пропоузали стають специфікаціями, а потім стандартами. Конкретно, в даному випадку пропоузал проходить декілька етапів узгоджень з 6-ти місячними перервами між кожним, поки не вийде вилизана до ідеалу специфікація, яку можуть затвердити як стандарт.

Про Рест також повна маячня, яка підтверджує, що ви дуже далекі від цього всього. Рест — зʼявився як PhD тезіз Роя Філдінга, який потім популяризував цей архітектурний паттерн і він став стандартом індустрії (через дуже довгий процес стандартизації, авжеж).

Щодо JSONP, то це був пропоузал використовувати певну техніку. Не специфікація чи стандарт. Дякую, що тут погоджуєтесь зі мною. Мій поінт якраз був в тому, що в 2005 ніякого стандарту JSONP і близько не було.

Таку нісенітницю могла написати людина дуже далека від цих питань.

Ага. Нісенітниця, брєд, далекі від цього всього, не відбиває... © 😂 І це наче шарпіст каже.

Я вам рекомендую, наприклад, взяти комітет TC39

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

Не специфікація чи стандарт

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

Ідемо сюди, де чорним по білому написано наступне:

> The original proposal for JSONP, where the padding is a callback function, appears to have been made by Bob Ippolito in December 2005

Потім читаємо оригінальний блог Боба і знаходимо там:

> I’m proposing a new technology agnostic standard methodology for the script tag method for cross-domain data fetching: JSON with Padding, or simply JSONP.

Дальше вашу нісенітницю навіть не читав.

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

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

вконтакті

web.archive.org/...​rapi.com/?act=doc#friends
Тут все JSON и нет даже опции XML. Декабрь 2008 года.

 же джейКвері вбудовану підтримку джсон завезли тільки в 7-8 роках

Опять же неверно
$.parseJSON появился в версии 1.4.1 [Январь 2010]

web.archive.org/...​p://www.json.org/json2.js
Вот самое старое что находит по json2 [Октябрь 2008]
Опять же большинство пользовались json без библиотек.

web.archive.org/...​index.php/Profile.setFBML

Май 2008.

Desired response format. Either XML (default) or JSON.

Но тут помоему есть и XML, потому-что оно вызывается с сервера, в примере там вызов с PHP через их SDK.

Тут все JSON и нет даже опции XML. Декабрь 2008 года.

Користуватись пошуком так і не навчились. ВК АПІ по замовчанню йшов з XML респонсами. Потім добавили JSON. XML респонси відключили 11 листопада 2014. Я автор самого популярного C# SDK для VK API і вбив дуже багато років свого життя на дрочку їх АПІ та переписування з XML на JSON клієнт (навіть декілька раз брав призові місця в конкурсах Дурова і блабла).

Опять же неверно
$.parseJSON появился в версии 1.4.1 [Январь 2010]

Опять жє, не вмієте не тільки гуглити, а й навіть прочитати моє повідомлення уважно не можете. $.getJSON був, здається, ще з версії 1.1 (2007 рік). json2.js — це був поліфіл для старих браузерів, який потрібен був для джейквері для підтримки джсона.

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

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Дуглас пише, що слабка типізація в JS є перевагою. Плюсом, а не мінусом.

Дєд пєй таблеткі

Дуглас пише, що слабка типізація в JS є перевагою. Плюсом, а не мінусом.

От ніколи не розумів того що слабка типізація є якоюсь перевагою.. тобто те що не перевірить компілятор буде перевіряти рантайм ?? Чи він щось інше мав на увазі?

ну попробуй прописати всякі DAO/Holder та AdminPanelRequest/AdminPanelResponse
на кожну сутність у проекті

Зрозумієш :)

Кепка на такому карʼєру зробив як в строгу типізацію впихіватьневпіхуємоє

Для веб це перевага, для банківського процесора мінус

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

так і в яві зараз не 98ий рік тож, є генеріки, є всяки AOP, генератори й інши приблуди, як є clojure/gradle, в оригінальній яві навть числа різних типів треба було явно один до одного приводити

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

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

або в тебе виклик чи операція з різними хренями вилітає або ні
в тапл чи масив в пітоні положи шо хош

mixed_list = [1, «hello», 3.14, [1, 2], {«name»: «Alice»}]

по третє

js це означає менше помилок в рантаймі

тіпа в python є ще щось крім рантайма

cуть не в мові, а тому що в js воно в плюс іде бо зменшує ото що ТС назвав accidental complexity

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

«Strongly typed» and «weakly typed» are terms that have no widely agreed-upon technical meaning. Terms that do have a well-defined meaning are

Dynamically typed means that types are attached to values at run time

# Python allows comparing different types
3 < «4» # TypeError in Python 3, but worked in Python 2
[] <= () # Works, comparing different collection types
None < 1 # TypeError, but worked in earlier versions
© claude

Я не знаю де ви таке вичитали про слабку і сильну типізацію. Хоч би chat GPT спитали чи що) Але на практиці означає що якщо в пітоні плюсувати строку та число то буде TypeError, а js автоматично приведе типи до строки і сконкриенує. Ось і приклад коли не буде валитись в рантаймі. Слабка типізація не тільки у порівняннях процює. Це коли мова автоматично приводить типи

та у Гугла спитай, в клода я тільки приклад спитав

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

це і значить нот вел де файне, ти вважаєш це одне, а хтось інше

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

Це коли мова автоматично приводить типи

if (0) {
}

ну попробуй прописати всякі DAO/Holder та AdminPanelRequest/AdminPanelResponse
на кожну сутність у проекті

Во всех вменяемых языках есть generics или аналоги, что делает написание всего этого элементарным.

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

Наприклад, я якось подивився на source code чи то Redux чи то ReSelect і мені стало сумно через те що людям довелося доволі складно описувати типами те що в JS просто працювало. Ну тобто раніше воно працювало, і написане через TS також працює, тільки коду набагато більше.

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

тобто те що не перевірить компілятор буде перевіряти рантайм ??

Нащо його перевіряти в райнтаймі? Перевіряти мають тести, від написання який TS ніяк не звільняє, так само як і від перевірок в райнтаймі, якщо функція має декілька інтерфейсів і логіка коду від них залежить. Чи ви хочете просто на вході кожної функції писати ассерти на всі аргументи? Яка від цього користь? Після тестів в рантайм і тим більше прод зламаний код немає попасти. Практично неможливо щоб на нормально написаних тестах логіка працювала правильно, але при цьому ми помилилися в інтерфейсах чи типах. Тим більше IDE вже дають непогані хінти, а з розвитком AI скоріше за все вони стануть тільки досконаліші.
Та і як глянути на той же багатомільярдний Аліекспрес, то там і в UI бувало NaN та undefined is not a function в консолі проскакує, що свідчить що там не тільки TS нема а і з QA проблеми, але бізнес працює.

Він пише в книзі, що строга типізація, на його практиці, давала малу перевагу і зазвичай не рятувала від помилок, забирала час на те, щоб «гратися» з типами. А слабка типізація, навпаки, дала йому гнучкість і швидкість.
Гарне код рев’ю та тестування в багатьох випадках знімає необхідність в статичній та строгій типізації. На практиці я бачив код написаний на мові зі статичною типізацією, але при цьому не покритий юніт тестами.
Крім того, бачив часто хаки такі як слово «as», «any», «ts-ignore». Навіщо тоді така строга типізація?!!!

Строга і статична типізація при цьому мають своє місце як на практиці та й в теорії.

Теоретично весь код типізований, питання лише чи ці типи явно вказані.

Книги книгами та на практиці чим більше коду тим менша вірогідність того що ви там зустрінете голу динамічну типізацію. Типи сильно допомагають в написанні та використанні вже існуючого коду навіть якщо це тільки перевірка під час компіляції. Тести та ревю не заміняють типи. На практиці тести дуже рідно мають високе покриття, та і задача в них не та сама. Часто код взагалі немає сенсу покривати тестами. Типи та інтерфейси також допомагають відокремити специфікацію поведінки (контракт) від конкретної реалізації. Звичайно і динамічній типізації є місце в деяких задачах. Якщо на ревю є any — то тут якби треба задатись питанням чи потрібні вам типи взагалі — бо якщо ні то ви дійсно робите тільки гірше витрачаючи час на те що не використовуєте, а якщо потрібні — то чи має PR взагалі йти в ревю якщо в ньому є any?

Для кода размером в 500 строк, зачем тебе типы. Это ж скриптовый язык. В C++ размер и длина кода не так важен, потому-что он будет скомпилирован, а тут все идет на клиент чистоганом.

В вас слово пропущене

Зараз JavaScript, на жаль, вже вийшов за межі скриптової мови і є мовою загального призначення. Ви можете створювати десктопні та серверні застосунки за допомогою Node.js.

блін а доу таки може кинути щось оргазмічне, тут тре буде ще й перечитати разок-другий, дякс

наявність одразу null та undefined конфузять, уявіть, що в TS є undefined, null, void, never, unknown, any.

та нащо ж, навіть не треба уявляти ;)

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

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