Pull to refresh
-5
0
Владимир @Bigata

web разработчик

Send message

Конечно в них. Их же матом обкладываю ;) Библиотеки и фреймворки очень сильно понижают порог входа и расхолаживают. + мало кто реально оптимизирует скрипты. Да пофиг что в цикле к бд запросы, да пофиг масиив будем перебирать в лоб, да пофиг ... моного чего ещё.

Ну вот в самую точку попали.

Да всё просто коллега. Берете ноут 5-6 летней и запускаете.

Я матом обкладываю разработчиков, которые написали Web для пары крупных банков, на react. Да, на современном компе с 16Гб, как-то работает, а вот на таком ноуте одни мучения. И это если не глянуть консоль, куда куча инфы зачем-то попадает. И эти поделия в прод выпустили.

Конечно признаю, и да, ООП классная фича. Вот только использовать бы её по назначению. А так и микроскопом гвозди забивать можно.

Плюсуюсь всеми конечности. TS хайп, нужны библиотеки JS, никто не пишет на ваниле и т.д. и т.п. Вот ООП стало хайпом, лепят всюду, когда нужно и не нужно. Отсюда и желание JS сделать настоящим ООП языком, но вот никак не вижу, зачем из него лепить java...

О да, ждём'с нормальный импорт

А не в виде json в slim данные из бд феньшуй не позволяет?

Можно даже div черным раскрашенные делать

Зашёл почитать в комментариях холи-срач, но пока тихо.

Есть пара вопросов: вот это тэг <app-button></app-button>,

А на фига? Неужели все настолько "продвинулись", что забыли наивный js, с современными api HTML5?

И почему ангуляр это фреймворков, а реакт библиотека? Дайте тогда определение, а так это голимое IMHO.

Наверное по этот перл: "В отличие от виртуального DOM, в инкрементном DOM память расходуется при перерисовке дерева DOM, если только в нем произошли изменения (то есть были удалены или добавлены элементы). Кроме того, выделение памяти пропорционально размеру изменений" стоит оригинал перечитать, но в переводе уж0с какой-то. Хотя как сказать, дуралеи наверное без изменения DOM могут его перерисовать а-ля ... render(). Ну а концовка фразы перл ещё тот - неужели V8 движек даёт клиентскому скрипту залезать в память? Извините - не поверю; V8 прекрасно сам сжти сейчас управляется.

Соль на спину уж точно. Excel никак не отнять, все привыкли.

Вот плюсуюсь неоднократно. Лучше самому представлять как регулярки работают.

~1с это по Вашему хорошо?

MyISAM - сам по себе, довольно медленный движок и он не рассчитан на 50 000 (!) товаров

Очень и очень спорное мнение. Для SELECT Myisam даже побыстрее InnoDB

Хе-хе, так значит всё-таки отдаёт готовый html… Ну так я об этом в своём 1-м комментарии и писал "… на сервере собирается готовый html...", Вы просто невнимательно прочитали мой комментарий и сделали неправильный вывод, за уши притянув «концептами SPA и SSR».
А что, нода быстрее соберёт готовый html? Где-то видел статью, где пробовали измерить эту скорость, примерно везде одинаковая, php или python, уже точно не вспомню, побыстрее на apache оказался
С чего это Вы взяли, что серверный язык должен выполнять js код?
Хоть SPA, хоть чёрт в ступе, на сервере скрипт может отдать данные например в виде json'а и на клиенте эти данные клиентский скрипт должен разместить как надо. И хоть нода, хоть asp, php, python и т.д. сделают это примерно одинаково по времени. Поэтому неуместно спорить о том, что серверный язык поможет скорее загрузить клиентский интерфейс.

Ну не знаю, я полагал, что интерфейс это некий шаблон, скелет, куда данные "расставляются", чтобы с ними потом что-то делать: глазеть на них, работать с ними и т.д. Нода работает на сервере, кроме как собрать html, не знаю как нода может ускорить клиентский интерфейс. А собрать html могут все северные языки и скорость примерно одинаковая

Интересно, как на загрузку интерфейса node влияет? Или на сервере собирается готовый html что-ли?!

Вот именно. Статья как навязчивая реклама. Для приложений, где на странице много что меняется, совершенно не подходящее решение. Как пример — много где рекламные блоки меняют содержимое неоднократно, их что, каждый раз перегонять туда сюда…

Information

Rating
5,701-st
Location
Москва, Москва и Московская обл., Россия
Registered
Activity