#Sidenote: о соотношении оптимизаций и прогресса
Перфекционизм давно не в моде. Любого спроси — скажет, что лучше хуяк-хуяк и в продакшн, чем идеально — но хз когда. Дёшево, сердито, просто и грязно — считается хорошо. Правильно, оптимально, сложно — считается плохо, времени нет выёбываться. Однако, мода модой — а физика физикой. Рассмотрим пример.
Больше пяти лет как Web-разработка идёт по пути усложнения клиентской части приложений и обогащения пользовательского интерфейса. Полная перезагрузка всего сайта при переходе на соседнюю страницу — это позавчерашний день. Вчерашний день — это асинхронные фоновые запросы к серверу для обновления только нужного кусочка сайта (AJAX, вот это всё). День сегодняшний, клонящийся к закату — полноценные SPA-фреймворки (Single Page Application, Angular.js, Ember.js etc).
Фреймворки, конечно, крутые. И местами даже оптимизированные по важным мелочам. Но в глобальном смысле — нифига не перфекционистские. Из-за трёх букв: DOM, и из-за того, как они с этими тремя буквами работают.
DOM - это дерево элементов в браузере. А работают упомянутые фреймворки тупо: при инициализации приложения выкинь все старое и собери с нуля; при изменении — аналогично, разве что чуть локальнее. Куча лишних операций с DOM-деревом получается. Но зато так проще. Выискивать минимально необходимые изменения в дереве — устанешь. А так вроде работает — значит, сойдёт и так.
У web-приложений, созданных на этих фреймворках, есть три старые и уродливые проблемы: 1) дублирование кода на сервере и клиенте 2) SEO — это боль 3) пользователю приходится ждать, пока приложение проинициализируется на фронтенде: страница вроде загрузилась, но что-то ещё тянет всё равно. Вторую при помощи какой-то матери и безголовых браузеров с горем пополам удаётся решить (если бы не удавалось совсем — сами понимаете). Первую и третью списывают в разряд неизбежных неприятностей. Хуяк-хуяк — и снова вроде ничего, как-то работает. КПД низковат, но кто ж его считает — у всех реальных процессов КПД низкий, утопии же остаются на бумаге.
Года четыре точно ситуация оставалась такой. А потом появился React. Не знаю, каким чудом, но вместо огибания острых углов разработчики этой библиотеки вгрызлись в породу и сделали всё не "дёшево и сердито", а "правильно и по-новому". Иными словами, React таки минимизирует операции с DOM, выполняя сложную задачу сравнения того, что уже есть с тем, что хочется получить и определяя набор наименее инвазивных влияний — и всё это, до последнего, в отдельной шустрой модельке виртуального DOM'а, а не в медленном "настоящем" дереве.
Казалось бы — молодцы, конечно, ускорили немножко приложение, но что с того? А с того бесплатным бонусом уходят три упомянутые жуткие проблемы. Потому как если библиотека не требует для рендеринга DOM-дерева браузера, и умеет деликатно подстроиться под уже имеющееся дерево вместо революционного "до основания, а потом!.." — то можно спокойно рендерить на сервере и получать изоморфное приложение, которое а) быстрее, ибо изначально рендерится на мощном сервере б) удобнее, ибо юзеру приходит уже готовая страница, а дальше все скрипты уже на неё в нужных точках аккуратно навешиваются в) SEO-friendly, понятно почему г) удобнее в поддержке, ибо код не дублируется.
А всё из-за того, что кто-то решил "сделать правильно несмотря ни на что".
Перфекционизм давно не в моде. Любого спроси — скажет, что лучше хуяк-хуяк и в продакшн, чем идеально — но хз когда. Дёшево, сердито, просто и грязно — считается хорошо. Правильно, оптимально, сложно — считается плохо, времени нет выёбываться. Однако, мода модой — а физика физикой. Рассмотрим пример.
Больше пяти лет как Web-разработка идёт по пути усложнения клиентской части приложений и обогащения пользовательского интерфейса. Полная перезагрузка всего сайта при переходе на соседнюю страницу — это позавчерашний день. Вчерашний день — это асинхронные фоновые запросы к серверу для обновления только нужного кусочка сайта (AJAX, вот это всё). День сегодняшний, клонящийся к закату — полноценные SPA-фреймворки (Single Page Application, Angular.js, Ember.js etc).
Фреймворки, конечно, крутые. И местами даже оптимизированные по важным мелочам. Но в глобальном смысле — нифига не перфекционистские. Из-за трёх букв: DOM, и из-за того, как они с этими тремя буквами работают.
DOM - это дерево элементов в браузере. А работают упомянутые фреймворки тупо: при инициализации приложения выкинь все старое и собери с нуля; при изменении — аналогично, разве что чуть локальнее. Куча лишних операций с DOM-деревом получается. Но зато так проще. Выискивать минимально необходимые изменения в дереве — устанешь. А так вроде работает — значит, сойдёт и так.
У web-приложений, созданных на этих фреймворках, есть три старые и уродливые проблемы: 1) дублирование кода на сервере и клиенте 2) SEO — это боль 3) пользователю приходится ждать, пока приложение проинициализируется на фронтенде: страница вроде загрузилась, но что-то ещё тянет всё равно. Вторую при помощи какой-то матери и безголовых браузеров с горем пополам удаётся решить (если бы не удавалось совсем — сами понимаете). Первую и третью списывают в разряд неизбежных неприятностей. Хуяк-хуяк — и снова вроде ничего, как-то работает. КПД низковат, но кто ж его считает — у всех реальных процессов КПД низкий, утопии же остаются на бумаге.
Года четыре точно ситуация оставалась такой. А потом появился React. Не знаю, каким чудом, но вместо огибания острых углов разработчики этой библиотеки вгрызлись в породу и сделали всё не "дёшево и сердито", а "правильно и по-новому". Иными словами, React таки минимизирует операции с DOM, выполняя сложную задачу сравнения того, что уже есть с тем, что хочется получить и определяя набор наименее инвазивных влияний — и всё это, до последнего, в отдельной шустрой модельке виртуального DOM'а, а не в медленном "настоящем" дереве.
Казалось бы — молодцы, конечно, ускорили немножко приложение, но что с того? А с того бесплатным бонусом уходят три упомянутые жуткие проблемы. Потому как если библиотека не требует для рендеринга DOM-дерева браузера, и умеет деликатно подстроиться под уже имеющееся дерево вместо революционного "до основания, а потом!.." — то можно спокойно рендерить на сервере и получать изоморфное приложение, которое а) быстрее, ибо изначально рендерится на мощном сервере б) удобнее, ибо юзеру приходит уже готовая страница, а дальше все скрипты уже на неё в нужных точках аккуратно навешиваются в) SEO-friendly, понятно почему г) удобнее в поддержке, ибо код не дублируется.
А всё из-за того, что кто-то решил "сделать правильно несмотря ни на что".
#Sidenote: on the ratio of optimizations to progress
Perfectionism has long been out of fashion. Ask anyone - he will say that a huyak-huyak is better in production than ideal - but when. Cheap, angry, simple and dirty - considered good. Correct, optimal, difficult - it is considered bad, there is no time to get fucked. However, fashion is fashion - and physics is physics. Consider an example.
For more than five years, as Web-development has been on the path of complicating the client side of applications and enriching the user interface. A full reboot of the entire site when you go to the next page is the day before yesterday. Yesterday is an asynchronous background request to the server to update only the desired piece of the site (AJAX, that's all). Today, declining - full-fledged SPA-frameworks (Single Page Application, Angular.js, Ember.js etc).
The frameworks are, of course, cool. And sometimes even optimized for important trifles. But in a global sense - nifiga is not perfectionist. Because of the three letters: DOM, and because of how they work with these three letters.
DOM is a tree of elements in the browser. And the mentioned frameworks work stupidly: when initializing the application, throw away everything old and collect from scratch; when changing - similarly, except perhaps a little more local. A bunch of unnecessary operations with the DOM tree is obtained. But it’s easier. Finding the minimum necessary changes in the tree - you get tired. And it seems to work like that - that means it will do.
Web applications created on these frameworks have three old and ugly problems: 1) duplication of code on the server and client 2) SEO is a pain 3) the user has to wait while the application is initialized on the frontend: the page seems to load, but it still pulls anyway. The second can be solved in half with the help of some mother and headless browsers with grief in half (if you didn’t succeed at all, you yourself understand). The first and third are attributed to the category of inevitable troubles. Huyak-huyak - and again nothing seems to work. Efficiency is low, but who believes it - all real processes have low efficiency, while utopias remain on paper.
About four years ago, the situation remained exactly the same. And then React appeared. I don’t know how miraculous, but instead of bending around sharp corners, the developers of this library gnawed at the rock and did everything not “cheaply and angrily”, but “correctly and in a new way”. In other words, React minimizes operations with the DOM, performing the difficult task of comparing what is already with what you want to get and defining a set of least invasive influences - and all this, to the last, in a separate smart model of a virtual DOM, rather than in a slow "real" tree.
It would seem - well done, of course, a little speed up the application, but so what? And with that free bonus, the three terrible problems mentioned go away. Because if the library does not require a browser DOM-tree for rendering, and can delicately adapt to the existing tree instead of the revolutionary "to the bottom, and then! .." - then you can safely render on the server and get an isomorphic application that is a) faster, because it is initially rendered on a powerful server b) it’s more convenient, because the user already has a ready page, and then all the scripts are neatly hung on it at the right points c) SEO-friendly, it’s clear why d) it’s more convenient to support, because the code is not duplicated.
And all due to the fact that someone decided to "do it right no matter what."
Perfectionism has long been out of fashion. Ask anyone - he will say that a huyak-huyak is better in production than ideal - but when. Cheap, angry, simple and dirty - considered good. Correct, optimal, difficult - it is considered bad, there is no time to get fucked. However, fashion is fashion - and physics is physics. Consider an example.
For more than five years, as Web-development has been on the path of complicating the client side of applications and enriching the user interface. A full reboot of the entire site when you go to the next page is the day before yesterday. Yesterday is an asynchronous background request to the server to update only the desired piece of the site (AJAX, that's all). Today, declining - full-fledged SPA-frameworks (Single Page Application, Angular.js, Ember.js etc).
The frameworks are, of course, cool. And sometimes even optimized for important trifles. But in a global sense - nifiga is not perfectionist. Because of the three letters: DOM, and because of how they work with these three letters.
DOM is a tree of elements in the browser. And the mentioned frameworks work stupidly: when initializing the application, throw away everything old and collect from scratch; when changing - similarly, except perhaps a little more local. A bunch of unnecessary operations with the DOM tree is obtained. But it’s easier. Finding the minimum necessary changes in the tree - you get tired. And it seems to work like that - that means it will do.
Web applications created on these frameworks have three old and ugly problems: 1) duplication of code on the server and client 2) SEO is a pain 3) the user has to wait while the application is initialized on the frontend: the page seems to load, but it still pulls anyway. The second can be solved in half with the help of some mother and headless browsers with grief in half (if you didn’t succeed at all, you yourself understand). The first and third are attributed to the category of inevitable troubles. Huyak-huyak - and again nothing seems to work. Efficiency is low, but who believes it - all real processes have low efficiency, while utopias remain on paper.
About four years ago, the situation remained exactly the same. And then React appeared. I don’t know how miraculous, but instead of bending around sharp corners, the developers of this library gnawed at the rock and did everything not “cheaply and angrily”, but “correctly and in a new way”. In other words, React minimizes operations with the DOM, performing the difficult task of comparing what is already with what you want to get and defining a set of least invasive influences - and all this, to the last, in a separate smart model of a virtual DOM, rather than in a slow "real" tree.
It would seem - well done, of course, a little speed up the application, but so what? And with that free bonus, the three terrible problems mentioned go away. Because if the library does not require a browser DOM-tree for rendering, and can delicately adapt to the existing tree instead of the revolutionary "to the bottom, and then! .." - then you can safely render on the server and get an isomorphic application that is a) faster, because it is initially rendered on a powerful server b) it’s more convenient, because the user already has a ready page, and then all the scripts are neatly hung on it at the right points c) SEO-friendly, it’s clear why d) it’s more convenient to support, because the code is not duplicated.
And all due to the fact that someone decided to "do it right no matter what."
У записи 4 лайков,
0 репостов.
0 репостов.
Эту запись оставил(а) на своей стене Key-G B-Tee
