Переїзд

Переїхав на http://lj.rossia.org/users/webhate/.

Webhate RSS

Webhate Atom

JavaScript і Netflix

Хроніки сайтобудування. В «A Netflix web performance case study» описується як web-макаки зменшили кількість JavaScript на головній сторінці Netflix на 200 кілобайт попутно відмовившись від React і виявили що це добре. Головна сторінка являє собою HTML документ з текстом, картинками, декількома кнопками і мегабайтом! JavaScript. Замість того щоб просто написати щиру правду, що чим менше JavaScript (цим самим применшивши власну значимість як web-програмістів) тим сторінки швидше завантажуються, текст політкорректно починається з твердження що не існує срібної кулі (There are no silver bullets to web performance.) і що на прості статичні сторінки скриптів можна пихати по мінімому (Simple static pages benefit from being server-rendered with minimal JavaScript). Така незначна зміна як скорочення обʼєму скриптів описана так що скаладається враження що вони там всі дуже сурʼйозні спеціялісти недарма їдять свій хліб і що картинки з текстом та двома кнопками це вам non penis canis est.

Проект GTK намерен отказаться от почтовых рассылок в пользу платформы Discourse

Замість роботи вирішив почитати новини на Opennet.ru і засмутився тому що JavaScript і тупорилі сайтики продовжують заміщати собою нормальні технології. Більше засмутився навіть не через це, а чере те що це GTK+, а не якась вебна фігня. Декілька цитат з коментарів під новиною для кращого розуміння того що сталося:

Для почты я могу использовать различные средства индексирования, обработки, фильтрации и чтения (я, например, использую notmuch). Задача почты — доставить информацию, и дальше я могу обращаться с этой информацией так, *как мне удобно*, и все унифицировано — работа со всеми списками рассылки разных проектов происходит одинаково, так же, как и с остальной почтой. Кроме того, почта федеративна: пользователи могут обмениваться сообщениями будучи зарегистрированными на разных серверах. И что теперь для каждого проекта предлагается использовать свое изолированное коммуникационное приложение со своим интерфейсом и способом организации информации?

Согласен! Децентрализованый P2P, без единой точки отказа, с воможностью автоматического шифрования и проверки подписи, кастомным гуем, фильтрами и прочим -- это таааак старомодно и немолодежно! Давайте перейдем на похожее, но централизованное, с прибитым гвоздями гуем а ля "'удобно пользоваться' -- в представлении веб-мака^W разработчика", прибитыми горячими клавишами (опять привет макакам, особенно тем, кто любит переназначать hjkl), без фильтров зато с неплохим отжиранием ресурсов! Ура!

Проект GTK намерен отказаться от почтовых рассылок в пользу платформы Discourse

GitLab продолжает политику навязывания JavaScript

Игнорируя сообщения о проблемах, в которых запрашивается реализация возможности использовать GitLab без предоставления ему доступа к JavaScript, GitLab продолжает усиление привязки к JavaScript. Теперь сервер не отдаёт список файлов в виде HTML, а добавляет на страницу элемент с id "js-tree-list", в который элементы вставляются посредством JavaScript. Указанное поведение управляется переменной vue_file_list_enabled, которая в свою очередь связана с настройкой vue_file_list, которая недавно была переведена по-умолчанию во включённое состояние.

GitLab продолжает политику навязывания JavaScript

Презирство до jQuery

