TL;DR

Якщо коротко, то HTML і CSS створювалися для розмітки і оформлення простих документів а ЯваСценарій це жахлива і по суті єдина мова програмування доступна для «розуміння» броузерам з купою недоліків створена за 10 днів (так навіть в «JavaScript: The Good Parts» написано), яку з усіх боків облизує дуже багато вебщиків які нічого крім JavaScript не бачили, і якщо процес оформлення цього тексту за допомогою HTML і CSS ніяких неприємних відчуттів не викликає, то беручись за створення чогось більш складного (читай, відмінного від статичних текстів) стикаєшся з купою проблем породжених недоліками і спеціалізацією вищеназваних технологій на тексті, на документах. Значна частина так званого web–програмування це зборище хаків тому що якщо тобі потрібно створити щось відмінне від не складного інтерактивного документу, то інакше просто ніяк, тому що, як я вже вище писав, технології WWW призначалися для зовсім іншого. 90% людей зайнятих створенням web–сайтів це погані малокваліфіковані програмісти і цілком можливо що любов до JavaScript є наслідком неосиляторства, вузького кругозору, низького рівня проф. придатності і синдрому каченяти.

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

Мені прикро це казати, але якби я наймав програмістів, то я б віддавав перевагу людям не замараним сайтобудівництвом і для вебщиків проводив би додаткове тестування.

Web для тексту. CSS відстій.

Наскільки мені відомо WWW задумувалося як середовище гіпертекстових документів (і доволі простих документів мушу зауважити) пов'язаних між собою за допомогою посилань а не як середовище для програм, не як програмна платформа. Це лише документи з домішкою інтерактивності у вигляді скриптової мови JavaScript (це те ж саме що й Microsoft Office з його Visual basic for applications. Кумедно, але гадаю, що можна писати здоровенні програми на VBA в doc файлах і потім розповсюджувати їх майже так само як вебщики свої HTML документи в Electron. Discord в doc файлі, м–м–м.). І чим далі від концепції документу, чим більша мімікрія під "нормальні" програми, чим складніші макети і оформлення тим мерзотнішим все це web–програмування стає і тим дужче моє роздратування. Про програми (саме про «нормальні» програми для ОС а не web–сторінки для переглядачів WWW) я тут згадав по перше, через популярність так званих SPA які намагаються бути як програми (віднині буду називати «нормальні» програми просто програмами тому що, як на мене, комбінація з мови для розмітки тексту, CSS і ЯваСценарія це документ з приліпленою збоку мовою програмування) перетворюючи HTML і CSS в інструмент для побудови елементів графічного інтерфейсу користувача (для чого вони не призначені вкотре вже повторюю); ну і по друге, тому що багато сторінок в WWW знаходяться десь між програмами з знайомими всім елементами GUI, майже голим текстом без форматування і чимось на зразок красивих глянцевих журнальчиків (хоча, мабуть, правильніше було б сказати що на HTML і CSS роблять і те і те). В HTML немає набору, бібліотеки типових (найбільш поширених) компонентів GUI (віджетів) а CSS як засіб керування розміщенням елементів сторінки просто жахливий. Якщо тобі потрібно написати програму з GUI для Windows, Mac OS, X window system, Android, то до твоїх послуг декілька спеціально для цього призначених технологій на зразок GTK+, Qt, FLTK, Cocoa, MFC, WPF, VCL з якими ти не будеш витрачати час на написання хаків і створення з нуля елементарних речей, а якщо ж ти сядеш за своє супер–пупер SPA, то ти опинишся в якійсь кам’яній добі з шматком граніту і кривою гіллякою чи не єдиним інтерактивним елементом придатним для створення GUI у вигляді теґу button (призначення багатьох інших теґів суто текстове — створити параграф, вставити картинку, додати список, таблицю і т.п.). Візьмемо, наприклад, Qt. В Qt на програміста чекає 2101 клас і купа компонентів GUI з можливістю їхнього розширення для створення власних а також такі штуки як менеджери компоновки які дозволяються як завгодно і без зайвої мороки розташовувати елементи інтерфейсу (для чого вебщики змушені використовувати CSS). Для створення панелі з меню в Qt достатньо викликати дві функції: fileMenu = menuBar()->addMenu(…) або мишкою накидати на форму потрібні елементи. У випадку з сайтобудівництвом ніяких 2101 класів нємає і вебщикам таке тільки сниться (хоча ні, не сниться. 90% з них про існування чогось подібного навіть не здогадуються і для них еталон і те на що всі повинні рівнятися це CSS і черговий модний framework написаний на JavaScript); їм доводиться мучитися, шукати різноманітні способи і писати гору CSS і JavaScript для того щоб створити таку банальну річ як панель меню. І так майже з усім. Потрібні симпатичні віконця в контексті сторінки а не нова вкладка в броузері чи блокуючі модальні alert, prompt, confirm? Але їх немає, тому давай пиши власні вікна і щоб у всіх броузерах працювало і було адаптивним. Хочеш стилізувати теґи radio і checkbox? Будь ласка, статті в яких описується 10 хитромудрих способів до яких ти б ніколи сам не додумався. Потрібен ієрархічний список? Ой, і таке теж відсутнє. Таблиця але, не проста а інтерактивна з сортуванням, фільтрацією, моделлю даних і т.п.? Звісно ж такого немає тому що це сраний документ тож таблиця тут це просто таблиця, як в зошиті, як в документі. Але якщо чесно, то середньостатистичний вебщик (з мого досвіду) такий компонент як ієрархічний список, випадаючий список з фільтрацією і т.п. робив би місяць та й WWW не вчора з’явилося тому до наших послуг певна кількість несумісних між собою бібліотек, скриптів, frameworkʼів різної якості і свіжості, які щось роблять добре, щось погано і мода на які міняється, мабуть, кожного року. Вебщикам за великим рахунком доводиться вдовольнятися теґом div як універсальним будівельним блоком і горою CSS і ЯваСценарію для того щоб виліпити з нього те що потрібно. Як би було добре якби прямо в HTML можна було б надрукувати щось на зразок

