Мой новый стек веб-технологий для 2020 года / forpes.ru

Главная
Мой новый стек веб-технологий для 2020 года

Мой новый стек веб-технологий для 2020 года +23

24.12.2019 09:30

ru_vds 101 29500 Источник

Помните те времена, когда стеки веб-технологий были простыми? Когда уровни этих стеков можно было обозначить в виде четырёхбуквенного сокращения вроде LAMP, LEMP или LEPP? Когда всё, что было нужно для создания и поддержки сайтов, сводилось к вполне обычному железу, к какому-нибудь опенсорсному софту, да к упорству в достижении цели?

Мой первый успешный сайт, теперь уже старинный проект 1999 года, был создан с использованием технологий, которые можно пересчитать по пальцам одной руки: HTML4, CSS2, JavaScript3 и Apache 1.1. Всё это крутилось на сервере с Linux 2.0. Сайт включал в себя 38000 страниц. И сегодня, через 20 лет, он всё ещё их выдаёт.

С тех пор всё изменилось. Это касается и стеков веб-технологий. Теперь они совсем не те, что прежде.

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

Стек веб-технологий 2020 года

2020 год — это начало нового десятилетия. Это — время, когда стоит поговорить о новом стеке веб-технологий.

На что похож «стек 2020 года»? Надо сказать, что на это очень сильно влияет то, чего пытается достичь разработчик сайтов. Выбор подходящих уровней сильно зависит от того, какая степень масштабируемости требуется для проекта.

Меня особенно интересуют маленькие веб-сайты. Те, которые хорошо чувствуют себя на виртуальном сервере. Таким сайтам не нужны балансировщики нагрузки или постоянные хранилища данных. Это — ниша CMS, которую уже давно занимает WordPress. Но в основе всего этого лежит не некий минималистичный сервер. Вместо этого речь идёт о системе, которая может выдержать постоянный поток трафика без необходимости автоматического повышения её мощности в часы пик.

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

?1. Облачный провайдер

Базой моего стека является облачный провайдер, который учитывает потребности тех, кто привык сам заниматься тонкими настройками сред, в которых выполняются их веб-проекты. Я пользовался собственными серверами до тех пор, пока стоимость их поддержки не стала слишком высокой. Аренда места в серверной стойке, выделенный IP-адрес, обеспечение нужной полосы пропускания… Всё это вносит вклад в месячную стоимость физического сервера. Но настоящий «вымогатель» — это стоимость электричества. Облачные провайдеры гораздо дешевле, чем $1.25 в день, которые я отправлял поставщику электроэнергии. Отказ от подобных трат позволил мне сэкономить сотни долларов в год.

?2. Дистрибутив Fedora Linux с SELinux

Безопасность — это то, что очень сильно всех нас беспокоит. SELinux можно сравнить с мощной охранной системой, работающей в Linux. Если к этому добавить ещё и хорошо настроенный iptables-файрвол, получится то, что позволит владельцу сайта спокойно спать по ночам. Если вы не уверены в том, что вам всё это нужно — проведите следующий эксперимент. Разверните новый сервер у вашего любимого облачного провайдера и понаблюдайте за тем, как скоро его начнут атаковать. Я видел, как брутфорс-атаки на новые сервера с попытками входа по SSH начинались менее чем через 10 минут после их создания.

?3. Веб-сервер Read Write Serve

Я пользуюсь веб-сервером Read Write Serve с TLS-сертификатами от LetsEncrypt. Раньше я был фанатом Apache, на настройку и запуск новых веб-сайтов у меня уходило буквально несколько минут. Но с тех пор, как я перешёл с PHP на JavaScript, об Apache пришлось забыть. Сервер Express казался мне чрезвычайно простым инструментом, но лишь до тех пор, пока я не попытался воспроизвести в нём весь тот функционал, который давал мне Apache. Речь идёт о механизме согласования содержимого, об условном кэшировании, о сжатии данных, о перезаписи URL для SEO, о CORS, о политиках защиты контента. В результате я и перешёл на сервер Read Write Serve, в котором все эти возможности присутствуют по умолчанию.

?4. Среда выполнения приложений Node.js

За логику приложения, выполняющуюся на сервере, отвечает среда Node.js. Возникает такое ощущение, что в экосистеме NPM имеются пакеты на все случаи жизни. Поэтому простыми и понятными оказались задачи по сборке из имеющихся пакетов того, что нужно именно мне, и по запуску всего этого на Read Write Serve. Для организации работы всего того, что нужно современному веб-проекту, не требуется прилагать чрезмерных усилий. Это — отправка электронной почты, работа с платёжными сервисами, обращение к базам данных, и всё остальное, подразумевающее работу с серверными API.

?5. База данных MariaDB

Я пользуюсь сервером баз данных MariaDB. Это — форк MySQL, подвергнутый ребрендингу и освоенный опенсорс-сообществом. Когда мне нужно хранить неструктурированные JSON-данные, я пользуюсь PostgreSQL. Дело в том, что это позволяет мне выполнять запросы непосредственно по конкретным JSON-свойствам. Это немного похоже на MongoDB, но основано на привычном SQL-синтаксисе.

?6. HTTP/2

Для организации связи между частями приложений я полагаюсь на возможности HTTP/2 с поддержкой постоянных соединений и с мультиплексированием потоков. Эти два дополнения к достойному уважения протоколу HTTP/1.1. изменили мой подход к формированию документов. Во-первых, исчезла проблема блокировки начала очереди. В результате пропала необходимость в спрайт-листах даже в том случае, если у меня имеются десятки маленьких изображений. Во-вторых, теперь не нужно оптимизировать JavaScript- и CSS-файлы, объединяя их в бандлы. После того, как соединение клиента и сервера установлено, все эти маленькие файлы без перебоев передаются по этому соединению.