Нещодавно jQuery це було єдиине що знало і що використовувало 99% вебщиків. Але якийсь час тому фокус змістився з цієї божественної бібліотеки на framework'и (або принаймні вони стали новою гарячою темою) і jQuery, по суті і нині залишаючись невідʼємною частиною вебопрограмування, заліг в темних глибинах підсвідомості сайтописак. Вивчивши React з Redux типовий вебопрограміст починає зверхньо дивитися і на jQuery і на тих хто jQuery користується. Така поведінка пояснюється дуже просто. І виникає вона через бажання самоствердитися принижуючи інших та через те що web-програміст вважає що він піднявся вище — я став суперспеціалістом, я став кращим, а ти гівно. Не jQuery єдиним, але питання в іншому. Чи сайтописака який перейшов на який-небудь популярний (а в основному тільки на таке і переходять) framework дійсно став кращим? Звісно ж ні. Тому що все що сталося це просто зміна інструменту. Інструменту для якого потрібні нові знання. От і все. Він не здійснив якогось еволюційного стрибку. Це як поміняти молоток на станок або на магічний молоток що керується заклинаннями.

Чому web-макакам так подобається обмазуватися JavaScript

Навіть не стільки JavaScript скільки різноманітним бібліотеками та framework'ами. Живемо ми в такий час коли сторіночка без Angular, Vue, React, Ember, Polymer, Meteor, Typescript і всякого такого серед сайтописак часто сприймається як щось погане, немодне, зашкварне. Вони полюбляють використовувати якусь неймовірно корисну (наспрадві ні) і дуже популярну бібліотечку навіть якщо можна спокійно без цього обійтися і не перевантажувати сторінку зайвими даними. Не так давно сайтобудівельники в масі своїй були скромнішими задовільняючись jQuery, Mootools, YUI і чужими кривуватими напрацюваннями знайденими на просторах Internet, а про щось серйозніше знало 3,5 найбільш метикуватих особин з всієї популяції.

Глибинна причина полягає в тому що вебщики таким чином намагаються відчути себе більш справжніми програмістами ніж вони є насправді. Хочуть показати всім що вони геть як дорослі дяді і теж пишуть програми. Вони як оті жінки з заздрістю до пенісу які через це частіше ніж чоловіки забувають повернути позиченого олівця або кулькову ручку. Тільки замість олівця web-макака хапаєтсья за черговий angular і гарячково пхає його куди тільки можна. Це стосуються не лише надмірно переобтяжених JavaScript'ом звичайних сторіночок а й бажання робити так звані SPA. Адже SPA це вже ніби то як справжня програма, а значить web-макака почуває себе набагато крутіше коли робить SPA.

Для кращого розуміння варто уявити собі які дії виконують серверні програми що забезпечують роботу типового сайтика. Зробити вибірку з БД, надати отриманим даним потрібну форму, можливо провести якісь операції над ними, записати дані в БД попередньо їх перевіривши, врешті-решт вибрати підходящий шаблон для HTML сторінки, вставити в неї дані і показати користувачу. Так працює що сайтик зі статистикою гравців в який-небудь «Світ танків», що internet-магазин зі списком товарів. Всілякі ж JavaScript-framework'и це вже інша справа. Тут тобі не тільки красиво зверстана сторінка з кнопками (як, наприклад, гарно оформлений документ в Word) виплюнута яким-небудь PHP скриптом, а його величність програма. І от в мозку у вебщика починають витати такі поняття як одностороннє звʼязування, двостороннє звʼязування, модель данних, чисті функції, компоненти, сервіси, MVVM, MVC, реактивне програмування, функціональний JavaScript, диспетчер, observable, привʼязка даних, JSX, віртуальний DOM, редукція та mutable калькований в мутабельний на пару з immutable (іммутабельний). Він починає слати HTTP запити у всі боки та синхронізувати моделі з сервером. В його свідомість поступово проникає концепція елементів керування GUI (згадаймо Delphi) яка витісняє віджети на jQuery. Він починає говорити не просто про верстку а про UI - user interface. Не віджет а control або компонент, UI компонент. Ох. Відчуваєте? Відчуваєте різницю між оцим всим та одинокою сторіночкою з jQuery та декількома скриптами зібраною програмою на PHP або Python десь там на сервері (частенько в таких сторіночках верстки більше і значення вона має більше ніж програмістські потуги web-макаки). І в нього самого аж дух захоплює і перед пацанами не соромно. Вже не просто інтерактивний документ а програма!

