Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
Рискну предположить, что не сами фреймворки — зло, а неумелое их применение.
P.S. Хотя да, веб-приложения, сделанные на голом JavaScript, оказываются производительнее, чем если бы их сделали на каком-либо фреймворке.
However if you want to get the best performance, benchmarks have shown time and time again, that a tuned vanilla js application outperforms any framework.
Здравствуйте, Lazytech, Вы писали:
НС>>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе. L>Рискну предположить, что не сами фреймворки — зло, а неумелое их применение.
Именно это я и написал, когда насильно запихивают фреймворки даже туда, где вреда от них больше, чем пользя.
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Рискну предположить, что не сами фреймворки — зло, а неумелое их применение. НС>Именно это я и написал, когда насильно запихивают фреймворки даже туда, где вреда от них больше, чем пользя.
Ключевое слово — неумелое, а не неуемное. По-дилетантски предположу, что при умелом применении фреймворка производительность сильно не пострадает.
Здравствуйте, Ночной Смотрящий, Вы писали:
A>>>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер. L>>Это потому, что ОЗУ мало, что ли? Или ЦП не потянет?
НС>Это потому что у современных фронтендеров руки из жопы. У нас тут попытались без мегафреймворков несложный UI в одном проекте сделать — так в результате остальные фронтенд-господа за это форменным образом зачмырили. Раз нет реакта или ангуляра, значит фтопку.
Махровый техно-расизм однако. Правильно сделали, что вас зачмырили Большей частью для фронта лучше взять готовое решение, а не пилить своё. "без мегафремворков" майнтейнить гораздо тяжелее.
В норме опытные фронтенды вынуждены бегать по проектам и тушить пожары, потому что ктото решил понаписывать кастомных решений. После таких вот пожаров лучше убивать подобные начинания еще в зародыше
Здравствуйте, Ikemefula, Вы писали:
I>Махровый техно-расизм однако. Правильно сделали, что вас зачмырили Большей частью для фронта лучше взять готовое решение, а не пилить своё.
Свое никто не пилил, оно там просто не нужно.
I>В норме опытные фронтенды вынуждены бегать по проектам и тушить пожары, потому что ктото решил понаписывать кастомных решений.
Там не было никаких пожаров, там все прекрасно работало и без фреймворков.
Здравствуйте, Privalov, Вы писали:
P>Ну тут как сказать. P>Во-первых, фреймворк фреймворку рознь. P>Во-вторых, получив фреймворк, разработчики зачем-то усиленно начинают его переписывать. Вместо того, чтобы решать поставленную задачу. P>В-третьих, если во фреймворке отсутствует какая-то нужная возможность, разработчики будут искать ее в других фреймворках, и потом притянут эти другие фреймворки в проект. Со всеми вытекающими. P>Насмотрелся я на такое. Не в вебе, правда, но говорят, что и там то же самое.
В бесфремворковом мире все еще хуже — появляется свой кастомный полу-реакто-ангуляр, с экзотическим стейтменеджментом, шаблонами, билдами, конфигурацией, рендерингом, и все это спихивают на первого попавшегося миддла, иногда даже джуна.
По этому кастомному решению нет документации, неизвестно, какие фичи реализованы, какие проблемы, какие соглашения поддерживаются, неизвестно вообще ничего. Как правило, качество решения крайне низкое, т.к. все кастомное.
Очень редко бывает так, что бы кастомное решение было высокого качества, было понятным со стороны кода и тд.
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Вообще-то фреймворки заметно упрощают разработку, так что...
НС>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
Если притимивный функционал тормозит на современном фремворке, то с большой вероятностью кастомное решение будет работать еще хуже.
Что бы кастомное работало лучше фремворка, то фронтенд-девелопер должен обладать весьма незаурядной квалификацией.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе. L>>Рискну предположить, что не сами фреймворки — зло, а неумелое их применение.
НС>Именно это я и написал, когда насильно запихивают фреймворки даже туда, где вреда от них больше, чем пользя.
Да нет, ты написал совсем другое: "у современных фронтендеров руки из жопы. ... фронтенд-господа за это форменным образом зачмырили"
Несложный UI пилится быстрее всего на фремворках, сгенерил проект и половина фич идут готовыми. Порылся в инете — нашел половину недостающих.
А вот сложный UI нужно пилить очень осторожно — не факт, что фремворк обладает нужными средствами, свойствами и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Если притимивный функционал тормозит на современном фремворке, то с большой вероятностью кастомное решение будет работать еще хуже. I>Что бы кастомное работало лучше фремворка, то фронтенд-девелопер должен обладать весьма незаурядной квалификацией.
Да да, чтобы написать вместо реактовской мутатени с компаратормами примитивный код по правке DOM, нужно незаурядную квалификацию.
Вот я и говорю, у фронтендеров руки из жопы, мимо своих фреймворков уже даже мыслить не могут.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Несложный UI пилится быстрее всего на фремворках, сгенерил проект и половина фич идут готовыми.
НС>Каких фич?
Разных. Сгенерируй несколько приложений, сразу узнаешь что к чему. ЦА фремворка это мелкие...средние приложения. Так было во все времена на всех платформах. Вот с большими приложениями очень часто идут без фремворка или с ограниченым применением фремворка.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Если притимивный функционал тормозит на современном фремворке, то с большой вероятностью кастомное решение будет работать еще хуже. I>>Что бы кастомное работало лучше фремворка, то фронтенд-девелопер должен обладать весьма незаурядной квалификацией.
НС>Да да, чтобы написать вместо реактовской мутатени с компаратормами примитивный код по правке DOM, нужно незаурядную квалификацию.
Не смеши людей, нету там мутатени, вход в реакт еще ниже, чем в jQuery. Но если в голове образовались рельсы "по правке DOM" то это отдельная проблема.
Ручная правка DOM это почти всегда неподдерживаемый код, когда всё прибито гвоздями одно к одному. В реакте все что нужно — взять минималистичный шаблон проекта и подумать, как у вас данные устроены. Если всё действительно просто, то и редух не понадобится. Студенты такое пилят по десятку за неделю при необходимости.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
Возможно, надо было с самого начала уточнить, что именно тормозит: прорисовка UI или что-то другое? Если сморозил глупость, прошу извинить.
К примеру, в последнее время я ради получения практических знаний пытаюсь делать простенькие веб-приложения под руководством опытного разработчика. Одно из этих приложений заметно глючит и сильно подтормаживает из-за моего неумелого обращения с асинхронными методами. При этом собственно UI работает быстро, а тормоза вызваны очень медленной загрузкой файлов на сервер и достаточно медленным получением файлов с сервера.
Здравствуйте, Lazytech, Вы писали:
L>Здравствуйте, alexsmirnoff, Вы писали:
A>>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер.
L>Это потому, что ОЗУ мало, что ли? Или ЦП не потянет?
Здравствуйте, alexsmirnoff, Вы писали:
A>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер. A>Запустишь хром и можешь идти чайку попить, как раз минут через пять страничка вылезет.
Ну не надо вот только преувеличивать. Десятилетние компьютеры сейчас работают с современными браузерами лучше, чем 10 лет назад.
Здравствуйте, Слава, Вы писали:
I>>Студенты такое пилят по десятку за неделю при необходимости.
С>А речь разве об этом? О скоростной разработке силами студентов?
С>Оно — тормозит.
Если тормозит маленькое приложение, то проблема точно не в Реакте. Полно внятных приложений и на ангуляре, и на реакте. Ты их используешь каждый день и даже не замечаешь.
Здравствуйте, Lazytech, Вы писали:
НС>>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
L>Возможно, надо было с самого начала уточнить, что именно тормозит: прорисовка UI или что-то другое? Если сморозил глупость, прошу извинить.
Антивирус наверное
L>К примеру, в последнее время я ради получения практических знаний пытаюсь делать простенькие веб-приложения под руководством опытного разработчика. Одно из этих приложений заметно глючит и сильно подтормаживает из-за моего неумелого обращения с асинхронными методами. При этом собственно UI работает быстро, а тормоза вызваны очень медленной загрузкой файлов на сервер и достаточно медленным получением файлов с сервера.
Здравствуйте, Ikemefula, Вы писали:
I>Не смеши людей, нету там мутатени, вход в реакт еще ниже, чем в jQuery.
Ты даже не понимаешь о чем речь. Дело не во входе, а в том что реакт при правке DOM делает кучу лишних действий. При этом на простых страничках разницы в объеме межу реактом и vanilla js очень мало.
Здравствуйте, Слава, Вы писали:
I>>Студенты такое пилят по десятку за неделю при необходимости. С>А речь разве об этом? О скоростной разработке силами студентов?
А это вот наглядная демонстрация того, о чем я писал. У них мысль в сторону от фреймворков даже не ходит, вопрос о том нужно ли его применять даже не задается. Неизвестно, про какой я писал проект, что он делает, но уже точно известно что реакт нужен обязательно.
Большей частью для фронта лучше взять готовое решение, а не пилить своё. "без мегафремворков" майнтейнить гораздо тяжелее.