?7. HTML-шаблонизация с помощью Blue Phrase

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

?8. Написание кода страниц с помощью Read Write Doc

Когда я создаю новые страницы, я сосредоточен на том, что пытаюсь выразить, а не на их оформлении. Для решения этой задачи я пользуюсь Read Write Doc. Этот инструмент помогает мне заниматься делом, ни на что не отвлекаясь. Я пользуюсь им даже тогда, когда то, над чем работаю, планируется опубликовать на Medium (а там есть отличный онлайновый WYSIWYG-редактор). Я отношу себя к ветеранам веб-разработки, поэтому привык к моноширинным шрифтам, и к тому, чтобы мои руки были бы на клавиатуре, а не метались бы между клавиатурой и мышкой. В любом случае, если мне нужно увидеть то, над чем я работаю, с применением к нему CSS, я могу, с помощью простой комбинации клавиш, переключаться между режимами просмотра и редактирования.

?9. Стандартные веб-компоненты

В области работы с веб-компонентами я придерживаюсь стандартов W3C. Это — теневая DOM, пользовательские элементы, HTML-тег <template>, ECMAScript-модули. Это позволяет мне полностью включать всё, что мне нужно, в пакеты, которые я распространяю через NPM. Для меня самым большим преимуществом всего этого стал тот уровень изоляции, который предоставляет теневая DOM. Это позволило избавиться от проклятья CSS, от загрязнения пространств имён.

?10. JavaScript для клиентских скриптов

Для написания клиентских скриптов я пользуюсь модульным объектно-ориентированным JavaScript-кодом. Я применяю новые возможности стандарта ECMAScript только тогда, когда их поддержка появляется в свежих релизах браузеров. То есть, включаю их в свой арсенал в тот момент, когда вижу, что на caniuse.com «зеленеют» все основные браузеры. Я избегаю полифиллов.

?11. Стилизация с помощью CSS

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

<link href='/fonts/source-serif-pro-400-latin.woff2' rel=preload as=font crossorigin />

Дополнительное преимущество такого подхода заключается в том, что он полностью избавляет меня от проблемы, известной как FOUT — (flash of unstyled text, вспышка обычного шрифта).

?12. Подготовка графических ресурсов с помощью GIMP и InkScape

И, наконец, для подготовки графических ресурсов я использую пару редакторов. Растровые PNG-изображения я готовлю с помощью GIMP, а векторные SVG-материалы — с помощью InkScape.

Технологии, которые потеряли былую привлекательность

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

Adobe Photoshop и Illustrator. Это — два замечательных приложения, которые многие годы удовлетворяли все мои потребности в работе с графикой. Я с грустью говорю им «прощайте» и благодарю их за то, что они были со мной. Теперь всё, что мне нужно, дают их бесплатные опенсорсные заменители.
jQuery. Эта библиотека стала ненужной тогда, когда закончились войны кросс-браузерной совместимости. Единственной ценнейшей для меня возможностью jQuery был синтаксис селекторов. Он оказался настолько востребованным, что в 2009 году был добавлен в DOM в виде querySelector.
AJAX. Этот прародитель Web 2.0. теперь превратился в пережиток прошлого. API XMLHttpRequest заменяется современным и более простым API fetch, а JSON приходит на замену XML.
SASS/SCSS. Я признаю то, что написание CSS-кода без переменных было неэффективным, в результате SASS многим пришёлся по душе. И модули тоже были весьма важной возможностью. Но в итоге для того, чтобы всё это использовать в JavaScript, нужно было потратить слишком много времени и сил. При этом, наряду с развитием вспомогательных инструментов для работы со стилями, стандарт CSS тоже не стоял на месте. В результате различные средства для преобразования CSS-кода постепенно уходят в прошлое.
БЭМ. Схема именования сущностей БЭМ (Блок, Элемент, Модификатор), используемая при формировании имён CSS-классов, решает проблему глобального пространства имён. Но за это приходится платить использованием очень длинных конструкций. Я перешёл к родительским/дочерним селекторам в семантических элементах, предпочтя более лёгкий подход идентификаторам и именам классов.

Например:
```
header > ul > li {
   ...
}
nav > ul > li {
   ...
}
footer > ul > li {
   ...
}
```
Шрифты Georgia и Verdana. Эти два шрифта многие годы занимали верхнюю позицию моего рейтинга шрифтов. Я мог положиться на их доступность и на их читабельность. Но после того, как появилось правило @font-face, и после того, как начали распространяться опенсорсные шрифты, я стал пользоваться подобными шрифтами.
Babel, Grunt, Gulp, Browserify, WebPack. Первые четыре пункта в этом списке вряд ли кого удивят. Но почему мой стек веб-технологий покинул Webpack? У того, что этот бандлер потерял для меня актуальность, есть некоторые причины, на которых я остановлюсь подробнее:
1. До появления HTTP/2 с поддержкой постоянных соединений и мультиплексирования потоков мы находились в зависимости от возможностей этих инструментов по сборке бандлов ресурсов приложений. Но бандлинг ничего нам не даёт в мире, где есть HTTP/2.
2. Стандарт ECMAScript 2015 был новым словом в JavaScript-разработке, все бросились использовать новые возможности языка в тот самый момент, когда они увидели свет. Однако тут была одна проблема. Код, написанный с использованием новых возможностей, не поддерживался браузерами. Поэтому его приходилось транспилировать в ECMAScript 5-код. В этом деле мы полагались на Babel, его применение стало стандартным шагом подготовки веб-проектов к публикации. Сегодня же все необходимые мне новые возможности языка доступны буквально повсюду. В результате Babel мне больше не нужен.
3. До появления в браузерах возможности динамического импорта модулей код приходилось транспилировать в формат CommonJS. Теперь же большинство основных браузеров поддерживает <script type='module'> (да и Edge 76+ скоро подтянется). В результате скоро мы сможем поздороваться с ECMAScript-модулями и попрощаться со всем остальным.
JSX. Я не понимаю тех, кто полагает, что JSX — это хорошо. И «Но вы же к этому привыкли» для меня — не аргумент.
Функциональное программирование. Я ограничил применение функционального программирования в своём коде до простых однострочных конструкций вроде numbers.sort((a, b) => a - b);. Для всего остального я использую объектно-ориентированное программирование.