Для тих хто не в темі коротко напишу що для 95% сайтиків всі ці framework'и і бібліотеки як машині 5 колесо і мода на них призводить до того що мегабайт а то й два абослютно непотрібних програмуленок на JavaScript показує 2 кілобайти тексу та декілька кнопок. Нагромадження faramework'ів полегшує (хоча й не завжди) програмістську працю і нічого не дає кінцевому споживачу. Заміна вже такого не модного jQuery і пачки плагінів до нього на черговий framework від Facebook, Google або будь-кого іншого і переписування існуючих скриптів під це чудо якщо й змінить щось для користувача, то тільки на гірше: сповільнення, більші витрати апартних ресурсів і електрики, різномантні недоробки і звісно ж відсутність підтримки не зовсім свіжих версій web-переглядачів (це означає що те що справно працювало може перестати працювати).

Якими мають бути сайтики

Якомога менше JavaScript

Більшість сторінок в WWW можуть прекрасно обійтися без JavaScript. JavaScript це додаткові дані які потрібно завантажити а потім витратити час та машинні ресурси на їх обробку. З увімкненим JavaSciprt olx.ua завантажується за 8,30 секунд а з вимкненим за 1,74 секунди; також сторінка прокручується швидше. На JavaScript припадає 1,2 МіБ від загальної кількості переданих даних в 2 МіБ. Більшість з того що воно там завантажило не потрібно нікому окрім Google.

mdeium.com. 4,7 секунди на завантаження. 491 Кіб з 644 Кіб даних це всілякі реакти і редукси (тобто програми на JavaScript). І все для чого? Для того щоб показати декілька абзаців тексту про те що Medium не такий як всі інші. Співвідношення шуму та корисної інформації просто вражає. Хочеться почитати не рекламний текст на головній, а статтю? То приготуйся завантажити 1896,69 Кіб коду незрозуміло яких програм. Більшість з того для чого призначені всі ці програмки можна зробити на боці сервера віддавши сторінку з мінімумом необхідних скриптів. Але хіба це модно? Хіба по сучасному? Ні!

Варто завжди пам'ятати що

JavaScript сповільнює перегляд та завантаження web-документів. Якби не JavaScript, то сайтики на всіляких Lenovo, SAMSUNG`ах, iPhone`ах та інших UleFone відкривалися б моментально.

Фарширування web-документів JavaScript'ом утискає власників не зовсім нових девайсів.

Виконання JavaScript-програм дуже енергозатратне і збільшує рахунок за електрику. Тобто ми всі платимо за JavaScript.

Саме за допомогою JavaScript web-макаки роблять всілякі ідіотські штуки на зразок прихованих коментарів для перегляду яких треба натиснути кнопку, форми для відправки яких потрібен JavaScript, поле пошуку для активації якого доводиться додатково натискати на піктограму або кнопку для того щоб воно вилізло з яким-небудь (неоригінальним) ефектом (оргазми кожного разу коли бачу цю срану анімацію). Таке роблять навіть тоді, коли місця вистачає хоч на 10 таких полів. Не забуваймо про новинні сайтики з текстами які не працюють без мегабайту скриптів, а з вимкненим JavaScript все що можна на таких почитати це заглушки у вигляді смужок для тексту та інших елементів сторінки які мали б завантажуватися тими самим скриптами. Хочеться згадати ще й про безкінечну прокрутку і кнопки «завантажити ще».

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

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

Вебщиків позбавили Flash і тегу blink, але залишили їм JavaScript для того щоб вони робили блимаючі баннери.

Мої слова також підтверджує Klint Finley в статті I Turned Off JavaScript for a Whole Week and It Was Glorious. Цитата: Pages loaded nearly instantly, my laptop battery lasted longer, and I could browse the web with fewer distractions… Закликаю всіх хто це читає слідувати моєму прикладу і вимкнути JavaScript!