<navbar postion="top" autohide="3s"><items><item>Menu item 1</item></items></navbar>

var fookingAwesomeWindow = new Window({title: 'My new window', content: 'awesome form.html', position: 'center', onLoadFailure: function(){…}})

jQuery

Якщо вам хтось скаже що в WWW програмують на ЯваСценарії, не вірте. Тут всі програмують на jQuery. JavaScript в контексті WWW вже давно = jQuery (якщо ти вирішив стати вебщиком і раптом вчиш як працювати з DOM в ЯваСценарії, то не варто, візьмист за вивчення jQuery оскільки на співбесіжах все одно будуть вимагати jQuery і на роботі маловірогідно що знадобиться). Бібліотека створена John Resig заборола конкурентів і витіснила ЯваСценарій з HTML документів. Чи багато вебщиків нині скажуть як видалити елемент DOM без jQuery чи, ну гаразд, іншої бібліотеки (елементКонтейнер.removeChild(елементЯкийПотрібноВидалити))? Як видалити вказаний клас? Сеньйори–помідори з ЗП в декілька тисяч доларів які не знають як без jQuery анімувати зміну висоти div'а чи надіслати HTTP запит, теми на форумах в яких у відповідь на питання про те як в ЯваСценарії обійти нащадків елемента моментально пихають код на jQuery це взагалі ознаки часу. Відкрию таємницю: для того щоб влаштуватися на роботу вебщиком і отримувати башлі часто вистачить поверхового знання ЯваСценарію (ще бажано вивчити відповіді на каверзні питання по ЯваСценарію які можуть задати на співбесіді), сяких–таких навичок програмування і, головне, знання jQuery (а ще доведеться навчитися верстати). Навіть якщо в оголошенні про найм ніндзя–вебщика чи рубі–кицьки на останньому–модному–JavaScript–фреймворку–останньої–версії немає нічого про jQuery, то такі знання маються на увазі тому що jQuery це стандарт de facto. Засмучують люди які стверджують що jQuery винен в тому що їхній код перетворюється в лапшу і тому jQuery це кака, всі кидайте jQuery, переходьте на фреймворк який я використовую ось уже третій місяць. Лапшокод що в клієнтських скриптах, що в серверних це взагалі стандарт в сфейрі сайтобудівництва ну і люди, отямтесь! Це не jQuery перетворює ваші скрипти в лапшу. Це ти (так. Саме ти.) не здатен зробити нормально. Фреймворки просто організовують все за вебщиків. Твердження про те що jQuery витіснила ЯваСценарій з інтерактивних HTML документів різного ступеня навороченості не безпідставне і ось чому: величезна частина більшості програм на ЯваСценарії це маніпуляції з деревом об’єктної моделі документу і HTTP запити, а DOM це капець як незручно (не згадуючи про відмінності в реалізації в різних броузерах), отже замінивши прямі виклики методів броузерних API для роботи з DOM на власні зникла і необхідність в великій кількості супутнього коду на JavaScript.