Технологии, которые стали фаворитами

Вот обзор тех уровней моего технологического стека, которыми я особенно впечатлён:

JavaScript-модули. Модули отлично зарекомендовали себя в серверном JavaScript-коде. И я безмерно рад тому, что наконец могу использовать их и на стороне клиента.
Объектно-ориентированный JavaScript. Вот пять золотых правил объектно-ориентированной JavaScript-разработки:
1. Заменяйте анонимные объекты именованными классами.
2. Объявляйте и инициализируйте все свойства объектов в конструкторах.
3. Защищайте объекты от изменений сразу после создания.
4. Объявляйте методы с неизменными сигнатурами.
5. Привязывайте this к каждому коллбэку.
Blue Phrase. Эта система позволяет мне пользоваться декларативным подходом при создании шаблонов и при подготовке различных материалов. Она превращает написание качественного HTML-кода в сплошное удовольствие.

Итоги

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

Уважаемые читатели! А какой он — ваш стек веб-технологий 2020 года?

Дисклеймер от переводчика: Blue Phrase, Read Write Serve и Read Write Doc — технологии, разработанные автором данной статьи. Скачивание и установка — на ваш риск.

Комментарии (101)

ikle
24.12.2019 12:57
#21054710
+3
2020 год — это начало нового десятилетия.
Люди так и не научились считать: 2020-ый — это конец десятилетия, точно так же, как 2000-ый — конец тысячелетия. Да ладно с большинством, но люди технических специальностей?

Самое интересное, что в нашем детстве все прекрасно понимали разницу между Васе пятый годик, а Ане уже пять лет… а к школе как-то резко забыли всё.
1. Cryvage
  24.12.2019 14:43
  #21055288
  +14
  Для программистов нормально начинать счёт с нуля.
  1. ikle
    24.12.2019 15:21
    #21055482
    -6
    Мне казалось, что для программистов важно думать головой: во-первых, нуля как числа не существовало в европейской цивилизации, когда была придумана, принята и распространилась данная система летоисчисления, как следствие — используются порядковые числительные.
    
    нормально начинать счёт с нуля
    Норма — понятие весьма расплывчатое и изменчивое. Да и во многих языках программирования индексация до сих пор идёт с единицы.
    
    P.S. Похоже, всё ещё хуже, чем я думал.
    
    boolive
    24.12.2019 17:26
    #21056258
    +5
    Меня смущает, почему годы, часы, минуты, секунды мы пишем с нуля, а дни и месяцы нет о_О В первый день должна быть дата 00.00.2020 =)
    
    savostin
    24.12.2019 18:07
    #21056498
    Русский язык всё объясняет:
    (прошло) 0 часов 0 минут
    (от) первого января
    2000 года
    
    boolive
    24.12.2019 18:19
    #21056556
    Прошло 0 дней 0 месяцев, на календаре 01.01.2020
    
    savostin
    24.12.2019 18:25
    #21056586
    -2
    Прошло 10 минут первого января — на календаре все правильно ;)
    
    boolive
    24.12.2019 18:53
    #21056670
    +4
    Прошло 10 минут первого часа — на часах 0, а не 1
    
    s_suhanov
    24.12.2019 19:54
    #21056900
    +1
    И поэтому часы показывают 10 минут. Потому что эти 10 минут уже прошли. Тут все логично. Но календарь показывает уже 1 января, хотя 1 января еще в процессе, и не прошло.
    
    ikle
    24.12.2019 21:07
    #21057110
    почему годы, часы, минуты, секунды мы пишем с нуля
    Это новодел цифровой эры: раньше писали не 00:15, а четверть первого, а вместо 00:00 — полночь (минуты вообще не писались). Ну не было такого числа как ноль, не было. И потому нет на классическом циферблате часов нуля.
    
    P.S. Ещё и карму слили молча несогласные — хоть бы аргументировали.
    
    maggg
    24.12.2019 21:07
    #21057112
    Не пишем мы годы с нуля. Не было нулевого года, сразу же был первый. Не было нулевого века, сразу же был первый. А часы, минуты и секунды действительно отличаются от дней, месяцов, лет и веков. Для них принято записывать не какая секунда, минута или час идёт по счёту прямо сейчас, а сколько полных успело пройти до текущего момента. Хотя и здесь иногда допустимо сказать, что «идёт одиннадцатый час». Это значит, что на часах десять полных часов и какое-то количество пройденных минут.
    
    maggg
    24.12.2019 21:08
    #21057122
    И в твоей логике первый день наступающего года должен обозначаться так: 00.00.2019. Потому что пройдёт ноль дней, ноль часов и 2019 лет с начала отсчёта времени.
    
    boolive
    24.12.2019 22:19
    #21057352
    +1
    В моей логике как на линейке, отсчёт с нуля. Понял что годы, месяцы и дни имеют точку отсчёта с единицы. Время с нуля. Понятно, но для летоисчисления непривычно.