Припинити мімікрувати під програми

Як всі прекрасно знають HTML + CSS + JavaScript як програмна платформа повний відстій. Всі ці SPA які намагаються бути як справжні програми нормальних людей ідуть проти природи WWW. Хочеться писати програми як дорослі хлопчики? Вчи Qt, Flash чи Silverlight.

Бути читабельними

Ідіотська мода останніх років на сірий текст дрібним шрифтом на білому фоні це, блять, погано. Погано тому що не у всіх хороший зір, якісні монітори і просто-напросто перегляд такого низькоконтрастного поєднання темно-сірого зі світло-сірим потребує більше зусиль. Маю на увазі не лише текст як в книжці а й різномантні кнопки та інші елементи GUI. Подібні стилістичні рішення мають право на життя, але лише там де це дійсно потрібно. Що цікаво навіть традиційно сині URL перефарбовують в сірий. Було б ідеально якби web-макаки менше лізли до шрифтів віддаючи остаточне рішення про розмір і колір web-переглядачу користувача: віддавали б перевагу відносними одиницями виміру замість абсолютних, більше покладалися б на на larger, slmaller, x-small та інші подібні значення font-size і слідкували за рівнем контрастності.

How the Web Became Unreadable

Підтримувати попередні версії web-переглядачів

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

В цілому хочеться щоб WWW залишався зборищем саме документів а не документів які намагаються бути як програми. Документів доступних як з Nokia 6300 так і з сучасного ПеКа. Щоб форма відправки чого б то не було залишалася просто формою відправки. Щоб WWW ставав семантичним та насичувався метаданими. Щоб нормлаьні програми не замінювалися скриптами на HTML сторінці. Чуваки, заспокойтесь — це лише документи.

WPF Contact Book (YouTube)

In this series we will be creating a contact book application using C# and WPF. This video covers the basic code and resources you will need in order to follow along with this project. All resources and code you may need can be found in the description below.

C# WPF Material Design UI: Fast Food Sales (YouTube)

Material UI with WPF. Код на Github.

"For developers the .NET Core Windows Forms Designer (when we will release the GA version) will look and feel the same as the .NET Framework Windows Forms Designer," said Olia Gavrysh, program manager, .NET, in October. "But for us it is a huge technical challenge to bring the designer to .NET Core because it requires the design surface that hosts the live .NET Core form to run outside the Visual Studio process. That means we need to re-architect the way the designer surface 'communicates' with Visual Studio."

І коментар від Jeff Jones:

Let's deal with reality. MS created a great WinForms designer nearly 30 years ago, in VB - and it only got better, fast. Then, with VB3, they rewrote it in assembly.   Later, around VB5 or 6, I think, they rewrote it in C++.  Then they rewrote it for Visual Studio .NET about 18 years ago.  The productivity and reduced time-to-market provided by the forms designer catapulted VB to the #1 Windows development environment.  Yet today's MS crew just can't get the job done.

Now, we are told that making a .NET Core WinForms designer, a Xamarin XAML designer (or a XAML designer that supports all flavors of XAML) is just too hard.

The problem is not that it is too hard.  History shows that is not true.  The problem is that MS, to save money, has hired developers and product/program managers who do not have the knowledge, skills, and abilities (KSAs) that were common on the VB development group 25 years ago, or even the group who created .NET.

When Microsoft hires the adults to lead and manage, this will get done a lot quicker when people with the experience, KSAs, and intelligence level to understand this is not so hard it takes this long.  Until then, look for competitors to keep taking market share.

(via Programming Sucks & Why I Quit)

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

JavaScript & even numbers

У ЖС макак есть модуль определения чётного/нечётного npmjs.com/package/is-even. У него 2+ миллиона скачиваний. Этот модуль зависит от другого модуля определения нечётного/чётного npmjs.com/package/is-odd У него уже 127+ миллионов скачиваний. Код первого модуля, привожу его целиком:

