Может ли быть такое, чтобы фреймворк был быстрее ванили?

Question

[Карлиндоу Мэрлифи]

Удобнее быть может это точно, а вот мощнее...
Библы же делаются на основе ванильного ЯП

Answer 1

[Алексей Уколов]

Внутри фреймворка, за счёт эффекта масштаба, могут быть реализованы оптимальные алгоритмы и применены какие-то оптимизации, ухудшающие читаемость кода, но ускоряющие его, которых может не быть в том ванильном коде, который напишете вы. Но, конечно, это редкий сценарий и в общем случае код без фреймворка будет работать быстрее или так же (Svelte).

Comments

[imko]

Есть еще вариант с кривыми руками разраба, который пишет ваниль, а используя фреймворк не создает криво те части, которые там уже реализованы)

[Алексей Уколов]

imko, ну, я это и написал, только дипломатичнее :)

[imko]

Алексей Уколов, так дипломатично что я аж не понял сразу)

[Adamos]

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

У меня так одна программа при переходе со статичных массивов и ручного управления памятью на банальный STL стала заметно раньше давать тот результат, который от нее, собственно, требовался - хотя и искала его, возможно, менее оптимально.

Answer 2

[mayton2019]

Ответ - и да и нет.

Обычно классический ЯП - предполагает прямое (директивное) управление процессом.
И качество оптимизации будет сильно зависеть от того как программист проработал весь прямой ход алгоритма.
В том числе работу с I/O и сетью.

Фреймворк - это ограничитель, который очень строго лимитирует присуствие программиста в результирующем
коде. В идеале программист делате только хендлеры. Или лямбды. Как в Inversion of Control.
Это позволяет хорошему фреймворку сильно соптимизировать поток выполнения базируясь
на том что I/O и сеть будут обеспечиваться фреймворком а программист будет вставлять только лямбды.
Кроме сети и ввода-вывода фреймворк может обеспечивать пул объектов (соединения с БД)
и типичные шаблоны обработки ошибок (retry-pattern) перформанс (cirquit-breaker) и
рейт-лимитеры и троттлинг.

Очень хороший программист который в этом разбирается может улучшить использование
фреймворка а иногда и полностью его заменить. Это будет очень медленно в разработке и дорого в оплате.

Но мы исходим из предположения что 80% программистов - середнячки и звезд с неба не хватают.
Поэтому для них фреймворк - является предпочтительной методикой. И код с фреймворком
скорее всего будет быстрее чем при прямом кодировании на той-же выборке кодеров-середнячков.

Answer 3

[Максим Морев]

Фреймворк за счёт внутренних оптимизаций может работать быстрее, чем плохо написанный ванильный код.
Хотя даже это по большей части работает на синтетических примерах.

Самый наивный из них:
Например, вам надо добавить 10 000 узлов в DOM.
Плохо написанный код будет выглядеть как цикл, на каждой итерации которого вы будете обращаться к DOM API, добавляя элемент.
Хорошо написанный код (как и код, который сгенерирует фреймворк, вероятнее всего) в цикле соберёт всё необходимое и по окончании одним запросом к DOM API вставит на страницу.

Answer 4

[Adamos]

Вообще-то 90% задач в JS предполагают, что решительно всем решительно похрен, что там в попугаях.
Лишь бы не глючило и можно было легко исправить.
Язык, просто-таки предназначенный для фреймворков.
Во всяком случае, его браузерная часть.
А если вам позарез понадобились реальные оптимизации - так пишите не на ванили, а на чем-нибудь низкоуровневом и собирайте в WebAssembly,