1. Crimento
  24.12.2019 15:55
  #21055644
  А я вот с раннего детства негодовал, почему 01:30 это пол второго, если отчёт времени начинается с нуля, а не с единицы.
  1. Whuthering
    24.12.2019 17:27
    #21056262
    В английском с этим проще, там half past one :)
    
    411
    24.12.2019 19:34
    #21056840
    Ну half to two в принципе корректно, хоть и не распространено
    
    JediPhilosopher
    24.12.2019 21:45
    #21057236
    Зато в английском 12pm это внезапно полдень, а не полночь. И наоборот, 12 am это полночь. Т.е. 12 am следует не после 11 am, а перед 1 am. Это вообще мозг взрывает.
  1. TheYellingChives
    24.12.2019 17:34
    #21056306
    -1
    На часах 12 делений, никаких нулей.
  1. maggg
    24.12.2019 21:10
    #21057128
    Зря негодовали. В 01:30 с полночи прошёл один полный час и ещё половина второго часа.
1. Du-X
  24.12.2019 16:29
  #21055834
  +6
  Отсчет времени начинается с нуля. Сутки с нуля, исчисление лет с нуля… Человек родился и ему 0 лет. Лет 0, но он уже есть. Когда ему (человеку) 1 год — это говорит о том, что прошел год с даты его рождения. Также и тут — 01.01.2020 00:00:01 начало десятилетия. В 2021 пройдет 1 год от начала десятилетия. Элементарно же.
  1. doozza
    24.12.2019 17:11
    #21056156
    +1
    Как минимум не элементарно.
    На часах 0:30, мы говорим «половина первого (часа)». С начала суток прошло ноль часов и ещё половина часа. Чувствуете, в чём подвох? Прошло ноль часов, но говорим «половина первого часа».
    Далее мы говорим, что живём в 2019-м году. В две тысячи девятнадцатом году. Сколько лет прошло с начала эры? По аналогии с часами нужно сказать, что две тысячи восемнадцать полных лет, и записывать их как 24.12.2018.
    
    Сутки с нуля, исчисление лет с нуля…
    
    Cогласно григорианскому календарю, нулевого года не существует [2 до н.э., 1 до н.э., 1 н.э.]. То есть ребёнку может быть ноль лет, а нашей эре сразу стал один год.
    ru.wikipedia.org/wiki/0_год
    
    И товарища ikle сверху слили ни за что. Первое десятилетие — это годы 1,2...10. Начало второго десятилетия — это 11-й год. Также и 2021-й год будет началом нового десятилетия.
    
    maggg
    24.12.2019 21:15
    #21057144
    Аналогия с ребёнком неверная же. Ребёнку действительно может быть ноль лет. Это значит, что идёт первый год его жизни. Нашей эре тоже было ноль лет! И при этом шёл первый год её жизни. Вся путаница в том, что в случае возраста мы отвечаем на вопрос «сколько лет», то есть сколько полных лет уже прошло, а в случае с нумерацией годов на вопрос «который год идёт по счёту».
    
    dom1n1k
    24.12.2019 21:37
    #21057210
    Короче: не надо путать момент и период.
    
    Du-X
    25.12.2019 07:55
    #21058242
    ISO 8601 развеял мои сомнения. Действительно я был не прав. Выходит, что календарная дата (годы, дни, месяцы) указывает на то, какой по счету период начался. А время (часы, секунды) и возраст указывают на количество завершенных периодов.
  1. Nickrus
    24.12.2019 17:21
    #21056224
    +1
    Нет. Количественные существительные можно начинать с нуля, потому что минимальное количество это ноль. А порядковые начинают с «первого», потому что если у тебя что-то есть (дети, прожитые годы, байты) — то минимально имеющееся количество это один, и порядковое существительное будет «первый».
    Поэтому родившемуся человеку ноль лет, он начинает проживать свой ПЕРВЫЙ, а не нулевой год. Когда с нулевой точки прошло ещё ноль лет, был ПЕРВЫЙ год нашей эры. Когда с нулевой точки нового десятилетия не пройдёт ещё и года, будет идти 2021-ый год.
  1. Virviil
    24.12.2019 17:22
    #21056228
    +1
    "ноль лет" и "нулевой год" — это разные вещи.
    В тот момент, когда "родился Иисус" начался его "первый год" а вовсе не нулевой. Соответственно, в тот момент, когда 10 лет закончились, начался "одиннадцатый год".
    Достаточно очевидно, что "нулевой год" вообще не существует, потому что такая конструкция не имеет смысла, в отличие от "нуля лет". Соответственно, декады, века, тысячелетия заканчиваются в конце 0, *0, **0 года.
    
    Подробнее можете почитать на википедии. Элементарно же!
  1. me21
    24.12.2019 17:33
    #21056300
    Да нет, самое первое десятилетие нашей эры начиналось с первого года. Нулевого года не было же.
1. boolive
  24.12.2019 17:19
  #21056214
  Если бы родились в 0 лет н.э., то в 2020 говорили бы — вам 2021 годик пошел, но лет вам 2020 :)
  1. Virviil
    24.12.2019 17:23
    #21056234
    0 год нашей эры не существует. пруф
    
    boolive
    24.12.2019 17:43
    #21056356
    Негодяи григорианцы!