/*! * is-even <https://github.com/jonschlinkert/is-even> * * Copyright (c) 2015, 2017, Jon Schlinkert. * Released under the MIT License. */ 'use strict'; var isOdd = require('is-odd'); module.exports = function isEven(i) { return !isOdd(i); };

Я не знаю, как это прокомментировать.

Код is-odd уже поинтереснее:

'use strict'; const isNumber = require('is-number'); module.exports = function isOdd(value) { const n = Math.abs(value); if (!isNumber(n)) { throw new TypeError('expected a number'); } if (!Number.isInteger(n)) { throw new Error('expected an integer'); } if (!Number.isSafeInteger(n)) { throw new Error('value exceeds maximum safe integer'); } return (n % 2) === 1; };

Наверняка у его автора уже 2 высших образования, а то и три.

Оригінал: https://umnik.point.im/mdszf.

HTML VS WPF

Почати варто з того що HTML це мова розмітки документів а WPF це технологія для створення графічного інтефейсу користувача. Вже з цього можна зробити висновок що HTML це поганий інструмент для побудови GUI і написання програм, але вебщики пишуть і багато хто з них стверджує що HTML і CSS це прекрасні (і нічого кращого не придумали) засоби для створення ПЗ з GUI. Мабуть WPF було б доцільніше порівнювати зі всілякими React, Rxjs, Knockout, KendoUI, Dojo UI toolkit, Vue і т.д. тому що WPF дещо ближчий до них, але це не так вже й важливо.

TL; DR

WPF це технологія для написання програм з GUI тому WPF в 100 раз краще HTML і CSS для написання програм з GUI.

В HTML вкрай мало теґів для чогось окрім тексту через що вебопрограмістам доводиться страждати (але багатьом все одно).

Для того щоб почати вебопрограмувати достатньо пробігтися по htmlbook.ru (і вивчити jQuery. Ха-ха.) а для того щоб почати творити на WPF потрібно сідати читати доволі об'ємні керівницта а бажано якусь книжечку. Звісно ж і Windows presentation foundation можна брати наскоком читаючи якісь коротенькі статті по суті (наприклад wpf-tutorial.com), але різноматних класів, елементів GUI, складних і простих концепцій в WPF більше і оскільки їх більше, вони потребують певного часу для вивчення або хоча б ознайомлення. В світі HTML і CSS багато всіляких тонкощів і складнощів, але моє враження таке що почати з WPF важче а його вивчення більше схоже на вивчення якого-небудь замороченого JavaScript-фреймворку. В HTML теґів не те щоб багато (а найчастіше вживаних вебопрограмістами якийсь десяток) і більшість з них описуються декількома реченнями. Наприклад теґ IMG. IMG призначений для показу графічного файлу шлях до якого задається через атрибут src. Для IMG можна задати розміри через атрибути height і width. Теґ P позначає абзац тексту. Кожен абзац починається з нового рядка і відділяється від інших відступами. SELECT створює випадаючий список. Кожен пункт списку повинен міститися всередені теґу OPTION. SELECT серед інших має такі атрибути як size, який задає кількість видимих елементів списку, і multiple який дозволяє вибрати більше ніж один елемент. І т.д. і т.п. Напротивагу такій простоті HTML в WPF документація по багатьом елементам керування складається з перерахування 40 методів, 20 властивостей, 30 подій а можливості більшості з них в сто раз перевершують можливості того що є в HTML тож приклади використання елементів можуть мати багато абзаців з посиланнями на пов'язані класи і суміжні теми. В WPF є прив'язка даних, шаблони елементів керування, концепція ресурсів, засоби для локалізації, команди (які схожі на події), залежні властивості, конвертація типів, шаблони даних, потокові документи, теми, користувацькі елементи керування, розширення розмітки, приєднані властивості, концепція доповнень і т.д. Багатопоточність. Для того щоб програма продовжувала реагувати на дії користувача під час тривалого виконання якоїсь роботи програмісту доведеться потурбуватися про винесення цієї роботи в окремий процес і його взаємодію з основним процесом програми. Скільком вебщикам доводиться про щось подібне думати (хоча це стосується не лише WPF)? Скільки з них насправді розуміють що таке асинхронність і багатопоточність?