JavaScript

ЯваСценарій (і все що з ним пов'язане) має купу недоліків особливостей при цьому нічого надзвичайного (чи просто хорошого) з себе не представляючи. Не помічати недоліків можна у випадках коли немає з чим порівнювати тому що нічого крім цього ти не знаєш, коли все одно, коли ти обклавшись бібліотеками пишеш черговий скрипт який показує діалогове вікно від Twitter bootstrap, змінює document.title при прокрутці сторінки і робить інші подібні речі які складають більшу частину роботи більшості сайтобудівельників (в таких випадках дійсно не так вже й важливі якісь там недоліки JavaScript зважаючи на наявність і кількість коду (jQuery і т.п.) який згладжує гострі кути). Ну або в тебе ЯваСценарій головного мозку і на щось інше ти перейдеш тільки коли від JavaScript відмовиться останній бомж навчений web'у якимсоь добрим хіпстером.

Хотів написати багато тексту про стандартну бібліотеку порівнявши те що є в ЯваСценарії з тим що має, наприклад PHP, але потім мені стало ліниво та й подумавши я виявив що мені в повсякденній практиці вбога стандартна бібліотека не так то й заважає. Звісно часом хотілося б більше функцій, але під Node.js я, дякувати Мойрам, не пишу а в броузері відсутність функцій на зразок md5, trim, in_array не критино… але постривай. В ЯваСценарії немає функції для перевірки того чи масив містить вказаний елемент (ну і trim теж немає). Якби можна було для цього використати оператор in було б чудово, так елегантно. Але ні, in не годиться і для 33 in [1, 33] він поверне false а у випадку з 1 in [1, 33] true (вгадай чому). Що ж робити? Писати власну функцію для такої тривіальної штуки? А може… так, дійсно, купа бібліотек зі своїми функціями для перевірки того чи містить масив вказаний елемент. В jQuery є функція яка хоч і називається inArray, але if(jQuery.inArray(1, [1,33])) це помилка тому що jQuery.inArray повертає -1 якщо елемент не знайдено і індекс елементу якщо знайдено, тож якщо шуканий елемент це перший елемент масиву jQuery.inArray поверне індекс 0, а 0 прирівнюється до false. Що потрібно робити так це перевіряти чи значення яке повертає jQuery.inArray більше або дорівнює 0. Хм. Може вже таку функцію додали? Так, додали… в 2012 році (в 2012 році!) в Google Chrome з'явилася повна підтримка indexOf для масивів. Тільки називається вона indexOf і працює так само як jQuery.indexOf. Дуже зручно. ЯваСценарій має мінімалістичну стандартну бібліотеку відсутні і затребовані функції з якої заміняються скопійованими скриптами знайденими на просторах Мережі, бібліотеками і пакетами з репозиторіїв для ЯваСценарію. Показова історія з пакетом left-pad за авторством Azer Koçulu який в 2016 році видалив свої модулі з NPM і зіпсував життя всім вебщикам тому що як виявилося Left-pad виступав як залежність для величезної кількості проектів. На той час щомісяця цей пакет завантажували близько 2 486 696 разів. А якщо тобі раптом потрібно буде з'ясувати чи містить якась змінна масив, то є пакет isArray (35 001 265 завантажень за останній місяць) використавши який ти без зайвої мороки зможеш дізнатися масив чи ні. На тему визначення масив, не масив можеш почитати статтю (зайвим не буде), обговорення на stackoverflow.com, скористатися функцією jQuery.isArray (оскільки воно й так, скоріш за все, є на сайті над яким ти працюєш) ну або ">Array.isArray підтримка якої, якщо вірити caniuse.com, в Mozilla Firefox з’явилася лише в 2013 році. Мова програмування яка, згідно відповідної статті на Wikipedia, з’явилася 1995 року, тобто 22 роки тому (зараз 2017), обзавелася рідною функцією isArray 4 роки тому. Хіба це не показник продуманості, зрілості і зручності? Всі ті хто наярює на JavaScript мабуть все життя мріяли написати щось на зразок (код з книжки «JavaScript: The Good Parts», дата видання May 2, 2008, автор Douglas Crockford)

var is_array = function (value) {
  return value &&
  typeof value === 'object' &&
  typeof value.length === 'number' &&
  typeof value.splice === 'function' &&
  !(value.propertyIsEnumerable('length'));
};

Можна й далі продовжувати, але ліниво, багато букв і потрібно надрукувати ще немало. Зроблю такий собі підсумок привівши цитату з божественної статті «Javascript: фрактал отсоса»

К самому языку докопаться к слову почти негде — настолько мала его доля во всем стэке технологий. Тот же DOM отдан на откуп браузерами, весь ввод-вывод отдан библиотекам, модули и человеческая поддержка ООП реализуется ими же. И куда ни глянь, в какую область применения не кинь взгляд, тут же откуда слышится шепоток восторженного JS-боя, о том, что и для этого у них есть библиотека. Когда библиотеки используются для того, чтобы использовать какой-то нестандартный или специализированный функционал — это нормально, когда библиотеки используются для расширения языка общего назначения, это тоже нормально — Boost для С++ отличный пример(если не брать в расчет его монструозность), а вот когда библиотеки используются для узкоспециализированного языка, причем не расширяя его функционал, а просто скрывая его недостатки, то это заставляет задуматься.

Ех. Прекрасна стаття. Від душі. Але до справи. Мені можна було б і не друкувати весь цей текст, але хочеться додати і свої п’ять копійок і я вважаю що потрібно більше критики сайтобудування і ЯваСценарію бо всі наче подуріли з цим своїм JavaScript. Перейду до іншої теми.

ООП в JavaScript і прототипи

ООП в JavaScript ніби то й є і ніби то й немає. В моєму бурситеті все що мені потрібно було розказати про ООП це пару речень про поліморфізм, наслідування, інкапсуляцію і далі цього я навіть не замислювався щось вивчати, але як виявилося стаття на Wikipedia містить більше інформації ніж я знаю і ніж мені зараз хочеться опрацьовувати. Особисто для мене питання ОО ЯваСценарію залишається відкритим. В будь–якому разі ЯваСценарій має об'єкти.

Хоча ЯваСценарій і не має поняття класу, але чомусь я часто зустрічаю його в коді скриптів (і рідко коли щось на кшталт protoObject, rootObject, rootProto). Мабуть програмісти так прониклися прототипами і ідеєю безкласовості що скрізь пишуть class і ключове слово class в ECMAScript 6 теж через це там з'явилося (тому що прототипи це зручно!). Якби там не було в JavaScript немає специфікаторів доступу і всі функції та змінні в об'єкті доступні для зовнішнього коду (що вже насторожує). Замість специфікаторів доступу пропонується використовувати всілякі хитрощі. В тому ж PHP є спеціальні ключові слова і все що потрібно це надрукувати щось на зразок private myFuntcion. В JavaScript пропонують створити змінну в конструкторі використавши ключове слово var (змінна не привласнюється властивості породженого функцією об'єкту), але в цьому випадку функції викликані в контексті породженого об’єкту не мають доступу до таких приватних даних і тому потрібно створити ще одну… далі описувати не буду, можеш почитати обговорення на цю тему.

Наслідування, чи то пак успадковування. Воно тут теж через прототипи. Як це відбувається в інших мовах програмування? Дуже просто — class B extends A. А як це відбувається в ЯваСценарії? Ну по перше, є більш ніж один спосіб це зробити і по друге, всі вони мають певні особливості. Можна писати функції–конструктори і буде щось таке:

function Descendant(name) {
	Forebear.call(this, name);
	…
}
Descendant.prototype = new Forebear();
Descendant.prototype.constructor = Descendant;

Правда зручно? Можна зробити ще краще. Автори «Pro JavaScript Design Patterns» вводять функцію extend для того щоб можна була друкувати extend(Descendant, Forebear):

function extend(subClass, superClass) {
	var F = function() {};
	F.prototype = superClass.prototype;
	subClass.prototype = new F();
	subClass.prototype.constructor = subClass;
}

потім вдосконалюють її додавши атрибут superclass:

function extend(subClass, superClass) {
	var F = function() {};
	F.prototype = superClass.prototype;
	subClass.prototype = new F();
	subClass.prototype.constructor = subClass;
	subClass.superclass = superClass.prototype;

	if(superClass.prototype.constructor == Object.prototype.constructor) {
		superClass.prototype.constructor = superClass;
	}
}

О так. Покажи мені своє ООП. А можна не писати функції–конструктори а просто вручну створювати об’єкти і складати на їх основі інші об’єкти.

var Person = {
	name: 'default name',
	getName: function() {…}
}

Атори вищезгаданої книжки вводять функцію clone для копіювання обʼєктів:

function clone(object) {
	function F() {}
	F.prototype = object;
	return new F;
}

І це ще не все. В «Object-oriented JavaScript» від Stoyan Stefanov розділ про наслідування містить 16 підрозділів. А в розділі Encapsulation and Information Hiding в «Pro JavaScript design patterns» (Ross Harmes and Dustin Diaz) є такі підрозділи як Private Methods Using a Naming Convention і Drawbacks to Using Encapsulation. З такими танцями в ОО стилі, мабуть, можна писати на чому завгодно. Або, можливо, ЯваСценарій і реалізує справжнє ООП, або ж мови на зразок C#, C++ це розвиток ООП. Не знаю (хех, від лайнокодера іншим лайнокодерам). В будь–якому випадку ну його такі ментальні перегрузи і стільки зусиль для реалізації того що в інших місцях є сходу і моя неврастенія не дає мені продовжувати (а читати літературу про ООП це буде твоїм домашнім завданням) і тому ще декілька абзаців і закінчу так як є.

Спаскуджування WWW

Ставши вебщиком ти здійсниш гріхопадіння, наблизиш кінець світу і будеш потворствувати Дияволу беручи участь в створенні перевантажених скриптами і CSS'ом HTML документів завантаження і обробка яких твоїм броузером додає до рахунку за електроенергію 20% (а в глобальному масштабі це екологічна катастрофа). Збільшити розмір сторінки єдина функція якої це прийняти від користувача номер телефону і відправити його програмі на сервері ледь не до півтора мегабайта? Чом би й ні. Адже не можна просто відцентрувати тег input і додати пояснення що вимагається. Потрібно ще тисячі рядків CSS і JavaScript коду (і обовʼязково jQuery) для того щоб зверху сторінки була красива панелька ледь не в три пальці товщиною щоб величезна зелена кнопка, щоб введені користувачем числа красиво форматувалися (дуже, дуже потрібна функція), щоб був якийсь не такий, особливий шрифт і щоб мені довелося декілька хвилин сидіти і перезавантажувати сторінку (бо в кого зараз низька швидкість доступу до Інтернет? Правильно, ні в кого? Яке ще погане 3G? Що таке 2G?) сподівючись що цього разу всі потрібні файли таки завантажаться з усіх цих CDN, всі скрипти нарешті запрацюють і я зможу переслати гроші. «Ходячи» по сайтах мені не потрібні всі ці свистопердячі красивості які функціонують за рахунок сотень і тисяч рядків CSS і JavaScript, сірий шрифт який зливається з фоном, SPA і т.п. Я б зрадістю відключив би JavaScript, завантаження шрифтів але проблема в тому що всім на…ть на якусь там достпуність і частень виходить так що навіть сайт з трьома сторінками і одним посиланням на завантаження нічого не покаже бо в тебе відклюено клятий JavaScript. Середовище з технологіями (HTML, CSS) які доступні ледь не на калькуляторі перетворюється на щось таке чим без роздратування можна користуватися тільки володіючи ЕОМ з декількома гігабайтами оперативки і процом пошвидше.

І цей рак розповзається і за межі WWW. Будь обачним! Вебщики пакують свої скрипти разом з HTML в огризки Хрома і оргазмують розповсюджучи це під виглядом нормальних програм. Завжди мріяв про програми які в оперативці займають сотні мегабайт, виглядають як сайти, не враховують системні налаштування теми оформлення і шрифтів (принаймні це справедливо для середовища дистрибутивів Linux) і нормально користуватися якими можна виключно мишкою. І ледь не забув згадати про те що оскільки це броузер, то воно має неприємну особливість спорадично ні з того, ні з сього жерти ЦП (особливо це стосується дистрибутивів Linux).

От і все. Хотілося написати більше і краще, але як вийшло. Сподіваюся що напишу ще щось таке. Тримайся подалі від JavaScript і Node.js, не ставай вебщиком.

Висловлюю подяку livecoding.tv. Закликаю заходити на тамтешні стріми і траллірувати вебщиків питаннями про багатозадачність, асинхронність, класи і прототипи, чим __proto__ відрізняється від prototype чи як щось зробити без jQuery.