1. Ogra
  24.12.2019 20:31
  #21056998
  Десятилетие, это просто временной промежуток длиной в десять лет, мы вольны выбирать точку отсчета. В 2020 начнутся двадцатые года. В 2021 начнется третье десятилетие 21 века. В Википедии была дискуссия на эту тему.
  1. ikle
    24.12.2019 21:27
    #21057176
    +2
    мы вольны выбирать точку отсчета
    Можно, вот только мы уже выбрали точку отсчета — начало первого года н.э. (или от РХ). А в текущем виде у нас два лагеря с двумя разными точками отсчёта.
    
    Википедии была дискуссия на эту тему.
    А вот это хорошая ссылка: не в том, что это ссылка на Wikipedia (это не reference source), а в том что в конце этого обсуждения есть ссылка на ГОСТ ИСО 8601-2001 (а это уже reference source) «Представление дат и времени»:
    
    Пункт 2.30: «Век (в григорианском календаре): Календарный год, номер которого кратен ста, начиная с 01 года. Каждый век имеет порядковый номер — 1-й век начинается с 0001 года».
    
    Пункт 2.35: «Календарное тысячелетие: Период времени в 1000 календарных лет, начиная с 01 года. Каждое тысячелетие имеет порядковый номер — 1-е тысячелетие (с 0001 г. по 1000 г. включительно). Третье тысячелетие начинается с 2001 г. по 3000 г. включительно».
    Ну и вывод по результатам дискуссии:
    
    К сожалению, в стандарте отсутствует понятие «десятилетие». Поэтому в статьях о десятилетиях произошла подмена понятий — десятилетие как 1/10 часть века (например, с 2001 по 2010 год) и «нулевые», или «2000-е годы» года (с 2000 по 2009 год), где 2000-й год на самом деле вообще относится к предыдущему веку.…
    
    Никто не оспаривает существования понятия «2000-е годы». Проблема совсем в другом — как в Википедии, называющей себя энциклопедией, давать статьи о десятилетиях — давать ли их в календарном понятии, как первое десятилетие XXI века (2001—2010 годы) или в некалендарном понятии — (2000—2009 годы). ...
    P.S. Скоро я, видимо, потеряю возможность отвечать .)
    
    technic93
    25.12.2019 00:58
    #21057730
    P.S. Скоро я, видимо, потеряю возможность отвечать .)
    Обычное дело для кармы и общества в целом, сначала осуждаем, потом разбираемся. Значит надо в каждом сообщении излишне разжовывать, чтобы разобратся мимопроходилам было легче.
    
    Lord_Ahriman
    25.12.2019 18:00
    #21060574
    +1
    надо в каждом сообщении излишне разжовывать
    
    Надо мимокродилам читать, что пишут, и вникать, а не начинать с улюлюканьем закидывать человека камнями и оплевывать его «за компанию»
    
    Ogra
    25.12.2019 06:47
    #21058146
    Можно, вот только мы уже выбрали точку отсчета — начало первого года н.э. (или от РХ). А в текущем виде у нас два лагеря с двумя разными точками отсчёта.
    
    Смотрите, 2020 год начнется 1 января 2020 года, неделя длится семь дней. Вопрос — когда начнется вторая неделя 2020 года?
    
    Восьмого января, или седьмого?
    Шестого. В понедельник, спустя пять дней после начала 2020 года.
    
    ainoneko
    25.12.2019 08:24
    #21058288
    Вопрос — когда начнется вторая неделя 2020 года?
    Зависит от значения слов «вторая неделя» («вторые семь дней» или «то, что кончается выходными (концом недели)») и «начнётся».
    Во многих странах неделя начинается с воскресенья, что даёт ещё один вариант.
1. maggg
  24.12.2019 21:20
  #21057154
  Поймал себя на том, что ровно двадцать лет назад вёл в интернетах такие же точно беседы с такой же точно аргументацией по поводу «миллениума». :)
  1. demin
    25.12.2019 04:29
    #21058030
    Меня тогда убедил пример с ящиком водки, который на 20 бутылке заканчивается, а новый начинается с 21.

Kerlaeeda
24.12.2019 12:57
#21054716
+1
Видимо вы очень счастливый человек, если можете использовать модули без полифилов, да еще и отказавшись от сборщика. Хотелось бы увидеть проект, требования к которому позволяют использовать ваш стек на следующий год)
1. hrie
  24.12.2019 13:13
  #21054820
  Это перевод, боюсь вам никто не ответит )
  1. Kerlaeeda
    24.12.2019 16:14
    #21055754
    Не заметил, спасибо)

hrie
24.12.2019 12:57
#21054718
+1
Какой-то человек из 2012 года прощается с jQuery, Grunt, Верданой и привязывает this к каждому коллбеку? Как мило.

Valsha
24.12.2019 13:34
#21054950
Интересно, о сервере «Read Write Serve» и не слышал. Посмотрим что за зверь :) Спасибо за перевод.
1. justboris
  24.12.2019 14:16
  #21055150
  нашли что-нибудь? Мне по этому запросу находится только оригинал этой статьи
  1. kemsky
    24.12.2019 14:30
    #21055232
    +2
    Это рекламная статья, сервер этот тут https://rwserve.readwritetools.com/, но качать его стремновато.
    
    TheYellingChives
    24.12.2019 16:34
    #21055888
    +4
    Скачал кстати, после распаковки архива меня в убунте разлогинило… Вот ща стрёмно чёто стало
    
    chupasaurus
    24.12.2019 19:34
    #21056836
    «Я за ~~джва~~джесять лет использования Апача выработал стойкую неприязнь к Nginx, поэтому буду крутить всякую экзотику»