З одного боку велика кількість різномантіних класів і елементів керування з широкими можливостями це додаткова робота і завада швидкому старту бо з усим цим доведеться хоч якось освоїтися а з іншого боку це велике благо тому що майже все вже готове і програмісту не доводиться мати справу з зоопарком несумісних між собою бібліотек, скриптів, фреймворків і підходів до верстки. Через орієнтованість веботехнологій на текст вебопрограмістам доводиться тяжко, коли справа доходить до чогось складнішого за блимаючий текст (але вони й теґ BLINK прибрали. Ха-ха!). Лише жменька теґів має відношення до GUI а призначення багатьох інших суто текстове. Тому вебщики вимушені все робити власноруч (що складно) а не покладатися на великий набір стандартизованих і легкорозширюваних компонентів, або шукати вже готове (і потім інтегрувати все те що їм пощастило знайти щоб воно могло працювати разом). Вони готові роздути простенькі сторінки до неймовірних розмірів підключивши Twitter bootstrap, jQuery, MDL (getmdl.io), Materializecss, Semantic UI, Blueprint, jQuery UI, Wijmo, Ionic і все що завгодно заради діалогових вікон, списків з фільтрацією, красивих кнопок з картинками, меню і навігаційних панелей, таблиць з пошуком і сортуванням, готових шаблонів компоновки, деревовидних списків і всього іншого чого немає в HTML і що є в WPF. Замість роботи безпосередньо над сайтом, над продуктом вони витрачають купу часу борючись з обмеженнями веботехнологій і займаючись написанням костилів. Намагаючись відцентрувати елемент на сторінці вебопрограмісти плачуть гіркими сльозами для того щоб з великим трудом зробити те що в WPF робиться дуже просто. Список (теґ SELECT) в HTML не йде ні в яке порівняння зі списком з WPF (ComboBox і схожі ListBox та ListView). Наприклад ComboBox має такі події як DropDownOpened і DropDownClosed а також властивість IsDropDownOpen за допомогою якої можна розкривати, закривати список. Заради таких простих речей в HTML доведеться якось викручуватися — мучитися з фокусом вводу, подіями, імітувати натиснення на потрібному елементі і т.п. І з багатьма іншими елементами так — примітивно, простенько, крок вправо, крок вліво — розстріл.

Про що ще хочеться згадати так це про менеджери компоновки (layout managers). Мова про структуру, про розташування потрібних елементів в потрібних місцях. В WPF з цим все доволі просто — є набір компонентів кожен з яких розташовує елементи GUI по своєму і вкладаючи одні контейнери елементів в інші можна легко досягти бажаного. StackPanel розташовує елементи один над одним (вертикально) або один за одним (горизонтально). WrapPanel розмістить елементи в рядах зліва направо або зверху вниз в колонках. Grid — це сітка з рядків і колонок невидимої таблиці що підлаштовується під розміри вікна. Є й інші менеджери компоновки а за потреби можна створювати власні. Наприклад для організації GUI в дві колонки ширину яких можна змінювати за допомогою смужки–розділювача достатньо розмістити всередині контейнеру Grid елемент керування GridSplitter задавши для його властивості HorizontalAlignment значення Center. Розмітка виглядає так:

