Помните те времена, когда стеки веб-технологий были простыми? Когда уровни этих стеков можно было обозначить в виде четырёхбуквенного сокращения вроде LAMP, LEMP или LEPP? Когда всё, что было нужно для создания и поддержки сайтов, сводилось к вполне обычному железу, к какому-нибудь опенсорсному софту, да к упорству в достижении цели?
Мой первый успешный сайт, теперь уже старинный проект 1999 года, был создан с использованием технологий, которые можно пересчитать по пальцам одной руки: HTML4, CSS2, JavaScript3 и Apache 1.1. Всё это крутилось на сервере с Linux 2.0. Сайт включал в себя 38000 страниц. И сегодня, через 20 лет, он всё ещё их выдаёт.
![](https://habrastorage.org/webt/xn/yn/nd/xnynndngv2phbo4io6g7eguegea.jpeg)
С тех пор всё изменилось. Это касается и стеков веб-технологий. Теперь они совсем не те, что прежде.
Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о том, как он перешёл от «фуллстека» к «стеку 2020 года». Некоторые технологии в ходе этого путешествия неожиданно стали фаворитами, а некоторые потеряли былую привлекательность.
2020 год — это начало нового десятилетия. Это — время, когда стоит поговорить о новом стеке веб-технологий.
На что похож «стек 2020 года»? Надо сказать, что на это очень сильно влияет то, чего пытается достичь разработчик сайтов. Выбор подходящих уровней сильно зависит от того, какая степень масштабируемости требуется для проекта.
Меня особенно интересуют маленькие веб-сайты. Те, которые хорошо чувствуют себя на виртуальном сервере. Таким сайтам не нужны балансировщики нагрузки или постоянные хранилища данных. Это — ниша CMS, которую уже давно занимает WordPress. Но в основе всего этого лежит не некий минималистичный сервер. Вместо этого речь идёт о системе, которая может выдержать постоянный поток трафика без необходимости автоматического повышения её мощности в часы пик.
Сейчас для разработки и поддержки проектов в интересующей меня области я использую стек технологий, состоящий из 12 уровней.
Базой моего стека является облачный провайдер, который учитывает потребности тех, кто привык сам заниматься тонкими настройками сред, в которых выполняются их веб-проекты. Я пользовался собственными серверами до тех пор, пока стоимость их поддержки не стала слишком высокой. Аренда места в серверной стойке, выделенный IP-адрес, обеспечение нужной полосы пропускания… Всё это вносит вклад в месячную стоимость физического сервера. Но настоящий «вымогатель» — это стоимость электричества. Облачные провайдеры гораздо дешевле, чем $1.25 в день, которые я отправлял поставщику электроэнергии. Отказ от подобных трат позволил мне сэкономить сотни долларов в год.
Безопасность — это то, что очень сильно всех нас беспокоит. SELinux можно сравнить с мощной охранной системой, работающей в Linux. Если к этому добавить ещё и хорошо настроенный iptables-файрвол, получится то, что позволит владельцу сайта спокойно спать по ночам. Если вы не уверены в том, что вам всё это нужно — проведите следующий эксперимент. Разверните новый сервер у вашего любимого облачного провайдера и понаблюдайте за тем, как скоро его начнут атаковать. Я видел, как брутфорс-атаки на новые сервера с попытками входа по SSH начинались менее чем через 10 минут после их создания.
Я пользуюсь веб-сервером Read Write Serve с TLS-сертификатами от LetsEncrypt. Раньше я был фанатом Apache, на настройку и запуск новых веб-сайтов у меня уходило буквально несколько минут. Но с тех пор, как я перешёл с PHP на JavaScript, об Apache пришлось забыть. Сервер Express казался мне чрезвычайно простым инструментом, но лишь до тех пор, пока я не попытался воспроизвести в нём весь тот функционал, который давал мне Apache. Речь идёт о механизме согласования содержимого, об условном кэшировании, о сжатии данных, о перезаписи URL для SEO, о CORS, о политиках защиты контента. В результате я и перешёл на сервер Read Write Serve, в котором все эти возможности присутствуют по умолчанию.
За логику приложения, выполняющуюся на сервере, отвечает среда Node.js. Возникает такое ощущение, что в экосистеме NPM имеются пакеты на все случаи жизни. Поэтому простыми и понятными оказались задачи по сборке из имеющихся пакетов того, что нужно именно мне, и по запуску всего этого на Read Write Serve. Для организации работы всего того, что нужно современному веб-проекту, не требуется прилагать чрезмерных усилий. Это — отправка электронной почты, работа с платёжными сервисами, обращение к базам данных, и всё остальное, подразумевающее работу с серверными API.
Я пользуюсь сервером баз данных MariaDB. Это — форк MySQL, подвергнутый ребрендингу и освоенный опенсорс-сообществом. Когда мне нужно хранить неструктурированные JSON-данные, я пользуюсь PostgreSQL. Дело в том, что это позволяет мне выполнять запросы непосредственно по конкретным JSON-свойствам. Это немного похоже на MongoDB, но основано на привычном SQL-синтаксисе.
Для организации связи между частями приложений я полагаюсь на возможности HTTP/2 с поддержкой постоянных соединений и с мультиплексированием потоков. Эти два дополнения к достойному уважения протоколу HTTP/1.1. изменили мой подход к формированию документов. Во-первых, исчезла проблема блокировки начала очереди. В результате пропала необходимость в спрайт-листах даже в том случае, если у меня имеются десятки маленьких изображений. Во-вторых, теперь не нужно оптимизировать JavaScript- и CSS-файлы, объединяя их в бандлы. После того, как соединение клиента и сервера установлено, все эти маленькие файлы без перебоев передаются по этому соединению.
Blue Phrase — это система шаблонизации, позволяющая в компактном виде точно описывать HTML-структуры. Для меня закончились времена нечитаемой мешанины из HTML-кода и несоответствий между открывающими и закрывающими тегами. В шаблонах я обычно использую лишь незначительное количество переменных (заголовок, описание, ключевые слова, SEO-данные, экран загрузки, дата и так далее) и размещаю их в шаблоне в декларативном стиле.
Когда я создаю новые страницы, я сосредоточен на том, что пытаюсь выразить, а не на их оформлении. Для решения этой задачи я пользуюсь Read Write Doc. Этот инструмент помогает мне заниматься делом, ни на что не отвлекаясь. Я пользуюсь им даже тогда, когда то, над чем работаю, планируется опубликовать на Medium (а там есть отличный онлайновый WYSIWYG-редактор). Я отношу себя к ветеранам веб-разработки, поэтому привык к моноширинным шрифтам, и к тому, чтобы мои руки были бы на клавиатуре, а не метались бы между клавиатурой и мышкой. В любом случае, если мне нужно увидеть то, над чем я работаю, с применением к нему CSS, я могу, с помощью простой комбинации клавиш, переключаться между режимами просмотра и редактирования.
В области работы с веб-компонентами я придерживаюсь стандартов W3C. Это — теневая DOM, пользовательские элементы, HTML-тег
Для написания клиентских скриптов я пользуюсь модульным объектно-ориентированным JavaScript-кодом. Я применяю новые возможности стандарта ECMAScript только тогда, когда их поддержка появляется в свежих релизах браузеров. То есть, включаю их в свой арсенал в тот момент, когда вижу, что на caniuse.com «зеленеют» все основные браузеры. Я избегаю полифиллов.
CSS — это типографское оформление и макеты страниц. Типографика начинается с правильного подбора шрифтов. Самое главное для меня — хорошая читаемость текста. В последнее время я взял себе за правило хостить файлы используемых шрифтов на собственном сервере. Это ограждает мои ресурсы от возможности блокировки, вызванной ограниченной полосой пропускания некоего стороннего сервиса. Например, я пользуюсь примерно такими конструкциями:
Дополнительное преимущество такого подхода заключается в том, что он полностью избавляет меня от проблемы, известной как FOUT — (flash of unstyled text, вспышка обычного шрифта).
И, наконец, для подготовки графических ресурсов я использую пару редакторов. Растровые PNG-изображения я готовлю с помощью GIMP, а векторные SVG-материалы — с помощью InkScape.
Некоторые средства, которые раньше мне очень нравились, а также некоторые, которыми я увлекался лишь мимолётно, больше не входят в мой стек веб-технологий.
Вот обзор тех уровней моего технологического стека, которыми я особенно впечатлён:
Раньше стеки веб-технологий вполне могли включать в себя всего четыре элемента. Но в современных условиях никого не удивишь стеком, состоящим из двенадцати уровней. Не хочу выглядеть как человек, озвучивающий общеизвестные истины, но, всё же, завершая этот материал, скажу о том, что у каждого разработчика может быть собственный стек. И мне было бы крайне интересно узнать о том, что другие назовут своим «идеальным стеком веб-технологий 2020 года».
Уважаемые читатели! А какой он — ваш стек веб-технологий 2020 года?
![](https://habrastorage.org/webt/yx/3g/bv/yx3gbv0xlht1gyjfwlg2z_kgylo.png)
![](https://habrastorage.org/files/1ba/550/d25/1ba550d25e8846ce8805de564da6aa63.png)
Мой первый успешный сайт, теперь уже старинный проект 1999 года, был создан с использованием технологий, которые можно пересчитать по пальцам одной руки: HTML4, CSS2, JavaScript3 и Apache 1.1. Всё это крутилось на сервере с Linux 2.0. Сайт включал в себя 38000 страниц. И сегодня, через 20 лет, он всё ещё их выдаёт.
![](https://habrastorage.org/webt/xn/yn/nd/xnynndngv2phbo4io6g7eguegea.jpeg)
С тех пор всё изменилось. Это касается и стеков веб-технологий. Теперь они совсем не те, что прежде.
Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о том, как он перешёл от «фуллстека» к «стеку 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
заменяется современным и более простым APIfetch
, а 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? У того, что этот бандлер потерял для меня актуальность, есть некоторые причины, на которых я остановлюсь подробнее:
- До появления HTTP/2 с поддержкой постоянных соединений и мультиплексирования потоков мы находились в зависимости от возможностей этих инструментов по сборке бандлов ресурсов приложений. Но бандлинг ничего нам не даёт в мире, где есть HTTP/2.
- Стандарт ECMAScript 2015 был новым словом в JavaScript-разработке, все бросились использовать новые возможности языка в тот самый момент, когда они увидели свет. Однако тут была одна проблема. Код, написанный с использованием новых возможностей, не поддерживался браузерами. Поэтому его приходилось транспилировать в ECMAScript 5-код. В этом деле мы полагались на Babel, его применение стало стандартным шагом подготовки веб-проектов к публикации. Сегодня же все необходимые мне новые возможности языка доступны буквально повсюду. В результате Babel мне больше не нужен.
- До появления в браузерах возможности динамического импорта модулей код приходилось транспилировать в формат CommonJS. Теперь же большинство основных браузеров поддерживает
<script type='module'>
(да и Edge 76+ скоро подтянется). В результате скоро мы сможем поздороваться с ECMAScript-модулями и попрощаться со всем остальным.
- JSX. Я не понимаю тех, кто полагает, что JSX — это хорошо. И «Но вы же к этому привыкли» для меня — не аргумент.
- Функциональное программирование. Я ограничил применение функционального программирования в своём коде до простых однострочных конструкций вроде
numbers.sort((a, b) => a - b);
. Для всего остального я использую объектно-ориентированное программирование.
Технологии, которые стали фаворитами
Вот обзор тех уровней моего технологического стека, которыми я особенно впечатлён:
- JavaScript-модули. Модули отлично зарекомендовали себя в серверном JavaScript-коде. И я безмерно рад тому, что наконец могу использовать их и на стороне клиента.
- Объектно-ориентированный JavaScript. Вот пять золотых правил объектно-ориентированной JavaScript-разработки:
- Заменяйте анонимные объекты именованными классами.
- Объявляйте и инициализируйте все свойства объектов в конструкторах.
- Защищайте объекты от изменений сразу после создания.
- Объявляйте методы с неизменными сигнатурами.
- Привязывайте
this
к каждому коллбэку.
- Blue Phrase. Эта система позволяет мне пользоваться декларативным подходом при создании шаблонов и при подготовке различных материалов. Она превращает написание качественного HTML-кода в сплошное удовольствие.
Итоги
Раньше стеки веб-технологий вполне могли включать в себя всего четыре элемента. Но в современных условиях никого не удивишь стеком, состоящим из двенадцати уровней. Не хочу выглядеть как человек, озвучивающий общеизвестные истины, но, всё же, завершая этот материал, скажу о том, что у каждого разработчика может быть собственный стек. И мне было бы крайне интересно узнать о том, что другие назовут своим «идеальным стеком веб-технологий 2020 года».
Уважаемые читатели! А какой он — ваш стек веб-технологий 2020 года?
![](https://habrastorage.org/webt/yx/3g/bv/yx3gbv0xlht1gyjfwlg2z_kgylo.png)
![](https://habrastorage.org/files/1ba/550/d25/1ba550d25e8846ce8805de564da6aa63.png)
Дисклеймер от переводчика: Blue Phrase, Read Write Serve и Read Write Doc — технологии, разработанные автором данной статьи. Скачивание и установка — на ваш риск.
ikle
Люди так и не научились считать: 2020-ый — это конец десятилетия, точно так же, как 2000-ый — конец тысячелетия. Да ладно с большинством, но люди технических специальностей?
Самое интересное, что в нашем детстве все прекрасно понимали разницу между Васе пятый годик, а Ане уже пять лет… а к школе как-то резко забыли всё.
Cryvage
Для программистов нормально начинать счёт с нуля.
ikle
Мне казалось, что для программистов важно думать головой: во-первых, нуля как числа не существовало в европейской цивилизации, когда была придумана, принята и распространилась данная система летоисчисления, как следствие — используются порядковые числительные.
Норма — понятие весьма расплывчатое и изменчивое. Да и во многих языках программирования индексация до сих пор идёт с единицы.
P.S. Похоже, всё ещё хуже, чем я думал.
boolive
Меня смущает, почему годы, часы, минуты, секунды мы пишем с нуля, а дни и месяцы нет о_О В первый день должна быть дата 00.00.2020 =)
savostin
Русский язык всё объясняет:
(прошло) 0 часов 0 минут
(от) первого января
2000 года
boolive
Прошло 0 дней 0 месяцев, на календаре 01.01.2020
savostin
Прошло 10 минут первого января — на календаре все правильно ;)
boolive
Прошло 10 минут первого часа — на часах 0, а не 1
s_suhanov
И поэтому часы показывают 10 минут. Потому что эти 10 минут уже прошли. Тут все логично. Но календарь показывает уже 1 января, хотя 1 января еще в процессе, и не прошло.
ikle
Это новодел цифровой эры: раньше писали не 00:15, а четверть первого, а вместо 00:00 — полночь (минуты вообще не писались). Ну не было такого числа как ноль, не было. И потому нет на классическом циферблате часов нуля.
P.S. Ещё и карму слили молча несогласные — хоть бы аргументировали.
maggg
Не пишем мы годы с нуля. Не было нулевого года, сразу же был первый. Не было нулевого века, сразу же был первый. А часы, минуты и секунды действительно отличаются от дней, месяцов, лет и веков. Для них принято записывать не какая секунда, минута или час идёт по счёту прямо сейчас, а сколько полных успело пройти до текущего момента. Хотя и здесь иногда допустимо сказать, что «идёт одиннадцатый час». Это значит, что на часах десять полных часов и какое-то количество пройденных минут.
maggg
И в твоей логике первый день наступающего года должен обозначаться так: 00.00.2019. Потому что пройдёт ноль дней, ноль часов и 2019 лет с начала отсчёта времени.
boolive
В моей логике как на линейке, отсчёт с нуля. Понял что годы, месяцы и дни имеют точку отсчёта с единицы. Время с нуля. Понятно, но для летоисчисления непривычно.
Crimento
А я вот с раннего детства негодовал, почему 01:30 это пол второго, если отчёт времени начинается с нуля, а не с единицы.
Whuthering
В английском с этим проще, там half past one :)
411
Ну half to two в принципе корректно, хоть и не распространено
JediPhilosopher
Зато в английском 12pm это внезапно полдень, а не полночь. И наоборот, 12 am это полночь. Т.е. 12 am следует не после 11 am, а перед 1 am. Это вообще мозг взрывает.
TheYellingChives
На часах 12 делений, никаких нулей.
maggg
Зря негодовали. В 01:30 с полночи прошёл один полный час и ещё половина второго часа.
Du-X
Отсчет времени начинается с нуля. Сутки с нуля, исчисление лет с нуля… Человек родился и ему 0 лет. Лет 0, но он уже есть. Когда ему (человеку) 1 год — это говорит о том, что прошел год с даты его рождения. Также и тут — 01.01.2020 00:00:01 начало десятилетия. В 2021 пройдет 1 год от начала десятилетия. Элементарно же.
doozza
Как минимум не элементарно.
На часах 0:30, мы говорим «половина первого (часа)». С начала суток прошло ноль часов и ещё половина часа. Чувствуете, в чём подвох? Прошло ноль часов, но говорим «половина первого часа».
Далее мы говорим, что живём в 2019-м году. В две тысячи девятнадцатом году. Сколько лет прошло с начала эры? По аналогии с часами нужно сказать, что две тысячи восемнадцать полных лет, и записывать их как 24.12.2018.
Cогласно григорианскому календарю, нулевого года не существует [2 до н.э., 1 до н.э., 1 н.э.]. То есть ребёнку может быть ноль лет, а нашей эре сразу стал один год.
ru.wikipedia.org/wiki/0_год
И товарища ikle сверху слили ни за что. Первое десятилетие — это годы 1,2...10. Начало второго десятилетия — это 11-й год. Также и 2021-й год будет началом нового десятилетия.
maggg
Аналогия с ребёнком неверная же. Ребёнку действительно может быть ноль лет. Это значит, что идёт первый год его жизни. Нашей эре тоже было ноль лет! И при этом шёл первый год её жизни. Вся путаница в том, что в случае возраста мы отвечаем на вопрос «сколько лет», то есть сколько полных лет уже прошло, а в случае с нумерацией годов на вопрос «который год идёт по счёту».
dom1n1k
Короче: не надо путать момент и период.
Du-X
ISO 8601 развеял мои сомнения. Действительно я был не прав. Выходит, что календарная дата (годы, дни, месяцы) указывает на то, какой по счету период начался. А время (часы, секунды) и возраст указывают на количество завершенных периодов.
Nickrus
Нет. Количественные существительные можно начинать с нуля, потому что минимальное количество это ноль. А порядковые начинают с «первого», потому что если у тебя что-то есть (дети, прожитые годы, байты) — то минимально имеющееся количество это один, и порядковое существительное будет «первый».
Поэтому родившемуся человеку ноль лет, он начинает проживать свой ПЕРВЫЙ, а не нулевой год. Когда с нулевой точки прошло ещё ноль лет, был ПЕРВЫЙ год нашей эры. Когда с нулевой точки нового десятилетия не пройдёт ещё и года, будет идти 2021-ый год.
Virviil
"ноль лет" и "нулевой год" — это разные вещи.
В тот момент, когда "родился Иисус" начался его "первый год" а вовсе не нулевой. Соответственно, в тот момент, когда 10 лет закончились, начался "одиннадцатый год".
Достаточно очевидно, что "нулевой год" вообще не существует, потому что такая конструкция не имеет смысла, в отличие от "нуля лет". Соответственно, декады, века, тысячелетия заканчиваются в конце 0, *0, **0 года.
Подробнее можете почитать на википедии. Элементарно же!
me21
Да нет, самое первое десятилетие нашей эры начиналось с первого года. Нулевого года не было же.
boolive
Если бы родились в 0 лет н.э., то в 2020 говорили бы — вам 2021 годик пошел, но лет вам 2020 :)
Virviil
0 год нашей эры не существует. пруф
boolive
Негодяи григорианцы!
Ogra
Десятилетие, это просто временной промежуток длиной в десять лет, мы вольны выбирать точку отсчета. В 2020 начнутся двадцатые года. В 2021 начнется третье десятилетие 21 века. В Википедии была дискуссия на эту тему.
ikle
Можно, вот только мы уже выбрали точку отсчета — начало первого года н.э. (или от РХ). А в текущем виде у нас два лагеря с двумя разными точками отсчёта.
А вот это хорошая ссылка: не в том, что это ссылка на Wikipedia (это не reference source), а в том что в конце этого обсуждения есть ссылка на ГОСТ ИСО 8601-2001 (а это уже reference source) «Представление дат и времени»:
Ну и вывод по результатам дискуссии:
P.S. Скоро я, видимо, потеряю возможность отвечать .)
technic93
Обычное дело для кармы и общества в целом, сначала осуждаем, потом разбираемся. Значит надо в каждом сообщении излишне разжовывать, чтобы разобратся мимопроходилам было легче.
Lord_Ahriman
Надо мимокродилам читать, что пишут, и вникать, а не начинать с улюлюканьем закидывать человека камнями и оплевывать его «за компанию»
Ogra
Смотрите, 2020 год начнется 1 января 2020 года, неделя длится семь дней. Вопрос — когда начнется вторая неделя 2020 года?
ainoneko
Во многих странах неделя начинается с воскресенья, что даёт ещё один вариант.
maggg
Поймал себя на том, что ровно двадцать лет назад вёл в интернетах такие же точно беседы с такой же точно аргументацией по поводу «миллениума». :)
demin
Меня тогда убедил пример с ящиком водки, который на 20 бутылке заканчивается, а новый начинается с 21.
Kerlaeeda
Видимо вы очень счастливый человек, если можете использовать модули без полифилов, да еще и отказавшись от сборщика. Хотелось бы увидеть проект, требования к которому позволяют использовать ваш стек на следующий год)
hrie
Это перевод, боюсь вам никто не ответит )
Kerlaeeda
Не заметил, спасибо)
hrie
Какой-то человек из 2012 года прощается с jQuery, Grunt, Верданой и привязывает this к каждому коллбеку? Как мило.
Valsha
Интересно, о сервере «Read Write Serve» и не слышал. Посмотрим что за зверь :) Спасибо за перевод.
justboris
нашли что-нибудь? Мне по этому запросу находится только оригинал этой статьи
kemsky
Это рекламная статья, сервер этот тут https://rwserve.readwritetools.com/, но качать его стремновато.
TheYellingChives
Скачал кстати, после распаковки архива меня в убунте разлогинило… Вот ща стрёмно чёто стало
chupasaurus
«Я за
джваджесять лет использования Апача выработал стойкую неприязнь к Nginx, поэтому буду крутить всякую экзотику»beduin01
Судя по новостям тот же Dart/Flutter сможет заменить все это если не в 2020, то в 2021 году точно.
Во всяком случае концепция: отдельно сайт, отдельно мобильное приложение скоро отомрет.
androidovshchik
Да, будет монстр вместо сайта наподобие эффекта electron для десктопа. Переубедите меня)
beduin01
Ну во первых хуже электрон нужно постараться. А во-вторых Flutter ни чем не хуже того же React. Более того теоретически он может быть более быстрый и компактный
epishman
Я ковырял палочкой. Машина Dart медленней V8, а декларативный дизайн виджетов Flutter без даже намека на CSS напоминает какое-то ретро-садо-мазо. После ядерной войны допускаю взлет Flutter для WEB, но для этого должны погибнуть все WEB-дизайнеры.
stilic
Вы имеете ввиду ту VM-машина Dart, что используется только для отладки?
Или речь о том, во что компилируется Dart в production?
epishman
А разве есть разница? Я просто себе поставил ноду и Dart, консольный, под линуксом, написал пару парсеров, и получилось что как числодробилка он раза в полтора медленнее ноды и в два — джавы. Возможно, на андроиде оно быстрее работает, гугл же заявляет у флаттера какой-то фантастический rate, тут я уже не знаю как померить.
PS
Скорее, screen rate у флаттера хороший не из-за дарта, а из-за концепции иммутабельности виджетов (можно кэшировать по конструктору), ну и вроде отсутствие каскадности CSS сильно ускорило (они так сами пишут).
beduin01
Я вас читаю давно. Со многим полностью согласен. Но скорость они скоро подтянут и если приложат усилия ноду смогут легко обойти. Где то примеры tree shake видел дарта и ноды. Преимущество за дартом
epishman
Это понятно, типизация дает больше возможностей для оптимизации. Хотя мне лично синтаксис TS / Котлина ближе, мода на джаваподобие похоже прошла.
stilic
Есть.
Для веб-фронтенда — там всё в обычный JS преобразуется. Причем, как уверяют, даже более оптимальным образом, нежели это было написано на JS изначально.
На Android — в native.
То, что вы замерили — это использование Dart на бэкенде, а там оно и не продвигается как «революционное».
epishman
Да нет, я же не про веб, а про standalone, консольный dart, такой есть у них, вряд-ли это обертка над v8, хотя не проверял.
stilic
Можно явно перегнать с помощью dart2js и проверить такой вариант насчет эффективности Dart
epishman
Надо бы бенч сделать и статью запилить, если будет не лень…
pesh1983
"Будет одно сплошное телевидение..." (с)
Fedcomp
Эта штука уже называется React native. Что то я не вижу чтобы на него массово переходили.
kavarzin
Blue Phrase, Read Write Serve и Read Write Doc — технологии разработанные автором статьи. Ничего плохого сказать не хочу, но аргументация в статье хромает на обе ноги. Очень похоже на то, что это обычное продвижение собственного продукта
denisshabr
Оба сайта с этими технологиями лежат. Хабр/Medium-аэффект?
Enmar
В каком мире живет автор оригинала, если он не использует Babel?
Про минификацию скриптов тоже не понятно — http2 явно не у всех поддерживается.
sumanai
http2 про объединение, про минификацию это сжатие.
TheYellingChives
Всё очень плохо. Смотрел сайт и «технологии» автора, разбил лицо фейспалмом.
m_vash
реально странная статья. Видел ее еще на инглише и хотел к себе на тг-канал запостить, но она мне показалась реально больше рекламной
QSandrew
Мой стек веб-технологий. HTML+CSS+JS, а остальное всё меняется.
somebody4
Надо бы J заменить на T, сразу полегчает.
0xd34df00d
Я вообще TS заменил на Haskell и генерирую сайты статически, либо в худшем случае Servant'ом их.
somebody4
Судя по счёту -2 vs -3, TS победил.
Хотя не очень понятно как статические сайты без client-side логики могут конкурировать с каким-нибудь фреймворком, типа ангулар. Или как в 1996, любой чих, идём ан сервер страницу перегенерировать?
0xd34df00d
Ну вот у меня есть три сайта: блог, сайт опенсорс-проекта (раньше был на друпале, но пхп сложный, я с шестого друпала на 7-8 мигрировать не смог), и что-то вроде почившего сохабра. Если про третий ещё можно поспорить (и там, собственно, сервант), то зачем первым двум клиентская логика?
А перегенерировать — нуу, написал новый пост в блог, сделал ./regen.sh, который и сайт перегенерировал (только изменённые страницы — скажем, саму страницу с постом и страницу со списком постов по упомянутым тегам), и по rsync на сервер все залил. Зато все в гите, удобно, и логика построения и навигации по сайту на привычном мне языке.
И, кстати, так как все в гите, можно было бы вообще обмазаться, скажем, github actions, чтобы оно там по коммиту все деплоило само, но меня не настолько напрягает руками вызвать шелл-скрипт.
А так как оно на привычном и адекватном general-purpose-языке, то я могу делать вообще произвольные вещи, от адекватного управления коллекцией скриншотов на сайте опенсорс-проекта, с автогенерацией версий в webm, до залезания в гит-репу проекта и вычленения актуальных версий зависимостей для генерации страницы с инструкциями для сборки.
somebody4
Для ваших собственных небольших сайтов понятно что можно хоть как сделать, работать будет. Я даже в конце 90-х занимался чем-то подобным, типа статическая SMS. Но для тех сайтов которые требуют некоторой логики на клиенте, даже банально сделать валидацию, тут уж хаскель не поможет. Только если какой-нибудь транспайлер напилить.
Ну и честно говоря, при всеё привлекательности идей заложенных в хаскель, существует огромная проблема, которая ставит крест на его практическом применении в почти что всех проектов, это то что если апологет хаскеля свалит с проекта, то будет банально некому подхватить упавшее знамя.
И подобные риски никто не желает на себя взваливать.
0xd34df00d
Ну есть же ghcjs, например, который в js компилирует (правда, я с ним не игрался).
Если вкратце, то, по моему опыту, выбор вещей типа C++ или Python или ещё чего от этого не страхует вот вообще, совсем. Даже, наверное, наоборот — я неоднократно видел, как питоноподелия переписывали с нуля даже знающие питон люди, так как поддерживать или хотя бы рефакторить то было невозможно.
А я не так давно за час въехал в совершенно незнакомый проект (Хактоберфест же!), который видел впервые, запилил туда фичу, про которую в первый раз слышал, и отправил (успешно принятый) PR.
Да и Haskell в резюме у людей я вижу почаще, чем какой-нибудь Go, а про него так не говорят.
Мой текущий и прошлые работодатели с вами совсем не согласятся.
Аргумент непопулярности был использован всего один раз, но то было в рамках некоторых подковёрных игр. Технология дала лишь повод, но не причину.
somebody4
В случае хаскеля, если проект начинает энтузиаст своего дела, то опять же в среднем, уровень программиста будет выше, чем в среднем для какого-нибудь питона. Что положительно скажется на качестве кода в проекте.
Но если перехватывать будет коллек
га, который первый раз видит это чудо и которого попросили быстренько пофиксить что-то, то результат будет более менее-пердсказуем. Ничего не значит, может у вас там рота хаскелистов, тогда это не проблема.0xd34df00d
Качество кода там, кстати, так себе, не топчик, но то такое.
Не, обычные совершенно места, где в основном люди пишут на плюсах и просто немножко вертят головой по сторонам (правда, больше в сторону какого-нибудь раста).
Neveil
Что за Read Write Serve? Не гуглится, оригинале также.
ffs
Какая-то платная срань rwserve.readwritetools.com
Neveil
Спасибо, ваш уровень гугления выше моего)
PaulIsh
При этом качество поддержки и часто самих NPM пакетов бывает весьма плачевное, особенно если нужна всякая экзотика. Столкнулся при работе с федерацией через SOAP:
— node-soap, strong-soap годятся только после серьезной доработки напильниками,
— xml-crypto — в недоделанном полу-заброшенном состоянии,
— node-gost и его предок gostcrypto в заброшенном состоянии — пришлось потратить массу времени для нормальной работы с гост-2012
Vadem
Перед ним обычно какой-нибудь Nginx стоит.
Вообще похоже что автор большой велосипедист.
Изобрёл Nginx, Jade и Wiki, но проприетарные и пытается это продать.
stilic
Автор упоминает Blue Phrase.
Не гуглится.
Кто-нибудь подскажет, где на это можно взглянуть?
somebody4
Если что-то не гуглится, то наверное это к лучшему.
И если количество найденых упоминаний меньше тысяч ста, то наверное тащить это в продакшн не стоит.
ru_vds наверное стоило бы удалить эту статью, как неприкрытую рекламу чьих-то поделок. Ну или по крайней мере дисклаймер написать.
ru_vds Автор
Решили статью все же оставить, дисклеймер добавили.
ReDev1L
Дисклеймер пишут в начале, я например скипаю всё что после итогов.
FTOH
А я вот дочитал, но после банера с рекламой не заметил дисклаймера и узнал о нем только из комментариев.
Tangeman
Когда-то и React или Vue не гуглились и упоминаний почти не было, равно как и всё остальное (к примеру, Rust или Go). Если следовать такой логике, то ничто новое вообще шансов на жизнь получит, хотя бы потому что вне продашкн не откатать действительно важные вещи.
Это не в защиту «стека» из статьи, это к тому что гугление и популярность не являются показателем надежности, качества, скорости или чего-то ещё — достаточно вспомнить популярность PHP несмотря на все его недостатки на протяжении более чем 10 лет, или даже сам JS — я ещё помню времена когда его гнобили, причём было за что.
somebody4
Вообще то это написано для адекватных людей, которые не желают быть морской свинкой (в том числе и с React или Vue в начале их жизни).
Если вы понимаете зачем вам нужен хайповый проект, про который никто, нигде не знает, то это ок.
Или если вы используете его на «продакшн» — своём пет-проекте или на проекте который если будет выключен на пару недель, никто и не заметит.
Но экспериментировать на реально используемом проекте, это сильно на любителя.
Tangeman
При правильном подходе можно делать боевые приложения на новой (и вообще почти любой) технологии, в то время как популярность и распостранённость сами по себе не гарантируют ничего (посмотрите хотя бы на некоторые чрезвычасно популярные приложения на PHP).
somebody4
Ещё раз повторюсь — для людей, которым надо предсказуемый результат, за предсказуемые затраты, надо выбирать майнстрим решения.
А так то конечно при _правильном_ подходе можно делать всё что угодно.
justboris
Оксюморон какой-то. Хайп – это как раз про то, что о проекте трубят на каждом углу, поэтому о нем все знают.
Наверное, вы хотели сказать "хипстерский"? Это как раз про непопулярные проекты не для всех.
somebody4
Да не очень внятно получилось. Имелось в виду хайповый проект, которые ещё не вошел в маинстрим. Т.е. про него уже много говорят и как бы круто на нём что-то запилить, но он еще не вырос из детских штанишек.
Dee3
Гуглится если добавить html к запросу.
Мне вообще не понятно как надо одичать чтобы посты в блоге оформлять через CSS.
plus_stick
bluephrase.com
Northerner19
По большому счету тут все для фронта, а есть инсайд для чистого бекенда?
Clasen01
В статье же написано, что на сервере node и mariaDB
kolkoni
Спорная статейка
v1000
я правильно понял, что, по тому как их придерживались, веб стандарты появились только сейчас, а раньше это были так, веб рекомендации?
botyaslonim
AJAX. Этот прародитель Web 2.0. теперь превратился в пережиток прошлого. API XMLHttpRequest заменяется современным и более простым API fetch, а JSON приходит на замену XML
— картинка в стиле «Кровь из глаз» по своему вкусу.
Вообще, более хайповой статьи выдумать сложно, хотя ru_vds часто провоцирует сообщество
akubintsev
Очень
интереснои нифига не понятно3263927
C# VS2919 js/jQuery Vue EF .net core 3.1 xamarin SVG