beduin01
24.12.2019 14:28
#21055226
-1
Судя по новостям тот же Dart/Flutter сможет заменить все это если не в 2020, то в 2021 году точно.
Во всяком случае концепция: отдельно сайт, отдельно мобильное приложение скоро отомрет.
1. androidovshchik
  24.12.2019 18:45
  #21056652
  +1
  Да, будет монстр вместо сайта наподобие эффекта electron для десктопа. Переубедите меня)
  1. beduin01
    24.12.2019 19:51
    #21056884
    Ну во первых хуже электрон нужно постараться. А во-вторых Flutter ни чем не хуже того же React. Более того теоретически он может быть более быстрый и компактный
1. epishman
  24.12.2019 21:51
  #21057256
  Я ковырял палочкой. Машина Dart медленней V8, а декларативный дизайн виджетов Flutter без даже намека на CSS напоминает какое-то ретро-садо-мазо. После ядерной войны допускаю взлет Flutter для WEB, но для этого должны погибнуть все WEB-дизайнеры.
  1. stilic
    24.12.2019 23:08
    #21057478
    Я ковырял палочкой. Машина Dart медленней V8
    
    Вы имеете ввиду ту VM-машина Dart, что используется только для отладки?
    Или речь о том, во что компилируется Dart в production?
    
    epishman
    25.12.2019 03:22
    #21057970
    А разве есть разница? Я просто себе поставил ноду и Dart, консольный, под линуксом, написал пару парсеров, и получилось что как числодробилка он раза в полтора медленнее ноды и в два — джавы. Возможно, на андроиде оно быстрее работает, гугл же заявляет у флаттера какой-то фантастический rate, тут я уже не знаю как померить.
    PS
    Скорее, screen rate у флаттера хороший не из-за дарта, а из-за концепции иммутабельности виджетов (можно кэшировать по конструктору), ну и вроде отсутствие каскадности CSS сильно ускорило (они так сами пишут).
    
    beduin01
    25.12.2019 07:08
    #21058168
    Я вас читаю давно. Со многим полностью согласен. Но скорость они скоро подтянут и если приложат усилия ноду смогут легко обойти. Где то примеры tree shake видел дарта и ноды. Преимущество за дартом
    
    epishman
    25.12.2019 11:19
    #21058888
    Это понятно, типизация дает больше возможностей для оптимизации. Хотя мне лично синтаксис TS / Котлина ближе, мода на джаваподобие похоже прошла.
    
    stilic
    25.12.2019 10:15
    #21058628
    А разве есть разница?
    
    Есть.
    Для веб-фронтенда — там всё в обычный JS преобразуется. Причем, как уверяют, даже более оптимальным образом, нежели это было написано на JS изначально.
    На Android — в native.
    
    То, что вы замерили — это использование Dart на бэкенде, а там оно и не продвигается как «революционное».
    
    epishman
    25.12.2019 10:38
    #21058706
    Да нет, я же не про веб, а про standalone, консольный dart, такой есть у них, вряд-ли это обертка над v8, хотя не проверял.
    
    stilic
    25.12.2019 10:49
    #21058756
    такой есть у них, вряд-ли это обертка над v8, хотя не проверял.
    
    Можно явно перегнать с помощью dart2js и проверить такой вариант насчет эффективности Dart
    
    epishman
    25.12.2019 10:54
    #21058782
    Надо бы бенч сделать и статью запилить, если будет не лень…
1. pesh1983
  25.12.2019 10:23
  #21058656
  "Будет одно сплошное телевидение..." (с)
1. Fedcomp
  25.12.2019 17:29
  #21060464
  Эта штука уже называется React native. Что то я не вижу чтобы на него массово переходили.

kavarzin
24.12.2019 14:42
#21055280
+12
Blue Phrase, Read Write Serve и Read Write Doc — технологии разработанные автором статьи. Ничего плохого сказать не хочу, но аргументация в статье хромает на обе ноги. Очень похоже на то, что это обычное продвижение собственного продукта
1. denisshabr
  24.12.2019 15:13
  #21055446
  Оба сайта с этими технологиями лежат. Хабр/Medium-аэффект?

Enmar
24.12.2019 16:15
#21055756
-1
В каком мире живет автор оригинала, если он не использует Babel?
Про минификацию скриптов тоже не понятно — http2 явно не у всех поддерживается.
1. sumanai
  25.12.2019 14:39
  #21059746
  http2 про объединение, про минификацию это сжатие.

TheYellingChives
24.12.2019 16:16
#21055762
+1
Всё очень плохо. Смотрел сайт и «технологии» автора, разбил лицо фейспалмом.
1. m_vash
  24.12.2019 16:33
  #21055870
  реально странная статья. Видел ее еще на инглише и хотел к себе на тг-канал запостить, но она мне показалась реально больше рекламной