<Grid> <!-- Колонки. 3 штуки. Друга для розділювача --> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto"/> <ColumnDefinition Width="Auto"/> <ColumnDefinition Width="*"/> </Grid.ColumnDefinitions> <!-- Розділювальна лінія в другій колонці. Нумерація починається з 0. --> <GridSplitter Grid.Column="1" Width="3" ShowsPreview="True" HorizontalAlignment="Center"> </GridSplitter> <!-- Ліва (перша) колонка. --> <StackPanel Grid.Column="0" Background="WhiteSmoke"> <!-- Ще один контейнер. --> <DockPanel> <!-- Кнопки групуються в один блок і розташовуються з правого боку від Label. --> <StackPanel Orientation="Horizontal" DockPanel.Dock="Right"> <Button Content="+" MinWidth="30"/> <Button Content="-" MinWidth="30"/> </StackPanel> <Label FontWeight="Bold" Content="Richard Roe" DockPanel.Dock="Left"/> </DockPanel> <DockPanel> <StackPanel Orientation="Horizontal" DockPanel.Dock="Right"> <Button Content="+" MinWidth="30"/> <Button Content="-" MinWidth="30"/> </StackPanel> <Label FontWeight="Bold" Content="Richard Roe" DockPanel.Dock="Left"/> </DockPanel> </StackPanel> <!-- Остання колонка. Просто Label з текстом --> <Label Grid.Column="2" VerticalContentAlignment="Center" HorizontalContentAlignment="Center" Background="BlanchedAlmond" Foreground="Black" FontSize="40"> Centered text </Label> </Grid>

Розмітка проста і зрозуміла. Не потрібно мудрувати з версткою, писати 150 класів і 20 div`ів вкладених один в одного, шукати якісь бібліотечки і перейматися тим чи буде воно працювати в усіх броузерах.

Виглядає це так:

Причина популярності web–програмування

Гадаю я відкрию страшну таємницю для багатьох вебщиків, але причина популярності Web`у не у п…сті технологій і не в тому що JavaScript і HTML це найкращі в світі мови програмування і не в тому що CSS це божественна технологія і крім CSS нічого кращого не існує. На мою думку дві (взагалі то причина одна: бабло) основні причини полягають в тому що WWW нагадує базар і газети-журнали. З того що WWW це такий собі величезний базар з газетними кіосками випливає те що на ньому можна доволі легко заробляти гроші. Гроші, як і в багатьох друкованих виданнях, заробляються за допомогою реклами (явної або не дуже). І як на базарі товар розкладають на прилавках так і в WWW його демонструють в каталогах на сторінках сайтів. Саме можливість легко продавати і заробляти гроші є основною причиною розповсюдженості вебопрограмування. Сьогодні вебщик робить інтерактивний рекламний буклет на 4 екрани  для того щоб який–небудь комерс міг продавати червоні нитки (якби цей буклет був зроблений у вигляді програми, його б ніхто ніколи не побачив але, існуючи в світі документів WWW, він індексується пошуковиками, показується в пошуковій видачі і приносить прибуток) а завтра пакує свій жуквері код в Chrome і всі користуються супер–пупер революційною програмою Дускорд з мемасиками і ботами що керуються штучним інтелектом з підвалів Пентагону.

Важко собі уявити щоб при використанні архіватору, файлового менеджеру, калькулятору чи програми для роботи з розділами HDD користувачам показували рекламу а от при перегляді web-ресурсів це звична справа. Юзер лазить по web–вузлам завантажуючи документ за документом, сторінку за сторінкою. Часто без якоїсь чітко визначеної мети, просто шукаючи щось цікавеньке. На базарі тебе можуть зазивати покуштувати їхнє чудове сало а от в WWW на тебе з усіх боків посиплеться реклама у вигляді блимаючих  картинок, відео про те який президент хороший або поганий, тексту з обіцянками збільшити пісюн на 10 сантиметрів і т.д. Сторінки на web–вузлах частенько являють собою каталоги з товарами, відео і аудіофайлами і всіляким іншим вмістом газетно–журнального типу на зразок новин, оглядів, кумедних картинок, блогів, кулінарних рецептів і т.д. Ти будеш шукати інформацію про те що такого цікавого можна зробити з лампами розжарювання а потрапиш на стоірнку internet–магазину з сувенірами і дизайнерськими меблями. В такому середовищі дуже легко не тільки продавати щось і показувати рекламу а ще й збирати дані про всіх і вся, шпигувати і слідкувати для щоб потім заробляти на цьому ще більше. Схожість з поліграфічною продукціює проявляється не тільки в наповненні а ще й в зовнішньо вигляді: структура, увага до шрифтів, стилізація звичних елементів GUI під щось незвичне і глянцево–блискуче і щоб не таке як в інших. Якби не існувало WWW в світі було б набагато менше різноманітного інформаційного сміття.

