И вдруг про монополизацию Google с V8 мы, конечно же, стыдливо умолчали, как же так) Что насчёт ботов, они мне неинтересны, к чему вы приплели это соломенное чучело, не понимаю. Ну и я так полагаю, вы отклонили предложение изучить историю, ведь "неудобно получится")
Советую научиться читать до конца, где уже пояснена монополия.
P.S. - ну и минусовать, это очень сильный аргумент, сразу видно зрелость и взросление личности
Это всё здорово, конечно, но такое "конкурентное преиущество" стоит клиенту трафика и производительности, к тому же мы бонусом получили от React2Shell и падения половины Интернета в попытке её починить. Это длилось всего пару дней, но это очень показательный пример, как часть Интернета может стать уязвимой просто потому, что многим захотелось немного performance.
Никто, конечно, не заставляет пользоваться небезопасными решениями, которые объединяют фронтенд и бекенд, напрямую нарушая стандарт (!) клиент-серверной архитектуры. Но думаю, вы будете ОЧЕНЬ недовольны, если ваши данные условно сольют из-за уязвимости в инструменте или в важный момент упадёт один из ваших любимых сайтов.
Узявимости могут быть у всех, но чем сложнее технология, тем больше шанс того, что там лежит дыра в безопасности. Просто о ней не знают не потому что её там нет, а потому что её мало не заметит в переусложненном коде.
Сейчас бы верить в то, что раз технология опенсорс, то она не влияет на рынок... Сейчас бы базовую экономику в "шизу" записывать, инвестиций и акций ведь не существует, правда?) Корпорации, видимо, эти технологии от чистого сердца пилят, добрые самаритяне)
Если вы хотите понять, как можно монополизировать рынок опенсорсными решениями, предлагаю изучить историю Chromium, как он отказался от поддержки NPAPI, к чему это привело и как "опенсорсный" Chromium привёл гугл к монополизации их V8.
Тогда вопрос уже переходит на плоскость того, что вообще означает фраза "сложные приложения". Если подразумеваются гиганты типа Facebook/VK/Pinterest и прочего, то тогда почему другие делают на этих инструментах "микросайты", ведь очевидно, что инстурмент под них не подходит? Если подразумевается какой-то сервис, работающий на CRUD-операциях, то это лишний жир, без которого код не усложнится. И тогда аргумент превратится в очередное "разработка дорожает", но от мира веба.
Тогда два вопроса, просто чтобы развить тему: - Не задумывались ли Вы о том, что проблема не в инструменте, а в прямоте рук? Иначе C/C++, PHP умерли бы с десяток лет назад. Суть-то в правильной архитектуре. Очевидно, что для сложного приложения нужно продумать грамотную структуру работы, иначе на полпути мы получим спагетти-код и жесткие циклы из условий и коллбеков. Тогда вопрос, а так ли нужен современный фреймворк или всё же нужен нормальный инструмент, который проявит себя с грамотным применением?
- Что такого магического есть у фреймворка, который позволяет делать сложные приложения с кучей бизнес-логики, чего не умеют классические решения? Вот чем принципиально отличается "сложное приложение" от несложного? Все говорят "для сложных приложений с кучей бизнес-логики", но никто не поясняет какой..
Вот именно. Каждому инструменту свой спектр задач. Но джунам нужно набивать портфолио кучей ToDo-листов, поэтому вместо подходящего инструмента используют условный React для лендингов и простых проектов, где PHP с MySQL уже покрыли бы все задачи
Это прекрасная статья, которая наконец озвучивает то, что копилось все эти годы: зачем начали усложнять веб? И действительно: логика веба была проста и понятна всегда: есть программа с HTTP-сервером, который парсит запрос, выдаёт текст в виде plain/HTML/JSON/тд.. С каких пор там появился весь этот жир в виде бойлерплейтов, миддлвейров и прочего? Зачем скачивать пользователю километры обфусцированных JS-скриптов, чтобы что? И зачем сервер нагружать лишними вычислениями?
Это прекрасная статья и пример того, как оптимизация творит чудеса. В мире, где игры с контентом на несколько часов раздуваются на сотни гигабайт это золото. Всегда фанател по играм Sega/SNES, где абсолютно вся игра с сюжетом, диалогами, катсценами, графикой умещалась в скромные два мегабайта.
Автор великолепен, апплодирую стоя, это безупречная работа с памятью и вычислениями! :)
Интересная статья про минималистичный веб! Вышло здорово, в очередной раз показывает, что хорошее обращение с матчастью позволяет творить чудеса оптимизации :)
Конечно в комнате, во-первых создайте новый пустой проект в React или в NestJS и отмерьте, как больше сотни мегабайт уходит в пустой (!) проект, я подожду (да, создание пустого проекта требует минуты времени). А ещё сколько весит сам React/NestJS, рантайм NodeJS (почти сотка мегабайт), докер с его контейнером, поверх ещё фреймворк (или сервер nginx полсотки + PHP, тоже под сотку выйдет), база данных (это тоже пара сотен мегабайт) и так мы получим гигабайт на то, чтобы сайт просто работал со всем стеком. И это я умолчал про пакеты, зависимости (которые весят больше, чем сами исходные пакеты) и дополнительный софт по типу (phpMyAdmin) или дешборда, они вместе весят как раз те самые "гигабайты мусора".
Теперь к докеру. Где я упоминал, что мой проект не совместим с докером, я не нашёл. Если вы это противопоставили как аргумент "переносимости", "оверхеду" и прочего, то во-первых, насчёт переносимости, это отдельная технология, которую надо устанавливать (!). А насчёт оверхеда, он не решает эту проблему, потому что оверхед не в докере, а в самих инструментах, которые внутри переносятся.
С микросервисами отлично, ваш аргумент показательно пояснил суть: при онбаружении bottleneck, вместо того, чтобы его чинить, его просто закидывают дополнительной мощностью. Но если разбирать сам аргумент, у меня эта проблема решается через распределение ядер процессора, где при той же проблеме можно на отдельный рут (да, в монолите можно делать микросервис в виде рутов) добавить мощности, перекинув ядра процессора.
А преподносить в качестве примера Flask и FastAPI была отличная идея. Сравнивать весь стек технологий с фреймворком и роутером, при том, что по вашим же метрикам тяжелее моего решения и потребляет больше, очень показательно.
Но раз Вы отлично знаете JS, тогда приглашаю в паблик, там будут этапы разработки и части кода, когда выпишусь. Аудит со стороны не помешает, мне как раз нужна будет помощь с асинхронными функциями у сервера. Так что Ваш вклад приветствуется :)
Насчёт тейка про менеджемент. Технически это инструмент, строгая типизацая в JS. На языке менеджемента это конституция чистого кода, которая обязывает её следовать. Это не плохо и не хорошо, просто это мотив, зачем такие инструменты создаются.
Опять же, почему правила JavaScript это "проблема плохой типизации"? Типизация JS имеет особенности, которые прописаны в самом движке, это преобразование типов, которое имеет свою логику.
Насчёт Вашей колкой "просьбы" освоить языки со сторогой типизацией, я пробовал, но не втянуло, JS нравится больше. В ответ на Вашу пассивную агрессию предлагаю "попробовать освоить сам JS и Вы удивитесь, как станет лучше, когда вы знаете основы языка")
В любом случае, я заметил, что диалог уходит в вечный спор про holy war типизаций, который не приведёт к значимому результату. Так что предлагаю либо наблюдать за развитием проекта и тем, как используется JS в рамках моего проекта, либо продолжать длинную ветвь комментариев, что я бы счёл неуважением к моим зрителям, которым всё это читать :)
Конечно, TypeScript придумали не просто так, ведь нужно поддерживать единую структуру кода среди разработчиков. В конце концов, Microsoft, как и любая компания, работающая на выгоду, делает подобные вещи не ради всеобщего блага, просто это также инструмент менеджемента, который позволяет использовать статическую типизацию в JS.
Я ничего не имею против TypeScript и тех, кто его использует, просто я считаю динамическую типизацию и его особенности в JS наоборот фичей. Кому-то она мешает, а мне помогает.
Благодарю, тоже никаких претензий, просто отвечаю на вопросы насчёт моего проекта :) (не люблю слово "продукт", убивает душу, словно это товар)
Да, это возвращение в прошлое, но на современных реалиях. Не вижу ничего зазорного в том, чтобы брать лучшее из разных временных эпох, в конце концов это не просто "раньше было лучше", а конкретный собирательный образ из того, что было хорошо, а что можно улучшить)
Тогда это меняет дело. Если тема заходит о языках, то чистый JS в моём движке используется по четырём причинам:
1) браузер понимает на фронте именно нативный чистый JS, все остальные диалекты типо JSX или того, что у Svelte (если Вы имеете в виду их) потом переводятся всё равно в чистый JS через чёрный ящик транспилятора, это посредники. А так есть прямое общение с браузером.
2) Ради большинства диалектов приходится пересобирать проект, потому что, как я сказал выше, это всё равно пережёвывается в нативный JS. Удобно ли писать фронт? Наверное. Удобно ли ждать сборку после каждого изменения? Вряд ли.
3) Каждый фреймворк предлагает отдельный язык для фронта и каждый из них учить. Это в целом странно и если лезть глубже, то это убивает айти рыночек, это делает из программистов одноразовых джунов, которые живут до тех пор, пока живёт фреймворк. Когда фреймворк предлагает свой диалект, человек его учит, тратит месяцы, работает на нём и всё хорошо. Но как только фреймворк устаревает, человек уже не нужен с этими знаниями, почему?.. он учил диалект, а не сам язык, его знания ограничены диалектом, и это не его вина. Поэтому я пишу на чистом JS, так как это будет полезно для тех, кто его освоит. Они будут знать не что-то выдуманное, а сам JS и ООП. Это база.
4) Это самый отличный вариант для контроля и стабильности. Что значит создавать диалект или свой язык? Это: писать транспилятор, писать плагины для известных редакторов кода, писать документацию не к объектам, а к самому языку, это продавать курсы. Для гаражной инженерии с бюджетом в два дошика это на грани возможного. А JS стирает эту грань и позволяет создавать что-угодно из объектов и его методов. В этом прелесть.
Каждый инструмент для своей области задач. Проект не создан, чтобы "убить условный React или NestJS". Зачем его убивать, если он хорош для крупного бизнеса? А вот инструментов для инди и стартапов пока маловато, и использование гигантов это перебор.
Именно так. Для менеджемента и для организации разных отделов команд микросервисы - идеальное решение таких задач. Но в плане работоспособности есть жинзненноважный код и сколько его ни дели, при ошибке базовые функции станут недоступны.
Ты абсолютно прав! Не стоило было сейчас кидать ядерку.
Хочешь, расскажу о вреде ядерного оружия?
а второй остров Эпштейна?
И вдруг про монополизацию Google с V8 мы, конечно же, стыдливо умолчали, как же так) Что насчёт ботов, они мне неинтересны, к чему вы приплели это соломенное чучело, не понимаю.
Ну и я так полагаю, вы отклонили предложение изучить историю, ведь "неудобно получится")
Советую научиться читать до конца, где уже пояснена монополия.
P.S. - ну и минусовать, это очень сильный аргумент, сразу видно зрелость и взросление личности
Это всё здорово, конечно, но такое "конкурентное преиущество" стоит клиенту трафика и производительности, к тому же мы бонусом получили от React2Shell и падения половины Интернета в попытке её починить. Это длилось всего пару дней, но это очень показательный пример, как часть Интернета может стать уязвимой просто потому, что многим захотелось немного performance.
Никто, конечно, не заставляет пользоваться небезопасными решениями, которые объединяют фронтенд и бекенд, напрямую нарушая стандарт (!) клиент-серверной архитектуры. Но думаю, вы будете ОЧЕНЬ недовольны, если ваши данные условно сольют из-за уязвимости в инструменте или в важный момент упадёт один из ваших любимых сайтов.
Узявимости могут быть у всех, но чем сложнее технология, тем больше шанс того, что там лежит дыра в безопасности. Просто о ней не знают не потому что её там нет, а потому что её мало не заметит в переусложненном коде.
Сейчас бы верить в то, что раз технология опенсорс, то она не влияет на рынок... Сейчас бы базовую экономику в "шизу" записывать, инвестиций и акций ведь не существует, правда?) Корпорации, видимо, эти технологии от чистого сердца пилят, добрые самаритяне)
Если вы хотите понять, как можно монополизировать рынок опенсорсными решениями, предлагаю изучить историю Chromium, как он отказался от поддержки NPAPI, к чему это привело и как "опенсорсный" Chromium привёл гугл к монополизации их V8.
То есть раздувание 10-строчного кода отдельным модулем с библиотеками, которых больше, чем строк этого кода?
Тогда вопрос уже переходит на плоскость того, что вообще означает фраза "сложные приложения". Если подразумеваются гиганты типа Facebook/VK/Pinterest и прочего, то тогда почему другие делают на этих инструментах "микросайты", ведь очевидно, что инстурмент под них не подходит?
Если подразумевается какой-то сервис, работающий на CRUD-операциях, то это лишний жир, без которого код не усложнится. И тогда аргумент превратится в очередное "разработка дорожает", но от мира веба.
Тогда два вопроса, просто чтобы развить тему:
- Не задумывались ли Вы о том, что проблема не в инструменте, а в прямоте рук? Иначе C/C++, PHP умерли бы с десяток лет назад. Суть-то в правильной архитектуре. Очевидно, что для сложного приложения нужно продумать грамотную структуру работы, иначе на полпути мы получим спагетти-код и жесткие циклы из условий и коллбеков. Тогда вопрос, а так ли нужен современный фреймворк или всё же нужен нормальный инструмент, который проявит себя с грамотным применением?
- Что такого магического есть у фреймворка, который позволяет делать сложные приложения с кучей бизнес-логики, чего не умеют классические решения? Вот чем принципиально отличается "сложное приложение" от несложного? Все говорят "для сложных приложений с кучей бизнес-логики", но никто не поясняет какой..
Вот именно. Каждому инструменту свой спектр задач.
Но джунам нужно набивать портфолио кучей ToDo-листов, поэтому вместо подходящего инструмента используют условный React для лендингов и простых проектов, где PHP с MySQL уже покрыли бы все задачи
Это прекрасная статья, которая наконец озвучивает то, что копилось все эти годы: зачем начали усложнять веб?
И действительно: логика веба была проста и понятна всегда: есть программа с HTTP-сервером, который парсит запрос, выдаёт текст в виде plain/HTML/JSON/тд.. С каких пор там появился весь этот жир в виде бойлерплейтов, миддлвейров и прочего?
Зачем скачивать пользователю километры обфусцированных JS-скриптов, чтобы что? И зачем сервер нагружать лишними вычислениями?
Когда кажется - креститься надо.
Настоящий уровень аргументации и фактуры...
Это прекрасная статья и пример того, как оптимизация творит чудеса. В мире, где игры с контентом на несколько часов раздуваются на сотни гигабайт это золото. Всегда фанател по играм Sega/SNES, где абсолютно вся игра с сюжетом, диалогами, катсценами, графикой умещалась в скромные два мегабайта.
Автор великолепен, апплодирую стоя, это безупречная работа с памятью и вычислениями! :)
Интересная статья про минималистичный веб! Вышло здорово, в очередной раз показывает, что хорошее обращение с матчастью позволяет творить чудеса оптимизации :)
Спасибо за ответ
Конечно в комнате, во-первых создайте новый пустой проект в React или в NestJS и отмерьте, как больше сотни мегабайт уходит в пустой (!) проект, я подожду (да, создание пустого проекта требует минуты времени). А ещё сколько весит сам React/NestJS, рантайм NodeJS (почти сотка мегабайт), докер с его контейнером, поверх ещё фреймворк (или сервер nginx полсотки + PHP, тоже под сотку выйдет), база данных (это тоже пара сотен мегабайт) и так мы получим гигабайт на то, чтобы сайт просто работал со всем стеком. И это я умолчал про пакеты, зависимости (которые весят больше, чем сами исходные пакеты) и дополнительный софт по типу (phpMyAdmin) или дешборда, они вместе весят как раз те самые "гигабайты мусора".
Теперь к докеру. Где я упоминал, что мой проект не совместим с докером, я не нашёл. Если вы это противопоставили как аргумент "переносимости", "оверхеду" и прочего, то во-первых, насчёт переносимости, это отдельная технология, которую надо устанавливать (!). А насчёт оверхеда, он не решает эту проблему, потому что оверхед не в докере, а в самих инструментах, которые внутри переносятся.
С микросервисами отлично, ваш аргумент показательно пояснил суть: при онбаружении bottleneck, вместо того, чтобы его чинить, его просто закидывают дополнительной мощностью. Но если разбирать сам аргумент, у меня эта проблема решается через распределение ядер процессора, где при той же проблеме можно на отдельный рут (да, в монолите можно делать микросервис в виде рутов) добавить мощности, перекинув ядра процессора.
А преподносить в качестве примера Flask и FastAPI была отличная идея. Сравнивать весь стек технологий с фреймворком и роутером, при том, что по вашим же метрикам тяжелее моего решения и потребляет больше, очень показательно.
Вот и отлично, тогда расходимся :)
Но раз Вы отлично знаете JS, тогда приглашаю в паблик, там будут этапы разработки и части кода, когда выпишусь. Аудит со стороны не помешает, мне как раз нужна будет помощь с асинхронными функциями у сервера. Так что Ваш вклад приветствуется :)
Насчёт тейка про менеджемент. Технически это инструмент, строгая типизацая в JS. На языке менеджемента это конституция чистого кода, которая обязывает её следовать. Это не плохо и не хорошо, просто это мотив, зачем такие инструменты создаются.
Опять же, почему правила JavaScript это "проблема плохой типизации"? Типизация JS имеет особенности, которые прописаны в самом движке, это преобразование типов, которое имеет свою логику.
Насчёт Вашей колкой "просьбы" освоить языки со сторогой типизацией, я пробовал, но не втянуло, JS нравится больше. В ответ на Вашу пассивную агрессию предлагаю "попробовать освоить сам JS и Вы удивитесь, как станет лучше, когда вы знаете основы языка")
В любом случае, я заметил, что диалог уходит в вечный спор про holy war типизаций, который не приведёт к значимому результату. Так что предлагаю либо наблюдать за развитием проекта и тем, как используется JS в рамках моего проекта, либо продолжать длинную ветвь комментариев, что я бы счёл неуважением к моим зрителям, которым всё это читать :)
Конечно, TypeScript придумали не просто так, ведь нужно поддерживать единую структуру кода среди разработчиков. В конце концов, Microsoft, как и любая компания, работающая на выгоду, делает подобные вещи не ради всеобщего блага, просто это также инструмент менеджемента, который позволяет использовать статическую типизацию в JS.
Я ничего не имею против TypeScript и тех, кто его использует, просто я считаю динамическую типизацию и его особенности в JS наоборот фичей. Кому-то она мешает, а мне помогает.
Благодарю, тоже никаких претензий, просто отвечаю на вопросы насчёт моего проекта :) (не люблю слово "продукт", убивает душу, словно это товар)
Да, это возвращение в прошлое, но на современных реалиях. Не вижу ничего зазорного в том, чтобы брать лучшее из разных временных эпох, в конце концов это не просто "раньше было лучше", а конкретный собирательный образ из того, что было хорошо, а что можно улучшить)
Тогда это меняет дело. Если тема заходит о языках, то чистый JS в моём движке используется по четырём причинам:
1) браузер понимает на фронте именно нативный чистый JS, все остальные диалекты типо JSX или того, что у Svelte (если Вы имеете в виду их) потом переводятся всё равно в чистый JS через чёрный ящик транспилятора, это посредники. А так есть прямое общение с браузером.
2) Ради большинства диалектов приходится пересобирать проект, потому что, как я сказал выше, это всё равно пережёвывается в нативный JS. Удобно ли писать фронт? Наверное. Удобно ли ждать сборку после каждого изменения? Вряд ли.
3) Каждый фреймворк предлагает отдельный язык для фронта и каждый из них учить. Это в целом странно и если лезть глубже, то это убивает айти рыночек, это делает из программистов одноразовых джунов, которые живут до тех пор, пока живёт фреймворк. Когда фреймворк предлагает свой диалект, человек его учит, тратит месяцы, работает на нём и всё хорошо. Но как только фреймворк устаревает, человек уже не нужен с этими знаниями, почему?.. он учил диалект, а не сам язык, его знания ограничены диалектом, и это не его вина. Поэтому я пишу на чистом JS, так как это будет полезно для тех, кто его освоит. Они будут знать не что-то выдуманное, а сам JS и ООП. Это база.
4) Это самый отличный вариант для контроля и стабильности. Что значит создавать диалект или свой язык? Это: писать транспилятор, писать плагины для известных редакторов кода, писать документацию не к объектам, а к самому языку, это продавать курсы. Для гаражной инженерии с бюджетом в два дошика это на грани возможного. А JS стирает эту грань и позволяет создавать что-угодно из объектов и его методов. В этом прелесть.
Правильный ход мыслей :)
Каждый инструмент для своей области задач. Проект не создан, чтобы "убить условный React или NestJS". Зачем его убивать, если он хорош для крупного бизнеса? А вот инструментов для инди и стартапов пока маловато, и использование гигантов это перебор.
Именно так. Для менеджемента и для организации разных отделов команд микросервисы - идеальное решение таких задач. Но в плане работоспособности есть жинзненноважный код и сколько его ни дели, при ошибке базовые функции станут недоступны.