QSandrew
24.12.2019 16:35
#21055898
+2
Мой стек веб-технологий. HTML+CSS+JS, а остальное всё меняется.
1. somebody4
  24.12.2019 19:03
  #21056708
  Надо бы J заменить на T, сразу полегчает.
  1. 0xd34df00d
    25.12.2019 02:16
    #21057884
    Я вообще TS заменил на Haskell и генерирую сайты статически, либо в худшем случае Servant'ом их.
    
    somebody4
    26.12.2019 18:03
    #21064232
    Судя по счёту -2 vs -3, TS победил.
    
    Хотя не очень понятно как статические сайты без client-side логики могут конкурировать с каким-нибудь фреймворком, типа ангулар. Или как в 1996, любой чих, идём ан сервер страницу перегенерировать?
    
    0xd34df00d
    26.12.2019 18:25
    #21064338
    Ну вот у меня есть три сайта: блог, сайт опенсорс-проекта (раньше был на друпале, но пхп сложный, я с шестого друпала на 7-8 мигрировать не смог), и что-то вроде почившего сохабра. Если про третий ещё можно поспорить (и там, собственно, сервант), то зачем первым двум клиентская логика?
    
    А перегенерировать — нуу, написал новый пост в блог, сделал ./regen.sh, который и сайт перегенерировал (только изменённые страницы — скажем, саму страницу с постом и страницу со списком постов по упомянутым тегам), и по rsync на сервер все залил. Зато все в гите, удобно, и логика построения и навигации по сайту на привычном мне языке.
    
    И, кстати, так как все в гите, можно было бы вообще обмазаться, скажем, github actions, чтобы оно там по коммиту все деплоило само, но меня не настолько напрягает руками вызвать шелл-скрипт.
    
    А так как оно на привычном и адекватном general-purpose-языке, то я могу делать вообще произвольные вещи, от адекватного управления коллекцией скриншотов на сайте опенсорс-проекта, с автогенерацией версий в webm, до залезания в гит-репу проекта и вычленения актуальных версий зависимостей для генерации страницы с инструкциями для сборки.
    
    somebody4
    26.12.2019 18:53
    #21064436
    Для ваших собственных небольших сайтов понятно что можно хоть как сделать, работать будет. Я даже в конце 90-х занимался чем-то подобным, типа статическая SMS. Но для тех сайтов которые требуют некоторой логики на клиенте, даже банально сделать валидацию, тут уж хаскель не поможет. Только если какой-нибудь транспайлер напилить.
    
    Ну и честно говоря, при всеё привлекательности идей заложенных в хаскель, существует огромная проблема, которая ставит крест на его практическом применении в почти что всех проектов, это то что если апологет хаскеля свалит с проекта, то будет банально некому подхватить упавшее знамя.
    
    И подобные риски никто не желает на себя взваливать.
    
    0xd34df00d
    27.12.2019 03:19
    #21065442
    Но для тех сайтов которые требуют некоторой логики на клиенте, даже банально сделать валидацию, тут уж хаскель не поможет. Только если какой-нибудь транспайлер напилить.
    Ну есть же ghcjs, например, который в js компилирует (правда, я с ним не игрался).
    
    Ну и честно говоря, при всеё привлекательности идей заложенных в хаскель, существует огромная проблема, которая ставит крест на его практическом применении в почти что всех проектов, это то что если апологет хаскеля свалит с проекта, то будет банально некому подхватить упавшее знамя.
    Если вкратце, то, по моему опыту, выбор вещей типа C++ или Python или ещё чего от этого не страхует вот вообще, совсем. Даже, наверное, наоборот — я неоднократно видел, как питоноподелия переписывали с нуля даже знающие питон люди, так как поддерживать или хотя бы рефакторить то было невозможно.
    
    А я не так давно за час въехал в совершенно незнакомый проект (Хактоберфест же!), который видел впервые, запилил туда фичу, про которую в первый раз слышал, и отправил (успешно принятый) PR.
    
    Да и Haskell в резюме у людей я вижу почаще, чем какой-нибудь Go, а про него так не говорят.
    
    И подобные риски никто не желает на себя взваливать.
    Мой текущий и прошлые работодатели с вами совсем не согласятся.
    
    Аргумент непопулярности был использован всего один раз, но то было в рамках некоторых подковёрных игр. Технология дала лишь повод, но не причину.
    
    somebody4
    28.12.2019 17:07
    #21068560
    Если вкратце, то, по моему опыту, выбор вещей типа C++ или Python или ещё чего от этого не страхует вот вообще, совсем. Даже, наверное, наоборот
    Если мы говорим в среднем, то скорее всего страхует. Граничные случаи будут конечно встречаться.
    
    А я не так давно за час въехал в совершенно незнакомый проект
    В случае хаскеля, если проект начинает энтузиаст своего дела, то опять же в среднем, уровень программиста будет выше, чем в среднем для какого-нибудь питона. Что положительно скажется на качестве кода в проекте.
    
    Но если перехватывать будет коллекга, который первый раз видит это чудо и которого попросили быстренько пофиксить что-то, то результат будет более менее-пердсказуем.
    Мой текущий и прошлые работодатели с вами совсем не согласятся.
    Ничего не значит, может у вас там рота хаскелистов, тогда это не проблема.
    
    0xd34df00d
    27.12.2019 23:37
    #21070220
    Что положительно скажется на качестве кода в проекте.
    Качество кода там, кстати, так себе, не топчик, но то такое.
    
    Ничего не значит, может у вас там рота хаскелистов, тогда это не проблема.
    Не, обычные совершенно места, где в основном люди пишут на плюсах и просто немножко вертят головой по сторонам (правда, больше в сторону какого-нибудь раста).

Neveil
24.12.2019 18:11
#21056518
Что за Read Write Serve? Не гуглится, оригинале также.
1. ffs
  25.12.2019 12:28
  #21059148
  Какая-то платная срань rwserve.readwritetools.com
  1. Neveil
    25.12.2019 13:03
    #21059314
    Спасибо, ваш уровень гугления выше моего)

PaulIsh
24.12.2019 18:23
#21056572
Возникает такое ощущение, что в экосистеме NPM имеются пакеты на все случаи жизни.

При этом качество поддержки и часто самих NPM пакетов бывает весьма плачевное, особенно если нужна всякая экзотика. Столкнулся при работе с федерацией через SOAP:
— node-soap, strong-soap годятся только после серьезной доработки напильниками,
— xml-crypto — в недоделанном полу-заброшенном состоянии,
— node-gost и его предок gostcrypto в заброшенном состоянии — пришлось потратить массу времени для нормальной работы с гост-2012