Чому я ненавиджу web–програмування і що мені в ньому не подобається

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. Кумедно, але гадаю, що можна писати здоровенні скрипти на Visual Basic for applications в 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 не вчора з’явилося тому до наших послуг певна кількість несумісних між собою бібліотек, скриптів, фреймворків різної якості і свіжості, які щось роблять добре, щось погано і мода на які міняється, мабуть, кожного року. Вебщикам за великим рахунком доводиться вдовольнятися теґом 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(){…}}) без того щоб це все потребувало 300 кілобайт ЯваСценарію, 1000 рядків CSS і щоб можна було обійтися без 12 вкладених один в одного блоків div з 40 CSS класами, але ж ні, вбогі броузерні API і спеціалізація на тексті не дадуть цього зробити; зроби сам або візьми он ті скрипти на півмегабайта щоб швидше. В плані написання всіх цих SPA і гламурних дизайнів в мене склалося враження що WWW застиг десь в 2000 році і по суті вся відмінність між тоді і тепер це кількість і хитромудрість хаків і вже готового написаного до тебе і замість тебе коду (jQuery, Vue, Angular, Backbone, Twitter bootstrap, Mootools, Dojo, React, Knockout, Ember і звісно тисячі додатків для jQuery) тому що основа (HTML, CSS) та ж сама тільки накручено навколо всього цього більше. Так от. HTML і CSS це про текст (хоча, як це не дивно для мене, є ті хто стверджують що зв’язка HTML + CSS це ідеальний інструмент побудови GUI) і для того щоб в цьому переконатися потрібно переглянути список теґів і властивостей CSS. Верстка кожного HTML документу це доволі таки особливий приготований по фірмовому рцепету коктейль з хаків які вебщик вивчив за свою кар'єру. Але так не має бути. Не повинно існувати 10 різних способів створення меню, комусь справді подобається читати статті на багато букв про те як створити модальне діалогове вікно, зверстати макет на три колонки? Я не хочу (і ти теж не хочеш) читати 19 екранів про рівномірне вирівнювання блоків по ширині. Центрування в CSS (цілі статті про таку банальну і просту річ як один елемент розташувати в центрі якогось блоку!); стаття про progress bar: 10 екранів пояснення. Пишучи програму останнє над чим я б хотів замислювати це як зробити таку базову річ як індикатор виконання замість роботи над власне самою програмою! Так не має бути. Опис зовнішнього вигляду і розкладка елементів на сторінці не мають нагадувати шаманізм або алхімію. Верстка має здійснюватися в один єдиний спосіб і бути такою щоб можна було верстати мишкою тут же бачити результати і не витрачати час городячи хаки. Створюючи дизайн ти повинен займатися саме дизайном а не вигадувати костилі для того щоб воно виглядало так як задумано.

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')); };

і тягати за собою запихуючи у всі скрипти (разом з самописними inArray і trim). Тепер я бачу за що JavaScript так люблять його адепти.

Можна й далі продовжувати, але ліниво, багато букв і потрібно надрукувати ще немало. Зроблю такий собі підсумок привівши цитату з божественної статті «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.