Vadem
24.12.2019 18:48
#21056656
Сервер Express казался мне чрезвычайно простым инструментом, но лишь до тех пор, пока я не попытался воспроизвести в нём весь тот функционал, который давал мне Apache.

Так не нём это не предполагается делать.
Перед ним обычно какой-нибудь Nginx стоит.

Вообще похоже что автор большой велосипедист.
Изобрёл Nginx, Jade и Wiki, но проприетарные и пытается это продать.

stilic
24.12.2019 19:11
#21056760
+1
Автор упоминает Blue Phrase.
Не гуглится.
Кто-нибудь подскажет, где на это можно взглянуть?
1. somebody4
  24.12.2019 19:17
  #21056778
  +4
  Если что-то не гуглится, то наверное это к лучшему.
  
  И если количество найденых упоминаний меньше тысяч ста, то наверное тащить это в продакшн не стоит.
  
  ru_vds наверное стоило бы удалить эту статью, как неприкрытую рекламу чьих-то поделок. Ну или по крайней мере дисклаймер написать.
  1. ru_vds Автор
    24.12.2019 20:14
    #21056962
    Решили статью все же оставить, дисклеймер добавили.
    
    ReDev1L
    24.12.2019 21:16
    #21057146
    +1
    Дисклеймер пишут в начале, я например скипаю всё что после итогов.
    
    FTOH
    25.12.2019 18:19
    #21060640
    +1
    А я вот дочитал, но после банера с рекламой не заметил дисклаймера и узнал о нем только из комментариев.
  1. Tangeman
    24.12.2019 21:21
    #21057162
    И если количество найденых упоминаний меньше тысяч ста, то наверное тащить это в продакшн не стоит.
    
    Когда-то и React или Vue не гуглились и упоминаний почти не было, равно как и всё остальное (к примеру, Rust или Go). Если следовать такой логике, то ничто новое вообще шансов на жизнь получит, хотя бы потому что вне продашкн не откатать действительно важные вещи.
    
    Это не в защиту «стека» из статьи, это к тому что гугление и популярность не являются показателем надежности, качества, скорости или чего-то ещё — достаточно вспомнить популярность PHP несмотря на все его недостатки на протяжении более чем 10 лет, или даже сам JS — я ещё помню времена когда его гнобили, причём было за что.
    
    somebody4
    24.12.2019 21:31
    #21057188
    Вообще то это написано для адекватных людей, которые не желают быть морской свинкой (в том числе и с React или Vue в начале их жизни).
    
    Если вы понимаете зачем вам нужен хайповый проект, про который никто, нигде не знает, то это ок.
    
    Или если вы используете его на «продакшн» — своём пет-проекте или на проекте который если будет выключен на пару недель, никто и не заметит.
    
    Но экспериментировать на реально используемом проекте, это сильно на любителя.
    
    Tangeman
    24.12.2019 21:54
    #21057272
    При правильном подходе можно делать боевые приложения на новой (и вообще почти любой) технологии, в то время как популярность и распостранённость сами по себе не гарантируют ничего (посмотрите хотя бы на некоторые чрезвычасно популярные приложения на PHP).
    
    somebody4
    24.12.2019 22:57
    #21057456
    Ещё раз повторюсь — для людей, которым надо предсказуемый результат, за предсказуемые затраты, надо выбирать майнстрим решения.
    
    А так то конечно при _правильном_ подходе можно делать всё что угодно.
    
    justboris
    24.12.2019 22:30
    #21057380
    хайповый проект, про который никто, нигде не знает
    Оксюморон какой-то. Хайп – это как раз про то, что о проекте трубят на каждом углу, поэтому о нем все знают.
    
    Наверное, вы хотели сказать "хипстерский"? Это как раз про непопулярные проекты не для всех.
    
    somebody4
    24.12.2019 23:00
    #21057462
    Да не очень внятно получилось. Имелось в виду хайповый проект, которые ещё не вошел в маинстрим. Т.е. про него уже много говорят и как бы круто на нём что-то запилить, но он еще не вырос из детских штанишек.
1. Dee3
  25.12.2019 00:09
  #21057642
  Гуглится если добавить html к запросу.
  
  Мне вообще не понятно как надо одичать чтобы посты в блоге оформлять через CSS.
1. plus_stick
  25.12.2019 06:45
  #21058144
  bluephrase.com

Northerner19
25.12.2019 00:13
#21057650
По большому счету тут все для фронта, а есть инсайд для чистого бекенда?
1. Clasen01
  25.12.2019 04:29
  #21058032
  В статье же написано, что на сервере node и mariaDB

kolkoni
25.12.2019 06:34
#21058134
Спорная статейка

v1000
25.12.2019 11:20
#21058890
я правильно понял, что, по тому как их придерживались, веб стандарты появились только сейчас, а раньше это были так, веб рекомендации?

botyaslonim
25.12.2019 11:34
#21058948
AJAX. Этот прародитель Web 2.0. теперь превратился в пережиток прошлого. API XMLHttpRequest заменяется современным и более простым API fetch, а JSON приходит на замену XML
— картинка в стиле «Кровь из глаз» по своему вкусу.
Вообще, более хайповой статьи выдумать сложно, хотя ru_vds часто провоцирует сообщество

akubintsev
25.12.2019 13:03
#21059312
Очень ~~интересно~~ и нифига не понятно

3263927
26.12.2019 12:04
#21062684
C# VS2919 js/jQuery Vue EF .net core 3.1 xamarin SVG